I know this is going to be controversial, since many people still seem to hate the ribbon Microsoft introduced in Office 2007 with a passion. However, I think a number of the new capabilities that toolbars have in DO11 are similar in concept. Now all we would need is the ability to have overlapping toolbar locations, and make them accessible and switch to the foreground via tabs, and there's the ribbon. I really think that the ability to have "subject groupings" of toolbars is helpful, and increases discoverability and functionality, particularly in complex applications such as DOpus. I know this may be a bit much to ask for DO11, although you guys seem to be at least halfway there as far as the required infrastructure is concerned, but is this something you might consider?
Have a search, this has been brought up before.
I like the idea, but with all the new toolbar functionality that was implemented in 11, I don't see it ever happening 
I disagree 
I was part of those other discussions, and I drafted my own set of alternating toggle-able toolbars in v10 based on those conversations and I like using them on a regular basis. By combining several of the new features already in v11, we can probably do much of what is needed to do this now, thanks to toolbars now being local to a lister and not global anymore.
I'll play with this a bit to see what I can come up with as an example. There are no "tabs" we can use really... but I think you can be creative with the use of special font and effect style icons, and a series of buttons that use the new lister-scoped variables to change out the icon from a plain font icon with the text name as part of the icon, and then an icon that looks as though a tab has been depressed.
I'll see... it would be a PITA to maintain if you have to create custom icons like this on a regular basis, but for an initial example drafting a Ribbon based equivalent to the default Menu bar would at least show what is possible with the new features already provided in v11.
I'll post some screenshots and examples later tonight after some experimenting.
Thanks for the advice to use Search, and sorry for not doing that earlier. Some good discussion there. I guess the only thing that is really "missing" in DOpus in that respect is some cosmetics (meaning the tabs). The other useful feature of ribbons, the context sensitivity, is already there in DO11. Oh, and, responding to a comment in that other thread, in DOIpus there's no reason not to have partial or full ribbons in combination with traditional toolbars.
After some initial playing... most of what you need to do can be done, toggle buttons to replace a toolbar with another are already easy to make. But GPSoft would still have to enhance our toolbar controls to let you do several things we can't do now in order to achieve the most common look-and-feel of most ribbon bars that I've seen:
- allow us to vertically stack buttons on a horizontally docked toolbar
- wrap button label text - OR - allow \n codes in the label text (like how we can use \t for tabs already)
- possibly control the vertical height of horizontal docked toolbars (maybe not necessary)
For the first, with the addition of 'Labels' as toolbar buttons in v11, it might be interesting if we had some sort of 'Label Box' button as well. My thinking is another field like the current 'Label' but which contains additional space where you could arbitrarily arrange buttons within the 'Label Box' area, say - in some sort of grid that wouldn't force you to need the same number of buttons vertically and horizontally. Maybe you could have some control over whether or not the 'label' for the box appears at the top, bottom, left or right edge of the box, or if it's displayed at all.
That said, toggling toolbars in place of one another is fairly easy to do now... if you're interested in what one might look like, give a shout.
I don't like ribbons at all and I think it's a waste of space.
I agree ... I'm quite happy with local toolbars toggling on and off in the same space and am stoked we've got toolbar status in layouts and formats. Woohoo...
The advantage of DO's toolbars is not jumping around and they have a very clear optical structure. Just have a look at the newer Explorer, mixed up icons/commands and without any symmetry (btw. MS placed "options" in "view"-ribbon - very intuitive). For example in Outlook I often need to look twice after using it for years. I don't want that in DO.
Of course, the big difference in DOpus is that you could configure those ribbons in any way you want, with any "clear optical structure" you like. There is no reason to expect any of the idiosyncrasies that some Microsoft ribbons have to be present in your personal DOpus configuration. One might add, as an aside, that even Microsoft's ribbons are highly configurable as well, at least in MS Office... Finally, the idea that ribbons necessarily waste space is patently false; in fact, the opposite is true: By grouping functions together in a flexible 2D arrangement one can sometimes achieve a higher density of functions than what is possible with a rigid linear toolbar. The only "wasted space" that I can see is for the tabs and labels of ribbon groups. While I would argue that those are helpful and aid discoverability, one could consider arrangements where these tabs are not used by, e.g., moving the functionality for switching to different ribbons to a menu.
Bottom line here is, I understand that some people have quite visceral reactions to those ribbons, for a variety of reasons. At the end of the day, however, all a ribbon is, is a flexible two-dimensional arrangement of buttons. In other words, they are just an extension of the toolbars that DOpus already has. Given that fact, some of the opposition I see against these things makes no sense at all: If you don't want to take advantage of the additional options that a ribbon can offer, you don't have to use one. It's as simple as that.
It wouldn't at all be like Microsoft shoving idiotic live tiles on a non-sensical Start Screen down people's throats. Oops, sorry, wrong topic.... 
Problem is, that isn't all a ribbon is, at least not in everyone's minds.
It'd be best to discuss the aspects of a typical ribbon UI you want.
I think whenever people talk about "the ribbon", whether positive or negative, they assume everyone else has the same features/aspects in mind (and that everyone else is viewing the many other aspects as unimportant), but it's not true, so it's best to talk about specifics.
Ok, let's talk about "optical structure" (the only specifics we need to talk about):
- Different sized buttons in each ribbon.
- Pulldown-arrow placed below on large buttons - makes them even larger. Arrow on vertical buttons on the right and asymmetric, because it moves to 2nd row when using a larger buttontext.
- Empty spaces when grouping less commands horizontal.
- Different distances between vertical buttons.
- In the same column text appears below an icon AND right to small icon/menu.
- Different heights and widths for each group.
There're other things I could mention here, but the above examples are enough to show that it is impossible to get a good structure, simply because it is not designed for.
A Ribbon is fine when you exactly know where your command is placed. But if you search for a command, it's really a disaster (!) - independent from the bad command-organization in Explorer and MS Office, you need to search between large buttons, small menus, menu-menues and the different ribbons itself. It is not eye-friendly, not intuitive. As said, it's only fine if you get used to. If I add a new button to DO I always now where to find, because the "optical structure" is intuitive, but a Ribbon isn't and will never be, even when you organize your commands in a logical way.
We can talk about placing two buttons one above the other (with text right to the icon) next to a single large button (with text at the bottom). But that only will look good, if the both buttons icons fit to the height of the large button icon. But this requieres another iconsize (either larger "large" or a smaller "small"!).
If I would like to have ribbons, I would not use DO!
Yes, I think this is an excellent suggestion in order to focus the discussion. Here are some elemnts I think would be nice to have:
- The ability to group buttons (of potentially different sizes) freely in a two-dimensional arrangement, rather than being restricted to linear arrangements. These groups could optionally have labels as well to aid in discoverability.
- The ability to group sets of such button arrangements together in a linear arrangement spanning the width of a lister (a "ribbon").
- The ability to "overlap" such ribbons, which would necessitate some way to bring them to the foreground, probably some form of labeled tabs.
- The ability to have certain ribbons activated automatically, depending on, e.g., file selection, content type of a lister, etc.
- One could have a goal to be able to expose the entire functionality of DOpus in a set of such ribbons (meaning, no menus necessary). Note that I am talking about being able to do this, not having to do this.
I fastly "designed" the example I mentioned in my previous post with to buttons above each other:
But as you see: It always looks asymmetric.
I'll just note that this is just flat-out wrong, and doesn't even begin to make any sense: Nothing in the nature of a ribbon prevents you from arranging the icons in exactly the same way you have them in your current toolbars. This may not be a good use of the additional capabilities that ribbons offer, but it is possible.
See, I understand, and I respect that you dislike ribbons, but the whole point is that you would not have to use any of the features of ribbons you dislike, or use any ribbons at all. On the other hand, even you may find that there are cases where you could welcome some two-dimensional button groups. Finally, my guess is if we call these things, say, "bands" instead of "ribbons", a lot of the animosity may go away... 
I don't see anything wrong with this. Other than having each one of the buttons labeled.
Oh, and of course that insufferable ModernUI style of those icons. If I was using Windows 8, I wouldn't be using DO.
Actually, if I was forced to use Win8, I wouldn't be using Windows at all...
Do we want to talk about MUI or Win8 here? Everyone prefers other things, and Explorer does offer Ribbons .
Yes, I don't like ribbons - but only the way how they're designed, not the idea itself!.
Ah, so that means we are in fact in agreement, are we not?
Maybe, but how to redesign them that way that people will like them?!
Following would be nice for content type, view display modes (with radio-buttons) and others things AND could be used within the normal toolbar:
Yes, one of the things I think might be useful is to have "partial ribbons" side-by-side with "normal" toolbars. As a consequence, we might have some fixed toolbar areas (1-d or 2-d) that are always there and do not have (or at least do not need tabs), and variable toolbar areas that have "partial ribbons" layered on top of each other, with the ability to automatically switch between the layers manually via tab selection, or automatically based on the state of DOpus.
However, looking at what I just suggested, this introduces a significant amount of complexity even just on the user configuration side, so maybe that's going overboard with things. I'm not sure, I guess we will have to leave it to our ingenious DOpus developers to make sense of this, or simply tell us that there's no way this is going to work, or happen...
I don't feel strongly one way or the other about ribbons. You can get used to them over time.
However, something the anti-ribbon advocates seem to overlook, is Opus' configurability. Should GPSoftware see fit to provide a ribbon tool, those who chose to use it would configure it to suit themselves, and the arguments about whether one can find items on them or not become moot.
Also, I would expect that, in making a ribbon tool available, GPSoftware would not at the same time remove the option to use toolbars, either instead or as well. If it could be used in addition to our existing toolbars, then it would simply extend Opus' functionality, presumably a good thing.
So, provision of a ribbon tool should boil down to a discussion over what facilities the pro-ribbon advocates whould like it to have, always assuming GPSoftware is interested in offering it in the first place.
This last question has not been answered.