Hi Ian,
first of all, thank you.
I like the fact we are thinking how to better serve the needs of
new users, expert users as well as potential contributors/new
committers. This is a common approach with many open source
projects [1,2,3,4,...] and I find if very useful for the open
source projects I use.
Things I appreciate about other open source project websites,
in particular for those open source projects I decide to depend
on, are: roadmap pages (i.e. what is going on and, approximately,
when it will be done), wish lists (i.e. what it would be nice to
have, if only we had infinite time) and/or feature requests (a
page could point to a subset of JIRA issues) and related
specifications/standards/recommendations (this is useful to new
users as well). (See JENA-16 [5]).
Another very useful thing for us and/or new potential contributors
are pages like: "how to submit a patch" or "how to build/release" [6].
For example, we recently have received patches which have not
been 'properly' generated and it was a pain to apply.
It is not clear to me the role that Jena's wiki [7] will have (if
it will have one).
Sharing and pointing to specific examples of other websites we
like or we think would server our community well is very useful,
at least to me. So that we can get ideas and/or compare what we
have with what we would like to have.
Finally, I am for an incremental approach where we start with
the homepage and the three/four main sections and then we gradually
migrate the existing pages we want to migrate (changing them if
necessary).
What are the three/four main sections from the homepage?
My 2 cents,
Paolo
[1] http://java.net/projects/hudson/
[2] http://www.restlet.org/
[3] http://cocoon.apache.org/
[4] http://rubyonrails.org/
[5] https://issues.apache.org/jira/browse/JENA-16
[6] https://cwiki.apache.org/WHIRR/how-to-release.html
[7] https://cwiki.apache.org/confluence/display/JENA/
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. The first level of
the hierarchy roughly corresponds to groups of suggested user goals.
These could be presented as a horizontal tab array. 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. 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
