My poor 2 usability cents on kickoff

[Will Stephenson]

On Sunday 13 January 2008 19:44:13 Matt Williams wrote:
> 1) While I agree with the reasons for this, I feel this would currently 
cause 
> a bigger problem than it solves. Since tabs are activated on mouse over, 
once 
> the user clicks on the kickoff icon and drags the mouse to the main kickoff 
> area, they would pass over some of the bottom tabs on the way, changing the 
> content. We don't have this problem at the moment since the pre-selected tab
> "Favourites" is the one directly above the kickoff icon. If the code was 
> changes such that the tabs were only selected on a click, I think this 
change 
> would be a good one.
> However, this does mean that the menu navigator (the grey bar with the 
arrow) 
> would no longer be at the screen edge.

Disclaimer: I helped design the original Kickoff at SUSE.  Therefore my 
judgement is coloured and any modifications to the One True Design are 
automatically worthless ;).

<serious>I'm a developer not a usability expert, but I did work with 4 of them 
on Kickoff so I'll share the experiences we made together then.

We tried the vertical tab layout, and also an L/arc shaped layout to minimise 
mouse travel distance and change of direction.  

Gabriele cites travel distance as a problem in his point 1).  I challenge that 
problem definition and disagree that the travel path is shorter with vertical 
tabs.  The user can mouse over the tab and then vertically to the desired 
item.  

The impression that the user must mouse diagonally from the tab onto the item 
text or icon stems from the highlighting that does not fill the full width of 
the item.  The area that is highlighted is a part of the hoverable/selectable 
area and this is confusing - we have patched this out in SUSE KDE4 packages 
and I would it if we could get it upstream.

A benefit of the horizontal tabs is that the difference between horizontal 
tabs and vertical menus is a cue to the user that, once a tab has been 
selected, they are acting within a qualitatively distinct context.

A drawback of vertical tabs is that it introduces a conflict between Fitts 
(distance to most frequently used items, ie Favourites) and expected ordering 
of items by importance.  The user will scan the list of tabs top to bottom, 
and the incongruous position of Leave at the top of the list will annoy.

> 2) I like the idea of this but it does get rid of the user's ability to 
> quickly throw the mouse to the screen edge to navigate to the parent level 
> (of course, if solution 1 were to be done, this would no longer be possible 
> anyway). Perhaps, a breadcrumb at the top of the scroller (much like the one 
> in dolphin) would provide the needed contextual information?

I'd also like to ask for more proof that there is a problem perceiving where 
current menu location.  In your .odp point 2) "Where am I?" you don't mention 
the menu title showing the current position in the menu.  This provides that 
information.  Before reworking the whole layout, if there is a problem seeing 
this information we should try to find a way to make it more visible.

We also tried the nested Up bar approach.  It becomes very busy; reading 
horizontal as well as vertical text is hard work; hitting the right "Up" bar 
is difficult, and the results are confusing when you hit the wrong one.  

We also mocked up a compressed columns view where the menu levels above the 
current level are displayed to the left of the current level using icons 
only.  This was even busier.

> 3) I like that you've got the guts to (literally) think outside the box on 
> this one. It's a nice solution to the problem and with some refinements 
could 
> prove useful.

I agree with Matt, it's good to review what we have and look for improvements, 
but you need to define the problems better, and then be careful of 
introducing complexity/decreasing interface element size with proposed 
solutions. 

Will