Re: [Usability] Three dialog problems

[Thorsten Wilms <t_w_ freenet de>]

On Tue, Feb 20, 2007 at 10:56:20AM -0600, Matthew Nuzum wrote:
 
> First problem: Open dialog is very ambiguous. I frequently run into
> the problem that I've illustrated here:
> http://people.ubuntu.com/~mnuzum/bugs/AmbiguousOpenDialog.png
> 
> The problem comes when I have multiple documents with similar names
> that were modified on the same day. For example, I frequently post
> press releases. They sometimes come in MS Word format. I may then save
> them as .sxw and as .pdf. In most of Gnome's open dialogs (I'd say
> all, because its every one I've seen) you cannot tell which document
> is the .pdf file. I know the .pdf is the newest file, but gnome
> "helpfully" conceals the modification time so I'm not sure which was
> edited most recently. This happens to me frequently enough that if you
> don't like my contrived example in the screenshot, I can come up with
> a non-contrived one by the end of the week.
> 
> I don't know a solution to this, but it is still a problem.

If it's really about the most recent, you can click on the Modified 
column header to switch to sort by date. Downward arrow means newest 
on top (I had to check, can't remember the direction mapping).

Seems like using labels like Today and Yesterday isn't such a good 
idea. I wouldn't be surprised if there's a gconf option to turn it 
off. If there is, there's still the question for the best default, 
of course.

The column header could give access to options via right-click. 
Nice for just-as-the-need-arises configuration, but I guess few 
would expect and discover it by themselves.

Tooltips could show full (wrapped if needed) filenames and  
date/time in all detail, perhaps.

 
> Second problem: Save as Dialogs are cluttered such that critical tasks
> are obscured. I use gedit a lot, and its save as dialog is a perfect
> example. http://people.ubuntu.com/~mnuzum/bugs/ShoddySaveAsDialog.png
> Note that folders I *never* use, folders whose name begins with a dot,
> come up first. "Character encoding" gets almost as much screen real
> estate as the file browser. The file browser itself is so tiny that
> you can barely see anything in there. Disabled form elements (two
> buttons and a select list above) consume a great deal of space.
> 
> I don't know a perfect solution to this, but one option could be to
> hide the disabled select list for "save in folder," shrink or remove
> the character coding select list, shrink the "add/remove" buttons
> (which I'm not sure what they do, so are they necessary?) and do some
> re-arranging of the "all files"  select list.

I guess the Character Coding stuff takes the full width because 
this is a variable part of the dialog. The othe elements stay where 
they are and below them is the space where application specific 
stuff can appear.

The Add/Remove buttons are for Bookmarks (Places). Select a folder 
in the file list, hit Add and you have a new entry. I added all 
my bookmarks through file dialogs, as it is when using them, I 
noticed the palces I need frequently. One could argue adding/removing 
could be done with drag and drop and/or context menus. There's a 
discoverability problem, but it looks like that's the case with the  
buttons, too, strange as it might seem.

-- 
Thorsten Wilms

Thorwil's Creature Illustrations:
http://www.printfection.com/thorwil