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:

alt text

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.

  • I've been thinking about this a lot recently too. Nice question. =) Commented Oct 5, 2010 at 11:52
  • I say say if you can't do a Ribbon in a way that clearly gives LOTS of benifits then sick to menu/toolbars.
    – Ian
    Commented Oct 6, 2010 at 9:20

5 Answers 5


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!

alt text


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.

  • My application does have a large number of commands, it's just not document based; instead it uses a database as the underlying data store. In the current (non-ribbon) version, every screen defines its own menubar and toolbar, and there is a lot of repetition from screen to screen.
    – Bevan
    Commented Sep 27, 2010 at 1:48
  • Even Microsoft mentioned in the guidelines that Ribbon may not be a good fit for other uses.
    – user1948
    Commented Oct 5, 2010 at 15:15
  • 1
    See: "Is this the right user interface?" msdn.microsoft.com/en-us/library/cc872782.aspx#rightui They even provided a funny example of a Calculator app with Ribbon UI, emphasizing the incorrect ways to use the Ribbon.
    – user1948
    Commented Oct 5, 2010 at 15:16

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.

  • I was thinking about a similar ribbon design based on my business objects, like 'customer', 'invoice', etc, and then a few other utility tabs like 'reports'. I'm not sure if it's a good design or not, though. Commented Oct 5, 2010 at 11:51

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.

photo gallery ribbon

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.

  • I like the idea of having a tab per "kind" of object - thought of it too. My problem with this is that every one of the tabs would have the same "Open" "Edit" "Save" "Delete" buttons, and the guide MS provide explicitly says you shouldn't duplicate buttons. Hmmm. More food for thought.
    – Bevan
    Commented Oct 5, 2010 at 18:52
  • Just because the guide says not to do it doesn't mean you can't. =) However, it would seem silly to have those same buttons on every tab. Commented Oct 8, 2010 at 13:35

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.