tags:

views:

349

answers:

2

I am thinking of implementing a ribbon GUI in one of my apps and of course want to adhere to the MS Guidelines so it feels like a normal ribbon, etc. But I'm trying to figure out how to solve a specific problem in dynamically changing the ribbon.

I'm creating a concept game editor, please no question on why a ribbon as this is purely a concept idea, but the application will have many editors (2D, 3D, Code, etc) and for each one the GUI should adapt and display relevant controls i.e. in the 2D editor maybe a paintbrush, on the 3D many pan and rotate tools.

Given the ribbon guidelines it makes sense to the Home menu to contain the most common tools, but only for the type of object being edited (rotate makes no sense for 2D or Code!).

I initially thought it could have one window per editor but this makes a real mess and I'd rather have lots of tabbed editors so you can flick through them fast like in eclipse etc. Also all editors save back into one file so it makes sense to have one application window to keep this metaphor for the user.

I was thinking I could dynamically change the ribbon tabs depending on what type of editor the user had open (tabs may appear/disappear, content on the Home tab etc would change) but then this breaks the MS guidelines of:

"Controls displayed in a group MUST NOT change as a result of selection. If a control is not active, then the control MUST be grayed out, rather than removed from the group"

"The tab selected on the Ribbon MUST NOT automatically switch as a result of user selections made in the 177 document (except as noted in the Contextual Tabs section)."

I understand the reasoning behind the guidelines but im not really sure how to get the ribbon to feel right in this situation:

  • Change the content of the tabs depending on editor type (goes against the guidelines)
  • Have a tab per editor type (but what if i end up with 15 editor types!)
  • Have a very generic ribbon and move specific editor operations to a side bar or something (not the best GUI design)
  • Use contextual tabs for each type of editor (better solution but means you always have one contextual tab open!)

Any other ideas/solutions would be greatly appreciated as I must use a ribbon and must use it for this type of application!

+1  A: 

If you are providing a tab that is editor-specific, I suppose you could lay it out in the way that is best for that particular editor. That means that controls are going to move around occasionally, if you use the same tab for the other editors. It doesn't seem practical to gray out the controls that don't apply to any particular editor, if it's going to cause a lot of clutter.

On the other hand, graying out controls does have the benefit of keeping each control in exactly the same physical place on the tab. Do not underestimate the power of this. There's nothing more aggravating than expecting a control one place, and having it suddenly move someplace else (or disappear altogether). The graying out is a clear indication that the grayed control does not apply in this context.

So depending on how different the controls are for each editor, you will have to decide which approach is less disruptive: to gray out the unneeded controls, or to provide a fresh layout for each editor.

It doesn't seem workable to open a tab for every editor that's open, since there will be many tabs that are useless when the user is in a specific editor.

If possible, enlist the help of some volunteers or beta testers, and do some paper prototyping with them to see which approach resonates better with them.

Robert Harvey