[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: Updated File Selection Dialog Designs
From:       Peter Postmus <ppostmus () mailshack ! com>
Date:       2004-08-09 10:55:58
Message-ID: 4117583E.3070207 () mailshack ! com
[Download RAW message or body]

Yeah, I'm still alive ;).

Aaron J. Seigo wrote:

>On Sunday 01 August 2004 12:50, Jamethiel Knorth wrote:
>  
>
>>http://www.csis.gvsu.edu/~abreschm/designs/file_selector/
>>    
>>
>
>ok.. let's address this in different sections: top navbar, speedbar, middle 
>navigation/file display section, the lowever "results" section and search. 
>
>Top Navbar
>----------------
>First, some trivia.. a home icon appears in the toolbar if you don't have a 
>link to Home in your sidebar or don't show the sidebar. i think this should 
>be preserved, as it's pretty important to have such a link SOMEwhere in the 
>dialog.
>
>i like the separation of the buttons to the left and right of the location 
>drop down. it would be VERY nice, however, if there was a section for 
>protocols... e.g. file://, ftp://, http://, webdav://, fish://, etc... this 
>would help reinforce the network transparency. in open dialogs it could show 
>all sensible read protocols, save dialogs would show only protocols that 
>support writing... it would, of course, support editting by hand so someone 
>could put imap:/ in there if they really wanted to ;-) ... i'm not 100% sure 
>how best to present this. perhaps as another drop down next to the path?
>
>  
>
IIRC, this was brought up some time ago wrt Konqueror. Indeed, users who 
are new to KDE don't realize there is so much network transparancy in 
there. Having a combobox to let the user choose a KIO-slave would help, 
but only for experienced users (for example, a power user coming from 
Windows). Novice users probably wouldn't know in what way http:// 
applies to saving a file. The question remains if we should try and 
educate such users ;).

>as for interaction issues, the path drop down should respect entering FILES 
>into it... so if you do /home/aseigo/foo/thefile.txt in the path drop down it 
>should open that file. right now it just removes the file and opens the 
>directory. i don't think that's expect behaviour.
>  
>
I'm not sure... I think the expected behaviour for that kind of URL is 
to open the containing folder, select the appropriate file (also put it 
in the "Selected file" area), but don't open it yet.

>in fact, i'm not convinced having the file name and the directory path so far 
>apart makes sense either. really, the url is:
>
>	protocol		path		filename
>
>it would make sense to show it as such rather than break it up and separate it 
>all over the dialog, IMHO.
>
>  
>
I don't agree; to many users, a file is a different thing from its 
protocol/location.

>note you'll get guff for removing the bookmarks menu in the top from various 
>people. i don't agree with them, but.. just give you a heads up, if history 
>is anything to go by ;-)
>
>now for the config menu.. i'm really not happy about the idea of adding a 
>configuration dialog. that seems insane given that this is to configure a 
>dialog. complex or not, it shouldn't require configuration. previews should 
>just follow the global settings (e.g. the ones konqi uses). bookmark editting 
>can be accomplished without a massive config dialog, either. the bookmark 
>button could be a delayed pulldown that has "Edit" as an option, for 
>instance. recent locations should follow the app defaults for such things. 
>configuring things like what details are shown are also overkill; this isn't 
>a file browser it's a file dialog, which is to say this isn't konqueror.
>
>  
>
Agreed.

>sharing F11 between the two file preview entries is a non-starter, too. there 
>are technical issues that prevent this, but furthermore this is just bad 
>practice. even if they affect items in the same area, they should have 
>individual controls. how do i add the file preview if i already have the 
>preview pane shown? this is a classic example of trying to expose an 
>implementatoin detail too literally. rather, if the user has EITHER file 
>previews OR file details turned on the pane should be shown for them, 
>otherwise it should be hidden. simple. and each would then have their own key 
>accel.
>
>Speedbar
>--------------
>
>i like the new look better than the existing one, however there are issues 
>IMO...
>
>why are Home, Desktop, Documents separate from the bookmarks? who's to say 
>that they are more or less important than the user set ones? or that the user 
>wants Home but not Desktop? what's the semantic difference? yes, global 
>versus app specific. i don't think that's enough to warrant putting one at 
>the top and the other bottom, though. separate them, perhaps, but not so far 
>apart. in fact, in the case of these bookmarks which ARE more important to 
>the user? configuring both sets of bookmarks should be identical, as well.
>
>devices should show all devices including unmounted ones since that's really 
>just a detail for users. why should they have to worry about mounting a CD 
>_first_ before being able to see it in the speedbar? no.. it should show up 
>as "CD" and if it isn't mounted it should do so. just like the current 
>devices:/ url...
>  
>
Agreed.

>the recent section.. i'm not sure it should be desktop wide. i mean, the 
>recent documents list in individual programs aren't, are they? this is 
>because i could care less where i last saved a file from a web page in Konqi 
>when i'm saving my word processing document. the challenge is that these 
>things tend to domain specific, e.g. are we working with image data, word 
>processing files, music, code, config files??? perhaps a more interesting 
>would be to base it on the mimetype of the file filters falling back to the 
>program's own recent list if there is no preferred mimetype defined.
>  
>
Great idea.

>the file preview area looks nicer, too. however, for slower machines or very 
>large files having an automatic preview is not practicle. ergo the "Automatic 
>Preview" checkbox. i'd suggest this gets moved to the config menu, greyed out 
>when previews are not turned on (either thumbnails or metainfo display), and 
>when chosen a "Preview" button is shown in the preview pane.
>
>and what about things like "separate directories from files"?
>  
>
Seperating directories from files might give a cleaner look, but what if 
there are very few directories in the current location? In that case, 
some space would be wasted. I guess it's a tradeoff.

>Lower "Results" Section
>----------------------------------
>
>great to see a more standardized location for the buttons and more room for 
>the rest of the stuff. however, the auto exstension checkbox SHOULD NOT be 
>between the buttons. that's very non-standard and would prevent using the 
>standard KDE dialog classes. it should be right below the filter selection. 
>or perhaps next to it (how long are the filter strings ever anyways?
>  
>
100% agreed.

>have you checked what the longer strings look like size-wise when translated 
>into other languages, esp the verbose ones like German?
>
>i really like putting app-specific stuff down there as well. e.g. the kwrite 
>encoding drop down really does belong down with the filter stuff.
>  
>
Agreed.

>
>Search
>----------
>
>search is a good idea.... i'm just concerned about the details, which will 
>make it work or not work =) look at kfind for an example of the absurd 
>details one might want when searching. of course, it would be a simplified 
>search, but would it search file contents, metadata or just file names? how 
>to communicate where the search was done in a clear manner? does the search 
>really belong at the top of the speedbar where it provides more visual 
>clutter and implies greater use than the speedbar or would it be better 
>served as "Just another protocol" e.g. search:// or as some other form of 
>interface altogether? what differences would there be between local searches 
>and network filesystem searches (e.g. over fish://) if any? how will we 
>handle the fact that searches probably won't autoupdate to reflect changes in 
>the filesystem like the normal views do?
>
>it seems to me that to be truly effective such a search really requires a 
>whole bunch of infrastructure that we just don't have currently. think 
>ReiserFS4, WinFS, that new MacOS X thing or GNOME storage. also note that 
>none of these are even production ready ATM, as far as i know. 
>
>
>well... there you have my initial thoughts =)
>
>  
>
True.. having search functionality implemented like this is unclear to 
the user. However, putting more search options would clutter the dialog 
too much IMO. I think we should have a "Search" button, which opens up a 
modal dialog, in which some more (but prob. not all) search options are 
present.

One last idea to make things look cleaner. The "Selected file" and 
"Display filter" textarea's in the Open File dialog, and the "Save file 
as" and "Save as type" textarea's in the Save File dialog would look 
much better if they are aligned like the location bar, so the left 
X-coordinate of the textarea's would be equal to the left X-coordinate 
of the location view pane. But, then again, maybe #25 is even a better 
solution.

-- 
Met vriendelijke groeten,
With kind regards,

Peter Postmus

WWW: http://starbase218.ath.cx

_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]