Tog on interface
Explores the central issues of user interface design, including the problems presented by multimedia applications. It is a unique treasury of ideas and opinions from one of the key thinkers in the industry. It will be required and fascinating reading for all those concerned with the relationship between computers and people.
Stats for nerds
10recommend
17mentions
14people
2010–2026years
65% recommend35% neutral
Mentions per year
What Hacker News says
- It's well worth watching that entire video, in which Bill Atkinson dropped many profound mind blowing ideas in his talk to Brad Myers' user interface students on February 4, 2019:
https://www.cs.cmu.edu/~bam/uicourse/05440inter2019/Bill-Atk...
At 1:02:26, a student asked Bill Atkinson what was his biggest joy when making Macintosh, and he replied:
Bill> I was pretty excited when I moved the menus to the top of the screen, and suddenly it just clicked. Like, ok, we have the full width, the full height, there is this kinesthetic reaching over for this place. The pull down menus moving to the top of the screen, I though, yeah, this is doing to work!
Then at 1:03:10, a student asked:
Student> I have a question about HyperCard. What was the impetus for that [Bill smiled and chuckled], and like, how did, or what you build the um, motivation to like do that, because it was a kind of odd thing at the time...
[Bill beams and reaches off screen to find some papers]
Bill> How many of you guys have done a psychedellic?
[Class laughs, Bill grins] [Brad: no hands!]
Bill> In 1985 I swallowed a teenie fleck of gelatin containing a medium dose of LSD, and I spent most of the night sitting on a concrete workbench outside my home in Los Gatos, California. I gazed up at a hundred billion galaxies, each with a hundred billion stars, and each star a giant thermonuclear fusion reaction as powerful as our sun.
And for the first time in my life I knew deep down inside that we're not alone. I knew that life on Planet Earth is not the only pocket of consciousness in the universe, and likely not the most advanced, but we still have a role to play in the unfolding drama of creation.
It seemed to me that the universe is in a process of coming alive. Consciousness is blossoming and propogating to colonize the universe. And life on Earth is one of many bright spots in the cosmic birth of consciousness.
But the stars are separated by enormous distances of darkness and vacuum, which may hinder communication between them. I lowered my gaze and saw the street lamps below, glowing brightly, each casting a pool of light, but surrounded by darkness before the next lamp. As above, so below.
The street lamps reminded me of bodies of knowledge, gems of discovery and understanding, but separated from each other by distance, and different languages.
Poets, artists, musicians, physicists, chemists, biologists, mathemetitions, and economists, all have separate pools of knowledge that are hindered from sharing and finding the deeper connections.
My vision distorted by thick eyeglasses, I witnessed the curvature of the Earth's horizon, and I felt the pull of gravity towards its center, such that every one of us is standing at the very apex.
Each of us stands at the top of planet Earth, and each of us is a leader or captain of the Blue Marble team.
How could I help? By focusing on the weak link. If I were captain of a soccer team, I'd look for the weak link, and work on it. If the goalie was letting too many through, I would spend extra practice time with him, and the whole team would prosper.
It occurred to me that the weak link for the Blue Marble team is wisdom. Humanity has achieved sufficient technological power to change the course of life and the entire global ecosystem. But we seem to lack the perspective to choose wisely between alternative futures.
But I was young, without much life experience or wisdom myself. Knowledge it seemed to me consists of the "how" connections between pieces of information. The cause and effect relationships. How does this action bring about that result?
Science is a systematic attempt to discover the "how" connections. Wisdom, it seemed to me, was a step further removed. The bigger perspective of the "why" connections between pieces of knowledge. Why, for reasons ethical and aesthetic, should we choose one future over another.
i thought that if we could encourage sharing of ideas, between different areas of knowledge, perhaps more of the bigger picture would emerge, and eventually, more wisdom might develop. Sort of a trickle-up theory of information, leading to knowledge, leading to wisdom.
This was the underlying inspiration for HyperCard: a multimedia authoring environment that empowered non-programmers to share ideas, using new interactive media called HyperCard Stacks.
Each card in a HyperCard stack included graphics, text, interactive buttons, and links that took you to another card or stack. Built-in painting tools, drag-and-drop authoring with a library of pre-fab buttons and fields, and simple event based scripting, made HyperCard flexible and easy to use.
It took a lot of hard work and a dedicated team to complete this mission. Apple shipped HyperCard in August, 1987, and included it free with every Mac, so any user could create and share HyperCard stacks.
Many creative people expressed their ideas and passions, and several million interactive HyperCard stacks were created.
HyperCard was a precursor to the first web browser, except chained to a hard drive before the World Wide Web. Six years later, Mosaic was introduced, influenced by some of the ideas in HyperCard, and indirectly by an inspiring LSD experience.
[Class laughs]
So that's, honest, that's where the idea for HyperCard came from. And uh, and I, I'm not, like, advocating that every software designer should go out and take LSD, but it worked for me.
----
That was a tough act to follow, but the next week I gave a presentation about pie menus and Fitts' Law to Brad's UI class on February 11, 2019:
https://www.cs.cmu.edu/~bam/uicourse/05440inter2019/Don-Hopk...
At 5:20 I mentioned Wiseman's 1969 PIXIE paper, the earliest known implementation of radial menus that ran on a PDP-7 with a 340 vector graphics display and light pen. Since then I've unearthed the paper, two films, and 128 pages of PDP-7 assembly language source code written by Heinz Lemke, which I've since reincarneted with a PDP-7 emulator:
PIXIE SIMELEC (1972) on PDP-7 and 340 Display emulator:
https://hyperties.org/cabinet/symelec/
Flight of the PIXIE - Yuja Wang:
https://www.youtube.com/watch?v=jDrqR9XssJI
PIXIE and FORTH on PDP-7 Cabinet Emulator with Type 340 Vector Graphics Display:
https://www.youtube.com/watch?v=lo8kdY-5i6c
As an homage to Bill's HyperCard story, at 37:11 I trolled Brad and his recently-shocked students by asking the class:
Don> One thing I wanted to ask the class: Have any of you ever used ...[dramatic pregnant pause]... HyperCard?
Then I told my own story of how in 1987 HyperCard blew my mind and changed my world.
More on the "Mile High Menu Bar":
https://news.ycombinator.com/item?id=44125835
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
[...]
- I adore Tog on Interface by Bruce Tognazzini, who led the earliest editions of Apple's HIG. He explores ideas that have been lost to time, like tailoring an interface to a user's personality.
- You must be too young to remember because a lot of the early user interface design principles, based on actual research, were pioneered by Bruce Tognazzini and Jef Raskin at Apple. Tog on Interface and Tog on Software Design were THE bibles back in the day and Apple's Human Interface Guidelines showed how a company could and should adopt consistent user experience across all of their products.
It honestly saddens me how far Apple has fallen.
- 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've called this ritual-taboo programming for decades. It happens for user interfaces and APIs when the documentation is absent, or only consists of examples. If there's no reference documentation, everything is a copy of something someone else did. Nobody understands how it really works.
Now, for some interfaces, this isn't too bad. Most people don't know why US AC power plugs are polarized, or what the ground prong is for. Electricians have to, but users do not.
For more complex interfaces, it means that many functions will either be misused or undiscovered. This is the source of the plaint that only 10%-20% of a product's features are used.
On user interface design, the classic is "Tog on Interface", Bruce "Tog" Tognazzini, 1992. That's from the Mac UI era. A more modern take is "The Gamer's Brain", by Celia Hodent, designer of Fortnite's UX.
Software internal documentation seems to suffer today from a mindset that comments are unnecessary and waste space. Especially in the Javascript era. It's worst in languages that don't have data declarations. There's no place to properly document the data.
Rust has good conventions and tools for documenting data. There's a well defined place where the documentation for each structure and field goes, and reasonable tools for checking it and turning that into documentation. If you fail to do this, when you publish your crate on crates.io, the documentation pages will come up blank, which screams "loser".
Rust is weak on function parameter documentation. There should have been a defined place where each formal parameter gets a comment, which then appears in the documentation of the call.
Most other languages don't take such a hard line. More should.
- Interface design is not about specific APIs.
Old books about Windows or Mac programming have all sorts of information that has apparently been mostly lost.
Two books I remember, perhaps not the best, but definitely with information that transcends specific technical details, are Bruce Tognazzini's Tog on Interface (or Tog on Software Design), and Charles Petzold's Programming Windows 95. The original "Inside Macintosh" series also comes to mind.
Related
Tog on software design
4 recommend · 8
Designing the user interface
3 recommend · 7
Macintosh human interface guidelines
10 recommend · 37
2011–2026
Linux Programming Interface
98 recommend · 156
Software tools
21 recommend · 44
User Interface Design for Programmers
18 recommend · 26
