21–30 of 156 posts
I think that using a bookcase that can be spatially ordered (in 2 dimensions) would be a really interesting concept for an operating system. 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.…
You can stream the documentary for free on Kanopy (with a library card from a participating library) here:
> At recent user interface conferences, several speakers have lamented that the human interface is stuck. We seem to have settled on the WIMP (windows, icons, menus, pointer) model, and there is very little real innovation in interface design anymore. Ooof, and here we are, 25 years later, with an intervening opportunity to completely redefine HCI (smartphones), and it's still basically all WIMP.
I guess we have gyros, and cool audio processing and I think there have been decent UIs that use them.
Maybe AR will change things on this front?
This inspired some of our design principles in the CLI Guidelines: https://clig.dev/ 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.
Its not like shell pipelines are really pipes between two processes or a filesystem is the same as a physical system of files.
I think that using a bookcase that can be spatially ordered (in 2 dimensions) would be a really interesting concept for an operating system. 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.…
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.
On other OS designs: “ They are navigationally cumbersome, asking users to go to the "other end of town" to pick up their email from the Post Office” Made me laugh, it seems silly now, but that’s a pretty creative way of describing what’s going on.
When I was a kid, I remember the Max my family owned have several different UIs you could enter in to. I think maybe the idea was that some of them were more kid friendly? When I saw those pictures in the article it took me back to that time.
This inspired some of our design principles in the CLI Guidelines: https://clig.dev/ 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.
I don't think the cli is any less of a metaphor than the desktop is. Its just a different metaphor. 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.
> At recent user interface conferences, several speakers have lamented that the human interface is stuck. We seem to have settled on the WIMP (windows, icons, menus, pointer) model, and there is very little real innovation in interface design anymore. Ooof, and here we are, 25 years later, with an intervening opportunity to completely redefine HCI (smartphones), and it's still basically all WIMP.
On other OS designs: “ They are navigationally cumbersome, asking users to go to the "other end of town" to pick up their email from the Post Office” Made me laugh, it seems silly now, but that’s a pretty creative way of describing what’s going on.
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.
This inspired some of our design principles in the CLI Guidelines: https://clig.dev/ 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.
I don't think the cli is any less of a metaphor than the desktop is. Its just a different metaphor. Its not like shell pipelines are really pipes between two processes or a filesystem is the same as a physical system of files.
We touch on metaphors in this section: https://clig.dev/#conversation-as-the-norm