Re: Tree sidebar (was: Re: Nautilus bugs and design choices (back-button))

[Mathias Hasselmann <mathias hasselmann gmx de>]

On Wed, 10 Jul 2002, Reinout van Schouwen wrote:

> Hi Mathias,
> 
> > > Not if you extend the functionality of the tree side panel to have
> > > incremental search capacity (with or without an accompanying textfield).
> > > Then the advanced user can still go where he wants with a few keystrokes.
> 
> > 	1) You'd have to get all those magic URL schemas supported
> > 	   gnome-vfs (applications: , preferences:, whatever:) into the
> 
> hmm, I didn't take this into account, my idea was limited to incrementally
> searching the visible contents of the tree. Entering all kinds of URLs is
> a bit out of scope for that.

	So advanced users still need a location entry field.

> 
> > 	2) How do I reach sites in the web with such a tree?
> 
> I guess you don't, for all the reasons you listed. There could be an "Open
> URL" dialog though, like many browsers have. (Ctrl+O iirc)

	Know that nearly each browser has such a dialog. Never used them: 
Too far away. Too inconvenient. From my point of view not a viable 
replacement for a location entry field.

> 
> > 	3) Of course you tree will support copy'n'paste -- but who'll come
> > 	   to the mad idea of pasting text into your tree view? It's
> > 	   definitly not a text area.
> 
> No, that would definately not be a good idea. In fact I don't see the
> point of copying & pasting within a tree; at least not when the dragging
> functionality is properly implemented with auto-scrolling when the list is
> too long, etc.

	So advanced users still need a location entry field. 

> > 	4) An entry field in a sidebar will be pretty small and so it
> > 	   will be damn hard to read/to edit.
> 
> Agreed, therefore I don't think an entry field should be visible in the
> sidebar at all times. If one would be used then I would be in favor of one
> that would dynamically appear when the incremental-search-hotkey-combo is
> pressed and disappear when the user has selected an item (and/or after a
> certain amount of time).

	Agreed: My hacker's intentuition agrees: A permantly visible entry
field isn't that useful. But some kind of visual feedback is needed
otherwise this function just will leed to confusion: Take some test
person, measure how much of them find/get along with NEdit's incremental
search function in it's file dialog. Another question: How to ensure that 
this function is found?

> > to -- and well: If the GUIs designed by their UI gurus just are
> > inconvenient, unusable for a good number of (maybe I have to add
> 
> I agree that CDE is clunky and inconvenient, but it wasn't designed by Sun
> alone (GNOME isn't either).

	Yup. CDE isn't from them. Well, but I also used OpenWindows: And
besides some really smart ideas like the smart "File" button in the text
editor's menubar I didn't find much convenience. Someone else brought Java
into play: AFAIR it was designed to fill the leak of desktop applications
for Solaris... Well, but I'd say: Let's stop this discussion if Sun is
competent in GUI design I've started: The list is about GNOME, not about
Sun. ;-)


Ciao,
Mathias
-- 
WWW:           http://taschenorakel.de/mathias/
PGP/GnuPG:     1024-Bit DSA: ID 55E572F3, 1024-Bit RSA: ID EAAF7CF1
"e:-1" is the Slashdot Troll Emoticon. Often seen after the word "Scor"