The point is: the best interface is NO interface. Go to car. Open door. Sit. Not: Go to car. Find keys. Unlock. Open Door. Sit.
Ordering your food is less simple than ordering your food and handle money? But you do loose a lot of anonymity, which offsets the ease of use.
- owner puts hand in pocket
- owner grabs keys
- owner removes keys from pocket
- owner finds car key
- owner inserts key into lock
- key engages pins in lock
- owner applies torque and turns the key
- pins allow tumbler to turn
- electronics detect turned lock
- lock disengages
- owner turns key back
- owner removes key
- owner puts key in pocket
- owner opens door
- owner enters vehicle
Why do I care about the pins? I don't. They do their job without me telling them what to do. With menus it's not that simple - I have to engage them; I have to obey them.
If your car door has menus, then yes, that's a huge usability problem, but no one's arguing in favor of that.
My point is that any interface has some abstractions beyond which you get only hacker delight in knowhing their inner workings.
For usability purpose you don't need to know there are pins or bits - just that they work. When on the other hand, you artificially expose inner workings (menus) and _force_ the user to make note of them - you should not be allowed anywhere near a design table.
Designer's job is to make users life easier not to shout at them "you stupid you who don't know how to exit my maze"
owner unlocks door with key
That statement hides a lot of mechanical complexity (especially when you consider central locking, alarm and immobiliser). you should break it down into what happens when you turn the key, like you have with the remote key example. you can have just as many steps.If the technology does 1 Billion operations on your behalf when you could do it in 10, but now you have to only take one action, then it is simpler to you.
- owner's keyfob transmits signal to car
- owner's car polls for incoming signal
- owner's car decrypts keyfob signal
- owner's car verifies that the keyfob has a legitimate encrypted key for that vehicle
- owner's vehicle signals the locking routine in the ECU
- owner's ecu flips solenoid for only the drivers side door
- door unlocks
All the above steps are done without the owner having to know about it.
I'm quite sure he is talking human->computer interfaces not computer->computer interfaces.
By your logic, it's simpler to buy something from someone in another country with cash than it is to use PayPal.
Awesome, I agree, except that all of those examples are shit.
It's not "more simple" to just walk up to your car and have it magically unlock based on proximity. Simple is using your damn key to unlock the car, not layering stacks of abstractions in order to compute ones location juxtaposed to a vehicle. In fact, that order of events should have gone something like this (as a generic, modern day implementation of this functionality):
- owner approaches car
- owner's keyfob transmits signal to car
- owner's car polls for incoming signal
- owner's car decrypts keyfob signal
- owner's car verifies that the keyfob has a legitimate encrypted key for that vehicle
- owner's vehicle signals the locking routine in the ECU
- owner's ecu flips solenoid for only the drivers side door
- door unlocks
- owner enters vehicle
How the hell is this more simple than:
- owner approaches car
- owner unlocks door with key
- owner enters vehicle.
Likewise, having your payments automagically charged based on location is NOT more simple. Simple is ordering your food and handing over money at the register.
The best interface is a simple interface, not a whole bunch of programming voodoo to achieve a simple task.