Re: [Usability] desktop lacks "Display properties" or " Screensaver - Power" options on right-click context menu

[Jacob Beauregard <jake13jake comcast net>]

On Monday 23 April 2007 10:15:57 am Curtis Hovey wrote:
> On Mon, 2007-04-23 at 09:25 -0400, Jacob Beauregard wrote:
> > On Monday 23 April 2007 08:48:56 am you wrote:
> > > On Mon, 2007-04-23 at 08:23 -0400, Jacob Beauregard wrote:
> > > > > > The question is, what is the familiarity of most GNOME users? Is
> > > > > > it in Windows or in GNOME itself? Do GNOME users even utilize the
> > > > > > right-click context menu, and would adding such an element to
> > > > > > that context menu be a constraint to the GNOME population?
> > > > >
> > > > > Adding items which the majority of people would never use would be
> > > > > a bad move, imho.
> > > >
> > > > Users would stop complaining if they could change their context menus
> > > > from the default configuration.
> > > >
> > > > Also, you're assuming that the majority of people would never use
> > > > this item. PROVE IT. You lack reason not to investigate a user's
> > > > input if you're going to declare a decision as final.
> > >
> > > I have to prove that the majority of users don't have the desire to
> > > change the resolution of their screen sufficiently frequently to
> > > justify a desktop context menu item explicitly to change resolution? 
> > > I've yet to hear a decent reason *for* it.  Why would someone want to
> > > change resolution so frequently that they'd need rapid access for it? 
> > > And why would the xrandr-applet not suffice in this case?
> > >
> > > > > What are we talking about now?  The ability to add arbitrary
> > > > > entries to the desktop context menu?  That is possible by adding an
> > > > > entry to the Nautilus scripts folder, but note how they are in a
> > > > > submenu so that they don't take over the context menu.
> > > >
> > > > Submenus bury functionality, making it harder for users to access it.
> > > > In addition, submenus that open to the side as opposed to unfolding
> > > > add extra work for the user.
> > >
> > > Yes, that is true.
> > >
> > > Burying functionality isn't an issue for the Scripts menu, as the user
> > > has to put stuff in there.  The choices were a) submenu or b)
> > > potentially huge desktop context menu.  I think the right choice was
> > > made.
> >
> > In the context you speak of, it's great the way it is. It's great for the
> > default, too, but giving people the ability to directly modify the
> > context menu makes no contest for all use cases.
>
> In this scenario I disagree. Accessing the screen* option from the
> desktop leads to additional choices that the user must consider (waste
> time). We have a control center so that the user knows there is one
> place to configure the desktop work environment. Once configure, the
> computer should 'Just Work'. If users need to visit the control center
> often, that is another problem that must be understood and addressed.

I never said this should be done. These are the constraints I inquired for 
someone to state.

>
> Adding additional items to the context menus will also waste time the
> users time if these items are rarely needed & available elsewhere, or
> the item is not exactly related to the context.
>
> Ross is correct in that we offer the panel launchers as a convenience
> (and time saver) to allow users to access _distant_ features quickly.
> Allowing user to adding items to a Context menu is already a feature,
> making it as easy as adding a panel applet is work that can be done. I'm
> not convinced that work should be done, but I'm willing to see a working
> concept.

It doesn't necessarily have to be done, I just see how people can be 
frustrated by it at times.

Has anyone thought of using click-activated folding/unfolding submenus 
(lengthening the context menu when a submenu is clicked) rather than a 
hovering side-menu? This would help the user save time by not having to 
reorient direction of hand motions, and therefore the features in submenus 
would feel less "buried."

>
> As for this particular example that you bring up, I added the Change
> Screensaver feature to my desktop menu in a minute and a half--then
> removed it. I don't see any nautilus scripts for changing screensavers
> or screen resolution in any of sites that host nautilus scripts. Yet it
> is simple for moderately experience GNOME users to create the two line
> script. I don't this there is a _want_ for these features in the context
> menu. So I don't think this is a Windows or a Mac issue, and I see no
> evidence that this is a community issue.

It isn't a particular example that I brought up.

>
> > > > > > > > The modesetting display capplet in notification tray, the
> > > > > > > > whole of display properties so one can change things on the
> > > > > > > > fly, seeing a movie, seeing a .pdf etc. hence atleast to me
> > > > > > > > it makes sense.
> > > > > > >
> > > > > > > Why would you change resolution manually when you want a movie,
> > > > > > > or read a PDF?  I'm still struggling to see a use-case for
> > > > > > > frequent resolution changes.  I change resolution relatively
> > > > > > > frequently (when I connect my external monitor), but I have a
> > > > > > > tool which changes resolution, font size, wallpaper and so on
> > > > > > > in a single keypress.
> > > > > >
> > > > > > Yea, I've got that external monitor case, too. There are also a
> > > > > > few games that like to add constraints to the resolution you can
> > > > > > use.
> > > > >
> > > > > Every game I've used changes resolution itself.  Interesting that
> > > > > there are some which don't.  That's a bug in the game of course,
> > > > > should GNOME add an extra menu item to the desktop context menu
> > > > > because there are some buggy games?
> > > >
> > > > Once again you have no idea what you're talking about... No, there is
> > > > no bug with the game, and please don't make assumptions on my use
> > > > cases.
> > >
> > > So why does a game enforce particular resolutions on the user, but not
> > > change the resolution itself?  How does this considered a feature and
> > > not a bug?
> >
> > The game in question isn't enforcing the resolution, it's simply
> > suggesting you use a lower resolution so not to have an unfair advantage,
> > and otherwise be limited to watching (which a higher resolution would be
> > better for as well). This game does provide a means to set resolution.
> > However, it can also be set to adapt to the current resolution. This
> > means it can be a choice of the player on whether they would want to
> > change their resolution via in the game or in the computer's resolution
> > settings.
> >
> > > > > > > > I find it extremely challenging to traverse through 3 menus
> > > > > > > > in order to get a simple thing done, hence if the display
> > > > > > > > capplet is there which has everything from brightness,
> > > > > > > > contrast, resolution-modesetting, themes etc. it would be
> > > > > > > > pretty cool
> > > > > > >
> > > > > > > Brightness and contrast are monitor settings, GNOME can't
> > > > > > > control those.
> > > > > >
> > > > > > Would a device driver possibly have control over these?
> > > > >
> > > > > No idea, I don't have the EDID specification to hand.  If it were
> > > > > possible and if X exposed it, then it could be added to the Display
> > > > > capplet.
> > > >
> > > > Who's the GNOME dev who's going to ask an X dev?
> > >
> > > Whoever wants to code the functionality.  If you want to code this, you
> > > can read the EDID (and so on) specifications, come up with a nice way
> > > of integrating this into X (using the controllers available on the
> > > XRANDR 1.2 CRTCs is probably a good idea), propose that to the Xorg
> > > list and if it's agreed up, add it to XRANDR>  Then you can add two
> > > sliders to the currently-non-existant Display capplet.
> > >
> > > > > > > That leaves resolution and theme.  Thomas Wood is working on an
> > > > > > > Appearance capplet which covers themes, colours, and fonts. 
> > > > > > > I've been planning on adding ICC profile selection to the
> > > > > > > Resolution capplet which would make it a Display capplet.
> > > > > >
> > > > > > If I wanted to switch my res from 1680x1050 to 1280x1024, would
> > > > > > GNOME be responsible for handling when my screen gets stretched
> > > > > > rather than certain parts getting ignored (I really doubt it, but
> > > > > > such a thing could probably be hacked anyway).
> > > > >
> > > > > I've never had the screen be ignored when expanded: nautilus
> > > > > notices the resize and draws the wallpaper there, the panel expands
> > > > > to fill the extra space, and metacity will place windows.   If you
> > > > > can replicate GNOME refusing to use space, then you've found a bug
> > > > > in X.
> > > >
> > > > What are you talking about? I'm talking about refusing to use space
> > > > for the sake of not distorting the monitor based on default
> > > > resolution, and I meant hacking through whatever bug or work-around I
> > > > could throw in my X source code.
> > >
> > > Sorry, I misunderstood you.
> > >
> > > My laptop panel is 4:3, my external display is 16:9.  In the new XRANDR
> > > implementation (available in xorg-server 1.3) I don't end up with a
> > > distorted screen but black bars on the sides, so I presume this is
> > > either a) fixed in xorg-server 1.3 or b) a driver bug (I'm using
> > > -intel).  Anyway, yes, this is nothing to do with GNOME.
> > >
> > > Ross
> >
> > _______________________________________________
> > Usability mailing list
> > Usability gnome org
> > http://mail.gnome.org/mailman/listinfo/usability