Re: [Usability] Reasoning behind default panel setup?



On Tue, 10 Jan 2006, David Tenser wrote:

> Date: Tue, 10 Jan 2006 21:14:40 +0100
> From: David Tenser <djst mozilla gmail com>
> To: usability gnome org
> Subject: Re: [Usability] Reasoning behind default panel setup?
>
> Thanks to Alan for the introduction, and to Evandro for the history and
> background of the default panel layout. I think I'm ready to continue
> the discussion (or, rather, actually start it). :)
>
> The reason why I'm posting about all this here is because I was
> recommended to do so by gnome-panel developer Vincent Untz. I see three
> general problems with the current default panel layout:
>
> 1. Icons are very small on a 24px panel.
>
> Many icons, especially application icons, generally look better when
> displayed in a larger size. The current layout, using two 24px panels,
> makes everything on the panels very small. This also has the drawback of
> making icons harder to target.
>
> 2. Valuable screen space is wasted.
>
> More specifically, it's the vertical screen space that's wasted.
> Widescreen monitors with a resolution of 1280x800 are becoming very
> common these days, especially on notebooks (I know this for a fact since
> I sell these things on a daily basis). The default panels make
> widescreens, a.k.a. "short screens" even shorter, which isn't a good
> thing. Loosing some of the screen width wouldn't be as much of a
> problem, for example by having one vertcal and one horizontal panel.
>
> 3. The separation of the panels makes little sense
>
> At first glance, you could argue that the top panel is for launching
> applications and providing system status, and the bottom one is for
> managing running applications and windows. After a while you realize
> that's not the case. The trash can has little to do with window
> management, and the notification area would actually fit better on the
> bottom panel than on the top, since it's a group of running
> applications. On the other hand, how does one draw the line between a
> running application and system status? The trash can could easily be
> grouped along with the volume icon, since it's in fact a system status
> (it shows whether or not there are files in the trash). It's not at all
> straightforward to motivate why some things are at the bottom and other
> things at the top.
>
>
> Alan Horkan and Evandro mentioned Fitt's law as one of the reasons for
> using two panels. While I agree that the corners are important to
> utilize, Gnome actually only makes use of two of them. The other two are
> wasted by the time/date applet and the trash can. Another argument for
> using two panels could be that the Mac uses it. However, they get away
> with it because they're actually using the top panel for something else:
> the application menu. This reduces the amount of wasted screen real
> estate of that panel to zero.
>
>
> My proposal, and the original reason why I created this thread, is to
> use one single panel instead of two separate. This panel would be of a
> slightly larger size. I would suggest 32px, which I've found is enough
> to make the icons easy to recognize (much easier than 24px) and still
> 16px smaller in height than the current 2*24px panels. The benefits for
> this would be:
>
> * Easier to spot, recognize, and click on icons. Also, better looking icons.
>
> * More vertical space available for applications.
>
> * Familiar environment for ex-Windows users (let's not forget them --
> there are a lot of them), and even KDE users.
>
> * Less clutter and confusion, by removing some of the default applets.
>
> I should probably not get too detailed on how this panel would be
> arranged, because that could potentially just lead to a discussion about
> the specifics. However, two things should probably be mentioned:
>
> * It would not include the workspace switcher. While multiple desktops
> is a very useful feature, it's not something "normal" users ever use. I

I agree, strongly, but I decided I did not want to argue it.

Removing it from the default installation would be very difficult and
require a lot of "discussion".  Short of running a professional usability
test with a reasonably sized test group and having hard evidence it will
be very difficult to convince people to remove what many see a killer
feature and key advantage we have over windows.

I turn off Workspaces on principl.  I get very annoyed at developer who
cop-out claim the availabily of workspace as a valid excuse for their
oversized overcomplicated and cluttered user interfaces which need to be
on a workspace all their own just to keep track of what is going on.

> bet this is one of those occasions where someone will ask me for stats
> proving my point. I don't have any. :)

Heh heh ;)

> would have no problem adding it to the panel(s). It's all about
> achieving a "sane default" here.

I encourage you to try but I dont envy you.  I think it will be a very
difficult case to prove.  Maybe you could setup a basic usability test
with and without panels and force users (including advanced users) to
manage a large collection of open applications with many windows, and
produce 'evidence' to help back up your point.  Even a test with 3-4
people and few well chosen questions could really help prove your point.

> I'd be happy to do a simple mockup of how the proposal would look like
> if anyone is interested. Thanks for reading this far and hopefully I
> have been clear enough about the suggestions.

Clear as crystal.

You never know, even though I'm not a fan of workspaces maybe this is one
of those difficult features we should try hard to make users understand
ratehr than trying to remove it from the default setup.  (I was quite
surprised by the number of people who objected to removing the
terminal shortcut from the default setup.)


Sincerely

Alan Horkan

Inkscape http://inkscape.org
Abiword http://www.abisource.com
Dia http://gnome.org/projects/dia/
Open Clip Art http://OpenClipArt.org

Alan's Diary http://advogato.org/person/AlanHorkan/






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