>>The new file dialog is a lot better to use. It needs only a little bit=20
>>of pratice to get used, but is a lot simpler, in particular using it=20
>>with the mouse.
> Research has shown that most users keep their files in rather broad,
> flat hierarchies.
Semi-flat. As in ~/images, ~/music, ~/documents, etc.
> Scroll-and-click by itself is neither a simple nor an efficient approac=
> for them.
Yes, but the solution is select-as-you-type (as in nautilus), not the=20
> What users really need is a simple (live) substring or prefix search to
> winnow the list and reduce hunt-and-scroll.
I think that using the nautilus behaviour of select-as-you-type would be=20
sufficient and consistent with the other user experiences.
> One possibility would be to use the entry field for that role --
> explicit (fully typed) filenames or paths would become simple degenerat=
> cases. (on the other hand, entries disappearing as they typed might be
I don't think that re-enabling the text entry is a good idea...
>>The decision to hide the text entry (it is still here, just press Ctrl-=
>>as in a web browser) was taken to hide the complexities and the=20
>>differences of the underlying OS from the user.
> From a UI perspective, that is a failure. How is the user supposed to
> know Ctrl+L does this?
The UI will fail not when you can use a program for the first time, but=20
when you cannot use it after someone has told you how to use it.
Ctrl-L is already used in nautilus (useful with the new spatial mode)=20
and in the web browser (epiphany but also tested with mozilla).
I've been using thi file dialog for a while and, apart some minor=20
annoyances as the lack of select-as-you-type, I find it quite comfortable=
I now it can appear strange at first sight, but it is not so terrible to=20
> Most of the Inkscape developers are pretty hardcore. If _we_ were
> totally unaware of the text entry hidden by Ctrl+L (how were we to
> know? where is it documented?), there's a serious problem. And we're
> the target audience for that shortcut.
Well, I've read about during the development process. But I've already=20
used it in mozilla and epiphany before. And also in nautilus, when I've=20
upgraded to GNOME 2.6
> There needs to be a visual "affordance". For example, Mac OS X's open
> dialog also hides part of its UI from the naive user, but it provides a=
> expander widget -- a standard visual metaphor both indicating that ther=
> is more hidden UI, and providing a _visible_ means of revealing it.
This could be a good idea, but with the expander my use didn't change: I=20
press Ctrl-L to get the text entry, which is now in the expanded part of=20
the dialog, instead of a popup window.
> IMO, at least adding an expander widget to the dialog would be a
> reasonable compromise. Pets and small children will not be scarred for
> life if they click it out of curiousity. The text entry widget is not
> Janet Jackson's boob.
Complimenti per l'ottima scelta.