Re: [Usability] Pathbuttons-Field

[Tomasz Janowitz <logan77 o2 pl>]

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.
> 
> 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 ] [>]
> 
> I'd be far better off with an small UP button (possibly one including a
> drop down to allow access to futher up the folder tree).

I get your point. But instead of ditching the whole idea, maybe some we can
work out some solution to this ? :

[<] [ Yr big long folder name ] [>]          #for comparison only
[<] [ My v..er name ] [>]                    #my proposition

People seldom name their folders like that, and even when they do, the part
different from other long name folders is likely to be on the beginning or
in the end of a name. So even if it's not the prettiest, it does tackle
this inconvenience that you complain about. Mc uses "~" instead of my "..".
And finally - we are talking about exceptions here rather then casual
situation. I remember that enforcing good habits and anticipation of casual
user behavior of setting shallow folder hierarchy were arguments for
spatial view. We could always assume that people don't give long names to
their folders? :)


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

I beg you reconsider. "The whole path button idea" is one of my favourite
advancements in nautilus as of late. It overlaps pretty much the history
functionality, which I loose, when buttons are all gone. I was very
reluctant to this idea at the beginning, but now it's a 'must be' for me.


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

He just says that you must specify target audience and then ask questions
what to change and how. Nothing even indirectly implying that we should
ditch buttons.


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

I thought it's rather obvious what is gnome's target audience, since whole
direction in which it was going lately points to :
a) ordinary people with no/poor knowledge of what computer is, but still
want/have to perform every day tasks on it with as little hassle as possible
b) corporate/enterprise users (whatever that means) - to let them be as
productive as possible, without forcing on them endless piles of options,
simply picking for them "reasonable defaults" that would let them just do
their job

Considering that RedHat and Novell are backing gnome for "b" audience, it
has done probably good job there.

But gnome is obviously appealing to advanced (computer-savvy) users too, so
letting them do it their way is probably also a good way to go (like
inserting path via keyboard that Linus complained lately, which of course
was there, but not that apparent). I really think that buttons can be good
for both groups - advanced and technical illiterates.

greetings
tj