Design of the Thunar Progress Dialog
Monday, September 14 2009, 03:21 - Permalink
Today, I merged the shared progress dialog into Thunar. I can be seen on vimeo. This evening I started thinking about the waste of space in it. For each copy/move/link/delete/trash operation we have: one icon and two lines of text, followed by another line with a progress bar (with text) and a cancel button. That's not too much and it looks kinda clean. Thunar has always hidden too detailed information from the user, like the size of the files, how many megabytes have already been transfered/deleted or what the MB/s rate is. But still, three lines of widgets for each operation is a waste of space. And the more space we waste for each operation, the earlier we have to add something like scrollbars around the widgets, as can be seen in the video.So I've made a few mockups to test alternatives. But first, let's have a look at how other file managers do it.
Nautilus / Finder
The progress dialog used in Nautilus is almost a 1:1 copy of the OS X Finder progress dialog. It too follows a three-line design with the first line either showing how many files are being transfered (e.g. Copying 2 files to "Desktop") or what files is transfered at the moment (this is what you can see in the screenshot below, which I am shameless linking here from Bob Peers' weblog). The second line contains the progress bar and a cancel button without any text and the third line shows some stats, again shown in the screenshot.
Now, the problems of this dialog are quite obvious (although not everything can be seen in the screenshot). If you're transfering more than one file, it will be almost impossible to figure out which of the progress views corresponds to this operation unless you know exactly how many files you're transfering and/or how large these are in total. Another problem is that the dialog grows and grows with each operation added to it until it finally grows beyond the height of the screen. Last but not least the progress bar and button heights are different, making the dialog look slightly unpolished.
Dolphin
I have to admit, this is a poor comparison. I couldn't find a screenshot of Dolphin's progress dialog on the net and I'm too lazy to install KDE in a virtual machine. Suffice it to say that I'm not a big fan of KDE GUIs in general. I think the KDE folks have a lot of great ideas but as nice as plasma and all that 4.x goodness may be, most of the windows and dialogs are too busy and cluttered for my taste.
Thunar Experiments
The original design can be seen on vimeo.
The first attempt of an improvement is the equivalent to Nautilus and Finder omitting the statistics by replacing them with a simple <time> remaining text on the progress bar. Like the Nautilus dialog it doesn't display the name of the current file when an operation includes multiple files. This is not shown in the screenshot, because that one is just a hard-coded mockup. All in all, this design makes it even more unlikely to find a job with multiple files again at a later point due to the left out stats.
The second mockup appends the number of files involved to the title (e.g. (1 of 2)) and because of that, it can always display the name of the file being transfered at the moment. The downside is that this of course requires the user to read more text.
Ideas and Opinions?
I'm not 100% sure which way to go here. I kinda lean towards the second mockup but since Thunar is designed to have no redundant options/elements in the GUI, I'm wondering whether the (1 of 2) isn't too much already.
What do you think? Any opinions or ideas for improvements? Sketches and descriptions are very welcome!
Comments
I really like the mockups and would prefer #2, because it's "more" information - but not too much.
(I even would like to see a x mb/sec statistic - but that could be overload ^^)
Thunar's one is worse than nautilus' because it contains less information, uses longer words (what's wrong with "2 min left" or "31 sec left"?) and black font is poorly visible on dark or black progress bars.
I'd go for number two because of the advantages, well, that you mentioned. I don't really consider it too cluttered. I'm not even sure whether you should be too worried about the scrollbars, because most of the time people aren't going to do more than three simulataneous operations on large files anyway, so as long as there's no scrollbar with three or less operations that shouldn't be a problem.
Some of tomas's problems are also invalid. Less information isn't necessarily bad (you don't want any information overload, and I presume if people really, really want the information you left out, they can do it from the CLI or whatever).
Also, using longer words, especially considering how there is enough space in the progress bar for that, is better than abbreviations because then the user has to convert that to a whole word in his head again, which means it involves an extra thinking operation as opposed to being able to quickly absorb the information. I also don't really see an advantage to using abbreviations here. Furthermore, whether the colour is visible enough really depends on the theme you use and of course has nothing to do with Thunar.
Interesting to see this process of developing a progress dialog :)
@tomas: As Vincent said, abbreviations are a bad idea in general. Thunar leaves out some information on purpose because it's written and maintained with simplicity in mind. We don't want to expose too much to the user. Does any novice really care about the MB/s rate or the exact MB that have been transfered so far? I don't think so.
@Vincent: I fully agree.
I've more or less decided to implement a third mockup:
http://en.zimagez.com/zimage/screen...
I think that might help in understanding that an operation includes more than one file. And it moves the "1 of 2" into the progress bar as it feels like a different representation of the percentage visualized by the progress bar.
About usability, but on a more technical matter, what about giving the file transfert lower IO priority ? That would improve the perceived responsiveness during the transfert.
Something equivalent to :
ionice -c 2 -n 7 cp bigfile Desktop/
That could also be of use on other process (thumbnails building, etc).
" whether the colour is visible enough really depends on the theme"
Ok, but it will still look ugly if the progress bar is black/dark and half the letters on the progress bar will be white, half black. Have you considered that?
"abbreviations are a bad idea in general"
Ok, you can use seconds and minutes instead of secs and mins, but what's wrong with left instead remaining?
hi, I really liked the the third mockup you did, but I believe it would look better if the cancel button was an only an icon (no text), that would make it less cluttered
also I favor the "x time left" text in the dialog, but that won't affect me that much as I use spanish locale on my computer :P
Can you "stack" files going to the same directory ?
On your screenshot, we have (1 of 2), (1 of 2) and well... (1 of 2). If you merge all the files going to a single directory, you will only have on line to display, with (1 of 6). Even if it doesn't resolve the problem when you copy files to many diffrents directories, it could help in some case...
@Faelar: Unfortunately, that's not possible. The screenshot example is a very bad one. I don't expect people to copy the same files to the same directory over and over again. Merging separate jobs with the same target and type (e.g. copy, move, delete) would require a lot of changes in the source code.
There's also the problem that people might want to cancel one copy operation to "Desktop" without cancelling a second operation copying to the same folder. In this situation, your proposal wouldn't work.
Just one comment about the third snapshot (this one: http://en.zimagez.com/zimage/screen...)
Please use "em-dash" (Unicode U+2014, HTML —) instead of double dashes "--".
Also, how about adding a "Pause/Resume" button at some point? :)
@anal typograhy dude: I'm a little anal about typography too, so yeah, of course a real dash will be used instead of "--". Pause/Resume is a little tricky and will have to wait.
One thing I like better the nautilus' team did it: the information how much one is copying/moving. This helps, when moving a lot of files simultaneously to cancel the 'right' transfer job (if one really has to). Otherwise it is hard to tell the difference between the operations, even if the number of files is shown.
And another thing I don't really know where to put it and if gio subsystem can handle this, but that seems related at this point: conflict handling when existing files are going to be overwritten. Nice information would be date-time, and if the files are the same (checksum comparison). Is there anything in the pipeline?
On Dolphin it runs in the background, always. It shows up in the KDE notification area actually, and I have to insist on the "KDE" cause a click on the icon can hide/show the notifications, it's different that what you could know from a libnotify daemon. In fact it has its own daemon knotify4.
And also, the notification once showed can be expanded but lets take the screencast, will be easier to get the idea of it :p
http://www.youtube.com/watch?v=7YGp...
OK here is my opinion. I also like the third mockup.
I think no text in the buttons is also a nice suggestion, and adding a "pause/resume" button sounds great.
The choice of words is important, so "left" even if less polite is better than "remaining" (though again I'm also Spanish, but the same goes for the translations: "Queda 1 minuto" is preferable to "1 minuto restante").
I personally don't see any problem with abbreviations. I think my brain can deal with the translation from sec. to seconds without any major struggles.
I also like the idea of showing the total amount of data being copied/moved. Saying "1 of 2" is good, but can give the idea that you are half way through, however it's not the same 1 of 2 when the two files are the same size (say 4Mb each), or when the first file is 4Mb but the second is 400Mb.
And just an extra idea. If the aim is to save space, what about making the bat just slightly thicker but fit the two lines of text inside? (or make the text smaller to make it fit in).
Take a look at teracopy:
http://www.codesector.com/screensho...
So, what is it going to be then?
Any final decisios or new proposals?
Very beautifully defined. Thanks a lot for the share. Good post.