Right now the All Powerful KDE File Dialog has a few unfortunate usability, visual and functionality quirks that diminish it's wonderfulness. (Is that even a word?) I didn't feel like doing anything too major to it as it's a proven model; that and I don't want to spend too much time on it either given all the other things I've got on the go. But still ... It needs a bit of love right now.
After fiddling with it a bit, I dropped an email to the usability list. Discussion ensued, and Peter Penz provided some data he gathered from user testing he'd done with it. (It's very nice how the number of people working on file management stuff has really grown with KDE 4.) I continued fiddling with things trying to improve the visual layout and make the order of things more correct (e.g. for scanning). Here is what it currently looks like on my disk:
I'll leave it as an exercise to the reader to see if you can spot all the modifications. I'm not quite done yet, but it's coming along nicely I think.
As a historical note, here's what the dialog used to look like a long time ago:
We're obviously not quite so obsessed with frames and divider lines anymore, but a lot has remained at least somewhat similar as the dialog has grown in power and usability over the years.
p.s. The QtWebkit crash I mentioned in a blog a couple days ago has now been fixed upstream. Huzzah! I can browse without crashes now. =P
56 comments:
I personally don't like the "quick access navigation panel" - but that's nothing new. Your new screenshot looks like a huge improvement, though!
What's the deal with the Encoding selector? What's the use case for a user actually needing to change this often frequently enough to warrant such a prominent location. I'd demote it to a menu and remove it from the actual widget.
I don't see the point of the encoding combo box either. Filesystem encoding is usually set by the system administrator at install time and it's unlikely to change.
What's the deal with the Encoding selector? What's the use case for a user actually needing to change this often frequently enough to warrant such a prominent location. I'd demote it to a menu and remove it from the actual widget."
I was just about to comment on that as well :). I bet that Joe Sixpack is utterly confused as to what that thing does and what "UTF-8" means. Hell, I consider myself a geek, and I'm confused about it!
Looking good, and getting better all the time... But is there anyway to switch to smaller icons???
nm... answered my own question.. :) Unless you changed the option (unlikely).
Now, if I can just figure out how to change the icon size in Folder View...
What I really miss is the option to manually filter files. In Windows file dialoges it is possible to enter in the name field for e.g. kde*.png, so that you only see this files. This is extremely usefull, if you have folder with many files.
@Mark: what do you think the 'filter' thing is for ;-)
One good thing about the Vista file dialog seems to be the search bar at at top right like in most web browsers. My father uses it very often to locate files where he has forgotten the name and sub-folder. This would be a great feature but I am not sure if Strigi/Xesam can limit searches to certain file extensions and a different top directory. Any thoughts about it?
About the encoding: I would remove the label and name the first selected entry of the combo box: "Default encoding (UTF-8)". This might remove some confusion?
What's with the empty space in the upper left corner?
+1 on a search thingie.
@Seb: it's the file dialog from katepart; it adds the encoding bits itself as a customization. i use it as a test for the file dialog because kwrite starts quickly and it uses features like custom widget additions.
the regular file dialog doesn't have an encoding dropdown, but for a text editor it's pretty useful/important.
@Henning Schröder:agreed; we're just not quite there yet with search integration unfortunately. soon though =)
@Fred van Zwieten: the breadcrumb aligns with the folderview this way. i tried it flush left, it sucked. i tried putting other things in that space, it sucked less but still more than having nothing there.
Strigi Integrations is planning? That is awesome. I thing it is very good feature either.
Aaron, I push the QtWebKit crash fix and it will be available in the next Qt 4.4.2.
Is Home really with a capital "H" in the breadcrump path? I would expect
a lower "h" there.
Is it still possible to change
the directory manually. E.g change
easily from:
- /home/kde4/build/KDE/
to
- /home/kde3/build/KDE/
Just change the 4 in a 3 and enter.
As can be seen in your blog post, this was possible in former versions.
Personally, I don't like it. We are wasting space just to move the toolbar on the right side, what's the improvement here? Even visually is uglier (blank space on the left)
And what about making the "quick access" panel looks like the "places" panel in dolphin :
http://pix.nofrag.com/6/9/e/e29fd4c04244c063562db0a137d3d.html
A lot of people don't want frame anymore but having just one for the bookmarks is probably not that bad...
@Richard Bos:
> Is Home really with a capital
> "H" in the breadcrump path?
> I would expect a lower "h" there.
/home/aseigo is substituted by the place "Home", so a capital "H" is OK. In KDE 4.2 it is also possible to switch the breadcrumb to a "Show full path mode", so that instead of
[Home]>[kde4]>[build]
it is shown as
[home]>[aseigo]>[kde4]>[build]
> Is it still possible to change
> the directory manually. E.g
> change easily from:
> - /home/kde4/build/KDE/
> to
> - /home/kde3/build/KDE/
Yes, you can always switch to the mode having a line edit and the setting is remembered. Hint: when being in the line edit mode and you press CTRL+Enter the change is submitted and the breadcrumb gets activated again.
Very nice job, Aaron. It now looks much more consistent with the file manager.
I only have a small question/comment of a thing that I wholeheartedly hate*: the directory selection dialogue (for example the one used in ark for selecting the directory in which you want to extract some files). I understand that this is a standard widget of KDE, isn't it?
I do not know how this is done in other OS, and I do not care. But this widget looks obsolete and out of place with all the nice improvements done all around... Are there some ideas around for this? ... Perhaps Aaron will tackle this next year? ;)
KDE4 is impressive, now you really have to look around very maliciously to find things you do not like.
* just wanted to make a bold statement :), it is really not like that .
Claudio
> > Is Home really with a capital
> > "H" in the breadcrump path?
> > I would expect a lower "h" there.
>
> /home/aseigo is substituted by the place "Home", so a capital "H" is OK.
Hmmm, I don't like as it does not reflect the reality.
It also surprises me, that the kde devs implemented this functionality.
> In KDE 4.2 it is also possible to switch the breadcrumb to a "Show full path
> mode", so that instead of
How does one switch? Is that with an accelarator key, or with
a configuration option?
> [Home]>[kde4]>[build]
> it is shown as
> [home]>[aseigo]>[kde4]>[build]
>
> > Is it still possible to change
> > the directory manually. E.g
> > change easily from:
> > - /home/kde4/build/KDE/
> > to
> > - /home/kde3/build/KDE/
>
> Yes, you can always switch to the mode having a line edit and the setting is
> remembered. Hint: when being in the line edit mode and you press CTRL+Enter
> the change is submitted and the breadcrumb gets activated again.
I guess as above, how?
Nice know that line edit will continue to exist :)
I think the filter box should be above the list view, just like it is everywhere else in KDE. Consistency is an important thing, IMHO. I agree with other comments on the encoding combo: I don't see a usecase. I'd rather have buttons to change the view (list/detailed/icons/etc.), which is something that is usefull sometimes.
@Richard Bos: please check http://dolphin.kde.org/features.html for some details.
Totally off-topic but I just wanted to put this out there. Mozilla Ubiquity has landed and it's totally awesome and seems to be very much in tune with the goals of KDE4, and all that.
I just wonder what room for cooperation there is though Mozilla would not want to tie to KDE nor KDE to Mozilla.
Hmm.. why is the navigation in a different place than konq and dolphin? Changing the position of controls is not a good thing to do.
In KDE 3.5, if I want to, I can preview my image files in the file dialog. I'm sorely missing that.
Thanks in advance ;)
looks good to me, man. My biggest frustration with non-Windows file save dialogs has been keyboard navigation.
I shouldn't have to take my hands off the keyboard to move around the dialog--it looks like you're handling that.
Thanks for all your hard work!
"I'll leave it as an exercise to the reader to see if you can spot all the modifications."
i still see the oh-my-god-what-a-huge-ones left side icons
learn from windows: save and win screen real state , don't waste it
my 2 c
I agree with 'Alejandro Nova', the thing I miss the most in 4.x are the thumbnail previews of files.
For example, when I'm looking for a background image for my desktop, I have to look up all images in dolphin first..
Sorry, but that is not an improvement.
Breadcrumb is good (thanks for that), but the only other change I can see compared to the dialog in 4.1 kwrite is that the location bar has switched places with the back/forward/up/etc toolbar buttons. That is confusing and should be reverted.
You brought up that very old dialog, but missed the most important point: the buttons are always to the left of the location bar. So for many many years people have been conditioned to that layout, and changing it will not be fun. The aesthetics of the change are debatable.. Now it looks pretty much exactly like the windows dialog: http://wiki.services.openoffice.org/w/images/thumb/e/ed/WindowsOpen.png/500px-WindowsOpen.png
These dialogs aren't usually that big, and now the cosmetic indent wastes space, and the breadcrumb view takes more space, making working with folders much more cramped than before. And when that search integration does come, there certainly won't be any space for an additional box on that line.
Either the order should go back to buttons locbar, or the location bar could go somewhere else, perhaps directly above the file selection pane, but in its layout (so the buttons are on the top bar by themselves, soon to be joined by a search bar).
@Alejandro Nova, Diedrik: previews are still there; if they aren't showing in your file dialogs, hit F11 or click on the configuration wrench and select "Show Preview"
@celest: scan order. when i first open the file dialog i want to know where i am, then i want to navigate and pick a file and then i want to dismiss the dialog. this is now laid out top left to bottom right.
dolphin's toolbar buttons are separated from the location bar, so it doesn't have this problem. konqueror .. well .. yeah. =)
@flouzy: hm.. maybe i'll try playing with that ... thanks for the idea.
@ombzzz: "i still see the oh-my-god-what-a-huge-ones left side icons
learn from windows: save and win screen real state , don't waste it"
actually, we don't waste real estate. the icons grow to consume the size you give the sidebar (larger targets == easier to hit). as the number of items grows, they shrink down (to a minimum height, o fcourse) and as you make the space for them smaller (either via the splitter drag handle or by making the dialog smaller) they also shrink if needed.
so there is no wasted space at all.
@Leo S: In the Windows dialog you linked to, you'll notice the visual chaos in the (lack of) alignment as well as the combobox vs breadcrumb. *shrug*
"the cosmetic indent wastes space"
it's not actually a cosmetic indent; aligning things is actually easier on the eyes and makes it quicker to visually switch between elements. as for how much space is being wasted, that depends on how big you make the shortcut bar, and even then it's a few hundred pixels at best.
"or the location bar could go somewhere else"
if you actually try this in the layouts, then one starts to really understand the meaning of "wasting space"; it also leaves a number of alignment issues open.
I think Alejandro and Diedrik ment displaying thumbnails in "main area" of the file dialog, just like konqueror and dolphin does. I miss that much too, as I don't find f11 preview sidebar very usable.
ok, time for spoilers =)
* back/forward buttons are first in the toolbar button line up; this is because it seems (according to user testing) they are more often used than up and the breadcrumb provides an implicit up as well.
* topleft->bottomright scan order reflects use order: where am i? (location), what file do i want? (directory listing), now do it! (action buttons)
* the technically correct but generally confusing "Location:" label is now "Name:"
* labels are right aligned
* the widgets are aligned to a grid so we don't have left/right edges forming uneven lines
Aaron, if the back/forward buttons are most frequently used, then shouldn't they be on the right-most edge of the window?
@njaard: "if the back/forward buttons are most frequently used, then shouldn't they be on the right-most edge of the window?"
they are the most used of the buttons, but not (usually) the first thing used.
the common first thing is to look at where you are, which is a combination of the location and the file listing.
the location bar is "the" component up there in the toolbar area, and so it's most-left; it's also aligned with the listing so that shifting attention between the location and the listing is as nice as possible..
Just to increase duplication with discussion on kde-usability :), here are mockups I made:
- Open dialog
- Save dialog
Changes:
- Navigation buttons on the left
- Configure / Ok / Cancel buttons on a bottom row
- No "new folder" button in the open dialog
- "new folder" button with label on the right of the url in the save dialog
It's amazing how much discussion there can be the order of some widgets.
I'm not sure I'm entirely on-board with the theory that one scans the toolbar topleft to bottomright but I like the fact that such details are being thought about.
Strange how odd it seems to have space in the top-right... perhaps there is something in that theory ;)
"I think Alejandro and Diedrik ment displaying thumbnails in "main area" of the file dialog, just like konqueror and dolphin does. I miss that much too, as I don't find f11 preview sidebar very usable."
https://bugs.kde.org/show_bug.cgi?id=158894
Rest assured, it's on the devs' TODO list :)
I am so tired of browsing file dialogs to find the location I did something in from another program.
What I really really would like to have: quick access to recently saved files, and the directories they were saved in.
If ALL file dialogs had this, and they did it the same way, it would be much easier to do work on a file in one program, and then continue working on it in another program.
Now all programs seems to have their file dialog states "unsynched". They may remember what directory they used the last time, or they may try to be intelligent what directory you want to use, but they don't really keep track of the users intentions. If a file was recently saved in using a file dialog, I think it is very probable that you would like to open it using a file dialog soon again. (It might not be so simple with files manipulated using the shell though)
Boo for encoding as well...
Something I've noticed is the left to right scrolling seems wrong.
If you have 3 or more columns, the scrollbar behavior is jumpy to either extremities, making it a precision operation to see the middle columns.
Great work.
Derek
Great work, Aaaron! The dialog is much cleaner now.
Also, it is great to see how Celeste's and Ellen's usability insights (alignment, etc.) make KDE better with nearly every screenshot shown on the planet these days!
Kudos to you all!
My concern is lengthy paths and how that will look/work.
What about /home/enderandrew/project/trunk/folder/subfolder/subfolder2/etc ?
I prefer agateau's mockups honestly, though I also don't mind the concept of duplicating the "places" look from Dolphin.
I understand the reasoning that you'll want to look at your current path first, however I think eventually you'll get used to knowing your default directory. Immediate, or first-time use would be to look at the location first. I rarely however pay attention. Either I'm in an editor of sorts, and it defaults to the folder I last opened a file (usually the same folder for the next file in one particular project I'm working on) or my default folder is there.
And even if it makes sense logically for the location to come first, it looks a bit odd.
agateau's mockup puts the buttons where I will seem them immediately and access them easier. I also like the prominence of the "new folder" button in those mockups.
I also wonder how necessary the forward button is in dialog. In a file manager you might go back and forth a great deal, however in a quick dialog, I can't anticipate going forward that often.
I really look forward to strigi integration. I'm not sure if that will be implemented in the current filter box (allowing regex, tags, wildcards and all kinds of crazy stuff) or be a separate box.
And maybe I'm crazy, but I'm wondering if it would look better for the icons in the open and cancel buttons to be aligned to the left, and then have the text centered in the remaining space.
@Claes,
"What I really really would like to have: quick access to recently saved files, and the directories they were saved in."
You should be able to do this with Strigi/Nepomuk, probably using the Nepomuk:/ Kio-Slave (you should be able to add it to the places column as well). Not something I've personally tried, but I'd be rather surprised if it didn't work.
@aseigo
"@Leo S: In the Windows dialog you linked to, you'll notice the visual chaos in the (lack of) alignment as well as the combobox vs breadcrumb. *shrug*"
Lack of alignment? Actually, the alignment of the path selector (combobox in this case) is exactly the same as in your dialog. The only difference is that they fill the space with a label (Look in:)
"as for how much space is being wasted, that depends on how big you make the shortcut bar, and even then it's a few hundred pixels at best"
Yes, but horizontal space is at a premium already. Breadcrumb eats (justifiably) some of that horizontal space. Then an unnecessary padding eats more. It's going to make working with deep paths a lot more cramped, no way around it.
"if you actually try this in the layouts, then one starts to really understand the meaning of "wasting space""
The wasting of space is only a big issue if its wasting space where space is tight.
But either way the problem remains.. In your design, the top bar is essentially full. When the search is eventually integrated, (I assume that's probably going to happen in the next year or so) where does it go?
One inconsistency that there is on KDE 4.1 is that the left sidebar places shorcuts require double clicking to open them, while the normal icons need only one click. Has this been fixed on 4.2?
No Leo_S, theres more than that. The Location Dropdown is aligned, but the label is not, it sticks out to the left. The toolbar icons are not aligned, they leave space to the right. The vertical icons ("places bar") overflows on the bottom and the filename dropdowns are too far away from their labels. I think the KDE file dialogue looks _much_ better than that.
And for all the people complaining about the file encoding: It's only there in text editors, and it's really needed there, damn' it!
I agree with Vide, it makes much more sense to put the toolbar buttons to the left of the location bar, now you're wasting all the space on the left, which means less space for the location bar. I consider that a step backwards.
Justs thought of something: why is there a reload-button in the file-dialog? To see if there has been changes in the filesystem? Shouldn't that be handled automatically? If someone changes the filesystem, the change should be visible automatically, instead of requiring the user to click "reload".
Did your changes include a way to show hidden files?
Aaron said: scan order. when i first open the file dialog i want to know where i am, then i want to navigate and pick a file and then i want to dismiss the dialog. this is now laid out top left to bottom right.
my anwser:
I do not think, this is how I use the dialog. I expect my location to be at ~ if I have not used the dialog in the program before or to be, where I opened/saved a file before. So I always know where I am even without looking. And still, this improvement does not fix the scan order issue. I have to scan ugly blank space before I can scan the path.
And have anyone ever asked the usability experts, what the user intends to do while pushing the back button? I think it's a safe bet to say, they want to get to parent directory. So the user is using a wrong button, but in most cases it accidentaly works for him.
@Kevin: i actually tried "filling" that space with things (the buttons, a label, etc), and then actually using the dialog afterwards ..
@Janne: that only really works for local file systems; most remote systems don't have great (or any, even) change notification.
@freOn: it puts the location first, that's the important point. and yes, i've been discussing this with Celeste as well (not like i'm a complete ignorant when it comes to design and usability, but whatever)
"@Janne: that only really works for local file systems; most remote systems don't have great (or any, even) change notification."
Couldn't KIO handle that? I have been dreaming of a folderview dropbox that resides on remote system, but if there is no live updating of filesystem-contents, that idea would not fly.
But, related to subject at hand: Since the reload-button is only needed when dealig with remote filesystems, could it be hidden when the user only handles local filesystem? If he's browsing the HD of his computer, he has no need for refreshing.
@janne: it really depends on the ioslave. some do (smb for instance, iirc) but others don't (e.g. ftp, due to the protocol itself)
hiding/showing ui bits is generally regarded as a bad thing as well usability wise. (exceptions to the rule exist as with most "rules of thumb")
@jospoortvliet: I know what the filter is for, but at least in KDE 3.5 (unfortunately I do not have 4.1 running to check if it changed there) you are dependent on the predefined filters and can not set one yourself.
@mark: hm... at least here in trunk/ i can just type in *pdf (or whatever), press enter and get just pdfs (plus folders, of course)
one thing that could be better there is it could apply the filter when focus is lost and not just when enter/return is pressed.
I'd suggest to make "ok" and "cancel" button taller, to take all the space down to the encoding selector
@Aaron J. Seigo: I don't doubt for a moment that you have tested your changes, but what felt best for you is not necessarily what's best for everyone:
* I think the wasted space and the shortened location bar are real practical disadvantages.
* Don't forget the power of habit. You're a very curious/researching and innovative person, willing to try out new things. Many computer users, on the other hand, either get confused when things change or feel that things are just "wrong" (and I'll happily admit to be part of the latter group - to give you an idea: I use the classic menu, the first thing I did to the file dialog was to click away the "breadcrumbs" and my style and windeco is Quarticurve, the Qt/KDE 4 port of Bluecurve ;-) ). So changing a UI shouldn't be something done lightly, there should be a real benefit, and I doubt putting the icons to the other side of the dialog is really worth it.
Now of course if you think I'm just an overconservative lunatic, feel free to ignore me. ;-)
Post a Comment