Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

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.

share|improve this question
    
I've been thinking about this a lot recently too. Nice question. =) –  Benny Jobigan Oct 5 '10 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 Oct 6 '10 at 9:20
add comment

5 Answers

up vote 14 down vote accepted

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

share|improve this answer
add comment

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.

share|improve this answer
    
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 Sep 27 '10 at 1:48
    
Even Microsoft mentioned in the guidelines that Ribbon may not be a good fit for other uses. –  thenonhacker Oct 5 '10 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. –  thenonhacker Oct 5 '10 at 15:16
add comment

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.

share|improve this answer
    
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. –  Benny Jobigan Oct 5 '10 at 11:51
add comment

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.

share|improve this answer
    
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 Oct 5 '10 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. –  Benny Jobigan Oct 8 '10 at 13:35
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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