The Anti-Mac User Interface (1996) • Hacker News Board

Re: The Anti-Mac User Interface (1996)

#151

Post by burnte » Sun, Dec 13, 2020, 3:25 AM UTC

capnahab wrote: post #102

brownjohnf wrote: post #77

Earlier quoted context omitted.

The design of a hammer has actually changed substantially over time. More recently, there's been a trend towards specialization in the framing hammer alone. 100 years ago most hammers looked like the classic hammers I remember from childhood: relatively small, sharply curved claws, a smooth face. As production framing exploded in the US after WWII, framers were pushing for more efficiency. The framing hammer got heav…

Noted. What has been stable for a long time and remains frustratingly static and unrefined is the field of surgcial instruments. There are a few exceptions but most haven't changed in the 20years I have been a surgeon. The regulatory costs of developing new instruments and intertia of manufacturers doesnt help. Once a manufacturer gains a market share they try and keep by not innovating which keeps their deveopment c…

Half of that is the manor manufacturer, and the other half is the FDA. These huge companies that can afford lots of money intentionally get the FDA to set a high bar with lots of expensive testing in the regulations. This creates a HUGE barrier to entry. Right now I'm working with a pathology lab who are buying a pathology slide scanner. This is basically a slide handling robot with a high end camera hooked to a PC with an image viewer. The combined system costs over $300,000 from companies like Leica and Philips. The software is incredibly basic, it's basically Thumbs Plus with Irfanview and that's $100,000 alone, aside from the scanner. But they charge that because it's incredibly expensive for a startup to come in and challenge their pricing.

Re: The Anti-Mac User Interface (1996)

#152

Post by astrange » Sun, Dec 13, 2020, 7:21 AM UTC

andreareina wrote: post #138

astrange wrote: post #135

Earlier quoted context omitted.

The research done for the original Macintosh UI showed that keyboard users aren’t actually faster than mouse users, but think they are because they lose track of time while concentrating.

Do you have a link? I suspect there's some asterisks there. I used to operate a photo minilab and could process a roll's worth of photos in 1-2 minutes. That's 4 seconds at the outside to evaluate a photo, make brightness and color corrections, next photo. No way I'd be able to sustain the same rate by having to mouse around and click at least four different targets, bouncing from brightness to magenta/green to blue/…

https://www.asktog.com/TOI/toi06KeyboardVMouse1.html

Re: The Anti-Mac User Interface (1996)

#153

Post by Privacy846 » Sun, Dec 13, 2020, 9:59 AM UTC

eschaton wrote: post #51

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.

I haven’t read your piece yet, but I searched the page and didn’t find any mention of DEC VMS’s DCL, or Symbolics Genera’s Dynamic Listener. 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…

That “Cli Guideline” seems to be written by people who are enarmored with terrible shells like Bash.

Re: The Anti-Mac User Interface (1996)

#154

Post by andreareina » Sun, Dec 13, 2020, 10:20 AM UTC

astrange wrote: post #152

andreareina wrote: post #138

Earlier quoted context omitted.

Do you have a link? I suspect there's some asterisks there. I used to operate a photo minilab and could process a roll's worth of photos in 1-2 minutes. That's 4 seconds at the outside to evaluate a photo, make brightness and color corrections, next photo. No way I'd be able to sustain the same rate by having to mouse around and click at least four different targets, bouncing from brightness to magenta/green to blue/…

https://www.asktog.com/TOI/toi06KeyboardVMouse1.html

Thanks for the link. Unfortunately without any details on the experiment design it's hard for us to get anything out of it. What was the task, who were the participants, what was their familiarity with the software they were being tested on?

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.

Re: The Anti-Mac User Interface (1996)

#155

Post by hhas01 » Sun, Dec 13, 2020, 1:55 PM UTC

wool_gather wrote: post #146

hhas01 wrote: post #113

Earlier quoted context omitted.

Not good, just “good enough”. 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 stabi…

Apple's other attempt right now (on iOS) is Shortcuts, which is graphical-programming-y. But it's disadvantaged a bit because it started life (as a third-party app Workflow) outside the system, unlike Applescript.

I didn’t go into Shortcuts as it has its own set of flaws: poor granularity, poor composability, excessively complex and expensive to extend. And it’s still not quite clear how Apple mean to position it so that it connects to users’ aspirations and needs. Within Siri? within Apps? In between? All fixable, but ultimately depends on Apple’s priorities and investment, not to mention how good a handle they have on the problem themselves.

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 (Soghoian).

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.

Re: The Anti-Mac User Interface (1996)

#156

Post by dgb23 » Mon, Dec 14, 2020, 5:19 PM UTC

bawolff wrote: post #119

dgb23 wrote: post #35

Earlier quoted context omitted.

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.

Doesn't that just punt the question to, "what is a computational object"? 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…

A window is full of physical metaphors, like buttons, draggable handles/bars, tabs/paging.

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.