[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [desktop] why kde and gnome's menu situation sucks



On Thu, Oct 24, 2002 at 12:44:11PM -0400, Jim Penny scribbled:
[snip]
> > > all of a sudden 50 sourceforge projects change their name to editor(1),
> > > editor(2)..... editor(50), Imagine the absolute disaster if this concept
> > > was extended to the command line.
> > That would be obviously ridiculous.
> 
> Exactly.  You get the brass ring.  So why is it not obviously ridiculous
> in menus?
Because nobody proposed to name the entries like Editor(1), Editor(2). There
were at least 2 or 3 reasonable solutions proposed. Obviously a label like
'Web Browser' should be used only when there's only one web browser
installed.

[snip]
> > 1. labels (Web Browser, Movie Player, Terminal Emulator)
> > 2. labels with the project name (Web Browser [Galeon], Movie Player
> >    [mplayer], Terminal Emulator [mlterm])
> > 3. project name
> > 4. long project name
> > 
> > The task of Debian Desktop should be to make the above possible and provide
> > a well-defined transition path from Newbie to Adanced User.
> > 
> > > It will be much harder for newbies to get help if they cant even workout
> > > the real name of the program they dont know how to use.
> > I don't think so. Newbie should not have too much choice _by default_. 
> > 
> > marek
> 
> But, newbies need to be able to communicate on the mailing lists,
> jabber, IRC, or whatever other medium of choice and in bug reports.
> How does [1] help them do so?
They say they have one choice in their menu. We know at once that they're
using the basic desktop, ergo we know what their choice is... Also a big,
fat Report A Bug icon on the desktop might come very helpful - it would ask
them a few questions in the wizard-like way, then post the bug report to the
tech support mailing lists with all the details necessary without the user
having to know how to find the details. For example: they have a problem
with their Menu, so they click on the bug report icon and are presented with
a question "which element of the Debian UI is giving you trouble?" and a
selection "Menu, Editor, Browser" etc. They select that category and move on
- if they chose Menu, they are presented with a fake menu identical to that
in their panel and are asked to select which item is giving them trouble.
When the program knows which menu the user has trouble with, it simply
includes all the details for that menu and sends that to the list. That's of
course an ad-hoc idea, but I guess it might be something worth pursuing.

> [2] is acceptible, athough I would personally rather see it promoted to
> submenu if there are more than 3 to 5 items in the same category.
Yep, I suggested that elsewhere and I think it would be a good idea.

> I am now going off on a tangent.  I fear this project!  Not because it
> will dilute the quality or reputation of Debian; I think neither are
> true. 
> 
> But, if it takes off, the debian desktop team is taking it on themselves
> to pick winners and losers from the free software spectrum.  How will
> these decisions be made?  How long will they persist, once in place?
> How will politicking and lobbying be handled?  Most importantly, how 
> will upstream "also-rans" react?
> 
> Socially, this could be very devisive.
> 
> I am not saying it is a bad idea.  I am saying that it will require
> tact --  something for which the free software community, and the Debian 
> community are not always known.
I think you might be right to some extent, but I do hope that people to make
those decisions on behalf of Debian will apply the only tactics possible -
they will be as little biased as possible. It is possible to make the
choices based on polls, personal experience, technical merits, the number of
bug reports :) - anything. I suppose you're right saying that it will take a
great deal of careful social engineering, but I do believe it's both
worthwhile and necessary.

marek

Attachment: pgphRTgOkyiQp.pgp
Description: PGP signature


Reply to: