3 ms·

The central thesis here is that APIs should be treated like GUIs. Make them as intuitive as possible to minimize brain space waste (ie. memorization of non-tra

The central thesis here is that APIs should be treated like GUIs. Make them as intuitive as possible to minimize brain space waste (ie. memorization of non-transferable, vendor-specific knowledge) Sadly, the post is too short to discuss what "intuitive" means for an API (which could probably fill several volumes).

astrobe_ 10y ago
Maybe the thesis is not totally right. A bad API can (sometimes? often?) be "fixed" by building a better layer on top of it. A bad UI can be "fixed" if its author allows it through configuration or plugins. Fixing the API is what you do, for instance, when you write language bindings for the horrible BSD sockets API. The fact that the user can fix it doesn't mean that API authors shouldn't care about simplicity, easy of use, consistency, etc., but it does mean that they shouldn't overdo it.
ArkyBeagle 10y ago
I've built GUIs that completely contravened every possible thing I've ever seen written about GUIs. For example, one ugly button. No "exit" button even - you can hit the X in the corner for that. Behind that button, there was no possible way to make a mistake. Now, to be fair when a constraint was violated ( which only happened when something physically broke or somebody didn't set a physical thing up right ) there was a comprehensive explanation of the failure - "The U42 wire for the Gerfish Space Defarbrulator is disconnected or broken. Please refer to section 1.145.2 of the service manual." That happened in a popup. To me, that's a good GUI - "just tell me when to go to it." But there is an ostensible public choice theory problem with this approach - who will be paid for training in it? Where will a support network for it exist? Nobody, and nowhere. Show this to people, and you can see it on their face - "there goes my job." They think this even after I show 'em the popup. It's asocial and that's more important that "it's correct." But it worked to sabotage any expectations people might have about me writing GUIs. Also, when people tell me that corporations are cost driven these days, I just laugh because of this.

astrobe_ 10y ago

Maybe the thesis is not totally right. A bad API can (sometimes? often?) be "fixed" by building a better layer on top of it. A bad UI can be "fixed" if its author allows it through configuration or plugins. Fixing the API is what you do, for instance, when you write language bindings for the horrible BSD sockets API. The fact that the user can fix it doesn't mean that API authors shouldn't care about simplicity, easy of use, consistency, etc., but it does mean that they shouldn't overdo it.

ArkyBeagle 10y ago

I've built GUIs that completely contravened every possible thing I've ever seen written about GUIs. For example, one ugly button. No "exit" button even - you can hit the X in the corner for that. Behind that button, there was no possible way to make a mistake. Now, to be fair when a constraint was violated ( which only happened when something physically broke or somebody didn't set a physical thing up right ) there was a comprehensive explanation of the failure - "The U42 wire for the Gerfish Space Defarbrulator is disconnected or broken. Please refer to section 1.145.2 of the service manual." That happened in a popup. To me, that's a good GUI - "just tell me when to go to it." But there is an ostensible public choice theory problem with this approach - who will be paid for training in it? Where will a support network for it exist? Nobody, and nowhere. Show this to people, and you can see it on their face - "there goes my job." They think this even after I show 'em the popup. It's asocial and that's more important that "it's correct." But it worked to sabotage any expectations people might have about me writing GUIs. Also, when people tell me that corporations are cost driven these days, I just laugh because of this.