Hacker News Reader

Comment by adamzochowski | Hacker News Reader

The question is what drives consistency.

80s 90s and early 2000s it was the OS. All apps running under a specific OS would look similar to each other. Behave same way. File menus looked same. Preferences was in same location.

But somewhere in 2000s this reversed and OS was no longer driver of consistency.

App developers stopped following OS UI guidelines and decided that it's not important for OS to be cohesive. The goal was that app, no matter where it is running, should have consistent look and behavior.

And now we are in application centric world where application dictates UI and there is no OS level consistency.

Additionally Microsoft and Apple did not help the situation by themselves breaking the OS UI paradigms with media players, or in MS case MS Office.

View on HN

In the case of Windows, that consistency wasn’t ever really there at any point. DOS was the Wild West when it came to UI and much of that carried over to Windows — it wasn’t unusual to come across Windows programs that looked nothing like the OS in the 95/98/ME/2k/XP era.

It was more of a thing on Macs, which never had a point where the platform didn’t provide guidance for what programs should look like, and that only got stronger with the introduction of OS X where non-native programs stuck out like a sore thumb due to looking so supremely unpolished next to apps built with Cocoa or Carbon, which were richly nuanced.

To my memory, all of this flipped with the introduction of flat design, when it became more acceptable to build software that didn’t have much love put towards UI design. An electron (or similar, e.g. CEF) app built using Material Design 1.0 stuck out much less starkly when framed by the flattened Helveticized OS X Yosemite or Windows 8 than it did framed by OS X Mavericks or Windows 7.

Every thing looked pretty much the same in the Windows 3 line. And almost everything looked the same on the NT line.

At the time of Windows 95, things were still basically homogeneous.

> DOS was the Wild West when it came to UI

You could tell when something was made with Borland and TUI. Professional applications tended to look alike.

[Article author here]

This is true... but, to be fair, there were a handful of apps that went out of their way to look like Turbovision apps but weren't, and by the same token, it was possible to create (e.g.) Delphi apps that didn't look like it.

The first console text editor I really liked on Linux was SETedit.

https://setedit.sourceforge.net/#scrnsht

That, I think, uses a 3rd party independent clone of Turbovision.

Mac has dispensed with consistency. Lots of secret handshakes, undiscoverable actions impossible to perform with a mouse for example.

The whole idea of a "standard user interface" always seemed totally goofy to me.

Do hammers, bulldozers, and microscopes all use a "standard user interface"? No, they do not.

A user interface should be optimized for the tool in question, not optimized to look exactly like the interface for all other tools.

Not to mention the hubris involved with imagining that one has invented the One True User Interface at the very dawn of the technology.

While performing roughly the same task, modern hammers don't have anything like the "user interface" of a Paleolithic hammer stone. Fortunately there weren't any "Human Interface Guidelines" people around when the hammer stone was invented.

App UIs should be optimized for their use case, yes, but I would argue that the idea that a one-off app UI design can do common widgets and interactions as well or better than a platform with tens of thousands of dollars and man-hours poured into user research involves just as much or more hubris as thinking that there’s One True User Interface. The average app with bespoke UI is chock full of usability/accessibility issues that wouldn’t be there had they been built with a platform UI framework.

> A user interface should be optimized for the tool in question, not optimized to look exactly like the interface for all other tools.

When you learn how to drive a car, you can expect the same standard across all cars. You don't relearn how to drive when you get into a new car. There's common UI and UX paradigms across all software and no one should have to learn your bespoke implementation. And I believe these sets should be part of the OS.

When you look at Spotify or Slack UI, there's nothing there that is better than their more native looking alternatives. I have utilities to populate a command panel with menu items, but it's essentially useless on these apps because everything is buried inside the app itself.

> You don't relearn how to drive when you get into a new car.

These days you do. We're at a transition these last 10 years or so as great as the one from crank-start to key-turn start cars, from regular steering to powered steering, and from manual to automatic transmission.

Even back a couple of decades ago I remember my 1980's Buick having shifting on the steering post toggles versus my 2000's Saturn having a standard shift stick.

Standards should change. No one is recommending to keep 1024*800 as the current resolution. I’m for evolution and for consistency. Not changes for the sake of change.

> No one is recommending to keep 1024*800 as the current resolution

I think the better parallel is aspect ratio, not resolution.

> When you learn how to drive a car, you can expect the same standard across all cars.

Across all cars. Not "across all controllable artifacts" or even "across all vehicles" (driving a bulldozer is way different from driving a car).

An optimal user interface for (e.g.) an accounting package is extremely unlikely to be the same as the interface for (e.g.) a video editor.

For that matter, imagine attempting to drive a car by picking the things you want to do off a menu with a mouse.

It would suck.

Big time.

"Ok, now open the Speed menu and scroll down to 'brake'. Now go to the 'slam' submenu item... whoops! Sorry, kitty!".

The OS is a tool in and of itself.

I think its perfectly reasonable to expect a program to look and feel similar to other programs on the same OS.

At least for things the OS is somewhat concerned with, like window decorations, menu bars and so on.

If i designed an OS id be frustrated with the inconsistencies in how different applications interact with the design of my OS.

> Additionally Microsoft and Apple did not help the situation by themselves breaking the OS UI paradigms with media players, or in MS case MS Office.

Indeed - I remember this situation very clearly. Back when Office 2007 came out, there was no first-party way to create applications like that, and after a year or two, only few third-party libraries that were lacking in quality and polish.

This was the turning point. Clients asked us for it, we tried, but ultimately we decided to ditch the bad libraries and do our own thing - then the clients decided they might as well define their own UI design language if they're paying for UI component development.

The Ribbon was a travesty. Organized menus were replaced by a giant bar full of incomprehensible icons. If you were decent at Office, then your muscle memory was screwed up. (If you were excellent, then maybe you had all the shortcuts memorized and it didn't matter, but most of us are in an in-between state.) If instead you were completely new to Office, then your consistent, discoverable indication of keyboard shortcuts (in the menus) also went away -- no more skill ladder. The only winners were preliterate toddlers, I have to assume.

This was justified with, "I am an HCI expert, trust me". Which is garbage: I'm the user of the tool; don't try to pretend you know better, like some colonial governor.

Also, it started getting slower. A process that only got worse and worse.

My assumption is that it was really all driven by internal politics within Microsoft, specifically some manager's need to Change Something.

[Article author here]

Strongly agreed. Better for newbies, maybe, but disastrous for skilled users. It broke the suite for me: I can't stand it at all, and switched to LibreOffice full time.

Sadly, though, LO Writer doesn't have Outline Mode, the one indispensible bit of MS Office for me. So I keep Word 97 or Word 2000 around, just for outlining.

And Microsoft could have just kept the old menu system. With a single click to switch between the ribbon interface and the menu interface. It could have been as simple as that, saving countless users from so much frustration. Instead they decided to force the inferior interface on every single user, whether they like it or not.

The whole ribbon interface debacle looks like a classic case of enshittification, where the users are no longer the customers anymore.

What for me is really strange, in a way, is that the Mac versions of Office did keep the menu bar, and still do. Until I upgraded to Monterey late last year, I was still using Word 2011. It has the ability to completely hide the entire Ribbon. That suited me well.

But Office 2011 is 32-bit and no longer runs. Now, I only keep Word around. I've been forced to update to 2016, the oldest 64-bit version that'll run on macOS 11 (AIUI).

The menu bar is an inextricable part of the macOS UI so it would be hard to remove, but it demonstrates perfectly that Office for Windows could have kept both UIs, because the macOS version did.

My normal mode of operation in Word for Windows uo to 2003 is just to turn off all the toolbars, and the horizontal scrollbar, and the ruler. It runs well with nothing but a menu bar and every feature is usable.

In the 90's it was easier to use the OS native controls and harder to customize them. Adding a small image to a button was pain. Using non-standard fonts or font sizes was pain.

Now it's easier to use HTML stack to create UIs and harder to use OS native controls.

Apple and MS own UI inconsistencies across app versions and the OS overall deserve part of the blame.

> The goal was that app, no matter where it is running, should have consistent look and behavior.

Microsoft is still working hard at Office 365. They are nowhere close.

Java had, at some time, achived this.

Reply on news.ycombinator.com