Windows: Interface Guidelines (1995) [pdf]
ics.uci.edu
ics.uci.edu
I have to say that those interfaces are clunky in retrospect, but they are undeniably clear and do not place form over function as many of the modern ‘flat’ and touch-orientated interfaces seem to.
The other two graphical interfaces I remember most fondly are NeXT’s and BeOS’, which are also, probably not coincidentally, OSes I used frequently over the same period of time.
(Just to give you some context, I remember avidly reading the Windows 95 Resource Kit in the run-up to the Windows 95 release in August 1995 because I had no internet access and therefore had had no way of downloading and testing the many “Chicago” betas that everybody had been raving about... and therefore I know that radio buttons on the interface were originally intended to be diamond-shaped rather than round.)
Somewhat related: long live the FOX Toolkit and its hard-coded Windows 95 theme http://fox-toolkit.org/screenshots.html
It was an experimental time, that's for sure.
Citation needed
Today's rush to simplified, web interfaces means typically that common keyboard scenarios have been completely forgotten about. A market leader in a niche sector, re-built their UI in Electron, it's primary purpose is to selectively migrate items from one technology to another.
While it does provide a treeview hierarchical structure, with a checkbox next to each item, selecting that via say "spacebar" or selecting multiple items using CTRL+SHIFT does not function. As well, it's non-native scrollbar does not accurately reflect your position and does not allow finely-grained re-positioning.
This is $5,000/seat software that has glowing reviews and has essentially captured the market for what it does - yes a small market, with approximately 6-8 competitors - almost all of whom have copied their user-interface and even Electron implementation.
- Lagging menus and widgets
- You misclick in Google Maps? Better if you start over the route
- 30x more resources for something done under 80MB, such as Discord vs Kopete. The later had inline LaTeX. And video previews. In 2007.
- Invisible scrollbars with no intuitive use
- Flat design not being able to distinguish a button for the background layer. Compare it with Motif, W9x, BeOS, KDE3 with Keramik.
So many people say this but I fundamentally disagree.
Applications are so much more complex today, supporting more combinations of OS and input method and data storage and accessibility and display modes and whatnot.
Applications are harder to use, yes, but because they do so much more. Your interface has to work and be responsive whether your file sits on a local disk or in the cloud, or maybe has to be synced. It needs to work with mouse and touch and a screenreader. And so on ad finitum.
Relative to their complexity, applications are doing just fine today I think. (Also don't forget there were so many terribly designed applications in the 90's. It's not like everybody was even remotely following established UX guidelines.)
The same kind of clear UX standards just don't exist anymore because there are so many different apps that do so many different things, and there's no obvious best answer.
But the good news is that applications do slowly converge on best practices. Think of how things like hamburger menus or swipe-to-refresh or pinch-to-zoom have become expected standards.
I use Microsoft office 2000, because since then, no new features have been added to word or Excel that I care about. In fact, I couldn't even name a single feature added since then. What they did add, is the ribbon instead of the toolbar, which makes it impossible to find things you need, and a whole lot of bloat.
On modern machines, office 2000 opens faster than I can release my mouse button from clicking its icon.
That is to say, I entirely disagree with your statement.
Well there's the rub.
There are tons of users who do require critical new features like cloud integration. And the ribbon was designed because specifically more people find it easier to use, as Microsoft's user research showed.
Office 2000 may very well be better for you. But it certainly isn't for everybody.
This internal survey seems to suggest otherwise. It asked a range of questions, not just "do you like it?".
More here: https://docs.microsoft.com/en-us/archive/blogs/jensenh/table...
Not exactly. What Microsoft's user research showed was that people who were unfamiliar with Office found the Ribbon easier to use than the traditional menu bar. They did not test whether the same held true for experienced users. They also did not test whether the Ribbon had a higher "skill ceiling" than a traditional menu bar (i.e. if you take two users, one who is proficient with the Ribbon and one who is proficient with the traditional menu bar, and ask them to complete the same task, who is faster?).
Most of the complaints about the Ribbon came from the audiences that Microsoft failed to adequately test the Ribbon on. Microsoft, as far as I can tell, figured that experienced users would quickly get used to the new UI paradigm and adapt. That was not the case, due to the aforementioned tendency for the Ribbon to "helpfully" move things around in order to put the most recently used tools front and center. This broke many people's muscle memory and, more importantly, inhibited the formation of new muscle memory. It's the latter that was especially galling for experienced users. Changing the UI is bad enough. But changing the UI and replacing it with a constantly shifting toolbar that gives the user no indication as to where their controls nor any consistency with regards to their positioning is intolerable.
Imagine if your car radio shifted its buttons around every time you started it to put the last selected station in the first position.
The problem with the ribbon is I find myself constantly having to click back and forth between different tabs. It's annoying, and takes twice as many clicks to get things done. Microsoft lost sight of the purpose of a toolbar: to make commonly used functions ONE click away.
When the rest of the industry followed suit and emulated them, the result was a tragic loss of precious vertical pixel space for the content I actually cared about: whatever I was working on.
I also miss the elegant discoverability of classic menu bars. I loved being able to open a program and quickly become familiar with what tools are available.
They did a great job surfacing keyboard shortcuts. Hints were right there beside the menu items, subtly advertised every time you clicked them. You naturally learned the ones you used most. I worked alongside a younger guy for a few months who was blown away by how quickly I navigated around my PC and got work done, for many sequences using like 90% keyboard and 10% mouse.
Would love to see menu bars make a return to the iPad and mobile, such as in this concept. You can really get a sense for how quickly a touch-based UI can be navigated using menus and toolbars: https://twitter.com/stroughtonsmith/status/12339911770803609...
It's very strange that Microsoft does not care about this. It's very annoying to me as well.
I don't mind much the vertical space of the Ribbon, but the stupid back and forth between tabs is really annoying.
But these cool kids will never understand functionality vs ubiquity.
But in a way it makes sense for the developers, if there is nothing left to change or for them to work on, there is no reason for them to still have their jobs.
Why fix bugs when instead you can just move things around and make things more flashy in an attempt to make management think you are making the app more 'responsive' or 'increasing user engagement'
But do they need to be that complex? Often times we are solving for the same problems (most CRUD apps aren't doing anything we didn't do in the late 90's), but devs have convinced themselves that all of this abstraction and overly engineered layering is necessary. It's often not.
If applications are worse because they are doing so much more then they should stop doing that "much more", focus on doing one thing and leave the rest to other applications.
> Think of how things like hamburger menus or swipe-to-refresh or pinch-to-zoom have become expected standards.
That isn't a great example for best practice IMO since the only expectation i have about hamburger menus is for them to die in a fire.
Really?! Just look at all the effort that people have spent their personal time contributing to projects like WINE for Linux for example. MANY many people want cross-compatability. I for one have certainly done a lot of waiting for things to become available for Linux, and very much appreciate all of the cross platform frameworks that exist and have existed in the past (WINE, Adobe Air, Electron, Cordova etc.) to enable cross platform software. I think they have been GREAT for the whole ecosystem, both for consumers and developers.
Making computers more accessible for visually or motor impaired has also been one of the great victories of modern software... and certainly not because developers have shoved it down peoples' throats. In fact they have had to REGULATE it in order to drag developers kicking and screaming into building accessible software.
As for input methods, that is just a natural evolution required from the proliferation of devices (desktops, smartphones, etc).
So sorry to say I don't think your statement is rooted in any kind of reality beyond what exists in your head.
Accessibility is something that can be necessary, but certainly not in all situations. Though of all things, it is the one bit that the OS itself can support the most and relieve applications from having to do it themselves (of course this assumes that applications do not try to use the lowest common denominator of OS functionality in order to be cross platform and actually take advantage of the functionality their OS provides).
About the proliferation of devices, this is a great case where what i wrote about leaving things to other applications applies: instead of having a single application try to cater to a bunch of different devices and input methods (and thus providing a mediocre experience on all of them), it is better to have one application tailored for each device and input method.
And note that i'm not writing about what is being done but what about should be done. Of course this is in my head, otherwise i would say that things are actually nice now.
Why? Why does every application need to be "cloud connected"? What's wrong with having a normal desktop application that saves files to the filesystem like every application did for thirty-odd years? The only reason for this that I can discern is that it's an easy way to lock users into paying a monthly or annual recurring fee, rather than a one-time fee for the software.
Users themselves are not asking for cloud connectivity. People understand files. They can save files, copy files to a thumbdrive (or Dropbox), and e-mail files as attachments. Files are an interface that people have figured out. We don't need to reinvent that wheel.
It needs to work with mouse and touch and a screenreader.
In my experience, older applications are far more screenreader friendly than new applications. Moreover, not all visually impaired people are so visually impaired as to require screenreaders, and the more skeuomorphic designs that were favored in the '90s and 2000s were far easier for them to use than today's flat designs where one can't tell what is and is not a button. Heck, even I get confused sometimes on Android UIs and don't notice what is a plain text label and what is an element that I can interact with. I can only think that it's far worse for people who have sensory and cognitive deficits.
As for "it needs to work with a mouse and touch", my answer is once again, "No it does not." Mouse and touch are different enough that trying to handle both in one app is a fool's errand. Mice and trackpads are far more precise than touch, and any interface that attempts to both mouse and touch with a single UI ends up being scaled for the lower precision input (touch), which results in acres of wasted space in the desktop UI.
The same kind of clear UX standards just don't exist anymore because there are so many different apps that do so many different things, and there's no obvious best answer.
Of course there's no obvious best answer if you're trying to support everything from a smartwatch to a 4k monitor with a single app. So why are you trying to do that? Make separate UIs! Refactor your code into shared libraries and use it from multiple UIs, rather than attempting to make a single mediocre UI for every interface.
But the good news is that applications do slowly converge on best practices. Think of how things like hamburger menus or swipe-to-refresh or pinch-to-zoom have become expected standards.
The problem is that all of these new "best practices" are far worse, from a usability perspective, than the WIMP (windows, icons, menus, pointer) paradigm that preceded them. Swipe to refresh is much less discoverable than a refresh button, and much more difficult to invoke with a mouse. Pinch-to-zoom is impossible to invoke with a mouse. Hamburger menus are far more difficult to navigate than a traditional menu bar.
When today's best practices are worse than yesterday's best practices, I think it is fair to say that applications are getting worse.
Mouse and touch seem like completely different things, but they're more similar when you consider pen/stylus input. 2-in-1 devices running a proper desktop-grade OS[0] are amazing devices, and one thing they're missing are properly designed apps, which are few and far between. 2-in-1 made me actually appreciate the ribbon a bit more - though an overall regression in UX, it shines with touch/pen devices, which I'm guessing was MS's intention all along[1]. 2-in-1s with pen are really magical things; I use one (a Dell Latitude) as my sidearm, and started to prefer it over my main Linux desktop on the grounds of convenience and versatility.
Best pen-oriented apps actually allow you to use keyboard + finger touch + pen simultaneously. You use pen for precise input (e.g. drawing, scaling, selecting), fingers for imprecise input (e.g. panning/rotating/scaling, manipulating support tools like rulers) and keyboard for function selection (e.g. picking the tool you'll use with stylus).
--
[0] - Read: MS Surface and its clones.
[1] - For instance, Windows Explorer would be near-unusable as a touch app without a pen, if not for the ribbon that makes necessary functions very convenient to access using finger touch.
(Tooltips usually show when you hold the mouse pointer stationary over an UI element. With pen, it's somewhat harder to do unless you're in a position that stabilizes your forearm, but there's an alternative trick: you keep the pen a little further from the screen than usual and, once over an element you want to see the tooltip for, you pull the pen back a little, so that it goes out of hover detection range. It's simpler than it sounds and it's something you stop thinking about once you get used to it.)
Of course they absolutely* are. I keep literally all my documents in the cloud. I'm constantly editing my documents from different devices -- my phone, my laptop, my tablet. Users like myself are absolutely asking for cloud connectivity. I simply won't use an app if it doesn't have it. Your argument makes as much sense of "why does every skyscraper have to have elevators? Users aren't asking for anything more than stairs!"
> Mouse and touch are different enough that trying to handle both in one app is a fool's errand.
Except you don't have a choice. Many apps these days are webapps, and absolutely require both interfaces to work. Many laptops also support both. That's just how it is.
> The problem is that all of these new "best practices" are far worse, from a usability perspective, than the WIMP (windows, icons, menus, pointer) paradigm that preceded them... When today's best practices are worse than yesterday's best practices, I think it is fair to say that applications are getting worse.
Except WIMP doesn't work on mobile. So it's an apples-to-oranges comparison.
If by "cloud" you mean a filesystem-like abstraction that's synchronized across multiple systems (e.g. Dropbox or OneDrive), I have no objection to that. Heck, I even called out Dropbox as a viable alternative to "cloud connectivity". What I am objecting to is the tendency that many apps (especially mobile apps) have of locking your data away in their cloud, making it impossible to get at your data, back it up, or share it with a different application.
Many apps these days are webapps, and absolutely require both interfaces to work.
That's a nonsequitir. It's entirely possible to detect the size and capabilities of the device that user is using and display a UI that's appropriate to that device. What I'm militating against is the lazy approach of designing the UI for mobile first, and then using CSS media queries to scale it up fit a desktop viewport. That results in acres of wasted space and a poor user experience, because the user doesn't have the same interaction expectations that they would have if they were using the UI on a mobile/touch device.
Except WIMP doesn't work on mobile.
And mobile UIs don't work on desktop. Trying to make a one-size-fits-all UI is a fool's errand. Much better to design each UI for the platform that it will be displayed on (laptop, tablet, phone, smartwatch, etc) than trying to scale a single UI across multiple devices.
But do they? The move to web browser apps and the loss of rich native desktop functionality means that many web apps offer far less functionality than native desktop apps. The companies that offer these web apps sell them on their easy sharing capability and collaboration features.
An example: thirty years ago (or more), you could use any desktop word processor and perform basic tasks like spell check, change the colour of text, choose fonts and change their size.
Or today, in 2020, you can use Dropbox Paper without any spell check, no way to change the colour of text, no ability to choose fonts or even alter their size. But it does runs in a web browser. This is apparently progress.
That is real, apparent progress.
Hamburger menus are literal garbage with a little bit of everything and zero organization. Give me a menu bar instead. Swipe-to-refresh is completely useless for well-behaving software and pinch-to-zoom often activates when I wanted to press a button instead.
Mobile device features were shoved into desktop UI without regard for desktop users. Desktop users' productivity has suffered as a consequence.
Also, what stops you right-clicking (or in Apple parlance, secondary clicking) on macOS? Context menus are plentiful, either by: - Holding Ctrl and clicking with the primary mouse button - On the Mighty Mouse and Magic Mouse, enabling secondary click in System Preferences - On the Magic Trackpad, enabling secondary click as either a click in one of the lower corners or two-finger tap in System Preferences
It's badly-designed apps, likely cross-platform or designed by people who don't know the macOS HIG, that bring mobile-style hamburger menus to macOS, not the hamburger itself.
As opposed to "completely succumbed to metrics". Conventions like shift to range-multiselect/ctrl to toggle-multiselect cannot evolve from a series of a/b tests. It's not as if people never tested UI ideas back then, but it was a tool, not the entire process.
Forgiveness
Users like to explore an interface and often learn by trial and error. An effective interface allows for interactive discovery. It provides only appropriate sets of choices and warns users about potential situations where they may damage the system or data, or better, makes actions reversible or recoverable.
I’m home on sick leave today, a colleague just called because he’s unchecked some boxes in the CAM software resulting in the license being disabled and the check boxes disappear.
I’ve remoted in, no obvious and no hidden way to get the check boxes back, so he has to call the support line.
I would screenshot the start menu, buttons, window borders, and various other UI components and try to recreate them in QBasic by zooming in and inspecting all the pixels.
I had subroutines to create windows, buttons, menues, various fonts, 255 colors and mouse support. It was coming together incredibly well given I had no idea how any of these were built. I had a working version of minesweeper and a text editor.
I did the same although trying to create a Unix GUI (in a purely visual “I’ve seen this in the movies” sense) and I did it in Amos Basic.
Needless to say it wasn’t a great success, but it provided me with the foundation for a making couple of neat-looking applications which actually did useful things (to me).
It was slow as heck, but I had great fun doing it.
The nice thing about Windows of that era - its widgets and their default color scheme was designed to still work with just the original 16 EGA colors (since that was the baseline for video cards back then). To be even more precise, everything other than window title and selection was done in 4 colors - white, black, and two shades of gray. Window/selection added a fifth. Things like selection rectangles and resizable window borders were done using XOR. This all was readily accessible in a DOS app, pretty much regardless of the language.
And hey, MDI is still there, and often still the easiest way to organize things in a desktop Windows app.
There's a nicer version of that PDF at:
http://mirror.informatimago.com/next/developer.apple.com/doc...
as well as a 1997 update for some newer interface elements:
http://mirror.informatimago.com/next/developer.apple.com/doc...
It was written largely by Tandy Trower (inventor of Clippy) and has many similarities to Apple's original Human Interface Guidelines though very different too.
I figure the closer I get to that, the easier the port to gui.cs will be.
Another good UX book I found was "The Definitive Guide to the .NET Compact Framework" by Larry Roof and Dan Fergus. Yes, it had mostly back-end stuff, but the UX concepts taught the reader to consider his audience.
Is the person using your app likely to be using it in a dock hooked to a full keyboard like you, Mr. Dev?
No, he will be standing next to a cellphone tower wearing gloves and trying to get the Falcon x3 out of the sunlight enough to see what the screen is showing him.
Okay then, make the buttons big enough for a gloved finger to mash, use combo-boxes everywhere you can stand it. So what if its ugly - if its functional and the user never has to use the SIP, then fine.
I had a really nice FreeBSD+xfree86+KDE setup at that time. The closest I can come now is something based on XFCE4.
(I'm worried this won't improve until web folks fix the broken pointer events APIs, and even then it'll only lead to proliferation of pen-oriented Electron apps.)
Of course, those ran WinCE usually. But I don't think pen input code was any different.
This looks like a fantastically good resource for inspiration :)
Acceptable: OK
WTF: Ok