AUG
28
2007
|
Tabbed, Context-Aware Application's WorkspaceThere's enough of meat committed to SVN so it's time to show you something those involved in Kexi have been waiting for: tabbed and context-sensitive style of application workspace. It honours Fitts' Law-friendly-KDE 4's-large-toolbar mode, while still is aimed at tools accessible for power user and development environments like Kexi. Tabs A switch from 1.x to 2.x series of the KOffice suite appears to be significant jump in technology. I hope users will also notice actively changing look and feel of the particular applications. In case of Kexi 2.0 -- it already differs very much from the previous series, to accept new challenges. The main visible change is absence of main menu. To rock in more areas, Kexi 2.0 needed a way for grouping global commands. A construction currently called Tabbed Toolbar allows that now. As you may recall, I have had some fun showing the idea of grouping actions using tabs is not MS' invention. It's rather best known from Borland tools. What I proposed after weeks of development if a mix of tabbed toolbars and local toolbars, so there is clear separation between global action and context-dependent stuff.
First, I'll give you example why groups visually distinctive could be usable. In Kexi 1.x there is "Project->Import->Table Data From File" action. So, the action itself (QAction::text()) is called "Table Data From File". Not very informative, as soon as you use such actions out of context. On the other hand changing this to "Project->Import->Import Table Data From File" could make the submenu chain bloated. So instead in 1.x I've been using tooltips to store reasonable full name (here it would be "Import Table Data From File"). In 2.x with toolbar groups, the action could look as presented below:
Of course there is one actions per group now, but this way we can add more import types still saving expensive screen space. In addition, tabbed toolbars can work with extensions -- including those delivered by plugins -- where we did not know how the traditional set of toolbars would look like with all those new actions. Custom actions can be merged in the new GUI, and hiding groups of actions is smoother and more obvious. Using so-called User Mode, where most of editing actions are visible during the whole application's session, the applications created on top of Kexi will look so simple that it will be easy to confuse it for a C++ app written from scratch. One night Aaron suggested tabs could have set up an auto switching on mouse over after about 0.5 second-long delay. Dealing With Context Fast forward to Kexi 2.0 alpha 3: the new Oxygen style makes tabs and panes look differently. The Kexi's 2.0 main window solution, still being subject for extensions, context in which you're working is honoured. For example, Kexi 1.x provided views where you can switch between Design View, Data View, and sometimes Text View (e.g. for entering SQL query statements). At the time, a group of two or three toggle buttons implementing the switch were placed on the main toolbar.
Because this frequently used action group was not about any global change, the buttons are now placed within the window's tab pane itself they belong to. Note: do not confuse toolbar tabs with main workspace area's tabs containing windows.
I am convinced that this change gives:
Actions like "Save/Cancel Row Changes", "Sort", and in the future - advanced combo boxes for data filtering - all this is now placed within a given window. Visually means that these buttons are often multiplied if you have opened many windows, but the action model is shared of course. (I'll tell that you personally I like more the way how the tabbed toolbar looked like with original Oxygen style - presented on the very first picture. Hope that contrast and focus hints in the new version will be finally better) Moreover, windows that have no idea about text mode at all (i.e. anything but the Query Designer), simply do not show "Switch to text mode" button now. These special designers have in turn many actions unique to them. How this looked like in Kexi 1.x main window? A number of buttons or menu actions, most of the time grayed-out. Summing up, the new iteration of Kexi follows quickly changing context and supports task-based interaction. It's nicely visible when you look at "Create" tab (see picture below) that has been put in place of old "Insert" menu. In theory it was not clear at the time why Insert does not contain "Insert row" action. Now actions related to rows (records) can be grouped in "Data" tab and local toolbar. And the very last, a typical session with many windows opened and "Kexi" toolbar's tab.
This is my current proposal for place, a bit inspired by similar menu in Mac OS X. I simply needed a way to remove "Help" tab because "Help Contents" and "What's this" actions have been moved to upper-right area for better discoverability. To answer how do you like it, you may want to try the interface on your own. (Links to images updated on 9th Feb 2015)
|
![]() |
Comments
Ribbon effect
Whoa... that ribbon effect looks *so* much better with the old Oxygen style. Not sure how it would work in practice (perhaps too bloated), but it looks really futuristic at first sight.
s|tab
So dialogs with a lot of tabs are not considered a good idea usability-wise, but a tabbed application we shall fancy now!?
Re
> So dialogs with a lot of tabs are not considered a good idea usability-wise
Do you mean a mess with multiple rows of tabs as in MSO 97 config dialog? This is definitely bad.
--
regards, Jarosław Staniek
KDE4/KOffice/Kexi development
Funny that..
So first you slag off MS Office for implementing the ribbon interface, alternately claiming that it is nothing new, and that it has lots of problems, and then you go and implement the concept yourself?
Personally I think it's a great idea, and can't wait to see it used more often (or have it as a widget in kdelibs), but this seems pretty ridiculous. Let's recall what you said about the ribbon concept. It wastes space, it spits all over your users' muscle memory, it's an interface for "retarded folk", doesn't work for power users' apps, etc. I think your final thought is particularly ironic:
"Summing up... I would rather think twice before starting to copy Ribbon GUI for an KDE app. If it's a simple app, sure, we can give it a try. But please leave an option to switch back to menus (hmm, but then for which GUI version will you prepare user's documentation?)."
So who goes and does just that? Oh it's you, and without even the smallest admission that you may have been wrong about your earlier views. Lets give credit where credit is due. Yes, not all of the ideas in the Ribbon are new, but the implementation was unique at the time, and it seems to be a good idea (after all, even you seem to think so now).
Back in 2005...
leos,
Thanks for your input. At the time (2005) I only have seen beta version of MSA2k7 (I even called it 2k6..). That said, however, many of my notes are still valid. For example there are many icons in MSO, and especially MSA, that are very similar each other ("table" looks like really beloved icon; see http://kexi-project.org/pics/blog/tabtoolbar2k5/msa_external_data.png) and unless you maximize the window on large screen, the buttons contain no labels other than tooltips/"what's this".
Today I would not use parody to describe this kind of interface, since I've been looking for a solution for Kexi (as development tool) where menus are dynamic, can be complex and can be edited by users, what's quite different compared a document-based apps like KSpread.
What's a bit different in Kexi's way: as mentioned in the blog entry, actions are pulled down to local areas/panes where these belong to. Keeping global actions in the tabbed tab and pulling local actions down already helped me to get more robust interface. Now my mouse pointer has less to do.
Regarding menus, I am also thinking about providing a fallback-to-main-menu as an option for users, But not before 2.1... The user handbook would still refer to tabbed toolbars, I guess.
Summing up, I think it's good we all can learn about possible traps by looking at other implementations.
--
regards, Jarosław Staniek
KDE4/KOffice/Kexi development
Ok
Fair enough. I think MS went a bit overboard with the ribbon, forcing it to apps like Access where it doesn't make as much sense as in Word.
The local actions in local panes idea is something I've been playing around with in my own apps as well, and I think the way you use it in Kexi looks very intuitive. However, what about keyboard navigation? If the action is not in the main menu, how can we get there without a mouse?
keyboard navigation
"However, what about keyboard navigation? If the action is not in the main menu, how can we get there without a mouse?"
Tabs in the toolbar have accelerators as in menu. Project pane/Main pane/Property pane need the same shortcut as in 1.x version. Toolbar items will most likely be activated by pressing CTRL and a letter, as in Konqueror's accessible mode for links (oh, that's another small thing MS did similarly to KDE... well, that's how computer science evolves ;) ).
--
regards, Jarosław Staniek
KDE4/KOffice/Kexi development