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

List:       kde-usability
Subject:    Re: Updated File Selection Dialog Designs
From:       "Jamethiel Knorth" <jamethknorth () hotmail ! com>
Date:       2004-08-09 16:00:00
Message-ID: BAY7-F29ap7LhLNyk4p0001417c () hotmail ! com
[Download RAW message or body]

>From: "Aaron J. Seigo" <aseigo@kde.org>
>Date: Sun, 08 Aug 2004 22:19:33 -0600
>
>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.

Thanks for the in-depth reply.

>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.

It does? Okay. In that case, I would say just always have the home icon 
there, as it will fill out that side when using normal icon sizes and look 
fine besides that anyway.

>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?

I'm not sure how useful it is, really. Those who don't understand it 
probably won't even if it is in a separate combo, while it simultaneously 
adds a lot of clutter to the dialog.

The best way I can see it just having a small combo-box beside the location 
bar, so that the protocol have the small box and then there is still a lot 
of space for the location to be displayed. That seems a fairly simple way to 
display it. I'll test how it looks when I next get a chance.

>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 disagree. The path drop-down is meant to display the location you are 
currently in. I would want it to be treated as such. Having it open a file 
can confuse the issue.

>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.

The problem there is that it doesn't separate out the selected file itself, 
meaning that the selected file it not given a lot of precedence to the user. 
In its basic usage, the dialog is used to select A FILE, and not having the 
file separate out to give it clearer importance can confuse that issue. 
That's why the file selection bar is given an entire line to itself in this 
design.

>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 ;-)

I know.

>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.

The problem I have been running into is that there are too many options to 
fit into one menu, but they are still important.

>previews should
>just follow the global settings (e.g. the ones konqi uses).

For which ones are shown, yes. However, if there is a configuration dialog, 
I see no reason not to include it there. If there is no dialog, that is one 
option that can be dropped.

>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.

The bookmarks should be editable through the context menus over them in the 
QuickAccess bar.

>recent locations should follow the app defaults for such things.

What app default is there for how many recent items to show in a dialog? In 
programs, the recent items list has a full sub-menu to itself, so space is 
not a concern, so that setting is clearly not acceptable.

>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.

There is not option to configure what details are shown, just to config 
which filetypes have details shown for then, which can be quite useful. With 
the options I included, you can set it to have it not show an icon when a 
preview isn't there, leaving only details. Then, if you have those items 
with previews not show details, the preview are would always show something: 
either the file details or the preview, which is how I would want it to be 
set up most of the time.

>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.

You almost stated the reasons in that comment there, but allow me to go over 
my thoughts:

When using a hotkey, the usual purpose is to hide or show all of the 
information on that side of the dialog, not to change just the preview or 
the information. By default, both are shown, and the usual desire for the 
hotkey is to hide them both or show them both, as they are currently set to 
be displayed.

The issue is trying to show the hotkey anywhere accurately, since the menu 
configures whether or not a specific one is shown.

>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.

Perhaps they should be placed beside each other, but that is a matter of the 
default configuration. The specific order things appear in is configurable 
for this reason. You're probably correct that the default order should be 
having both bookmarks at the top. I'll note that and see about changing it 
when I get the chance.

>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...

That can be a serious problem, since showing unmounted devices can make the 
list very long. Also, it's counterproductive in a more recent desktop. 
People can be easily confused between the mounted/unmounted icons and they 
don't actually do anything useful a lot of time. Clicking an umounted one if 
nothing is there will just give you an error message after hanging for a 
second trying to mount something that isn't there. If you have an 
auto-mounting system of any sort, inserting a CD will add it to the list, so 
the icon is a total waste of space in that case.

It should be up to a distribution to ensure that the setting for showing 
unmounted devices matches up with their automounting system.

Even if that is changed, the list does need to be dynamic, to allow for USB 
drives and so such.

>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.

My reasoning here was in regards to solving one of my most common problems, 
so I'll explain it here quickly and see who else thinks it's more useful 
that way. I still do, but I'm biased by my own problems.

The most common issue in the open/save dialog is actually when editing the 
same group of things with a new tool. I commonly switch programs to work on 
the same project, and then have to dig around for it. As long as I am inside 
one program, it recalls the last directory I was in and that is good enough. 
The recent-locations list solves the problem of a newly started program 
knowing where I am currently working.

However, the opposing side is that the recent items list allows you to 
maintain a location between sessions of one program, but that is also very 
easily done with the bookmarking option. Since the new button is a 
single-click action to add a bookmark, it solves that problem for 
remembering locations and the recent-locations list solves the other.

Although it may be slightly less useful to a new user, having those two 
complimentary actions is more powerful overall and can give a more 
significant performance boost in the end.

>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.

The "Automatice Previews" option is available through the configuration 
dialog, and I put it there alone to avoid cluttering the configuration menu.

I would like to have a way to indicate that clicking the large icon would 
cause it to display a preview. This seems the intuitive way for things to 
work, yet I can't think of a way to convey this to the user. Any ideas?

>and what about things like "separate directories from files"?

That is also in the configuration dialog. I'm short on time at the moment, 
but I'll reply sometime tomorrow with more comments about the configuration 
dialog.

>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?

You're right.

I'd prefer for it to be below it, so that all added options go in the same 
place, always.

>again, i question splitting out the filename from the rest of the URL. they
>should be separately edittable, but seperated across the dialog? i dunno...

The main reason is to give added importance to the filename, which is the 
primary focus of the dialog.

>if that were to move to the top leaving us with just the filter drop down
>below then it should probably sit directly beneath the file display 
>(meaning,
>not including the speedbar) since that is its true context.

That is a good point as well, and I'll have to give it a little more 
thought.

>have you checked what the longer strings look like size-wise when 
>translated
>into other languages, esp the verbose ones like German?

No, I have not. However, this is all at an increased-size font (13 point, I 
think), so it will usually be a little cleaner than this.

>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.
>
>
>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.

Another thing I'll comment on tomorrow or the next day, since I have to be 
going in approximately negative two minutes.

>well... there you have my initial thoughts =)

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE! 
hthttp://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

_______________________________________________
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]