Bug 120008 - Suggestion for new menu/toolbar appearance
Summary: Suggestion for new menu/toolbar appearance
Status: RESOLVED INTENTIONAL
Alias: None
Product: kde
Classification: I don't know
Component: general (show other bugs)
Version: CVS
Platform: Ubuntu Linux
: NOR wishlist
Target Milestone: ---
Assignee: KDE Artists Mailinglist
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-01-12 22:40 UTC by el3ktro
Modified: 2020-09-29 00:05 UTC (History)
7 users (show)

See Also:
Latest Commit:
Version Fixed In:
firefox: Usability+


Attachments
Konqueror when you open it (48.54 KB, image/png)
2006-01-12 22:42 UTC, el3ktro
Details
Konquerors "View" menu (46.93 KB, image/png)
2006-01-12 22:42 UTC, el3ktro
Details

Note You need to log in before you can comment on or make changes to this bug.
Description el3ktro 2006-01-12 22:40:50 UTC
Version:            (using KDE KDE 3.4.3)
Installed from:    Ubuntu Packages

I'm suggesting a new way of how to present menus & toolbars to the user. The way this is done now is not very satisfying to me. Most KDE menus & toolbars are a complete mess, apps like Showimg or Konqueror are horrible when it comes to usability - at least when it comes to menus & toolbars.

What I suggest is a mixture of menus & toolbars. For example, in Konqueror,you have the menu bar (File Edit View ...). Beneath that, you have the standard web browsing toolbar (back, forward, reload/stop, adress ...). When you click any of the menus, say "View", you don't get a menu popup, instead the toolbar beneath it is replaced by a "View" toolbar, presenting you icons that change how you view the website (fullscreen, font size etc.).

The main goal would be to slim down menus & toolbars, because as I said they're really a mess imho. Another neat thing would be that you could add some configurability to this toolbars. Common configure tasks could be done in the toolbar, like allowing/disallowing popups as shown in the second mockup I've made.

I think this could really improve the KDE experience, I think a good UI is a UI that doesn't get in the way. Today it seems that many KDE devs think that a good UI is a UI that gives you all functions of the programs with only one click - the result is overcrowded toolbars & messy menus. It's astunishing when you compare some KDE apps with Mac OS apps, like Mac OS' address book & KDE's address book, or KDevelop & XCode. Compared to the KDE apps, the Mac OS apps look much more polished & clean, they look much easier, but yet they offer nearly the same functionality, only that they are much more intuitive & pleasant to handle - because the UI stays out of the way.

Well, look at my screenshots and please give me some feedback!

Tom
Comment 1 el3ktro 2006-01-12 22:42:15 UTC
Created attachment 14230 [details]
Konqueror when you open it
Comment 2 el3ktro 2006-01-12 22:42:55 UTC
Created attachment 14231 [details]
Konquerors "View" menu
Comment 3 el3ktro 2006-01-12 22:43:33 UTC
Sorry I marked this as "bug" instead of "wish" - can this be changed?

Tom
Comment 4 Gilaras Drakeson 2007-04-19 16:28:00 UTC
Like the top menu at www.apple.com? Nothing new, but can be usable. Example behavior: when you click on "view" the view horizontal menu appears and covers the default horizontal menu. Then, when you leave the area after e.g 0.5-1 sec the default horizontal menu reveals.
Comment 5 David 2007-08-20 22:11:57 UTC
That's useful, because if you want to change multiple things you don't have to open the menu again (cuz now it closes every time you change something).
Comment 6 pinheiro 2009-01-12 15:12:59 UTC
this is not a bug for the kde-artists, and most of those mocks are not codable I think, not with qtstyle at least...
Comment 7 James Richard Tyrer 2009-01-18 12:37:27 UTC
Re: Comment #6

Perhaps you miss the point.  It is not about style, but rather about substance.

This is an interesting idea that would certainly cut the clutter.  OTOH, the idea of having toolbars is to have operations available as one click.  So, I don't see this as replacing the toolbars but rather as an alternate way to display submenus.  There is a potential issue there as well since some submenus are rather long and would not fit in the width of the screen.  I note that some non-KDE applications do work this way, at least to the extent that states are entered and new toolbars appear.

It looks to me like this would require additions to Qt for it to be possible.

IAC, I have changed this to a KDE, General issue but I am not confirming it.
Comment 8 Fri13 2009-01-18 15:11:01 UTC
Current (old) menu and toolbar working way, allows user to browse all menus and submenus with one click. You need to click one menu open and then just move mouse cursor to from menu to other. The menu is active as long until you click somewhere else. 

Bad side is that you can click only one function by time. But because most of the actions (if not all) on menus are such that you can not use them than once, like opening a configuration window on konqueror, you do not need anything else than get that open. There is things what needs other click to complete task, example the copy --> paste. But if there is only a 3 functios what needs other time to go menu, I say we do not change the way because then the all other functions would not work correctly.

The suggested (new idea) menu and toolbar would need more clickin but not so many if having such hovering function as current has. The problem is that we have most important functions shown on the toolbar. When user is using konqueror, he needs buttons back, forward, refresh, addressbar, go and "closed tabs" button and mayby "print" button too. If user opens "Edit" menu. These buttons would get hided. 

If user then clicks the "Copy", the menu does not hide. When user clicks the area where gets the buffer being pasted the menu is still shown. When user clicks the "paste" button, the menu is still visible. Now if user wants to get other functions back, after sended the form. He needs to click new button to switch the default toolbar, because the "Edit" toolbar is hiding that. So the user needs at least 2 clicks to show and hide the menutoolbar. 

If we remove the need to show back the default panel, we loose the whole idea to allow easy way to copy-paste data without opening menu again. It should work by hovering. When user is hovering the menu (file, edit etc) the toolbars get changed. But they would stay as so long as mouse cursor is over menu or toolbar. Brettu small area to keep the mouse. 

When comparing that to old menu, user could move the mouse where ever he wanted on screen and menus worked on hovering, until clicked menu, toolbar, window part or any other thing on screen. 

This idea is more or less same as Microsoft Office Ribbon. (what was copied, but that is other story ;-)) And fact is, that functionality does not work on all applications. Office application functions are different than what internet browser, filemanager or photomanagemet applications has. You do not use all applications same way. Different functions are needed on different applications and one UI can not apply to them all as great as it fits to other.

The current old UI is currently the _best_ for all situations. You should get UI what is available on all applications to get a intuitive and easy usage. Not that you have own kind UI for every application. Some would use this new kind menu+toolbar and some the current etc. Just does not work.

The learning curve is deep on both of these UI's. But the current way gives more possibilities for user. If user can edit the toolbars as he wants, add any wanted function to anywhere (currently not possible to make own buttons/functions and use all functions from different groups on one panel) he gets more buttons and fucntons to toolbar. User could customise the UI to fit for usage what he usually does. 

I can have more functions on the UI than what the suggested UI could give me. But I do not need to do so, if I do not need. I can remove complete the need to use menu, because I can have all the functions as buttons on toolbar, where I have lots of space. So then I am always capable to copy-paste with 2 clicks... without need to open or close any menu before/after the functions.

What these menus needs, is checkin is the sub-menu nececerry. Example of Konqueror Tools menu. You have Kget and then submenu for it. We could easily move all the entries from that submenu to own area on the "Tool" menu.

The suggested menu does look nice, but I can not find any way to get it working as nicely and intuitive as current way. I do not take nice looking idea and forget the one what works... It is my opinion.
Comment 9 fire f. 2018-06-13 07:09:43 UTC
Would be nice to see a working demo before KDE is turned into something as horrible as Gnome !
Comment 10 Andres Betts 2018-06-13 14:28:11 UTC
So basically, the idea is to be more like Windows showing a ribbon-like toolbar in more applications? Am I understanding this right?
Comment 11 andreas 2018-06-13 22:00:26 UTC
Hi

I work on a ribbon/tabbed bar ui for libreoffice. Pro: you can show all functions for a specific workflow in one tab. Con: everything else is hidden in another tab and you have to click where this actions are.

In the end eg. MS outlook is confuse and ms paint don't have items in each tab cause there are not that much functions.

Caligra office has tabbs and a sidebar. In general the ui should depend on the app and not on a desktop environmental hig.

Kate has enough functions for a ribbon ui, but kate has only a menubar by default, cause power users use shortcuts and default users write text and if you need a specific action search in the menubar is faster than in tabbs cause read a vertical list is faster than on an icon label tab.
Comment 12 Nate Graham 2020-09-29 00:05:39 UTC
I rather like ribbons myself, but as Andreas says, this is optimally done on an app-by-app basis. In some apps, a ribbon would be super overkill. In others it.s not enough, and it more confusing than helpful.