The Windows 95 user interface: A case study in usability engineering (1996)

I think there was a period from Windows 3.1 to somewhere during Windows 98 (maybe right up until the release of Office 97?) where both first-party and third-party Windows apps were all expected to be built entirely in terms of the single built-in library of Win32 common controls; and where Windows was expected to supply common controls to suit every need.

This was mostly because we were just starting to see computers supporting large bitmapped screen resolutions at this point; but VRAM was still tiny during this period, and so drawing to off-screen buffers, and then compositing those buffers together, wasn't really a thing computers could afford to do while running at these high resolutions.

Windows GDI + COMCTL32, incl. their control drawing routines, their damage tracking for partial redraw, etc., were collectively optimized by some real x86-assembly wizards to do the absolute minimum amount of computation and blitting possible to overdraw just what had changed each frame, right onto the screen buffer.

On the other hand, what Windows didn't yet support in this era was DirectDraw — i.e. the ability of an app to reserve a part of the screen buffer to draw on itself (or to "run fullscreen" where Windows itself releases its screen-buffer entirely.) Windows apps were windowed apps; and the only way to draw into those windows was to tell Windows GDI to draw for you.

This gave developers of this era three options, if they wanted to create a graphical app or game that did something "fancy":

1. Make it a DOS app. You could do whatever you wanted, but it'd be higher-friction for Windows users (they'd have to essentially exit Windows to run your program), and you'd have to do all that UI-drawing assembly-wizardry yourself.

2. Create your own library of controls, that ultimately draw using GDI, the same way that the Windows common controls do. Or license some other vendor's library of controls. Where that vendor, out of a desire for their controls to be as widely-applicable as possible, probably designed them to blend in with the Windows common controls.

3. Give up and just use the Windows common controls. But be creative about it.

#3 is where games like Minesweeper and Chip's Challenge came from — they're both essentially just Windows built-in grid controls, where each cell contains a Windows built-in button control, where those buttons can be clicked to interact with the game, and where those buttons' image labels are then collectively updated (with icons from the program's own icon resources, I believe?) to display the new game state.

For better or worse, this period was thus when Microsoft was a tastemaker in UI design. Before this period, early Windows just looked like any other early graphical OS; and after this period, computers had become powerful enough to support redrawing arbitrary windowed UI at 60Hz through APIs like DirectDraw. It was only in this short time where compute and memory bottlenecks, plus a hard encapsulation boundary around the ability of apps to draw to the screen, forced basically every Windows app/game to "look like" a Windows app/game.

And so, necessarily, this is the period where all the best examples of what we remember as "Windows-paradigm UI design" come from.

Ribbon has some good elements to it, but other elements are questionable at best. Sizing of buttons for example feels completely arbitrary and not connected to frequency of use or anything else obvious.

I think the best parts of it could be replicated by just combining tabs and traditional toolbars, but that’s not complex enough of a concept to need a dedicated moniker.

From what I remember it lost the ability to render rounded window corners, because while Windows 8 msstyle themes existed they all had the hideous boxed corners that clashed hard with many looks.

I don’t agree that transparency is always a detractor. Judicious use can be a net positive, but it doesn’t work for all themes and there should be an option to turn it off. Personally I didn’t find the W7 variation of Aero to be bad at all.

MS may not have been as tasteful as MacOS, but the functionality was at least there and it was easy to find and use. That goes a long way to make up for the bland-ish look.

Then we lost even more taste, and eventually the functionality and user friendlyness, on both sides of the isle.

Looking forward to your talk.

I feel like there's a taste issue which is similar to tabs vs spaces or other coding styles. Some languages kind of solve this with auto-formatting but just because they choose a standard doesn't mean their standard is as readable as some other.

In languages one taste issue that comes to mind. Many languages have the invisible scope issue

    foo = bar

In C++ for example, foo could be a local variable, a member of the enclosing class, a local module static, or a global. Some programmers like this, JBlow for example complained that in C++, switching between standalone function, member function, a lambda required too many changes. (foo = bar) isn't an example but the point is he wants that to be frictionless.

Me though, I want the line to be understandable with as little external context as possible. I don't want to have to dig up 10, 50, 100 lines to see if a local foo has been defined or if it's member. So like python or typescript. I like foo has to be this.foo or self.foo if you want it assign the current object's member. Most programmers seem to agree because they end up using mFoo or foo_ or some naming convention to work around the issue but I think I'd prefer the language to enforce it.

I don't know which if any languages make all the different scopes more explicit.

So far I haven't liked Swift though which seems more explicit. Even though it's more explicit in some areas I feel like the majority of my time is typing boilerplate and fixing trivial syntax errors. I know programming requires syntax and, as an example, I include semicolons everywhere in JavaScript even though they are not required. That said, I would like to get all the time back in my life where I compiled some C++ only to be told "error: missing semicolon at end of class definition" or "error: extra semicolon at end of member function declaration". It feels like a language should fix this stuff for the dumb human rather than make the human do random tedious work. I get there might be times where it's ambiguous but I wonder if it's also a language design issue.