Designing a Fluent Ribbon for a CRUD Application

Question

I'm working on designing a Fluent ("Ribbon") style UX for a CRUD application working over a database.

There's lots of information about how to design a ribbon for document based applications. The Microsoft guidelines even specify standard tabs and groups.

However, these standard groups don't seem to be a great fit for non-document situations. The "Find" command, for example, should be within an "Editing" group:

Entirely relevant for searching within a document, but not for searching for a record.

What resources and/or examples are there for using the ribbon for non-document applications?

Updated 27/9: Yes, I'm sure that a Ribbon is appropriate for the application I'm developing. It's not document focused, but isn't pure CRUD either - it's a complex application with a lot of business behaviour. It'll be easier for me to run a workshop on arranging the ribbon if I can provide some guidance in advance - so I'm hoping for some answers to my original question on resources and examples.

Answer 1

I think the best example you could look at is Ms Access. All the CRUD commands are in a Records group and the Find command is in the Find group!

Answer 2

The ribbon was designed for programs with a lot of commands, CRUD application tend to have just a few commands so maybe the ribbon is not the right UI to begin with.

You can do what MS did when they designed the ribbon, take as many people as you can (that know the field, preferably customers) give then a list of tabs/groups and a few command and let them choose the most logical place for the command.

And most important, don't blindly follow guidelines (but also don't ignore them without good reason) and don't confuse your personal preference with what the users find intuitive.

Answer 3

I'm in almost the same situation that you are with my application and designing a "Ribbon" interface. I've contemplated a situation where I group commands in the ribbon based upon the core "business" object. In other words, if my app allowed users to manage Clients and Vendors would it make sense to have a ribbon group dedicated to Clients, with all of the commands you would commonly invoke and then another ribbon group dedicated to Vendors with the various commands that make sense to run against those objects\records?

As I sketched this out it became apparent (at least to me) that screen management would become very tricky with this style if I only provided a single Ribbon and would probably frustrate users more than help.

About the best UI I've come across that deals at least tangentially with this issue is the Outlook 2010 interface. Outlook relies upon a separate navigation element, but when you switch from Messages to Contacts for example, the Ribbon changes to show the supported commands for the interface you are working with at the time.

Bringing it back to your example, it would seem that Finding a particular record would imply that the user knows the type of record he is looking for. It may make sense to first have a navigation system in place so that the user could navigate to the core object (e.g. Customers view) and then be presented with a set of commands within the Ribbon that relate solely to Customers. Find may indeed be in the "Editing" group, but its context only pertains to the Customers view. You may also have another Find command located in an Editing group that relates to some other entity within the application.

Answer 4

I've been thinking about this too, and the main idea I've come up with is similar to what Tim Lentine described: having a tab for each of my main business objects. I'd put the most commonly performed commands for that object in the tab for it, for example and "Order" object might have a commands to change status (eg cancel, ship, etc), bill, send invoice, etc.

However, I've also been thinking about how the ribbon in Windows Live Photo Gallery works. In a way, it's managing a database (of photos and meta-data). Of particular interest were the Home, Find, and View tabs. I also liked the idea of the search/filter box that appears.

So these are the two main ribbon ideas for a CRUD application that I've been mulling over. I still haven't decided anything yet, though.

Along the lines of photo gallery, I might do one tab for retrieving a particular list of data and deleting, etc (I planned to make the main panel of my window display a list of objects). I might have another one for filtering/grouping (similar to WLPG's 'view' tab). I'd probably have another tab for reports. I might also use contextual tabs to perform common commands on the selected object as I described in first paragraph.

Answer 5

I don't have extensive experience in a CRUD app with a ribbon, but here's some ideas...

Read - Have one or more tabs committed to the standard ways a user would find the particular objects. For example if it were a college database one tab for students/faculty, one for classes, one for buildings. Group the objects in the tabs by finer levels like one for students and one for staff. If it is a simple field query you could put the plain text control directly, or pop up the complex search dialog.

Create - have just one tab for delete, or put it in the read tabs. If you do a separate create tab make the groups map to the tabs and add separators to make mini-groups.

Update - I would seriously consider contextual tabs for this. One context per object type. If a form has multiple types you will have to drive the context by keyboard focus. Not so much fun. You may also want these update tasks in the forms themselves, especially if they map nicely to dialog 'command' options like apply and such.

Delete - Buried in the command well, not on the ribbon by default. Destroying data is something to be discouraged. Instead encourage the user to 'archive' or 'deprecate' or 'graduate' data so it will only show up in specific queries. And those actions are generally object specific so they would live either in the forms or the contextual tabs. Let the weekly backup, archival, and maintenance tasks do the deleting.