cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Borut BolĨina" <borut.bolc...@gmail.com>
Subject Re: Site structure redesign
Date Sat, 09 Sep 2006 13:44:46 GMT
Hot topic, we should have some kind of conference...

2006/9/9, Aristedes Maniatis <ari@ish.com.au>:
>
>
> I think that with floating css designs working so well on every
> browser, there is no reason to not have all the navigation available
> everywhere. So, top level navigation appears as a list (of some
> sort), and the second level can work as a drop down (down, sidewise,
> whatever) when hovering over the top level. This degrades well on
> older browsers. It also makes the navigation consistent (doesn't
> change on different pages), clearer (the user can understand what sub-
> menu options are available in each section without hunting through
> each section one at a time) and faster (less clicks/page loads).
>
> See http://www.ish.com.au/test for a two level menu system which
> could have easily been made three levels if the site needed it.



I am personally against such a solution, but when we will know exactly what
content the site will host, we will decide based on that knowledge.


> 2. Home Page
> >
> > * (taking this item from my other message) Need a small "latest
> > news" section, listing recent news titles (we can automate an
> > update process, using RSS, to avoid stale news).
> > * +1 for the modeler section with the screenshot.
> > * -1 on the supported DB section - maybe replace it with a quick
> > summary of features, with a link to a "feature overview" page.
>
> I agree. The modeler is a great feature, but the supported DB makes
> Cayenne seem subordinate to the DB. I'd think that many people would
> choose their ORM before they choose their DB. (well, we did).



I worked with WebObjects and EOF in the past and consider myself lucky to
know the technologies, but in real world databases rule not the persistent
frameworks and that is a fact we must face. I don't hate the SQL, but will
seize every opportunity not to use it, if I can use some persistence
framework. I think the majority of Java enterprise developers are somehow
preconditioned with legacy systems which include all sorts of databases.
Having a free mind in choosing every bit of technology is a rare luxury. I
would add an explanation text next to a list of supported databases. This
list can be a powerful factor for db oriented group of developers which are
presented with persistence framework. The semantic gap when programming in
object oriented language and coding raw SQL to manipulate data in relational
databases is leading to impedance mismatch, but the database oriented people
coding in Java takes this for a fact of life and live on happily ever after.
We must do something to make a bridge to them.


> 3. Documentation Page
> >
> > * Big +1 for current organization of the top-level documentation
> > topics (including splitting the user guide into installation/quick
> > start/user guide).
>
> I agree. Except that "bugs and features" should be "bug tracker" or
> similar since it sounds like it will show you a feature list right
> now. And "how can I help" should be under collaboration. And "wiki"
> should be "Index" or similar since the tool which was used to create
> the docs is not really as relevant as being able to find them.



Since a picture (web page) is worth more than a thousand words, I suggest
you make a proposition of content and  navigation.


> * Need a clear split between different versions of Cayenne
> > documentation (via side menu or tabs?) Side menu is probably more
> > scaleable.
>
>
> Yes, especially for documentation which will continue to grow over time.



...and  how the updates will be performed. See my previous post.

Borut


Ari Maniatis
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message