Re: [Usability] Pathbuttons-Field

[Thorsten Wilms <t_w_ freenet de>]

On Sun, Feb 12, 2006 at 03:54:13PM +0000, Alan Horkan wrote:
> 
> I'll try not to comment on this discussion other than to say I think many
> users will need to learn about Paths and the "trail of breadcrumbs" path
> buttons do them no favours in the long run.

The path buttons just come without /. But the hierarchy is all the  
same. So they don't hide paths. Maybe there's an aestheticaly satisfying 
way to introduce / in my idea.
 

> Also in recent use I have noticed that with long folder names the file
> chooser dialog is very cramped and I only get to see a button for the
> current folder and arrrows nullifying any of the benefits of the system.
> 
> [<] [ My big long folder name ] [>]

Not having an imediatley accesible way to go one up is bad of course.
Realy long folder names and/or long pathes can be troublesome in browser 
style URIs, with path buttons, on the console, in lists and treeviews, 
panes like Apple uses them ... everything.
My proposal would allow you to hit backspace to go up at least.


> I'm glad we experimented but I think we will eventually need to reconsider
> and drop the whole path button idea.

Who has come to what conclusions and how again?
On anecdotal evidence, I can say path buttons work very well for me.
They're the only thing about the new file dialogs I like (oh, and type 
ahead on the opne dialog, but not the Save one, due to focus problems).

 
> I'll finish with a link to recent discussion where I asked Havoc about
> whether or not to expose paths:
> http://mail.gnome.org/archives/usability/2006-February/msg00064.html
> 
> "What I'm saying is that right and wrong here is 100% relative to the
> decision on specifically what GNOME is doing for specifically which
> users."
> 
> "If you debate some microdetail like whether to expose paths before
> making a decision on who and what, you're just going to waste your time
> and go in pointless circles."
> 
> I don't disagree that we need to define our audience to make progress but
> Havoc and others have been mentioning personas for quite a while and no
> one has yet had the time or expertise to adequately decide who our
> target audience or audiences actually are.

Some decisions on that would be nice indeed. But I don't think some 
personas suddenly make it clear if exposing paths is good or not.

Hmm, actualy you can't realy hide them, only choose 1 or more styles 
of representation of them. So obviously:
- the number of representations should be kept low, because  
each one requires coding, maintenance, documentation, learning ...
(that shouldn't stop experimentation, though)
- all offered representations should share as much on look and feel 
as possible given their specific characteristics.
- each officialy supported representation should have clear benefits 
over others in some situations, to make them worthwhile.
- each rep. should be refined to make the most out of it.


Cheers,
Thorsten Wilms