Re: Panel configuration

[Havoc Pennington <hp redhat com>]

Hi,

Mark, in this barrage of panel features/redesign I feel like we're
just flailing around without a task analysis of the panel and the
"personas" intended to be using it. At the very least, how do people
use it now. If not who/how we want to see in future.

I wish we had something as in "designing from both sides of the
screen" in short - Nils thinks I'm getting kickbacks on this book, but
I just think it gives a very concrete process for UI design that
hackers could get a grip on.

Brainstorming on desktop-devel-list by random programmers - not ideal.

Concretely, for example:

>   [ ] Autohide
>   [ ] Show Hide Buttons

I'm pretty sure in the "designing from both sides of the screen"
analysis, these would be in the either "occasional by few" or
"occasional by many" category, either way the conclusion is that the
feature doesn't need to be quickly accessible, i.e. no point putting
it in the context menu. Also, remember the suggested limits on context
menu size in the HIG (or that should be in the HIG anyhow)

Here is a quick summary of the Frequency x Commonality grid 
for classifying tasks:

                 By Many                   By Few

Frequent     Visible, few clicks       Suggested, few clicks

Occasional   Suggested, more clicks    Hidden, more clicks


By "clicks" the book means any UI step, such as pressing a key,
clicking, etc. "Hard" steps such as using a combo box count as tons of
clicks.

If a task is used often by everyone (frequent by many), it should be
accessible ideally with one click. e.g. a toolbar button.  Example,
clicking "connect to internet" in a modem app is something everyone
using the app would do daily.

If a task is frequent by some people but unused by most, it should be
suggested in some way in the GUI, but can be harder to find than a
frequent by many task. But should still be doable in few steps.
Example, a "locations profile" feature in the modem app; most people
only have a single location, but some may change locations daily.

Occasional by many is something like initially configuring your
modem (or your panel). You do it once or twice, or every month, but 
it can go ahead and require a few extra steps, and  it doesn't need to
be in the most visible/easy-to-find part of the GUI.

Occasional by few features are often power-user type features.  An
example might be showing the log of the PPP login process for
debugging, or something. These can be the least visible or even
hidden, and can require extra clicks to perform the task.

So frequency implies fewer steps to perform the task, and commonality
implies the task is more visible/prominent in the GUI.

Frequent by many tasks are also the highest priority to implement.

In any case, again, it sure would be nice if someone (maybe UI team)
could catalog the tasks the panel currently supports, and classify
them into this grid, and otherwise work on a more rigorous framework
for figuring out what the panel should be like. And if someone does do
this I hope we'll pay attention to it.

Havoc