>>>Sorry, but your answer is as unuseful as unpolite. How a UI works is decided by the customer whio pays.
>>
>>Tore's choice of word was poor, but the idea was correct. A menu that has dozens of items on a single list is a poor choice. The "customer who pays" is paying for expertise and that should include telling him when what he asks for isn't a good idea. As the expert, our job is to guide the customer to an application that accomplishes his underlying goals. Having an application that's hard to use surely isn't one of them.
>
>OTOH, one recurring theme that I keep seeing more and more is the growing complexity of apps. And that complexity has to be laid out in the GUI somewhere - either rich menus, or long toolbars or local toolbars on each of twenty pages of a pageframe... It has to be somewhere.
>
>In my experience, whichever layout is chosen is good as long as it allows for moderate expansion, additions of perhaps 15-20% of more items. The one thing that is, IMO, absolute no-no is to rework it and shuffle options around. That's equivalent to shuffling stuff on the shelves in a supermarket, where it has the goal to make you walk around, hoping that you'll do something you usually don't (e.g. buy something you otherwise wouldn't). In an app that someone is using for years it's a major annoyance.

Adding to that, for a lot of custom apps, enhancements are driven by power users. Anything that changes their high-volume work flow is a very tough sell.

Maybe right now their app has a "Forms" menu pad, with 30 suboptions, and the one they use the most is MyForm. Right now they can blast into that form with Alt-F...M. If this gets rejigged into a "proper" design with, say, 6 submenus with 5 options each, it changes to Alt-F...SubMenuHotKeyX...M. Now:

- As you point out, it's different. They have to grind the engraved path off their brain, and engrave a new one

- It takes an extra keystroke to achieve the same thing. This is a waste, if they do that operation hundreds of times each day they will complain loudly and never let anyone forget it

It's worth pointing out that sometimes the interface requirements to make high-volume data entry quick and efficient will not match any published interface style guides.

I remember a few threads over the years asking how to implement blinking controls in VFP. Invariably a member here would jump in and declare that blinking elements violate every Microsoft UI design principle and never have any place in any Windows application. I can only imagine that every day when he drove home from work, he never used his turn signals...

>The case at hand is the ribbons in M$ Office... I use it only sometimes (mailmerges in the app - for myself I use Libre) and for some options I simply don't know where to look. If this was a supermarket, I'd walk out with an empty cart.

Having used both interface styles extensively, IME it takes, on average, fewer clicks or other interface operations to do the things I need to do with the ribbon interface, than with the earlier menus. The ribbons group functions that are likely to be used together, and get it right far more often than wrong. I now mostly use Office versions with the ribbon and I find it a minor drag to go back to the old menus.

If you want or need to get more efficient with newer versions of Office, take some time and explore the ribbons. A couple of hours should be all you need; then you get the benefits every time you use it.