Hacker News Reader

Comment by pavlov | Hacker News Reader

These ideas have a strong late 1990s vibe.

Desktop app complexity had grown over a decade so that Microsoft Word, which started with a simple single-row toolbar, now was taking over 30% of a typical PC screen with a sea of icons and controls. Meanwhile the growth in PC sales meant there was an influx of non-corporate users who were not being trained to use the apps.

That’s how we got Clippy (essentially similar to the text input box proposed here), “progressive”menus that hide advanced actions and features the user hasn’t been accessing, as well as the explosion of task-oriented panels in Windows XP.

The execution of these ideas left a lot to be desired. (The Office 2006 Ribbon UI was actually a meaningful step forward because it contextualized and prioritized the UI rather than hiding stuff. Microsoft has solid data showing that Ribbon improved the user experience.)

Maybe language model AI can give this kind of UI a new lease of life.

View on HN

> The Office 2006 Ribbon UI was actually a meaningful step forward because it contextualized and prioritized the UI rather than hiding stuff. Microsoft has solid data showing that Ribbon improved the user experience.

It’s great for learning. But the different panels and varied icons, make it annoying to scan and find things…

compared to the traditional nested toolbar with consistent sized icons and labels

On the flip side, the variety of shapes and layouts makes it easier to recognize a feature you’ve used before.

Humans need some variety to make sense of their environments. Imagine if every tool in a toolbox was the same shape and size and color, or if every room and hallway in a building had the same plan and decor. It would be a lot harder to find what you’re looking for.

If I'm typing in a doc then Ctrl-? and type the name/keyword for the feature I want is much easier then navigating through the zoo. The zoo is fine when I don't know what I'm looking for and I can browse the pictures for inspiration.

Yes!

We've arrived at "recognition vs. recall" and "a sense of place".

https://www.nngroup.com/articles/recognition-and-recall/

I've struggled to enumerate the spectrum from one to the other as I've worked through the impact of GPT on my work over the past year. What the author describe here is a great attempt at getting to the core concepts:

* mixing and matching aspects of GUI and CLI in a single unified interface

The key, to me, is that when designs combine elements of recognition vs. recall, those designs need to link the CLI and GUI in bi-directional ways such that direct manipulation of GUI objects impact model queries with near zero latency in the CLI while query and manipulation of the models in the CLI show changes in GUI "at once". Direct manipulation matters in both directions owing to perception.

Of course, I'm probably describing ancient history in terms of Logo or Borland's early attempts at bi-directional tooling, but I think a tip of the hat and a little retro-computing software is not a bad way to approach the problem.

Icons/graphical selectors are difficult for me personally, but I don't object to them as I understand they are helpful to most people. I'd love to see brief textual labels, always displayed in the same order and disabled when they don't apply. Make the icons optional so I don't have to take up space with them.

This puts everything in the same place, every time I want to use it. Under CUA, it was a basic tenet - don't move things around or hide them. Menus used to provide this, now nothing really does - everything wants to subtly (or not so subtly) shift the controls you are provided based on context, which means it always requires some mental processing until/unless you learn state+position.

The exception to this (for me) is the context menu, which you will assume by default only presents contextually relevant options.

You got the same effect with simple colored icons inside the ordered menus though.

> the variety of shapes and layouts makes it easier to recognize a feature you’ve used before.

It has the exact opposite effect for me. It makes the whole thing harder to navigate and even more difficult to find the exact thing you're looking for. It increases the cognitive load required to do anything except the most common actions significantly.

I just do not understand the love for the ribbon. It's a junk drawer of icons and if you don't already have an idea of what your feature "looks like" and roughly where it lives spatially. It's painful to use.

It just feels like a visual representation of keyboard shortcuts. Spend enough time in an application and you learn how to get to stuff efficiently, but it doesn't help you if you just want the basics.

> Microsoft has solid data showing that Ribbon improved the user experience

do they also have data filtered to show powerusers? just because metrics go up doesn't really mean it got better. I'm pretty sure google also has metrics "showing" that it got better at finding stuff, which I really can't agree with. my ms-office literacy was much higher pre ribbon, and it never cought up

It’s a trade-off. The Ribbon demonstrably enabled average users to discover and access functionality that they never knew about or understood before. The numbers were very significant. (I think I read about it in Steven Sinofsky’s newsletter called Hardcore Software. He was in charge of Office back then.)

Power users by definition tend to invest in learning the software. They’ll be initially annoyed at changes, then adapt. And in the era of continuously delivered web apps, there really isn’t any UI stability left for a lot of the widely used software (sadly).

Does the confirm or cancel go on the left or the right? How is that not even accidentally standard at this point?

Because it is specific to a given platform and culture.

For example: https://ux.stackexchange.com/a/1077

There isn’t one standard set of guidelines. Platforms evolve, new ones come, guidelines will always be contradicting each others in weird ways (like this button positioning).

I've seen Windows "wizards" that manage to swap them between steps.

The only justification in my mind that makes sense for having it one way and then the next screen is the opposite is in the case of destructive actions (e.g. formatting a drive). It can help prevent users on autopilot from nuking things.

The only example of this that comes to mind is factory resetting a Nintendo Switch, but I'm sure there are much more.

If you're worried about autopilot, The button should move around so that auto pilot clicks have no effect, not change meaning. Or, require text input to confirm an action.

I have a HP wide format printer where after loading in a roll of paper, it presents a "Paper loaded successfully" dialog, with an "Ok" button to dismiss the message. The fun part is that the dialog also dismisses automatically in a couple of seconds and the UI underneath has the "Unroll paper" button in the exact same position where "Ok" used to be. I must have accidentally unrolled the paper immediately after loading it in dozens of times by now.

That is just plain evil.

Confirm goes on the right, cancel goes on the left. Similar to next and previous.

Anyone doing it the other way, I'm curious what the reasoning is for that.

Different operating systems have different conventions.

Windows centre- or end-aligns all these buttons (depending on the context), with Cancel last (generally mapping to having the primary action first). That has been its convention since at least the start of Win32 era. If you’re targeting Windows, this is probably what you should do.

Another platform end-aligns all these buttons, with the primary action last.

Still another platform stretches buttons, with the primary action last.

Others have cause to split things, start-aligning any cancel/negative button, and end-aligning others.

If you’re targeting a particular platform, you should generally aim to match its conventions unless you have very good reason not to.

One piece of related reading (and you can easily find others): https://www.nngroup.com/articles/ok-cancel-or-cancel-ok/

And so because a Windows person was carless 40 years ago, we still have poor pattern today.

Not sure. When I wrote it the other way I was thinking windows did it the way I said (I only use windows at work). Turns out they do it how I think is backwards, but looking at it I don't think it's a big deal.

With the way Windows has always laid things out and designed its buttons, its ordering is, I think, objectively at least mildly superior, following reading order and with no major stylistic difference between the buttons. Platforms that have switched to doing things other ways have normally (and more recently I think it’s consistently) been laying things out differently and/or designing their buttons differently. On mobile devices especially with their right-hander bias, limited maximum width and screen-based navigation, primary action to the right is objectively superior, for tactile and UI flow reasons.

KDE puts confirm on the left, iirc their reasoning is that people read left-to-right and want to see the most likely option first.

(Screenshots: https://freeaptitude.altervista.org/articles/show-a-dialog-w...)

As sibling says, ultimately it's best to follow the platform convention so your app doesn't confuse anyone or cause them to misclick.

OS X had OK to the right, Windows had OK to the left. Now Apple has removed OK buttons in favour of writing the action on the button, which makes much more sense. Inspired by BeOS maybe?

So instead of "Do you want to save before you quit?" "OK / Cancel" it is now "Do you want to save changes?" "Cancel / Save"

The original Mac’s layout was

    (Yes)
    (No)       (Cancel)

They switched from that to

    (Don't Save) ----- (Cancel) (Save)

with System 7.0 in 1991.

From the outset, Apple’s HIG recommended using more descriptive words rather than 'OK'.

Thinking back to a link posted here a few months back [1], the call to action goes on the outside edge because it's visually the heaviest element.

So if the buttons are on the right of the dialog, "OK" / "Save" would go on the right; and opposite if they're on the left side of the dialog.

I'm far from a designer but I read through this a few times and think it's pretty good.

[1]: <https://anthonyhobday.com/sideprojects/saferules/> "Visual design rules you can safely follow every time"

> They’ll be initially annoyed at changes, then adapt.

I tried to adapt, but never really could. Instead, I stopped using software that forced me to use a ribbon.

Haven't seen the data, but I assume that not all users got it better (that's kind of impossible in most scenarios?) but that on average it got better?

Me personally like the ribbon concept and feel like it was a good improvement (because I could see the long term benefits) even if it meant I had to re-learn significantly.

That data may be very interesting to differ between average, mean and median. If most of the people are not pro-users, the average may increase significantly, while the mean may not.

Doubtful, because that wasn’t their target. They want MS Word to be approachable to the masses.

“Make the easy things easy and the hard things possible”

> “Make the easy things easy and the hard things possible”

Unfortunately, that's not the principle in action. Modern UI/UX philosophy is more of "make the easys thing easy, and make the hard things out of scope of the product".

I was referring specifically to the MS Word toolbar transformation.

Everything you could do previously was still possible, but the most common things got a lot more obvious.

Oh, I see, sorry for misreading.

You're right, that era obeyed the principle you stated, but that was still the Golden Era of UI.

Unfortunately, keyboard usage became harder, to the detriment of power users. Personally I also find the classic menus much easier to scan visually than the ribbon icons which have varying sizes and are laid out in two dimensions (no clear scanning path).

> to the detriment of power users

Yes this is my whole point. They made it easier for casual users at the expense of power users. It was a purposeful decision.

I don’t think they intended to negatively affect power users. They convinced themselves that the new keyboard scheme is just as adequate.

I guess that explains why I've grown to dislike MS Word so much.

Then why they made vimperator-like controls for the ribbon? Press Alt to display the tags, then enter the corresponding tag. Works in Windows Explorer too.

It's a pretty useful feature, clearly aimed at power users. It makes the ribbon both discoverable and productive, in contrast to most other controls, which are typically either or.

They also clearly made large steps towards keyboard-only controls. In Windows 8 and contemporary Office versions, they bound most settings (previously only accessible through GUI) to PowerShell objects. In modern Windows/Office builds, you can control practically everything from the console or keyboard, or script it - something that was traditionally missing in the Windows ecosystem.

And of course they vastly expanded the PowerToys. I just don't see them ignoring power users - they made great improvements for the advanced Windows and Office usage.

The ribbon keyboard navigation is significantly slower to use though than the classic menus, because you need to release the Alt key first, and also many sequences are longer. With the classic menus, many commands were like Alt+B+C where you could press those keys almost simultaneously like a chord, in a fraction of a second. The new keyboard shortcuts always feel clumsy and awkward to press in contrast, and they don’t build muscle memory well for that reason.

You don't need to release the Alt key. Not sure I understand any other points either, as "clumsy and awkward" sounds really opinionated. Ribbon tags are just ordinary vi-style modal shortcuts that were proven to work well before Microsoft even existed - you memorize mnemonics/syllables, and utilize your touch typing skill with them. Unlike Win32-style menu navigation shortcuts, they're mostly on the home row, and/or represent a mnemonic.

For the speed, you should really use the traditional non-modal shortcuts (which never went away), not Win32 menu navigation. However this question is discussed to death in vim vs emacs debates - the minuscule speed difference is irrelevant for one-time actions, what matters is the cognitive load and muscle memory.

The valid use case for non-modal shortcuts (as opposed to combinations) is manually repeating the same command multiple times over and over, but in text editors this is the strong anti-pattern, and in Word you can use F4 for that, which is much more convenient and can be done just by holding the key.

You do need to release the Alt key because the old menu access keys still work (invisibly), and are activated otherwise if you don’t release the Alt key. I think part of the subjective clumsiness is because the ribbon has higher latency than the classic menu had. This is a general problem with newer UI elements in Office. They sometimes have a latency such that they don’t register key presses if you press them to quickly. This means that you have to consciously have to insert a small delay between key presses, or have to wait for visual feedback before pressing the next key. This is something that wasn’t an issue 20 years ago.

> You do need to release the Alt key because the old menu access keys still work (invisibly), and are activated otherwise if you don’t release the Alt key.

This is a backwards compatibility feature overriden by Ribbon keys, isn't it? When you hit Alt+I (Insert menu in Word 2003) you get a specific pop-up warning about that (in Word 2019 you do), and can use the invisible old menu relying on the old muscle memory. But when you use an existing Ribbon combination, it takes precedence. For example, hitting Alt+W without releasing Alt calls the View tab on the ribbon instead of the old Window menu, so you don't issue two different commands.

The reason tags feel like having higher latency is because the tag appears either on release or after ~500ms of holding. But there's no input delay, it's purely visual. If you memorized it, you just touch type the combination at any speed.

Classic Win32 and Office menus are prone to actual input delays, though, if implemented incorrectly (e.g. starting slow operations on opening the menu).

Around the time they released that I happened to attend a talk from someone on the team that came up with it, presenting their "solid data". It's so long ago that I can't remember the details but I definitely wasn't the only person in the room thinking they were doing some extreme cherry-picking to make that case.

> 2006 Ribbon UI was actually a meaningful step forward because it contextualized and prioritized the UI rather than hiding stuff.

I deeply hate the ribbon because it's so good at hiding stuff. And moving stuff around.

> That’s how we got Clippy (essentially similar to the text input box proposed here), “progressive” menus that hide advanced actions and features the user hasn’t been accessing, as well as the explosion of task-oriented panels in Windows XP.

You're implying those were bad decisions, but could you also explain what exactly was bad about them?

I think Clippy legitimately was a bad idea: It was a clumsy attempt at anthropomorphising the computer, and it also came over cartoonish and game-y: Effectively, used UI patterns from a video game in a context where users wanted to get serious work done. (Interestingly, it also foreshadowed a lot of later trends in tech: Clippy was asynchronous, interrupting the user with notifications even if the user never did anything; and it foreshadowed the ability of programs to actually analyze content and not just be dumb typewriters with the infamous "it looks like you are writing a letter" message. I guess Tech learned it's lesson from the backlash, namely that it needs to be more covert and subtle about those abilities...)

However, the idea to show possible actions in the context where they are useful always seemed like the most straightforward thing to me. Maybe i'm biased as a programmer, but it seems natural to structure an UI in an "object oriented" manner, where the user is presented with certain types of "entities" and can manipulate them using certain actions: E.g., if you have a file, you can copy, delete or move it; you can also launch a program to edit it. You can do the same with a folder, but you can additionally navigate into the folder, etc.

The same pattern in a lot of programs designed for creating media: The entities would be text selections in word processors, shapes and layers in image processors, 3D objects in 3D designers, etc.

That was the basic idea behind the task panels in WinXP I believe. So what was bad about them?

> and it also came over cartoonish and game-y: Effectively, used UI patterns from a video game in a context where users wanted to get serious work done.

Hey hey hey. To an enthusiastic 12 year old like me, Clippy was pure gold! I could spend hours having fun with that guy. The doggie version was cool too.

Same :D

Also the cat.

Reply on news.ycombinator.com