IIRC Bill Atkinson said that it is at the top because it was easier to code. at any rate, it’s true that screen edges and corners are easy to click because their hit region becomes infinite in one or two directions
In this video Bill explains why he moved it. At 28 min he says: "…and if the window is near the bottom, how are you going to show all the choices? Well, I tried moving the menus to the top of the screen."
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:
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:
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:
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!
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".)
>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! ;)
I would really like to see an opensource or freely accessible version of HyperCard which does user interface right. Still annoyed by the rug-pull the LiveCode folks did for their opensource version and wish that the OpenXTalk folks would get some traction.
One of the most effective menu implementations ever for me was Altsys Virtuoso on NeXTstep's right-click (to pop-up the main menu at the mouse cursor), drag-down to Modify, then drag right to "Punch" or "Union" (whichever was the top command) --- it was a command I did a lot and it was almost gestural, kind of lke a well-done pie menu.
FWIW, the current Windows Start menu at lower-left, while not drawn to the corner now allows one to click the corner to open it, lower-right is "Show Desktop" and upper right closes the current maximized window --- only upper left is at the mercy of whatever app is currently running.
One criticism I have of HyperCard is that it wasn't "HyperCard All The Way Down", in that not all the rest of its dialogs and user interfaces and menus were made out of HyperCard stacks. It wasn't "metacircular", defined in terms of itself.
That's totally forgivable given that HyperCard was the first original iteration, and "merely" getting it finished in time to ship on every Mac desktop was a spectacular achievement. But it doesn't excuse anything that came after it, and it doesn't excuse Apple for dropping it instead of evolving it.
Cyberdog for OpenDoc was another interesting approach to a web browser, built out of components you could embed in documents, but Apple dropped that along with OpenDoc too:
Looking back 30 years, that demo is unintentionally hilarious, and it makes me wonder what HyperCard would have been like if Apple had continued to develop it as much as it deserved.
>You always want to end a report with some pizzazz, and these days, nothing is more pizzazz than Java. So over here I have a Java applet, and I want to put it into Claris Works. [...]
>It's actually a little bit different than that. Rather than just being FreeHand it's actually Shockwave for FreeHand, and what we're running here is the Shockwave for FreeHand Netscape Plugin running inside of an OpenDoc Part that can run any Netscape Plugin. So because it's -- [applause] -- it's a little complicated...
Bottlenecking every event and pixel through the Stone Age nascent NPAPI to see Duke waving at three frames a second was not the flex they thought it was.
>The event handler never gets mouse motion or mouse up events, so I had to track the mouse motion and button release manually by checking the button status in the idle callback.
HyperLook, which was written in PostScript for the NeWS Window System, was deeply inspired by HyperCard, and addressed the "All The Way Down" problem, as well as Atkinson's admitted limitation of being chained to a hard drive instead of networked.
All of HyperLook's property sheets, dialogs, popups, help windows, menus, etc, were defined in terms of itself, editable and replaceable.
The PostScript graphics editor was a component you could use in your own stacks to edit graphics, like a clock's face and hands, and you could copy ("capture") any user interface as editable structured graphics, which made it easy to illustrate the documentation:
Even the user interface editor itself was a replaceable component, so you could plug in different kinds of user interface editors, or remove it completely to deliver a non-editable runtime system (like SimCity).
The other thing that HyperLook added was another layer in the event delegation system: Button => Card => Background => Stack => Client. The client being what we would call a "web server" or "distributed application" now, implementing what we call the "AJAX" architecture now.
I developed SimCity and HyperLook together, each one a forcing function for the other, and I'm taking the same approach now with reincarnating HyperTIES, Ben Shneiderman's pioneering hypertext system from the University of Maryland:
"It is an unworthy design objective to aim for anything less than trying to do to the Macintosh what the Macintosh did to the previous state of the art." -Bill Buxton
The "Natural" Language of Interaction: A Perspective on Non-Verbal Dialogues, INFOR: Canadian Journal of Operations Research and Information Processing, 26(4), 1988, pp. 428–438.
>Before going too much further, it is probably worth making a few comments about my approach and my examples. As will become pretty evident, the Apple Macintosh takes a bit of a beating in what follows. Some readers may view this as evidence of contempt for its design. From my perspective, it is evidence of respect. Let me explain.
>User interface design today is plagued by an unhealthy degree of complacency. We live in a world of copy-cat unimaginative interface products, where major manufacturers put out double-paged colour spreads in Business Week announcing "... our system's user interface is as easy to use as the most easy to use microcomputer [i.e., the Mac]" (or words to that effect). In what other industry can you get away with stating that you're as good as the competition, rather than better? Especially when the competition's product is over 4 years old!
>The best ideas are the most dangerous, since they take hold and are the hardest to change. Hence, the Macintosh is dangerous to the progress of user interfaces precisely because it was so well done! Designers seem to be viewing it as a measure of success rather than as a point of departure. Consequently, it runs the risk of becoming the Cobol of the 90's.
>I criticize the Macintosh precisely because it is held in such high regard. It is one of the few worthy targets. If I can make the point that there are other design options, and that these options appear to have a lot of potential, then I may help wake people up to the fact that it is an unworthy design objective to aim for anything less than trying to do to the Macintosh what the Macintosh did to the previous state-of-the-art.
>Enough of the sermon. Let's leave the pulpit for some concrete examples.
I would believe this, "single menu bar at the top, just update the values" is absolutely the solution you reach for when you're writing assembly by hand on an Apple II. It's hard to imagine but that UI element has been around since it started showing up in preview articles in ~1981
It's not that he changed his mind. He said there: "The kind of expectations I have is that people do their best and I expect people to understand what they are doing. But that understanding has very little to do with what tools they use."
They do have answers in Firefox. Maybe your setup is bugging out. I clicked through them, and all of them had answers.
Is Muse free?
Muse is available for free with a usage limit. If you reach your free limit and want more, you can upgrade to a paid subscription, or wait until your free usage limit refreshes.
That might just be from developers getting a Figma of a FAQ section without final copy, then Meta not doing adequate QA and shipping empty FAQ sections.
There's room for improvement still. Currently, the production build is using long-dev class names. e.g. `DirectoryContent-module__Box_3__gl6dE` could be compiled to a shorter hash like `gl6DE3a2`.
You could also drop the hash part and gain most of that improvement. Or module and hash and do better on compression (because the hash is high-entropy).
${local}: 52610 raw, 7927 br. (Now in practice a few of these are likely to need disambiguation, so it’s probably a tad smaller than realistic.)
Frankly I think ${local} is the right target, with global disambiguation where necessary. For typical systems, I consider the hash approach to be foolish: its value is when interacting with unknown other styles, but when you’re compiling everything you should know everything, so you can disambiguate more selectively and succinctly/compressibly, as JS build tools like Rollup do (in flattening modules with colliding names, you’ll get Foo, Foo$1, Foo$2, &c.).
> ${local} is the right target, with global disambiguation where necessary.
How?
---
Another approach is using base52 sequential names, such as `aa, ab, …`. I tried that a few years ago in Webpack, I don't remember but there was an issue, IIRC they weren't deterministic.
Compile everything together and you know what names are used. I can’t comment on whether it’s easy or even possible with the specific toolchain in question, but the concept is very straightforward.
The only thing hashing classes achieves is making it difficult for users to use ad blockers and/or custom CSS. I understand why e.g. Meta does it on their sites, but for GitHub it makes no sense.
Recently, I was screen-interviewed for coding speed with a fairly easy project. The company used a 3rd party platform which gave me 90m to complete 4 levels, each one building upon the other.
I think that was a nice test, but the platform is too buggy to recommend.
> In contrast, bug reports to a typical end-user application go into a black hole from the moment they’re submitted.
True, but not always, I've heard PMs saying: "this was a user-submitted bug", meaning you better fix this ASAP.
But yes, for the most part they don't like it. I recall reporting a bug and then they obfuscated their SPA bundle.
Funny enough, today I spent like an hour thinking: should I report this, should I ever report bugs at all. It was a P0 but I didn't report it, and I noted it as my first time considering giving up on my career.
Last week I reported a list of medium-bugs and I ended with: "I'm not sure if you'll ever read this, so I'm not adding more details that could help you debug, but feel free to reach out…" They responded: "We will share this feedback with the appropriate team. No further action is required on your end. Your ticket 124443 is solved. Please rate us!"
> I've heard PMs saying: "this was a user-submitted bug", meaning you better fix this ASAP.
There are certainly developers with a practice of triaging and action user-submitted reports, but unfortunately it’s opaque to the one who reported it.
reply