My WineHQ menu structure proposal

Dimitrie O. Paun dpaun at rogers.com
Sun Nov 3 10:36:36 CST 2002


On November 3, 2002 05:28 am, Francois Gouget wrote:
>  * having a fully expanded menu means we must have fewer items otherwise
> it risks being overwhelming. Things are not as bad as they seem because
> in my proposal I tried to include every item currently in the web site
> and I gave it a place in the hierarchy. But some of these items should
> not have a menu entry for themselves but just be a section on a page.

This is the crux of the matter. If we go for fully expanded menus, they
all become "top-level"/one click, and the way you organize them is not
that important anymore. So, I like your proposal, I think its the way to 
go.

That being said I have a few items where I want to comment on
(in order of importance):

  * I am with Jer, Andy, and Igor that News has to go on the first
    page. There are many reasons why this is so, but most important,
    it's current practice, and as I said, the burdon of proof it's
    on you to do away with it :). But let me list a few reasons here:
	-- a person reads the "About" section *on time*. Once that's
	   done s/he is interested in News.
	-- even before reading the "About" most people want to get an
	   idea if the project is still alive, so they don't waste
	   time going through all the info. There's no better way
	   then with a News section that's visible first hand
	-- If you visit the site more than once (which everybody that
	   we aim the site for will do), it becomes sooo tiring to
	   see the same old information over, and over, and over, again.
	   Gimp was doing that, and I *hate* it. I was so glad to see
	   them add the news section on the Home.
  * I also hate the term "Application Database". It sounds too techy,
    and it's one of the reasons I never used it. So I suggest
	"Application Status"
  * The "Supported Applications" idea is a good one, and I've been
    advocating it for a few days now. This should be a hand-maintained
    list of apps what we have 'officially' tested, and know for a fact
    that work decently in Wine. See the current efforts to come up with
    the Gold list of apps supported under Wine.
  * Minor nit, but I still don't like CVS under Downloads. First off,
    nobody thinks about using CVS as a Download option. There is a big
    semantical impedance mismatch here. CVS is viewed as a development
    tool. Also people using CVS don't go to Download, and viceversa.
    I think it's a mistake to group items based on their form/syntax,
    rather than meaning/semantics. In this case, the grouping is based
    on the fact that there are bits going across the wire, and I don't
    feel it's a meaningful distinction for anyone.
  * I think the header boxes for the menu (what used to be top-level 
    before, like Development, About, etc.) should not be clickable. 
    It's a minor nit, but if we go to fully expanded items, they don't
    'feel' like a menu, but a heading. This goes to the About/Intro
    discussion.
  * Something to keep in mind: the App DB menus don't render properly
    in Konqy. If we're gonna standardize on that format, we should make
    sure they render correctly in the OSS-world browsers.

I suggest we work off of your latest proposal, and suggest 'patches'
to it, if anyone feels there should be changes. But this does seem
to bring us closer to a universally accepted solution. Yay!

-- 
Dimi.




More information about the wine-devel mailing list