[Grok-dev] grok.zope.org design proposal (ok, kill me...)

Sebastian Ware 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  
rendering bugs.
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  
following workflow:

   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...,
       Revised Solution,

I believe this model will be easier to navigate than traditional  
forums and a good complement to the regular editor driven content on  
the website.

Regards Sebastian

More information about the Grok-dev mailing list