[Usability] Path-buttons-field Open dialog mockup

[Thorsten Wilms <t_w_ freenet de>]

Hello!

I refined my path buttons/field combo and created mockups of 
an Open dialog:

http://xs68.xs.to/pics/06071/text-path_05_a.png
http://xs68.xs.to/pics/06071/text-path_05_b.png

Buttons now take full hight and appear blueish-white to 
better integrate with the field.

Please remember from my previous post that backspace, 
../, wildcards and specifying a full path starting with / 
shall all be working.
Additionaly a file extension (specific or with wildcards) 
could be given after putting in a dot. That should also 
affect the filetype selector below the list.

Including / in the labels is an option to make users familiar 
with that seperator.

The path/button section of the field is right aligned to the 
left edge of the list view, to make the input section line 
up with said list view.
This way the dialog is split up into a path/places part
and an input/list part.

With no input, all files of the current dir are shown, with 
the first one preselected. Hitting enter will open it (go into 
a dir or open a file).
Mockup B shows how the file list will be filtered and how 
completion could work. If there's only one match, it would be 
selected to be opened on hitting enter. Partial completion is 
to be shown after the cursor, in a different colour and an 
Enter icon, as hitting Enter will accept the completion (until 
then, the Open buttons should be grayed out, actualy).
(a single character for completion is not the best example, 
I was just lazy here ;)
I thought about automatical partial completion, so in my example 
entering "h" would result in "ha" directly. But that would 
require the user to check what happens after each single key ...


I removed the bookmark buttons, because a larger list and less 
cluttered look seems more valuable to me. Would also make using 
the bookmarks in one-click mode a no-brainer.
Maybe a hint about drag and drop could be shown as last element 
in the list.


Cheers,
Thorsten Wilms