If you implement the Ribbon, you are also supposed to implement the Quick Access Toolbar, where the user can add options they require. I find this useful in Office for example, where I can put common commands and not have to remember where they are on the main ribbon.
In this talk, The Story of the Ribbon, Jensen Harris explains how the Ribbon came to be from the old Office 2003 UI.
At this point, he mentions what he calls Command Loops: two or three commands that users often run in sequence, that should be in the same tab of the Ribbon.
We looked at Command Loops, which is if you have two commands that you use over ...
Martin Dostál conducted a study of the Ribbon interface focused on evaluating user acceptance of the new mechanism. He surveyed 117 participants of varying demographics and experience with computers and office software with the following hypothesis:
Our hypotheses were as follows:
H1 Ribbon user interface is received better by
It seems like the different options are more related with each other than that they are unrelated. They all manage "tree operation". In that sense it would make a lot of sense to combine them on just 1 tab. It would take away the need for users to constantly switch between the tabs.
The fact that you have plenty of screen real estate left is also an ...
Jensen Harris posted a number of articles explaining the design rationales behind the new (2007) Office experience, including the move to the Ribbon interface:
Why the new UI?
In episode 7, specifically, he discusses the data that went into the redesign. This isn't a usability test, specifically, but does give some insight into the thought process.
One way would be to implement a new floatable quick access area that's always visible, to where the user can drag and drop the favorit items. Hard to tell if this answer means that you have to alter your current ribbon implementation, as you don't want to.
This has the advantage of not forcing the users to always be in their favorites ribbon tab. After all, ...
For starters, I recommend reviewing the official Ribbons guidelines.
In general, though, I think the intent of the ribbon is for use as a space to expose commands, not for things like confirmation data.
In this answer, I will only consider the discoverability of features and not discuss the mere graphical design, or aspects such as the size occupied (as they are very implementation-specific).
In my opinion, there are two aspects in the discoverability of features:
The first is discoverability by the user without any external information: Just by visually ...
After thinking about this for some time, I thought panel.
Besides "bunch of speakers", a panel generally means a collection of buttons and widgets you can interact with to control things.
Microsoft hijacked the term control panel to mean System settings widgets, but a control panel is precisely this.
This would be a menu. The image would specifically be a an Options Menu.
From there it get's less specific and more descriptive. You could call it a Modal Options Menu or a SlideUp Menu for something that incorporates a description of the accompanied animation.
As far as I know, there is no standardized word or label.
The main problem with a ribbon on a website is the wide range of devices you (might) need to account for. The obvious problem is it won't work well on a phone size device, the the other problem is the size of a pixel unit (css px, or device pixel) varies greatly depending on the device. I've seen apps that work fine on an iPad but on an iPad mini become 20%...
I don't think that there are any web-specific considerations regarding the use of the ribbon. One somewhat relevant factor is that the ribbon is well-designed for the use of keyboard shortcuts which isn't as common on the web as on the desktop, but otherwise I think that all the usual considerations apply.
Actually Balsamiq uses a ribbon-like interface with ...
Using a dropdown of languages positioned appropriately on the form of course would be ideal. One - you can just add more languages to the dropdown in the future. Two, you can display the language in the dropdown in native script. Three, assuming you add 20 languages in the future, scroll on the dropdown won't be an issue, whereas content would scroll inside ...
From Use the Ribbon instead of toolbars and menus:
The Ribbon is designed to help you quickly find the commands that you
need to complete a task. Commands are organized in logical groups,
which are collected together under tabs. Each tab relates to a type of
activity, such as writing or laying out a page. To reduce clutter,
some tabs are shown ...
This may be a good example of the caveat contained in the MS guidelines for Ribbons.
Generally the guidelines have this to say about duplicating items between tabs:
Here are some common pitfalls to avoid
Avoid multiple paths to the same command—especially if the path is
unexpected or the command requires many clicks to invoke. It may seem
You could hide the classic menu and toggle its display between hidden and shown when the alt key is pressed (just like Microsoft does).
Screen real-estate is important. If the classic menu would be used less, then removing it or hiding is a valid decision. You should always work towards reducing the cognitive (visual) load on the application itself. The ...
AutoCAD allows undocking of ribbons. It allows users to undock ribbons and use them as side panels. Refer to this video.
If the video becomes unavailable:
The right-click dropdown on the ribbon contains the "Undock" option.
It undocks the whole ribbon and presents it as a draggable panel (The tab titles become left aligned)
This panel is resizable and it ...
Word merge the two styles, but the dropdown is a additional menu.
When the selected option has few options, they use a dropdown, when has a lot they open a modal with the options.
I think this type of design tries to reduce the learning curve for users. Using both menus can offer many paths to the user and become confusing.
But if you want, you can perform ...
You should test this with users. But here my thoughts:
The ribbon is used interact or apply functions to the object in the main window. This is learned behaviour. By switching the ribbon group users probably do not expect that the main window content changes.
With no further information of your current issue, I would recommend doing the following:
What about an actual, simple "ribbon"?
I have an app on my phone that does exactly that:
All feature categories are available in this horizontal list, like the tabs in the Windows ribbon tabs. Once you click on one, you get into a deeper level with yet another ribbon of features.
But to be honest I think I'm not able to judge the intuitivity of this ...
I believe the standard Microsoft ribbon already applies two methods of showing 'More' options.
When the space gets tight, the ribbon groups similar items underneath a menubutton.
This is also used to expand the functionality for a single button/action.
2: Expand buttons:
In some occasions there's an expand button underneath ...
The Ribbon is a context sensitive control, and you need to move the lower tab bar up to the ribbon tab bar. While selecting a patient name, automatically select the medical history cell 1 to fire up the context sensitive ribbon tab. On that ribbon tab, implement your Add, Edit and Delete functional buttons.
Yes, there are problems with allowing a user to customize a toolbar or Ribbon in any way that they would like, depending on your users and how this customization occurs.
Allowing customization can lead a team to not spend time considering what the best default toolbar should be. When discussing the toolbar layout, if the answer is always, "well, the user ...
If you want an alternative design to the Windows Ribbon UI, you can basically follow the development trends of the three key Microsoft application UI designs:
File menu - hidden and nested navigation giving main space to the application window, which is useful for applications with many features and options to prevent cluttering of the screen space.
You should review your application and reexamine if a Ribbon is appropriate for your application.
Ribbons are not meant to be used in parallel with menus and toolbars. The opening paragraphs to the Ribbons Guidelines:
Ribbons are the modern way to help users find, understand, and use commands efficiently and directly—with a minimum number of clicks, with ...
Was your boss right to say that tabs are "actions".
No. Tabs are UI elements that do not carry out any action other than to switch between UI views. From MSDN: "Tab controls represent the tabbed manila folders used to organize information in filing cabinets commonly found in the United States." Example:
What is the difference with ribbons?
again, according ...
I don't have quantitative studies, but consider the following:
The Ribbon UI was created based on a huge quantitative research which came back with the result - if I remember correctly - that everyone uses a small amount of features, but everyone uses a different small set of those, with a pretty flat curve (if I remember well, all features were used by at ...
If you are building RIA with lots of features you have to use ribbon :). According to this discussion:
One of the main drivers behind the Ribbon was discoverability of new
functions. This was driven by research conducted by Microsoft that
indicated that a large number of most requested features for Word
actually already existed in the product; the ...
UIActionSheet is more of a way to communicate how the menu is presented. UIAltertView, for example, is presented modally, but could have the same elements as the UIActionSheet.
Having said that, if you are looking for the most generic way to describe a grouping of function/method calls the user can interact with to make the system do something, I would go ...