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

The Anti-Mac Interface (1996)

nngroup.com

Post reply on HN
Print view View original

41–50 of 138 posts

Re: The Anti-Mac Interface (1996)

#41

Post by pqdbr »

m_mueller wrote: post #35

One thing that almost always gets overlooked when critizing / trying to innovate on Xerox Parc-like interfaces, is discoverability. Look at departures from this interface (or predecessors of it) and you'll almost always find a system where it's hard for users to discover what they can do and how their actions will affect the state. Most prominently: * iOS style gestures * Office Ribbons (where has my feature XY been…

Since you touched discoverability I feel the need to point out how bad a design choice I think "Force Touch" really is.

I've had the Apple Watch for a month now and I don't really see the point of it. The argument for little screen real estate simply doesn't cut it.

Take the notifications pull down for instance. (BTW, you have an already hidden UI gesture to open it - swipe from top to bottom). Then you see a list of all your notifications in a column of little cards one after the other. There's no reason there shouldn't be a button in the end of this list labeled "Dismiss all". Force touch is simply too hidden from the average non-tech-savy user.

Apple even has this "dismiss button" when the Apple Watch brings you individual notifications as they happen. They should have just put a button there instead of hiding the option in Force Touch just to demonstrate the new technology.

Not to mention that it's slower then tapping a button and there are misses (10% of my force touches are not recognized; it's not a lot, I'll give you that, but it's annoying as hell when it happens and the slowness bothers me every time).

Lastly, I read an article in AppleInsider 5 days ago [1] stating that Force Touch will be a revolutionary addition to the next iPhone.

Needless to say, if Force Touch had anything going for it on a really small screen as the Apple Watch, I dont know who could benefit from using it on a huge screen like the iPhone. Silly UI choice in my opinion.

[1] http://appleinsider.com/articles/15/06/29/as-apples-iphone-t...

Re: The Anti-Mac Interface (1996)

#42

Post by sanoli »

jimmaswell wrote: post #27
vbezhenar wrote: post #5

> We seem to have settled on the WIMP (windows, icons, menus, pointer) model, and there is very little real innovation in interface design anymore. It's an interesting exercise to compare this to the mobile platforms, e.g. iOS. Windows are gone. Icons are here. Menus are changed. Pointer is changed too (your finger is pointer, not an abstract arrow). Though on OS X desktop I don't see any innovations at all! May be I…

It's not "stagnating", there's simply not much need to "innovate" it anymore. It works well for both new and advanced users. Changing the standard UI would just be a pointless frustration - see Windows 8.

I always laugh when I hear someone complaining about the WIMP model where their main argument is "it's been the same way for xx years, with no real innovation since its beginning". Right, and the steering wheel sucks so bad as a driving interface because it's so old and hasn't changed any.

A couple of years ago there were these 3D interfaces being designed, with the intention of replacing the WIMP dsktop 2D space, and I remember one guy saying how the biggest mistake in computer interfaces was done because somebody decided to attach a typewriter to a TV, meaning we only took what we had and used them as models for what to do (typewriter->keyboard; TV->monitor). Sorry, but no, the stuff worked, and it worked pretty well. It's like this not because it sucks, but because it's actually quite good.

I also always think about the simple light switch on every wall. Not to be replaced with sensors so soon, even though it always seems like it's close to being so.

Re: The Anti-Mac Interface (1996)

#43

Post by m_mueller »

pqdbr wrote: post #41
m_mueller wrote: post #35

One thing that almost always gets overlooked when critizing / trying to innovate on Xerox Parc-like interfaces, is discoverability. Look at departures from this interface (or predecessors of it) and you'll almost always find a system where it's hard for users to discover what they can do and how their actions will affect the state. Most prominently: * iOS style gestures * Office Ribbons (where has my feature XY been…

Since you touched discoverability I feel the need to point out how bad a design choice I think "Force Touch" really is. I've had the Apple Watch for a month now and I don't really see the point of it. The argument for little screen real estate simply doesn't cut it. Take the notifications pull down for instance. (BTW, you have an already hidden UI gesture to open it - swipe from top to bottom). Then you see a list of…

I think stuff like that is ok iff it works consistently (>99%) and if it does something consistant as well. For example, on Windows I do like how I can usually predict what a right-click does. If Force Touch is used consistantly for context based interactions, then I think there would be some advantage on larger touch screens, since it could be executed wherever your fingers are, instead of scrolling back to the top / doing the akward double-home-button-tap-dance. Basically, I'd like it to do exactly what a right click does in Windows or CMD-I did on OSX when it was still geared towards power users, which is basically also a way to reduce mouse movement.

Re: The Anti-Mac Interface (1996)

#44

Post by jacobolus »

m_mueller wrote: post #35

One thing that almost always gets overlooked when critizing / trying to innovate on Xerox Parc-like interfaces, is discoverability. Look at departures from this interface (or predecessors of it) and you'll almost always find a system where it's hard for users to discover what they can do and how their actions will affect the state. Most prominently: * iOS style gestures * Office Ribbons (where has my feature XY been…

I’d love to have a shell-like environment where every command’s output was a stream of structured records with support for rich data types (ideally including stuff like images), not just lines of plain text.

The hard part here is not just figuring out all the core UI and protocols (though that would also take some work), but actually implementing all the hundreds or thousands of essential basic programs. Unfortunately existing technologies are so entrenched that this kind of thing isn’t going to happen without someone with very deep pockets funding it.

One neat thing is that a rich enough structured metaformat could be used directly for storing things like config files, logs, many types of structured documents, etc. directly to disk, and wrappers could be added to transcode existing legacy formats to/from the standard metaformat.

The difference could then be minimized between reading a typical file vs. reading the output of some tool, and likewise the difference could be minimized between reading config options from a file vs. passing in config options in the shell directly, etc. etc.

[Aside: also unfortunate is that there aren’t any solid document/protocol metaformats which would serve this purpose, as far as I can tell. The Clojure guys have generally the right idea with edn/fressian/transit, but the datatypes they’ve implemented are a bit too closely mapped directly to Clojure types (including types irrelevant in other contexts and missing meaningful distinctions from other contexts); in particular they haven’t really considered binary data types like images or big tables of numerical data. By contrast, data metaformats used in the scientific computing world like e.g. HDF don’t pay enough attention to standardizing complicated structures of non-numeric data. JSON and similar formats, even e.g. Apple plists, aren’t rich enough and so end up causing fragmented ad-hoc solutions to common problems. XML is terrible in almost every possible way. Etc.]

Re: The Anti-Mac Interface (1996)

#45

Post by pqdbr »

m_mueller wrote: post #43
pqdbr wrote: post #41

Earlier quoted context omitted.

Since you touched discoverability I feel the need to point out how bad a design choice I think "Force Touch" really is. I've had the Apple Watch for a month now and I don't really see the point of it. The argument for little screen real estate simply doesn't cut it. Take the notifications pull down for instance. (BTW, you have an already hidden UI gesture to open it - swipe from top to bottom). Then you see a list of…

I think stuff like that is ok iff it works consistently (>99%) and if it does something consistant as well. For example, on Windows I do like how I can usually predict what a right-click does. If Force Touch is used consistantly for context based interactions, then I think there would be some advantage on larger touch screens, since it could be executed wherever your fingers are, instead of scrolling back to the top…

You touched another interesting point. I remember reading somewhere that Steve insisted the mac shouldn't have a 2 button mouse for such a long time just because it would force developers make a simpler UI, where no 'hidden menus' could be created. The lazy option of just throwing everything under a 'right click' simply couldn't exist.

If you think about it, Force Touch could create that 'right click' in iOS, which I think is a bad idea for starters. We already have hidden gestures and tap & hold, so there's already enough stuff hidden from plain sight in the User Interface.

Let's face it: the popularity of these devices came from the fact that they are really easy to use to the average user (think your mom for example). Will she know about Force Touch and incorporate that in her interface discovery process ?

Re: The Anti-Mac Interface (1996)

#46

Post by SomeCallMeTim »

jimmaswell wrote: post #27
vbezhenar wrote: post #5

> We seem to have settled on the WIMP (windows, icons, menus, pointer) model, and there is very little real innovation in interface design anymore. It's an interesting exercise to compare this to the mobile platforms, e.g. iOS. Windows are gone. Icons are here. Menus are changed. Pointer is changed too (your finger is pointer, not an abstract arrow). Though on OS X desktop I don't see any innovations at all! May be I…

It's not "stagnating", there's simply not much need to "innovate" it anymore. It works well for both new and advanced users. Changing the standard UI would just be a pointless frustration - see Windows 8.

OSX has never gotten the basic keyboard interactions right that Windows has had from the beginning: The ability to trivially navigate menus from the keyboard.

I want Alt-F to open the file menu, and then "S" to save a file. Yes, I know that the Mac has Cmd-S to save, but there can be 50+ menu options spread across various menus, and the 10-15 that I use the most are far easier to remember (for me) as Alt-[menu letter], [hot letter of menu entry].

When you know what the underlined letters mean, it makes every new app have a completely discoverable keyboard interface that is easy to memorize, and it's one of the key advantages of Windows of OSX. That feature alone is why I only use Windows and Linux (except when I am forced to use OSX to do iOS builds) for development.

Re: The Anti-Mac Interface (1996)

#47

Post by metasean »

sanoli wrote: post #42
jimmaswell wrote: post #27

Earlier quoted context omitted.

It's not "stagnating", there's simply not much need to "innovate" it anymore. It works well for both new and advanced users. Changing the standard UI would just be a pointless frustration - see Windows 8.

I always laugh when I hear someone complaining about the WIMP model where their main argument is "it's been the same way for xx years, with no real innovation since its beginning". Right, and the steering wheel sucks so bad as a driving interface because it's so old and hasn't changed any. A couple of years ago there were these 3D interfaces being designed, with the intention of replacing the WIMP dsktop 2D space, an…

Changing for change sake is bad, but questioning long-held assumptions can lead to highly desirable changes. I largely agree that what we have works, but I also like to see how it may change.

One example that's been big in my life is the transition from a mouse to a trackpad. The mouse worked in many cases, but it was a nuisance for laptops. In my case, they also caused excruciating repetitive stress related-tendinitis which, thankfully, a laptop trackpad doesn't.

Funny you mention simple light switches not being "replaced with sensors so soon". Years ago, the very first modification I made when I moved into my house was to replace many of the simple light switches with motion, light, and time-based sensors, and a few with dimmer switches.

Re: The Anti-Mac Interface (1996)

#48

Post by jimmaswell »

metasean wrote: post #47
sanoli wrote: post #42

Earlier quoted context omitted.

I always laugh when I hear someone complaining about the WIMP model where their main argument is "it's been the same way for xx years, with no real innovation since its beginning". Right, and the steering wheel sucks so bad as a driving interface because it's so old and hasn't changed any. A couple of years ago there were these 3D interfaces being designed, with the intention of replacing the WIMP dsktop 2D space, an…

Changing for change sake is bad, but questioning long-held assumptions can lead to highly desirable changes. I largely agree that what we have works, but I also like to see how it may change. One example that's been big in my life is the transition from a mouse to a trackpad. The mouse worked in many cases, but it was a nuisance for laptops. In my case, they also caused excruciating repetitive stress related-tendinit…

I always found trackpads to hurt my hand somewhat after a while in contrast with mice. Maybe you just had bad mice?

Re: The Anti-Mac Interface (1996)

#49

Post by metasean »

jacobolus wrote: post #44
m_mueller wrote: post #35

One thing that almost always gets overlooked when critizing / trying to innovate on Xerox Parc-like interfaces, is discoverability. Look at departures from this interface (or predecessors of it) and you'll almost always find a system where it's hard for users to discover what they can do and how their actions will affect the state. Most prominently: * iOS style gestures * Office Ribbons (where has my feature XY been…

I’d love to have a shell-like environment where every command’s output was a stream of structured records with support for rich data types (ideally including stuff like images), not just lines of plain text. The hard part here is not just figuring out all the core UI and protocols (though that would also take some work), but actually implementing all the hundreds or thousands of essential basic programs. Unfortunatel…

By chance, have you ever had a chance to use Quicksilver? If so, what are your thoughts on it? http://qsapp.com/about.php

Re: The Anti-Mac Interface (1996)

#50

Post by m_mueller »

pqdbr wrote: post #45
m_mueller wrote: post #43

Earlier quoted context omitted.

I think stuff like that is ok iff it works consistently (>99%) and if it does something consistant as well. For example, on Windows I do like how I can usually predict what a right-click does. If Force Touch is used consistantly for context based interactions, then I think there would be some advantage on larger touch screens, since it could be executed wherever your fingers are, instead of scrolling back to the top…

You touched another interesting point. I remember reading somewhere that Steve insisted the mac shouldn't have a 2 button mouse for such a long time just because it would force developers make a simpler UI, where no 'hidden menus' could be created. The lazy option of just throwing everything under a 'right click' simply couldn't exist. If you think about it, Force Touch could create that 'right click' in iOS, which I…

I think there is a gradient when it comes to imterqctions and discoverability:

Text Buttons > Icon Buttons with hover text = menu entries with hotkey explained > menu entries with hidden hotkeys = ribbons > context actions with visible button > grouped context actions without visible button (right click / force touch) >> context actions with one hidden interaction per function (gestures)

The more complex your app, the deeper you need to reach down in this bag. What I want to say is, I'd still prefer a force touch menu over hidden gestures - what's idiotic is if you have enough space for something more discoverable, yet you opt for force touch or a gesture like in your watch example. But imagine MS Word on iPad with full desktop featureset - I'd be just fine with a force touch context menu there.

Post reply on HN