KDE4 Application Toolbar Specs
Over the past week, Ellen and I have been working on toolbars for KDE4 applications. Actually creating the specifications for popular KDE4 applications seemed easier than creating generic guidelines. There will be guidelines, but this is a more pragmatic approach to Getting Things Done. At first we thought it would be a good idea to post the new specs in the bugtracker, but I have gotten mixed results about this approach. Instead, I will post what we have so far.
We encountered some general issues with applications or KDE4 functionality which we are not sure will be included. For example, Kubuntu omits menubar items if the functionality exists on the tool bar — a big no-no. We need to take a closer look at Gwenview’s file view options and how they are designed, the Browse view is a little confusing. Zooming and size control needs a better solution because currently many applications do it differently (we are getting a consult on this as we speak). Also, there is a need for a split button to replace the drop-down buttons we currently have — Ellen has more details on this.
I realize now that we did not do the toolbar for the KMail composer. We are also planning on looking at Amarok and a few utility applications in the next week or two.
-=-=-
Split buttons are denoted by ^
(Which may or maynot replace the current drop down button with the little black arrow)
Icon separators are denoted by |
(Typically follows organization in the menubar, however this isn’t always the case)
Notes are denoted by *
(Usually to describe split button options)
KMail
New Print | *Check Mail^ | *Reply^ *Forward^ | Previous Next | Trash | Spam Ham | [User-defined Tags]
* Check Mail (all), List of individual accounts
* Reply, Reply All, Reply Mailing List
* Forward, Forward as Attachment
Konqueror Web
Previous^ Next^ Refresh Stop | Home Bookmark [URL]
Konqueror File
Up Previous^ Next^ Refresh Stop | [*View^] | [*Location]
* View should be two buttons options: Icon List. If user configures additional views, the toolbar should (can it?) convert to a split button. The individual views should be available in the toolbar configure tool.
* Location should include bookmarks to major locations such as $HOME and media locations.
Gwenview (This is only for Image view and embedded interface)
Prev Next Refresh | * Fit Smaller Larger | *RotateL *RotateR *More | [Location]
* This is pending — we are trying to find a general zooming solution
* Rotate Left and Rotate Right, respectively
* More functionality such as Crop or Flip as it becomes available or necessary
Rather interesting how “usability” sometimes tries to play stubborn revolutionary.
Notably, the return of “Up” to the beginning of the line for file browsing mode reminds me of Microsoft Office’s “ever-moving” menu items. Somehow, I always was forced to LOOK for the new location of the menu item, instead of just going to the same place.
Oxygen team did not make it any easier to distinguish the “back” “forward” “up” at a glance. They are still the same circles with some lighter dots inside. You put that, and the “ever-moving-based on context” tool bar buttons and you have a royal pain for regular users.
Try to keep consistent position of “back” “forward” “home” buttons among the “contexts”
Thus, I, as a regular KDE user too, beg of you to recommend something more like this:
http://kde.org/screenshots/images/3.5/04-konqueror-multipurpose.png
(You can swap the “Up” button with “Bookmarks” when switching between “File” and “Web” if you really want to.)
Why is the sane recommendation important, when I can easily customize the tool bar? I can’t customize it everywhere. One example is Open/Save dialog. So, pretty please, think of “regular” users as well as of “new” users while designing the ui.
thx.
The thing about “View modes”
While poking around Vista i noted how they arranged the View modes along the “Most Appealing (Huge preview thumbnails) — Most Informative (small icons, lots of text)” range.
The View button actually has a slider. It didn’t seem intuitive in the beginning, but really made sense in practice, as the View modes were no longer a disorganized “blob” of options.
In the years of using KDE it always puzzled me why there are 2 buttons for view. Some variation on Vista’s View button is probably in order.
(Vista’s db-like, multi-step view sorting is completely genius, but, that’s another subject…)
Its fine to focus on toolbar issues when looking at Amarok. But we’re quite probably going to be doing some major UI overhaul for Amarok 2.0. So any major changes you think should be made, don’t hold yourself back - at this point we know we probably want to change the UI but aren’t sure how exactly.
@Daniel D.
There isn’t anything “revolutionary” about moving the “Up” button, it just makes the most sense. Besides the fact that Konqueror will possibly be separated in to Web and File, the Previous and Next navigation controls in a filesystem context is confusing to users.
Although practically the same functionality as the web control (navigating history), conceptually, the navigation model used is different. The user has knowledge of their information management hierarchy, and does not create a “history” as he moves around his data. The Previous control is often misunderstood or misused as the “Up” functionality to navigate to the parent directory (with confusion if the Previous was actually navigating down). Next seems to retain some understanding as “history” when used to go back “down” to the last selected child directory (with confusion if the previous Next was navigating up).
Advanced users are most likely to employ keyboard navigation anyway, so this change will have less effect on them than Average users.
For this reason, we decided to move the “Up” navigation control to the beginning of the toolbar because it makes a more logical control more easily accessible. This is all dependent on the fact that Konq will probably be split. If it is not, we will revisit our design decisions.
@seele
> Besides the fact that Konqueror will possibly be separated in to Web and File, the Previous and Next navigation controls in a filesystem context is confusing to users.
Since when? It’s completely natural and works in exactly the same way as a web browser. I would like to see some evidence that this functionality is confusing. It has been in every file manager I’ve used for years and years and I’ve never seen anyone have trouble with it. Although I don’t agree with the decision, Microsoft even removed the up button and just offered the back/forward buttons in their file manager. I often find myself using the back button in place of the up button anyway, or using next/previous to quickly go between two folders. I would argue that to change button orders that everyone has years of experience with requires some pretty overwhelming evidence that it will improve things for new users.
I think a better idea would be to remove the stop button from the toolbar in the file management mode. When was the last time you clicked stop when browsing the local filesystem? Unless you have several hundred thousand files in one directory, or your hard drive is failing, you should never have to. (of course, since konq also handles network resources this may be difficult to actually implement).
@Leo
Microsoft’s file manager is where I have seen these problems during user testing. And YES — it works exactly the same as the web browser — while the activity itself is conceptually different.
The stop button is for network filesharing, ftp, and mounting remote directories via fish:// which is pretty common — especially for users who use remote ftp for a website or file storage.
Ohh…
No longer up button in web mode for konqueror ???
Thats one of those I use most : I would prefer to have Previous^ Next go than up :(
This is one of the thing that make me use konqueror instead of competitors, whith it beeing fast and well integrated whith the rest of the desktop.
At least, alow me to easily add this button to the toolbar, for any viewmode.
Please, please, just stick to
[back] [forward] [up].
This is what most people are used to, and moreover stops the most important buttons from appearing at different positions! (I’m using back more often than up, even when the two would result in the same action).
The “back” action is something that we all use at least 100 times a day. (I would even go as far as saying you generally don’t even need the “up” action, except for the case when you’ve opened konqueror at a deeper level)
The “back” action is probably a lot less confusing than “up”, because you don’t even have to know that your disk is a tree, you can just imagine that folders and files are web links
(and has the nice side effect of keeping your history working in a logical way).
Also keep in mind that most users start to use the computer for
a) internet == browser
so I feel it is wise to stick with the well known.
This might not be easy to change now as it has been the default button order in kde3, but I still think it is worth to think about and maybe even yo try out.
Sorry for the rant, but this is something that always bothered me:)
What about joining the reload and stop buttons? The same goes for the play and pause buttons in media players.
Both states are exclusive - so you could very well alternate between them: put them at the same location and save some toolbar space. Also for many it’s the same logical action (pause a movie/song for a short moment and play again), so spreading it onto different/multiple spaces is tedious to navigate, when you needn’t have to move the mouse.
When loading or reloading, show the stop button. When nothing happens, show the reload button.
Same for media players: either it is playing (you can pause) or it is paused or stopped (you can start playing).
The reloading/stop thing is in e.g. Opera.
The play/pause alternation is also in quite a few media players. However, it is not consistent which button is shown, the current state or the action which can be done.
This is probably the most critical point which could be confusing again. But as you are guidelining the HIG and if every application follows this (which I presume is your expecation if you have the slightest faith that the HIG will have an effect on and matter for KDE) some mouse-finger click training with the following general recognition that hitting the play button with the play icon will pause a track, show the pause icon, which can be clicked again to play on will do the rest.
Another pont (not) to worry about would be that an action is not always shown, or just not under certain conditions. But in this case, who is in search or even in need of the the stop button when a website is loaded and only the reload icon is shown, the stop button would be greyed out anyway.
It’s not really that obscure — who is confused that his remote control has one button with two functions: switching on and off?
The whole emphasis on “Up” button worried me for a while and I couldn’t get it at first…
My gut displeasure with “Up” navigation stems with great desire to have filesystem behave like a db query views, where files I need are virtually grouped and where there is no “Up”.
I was wrong in calling “Emphasis on UP - stubbornly revolutionary” Instead it is “stubbornly retrograde.”
The easiest way to attack a good study is to attack the constants - the assumptions. In this case, it seems your assumptions about file-management behavior of close future are anachronistic.
Please, reconsider your definition of file browsing.
Some people prefers to use “back” and some prefer to use “up”.
Daniel, I’m sure everybody has understood you p.efer “back”… Personally I prefer to use “up”.
This is 2 different behaviors, and while sometimes they can look very similar … they are DIFFERENT.
Now the question is : which is the most logical one ?
For web browsing, I think it is normal to use “back / next”, because the web is very heterogeneous and anarchical : when you click on a link, it is often on a completely different hierarchy (ex: you are on http://www.kde.org, and then you follow a link to http://www.kde-apps.org). So the concept of “history” is very useful here.
When you use a file browser, this is different. Generally your folders are quite organized, so to know where I am, I prefer to think in term of HIERARCHY than in term of history. The history will mostly help you to go to the parent or child directory, which is imho not a logical use.
Anyway, it doesn’t answer the question of where to put the up button. But there are 2 points :
- Placing the up button in first position, would be more practical for users thinking like me.
- Placing the up button in first position, would surprise users coming from other OS (windows, kde3, gnome etc.)
So how to come up with a solution ???
Here is the solution ! Suppress the “up” button, and do like Dolphin :
http://www.kde-apps.org/content/preview.php?preview=1&id=40491&file1=40491-1.png&file2=40491-2.png&file3=40491-3.png&name=Dolphin+File+Manager
:)
Honestly, I don’t understand the hatred for the “Up”-button shown by some people in this thread. The availability of this button is one of the main reasons why I switched to Konqueror (other main reasons include kparts and kioslaves). I have the “Up”-button at the left of the “Previous”-button for years, since this seems to me to be the most natural place: when you are browsing your filesystem, I more often consider going up in the directory structure than going back where I come from (even when these actions coincide). On the other hand, when I am browsing the web I more often go back or forward, but nevertheless the “Up”-button is still the most left one because I am used to finding it there (I do go up while browsing the web, because I want to know what else the website of which I am visiting a page is offering).
I do not agree at all that the “Up”-button is anachronistic (or that the tree structure of a filesystem is anachronistic). When I store my papers, I have several closets, each of them have several drawers or shelves, in each shelf there are maps containing several papers separated by a colored sheet of paper. This is a tree structure. If I have tree structures in real life, then why should I not have it on my computer? In my experience, if you know the exact or almost the exact location of a file on your computer, it is much easier to find it than to launch a search program (like KFind, Beagle or Recoll) to find it. So I prefer to have my files organized in a tree structure rather than in an unstructured database-like blob.
Something different: in the main window of KMail, I like to have the “New”, “Reply” and “Forward” buttons grouped together, since all these buttons have a similar effect: they pop up a composer window in which I start writing an email. “Check Mail” is the most left button, since this is the first thing you do when you open KMail (I never understood why in the default layout you have to look for this button somewhere in the middle of the toolbar).
When I reorder buttons (which I often have to do), I try to group the buttons that have a related functionality or that act on the same object, e.g. in KMail my toolbar looks as follows: “Check Mail | Previous Next FindMessages | Save Print Trash | New Reply Forward”. “Check Mail” is the first item since it is the first thing I do when I start KMail, “Previous Next FindMessages” are three actions that are done in a folder, “Save Print Trash” are three actions done on a single message, “New Reply Forward” all produce a composer window so that you can start writing an email. This seems more organized than the current toolbar: now “Print” is somewhere on the left and “Trash” somewhere on the right, but it is the same object (a message) that is printed or trashed. Similarly in Kate: “New Open Save SaveAs Close | Previous Next | Print | Undo Redo Cut Copy Paste | Find”: “New Open Save SaveAs Close” are grouped together (on my computer) since these are all file actions applied on a single file (the current file), “Previous Next” are actions in the current session (but not restricted to a single file), “Undo Redo Cut Copy Paste” are editorial actions in the current file. I removed the “Enlarge Font” and “Shrink Font” buttons from the toolbar since in my opinion they are useless: if you want a bigger font, then you set a bigger font in KControl for *all* widgets and not only for the katepart. In Konqueror it makes more sense to have these buttons, since some websites use unreadably tiny fonts.
I hope that the above description of my toolbars gives you some ideas.
@ Vlad
There are as many mail app tool bar layout variants as there are people in this world. :)
Thank [insert diety here], the tool bar is configurable!
I agree with Shamaz. The up button is essential for navigating the tree structure of a file system, while not as useful for the web. But it’s still nice when you are linked deep into a site to just hit the up button a couple times to go to their home page.
The up button can go away for all I care when Konquere implements bread crumb bars, like in Nautilus and Windows Vista’s Explorer:
http://members.iinet.net.au/~aaronharvey@iinet.net.au/Vista/Explorer_Mock_Up/MyPrototypeV2.jpg
http://www.widdix.de/wp-content/uploads/ubuntu-6-10-b-nautilus.png
I’d have to agree with removing stuff in the toolbars from the menus.
Menus become less cluttered, and you lose the redundancy effect.
Toolbar tooltips should show keyboard shortcuts, and toolbars could accept tab focus.
Yes if the user decides to customise his menu or toolbar, menuitems may confusingly (for the user) disappear, but only advanced users customise such stuff and they will prolly accept it. At least you’re talking a 0.5% user backlash here, which is generally what you’ll at least get with any interface policy.
I fail to see the big no-no. Seems like a positive step to me.
BTW the font on this blog is a bit tiny :)
WRT to the up button.
My girlfriend; a normal 20 something computer user, really likes the Up button. Who would have thought?