33

Hello, I‘m implementing the Ribbon UI for KDE4.
Also plans to provide MainWindow (QGraphicsWidget and QWidget) for both more complexed plasma applet and normal QWidget based applications to make them able to share the beauty/power of plasma and krunner.

I need some more ideas, criticisms, suggestions, mockups

What it looks like currently (under kde 4.3 air theme)

First row is tabbar, a button(to select krunner syntax), a line edit (krunner related).
Second row is the Ribbon menu,
The remaining area is central widget (and optional Dock, Drawer, Statusbar not shown/implemented yet. );

You can see detailed descriptions and more pictures on my blog:
http://qiacat.blogspot.com/2009/04/ribb ... at-ui.html

wkai wrote:Hello, I‘m implementing the Ribbon UI for KDE4.
Also plans to provide MainWindow (QGraphicsWidget and QWidget) for both more complexed plasma applet and normal QWidget based applications to make them able to share the beauty/power of plasma and krunner.

I need some more ideas, criticisms, suggestions, mockups

What it looks like currently (under kde 4.3 air theme)

First row is tabbar, a button(to select krunner syntax), a line edit (krunner related).
Second row is the Ribbon menu,
The remaining area is central widget (and optional Dock, Drawer, Statusbar not shown/implemented yet. );

You can see detailed descriptions and more pictures on my blog:
http://qiacat.blogspot.com/2009/04/ribb ... at-ui.html

Well I have mixed feelings about it. I did read your blog, I understand that you don't wish just to clone the ribbon menu but KDE or rather plasmafy it.
But the question is, do we want to build on it to start with?
I'm all for plasma-kind of menu that would make KDE more usable, but I wonder if Ribbon is a top of the line usability menu.

Anyway I'm quite astounded and sad that nobody added any feedback at least if not build-up on this idea.
Your mock up does look interesting and I do believe it's a starting point. Me as a more do-it-yourself kind of guy I would like to see that there were more
"menu widgets / plasmoids" to choose from.

I never actually used ribbon menu. I used Windows XP with Open Office, before switching to Linux, so I never had chance to use Ribbon menu.
I did try Windows7 which has a Ribbon menu implemented in most of the apps, but I didn't use it that much, and when I did it felt "wrong".
But that's just me.

Hope that helps at least in some way.

Is it an exciting feature?
It is a tab-widget containing toolbars.
Is XML-support an exciting feature?
There is uic.

Cool idea and I would love to see this happening. I'll post some mockups later.

(posted this on your blog as well)

What I disliked immensely about MS office's ribbon interface: sure, it's a what-you-see-is-what-you-get method and doesn't hide anything, but half the time you don't even know what you're looking at or looking FOR. MS Access in College was a nightmare for this.

It does feel far too space-consuming for me. If a ribbon-like interface be integrated into KDE at all, MAKE IT OPTIONAL!

The reason why the current toolbar UI has survived so long is the same as the reason for the keyboard/mouse surviving: the toolbar is easily one of the best methods of giving users quick access to actions. Simple as that.

I'm also a huge fan of the way Koffice 2 is heading. It gives me the option to show anything I need, hide anything I don't and store away anything I only really use on few occasions (in the form of named tabs) (though maybe that's a little biased, because I am also a fan of the new flake shape system: it just seems so genius, I don't know why no-one else has thought of it before...)

P.S: If it were my choice, I'd make this optional at compile-time. Switching to and from a ribbon interface just seems infeasible. Of course, that would make it a little harder for distros (Kubuntu ribbon AND Kubuntu traditional?), but I don't think to as much of a degree as it would for users to switch too-and-fro.

Madman wrote:P.S: If it were my choice, I'd make this optional at compile-time. Switching to and from a ribbon interface just seems infeasible. Of course, that would make it a little harder for distros (Kubuntu ribbon AND Kubuntu traditional?), but I don't think to as much of a degree as it would for users to switch too-and-fro.

I'm not so sure about that. How about an option in Systemsettings/Appearance to turn it on and off globally, together with other options that may or may not be wanted by the user (such as an MacOS X toolbar if/when one apart from Xbar is available)? And if it's turned off, programs that uses it would default to the usual toolbars instead.

What I hope won't happen is that, when it's good enough to be used, is that some programs will choose to use it and some won't. What can I say...I happen to be a fan of consistency.

XBar is available if you use Bespin.

bcooksley wrote:XBar is available if you use Bespin.

I know it is, but nothing should be dependent on the style used. Besides, it was just an example.

Kryten2X4B wrote:What can I say...I happen to be a fan of consistency.

Consistency is good. :P

Of course, this option would also have to be disabled for Mac users anyway...

I always hated the ribbon in Office 2007, it took me forever to find some commands, the tabs don't map to menus' accelerator keys from earlier version of Office (it took me some time to even find that the ribbon is keyboard accessible). I was lost completely when my college switched to Access 2007 a year ago, in preparation for switching to Office 2007 the year after I graduated. Of course the fact that some of campus computers are still at at 800x600 helped, it's useless at such a low resolution.

But every newbie I know who's never used Office before finds the ribbon to be easy, and feels confused when given an older version of Office to work with.

I like your work though! If it has to go in some KDE apps, make it optional.

I gave a lot of thought t this idea, and I came up with modular menus.

Let's say that you would be able as user / distro developer / packager to determine what you or your user base need or doesn't need in menus.
Many times KDE is criticised by Gnome users or anyone else that it gives too much choice to user. So we do give choice to user, but not just to user but also
to distro. So you could rearrange menus in your liking.
Now KDE has quite a lot of menus options and right click actions, that for you and me make perfect sense, but a new user might be overwhelemd by it.

Let me give you example:
Konqueror it's one of most noted KDE apps and represents the KDE philosophy.

KDE default menu has all the powerful options of Konqueror, both as file manager and browser and beyond...
But
Kubuntu has the philosophy one app does one thing only. So Konqueror is just a browser for Kubuntu.
So with modular menus Kubuntu devs could "remove" all unnecessary options, like split window or terminal. This could still be brought easily back by
"seasoned" KDE user, but default would do what it Kubuntu devs would intended it to do. Not necessarily what I written, but still.
Or
OpenSuSE is known to apply their patches, backporting features and so on, so they could add a menu for a feature which exists, but has no GUI yet as it's in
development.
And
In distro like Arch user would get KDE vanilla menus and then decide what he or she wants and what not.
Well same goes for all the previously stated distros, but I had to make examples, to explain my idea.
It's not necessary that it will be like that.

I love the Ribbon UI. Once you get used to it its far superior to the old style toolbar/menu mix, at least for Office. Of my friends many complaint about it in the beginning but learned to like it.

I made a mockup for the search bar in the top. I hope the image is self explanatory.

lzfy wrote:

I made a mockup for the search bar in the top. I hope the image is self explanatory.

Edited so that it links directly to mock-up and avoiding the pop-up.

Thanks for all your comments and mockups.
I've redesigned it.
I'm implementing a 2D physics engine to bring impressive animation to my UI elements,
which also introduce two new physically natural mouse interactions: push sth, or throw sth. (other than drag'n drop).