Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Anti-Mac User Interface (1996)

nngroup.com

Post reply on HN
Print view View original

41–50 of 156 posts

Re: The Anti-Mac User Interface (1996)

#41

Post by dafoex »

dafoex wrote: post #37

I recall reading this and some related papers a while ago, and for the fun of it I tried my hand at mocking up a UI based on the ideas laid out. The basic premise was that the application menu was replaced with a "new document" menu (like Google Drive has) that would take you to the relevant place to get things done automatically. Standard apps could still be run, but like you might go "new>text document>template" yo…

Oh, feel free to run with any ideas of mine if they strike a chord. I'm not competent enough to tackle making a whole DE just to satisfy my curiosity at this moment.

Re: The Anti-Mac User Interface (1996)

#42

Post by xixixao »

bfirsh wrote: post #12

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.

Good web design and content. This is useful. It's mostly basics but even those can be very helpful to have on a single page. Thanks for the resource!

Re: The Anti-Mac User Interface (1996)

#43

Post by Spivak »

bawolff wrote: post #31
PaulDavisThe1st wrote: post #27

Earlier quoted context omitted.

A pipe(2) in Unix is actually a piece of memory arranged so that it can be used as a FIFO, written and read to. There really is a physical object corresponding to the pipe, and the "|" refers directly if tersely to that object. 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…

> There really is a physical object corresponding to the pipe 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 differenc…

Abstractions aren’t illusory, they are definitions that ideally make things easier to reason about.

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.

Re: The Anti-Mac User Interface (1996)

#45

Post by anyfoo »

Phrodo_00 wrote: post #34
bawolff wrote: post #31

Earlier quoted context omitted.

> There really is a physical object corresponding to the pipe 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 differenc…

> If you open up your computer and get out your microscope, you're not going to find the pipe. 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.

Or I could argue that I could ultimate find the capacitors and transistors for anything else we're talking about here.

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?

Re: The Anti-Mac User Interface (1996)

#46

Post by burnte »

amyjess wrote: post #38

> 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. 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…

I completely agree. The design of a hammer hasn't changed much in centuries because it's already designed well for its purpose. Same thing with sharks, I don't hear biologists say "there hasn't been much innovation in sharks for millions of years."

Re: The Anti-Mac User Interface (1996)

#47

Post by anyfoo »

Spivak wrote: post #43
bawolff wrote: post #31

Earlier quoted context omitted.

> There really is a physical object corresponding to the pipe 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 differenc…

Abstractions aren’t illusory, they are definitions that ideally make things easier to reason about. 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…

So do emails themselves. It's in the name: it's "electronic mail". The underlying implementation has modified its behavior to fit the physical properties of how letters usually work to some degree. You think an email is something different than a text message, or a Slack message, or even a website or a video, when it is information that reached you by electrons moving a certain way in a wire. Or multiple wires. Or electromagnetic fields in space. Or photons in strands of glas or plastic.

It's all abstract, it's all metaphors.

Re: The Anti-Mac User Interface (1996)

#49

Post by PaulDavisThe1st »

dgb23 wrote: post #35
bawolff wrote: post #31

Earlier quoted context omitted.

> There really is a physical object corresponding to the pipe 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 differenc…

As I understand it, the difference is that an abstraction is a sign for a computational object. A metaphor is a sign for something else, outside of the computer, and only indirectly related to the computational object it represents.

Thank you! Put very precisely and, IMO, accurately.

Re: The Anti-Mac User Interface (1996)

#50

Post by fbelzile »

amyjess wrote: post #38

> 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. 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…

I agree, these new metaphors survived the test of time. Probably because of it's flexibility and ability to change to user requirements.

Flat design is kind of like an extreme version of this. It's easy to build and change when needed.

Post reply on HN