6 ms·
The best interface is indeed no interface and it's the end goal of a long design and product process. There's probably some Maslow's hierarchy for design that
by liyanchang 12y ago
The best interface is indeed no interface and it's the end goal of a long design and product process.
There's probably some Maslow's hierarchy for design that looks like (designer friends - please let me what wheel I'm reinventing please):
1. The system has to be told exactly how to perform a task.
2. The system has reasonable defaults on how to do it. You push execute.
3. The system knows what you want and just does it.
The car key app requiring 13 steps means we're still in phase 1. The fact that it works at all is forward progress because before you couldn't do it at all! (One might argue that it's right now not useful and I would probably agree with that.[0][1])
The next step forward is probably to geofence your car and when you're near, a push notification asks you if you'd like to open your car door.
Finally, we get to the two step walk to door, open door.
We've got a long way to go and I applaud Mr. Krishna for pushing us further along. It does seem therefore that we should encourage app designers to continue to make apps with clunky interfaces so that we can begin the journey towards the goal - no interface at all.
I'd actually love to hear examples of systems that leapfrog from nonexistence to it's final evolution without intermediate steps. That would be really fascinating.
[0] Unrelated - rented a car once with remote keyless entry and keyless start - it is indeed a magical experience when the key never has to leave your pocket.
[1] Having gone through winter on the East Coast recently, I do think phone remote start might singlehandedly make the app worth it.
- TeMPOraL 12y ago> 1. The system has to be told exactly how to perform a task. 2. The system has reasonable defaults on how to do it. You push execute. 3. The system knows what you want and just does it. This. Interface is by the very definition a barrier between your brain and the system you want to change (by "system" I mean a system in general sense, a hammer, nail and a piece of wood also form a system). What matters is your goal and the change of system's state - everything else is cruft and we should aim to remove it. Your brain actually tries to do that by its own. You can see it when e.g. driving a car. At first you're aware of everything - the steering wheel, the pedals, the gear shift knob, etc. You consciously manipulate them to move the car around. But at some point, with enough accumulated experience, you don't really think about the interface anymore. You just think "I want to be there" and do all the required movements to steer the car to the right place. What is important for your brain to learn to ignore the interface is the interface being predictable and consistent. This is where, I think, smartphones are a step backwards compared to old featured phones. As we moved from firmware to full OSes, you can't rely anymore on timing. For example, on my old SE K800i I could do most frequent actions without even taking my phone from my pocket, because my brain learned the position and timing of various options. "Press Right Function, move down twice, press Right Function, wait 0.7 seconds, press Right Function...", etc. It's something that you can't do on a smartphone, because the new tech is laggy and full of unpredictable interface delays. > The next step forward is probably to geofence your car and when you're near, a push notification asks you if you'd like to open your car door. Or we could, you know, use NFC for opening and/or BLE for determining if the phone is near/inside the car. Geofencing is totally a wrong tool for the job (and so far every time I heard it being suggested for something, ot was wrong for that as well). > Finally, we get to the two step walk to door, open door. We could do that decades ago. The way smartphones are getting introduced into the equation seems to be a huge leap backwards.
- to3m 12y agoI used to text while driving when I was a young man. My Nokia 2110 had no T9 and nice big buttons, so I could do this without the phone ever having to leave my coat pocket. I would even properly punctuate, too!
- digi_owl 12y agoI would not trust 3 even if we reach the point where we are making Jeeves level AI assistants. And 2 better damn well have a easy way to get to 1, just in case those defaults don't fit the situation (and by Murphy you can be sure they will not).
- yellowapple 12y agoI actually wouldn't be so sure. 1 and 2 remind me of imperative and declarative programming languages (respectively) - telling your program how to do something versus merely telling it what to do. It's the difference between saying "x = 1" and telling your computer how to allocate sufficient memory for an integer, store that integer in said chunk of memory, and access it later.
- digi_owl 12y agoAnd the first thing that comes to mind is that "you" can do declarative programming now, because someone in the past did all the imperative programming to enable it. Question is, what happens if the declarative fails? How easy is it to get at the imperative guts?
- slavik81 12y agoConsider a door with a handicap button. The interface is: press button, door opens. Now consider a door with a motion sensor, the new interface is: walk towards door, door opens. This is basically an example of eliminating an interface. You rarely think about these interfaces because they just do the right thing. Many very simple operations have interfaces, and you can sometimes streamline or remove those interfaces using simple mechanisms.
- digi_owl 12y agoAdn then the sensor fails or similar, and we need some other way to open and close. Never mind some way to prop it open in case something larger needs to go through.
- robewald 12y agoIt is not Maslov, but Parasuraman[0] for automation and decision selection: 1. The computer offers no assistance. 2. ... offers a complete set of actions. 3. ... narrows the selection down to a few. 4. ... suggests one alternative. 5. ... executes the suggestion if the human approves. 6. ... allows the human a restricted time to veto the execution. 7. ... executes, then informs the human. 8. ... executes, informs the human when asked. 9. ... executes, informs the human when the computer decides to. 10. ... acts automatically. This is a framework for more than user interfaces, but it comes close. Look at Fig. 1 in the paper. [0] https://hci.cs.uwaterloo.ca/faculty/elaw/cs889/reading/automation/sheridan.pdf https://hci.cs.uwaterloo.ca/faculty/elaw/cs889/reading/autom...