[Grok-dev] grok.zope.org design proposal (ok, kill me...)
sebastian at urbantalk.se
Fri May 25 10:20:29 EDT 2007
Note 1: I have considered the caveman as part of the content.
Note 2: There are some artefacts that are obviously miscoloured
(hint: red or purple...). Their colours will be changed.
Note 3: Use Firefox or Safari (Internet Explorer needs some standards
defying fixes... ;)).
Note 4: I have tested with Firefox and Safari on a Mac, please report
Note 5: I have listened to all the feedback, but everything wasn't
doable within the time constraints.
You can click on tracks
**/ Website Structure Overview /**
"If we keep it simple, it becomes accessible."
The website is based on a semi-structured content model with keyword
tagging and tracks. There are five tracks, four of them representing
the developer life-cycle and the fifth being action driven:
-Share ("contribute" was too long, I have tried!)
(A more detailed outline was posted as "[Grok-dev] Suggested site
There are three ways of accessing content from within the website:
-Follow a track
-Use keyword tags
-Use boolean full-text search
This allows for a variety of entry points into the content. Tracks
are contextual guides and tags allow content oriented access. Full-
text searching might in the long run prove to be the most useful way
of accessing the content for returning visitors.
*/ Evaluate /*
Guides a new user to answer the question: Is this framework worth
*/ Learn /*
All that is needed to get up and running, including trying and
modifying sample code.
*/ Develop /*
Resources and documentation that is needed during development of
applications. This would include the user-community and here is where
reference documentation, patterns and practices etc. would reside.
*/ Share ("contribute" was too long) */
"Sharing is caring" A track covering how to contribute by sharing
time/code/money/other and the resources needed to support GROK. This
would include the core-developer community.
**/ Publishing Workflow /**
Each track is maintained by a separate editor. Content follows the
Draft / Pending / Published / Archived / Trashed
In the early stages, content is gathered by the editor who edits and
publishes the material. The Download track will probably be supported
by some kind of version repository.
If things develop well, each editor could have a couple of regular
writers who help maintain the content. Alternatively editing and
publishing content/updates that are submitted ad hoc by users.
The purpose of using an editor driven publishing process rather than
an adhoc wiki, is to maintain a consistent quality and writing style.
**/ Knowledge Base (Forums with a twist) /**
I would like to add a forum with a twist within the next six months.
The twist would be to make it easy to track questions and solutions
in order to create a user generated knowledge base. Traditional
forums tend to require you to read entire threads to figure out what
the actual solution is. This makes them difficult to maintain.
Question/Problem > Discussion...,
Solution > Discussion...,
Revised Solution > Discussion...,
I believe this model will be easier to navigate than traditional
forums and a good complement to the regular editor driven content on
More information about the Grok-dev