Comment by ender7 | Hacker News Reader

Comment by ender7 | Hacker News Reader

For me, this should serve as a warning to anyone trying to let data do the designing for them.

To me this screams "hey! Our data says 'X'! Let's apply it in the simplest way possible, with little to no editing or afterthought, and then bask in the false confidence our data provides."

I'm not saying that their approach is a bad idea, but they've allowed their execution to falter. They're still in the idea phase. This is not a 'product' phase.

1. It's visually noisy. The problem is not necessarily that there are shitloads of buttons, but that they're everywhere. We have an area for buttons on the top right, then an area of tabs, then an area of large, poorly-gridded buttons, then another row of buttons on the address bar area. Oh, and the freaky tab-above-the-tabs thing on the title bar. There's no visual organization or hierarchy. The whitespace and value is all monotone. When you squint your eyes, all you see is buttons, and no organization behind them.

2. Look, I'm sorry, it's ugly. I'm not saying you need to go stick-up-the-ass Apple brushed metal. Just...after you've worked out the usability aspects, hire a graphic designer. They're really good at all those tiny little visual tweaks that can make the difference between 'eh' and 'great'. UI/UX people usually don't have the chops to accomplish that - you need a dedicated artist.

3. In the words of Dr. Malcolm, "Yeah, but your scientists were so preoccupied with whether they could that they didn't stop to think if they should." All right, your solution appears to be "more buttons". Take that a little farther. How many is enough? Can you have 'too many buttons'? (hint: yes) Do you want to distinguish visually between commonly-used and uncommonly-used buttons? Is it safe to draw this conclusion from your data? How representative of the average user's needs are these after-market add-ons that will probably only be installed by power users?

Look, data is useful, but poorly-analyzed data is dangerous. If you're not careful it will sing you whatever song you desire, whispering "yes, yes, more like that" in your ear as you dance down to hell.

To your point about letting the data do the designing for them, I believe they actually ignored an important aspect of their data or they were so biased towards the ribbon that they interpreted the data towards supporting it's implementation.

For example, the "Command Entrypoint Usage" graph, shows the Context Menu as the most prominent means to perform tasks and the "Menu Bar" as the least. Whereas they read this as "We need to make the menu bar easier to use", I would interpret that as a strong indicator that the context menu needs more attention.

The article points out that context menus are not very discoverable, and yet despite this they are used a lot. Getting past a simplistic reading of the data, MS are focussed on improving the UI for the majority that probably don't even know about the context menu.

Arguably, to look at the data and resolve to tune the context menu would be similar to getting data that most people are climbing up a drainpipe to get into their apartment, instead of using the lift, so to improve their experience we should signpost the drainpipe and build a nice ladder up the side of it. (BTW I use the drainpipe - it's quicker)

Ha, that's a fun analogy. If I understand it, you're saying the 'lift' is the menu bar (soon to be ribbon). Which, if I were to reuse the comparison, is more like walking down the street to your neighbour's building, climbing up _their_ drainpipe and jumping across rooftops to get to your apartment.

The menu bar is just not near enough to the "context" of managing what you want to manage. None of us would really like to click on hyperlinks in a webpage, then go up to the menu bar and click "open/copy/paste" to use said hyperlink. Just as the majority don't seem to like doing the same with files.

The ribbon is about as "front and centre" as you can get for an app, so I can't read your analogy in any way that makes sense to me.

Look. Context menus are useful but lots of people don't find them. In fact, MS added something to apps such as Outlook that addresses your comment about commands being near to the content that they work on, but presents the UI in a more discoverable form. Not sure what it's called, but it's a popup toolbar that fades into view next to your text selection, allowing access to text styling such as bold, italic, etc.

I find that in practice, I know where these commands are on the ribbon - they never move - and have no problem moving the mouse pointer to there, to click them. So, I tend not to use the contextual popup.

For nearness and discoverability, perhaps MS could try this UI again with Explorer and see if people liked it.

I just meant the ribbon is far away from the files one is managing (relatively).

Your example of the 'popup toolbar' is exactly the sort of thing I might expect to make the context menu more discoverable; but if it's been tried and didn't work, then the point could be moot. Perhaps utilizing some space next to the filename for the most common actions would suffice. I just think having the available actions closer to where you're working, on-screen, would provide a better experience with less scanning and less movement.

In any case, I'll continue to hide any such menu bar wherever possible :)

To me this screams "hey! Our data says 'X'! Let's apply it in the simplest way possible, with little to no editing or afterthought, and then bask in the false confidence our data provides."

If you read the previous post they also do a lot of user testing and iterate it down.

Like any UI element there are plenty of reasons to knock on the ribbon, but the lack of analysis, editing, or afterthought is not one of them. The premise of the parent post that this is accidental and the result of ignoring a few design guidelines is just wrong.

Have you read Jensen Harris' exhaustive blog posts on building the Ribbon for office?

http://blogs.msdn.com/b/jensenh/archive/2008/03/12/the-story...

Calling the ribbon poorly analyzed is jumping to an unsupported conclusion. Some of your specific suggestions were tested during the building of Office and found wanting.

   *Oh, and the freaky tab-above-the-tabs thing on the title bar.*

For me, that specifically spells of bad design. It looks like a multi-headed monster committee shouted, "WELL CAN'T YOU JUST PUT IT UP IN THE TITLE BAR?????"

It's a context menu, it isn't always there, just when you select something that have special options.

Now, that doesn’t really change anything, does it?

You know, I like the ribbon and I think it’s great UI design, at least for certain tasks, but it is very, very ugly. There has to be a better way to put the elements together.

I understand your point but if it's only there 5% of the time then it kind of changes something, right?

I like the idea and it makes sense design-wise (as in the hierarchy of commands from the most used to the not used at all) but after all these years I'm still not sure how I like it. I feel lost even with apps I use all the time (Excel or Word). But it's way better than what they had before ("millions" of buttons).

Reply on news.ycombinator.com