The Anti-Mac User Interface (1996)
nngroup.com
nngroup.com
Alternately, you can say that UX design stabilized on a known good pattern.
This reminds me of how some people will refer to stable software projects that only receive the occasional security patch as "abandoned". They're not abandoned, they're just stable.
Anyway my point is that if you change all hammers in the world overnight (like software does) you better have done a good job of century-testing your changes in all situations. If your reasoning is just “it gets old”, well, this site’s rules do not allow me to express what I think of that.
[1] https://duckduckgo.com/?t=ffsb&q=hammer+nail+magnet&iax=imag...
Which does explain why OSHA says you have to wear safety glasses when nailing.
How "many of these tasks" can they reliably help you do? They screw up even the simplest tasks like setting a timer.
The framing hammer got heavier with a longer handle, broader face, straighter claw, and waffled face better for gripping nails (also why most loose framing nails have a cross-hatched pattern: so they can mate with the hammer face). From there, materials science really kicked in, and we saw steel-handled models, followed by fiberglass and other composite handles.
The latest developments (that I'm aware of) are products like the Stiletto (http://www.stiletto.com/p-80-ti-bone-iii-hammer-with-milled-...), which leverage materials like titanium to reduce weight while maintaining driving power, and include a replaceable steel face to prolong hammer life and allow using different faces for different applications.
Modern hammers with advanced material properties and functions can cost hundreds of dollars, but deliver much higher efficiency with less fatigue and a longer life. I compare that with the Sears hammer in my grandfather's garage and see a whole new generation of evolution.
There's a great article about hammer history at Fine Homebuilding: https://www.finehomebuilding.com/project-guides/framing/hamm...
edited: Fix link formatting.
Something that seems to be so simple, and has existed for thousands of years, can still be made better. I'm not a professional carpenter, but I've used a hammer a lot to do things like framing, and can confirm that many of these innovations are meaningful in function, not just form.
If you take a hammer from 1920 and lay it next to the most jazzed up hammer from 2020, they would be recognised as the same tool/having the same general purpose. A carpenter from 1920 wouldn't need to change the way he used a hammer if he picked up the 2020 model, even if the 2020 model might enable new ways of actually using it (or improve old ways of using it).
So while there is evolution and development going on, we're not replacing the hammer metaphor as it were.
The WIMP model has also seen evolution and refinement, but it's still recognisable as the same model. I think the analogy holds.
So, what's the line between inventing and refining?
If the idea behind a hammer is to use the momentum of a relatively large mass to drive a relatively small mass into a material, then the idea of a piece of steel on a handle is just the simplest thing you can manufacture as admittedly a versatile one but not necessarily the best one. If your task as the user is to join two materials together then hammer and nail won’t necessarily even look like hammer and nail (glue, screws). If the goal is to separate material like you might with a chisel, depending on the material you might not be using a manual hammer but something that looks very different, like a saw, a file, a jackhammer, etc.
What the person who mentioned the evolution of framing hammers is pointing out refinement of the hammer as it is. Creating a tool better suited to the user’s task is closer to what TFA is about.
It's not like we're bashing nails with bricks and calling it an MVP replacement to the hammer.
What you described isn't innovation, its iteration.
The point is the essential form and function has remained the same for thousands of years. Knives, forks, spoons etc. are still knives, forks, spoons etc.
I'm happy to see so many different people here in addition to programmers, techies, VC etc.
I work on (mostly non-critical) medical devices and I would like to remind that regulatory is there for a purpose.
If anything the 737 Max fiasco should remind people what can happen when regulatory is considered a cost that need to be cut in a field where there can be some hazards, and where some people in the chain do not have the best interest of the public in mind.
And yes, in the medical industry too, there can be some people who care more about optimizing profits than about patients.
Maybe there are some undue regulatory rules, but hopefully there are not the majority.
In the case of what I work on, regulatory does not prevent us from using state of the art CPUs and GPUs, so yes R&D may need somehow longer cycles from consumer electronics to get a return of investment, but let's be honest it is not too much scandalous to get some features a few years after you get similar things in consumer electronics, especially in cases where there are diminishing returns of improving X or Y.
And yes it is easier to build things when you don't have to care about e.g. ability to disinfect materials, you can cope with more bugs, etc.
UX/UI has the same issues. Everything is a metaphor anyway. You don't get to choose whether your interface is a metaphor, because there is no other option for interfaces. You only get to choose the type of metaphor, and its affordances - from hand-editing binary in a "file" (...which is also a metaphor) to voice recognition.
There are some good points in the article, but they're maybe 10% of the way to a full understanding of this issue. Most of the complaints are about inconsistencies and expert-level operation (written scripting) vs beginner-level operation. But there's also a point about contextual metadata.
Modern operating systems are pretty bad at all of the above, but that's because designing intuitive and powerful interfaces that incorporate expert-level features with some workable built-in intelligence - and preferably some form of composability - is incredibly hard.
It's so hard it's barely been attempted, never mind done successfully. So most operations in userland are explicitly task-oriented. Their settings are customisable, but not the menu of operations on offer.
As a non-expert if you want to rename a folder full of files, you buy a file renamer. You don't try to write a script, because even trivial scripting requires a level of comfort with abstractions that most users simply don't have.
Experts do have that skill level, but they can already use $scripting_lang.
It's possible to imagine an OS that would be more open-ended and wouldn't silo data inside task-oriented applications. But this runs into huge problems with efficient representations and the most appropriate schema for each domain, and just the concept on its own is far outside anything most users would want to deal with.
A lot of the critics of lack of innovation in computer UX design don’t want incremental improvements of the existing building blocks of modern UIs, they want to tear it all down and start from scratch. They want VR interfaces, Jeff Raskins The Humane Environment, Button-less UI, etc. They don't care about better hammers, they want nail screwdrivers or handle-less hammers.
Software does radically different things, things as different as, say, hammering and opening cans. It is difficult for me to believe that the WIMP interface as we know it is actually optimal for all those different software tasks.
I mean, sure, you could probably open a can with a claw hammer, if you used some care, and you might be even able to drive a nail with a can opener.
You wouldn't want to, though.
Note that we still drive cars by using steering wheels and foot pedals. We haven't gone to some "click on the menu item" interface, even though such an interface could easily be written for many modern cars.
Put me in the camp that believes that UIs are stuck in a rut, and need to be fundamentally rethought.
Raskin's humane interface had some interesting ideas, though it does not seem to have caught on.
Flat design is kind of like an extreme version of this. It's easy to build and change when needed.
I have no idea how to find out what I can do with Alexa, or which particular magic phrasing Alexa will understand.
My personal biggest issue, as means of illustration, is that I have no idea how to play the latest episode of something on the BBC app, rather than continuing from where I left off.
I'm sure there is a way, but none of my "natural language" attempts are recognised, and I can't find any way to find out what the true commands might be. Given that I mostly listen to news shows while doing something else (and hence rarely finish a particular episode) this makes the whole system near useless.
I may be missing something basic, or if you have any tips on the discoverability of Alexa commands, I'd be very grateful. But in my experience, the discoverability of voice commands is the worst I've ever come across; at least with CLI you have man pages, and with a GUI, even in the worst case of no documentation and obscure icons, there are buttons to explore through trial and error.
Not sure how bad/good Alexa is, but everyone (myself included) in my household are talking to Google and Siri all the time to do tasks that would have taken multiple clicks on a screen, and a bunch of typing. A huge reduction in friction. The state of the art isn't perfect, but as it improves, it's undoubtedly taking UX in a direction that is popular and desirable to consumers.
Or maybe known-good-enough: We evolved this specific design through a path-dependent fashion, so it could have been different had other designs survived, but nobody else has come up with a new UX paradigm which is sufficiently better to displace it yet.
Various kinds of large dinosaurs were dominant for millions of years, and birds still exist.
If you look at a lot of interfaces that are built for a specialized power user (e.g. cashiers), they avoid pointers and have keys for everything. Also, AutoCAD, the last I used it, looked to be centered around command-line primacy.
Magit[1] is another modern example of a TUI done right: discoverable, good dwim[2] inference that doesn't get in the way of experts, plus an escape hatch for typing out the exact git commands for those 5% usecases.
[2] do what I mean
I'm not saying that keyboard-based operation is superior in all cases, but a good keyboard-centric interface can eliminate the need to acquire a target (e.g. menu/toolbar item) for the most common operations because there's a hotkey. Well-understood operations can go almost at the speed of thought (either the operator's or the machine's).
I can say that this talk of using the keyboard being so fascinating that it takes up significant mental resources to be not represent my experience using and seeing others use keyboard-centric interfaces. When I use magit, or when I was operating the minilab I mentioned above, I don't have to think about what key to press to do the thing I want. I am in fact "so disengaged [with the mechanics of manipulating the interface] that [I] have been able to continue thinking about the task they are trying to accomplish". Competitive StarCraft is another example that illustrates the same point without relying on personal anecdote.
I imagine the next revolution in UI will be because our computers change form and present in a completely different way, for example a virtual assistant that lives in the cloud and talks to you via AR visualisations and plain old speech.
Revolutions are not usually a reworking of the dominant mode but a displacement to another medium - e.g. iphone replacing computers for many people.
It might be possible to do a smoother and more effective version now that we have CSS3 and all these cool transformations available.
UX, like evolution, once it goes down one particular path, tends to get stuck there, fiddling with the details at best. Radical innovation becomes really hard to effect: in evolution’s case because any new feature can only extend/adapt what is already there; in UI’s case because users tend to reject anything that doesn’t fit into what they already know.
It’s the distinction between stability and stagnancy. Stability is good in that it’s predictable; its benefit vs cost ratio is known. Stagnancy is not so hot: that ratio cannot (or will not) improve. WIMP is both stable and stagnant; trapped by its own early success with no obvious path forward.
.
Very relevant: after an early 8-bit dalliance I cut my adult teeth on Macs. Some of WIMP’s productivity gains were significant, but in other aspects it was just the same (or more!) drudge work in a cutsier skin. it wasn’t until I taught myself automation (via frustration and AppleScript) that I really put a decent dent in the latter.
And these were automations that built on my existing understanding of WIMP applications (unlike, say, the nix CLI which ignores all that knowledge and invents a whole new unrelated world entirely from scratch). All the Models were exactly the same; all my knowledge of how to manipulate my data in those apps was fully transferrable, not to mention all my existing documents. The only difference was the View-Controller I was using: RPC vs GUI. And whenever I got to a point in my workflow where it was easier/necessary to do something manually, I could freely switch back and forth between those two UIs.
Achieving 10x productivity gains over WIMP on frequent repetitive tasks is embarrassingly trivial* with even modest automations. The hard part is creating an automation UX that’s efficient and accessible to the large majority of less/non-technical users (AppleScript failed, but at least it tried).
.
When will we see another attempt? Dog knows. Voice tech like Siri is obviously trying, but is starting from the hardest end of the problem and trying to work back from there.
I believe there’s much quicker, easier pickings to be had by revisiting the AppleScript strategy—“server” applications exposing multiple View-Controllers for different interaction modes, and a really simple, textual “client” command language along the lines of Papert’s Logo (which 8 year-olds could learn how to use and compose), combined with modern auto-suggest, auto-correct, auto-complete to provide the transparency and discoverability that traditional CLIs fail so hard at.
The written word has 10,000 years of learning and practice behind it. And the most powerful word in the world is the word that expresses exactly what you want to say, whenever you want to say it. If that’s not an opportunity for some smart young coders with a desire to make a better world for all, I don’t know what is. You just gotta know history is all.
--
“It’s a curious thing about our industry: not only do we not learn from our mistakes, we also don’t learn from our successes.” – Keith Braithwaite
What Shortcuts does undeniably have is youth, looks, and an established following; and never underestimate the value of those. AppleScript may be built on a better technical foundation, but that don’t mean squat if it can’t bums on seats. And the bottom fell out the AppleScript market a decade ago.
However, being an outside product is absolutely no disadvantage. I’ll rate a passionate team of third-party devs with a vision over in-house chair-warmers going through vague motions with zero direction or objective. Being within Apple can be a huge advantage in that it offers prime positioning within the OS itself; but that’s of no use if you’ve got no clue how to deliver a desirable product and sell it to customers in the first place (<cough>Soghoian</cough>).
Whatever the strengths and weaknesses of their product, the Shortcuts team cut their teeth and proved themselves out in the real world. I don’t doubt Apple bought WorkflowHQ as much to get those people as their product. As change of blood goes that was badly overdue.
Web does not value menus and window manipulations either. I don't get it too, tiling window manager optimizes geometry, multiple desktops available by shortcut.
Shell is a manual mode of automation tool. It stores history, I can easily call previous command, combine several commands into new one.
> The see-and-point principle states that users interact with the computer by pointing at the objects they can see on the screen. It's as if we have thrown away a million years of evolution, lost our facility with expressive language, and been reduced to pointing at objects in the immediate environment. Mouse buttons and modifier keys give us a vocabulary equivalent to a few different grunts. We have lost all the power of language, and can no longer talk about objects that are not immediately visible (all files more than one week old), objects that don't exist yet (future messages from my boss), or unknown objects (any guides to restaurants in Boston).
Does this mean a commandline is always better, because it's more expressive? No, it's a trade-off between this and ease of learning:
> The GUIs of contemporary applications are generally well designed for ease of learning, but there often is a trade-off between ease of learning on one hand, and ease of use, power, and flexibility on the other hand. Although you could imagine a society where language was easy to learn because people communicated by pointing to words and icons on large menus they carried about, humans have instead chosen to invest many years in mastering a rich and complex language.
There's a neat coincidence that illustrates this tradeoff. While this article says:
> If we want to order food in a country where we don't know the language at all, we're forced to go into the kitchen and use a see-and-point interface. With a little understanding of the language, we can point at menus to select our dinner from the dining room. But language allows us to discuss exactly what we would like to eat with the waiter or chef.
Joel Spolsky's User Interface Design for Programmers (an excellent book, looks like it's available online in full on his blog: https://www.joelonsoftware.com/2001/10/24/user-interface-des...) says:
> Using a command-line interface is like having to learn the complete Korean language just to order food in the Seoul branch of McDonalds. Using a menu-based interface is like being able to point to the food you want and grunt and nod your head: it conveys the same information with no learning curve.
I'm pretty sure it's a coincidence that the same example of a restaurant in a foreign country is used, but despite apparent contradiction, they make the same point: The text interface requires more time to learn, in return for being more expressive and powerful. Whether that's worth it to you depends on how long you intend to live in that environment, and how rich an experience you'd like to have.
That analogy makes one significant assumption: that you are trying to order food from McDonalds, which is a thing you are used to doing at place you are already familiar with. Of course it's more difficult to learn Korean when you just want to order some American food, but what happens when you try to order Korean food? What if you are trying to do something more complicated than order food? There are cases where learning Korean would be clearly beneficial.
The limitations of GUIs stand out most in technical tools. When the thing a user is trying to do is already complicated, it doesn't really help to give them a simplified menu system: that just provides a frustrating amount of options.
There has been a significant prejudice in UI/UX design to optimize for approachability, even when expressiveness is a better target.
Ordering food is a great use case for "point and nod" UX. The pointing and nodding only needs to occur a small number of times. There is much more need for approachability than expressiveness. To contrast, editing text is a terrible use case. A point and nod system would involve a fatiguing amount of pointing and nodding. There are reasons that tools like Vim and Emacs are widely popular, even with their steep learning curves.
Then again, collaborative (open source) design is the workaround for monolithic software, and it's worked exceptionally well for Linux and Blender.
https://en.wikipedia.org/wiki/Archy
Archy clearly hails from the eighties when it was still imaginable to change users' workflow with desktop computers—that users would type a command while holding a special key (also apparently the author wasn't a touch typist).
The commands feature, isolated, was later adapted by Jef's son Aza Raskin, first as Enso (if I'm not mistaken), and then as a Firefox extension Ubiquity.
Also I've heard about some ‘pasteboard’ service as an alternative to a internal corporate wiki: you likewise zoom around and slap content anywhere on the infinite canvas. The trick, of course, is to keep the content organized thematically and tidy it up so it can be found later. Again, chances are slim that I will remember the name of the service now.
‘Rizzoma’, which is a clone of the late Google Wave, may also be seen as ‘zoomable’
The CLI is the opposite of the Mac in a lot of ways -- reality instead of metaphors, remember and type instead of see and point, make it a conversation, and so on.
For me, this was the signal that this as a "if only people used computers like I personally think they should" pieces. I know lots of people who play guitar hero, lots of people who play real guitars, and some who play both (me for one, mediocrely in both cases). I have met zero people who think guitar hero = guitar. They are different things that serve different needs.
I use a cli to compute all day, every day. Can't imagine using computers without one. I have no empirical proof of this, but I would be willing to wager the deed to my house that the vast majority of users, having been explained what a cli is, the benefits of it, and how to use it, would chose to never use a CLI again. It's not what they want, it's what other people want and it's a myopic view of what computing is.
If people could understand what computing was about, the iPhone would not be a bad thing. But because people don’t understand what computing is about, they think they have it in the iPhone, and that illusion is as bad as the illusion that Guitar Hero is the same as a real guitar. That’s the simple long and the short of it.
What’s interesting is, the computational ability of an iPhone is far beyond what we need to do good computing. What you wind up with is something that has enough stuff on it and is connected to enough stuff, so it seems like the entire thing.
"A combination of this 'carry anywhere' device and a global information utility such as the ARPA network or two-way cable TV, will bring the libraries and schools (not to mention stores and billboards) of the world to the home. One can imagine one of the first programs an owner will write is a filter to eliminate advertising!"
[Kay72] "A Personal Computer for Children of All Ages"
As stated, I agree.
But "ugliness" and unfamiliarity are big confounds here.
The fairer experiment would be something like: For tasks where a CLI app is a better fit than a GUI, would a person trained in the CLI and forced to use it for, say, a day (however long it took to become comfortable and see productivity benefits) then decide to keep using it, or go back to a GUI?
Imagine an office worker and some cumbersome workflow with excel, microsoft word, and GUI folders.
I think that if one could take a sufficiently aggregated superset of that from everyone on HN, one might very well come up with a philosophy of computing that actually is quite powerful.
In general I think the idea is that the computer is supposed to be a tool, in addition to a toy; with the awareness that playing with tools is often just as much fun as any toy could be, and conversely that a toy is a powerful way to learn.
> "Because people don’t understand what computing is about, they think they have it in the iPhone"
I agree this is myopic. I can use my iPhone to do a great many computing-related tasks; and when it is insufficient, it is certainly sufficient to reach out to a bigger, more powerful machine where I can do such things. As long as we retain the powerful (and not yet enshrined) freedom to connect things together over the Internet, your "computer" is not just whatever device you hold in your hands.
Its not like shell pipelines are really pipes between two processes or a filesystem is the same as a physical system of files.
A filesystem is fundamentally a way toorganize blocks of data on a storage medium. It consists of an actual physical medium with various attributes, which is used by a rule-driven system ("the filesystem") to decide where to put data (and conversely where to find it). It doesn't actually work in the same way as a paper filing cabinet, but in most operational senses, the two things are far closer together than they are different.
The CLI is not a metaphor - it's an abstraction. It removes details that you don't need to know about (mostly), but provides you with a way to operate directly upon the objects (concepts) known to the operating system that you are interacting with.
The classic Mac desktop described in TFA does consist of a lot of metaphors. Technically one can see this clearly in the way that the kernel of macOS isn't responsible for most of the way that desktop functions today: this is left to user-space services that create higher level objects for the user to interact with, leaving the kernel to deal with the same sorts of objects you'd describe with the CLI.
Or something like that.
If you open up your computer and get out your microscope, you're not going to find the pipe.
Computers are metaphors on top of metaphors. There's nothing wrong with that but you have to go way way down the abstraction tree before you are dealing with anything "physical"
> The CLI is not a metaphor - it's an abstraction.
I'm unconvinced there is a difference (other than abstractions being hardcore)
You should be able to, though. The pipe has a (OS) memory location, which, after a bunch of redirections, is an absolute location in memory, which is a bunch of capacitors and transistors. Now, you could argue that those redirections are akin to metaphors, though.
Except if they're just transistors because the representation of the pipe is sitting in static RAM for some reason, or in the fluctuation of a magnetic field. Or all of the above at the same time (caches, page files). Which one is the "real", non-metaphorical representation of the pipe? The one in the cache because it's being worked on by the CPU? The one in memory because its lifetime is longer?
Writing that on my wall.
Over the past year, I have revisited the SICP [0] and the audio recording of a one-week short course that Hal Abelson and Gerry Sussman taught for HP [1]. You nailed it.
[0]: "The Structure and Interpretation of Computer Programs", https://en.m.wikipedia.org/wiki/Structure_and_Interpretation...
(see also https://github.com/sarabander/sicp )
The fundamental abstraction/metaphor of the CLI is the file (especially in unix), where for a graphical system it is the "window". But the window has always been a weak metaphor. Windows are nothing like the thing outside the computer. Nobody understands them to be metaphors to physical windows. They are much closer to the computational object they represent (an area of i/o) than they are to a real window. Files on the other hand, are like their physical non computer counterparts. They are in fact much closer to real files than they are to a filesystem that's divided up into sectors or whatnot and distributed in the disk.
Does that mean from this definition, cli's are the metaphors and window systems are the abstraction?
But yes, it is also an abstraction of a set of related functions that manipulate or show data. It is even necessarily an abstraction of the computational objects it represents. But the sign(s) of the window points to physical/metaphorical objects.
Now the name "file" is also a metaphor. It represents (abstracts) a block of physical memory. But "file" is (or was) a sign for a physical thing made out of paper.
The metaphor of a file is on one hand useful, as it helps to understand physical memory as a set of objects we relate to in the outside world.
However it is also misleading: A real world file is typically immutable, to a high practical degree at least. We usually don't change files outside of correcting mistakes. We just add them and put a date. The file is first in "working" mode, then it is "done" quasi forever. To achieve the same with the computational object we need to impose constraints and/or discipline.
This may be true of our perception of “real life” too, of course, in which case computer interfaces are not something different, just an extra couple of layers
A pipe in the Linux kernel is a real thing. The name is metaphorical because it’s supposed to evoke the image of things flowing through it but that’s where it ends. A Linux pipe makes no effort to pretend that it behaves like a physical pipe. But it does abstract the implementation details about how data is sent to and retrieved from it.
An email program where the user is shown sheets of paper and envelopes is an illusion. The underlying implementation now has to modify its behavior to fit the physical properties of paper and envelopes to some degree. Letters only have one destination, CCing and BCCing now means copying and sending bundles.
It's all abstract, it's all metaphors.
By that argument, there really is a physical object corresponding to the desktop. That, too, is made up of pieces of memory.
> It consists of an actual physical medium with various attributes
Not necessarily. I mean, yes, ultimately it does because we live in a physical reality. But ultimately even I start think about a filesystem in my head it exists on a physical medium, my brain.
Are the trees that modern filesystem usually consist of nowadays actual trees growing in my computer, or are they metaphors? Named after their biological counterpart because they roughly look and act like them in very specific aspects? Like a desktop, or a window?
Are the "folders" or "directories" that you interact with in your shell actually those pieces of objects, or are they a metaphor?
> The CLI is not a metaphor - it's an abstraction. It removes details that you don't need to know about (mostly), but provides you with a way to operate directly upon the objects (concepts)
I don't see the distinction. The desktop provides you with a way to operate directly upon the objects/concepts of the OS. In both cases, there is usually a multitude of abstractions before you reach any actual physical object.
> the way that the kernel of macOS isn't responsible for most of the way that desktop functions today [...] leaving the kernel to deal with the same sorts of objects you'd describe with the CLI
You mean the same way the kernel is not responsible for the way the CLI functions?
Why is an open() system call (which can refer to numerous virtual, abstract, immaterial things) more "real" when the piece of memory it has been passed has been collected through a multitude of abstractions and maybe originated from a sequence of keystrokes on a keyboard via USB, than if it had been collected through a multitude of abstractions and maybe originated from a sequence of mouse movements via USB?
We touch on metaphors in this section: https://clig.dev/#conversation-as-the-norm
If you’re talking about how to design a command line for usability, you really need to become familiar with them, as usability and extensibility were explicit design points and they both work very differently than (and much better than) even modern UNIX.
They should have come up in whatever literature search you did prior to writing your piece. At least you can easily investigate both of them via preserved documentation and emulators, if you don’t have access to hardware on which to run them: There’s an x86-64 build of OpenGenera floating around you can run on Linux, and you can run VMS in SIMH. And Kalman Reti did a great demo of Genera on YouTube.
Applications and files alike, filed on the same bookshelf. A very easy metaphor that makes it easy to explain how computers work, but also locate files that you use often (perhaps by size, shape, colour and location) without using the part of your brain that processes language.
Humans are spatial creatures, so I'd like to think that perhaps everything being in lists doesn't make sense and that's why we hate using them to find something.
The traditional notion of the Desktop is a bit like this, but the presentation is messy. There's no nice way to order your desktop, and everything is the same size and shape. Despite this, many people work solely from their Desktop.
Edit: It would be very interesting to have a check in/check out system where you can drag files on the shelf to your "working box", or check them out, or whatever. Basically the equivalent of your desktop. This gives you fast easy access to files from a variety of locations for whatever job you're doing. When you're done working with them, you can check them out, and poof they go back to wherever you got them from. This is an awesome physical metaphor to a library where the clerk does all the work for you in returning the books. This box could also give you a good metaphor for moving files, and cut/copy/paste. Move to box -> put back on the shelf elsewhere. Or, move to box -> duplicate -> put copies back on the shelf and send the originals back.
As a side note, this caused me to throw Ubuntu on a desktop/laptop for a few of the people who needed the most support, and within a month they didn't need any help and were trying to get me to install it on their friend's machines.
Seriously, I was constantly being asked by old ladies to start an underground Ubuntu support network. They just needed a way to browse the web, upload photos to facebook, and play farmville. That was it, that's all they wanted to use it for.
If I were to do it again today I'd use ChromeOS probably.
I don't have much experience with the zooming stuff, but I did use Nautilus heavily then (see also Siracusa's Mac-focused discussion here: https://archive.arstechnica.com/paedia/f/finder/finder-1.htm). As soon as you got used to it, it was amazing -- accessing files felt natural in a way it just doesn't in other systems. It was both digital and leveraged our natural understanding that things are at particular places. It's no surprise people still miss it.
A few people, of course. A very large majority of people absolutely hated it, and it's widely considered a huge mistake now. Familiarity and habits win out, users hate changing paradigms and unlearning habits.
Imagine an open floor plan with a hundred programmers or administrators shouting code and commands at their giant, flashing 52" screens all day, having to raise their arm in some ergonomically counter-indicative way each time they need to swipe a pop-up ad away from their vision.
I know what a general purpose computer is. I know how to control it. Without a reasonable interface to do so, being completely at the mercy of some "UI visionary" (probably the kind who decided we shouldn't be able to change the default fonts in programs made for text messaging), it'll be even more useless to me than most modern UI:s already make it.
You can stream the documentary for free on Kanopy (with a library card from a participating library) here:
I don't actually think the ideas of things like Bob were bad, though, I just think they were cumbersome. Using the post office example, a top down map would solve everything, and be close enough a "start menu" that a totally fresh user might feel confident trying a computer without balancing wheels.
All of these visions feel like they stem from TMoAD. Does anyone make inspirational concept films for industry/academia/etc like these anymore?
https://web.archive.org/web/20120206012754/http://counternot...
The article might be a bit aggressive on suggesting that language _replace_ icons, rather than augment them - but it seems just as likely that we're still in the middle of the transition and assistants being built from the ground up without icon-based UIs is exactly what the article is predicting.
Over time new concepts emerge which are based on metaphors native to the digital space and understood by the new generations.
The really good ones are learned early and are highly conserved across time and culture.
Ooof, and here we are, 25 years later, with an intervening opportunity to completely redefine HCI (smartphones), and it's still basically all WIMP.
https://www.nngroup.com/articles/pdf-unfit-for-human-consump...