M. C. Morgan (my first friend met through federated wiki) pointed me to this series on NeoVictorian Computing by the guy who wrote Tinderbox, a Mac-only hypertext computing tool. The primary point he makes throughout the series is how our fetish for “transparent computing” is making both users and programmers miserable.
What do I mean “our fetish for transparent computing”? You see it everywhere — that every program should look the same, that every bug must be eliminated, no matter how small, that a user interface must be immediately understandable to the novice.
This results in a sort of fast food computing that pleases the senses but ultimately leaves us unsatisfied, unhealthy, and unproductive. We expect our software to demand about as much out of us as watching YouTube #FAIL videos, and we end up getting about as much out of it as we should expect in such circumstances. Problems that software could solve (and could have solved ages ago) remain unsolved because if it doesn’t fit in a bugless File > Edit > Tools menuing system, or worse, the intuitive touchiness of Tablet Computing, then no one is going to use it.
Our response to this trend is interesting. How many times have we heard the story about the toddler who “just starts working the iPad naturally?” And what amazing progress this is!
Step back from that and analyze that statement. The device we are using for our jobs can be used by a toddler. And we’re proud of that!
Would you feel the same way about books? “This book on utility computing is so simple that my third-grader gets it. You have to buy it!”
The problem is that the whole point of your computer is it is NOT an intuitive physical object, but rather an instrument relatively unconstrained by the physical world, and unconstrained by the program author’s intention. It’s supposed to push the boundaries of what’s possible.
A car simple enough for a third-grader to drive is an accomplishment, because we are not counting on the car to do anything radically new.
On the other hand, an interface a four-year-old can use on top of an information technology product is probably a failure, because it means your product encourages a four-year-old’s vision of the world.
I’m not saying you should keep all things hard forever hard. I’m not saying it’s a virtue to force your user to compile their own code and run it on Node.js on an S3 instance (after installing pm2, of course, because we all know screen crashes!). Eventually, such things need to be made easier. (Though obvioulsy, in beta states this is how things may have to be).
No one is asking for installation and setup to become less transparent. That’s just making your user do work you couldn’t automate.
But interface elements that are essential to advancing the way we do things? New gestures that pay off after a week of use? New models of thinking about media elements? We under-use these. And we give ourselves too many excuses for not engaging with them. Sure, Google Wave was corporate Google-ware, but the tech press gave it, what, a week?
And that tablet computing is making our applications even simpler is not an achievement, but rather a threat to our ability to solve new and complex problems.
What’s the alternative? More software. More specialized software. Small pieces loosely joined. Long term relationships with software instead of acquaintances. NeoVictorian Computing. Read it.
UPDATE: In response to Scott’s comment, I wanted to clarify things. This is not a defense of lazy, crappy software, or software that forces you to understand your system’s file-structure to make it work. I don’t buy into the whole “editing your config file will set you free” line of thought any more than I bought the “to truly drive a car you have to rebuild an engine” line of thought. That’s laziness posing as edification.
The claim is actually meant to be the opposite. Think of Google Wave, which was actually a pretty slick piece of software that was far more refined and far less machine-like than email. I don’t know if Wave should have succeeded or failed. But the critique of Wave was not that it was hard to get running, or difficult to use, or forced you to know the internals of it to really use it right. The critique of it was it forced people to reconceptualize their mail, and they couldn’t do that after ten minutes of playing with it, and therefore it was doomed.
I understand why the general public felt that way. But why do we support that? Nelson’s OpenXanadu is yet another example — “It requires to much reformulation to make XanaDocs” is probably an OK response, but the response that will kill it is that it is “too confusing”. Never mind that he is trying to create a whole new paradigm.
So yes, any system that makes me generate reports by saving a csv somewhere and uploading to another place that produces a PDF to download from a third location — please stop making crap-ware like this. It wastes my time in exchange for yours.
But we also have to be careful we don’t fall down this rabbit hole of making only software that does not take any time to master, or software that is only general in nature. What I want from a developer is some very careful thought about what the experience of using this system will be like 30 hours into it, not a relentless focus on my first 30 seconds.
Leave a comment