On the menubar
February 20, 2010
KDE developers are currently discussing whether Rekonq could replace Konqi as KDE’s default web browser. I’m glad that this discussion has not (yet) turned into a flamewar like we saw in the days when Dolphin replaced Konqi as the default file manager. Instead, people are mostly discussing whether Rekonq is up to the task it is supposed to fulfil, and many people are arguing against that (including the Rekonq developers themselves!).
As you might already have concluded from the title, this blog post is only going to deal with a tiny detail of the whole discussion. Let’s start by quoting a mail by Eike Hein on the kde-core-devel mailing list:
[Rekonq’s] user interface also strays far from the path established by our other standard applications and the HIG. You’re going to have to make a good case for why our interface standards are not supposed to apply to our default web browser.
For those who do not know that yet, “HIG” stands for “Human Interface Guidelines”, a set of guidelines provided by desktop creators such as KDE, Microsoft and Apple, which allow third-party developers to create applications which fit into this desktop just like apps created by the original manufacturer.
In one of the following mails, Eike expands on his point:
I think our HIG is really important to the KDE SC’s identity as an app platform – we’re not just a set of libs, we’re a user experience with its own set of conventions – and we should really take care to manage that responsibly and not lose cohesion.
At the same time we also shouldn’t be afraid to evolve our interfaces, of course. It’s a fine line to walk.
I totally agree. Actually, we observe divergences from the classical menubar-toolbar-statusbar concept in many applications these days. Examples include Google Chrome, Firefox and Bangarang. What do we observe?
- Web browsers tend to replace the menubar by one or two drop-down menus (see Rekonq screenshot above, or Internet Explorer 7/8, for instance). Many also move the toolbar below the tabbar, because the state of most toolbar controls (adressbar, Back and Forward buttons) strongly depends on the state of the tab.
- Media center applications abandon the menubar/toolbar/statusbar concept completely and build their interface around the video viewport and the player controls. This trend is actually not new, it dates back to the 1990s.
The central question is: Could applications from other genres could also benefit from this trends? (Now, before we continue, the disclaimer: I am in no way a usability expert or educated interface designer. I’m just an application developer with some practical experience on interface design.) From my point of view, the menubar has three key conceptual advantages:
- A menubar can organise very many actions. While a growing number of actions may be an indicator for featuritis, it is also inevitable for a large number of applications, mostly professional ones (see e. g. KDevelop, SciDAVis).
- Compared to other interfaces that may accommodate a large number of actions and tasks, the menubar saves screen estate. For example, MS Office’s Ribbon consumes more vertical space then a menubar plus a toolbar. This is bad especially for small netbook screens or other compact form factors.
- The menubar has good accessibility. It contains very much text, which makes it a good target for screenreader software, and it has a coherent keyboard access scheme across all applications (Alt key + a series of letters highlighted in the action labels, or the shortcuts presented at the right of each action).
The main problems of the menubar are the discoverability of single actions (carefully crafted context menus usually perform better), and that most of its contents are duplicates of actions that are already available elsewhere.
With the menubar having many important advantages, but also quite some disadvantages, it might be time to rephrase the central question I’ve asked earlier: Is there a way in which we can evolve the current menubar into something that addresses these problems while retaining the conceptual advantages of the menubar?
The second part is the one that I’m missing from most current concepts. Most available concepts are crafted for single applications with a relatively small number of actions and a workflow that does not heavily rely on the keyboard (at least for most users). What I’m looking for, is a HIG-compatible approach: a design that also works for applications with a big number of actions or a keyboard-centric interface.
Instead of philosophizing any further, I’m going to present a possible solution. It may not be the perfect one-size-fits-all solution, but I hope that I can at least get a discussion going, or get some code written.
If you’re regularly following this blog, you know my jigsaw puzzle game Palapeli, which has just been released as part of KDE SC 4.4. Palapeli also diverges from the classical menubar, or better: it extends the classical menubar concept. When building the interface, I noticed that Palapeli consists of two disjunct parts: the puzzle collection (basically a list of all puzzles on your computer) and the puzzle table (where you play the puzzles). I organised both areas into tabs, and just like Google Chrome moved its toolbar inside the tabs (because, as I mentioned above, the toolbar state heavily depends on the tab content), I placed the toolbuttons for both views directly inside the tabs. Now I was left with a tabbar with only two tabs, and a menubar with only two menus (“Settings” and “Help”, as provided by default for all KDE applications).
The original reason for merging tabbar and menubar was to save some space. However, I think to have found a concept which can be generalised much further:
- Apps with a tabbar merge that with the menubar. If the app has a variable number of tabs (e. g. webbrowsers), the menus are concentrated at the left, to have their position fixed at all time. Dynamic tabs pile up left-to-right just as usual. There may also be static tabs (like Welcome pages, or like the two areas we saw in Palapeli), which can be mixed into the menus at the left.
- If the number of dynamic tabs is greater than what the menubar can display, only the dynamic tabs can be scrolled, the menus and static tabs are always visible (at least unless the menubar is shrunk too much).
- Even apps that do not have a tabbar currently could consider to add tabs to their menubar. Complex interfaces could offer multiple tabs with interfaces that are optimized towards one task or towards one group of tasks.
- The tabs could also have drop-down menus, just like the classical menus inside the bar. When you click on the tab for the first time, the tab will be opened. Click a second time, and the drop-down menu is displayed. Alternatively, one can click and hold the mouse button for a short moment to get to the menu directly.
- The thing that I like most about this concept is the backwards compatibility: If the tabs do totally not fit into an app’s workflow, the developer may just use the menubar as he did before.
I’ll conclude this very long post with a simple mockup of my “SuperMenubar”…
…and an example: How would Rekonq look like with a SuperMenubar? The tabbar would be moved to the top, and the “Tools” and “Bookmarks” buttons in the toolbar would become menus again. These menus would be inserted in the tabbar at the very left to form the SuperMenubar.
The Geek Shall Inherit The Earth 
February 20, 2010 at 23:07
Please move the “menu” button before the address bar, this way it does not get “messed up” when you maximize the window. This is what I did on my branch of arora.
February 20, 2010 at 23:18
I like your concept, but I think the mockup you have posted is not very usable. For me, the best way to put menus and tabs in the same line would be to align menus to the right and keep tabs aligned to the left. If the number of tabs grow (like in a browser) they just add themselves to the right of the others, but the menus keep their place.
BTW, I love Palapeli and its name 🙂
February 20, 2010 at 23:20
Experimenting with menu bars is good, but please keep in mind that KDE SC officially also runs on Mac OS X which has a global menu bar.
For Plasma under X11 platforms there’s also Bespin with Xbar.
Whatever is done to menu bars, it should work with those desktop configurations as well. (Haven’t tried it yet, but I fear that Rekonq and Papaleli currently fail there.)
February 21, 2010 at 12:20
Mac OS is a good point.
Concerning Bespin+XBar, I’ve never tried it, and I cannot really predict what would happen. It might break, but it could also work very well, depending on how it is implemented.
February 20, 2010 at 23:27
“How would Rekonq look like with a SuperMenubar? The tabbar would be moved to the top, and the “Tools” and “Bookmarks” buttons in the toolbar would become menus again”
It is not so easy to move the tabbar to the top: it break qmainwindow layout.
Moreover, you must create toolbars in each tab. That doesn’t use more memory ?
February 21, 2010 at 12:23
I’m aware of the technical limitations of the QMainWindow framework. Palapeli’s current SuperMenubar is the most I could hack together without rewriting half of QMainWindow and QTabWidget.
I think that your questions are implementation details, which should not hinder the actual idea from being implemented.
And after all, big parts of Konqueror’s toolbars are also provided by the KParts, so for 20 webpages open, we have 20 sets of KHTML actions loaded.
February 21, 2010 at 19:27
“Moreover, you must create toolbars in each tab. That doesn’t use more memory ?”
I do that for Kexi e.g. http://www.kexi-project.org/pics/2.0/alpha12/kexi-2.0-alpha12-forms2.png. QWidgets are not really expensive compared to the cost of painting. One toolbar is painted at a time so I cannot see a resource problem here (haven’t checked that using any tools though).
February 20, 2010 at 23:39
A big problem I have with this is it will lead to a LOT of scrolling for applications with a lot of tabs. It also doesn’t really help with applications that don’t use tabs.
February 21, 2010 at 12:25
Like every new interface, the application will only really benefit from it if the new interface is used properly. In the case of the SuperMenubar, this means moving actions from the static menus to more appropriate positions, such as the dropdown menus of the dynamic tabs. We could end up with a greatly reduced number of static menus then, just like Rekonq in its current state would only have a “Tools” and a “Bookmarks” menu.
February 20, 2010 at 23:42
This might be a good idea for some applications, which use almost no tabs. But it is a terrible idea for a webbrowser. Usually my konqueror windows have 5 or more tabs, and having a menubar merged tabs would leave my tabs with shortage of space resulting in lots of scrolling.
And in my humble opinion, it looks ugly and incoherent too, you can click on a menu to get a dropdown box, but when clicking on a tab you switch to it? That is not consistent and maybe even confusing.
I did not really like the approach in the current Rekonq either, but that was fine, because it only disturbed me slightly (no menubar).
February 21, 2010 at 12:27
See my reply to the comment just above yours for the space question.
@incoherence: That’s why I’m publicly proposing this idea before implementing anything. I’m aware that my proposal has some problems, but perhaps someone can extend on this concept to make it feel more natural.
February 20, 2010 at 23:43
You’re the fastest blogger in Heart 🙂
February 20, 2010 at 23:48
Thanks for this entry.
“””Many also move the toolbar below the tabbar, because the state of most toolbar controls (adressbar, Back and Forward buttons) strongly depends on the state of the tab.”””
Yes and this can be extended to needs of apps like KDevelop and, well, Kexi: each tab can present entirely different “content type”, and thus the collection of actions is different. If these types can be added using plugins… original developers would never know how the app can look after users customized it using the plugins. Traditional menus grow expotentially with such additions. We have seen this in Konqueror menus and context menus…
I am glad you have presented some mockups.
As can be seen at e.g. http://www.kexi-project.org/pics/2.0/alpha12/kexi-2.0-alpha12-forms2.png, we have moved actions from menus down inside the tabs in Kexi. Only global actions remain to be shared on the top, to avoid duplications and space waste. Early adopters and testers found out that the new positioning of the actions save a lot of mouse movements…
my 2c
February 20, 2010 at 23:54
Sounds like a good proposal.
February 20, 2010 at 23:55
Just one word: global-menubar. It saves screen space, it can even autohide and save some more space. Plus apps without a menubar look simply nice!
dbusmenu could possibly finally fulfill the dream of a cross-DE global-menu
February 21, 2010 at 00:30
The SuperMenubar looks way too confusing (too little visual difference between very different things) to me, but I agree that it would be nice to come up with something good…
I don’t like IE’s and Chrome’s UIs.
February 21, 2010 at 00:43
If your idea were to be realized I would have to switch to another browser. Rekonq – while it has it’s benefits in the webkit core is barely useable as it’s bookmark handling is awkward and – as you observed yourself – it lack the normal menu bar which contains a lot of the functionality in konqueror. I often use the Tools, Settings and View menus and I really like the way the image viewer or okular parts integrate – which just doesn’t happen with rekonq.
Now back to your idea: It wouldn’t work for anyone I know, most have adopted a highly tabbed browsing style in which there simply isn’t any space whatsoever to fit the menu in, I for example have about 12-14 tabs open at any time, my wife’s count could be around 20 and we both switch from tab to tab as we closely follow discussions on technically oriented sites with automated updates of the contents which are signalized by the load status of the site, so having all tabs visible at all times is sort of essential.
For me your assumption that the menu is more important than the dynamic tabs simply doesn’t hold true, in fact they are sort of equally important in their own rights. The toolbar is mostly useless (it is redundant but can be basically merged with the location bar which is required anyway), so I hope that rekonq will be sort of forced to adhere to the HID guidelines and not become the driving force behind a further alienating change in the KDE SC user interface…
February 21, 2010 at 12:31
I’m trying to not prioritize any of the three bars. I place the static menus at the left of the SuperMenubar to have their positions fixed while dynamic tabs appear and disappear.
The toolbar is not useless. It can be very useful to present common actions and guide the user through the multitude of available functions.
February 21, 2010 at 00:54
While I agree that being bold and trying now stuff is a very good thing, I don’t think I coul ever work with with an appication implementing what you proposed.
Basically, I agree 100% with Andreas, even on the Chrome issue. No idea about IE, though.
That being said, if there was an easy and coherent way to switch between the views, some people might prefer this new scheme.
February 21, 2010 at 01:07
while on the topic of HIG, ever though about having the tab bar at the bottom like in konsole? The only reason why menubar existed in browsers was because that was what everybody else was doing until chrome/chromium changed it.
Having tabs at the top wastes more time going after them than if they were at the bottom. The only reason why they are still at the top is because that is what everybody else is doing. Konsole thinks otherwise, will rekonq? or will you guys wait for somebody else popular to popularize it first?
February 21, 2010 at 05:48
“The only reason why they are still at the top is because that is what everybody else is doing.”
Yes. And it’s interesting you make it sound like you would prefer it to be otherwise: Mmmm.. let’s see… let’s make all applications different so that clueless noobs cannot even _guess_ how to run them. Then us enlightened hackers can have the machines all to ourselves!!! l33t!!!
February 21, 2010 at 07:43
@mtz: Toolbars are typically at the top. If they stay there and we move tabs to the bottom, more time/mouse moves is wasted, not less. If (to address this waste) we also move toolbars to the bottom, we would created strange interface.
Let’s also do not forget that eyeball tests show that users are more focused to the top of the screen than bottom – they start to scan the screen this way.
Konsole’s case may be different in that the terminal input line is often scrolled to the bottom, so it eyeballs are already focused on the bottom of the screen most of the time (and mouse cursor may often be there too).
February 21, 2010 at 10:32
It is quite natural to place dependent gui elements from top to bottom and/or left to right. Therefore, I don’t like tabs at the bottom.
February 21, 2010 at 02:38
@mtz: Having the tabs at the top in a browser makes sense and is better usability wise, since the majority of actions is done at the top. All the controls are at the top Locationbar, back button etc. As opposed to Konsole, where all action is done at the bottom at the command line, making Konsole a special cause.
As for the issues whit the menubar, it’s seem like looking for a solution for something that is not a problem. Simply said the “SuperMenubar” mockup, the Rekonq and the Palapeli are all inferior to the solution offered in the HIG. It’s simple, well establishes, flexible, less confusing and efficient compared to the alternatives, basicly it offers better usability. Why waste time and resources on it, just keep it and have an option to hide it to satisfy people that for whatever reason hate it. IMHO there are plenty of real and more important usability issues and functionality problems in KDE software to spend time and resources.
February 21, 2010 at 03:25
@mtz
At least to me there is a big difference between using an application like konsole, where – after some use – the input / user interaction tends to happen at the bottom of the window (e.g. type ls -al in a fairly well populated directory and look where the command prompt ends up) and a browser, where the location / address bar is typically close to the top of the “page”. (Furthermore, I tend to read longer posts / pages in web browsers in a way that keeps the center of my attention close to the top of the screen, but that’s maybe just my strange personal behaviour)
I would be interested to hear arguments from the HCI / usability crowd on these matters, though.
February 21, 2010 at 03:48
What about going one step further and also directly reusing the new KWin feature of grouping windows together with tabs. This could replace current application specific “whole window” tabs and even give more flexibility for grouping different kinds of windows that otherwise belong to the same task.
February 21, 2010 at 12:34
I do not want my KDE applications to be dependent on KWin. Without me having ever considered it, Palapeli works just fine on Windows. That’s an advantage that I do not want to miss.
(Everyone be warned, I’ll remove any comments on KDE on Windows. That’s an entirely different discussion.)
February 21, 2010 at 05:20
Very interesting idea! If this becomes reality I think the widget styles would evolve to make menu items and tabs more visually distinct, so that shouldn’t be a problem.
I have been thinking for the last 5-6 years that tabs should be in the title bar of a window, equally dividing the whole width of the window. But of course that requires changes to the window manager, running the app with a window manager that doesn’t support this would make the application nearly useless, etc…. So I guess your idea is way more realistic:) And mixing tabs with menu entries could potentially offer a more logic placing of menu entries together with the tab the actions would affect.
For example in akregator you have the “Articles” tab and then browser tabs with individual articles, menu entries for the browser part would be placed together with the browser tabs, entries for akregator itself would be to left together with the “articles” tab. And maybe the menu entries relating to the currently active tab should also be highlighted in some way (different background color or something)…
February 21, 2010 at 11:49
I think SuperMenubar looks like a nice compromise. Though I like the idea of tabs on the decoration even more. I’m glad that with Kwin 4.4 it’s possible even if apps are not designed for it 😛
February 21, 2010 at 12:35
+1 to KWin tabbing, but as I said above, an application developer can not rely on it.
February 21, 2010 at 12:28
I love Chrome-like UIs and therefor also Rekonq, so I will follow the discussion with much interest!
February 21, 2010 at 12:51
I think you missed an important point: on reason most browsers today removed the menubar is, that screens today tend to have less height (trend goes to 768 px again) and more width. And a menubar requires too much vertical space. I dislike this trend, and still use (a now rare) 4:3 screen. And I really miss the menu bar in chrome (which I use because of its speed since months). It would be nice, to be able to toggle the menubar in reqonq.
February 21, 2010 at 15:36
I think I have mentioned that. If not, I at least had it in mind. The tabbar and the addressbar are the bare minimum interface, and their layout is pretty much fixed. My proposal allows to display the menubar inside the tabbar.
February 21, 2010 at 13:17
Hi,
I think that is a good idea to use HIG, many users are too lazy to learn a new gui. But we need tailored a gui for poweruser. Is it possible to add a “profile guided UI”? So that I coud choose a GUI like Chrome,Firefox or somethink else…
February 21, 2010 at 15:35
Konqueror has some support for profiles, but it’s not that powerful because it is based on KXMLGUI framework, which closely follows the menubar-toolbar-statusbar concept.
February 21, 2010 at 13:36
for complex apps with a lot of menu entries, it could be great to have something like the plasma runner (alt-f2). Just type a few letters (“copy… “) and you have a list of related entries (“copy, copy line, etc.).
It could be nice to have several keywords associated with each action when necessary, in order to ease the action discoverability (btw, it could be the same with the plasma krunner, eg to have kpackagekit when typing “software” or “application”, or “install”…
what do you think ?
February 21, 2010 at 13:53
For me the weak part of konqueror UI is not its menu bar, but its toolbar.
When konqueror switches from one kpart to another, some of the toolbar elements remain the same, and other are added and they do not fit nicely the place left for them.
For example, try opening some web page – currenty my main tollbar has from left to righ: back/forward/up/reload/stop and some other buttons, then some free space and then location text field. But when I click on some image link, the page content becomes different and in addition to the existing toobar item image-specific elements do appear (3 zooming buttons) – they try to occupy the free space between browsing buttons and location text field – there is not free space there, so I have inconvenient popup-toolbar with zoom+ and zoom- buttons. It could be even worse if current kio would have more specific toolbar elements.
I like the way this problem is solved in netbeans IDE – see screenshot for example:
I has the following elements:
1. Menubar (which is rather thin and I do not see any benefit from getting rid of it)
2. Global tool bar – generally it is not content-dependent and it always has same elements no matter what document typ is opened inside it.
3. Tabs with local content-dependent toobars inside.
4. One more important detail – in case when same document might have different view representations, the tab contains a number of toggle-buttons to left of inner toolbar – each button swiches view (from text editor to form editor for example) and local content-depented toolbar also changes.
I really like the way this all staff works in netbeans – the ui is clean, intuitive and logical at the same time. And netbeans has very much in common with konqueror – it is designed to work with different types of documents with different visual representations at the same time, so konq could learn some staff from this positive example.
February 21, 2010 at 15:12
I have made two rude mocups for konq with netbeans-like interface – and it seems that they look much like kexi screenshot provided above.
February 21, 2010 at 15:39
I like it! This looks like a good design for Konqueror, if (and only if, IMO) we ship a separate default webbrowser. We could then focus to make Konqueror the swiss-army knife it was supposed to be, and tailor its interface towards the requirements of professional users.
February 21, 2010 at 18:04
Please don’t miss Gtk/Gnome devs…
Users use gtk apps under kde et qt apps under gnome, so this kind of change need to be a freedesktop base HIG.
February 21, 2010 at 18:07
The dumb thing with menus is they are modal, they hopelessly block whatever is running, but they still try to take up as little space as possible simply because taking up more space makes them suck more. Something is wrong with that design.
I think switching modes for the entire application makes sense in a lot more places (instead of appearing a small menu full of all the buttons that would normally be located in good places amongst the entire area of the UI).
I love to see people doing work with this part of interface design, since it has always irked me.
One issue with your design here is that the behaviour is inconsistent. For one thing, it’s normally possible to scrub along different menus really easily and it’s dead easy to back out of a menu: just click somewhere else. (Although, when an application crashes with a menu open and X continues to honour its mouse grab when the thing is hanging indefinitely, I wish that wasn’t the case). Much tinkering to be done 🙂
February 22, 2010 at 00:35
I don’t like your mockup, the distinction between tabs and menus is not visible. Worse: the tabs and menus are mixed, so if you click on one random item in that list you get a menu, if you click an other random item you suddenly get a tab-like behavior: confusion guaranteed! Anyway, it is a good idea to brainstorm about such things and try to find something that is better than the current HIG (although I doubt that you will soon find something better).
I also don’t like the current interface of rekonq. The menu of the last button on the toolbar seems to be a dump of all menu-items that cannot be put in some other sensible place; that menu should be split in at least 2 or 3 menus in order to be usable (each time that I need an item in that menu, I have to scan the whole menu to find it, and what is that slider doing there and what is its meaning???). I furthermore hate the total lack of configurability of the toolbar.
IMHO, if one uses a window manager that supports tabs, there is no reason why a web-browser or a terminal application like konsole should have tabs. The web-browser could give a hint to the window-manager that a new window should be opened in the same tab instead of somewhere else on the screen, if the window-manager doesn’t support tabs, it could simply ignore the hint. Such hinting should of course be standardized in a freedesktop.org spec. This would lead to cleaner code in konqueror and konsole, and it would eliminate the current confusion that sometimes arises when a new tab is opened: sometimes the user (read: I and some people I talked to) forgets that it is a tab and not a new window that has been opened, so the user clicks on the close button on the window decoration (now konqueror is smart enough to ask the user whether he wants to close the window or the current tab). The only kind of applications that really need tabs are IDEs like Kile and KDevelop in which one project can contain several files. For such programs a Netbeans-like interface is the most appropriate: global menus and toolbars, and the actions that are specific to one tab should be in a toolbar that belongs to that tab. A tabbed-like interface for Palapeli seems strange and unnatural to me: the collection and the puzzle-table are two things between you don’t constantly switch. When you start the program you go to the collection, you choose a game, the puzzle-table appears and you play the game, only when you’re finished or bored you want to go back to the collection and choose a new game. As you see the workflow is quite linear: collection -> play game -> collection -> play game. The two don’t need to coexist at the same time (as is now the case with the two tabs).
February 22, 2010 at 14:55
Usually the first action I do with new application is to press control+M and hide menu. How much do you use main menu? So some improvements in Rekonq style are welcomed.
February 22, 2010 at 20:04
I think there is no one size fits all solution for this, some application require a very simple and non-obtrusive ui but others need a powerful but nice to use ui.
I think there should be “Levels” with different kind of programs in mind.
From simple to complex:
Level 1: No menu, no toolbar, controls in content window, this would be for multimedia apps or the like (bangarang does this).
Level 2: No menu, simple toolbar with “menu buttons”, just like rekonq it may also have an additional tab bar (again like rekonq) and maybe even another content dependent toolbar below the tabbar depending on the apps need
Level 3: Level 2 plus docks at the side,perfect interface for dolphin it would move menu bar actions to toolbar and docks, for example moving all three views to a single toolbar “menu button” which says view, and moving all edit and file actions to another dock below the places dock (copy, paste, cut, etc)
Level 4: Level 3 plus static tab bar (which could be embedded in the toolbar) the static tab bar should separate tasks from a complex or semi-complex program into more manageable simple tabs, for example:
Kword could have 1 tab for text editing, 1 tab for paragraph formating moving and inserting things (including tables). maybe one more to advanced table editing and another for making formulas, it would be nice to also have one which opens krita or karbon embedded for making things to insert in document ( had to this lots of times)
Another example : gwenview is almost a Level 4 app it has view and browse mode, docks at the side with actions, but it has a few things in the menu bar which are not in docks or toolbar, if those things could be moved to the docks or put in a “menu button” in toolbar.The ui would be even better in my opinion,
This could be done by moving plugins to an icon in toolbar, settings and help to another one, and the 2 or 3 things in the menu and not in the dock to the docks(sort by, thumbail detail, and edit tags are the only things I could found)
This would be consistent because
– All simple toolbars would have the same settings and help menu, the same configuration dialog (each item should be configurable like in the actual one, rekonq doesn’t do this yet but it should) and the same behavior for the menu buttons and tabbar.
– Same dock configuration and moving and same docks in every app
– Same static tabs in every complex app,they should be put in the toolbar with settings and help in the right of them for consistency and simple tools all way to the left.
Note: when I say “menu button” I refer to those toolbar buttons which when pressed show a small menu.
PD: All levels could also have a status bar or another implementation of it when needed.
February 23, 2010 at 14:37
I think this discussion should be moved to kde-usability postlist.
https://mail.kde.org/mailman/listinfo/kde-usability
I hide the menubar always as I have just a change. I just love the KDE Ctrl+M functionality. Bad thing is that its not a global function. KDE devs do not want to get it added to kde libs so it is always up to every KDE apps dev to include that support.
But I do not hide the menubar because I can or because I do not need menu. I hide it because it adds clutter to the toolbars.
We do not need to use Bespin + XBar. Even the QtCurve style supports XBar. But QtCurve has own experimental Ctrl+Alt+M function, what is same as Ctrl+m. But it works on all KDE apps.
What we need to do, is to think what is good defaults on toolbar and have a easy way to globally hide/show the menubar.
Some devs, like Amarok devs do not want to hide the menubar because some people have in 1.4 series hided it in accident and did not know how to get it back. That has be fixed by prompting user in first time about menu hiding when they pressed Ctrl+M and after they have readed the information, they could just configure the warning to be always hided.
What is important in the usability, is that the GUI follows same rules in all apps. Thats why menus has survived so long time because there is no other better way to deal with them. Chrome does not have same functionality as Konqueror does. We can not compare them because it is like comparing a egg and orange.
Konqueror has multiple viewstyles, its having a file/web browsing capabilities, its having a shared views etc. It has so much functions that are only available from menu.
We can not just trohw the ReKonq there to replace Konqueror because functionalities are not there. Otherwise we should need to make a even better addons function to browser and let the users to grow the functionality with those even more. That ends up more to have 4-5 different toolbars and other problems same time.
Does anyone remember the toolbar of Konqueror in KDE 3.5? It was just a mess. All the functions were on toolbars. Same thing is used earlier on some web development apps until MS copied it to Office and renamed it as Ribbon. It is a mess. Full of functions with different sized icons, icons with text, text only, one or two or even three rows of icons and functions. HIded functions behind tabs that you can not see them right away or access them with one click or use shortcuts. Ribbon does not work well on different sized screens it hides and unhides functionalities by that. So you can not memorize well functions places.
And the Ribbon does not work well at all on other apps than write app, where it does not work well either.
Apple has kept the global menu because it has great advantaged over tabbed toolbars.
First you have all shortcuts (as mentioned here already)
Second, you can fast find all wanted functions clearly
Third, the Application window stays always clean and simple only with the toolbars with most used functions.
Fourth, the menubar is always located to same place.
The Chrome idea of tabs works well on websites. They are the content, not the toolbars. Google changed the tabs to top because normal users did not understand tabs when they were just between addressbar and website. On top they looks more like a bookmark in books. You can see right away what you have etc.
When we add hardcoded functions to toolbar, it loose its usability as well. The toolbar idea is to show a user most needed functions with one click away. Not to include all possible functions.
When we move menubar to behind one dropdown list, we loose even more usability if we have more then few functions there.
Thats why menubar is just so great because we can group the functions to one place. View settings are on one dropdown, edit settings on other and documentation on third etc. WIth Chrome kind dropdownlist user is already searching trought the dropdownlist between different functions, view, edit, help, settings etc. Groupping everything behind one button does not make it better at all. It makes it simpler but simpler is not always best choise.
I have few buttons on my toolbar in konqueror and menubar is hided.
Back
Forward
Nepomuk
[Addressbar]
Most visited sites
History
Closed tabs
I have six buttons in toolbar and addressbar. That is something what I need usually. I do not need menubar or settings anykind usually. So I do not include those at all. When I need them, I can just right click and select “Show menubar” or press Ctrl+M.
And konqueror fits very well to netbook sized screen. It would be even better if the bottom panel would be possible to hide like on rekonq.
Under the toolbar I have tabbar. With add tab | tabs. Every tab has a close button so I do not need a Close tab -button. Toolbar is with “icons only” -mode.
Even on dolphin I have hided menubar and most buttons. I can use Ctrl+1-3 to switch view and preview is on Ctrl+R (99% times I use icon view)
On toolbar I have previous/Next/New…, move to trash and searchbar. Text aside of the icons to make them bigger. Very clean and simple UI with the places sidepanel.
Same thing is with KMail, Korganizer, Basket, Ktorrent, Amarok etc. Menu is always hided. Toolbar includes only the functions what I need most times. And with that setting. I only need to access menubar with few times a month if even that. I do not need any button to toolbar to give me a drop downlist of different settings.
I can not find any good reason to start mixing tabs and menubar to one toolbar. It is intresting idea but it does not seem to work well.
I just hope that KDE could do that we change default settings.
1. Add Ctrl+M to kdelibs so every application has that functionality!
2. Design the default toolbar to be such it has all needed most needed functions.
3. Make clear to the user when first time pressing Ctrl+M that what just happened (already done!)
4. Make it very easy to configure toolbars. How to add/remove functions and how to arrage it wanted way. Even in possible way to easily add new toolbars (what user would want) and place new functions there.
5. Make it easy to assign shortcuts to some functions and have all global functions covered in first place (just like Ctrl+C/Ctrl+V).
The menus are great because it works great on every application. If application does not need menu, it does not need it. But if it does, it should be possible to hide and have a sane, great default toolbars.
We have one GUI what looks and works same way on every app and that is something what is always being better on KDE SC / GNOME than in Windows.
Does anyone remember the 90’s boom where every application had own UI on Windows? You needed to learn every UI with their “great” graphics and nice own custom ideas.
February 23, 2010 at 17:31
I really appreciate KDEs adherence to its HIG, and love to mock MS and Windows for its lack of coherence. That said, I’m interested by your proposal; I think that it’s not the correct approach, but am interested in what develops from it. I agree that a general approach, of use in many applications, is important.
One of my concerns with your approach is the distinction between static tabs, and dynamic tabs – these are very different things, having different uses, and yet displayed side-by-side, and appearing similar or even identical. Chrome’s approach with the ‘new tab’ page could work for Palepeli; maybe this is more widely applicable?
February 25, 2010 at 08:48
I dont know, if someone wrote a similar post to this one ( I did not read everything above), but here is my idea of your proposal:
You said:
3. “Even apps that do not have a tabbar currently could consider to add tabs to their menubar. Complex interfaces could offer multiple tabs with interfaces that are optimized towards one task or towards one group of tasks.”
This sounds like the ribbon interface from microsoft. But you said earlier , that Ribbon is bad for smaller screens…
4. “The tabs could also have drop-down menus, just like the classical menus inside the bar. When you click on the tab for the first time, the tab will be opened. Click a second time, and the drop-down menu is displayed. Alternatively, one can click and hold the mouse button for a short moment to get to the menu directly.”
This is something i totally disagree. Pressing the mouse and holding it to get a dropdown menu is really something the user does not know how to access the menu.
Eventually i had problems with it until someone told me to get a menu when holding (i.e. the shutdown button on the krunner dialog). In General, this is seriously an usability problem (but thats another topic 🙂 ) see: the “7 stages of action” by donald norman.
But back to your approach: My question is: would it not be confusing to the user to see a tab and next to it a menu? Of course there will be a clear difference to see what is a tab and what is a menu ( because tabs have an outer bevel and menus are flat), however would it not be clearer to separate content from actions? And how does the user know which menu belongs to which tab? (if you think “why this last question” then probably i kinda misunderstood your approach 🙂 )
Anyways…
Surely, your ideas sound really attractive and I am also not a fan of the menu bar but I think we should stick to what we have.
On the other hand, i am really pleased to talk more about this topic. (and maybe about this holding the mousebutton-problem. I already posted this on the kde-usbility list but noone answered…)
bests from berlin
February 25, 2010 at 09:56
“however would it not be clearer to separate content from actions?”
I like to separate content from actions, too, but many programs are divisible into a set of areas, each with distinct actions. Think of KDevelop for example, with its “Code”, “Test” and “Debug” contexts. Another example could be a spreadsheet application, which needs to suddenly offer a totally different set of actions when you select a graph.
The ribbon has a big advantage in that context switches are already included in this concept, and from my experience with Office 2k7, this part of the ribbon works very well. You see that you were right when saying that…
“This sounds like the ribbon interface from microsoft. But you said earlier , that Ribbon is bad for smaller screens…”
I like the context-dependent part of the ribbon. I do not like the actual appearance.
“And how does the user know which menu belongs to which tab?”
I think you’re right that you misunderstood me: In my concept, the menus hold these actions that do not belong to a certain view (like “Settings” and “Help” in Palapeli). Looking again at the concept, this might not scale up very well, but this depends very strongly on the actual application.
March 16, 2010 at 09:34
Mainly dropping by with a note to say that after all the anticipation from following your blog, getting palapeli in 4.4 was worth it. Certainly it was my the most anticipated new app or feature by far, tho a couple of the bug fixes were highly anticipated here, too. =:^)
I was very pleasantly surprised with the palapeli menu/tab interface and how well it worked for palapeli — it worked so well and so intuitively, in fact, that I had done several puzzles and was I think on my second palapeli session before I suddenly realized the tabs were /in/ the menu bar! Now THAT’s intuitive, when you don’t realize a change it until some time after you’ve started using it with no issue at all! =:^)
But while it works very well for palapeli, due to the limited number of tabs /and/ limited number of menu entries, as others have pointed out, the idea as it is here needs some work before it will work so well for many-tabbed apps like the way many people use their tabbed browsers. I’m normally quite conservative on tabs, and have a far larger desktop layout than most (1920×2400), but when I’m browsing say color-schemes at kdelook, I may mid-click-open a whole page of schemes at once, then look at them one by one, closing them as I go. With such usage, even a full 1920 width tab bar can feel constrained, and I’d hate to have menus, ESPECIALLY uncollapsible menus, taking up some of that room. And I normally browse with horizontally tiled half-width windows (and was using kwin’s per-window settings to do that before the so convenient drag-to-side functionality of 4.4), making tab space even more constrained, tho I do usually maximize when I’m doing many tabs, in part for that very reason.
OTOH, I’ve experimented a bit with a firefox extension that makes the tabs into a sidebar — which can be set to autohide, and while originally skeptical, I surprised myself at how well I ultimately liked the idea. For many-tabbed apps, that seems to work better than a horizontal tab bar, at least for me, because I can then see more tabs without constraining their title area (and because the tab sidebar, like most sidebars, is auto-hide, it doesn’t get in the way of ordinary browsing, either.
Between the two solutions, combined menu/tab-bar for limited-tab/menu apps, and a vertical tab list side-panel for many-tabbed apps, I’d find things quite workable.
Meanwhile, what about making the menubar and tab bar just additional toolbars, with the usual text placement and/or icons only options per-toolbar, and draggable docking to any side or floating. Add an auto-hide option for each, customizable width for *bars on the sides, and the ability to “stack” toolbars (custom height when stacked on the side), and that’s approaching an ideally customization flexible app. Let the /user/ decide whether he wants multiple *bars combined, and how! =:^)
Then let the HIG define appropriate defaults, so users don’t get too mixed up but can still customize their *bar layout as desired, and away we go. =:^)
July 8, 2012 at 08:52
Is this a dropdown button in the urlbar, in the first picture? A history dropdown? The current rekonq doesn’t seem to have one. *sad*