Correct use of Ribbons in Windows program

Question

I need some advice on the correct use of Ribbons in desktop applications. The program I'm working on is for a clinic, I have done a simple mockup below to make it easier to visualize.

My client wants the names of the patients listed down the left (shown below), when the user clicks a patient the tabs in the main area are related to this patient. One of the tabs is called Medical History, here we need to include Add, Edit and Delete buttons.

My problem is I feel these buttons should be in the ribbon but if I do that and the user is on any other tab (e.g. General) then these buttons don't apply to these tabs only to the Medical History tab. The General tab contains the patients name etc.

Is having the buttons on the tab as shown below acceptable? Any suggestions?

Answer 1

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.

Answer 2

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 only when needed. For example, the Picture Tools tab is shown only when a picture is selected.

Ribbon architecture is:
^{(click to display full size image)}

So, a Ribbon title (Tab) plays descriptive role and encloses its contents, creating logical structure of command controls. Pay attention on hierarchy: title and contents. Visual hierarchy creates sense.

Possible Ribbon usage in you interface could be as pictured:

But this option requires to set Medical History as the Ribbon title!

Actually, your current design of Medical History implements the idea of contextual-dependant controls, which is the one of the point behind a Ribbon control. The Medical History tab includes contextual controls for processing its content, so this is acceptable solution.

Also pay attention, a patient could be occasionally changed while interacting without noticing. This is a possible source of errors in the current design.

Answer 3

Well, one thing's quite clear: they shouldn't be in the ribbon (by 'ribbon' I assume you mean the large tabbed area at the top). The Add, Edit and Delete buttons pertain to the patient record at hand. The ribbon in your mockup seems to be for higher-level tasks. Having the buttons there not only takes the user away from the data, it also forces them to mentally jump back up to a level of the GUI that doesn't even correspond to what they're currently trying to do.

You could have two layers of ribbons, perhaps, to avoid the problem described in your question - but that would be confusing and a waste of screen real estate.

Here is a quick and dirty MS Paint edit of your mockup. It's is far from ideal*, but perhaps consider something like this instead?

*for instance, after making this I realized you'd want the patient/appointment tools to be more visible given how frequently they're used; perhaps keeping them as always-visible buttons at the top right of the screen?

Answer 4

I am not sure that a Ribbon is a good choice for your design. The situation in which Microsoft created the ribbon was: there was a single view in which the user can operate (the view contains an open Word document or Excel spreadsheet) and there were hundreds of commands, all of which are valid within this single view. So they kept the main view unchanged, but let the user switch between ribbons.

There is indeed the context-sensitive ribbon which gets shown when a user has selected a Table or Graphic or Chart within the current document. But there is still no switching between views, there is just one more valid ribbon for the current view. When you have added a Table in Word and the table is active (the Tabellentools ribbon is accessible), you can still switch to the Start ribbon and use the button for changing the font color, as if you weren't in a table at all. The view still hasn't changed to some kind of different "tab" with different data which have a completely different set of valid actions.

Your situation here is radically different. You have different views, and they don't seem to have common actions. The actions which can be completed are specific to each view. This makes it more logical to have the controls for them coupled with the view, not always accessible on the top. If you had dozens of actions within a single view, it might have made sense to enable the user to switch between multiple ribbons per view, but this doesn't seem to be a problem here.

From this, I would say that the ribbon is the wrong tool for the job. It does not intuitively fit with the structure of your application. But if you still want to use it, you can follow Microsoft's example. But you shouldn't be imitating Word, you should be imitating Outlook. This is the Office application in which there is a switch between completely different views (mails, calender, contacts) with completely different actions. Notice how the tab selectors are in the lower right corner, not on top below the ribbon - this intuitively separates the actions in the top horizontal ribbon from the navigation, and maybe even spares the user a disorienting visual experience while the ribbon switches from the "E-Mail" ribbon to the "Calendar" ribbon.

Note that personally, as a user, I am unhappy with Microsoft's decision to mix view-specific ribbons and common ribbons. The Start, Folder and View ribbons are available in all views (but with different buttons) and works on the elements in the current view; the Send/receive ribbon is available in all views, with the same buttons, and always acts on e-mails. As Microsoft usually does extensive user testing, maybe I am an outlier here, you should decide for yourself if you want to follow their practice or not.

Answer 5

I would not do Ribbon. What I would do:

1. Have a toolbar with buttons "New Patient", "Add Patient", "Add Appointment", "Settings".
2. Above the patient list, add a drop-down list with ["All Patients", "General", "Surgery"] (I feel like "All Patients" might be convenient in some cases). If you have strict 1-to-m relationship between patient and department you might want to consider something like accordion control.

This way, you will have the whole window dedicated to the patient view.