Gurus of 90s Web Design: Zeldman, Siegel, Nielsen

> He would say stuff like “hyperlinks should always be blue and underlined” because that’s what users expect, without realizing that at that point in time we were still so early in the adoption of the web that it made no sense to apply such rigid rules.

I always remember recommendations from Nielsen as (a) backed by some testing with real users, (b) temporal, i.e. “at this time users expect…” and ( c) only focused on usability, that is, in practice there are other things to consider like design, performance, etc.

I will say that most of this nuance gets rounded to a Boolean like most advice.

Honestly, I believe that the Web would have been better had we stuck to those expectations more diligently and evolved more slowly and thoughtfully. That one can does not imply that one should.

Blue links and purple visited links were fine. And now on most sites there is no differentiation, and it’s sometimes difficult to tell what is a link, and a lot of sites don’t even bother linking. This is not an improvement!

Why didn't he say the same thing about links:

> he was saying that each browser should define how headers would be displayed to their users.

And let the user define the color and underline style?

Ben Shneiderman's the "hyperlinks should always be blue" guy. ;)

https://blog.mozilla.org/en/internet-culture/why-are-hyperli...

https://news.ycombinator.com/item?id=29897811

Seriously, while he was the first to use blue for links in HyperTIES, there was a historical context (like the IBM PC's color palette), and he never meant it in a "640k ought to be enough for anybody" way. His reasons for recommending blue are based on empirical studies, measuring visibility, comprehension, retention, etc.

Blue is good not just because users recognize it (they didn't in 1983), but for how it stands out, because of how the human visual system works. He was originally a fan of cyan aka "light blue".

Ben Shneiderman wrote:

>"Red highlighting made the links more visible, but reduced the user’s capacity to read and retain the content of the text… blue was visible, on both white and black backgrounds and didn’t interfere with retention,"

>"We conducted approximately 20 empirical studies of many design variables which were reported at the Hypertext 1987 conference and in array of journals and books. Issues such as the use of light blue highlighting as the default color for links, the inclusion of a history stack, easy access to a BACK button, article length, and global string search were all studied empirically.”

>"My students conducted more than a dozen experiments (unpublished) on different ways of highlighting and selection using current screens, e.g. green screens only permitted, bold, underscore, blinking, and I think italic(???). When we had a color screen we tried different color highlighted links. While red made the links easier to spot, user comprehension and recollection of the content declined. We chose the light blue, which Tim adopted."

HyperTIES Discussions from Hacker News:

https://donhopkins.medium.com/hyperties-discussions-from-hac...

“hyperlinks should always be blue and underlined”

this honestly make life so much easier...

Teenage me thought there was NOTHING cooler than a flashy splash page and those micro bitmap fonts a la "silkscreen".

Who am I kidding I still think it's awesome.

Most splash screens had a "skip" button though. If you were visiting the website frequently, you as the user could always bookmark the internal page that the intro screen pointed to.

It seems the next battle we'll have to fight is for fonts that actually present enough information to the user to disambiguate "Weird Al" from "Weird AI". Seems like we used to have these things called "serifs" but modern design knows nothing of such heresies.

That 2Advanced flash intro tho...

I don’t think designers hated Nielsen. I was doing web design at the time, and the general sentiment seemed to be: “Sure, he’s probably right—but the client wants it done their way instead, so…”

Still, his bite-sized advice stuck around and continues to shape the conversation. That’s where everyone learned about Fitts’ Law, Hick’s Law, optimal text column widths, the value of usability testing with just a few users, and the deep shame you should feel for making text hard to read. He may not have invented those ideas, but his articles popularized them. And because he was one of the few doing serious usability research and publishing it online, his authoritative voice gave those ideas real weight that designers could leverage to make the case to their bosses and clients.

Yes, to be fair, Nielsen essentially has had the last laugh. Simple navigation, consistency, fast loading times, and ruthless minimalism, and the full Flash intro page is a relic.

> Designers hated Nielsen.

Several of the designers I worked with liked him, in as much as he gave them research to back them in their arguments with clients that the site should actually be usable.

It is still one of the high points of my career that I was part of a team that shipped an internet banking application that worked well in the then-current major browsers of IE 6 and Navigator 4, but also worked in Lynx and on a Palm Pilot browser.

We've now degenerated to the point that "engineers" demand Chrome everywhere.

Certain designers may have hated Nielsen, but their users hated them, and they have more users hating them than Nielsen has designers hating him, and users matter much more than designers, so I think he came out way ahead.

Bruce Tognazzini is the OG GUI Guru of 80's user interface design!

https://asktog.com/atc/about-bruce-tognazzini/

Tog not just invented and implemented, but also deeply rationalized and documented a lot of great user interface techniques, like the "mile high menu bar", which partially exploits Fitts' Law (in the "up" direction), but made more sense on the original single small Mac screens. (While pie menus more fully exploit Fitts' law (in "all" directions") and they work great on large screens, giving you even more "leverage".)

https://www.joelonsoftware.com/2000/04/27/designing-for-peop...

>When the Macintosh was new, Bruce “Tog” Tognazzini wrote a column in Apple’s developer magazine on UI. In his column, people wrote in with lots of interesting UI design problems, which he discussed. These columns continue to this day on his web site. They’ve also been collected and embellished in a couple of great books, like Tog on Software Design, which is a lot of fun and a great introduction to UI design. (Tog on Interface was even better, but it’s out of print.)

>Tog invented the concept of the mile high menu bar to explain why the menu bar on the Macintosh, which is always glued to the top of the physical screen, is so much easier to use than menu bars on Windows, which appear inside each application window. When you want to point to the File menu on Windows, you have a target about half an inch wide and a quarter of an inch high to acquire. You must move and position the mouse fairly precisely in both the vertical and the horizontal dimensions.

>But on a Macintosh, you can slam the mouse up to the top of the screen, without regard to how high you slam it, and it will stop at the physical edge of the screen – the correct vertical position for using the menu. So, effectively, you have a target that is still half an inch wide, but a mile high. Now you only need to worry about positioning the cursor horizontally, not vertically, so the task of clicking on a menu item is that much easier.

>Based on this principle, Tog has a pop quiz: what are the five spots on the screen that are easiest to acquire (point to) with the mouse? The answer: all four corners of the screen (where you can literally slam the mouse over there in one fell swoop without any pointing at all), plus, the current position of the mouse, because it’s already there.

>The principle of the mile-high menu bar is fairly well known, but it must not be entirely obvious, because the Windows 95 team missed the point completely with the Start push button, sitting almost in the bottom left corner of the screen, but not exactly. In fact, it’s about 2 pixels away from the bottom and 2 pixels from the left of the screen. So, for the sake of a couple of pixels, Microsoft literally “snatches defeat from the jaws of victory”, Tog writes, and makes it that much harder to acquire the start button. It could have been a mile square, absolutely trivial to hit with the mouse. For the sake of something, I don’t know what, it’s not. God help us.

Another great technique he documented in the original Apple Human Interface Guidelines was the "drag delay" of popping up "pull right" submenus, to mitigate a problem that linear menus have, but pie menus don't. People keep forgetting and re-inventing it in sometimes better, sometimes worse ways, but he invented and implemented it for the original Mac, then most importantly documented it in the first edition of the Apple's 1987 Human Interface Guidelines, and the Mac UI still supports it. It's the kind of thing nobody notices if it works well, that's invisibly built into the toolkit, that nobody appreciates how much thought and nuance went into it, that deserves a lot of user testing and iteration to get right. (Or you could just use pie menus and not have that problem! ;)

https://news.ycombinator.com/item?id=39210672

>aidenn0 on Jan 31, 2024 | parent | context | favorite | on: Kando: The Cross-Platform Pie Menu

>>For example, while moving horizontally to a sub-menu, you can easily cross the width of a single line since it's not easy to move your mouse absolutely steady horizontally (in pro graphic apps you'd usually hold a Shift for that), so instead of moving to a sub-menu, you switch to another item. In a Pie menu that's much harder since as you move further the menu's area increases, so the tolerance is higher

>This is why properly implemented context menus don't strictly require you to move in a straight line. Implementations vary; I just tried it with the firefox context menu on linux and found that, once the submenu was open, I could move the cursor quickly to the submenu on any path, even taking a diagonal line to the most extreme options in it. I have also seen implementations where you had a ever widening path you could take as the cursor moved closer to the submenu, making the active area of the currently selected parent item trapezoidal.

>DonHopkins on Feb 2, 2024 | prev [–]

>That astonishingly clever technique was invented by Bruce "Tog" Tognazzini and described in the first edition of the Apple's 1987 Human Interface Guidelines (page 87, "drag delay").

https://news.ycombinator.com/item?id=32961306

https://archive.org/details/applehumaninterf00appl

https://andymatuschak.org/files/papers/Apple%20Human%20Inter...

>>Two delay values enable submenus to function smoothly, without jarring distractions to the user. The submenu delay is the length of time before a submenu appears as the user drags the pointer through a hierarchical menu item. It prevents flashing caused by rapid appearance-disappearance of submenus. The drag delay allows the user to drag diagonally from the submenu title into the submenu, briefly crossing part of the main menu, without the submenu disappearing (which would ordinarily happen when the pointer was dragged into another main menu item). This is illustrated in Figure 3-42.

>Implementations certainly do vary, but the point is that it's essentially a weird magical non-standardized behavior that isn't intuitively obvious to users why or how or when it's happening. It's extremely difficult to implement correctly (there's not even a definition of what correct means), and requires a whole lot of user testing and empirical measurements and iterative adjustments to get right (which nobody does any more, not even Apple like they did in the old days of Tog). Many gui toolkits don't support it, and most roll-yer-own web based menu systems don't. So users can't expect it to work, and they're lucky when it works well.

>Pie menus geometrically avoid this problem by popping up sub-menus centered on the cursor with each item in a different direction, so no magic invisible submenu tracking kludges are necessary. Don't violate the Principle of Least Astonishment!

https://en.wikipedia.org/wiki/Principle_of_least_astonishmen...

>I think it's important for users to intuitively understand how the computer is going to interpret their gesture, without astonishment, and for the computer to provide high fidelity unambiguous instantaneous feedback of how it will interpret any gesture.

>I like how Ben Shneiderman defined "Direct Manipulation" as involving "continuous representation of objects of interest together with rapid, reversible, and incremental actions and feedback".

https://en.wikipedia.org/wiki/Direct_manipulation_interface

>>In computer science, human–computer interaction, and interaction design, direct manipulation is an approach to interfaces which involves continuous representation of objects of interest together with rapid, reversible, and incremental actions and feedback. As opposed to other interaction styles, for example, the command language, the intention of direct manipulation is to allow a user to manipulate objects presented to them, using actions that correspond at least loosely to manipulation of physical objects. An example of direct manipulation is resizing a graphical shape, such as a rectangle, by dragging its corners or edges with a mouse.

>Those ideals also apply to pie menus. Pie menus should strive to provide as much direct feedback as possible, via tracking callbacks, previewing the reversible effect of the currently selected item (possibly even using the distance as a parameter), so you can easily use them without ever popping up the menu.

>For both novice and expert users, the directly obvious geometric way pie menus track and respond to input is more intuitively comprehensible, predictable, reliable, and most importantly REVERSIBLE than traditional gesture recognition (like Palm Graffiti, or StrokePlus.net) or "magical" kludges like the submenu hack.

>With pie menus there's a sharp crisp line between every possible gesture, that you can see on the screen.

>But with a gesture / handwriting recognition system, you wonder where is the dividing line between "u" and "v"? The neural net (or whatever) is a black box to the user (and even the programmer). Some gestures are too close together. And most gestures are useless syntax errors. And there's no way to cancel or change a gesture once you've started. And there's no way to learn the possible gestures.

>But with complex magical invisible submenu hacks, you wonder if it's based on how long you pause, how fast you move, where you move, what is the shape, why can't I see it, how does it change, what if you pause, what if my computer is lagging, what if I go back, what if I didn't want the submenu, how do I make it go away, why can't I select the item I want, what do I do?

>But with pie menus, if you make a mistake or it doesn't behave like you expect, you can at least see and understand what went wrong (you were on the wrong side of the line) and change it (move back into the slice you meant to select). No fuzzy gray area or no-man's-land or magic hand waving. And the further out you move, the more "leverage" and precision you have.

>The area and shape of each item target area should not be limited or defined by the font height and the width of the longest label. It should be maximized, not limited, to encompass the entire screen, all the way out to the edges, like the slices of a pie menu. If you move far enough, it's practically impossible to make a mistake, as the target gets wider and wider, so you can even use pie menus during an earthquake or car chase.

I thought the same thing of his website when he first hit the scene. Great info, but the design was so bad it made it difficult to read. It was quick though, and today’s reader view would have fixed that issue. Being usable doesn’t mean zero design; everything needs to work together.

I'm not sure that realization was great, given how often I have to scroll and scroll and scroll to find information on a business web site that should be front and center -- things like location, phone number, hours, etc.

There was also this guy, don't remember his name, whom you could email your questions/issues etc, reply with great detail and post the discussion on his website for others to learn from. Like a one on one precursor to stackoverflow.

I remember email him and asking about why my photo gallery didn't work when I tried to save the "currently selected image" as a cookie. He replied and explained to me that cookies contain string values and that you can't save a reference to a DOM element as a cookie. So, cookie = document.getElementById('image0') will not work, but cookie = 'image0' will :)

A group who never seem to be mentioned in these threads are Jason Arber, Richard May and Rina Cheung. Pixelsurgeon was enormously influential in its day.

I remember Shaun Inman, did he do Mint?

All those guys. Also, the daily visits to lnkedup.com k10k.net, designiskinky.com, newstoday.com were so influential and informative to me (wow, just did an archive.org lookup of some of those and got a nostalgic chill - https://web.archive.org/web/20050303092717if_/http://www.lin...).

> Does anybody ever say "man, this site has great information, I just wish it would bounce around my screen like a Jack Russell terrier."

I always find myself thinking "man if only this website would hijack my native browser scrolling...but terribly". Websites that don't hijack scrolling are just too useful and easy to use. Even better is when paragraphs fade-in as I scroll! Oh man I just love seeing shit jump around as I'm trying to read. It's so calming and doesn't induce seasickness at all!

Maybe the people implementing such things never accidentally saw off their fingertips. /s

Heh - I have been in many corporate and government environments where the desktop browsers are locked down via centralized policies, and not only is "View Source" disabled/removed, but so are the "Developer tools"...

He’s probably saying it with a bit of a wink and referring to this

https://www.malwarebytes.com/blog/news/2022/02/journalist-wo...

There are elements of truth in your comment, but it just seems weirdly derisive. The way the web evolved to where it is now happened in a similar fashion to games, through gradual improvement of the underlying platform and people try to do anything and everything with it before it was formally capable of doing it in a standardized way.

> Most of what these books teach is how to get the illustrator/coreldaw/quarkr approach and slap it on top of a webpage. How very little people experimented with the widgets already available to them such as pages, buttons, etc, the fact that it can show little, but be navigated.

People experimented plenty, but print was the start and ultimately those were the tools available at the time, and they were ahead of what the web was actually capable of. At a certain point, pushing the limits meant figuring out how to make rounded corners without rounded corner support or css, how to load images optimally, or debug. Game devs and porn industry absolutely pushed it past those limits, but also hardware got better, standards evolved. Many barely distinguishable bits of underlying primitive tech powers this website, and many others power YouTube, and Zoom, Gmail. It pretty much took until now to come up with decent design tools that sufficiently deal with designing for the complexity of the web.