Re: Reducing the number of special uris in gnome
- From: Alexander Larsson <alexl redhat com>
- To: Seth Nickell <snickell stanford edu>
- Cc: Dave Bordoley <bordoley msu edu>, <nautilus-list gnome org>, <desktop-devel-list gnome org>
- Subject: Re: Reducing the number of special uris in gnome
- Date: Mon, 1 Jul 2002 04:12:07 -0400 (EDT)
On 29 Jun 2002, Seth Nickell wrote:
> > > > So you want to expose the fact to users that our settings dialogs are in
> > > > fact applications?
> > >
> > > Seth already made this decision when he put preferences in the
> > > applications menu (and therefore in the applications:// directory).
> > >
>
> Preference pages should not be presented as applications. That desktop
> preferences is under a menu entry called "Applications" is regrettable,
> and a point that Nils and I discussed for quite a while with no good
> solutions presenting themselves to our little minds.
>
> > > (applications://Preferences, applications://system)
> >
> > And I must say I disagree with this decision, since they were already put
> > somewhere else before that. That decision was already made before seth
> > made his decision, if that matters.
>
> Eh? Preferences/Settings in GNOME have been under the
> Applications/Programs menu for quite a while now. Ximian customized this
> and adding a top-level Settings menu, which I sort of liked, and I
> originally pushed for the GNOME 2 menus. See below for more discussion
> of this.
Ah. I was thinking here about the start-here hierarchy, and how it has
prefs as a toplevel node, plus also in the applications "directory".
> > I would prefer if e.g. "desktop preferences" were part of the toplevel
> > gnome menu rather than under applications, since I'm not sure at all that
> > people will look under applications when they browse the menu looking for
> > where to change the font. Of course they'll quickly learn that the fact
> > that the submenu is called applications doesn't mean anything, and in fact
> > whatever you want to do it's the menu to look in (unless you want to take
> > a screenshot, which for some unknown reason has been decided is more
> > worthy than e.g. preferences of a top-level menu entry).
>
> FWIW, I didn't think screen shot taking should be in the actions menu.
> It didn't seem like an important enough item to me to promote it to such
> prominence.
Nod.
> We discussed making Preferences a top-level item. While on the one hand
> this is obviously a more coherent arrangement since we aren't
> incorrectly classifying preferences as an Application, it pushes
> Preferences to more prominence than I think is really necessary. I
> originally pushed for this idea and Calum (I think it was Calum?)
> convinced me that Preferences didn't really need to be promoted that
> much.
>
> How often do you access preferences relative to either applications or
> actions? It could well be that I don't have normal use patterns, but in
> the course of daily work I use search and run, or launch an application
> far more frequently than I change a preference. I do fiddle in
> preferences a lot these days, but that's because I'm working on the
> control center. That I guess is the primary argument against making
> Preferences is a top level item.
>
> Honestly, I don't have strong feelings either way though. There are
> things to be gained and lost in both approaches.
My argument is not about how often they are used, but the fact that when
you want to use them you need to be able to find them. And if things that
are different in the users mental models are split apart into separate
menus they are probably easier to find.
Moving them up a level probably also makes the applications submenu easier
to navigate.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander Larsson Red Hat, Inc
alexl redhat com alla lysator liu se
He's a sword-wielding skateboarding paramedic haunted by memories of 'Nam.
She's a bloodthirsty cigar-chomping snake charmer with an incredible destiny.
They fight crime!
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]