I did an internship where I was creating a prototype UI for a Windows application, and used the ribbon API to build it. I thought it was a well thought out design, and was definitely an improvement over nested menus. A problem I’ve seen come up a lot though is shitty implementations where the pattern wasn’t followed correctly making it really hard to find things because the developers put items in dumb places.
Generally in UX you want often used buttons to always be in the same place to take advantage of muscle memory. Text is more intuitive than an icon, but an icon will use less screenspace, so once the user learns the icon, you can have an interface that’s more user friendly (though less intuitive) so that’s fine. Small amount of experience or training needed with the softwareresults in more buttons available at all times, so it’s worth the trade off to use one button bar. Less used items should be put into a menu because a) it’s not used often so it’s fine to be hidden away unless needed and b) it’s not used often so the user isn’t going to be familiar with an icon so text is preferable.
The ribbon is some weird combination between a menu and a bar with buttons on it. So all of the disadvantages of menu (buttons aren’t always on the screen) and all of the disadvantages of button panel (icons that have to be learned for nearly every single feature). The advantages of being able to access the most used features from muscle memory is lost, the advantage of being able to discover lesser used features by simply reading text is lost.
It’s just indecisive design. Not putting any thought about how the user actually uses the software, Just chuck some buttons onto a ribbon somewhere, make a pretty icon so it looks good and let the user click on various ribbons an click on random pretty buttons until they find the button that adds an attachment to an email in outlook. But when they find that button, make sure we default to OneDrive instead of the Documents folder because pushing cloud storage is currently the top priority as MS.
Sorry… bit of a rant there. But yeah, just put thought into which features will be used most often make them to be the buttons on the bar, put everything else into a menu. Worst case is the user has to click two things to use a feature, which is the same as using ribbons. Best case the user is clicking the same button they’ve clicked 100 times before and it’s in the exact same place as when they clicked it all of those times before.
I just want to come in with extra hatred for the “start” button, which looks like it’ll just open another ribbon, looks like another ribbon but doesn’t. No, it opens a full size menu where items are primarily arranged vertically for some reason.
I did an internship where I was creating a prototype UI for a Windows application, and used the ribbon API to build it. I thought it was a well thought out design, and was definitely an improvement over nested menus. A problem I’ve seen come up a lot though is shitty implementations where the pattern wasn’t followed correctly making it really hard to find things because the developers put items in dumb places.
Generally in UX you want often used buttons to always be in the same place to take advantage of muscle memory. Text is more intuitive than an icon, but an icon will use less screenspace, so once the user learns the icon, you can have an interface that’s more user friendly (though less intuitive) so that’s fine. Small amount of experience or training needed with the softwareresults in more buttons available at all times, so it’s worth the trade off to use one button bar. Less used items should be put into a menu because a) it’s not used often so it’s fine to be hidden away unless needed and b) it’s not used often so the user isn’t going to be familiar with an icon so text is preferable.
The ribbon is some weird combination between a menu and a bar with buttons on it. So all of the disadvantages of menu (buttons aren’t always on the screen) and all of the disadvantages of button panel (icons that have to be learned for nearly every single feature). The advantages of being able to access the most used features from muscle memory is lost, the advantage of being able to discover lesser used features by simply reading text is lost.
It’s just indecisive design. Not putting any thought about how the user actually uses the software, Just chuck some buttons onto a ribbon somewhere, make a pretty icon so it looks good and let the user click on various ribbons an click on random pretty buttons until they find the button that adds an attachment to an email in outlook. But when they find that button, make sure we default to OneDrive instead of the Documents folder because pushing cloud storage is currently the top priority as MS.
Sorry… bit of a rant there. But yeah, just put thought into which features will be used most often make them to be the buttons on the bar, put everything else into a menu. Worst case is the user has to click two things to use a feature, which is the same as using ribbons. Best case the user is clicking the same button they’ve clicked 100 times before and it’s in the exact same place as when they clicked it all of those times before.
Ribbons are just a crime against UX.
I just want to come in with extra hatred for the “start” button, which looks like it’ll just open another ribbon, looks like another ribbon but doesn’t. No, it opens a full size menu where items are primarily arranged vertically for some reason.