Re: File Open/Save dialog

Reinout van Schouwen wrote:
> Op zondag 03-01-2010 om 11:51 uur [tijdzone +0100], schreef SZABÓ
> Gergely:
>
>   
>> A few thoughts on the file Open/Save dialogs. I've just had a quick look 
>> in Bugzilla, there are about 200 related bugs, each dealing with some 
>> minor aspect. I'd rather propose a more general solution.
>>     
>
> I will try to give some short replies based on my knowledge of the
> situation.
>
>   
>> 1. Layout
>> 1.1. File name edit-box should be together with optional file-type or 
>> encoding drop-downs.
>>     
>
> Why? It might be obvious to you but if you think the current placement
> is bad, you'll have to explain how you come to that conclusion.
>   
Simple: the file-type determins the filename. A JPEG type file is called 
foo.jpg while a PNG is called bar.png. They belong together. They are 
even placed together in the OpenOffice Open/Save dialog (not to mention 
Windows, Mac OS X, etc). It's probably not a coincidence.
>  
>   
>> 1.2. "Places" should be deleted or optional, see below
>> 1.3. Folder Button-bar should be deleted or optional, see below
>> 1.4. Separate "Save in folder" and ""Browse for other folders" are an 
>> unnecessary complication, just display the folder-browser
>>     
>
> The designers of the dialog felt that the folder-browser was an
> unnecessary complication, at least unnecessary to display by default.
> Why do you think every user should be forced to think about folder
> hierarchies when he just wants to save a file?
>   
Most people reluctant to think about folders end up saving everything on 
their Desktop. Utter chaos, in other words. Why make my life miserable 
for their sake?
According to your arguments, the "Create folder" button should be 
removed as well.

Actually, I think people were originally not reluctant to think about 
folders, Microsoft just corrupted them with these My Documents, My 
Videos, etc. shortcuts. My boss used to program ABS systems in assembler 
10 years ago, but now it's a pain to watch him deal with his files...
>   
>> 2. Folder Browser Behaviour
>> 2.1. Hotkey Backspace for up-dir does not work as in Nautilus
>>     
>
> Works for me (Gnome 2.28).
>   
It was fixed in the meantime, then :-)
>> 2.2. Even item up-dir ".." is missing
>>     
>
> It's not missing. ".." is meaningless for anybody except people with
> good knowledge of the command line and filesystems. The breadcrumb bar
> is there to navigate a level up.
>   
I just proposed it as an alternative of the missing Backspace.
>   
>> 2.3. Items are not right-clickable as in Nautilus
>>     
>
> That is because the filechooser is not a file manager.
>
>   
It is in Windows. You can stone me now.
>> 3. Keyboard navigation
>> 3.1. Tab-completion in file-name edit box is nice, but first I thought 
>> it's broken keyboard navigation
>> 3.2. Escape from file-name edit box by Ctrl-Tab is not intuitive, as Tab 
>> works everywhere else
>>     
>
> You have a point, but believe me when I say that hell would break loose
> on the internets if the GTK+ developers were to change this.
>   
It's OK, I can live with that.
>   
>> 3.3. Folder Browser unusable due to lack of up-dir hotkey, see above
>> 3.4. "Places", folder button-bar etc are simply a huge bug as regards 
>> keyboard navigation, see above
>>     
>
> Then let's fix the navigation and not remove a useful feature.
>   
The main way to fix keyboard-navigation is to (optionally) decrease the 
number of widgets on the dialog.
>   
>> 4. (Dis)similarity to Nautilus
>> To summarise things, the dialog's main problem is its dissimilarity to 
>> Nautilus. It looks similar, but it behaves completely differently, which 
>> users do not expect.
>>     
>
> It looks similar to Nautilus' list view, but that's not even the default
> view in Nautilus (that's icon view). So I don't think this point is
> really valid.
>   
I meant the functional, behavioral dissimilarity. No right-clicks, no 
configurability etc.
>   
>>  I actually think Nautilus and these dialogs should 
>> be the very same project. 
>>     
>
> Technically impossible. The filechooser is a GTK+ widget which cannot
> depend on the pile of Gnome libraries Nautilus depends on.
>
>   
>> 4.1.1. Take over layout config from Nautilus (presence of Places, 
>> button-bar etc)
>>     
>
> Actually I don't see many differences in the layout between the Nautilus
> Places sidebar and the one in the filechooser.
>
>   
I mean the PRESENCE of the Places sidebar, not how it looks. You can 
notice a theme developing here: I want to get rid of the Places sidebar 
somehow ;-)
>> 4-1.2. Use the icons/list/column layout as configured in Nautilus for 
>> the Folder browser
>>     
>
> Note that this is per-folder setting. 
>   
Unfortunately.
>   
>> 4.2. Take over Folder Browser's behaviour from Nautilus
>>     
>
> Please specify what exact behaviour you refer to.
>   
Please look just below...
>   
>> 4.2.1. Backspace for up-dir
>> 4.2.2. All items right-clickable with usual context-menu (e.g. remove 
>> write-protection etc)
>>     
>
> Read-only permissions are located in the Properties notebook of a
> file/folder, not in its context menu. 
> What's more, replicating a file manager within the filechooser would be
> a waste of effort. If you want to manage files, use Nautilus. If you
> just need to open or save a file, the filechooser does its job just
> fine.
>   
The evil and rude Microsoft still managed to do it: A fairly intuitive 
user interface, which looks and behaves the same all the time. Please 
stone me again.
> To conclude: certainly improvements to the GTK+ filechooser are
> possible, but not all of the points you mention are actual bugs. Reading
> up on the history of the filechooser may explain you better why things
> are as they are.
>
> regards,
>
>   

I never said these were bugs. I just proposed possible usability 
improvements.
That's the exact reason I've posted this to "Usability" and not 
GNOME-bugzilla.

If nothing goes, I promise I'll stick to the Tab-completion feature in 
the future (that's a rhyme!).
And as much as I was praising Microsoft, their product is completely 
broken by the simple fact that Backspace jumps to the first item of the 
up-dir and not to the dir where you've just come from. GNOME rulez.

Best regards
Gergely
_______________________________________________
Usability mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/usability