First UI component needing replacement.



	For the first component to be replaced, I have decided that the horrible
son-of-Motif GTK+ file dialogs must go.  I have made a mockup of a proper
file dialog, available here:
http://www.thock.com/Dylan/new_dialog.jpg

Here are my explanations for the changes/widget layout:
The file listview and directory treeview are split so that people need not
page through all the directories (as in the Win9x common file dialogs), but
neither are they given the equal size (since file names tend to be larger
than directory names).  Both should show colour icons to help indicate the
MIME/special (links perhaps) type of the files listed.  Presenting a small
graphic with each item in a list allows the opportunity to provide
additional information to the user, without sacrificing valuable screen real
estate. 

A recently used directories box has been added, saving people retyping
commonly used directories.  Obviously, the contents change based on the
application as Gnome could store the information in a section of the app
specific ini files stored in ~/.gnome (or the newer Gnome data storage
planned for v2.0).  Also, resizing of the dialog would be saved, but as a
global variable (in a Gnome config, not an app specific config like the MRU
directory listing).

I've also tweaked the buttons.  I replaced the "cancel" button with the
"close" button, since "cancel" will not rollback any operations performed in
the dialog on any systems I have ever seen.  Added are a rename and new
directory button.  This allows the user to rename old files when saving new
ones, as well as creating new directories to store new files in quickly. 
This simple addition can a lot of time for the user.  The buttons included
underlined letters to indicate the keyboard accelerator to use (meta + the
underlined letter) to active them without tabbing to them/using a mouse.

Besides just layout, there is a behaviour problem with some common file
dialogs that we need to stamp out.  The Motif dialog that Netscape 4.x ships
with is a great example of a badly behaved dialog.  If I shift+click on a
link to get the same as dialog, but wish to save in another directory, I
lose the file name when I change directories.  Why?  This makes no sense.  I
have to browse to the intended target directory, close the dialog (without
saving), shift+click again, and then I get both the target directory and the
proper file name.  No dialog or program should be designed in such a way to
increase the number of actions to get the desired results.

Comments?

-- 
    www.kuro5hin.org -- technology and culture, from the trenches.




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]