Sadly, i'm rolling misses on my Google Fu this morning, but i believe that C.J. Cherryh wrote a short story about an elderly woman who wanted a new toaster. It being the future, the device delivered itself and promptly started doing the laundry, fixing the car, reprogramming the TV and all sorts of other wondrous tasks. The Matron, tutted, jabbed a fork deep into the machine. It sputtered, fell over, sparked and finally a warmed, lightly browned piece of toast popped out of a slot.
While the story is funny, it's also really useful to remember when building a tool.
Ultimately, you want your tool to be as simple as possible. This is the general theory of Unix. Little things that work well together. The problem is that building simple things tends to not be very popular.
As a software engineer, i am both subject to, and constant advocate of, feature creep. i want things that just do a bit more. i mean, sure i could have something that's just a front end to a database that allows me to enter a blob of text and then later display it,… but it could also have an inline editor, ooh, and a search function, and it'd be neat to have plugins… And, well, you wind up with WordPress.
Same with things like jquery, which started off as fairly simple and small, then became, well, jquery1. Even protocols go through that sort of progression (mind you, i already ranted a bit about "human vs. machine readable"). Darn near everything tends to start simple, but get increasingly more complicated.
As is usual, a number of things tweaked me about this point. One was an old rant about how even though people spend most of their lives in front of a computer now, most don't know how to use one. The other post talks about developer inequality and a longing for Hypercard. Both pretty much highlight the same thing, and i could argue against both equally.
For the first, i'll note that computers are media delivery devices and people tend to prefer to consume more than create, and that's ok. A fair number of people have no idea how to maintain their auto or understand the mechanics of municipal transit but use it to come and go. Granted, if they're taking an intro course on how to do car repair, probably a good idea to show them how to change the oil and rotate the tires, much like an intro class to computers ought to discuss programming.
Give 'em two weeks.
Likewise straight HTML is delightful because it's actually nearly readable. Pretty print it and it's pattern matching you can easily wrap your head around. Heck, explain to someone that The Web® really is basically a bunch of fancy telnet calls, and it's like watching a light bulb go off.
The final thing to note about all of this is that folks will surprise the hell out of you. They're not going to follow your arbitrary rules and will pretty much use whatever you hand them as a hammer. Done right, that's not a problem.
In fact, it could be a huge benefit.
Good Sir Tim Berners-Lee never expected people to use his protocol to do face to face video chats. Heck, he wasn't all that hot on documents having things other than links, but he was willing to let folks be creative with his toy. Heck, i've built stuff, given folks instructions on how to properly use it, and they've blissfully ignored me again and again.
This is typical (regardless of my continually trying to either ignore or change it), and should simply be part of any service you build. If anything, that sort of abuse should be lauded.
So, when you're building your next toaster (or library, app, interface, device, whatever), ask yourself:
- Is this doing the least it can to be useful?
- Can it talk to other things easily?
- Does this tool make zero presumptions about the user or the way it will be used?
Answering those questions will pretty much tell you how successful your thing will be.
Otherwise, you're just making a worse toaster.