[kdewebdev-site] Phase I design and development opportunities

[Eric Laffoon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 13 April 2004 6:55 pm, David Joham wrote:
> Hello all!
>
> Here's my first pass at the jobs that will need to be assigned for the
> initial work on Phase I. Please review and comment if you see any jobs I
> left out or some you don't think need to be here yet. Please keep in mind
> that these are only the jobs for the initial work on Phase I, not all that
> will be needed to complete the work.
>
> 1) www.kdewebdev.org and <tool>.kdewebdev.org page layout prototype. I want
> to have an XHTML prototype with graphics for approval as soon as possible.

As Bill mentioned we are looking to hear from Americo.
>
> 2) www.kdewebdev.org and <tool>.kdewebdev.org site map. What tools are
> going to be included in Phase I? What will the navigation options be?

I've submitted a proposed navigation, which of course could change, but since 
the tool sites are clones and most tool owners are on board I don't see why 
they can't all go... a possible exception is Kallery just because:
1) something's up
2) It's not yet in CVS
>
> 3) A list of www.kdewebdev.org and <tool>.kdewebdev.org content providers.
> I want to know who is committed to writing content for these sites so we
> can get them on board as soon as possible.

I am committed to working on the content for Quanta and Kommander, though I 
probably will end up not having to do much Quanta and a fair amount of 
Kommander. So far every tool owner I've spoken to was on board to work with 
the team to provide content.
>
> 4) A "Build or Buy" strategy. I would like to know if any existing tools
> (such as Plone or SquishDot or others) can help us create www.kdewebdev.org
> faster than if we did it from scratch. I don't have any objection to
> building our site from scratch (more fun) but one of our objectives on this
> project is getting the site running as quickly as possible. If an existing
> tool will let us do that, we should seriously consider using it.

Prebuilt software is rarely an actual savings, especially given the team we 
have here to reduce the time of a task. I think it only makes sense for a 
forum. Also a number of things we want to do are unique and we can't have 
less than excellent compliance which rules out most pre built packages. ;-)
>
> 5) An L10N strategy. This may be partially tied into #4 above but is more
> detailed as well. What L10N resources do we have? What languages do we
> want? Assuming we're going to use PHP for the development of this site (in
> either an existing tool or our own in-house tool) what is the best way to
> proceed knowing the we want to have our site in as many languages as
> possible?

Chris has proposed an idea based on what KDE does. In reflection I think KDE 
was set up with this interesting and unique procedure because of their 
familiarity with the tools. In thinking about this the idea of being able to 
use an XML processor within PHP and the ability to add tags in XHTML gives me 
the idea that this abstraction could be accomplished using XML. It would 
require a definition of the page layout elements and an XML name for those 
elements which would make content writing sort of like writing docs.

Ironically it would even be possible to still use elements of Chris' PHP code 
and solution here. My problem though is that I don't want to require every 
string to actually be written in a PHP function and I want the translation to 
be as web developer oriented as possible.
>
> 6) A database strategy. This may also tie in slightly with #4 above.
> However, I want someone to make a recommendation as to how much
> database-sourced content we're going to have for Phase I. At the moment, I
> see that Phase I could go anywhere from flat HTML files to everything being
> stored in the database. We're going to need a database developer if we do
> any database work at all.

I do a lot of database work and have a database already set up on the site. 
This is because the develop.kdewebdev.org section will be extensively 
databased. For the record I've never been a subscriber to databasing the 
entire content and I don't like static design because at the very least 
includes are needed for menus and footers. My procedure that has worked well 
in the past for me is to abstract out content and have a controling layout 
file that can load various content. It assures consistency perfectly and 
adheres to object design methodologies.

What seems attractive to me is to have a primary loader file that can assemble 
various formats or several loader files. On calling the page the loader 
assembles the rendered page from the elements included in the content. This 
is all constrained by conformance to the primary design and one of the 
standard variants. This could allow us to have a few library pages, one of 
which would be loaded into a page frame along with it's content, the 
resulting page is rendered and we could even cache it. This would give us...
1) A rather complex central layout library done by a small group
2) Very simple page frames to be built over the site with basic black box 
design
3) A high degree of content control *within* a constrained framework by 
content authors.

The additional requirement here would be a DTD or DTEP for content that would 
define the content element containers. If this came with a custom toolbar in 
a DTEP it would be very cool because to write content all you would need to 
know is the container tags for page elements. These could be laid out with 
several basic templates. ;-)
>
>
> I'm sure there's more initial Phase I work, but at the moment, I'm drawing
> a blank. For those of you who have been looking at getting going with this
> project, here's your chance! Not only am I looking for other jobs that I
> might be missing, I'm also looking for volunteers. If anything interests
> you, please let us all know so I can officially start handing out
> assignments. Here's where it starts to get fun :)
>
>
> Best regards,
>
> David
Well I've tossed all kinds of things into the pot here. ;-)
- -- 
Eric Laffoon - Quanta+ Team Leader 
http://kdewebdev.org  eric at kdewebdev.org
Mailing list - http://mail.kde.org/mailman/listinfo/quanta
GPG Fingerprint: 48FB 218D 747F A54A 319D EE98 4A25 794E A453 004B
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFAfXazSiV5TqRTAEsRAo13AKCeSn3HWSlHqhyru+D8Azwr/2WemwCfQiMU
n4SrGYtTTlWV2dBoY323CTg=
=SIu/
-----END PGP SIGNATURE-----