incubator-jena-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paolo Castagna <>
Subject Re: Jena documentation - new structure working notes
Date Thu, 17 Feb 2011 16:43:52 GMT

Ian Dickinson wrote:
> Thinking about the structure of the new site, I spent some time 
> surveying what we have. The attached pdf & freemind documents show the 
> current structure, including tdb, sdb and fuseki.  The second attachment 
> shows some suggested goals for the new IA, thinking in terms of the user 
> goals we would like to satisfy.
> The final attachment sketches a possible solution. 

I propose to go from this:

  +-- About
  +-- Learn
  +-- Guides
  +-- In-Depth
  +-- Tools
  +-- News
  +-- Javadoc
  +-- Extras
  +-- Developers

To this:

  +-- About (
  +-- Download ([...]/download/)
  +-- Getting Started ([...]/getting-started/)
  +-- Documentation ([...]/documentation/)
  +-- Getting Involved|Community ([...]/community/)

... and I am not even sure we need "Download".

However, if we want to increase number of downloads, I propose to keep it
there, in the global navigation after "About". Otherwise, it will be the
first paragraph in "Getting Started". However, this would not serve well
expert users/developers who just want to get the latest Jena release.

Let's check it with the goals:

  - explain what Jena is -> About
  - how to learn Jena -> Getting Started + Documentation
  - How do I? -> Documentation
  - Delve into technology -> Documentation
  - Get Jena -> Download
  - Drive Jena using command line utilities -> Documentation
  - Going beyond Jena -> Getting Involved | Community
  - See what has been happening recently -> Homepage | Community
  - Process goal -> less clear choices

Once we agree on the first level structure we can start discussing and
producing content for it: 6 pages to start with (homepage + 5 sections).

> The first level of 
> the hierarchy roughly corresponds to groups of suggested user goals. 
> These could be presented as a horizontal tab array.


Either horizontal or vertical, but a global navigation always present
and consistent whenever you are in the website.

> The second level of 
> hierarchy would in most cases be actual topic documents (such as the 
> eyeball howto in the tools section). However, three of the goals are 
> sufficiently large that having a second level of hierarchy would be 
> helpful to our users, I think. I propose that, where it's necessary, the 
> second level of hierarchy would ideally be consistent, to aide 
> findability. A working suggestion is:
> RDF (i.e. the core API)
> querying (ARQ & SPARQL)
> persistence (TDB, SDB, FileModel, etc)
> ontology API
> inference
> serving data (Joseki, Fuseki)
> My proposal is that we use a static navigation structure, using nested 
> <ul> elements to model the hierarchy, but use progressive enhancement 
> javascript techniques to pretty this up as a more dynamic 
> reveal-on-demand menu structure.  


Initially, a static navigation structure is sufficient for the global

 > That way, we get benefits of
> accessibility, and visibility to search engines, keep the ease-of-update 
> of the Apache CMS (thus avoiding the Forrest approach of update the site 
> config & rebuild everything), but manage the visual and complexity we 
> present to most users on capable browsers. This would all need some 
> prototyping and experimentation, of course.
> Comments welcome.
> Ian

View raw message