Re: Panel configuration

[Mark McLoughlin <mark skynet ie>]

Hey,

On Tue, 2003-02-11 at 15:26, Havoc Pennington wrote:
> 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.

	Oh, I totally agree. I should have made it more explicit - with these
mails I was mainly targetting the usability team, but wanted to include
a wider audience too. So I guess they really should have gone to the
usability list.

	What I'm really hoping for here is that someone with a clue and who has
some decent seperation from the code will step up and take on this
analysis. I've been hoping for that for a while now :-)

	I don't see what I've done so far as real work on the usability of the
panel. Basically, its a code re-write (to make it easier to change the
behaviour in future) taking on board some of the many ideas in bugzilla
(giving ideas from usability-maint the most weight) and adding in some
ideas of my own ideas where I thought they make sense. Nothings concrete
and its totally hit and miss.

	I just don't feel I'm in a position to do a decent design analysis of
the interface. It would be too biased by how things work currently etc.
and I've a very limited knowledge base when it comes to usability
issues.

> 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)

	... and this is an excellant example of where I obviously didn't put
too much thought into it. And that's why it hasn't been implemented yet.


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

<snip/>

	Sounds like another worthwhile read ... unless you are actually getting
kickbacks from these people ? hmm

> 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.

	It certainly wouldn't be ignored by me. I for one would certainly
prefer that than "hmm, maybe it would be better if it worked this way
... or maybe this way" from the usability team and then me being the one
to decide which way actually makes sense. Me ? - wtf am I to decide
which is best ? But I said all this to Seth/Calum/Nils at the last
GUADEC ... but then does anyone really have the time to do it this way ?

	Anyway, I think this is part of a broader discussion we need to have
about how we can really co-ordinate between hackers and the usability
team more effectively.

Good Luck,
Mark.