User Instrumented Api

One of the great new ideas of the 21st century. In a UserInstrumentedApi, users measure every widget with calipers, and email complaints about their sizes directly to developers' home email addresses. -- DougMerritt

A common AntiPattern one commonly finds in the "design" of user interfaces, and/or other interactive systems. The UserInstrumentedApi is a seductive technique, which programmers just love, because it's powerful, easy to do, and doesn't require much in the way of considering the user's needs, workflow, etc.

Simply take the programmer API (or WireProtocol?) to some subsystem, wrap a thin veneer of UI on top of it (so that users can drag and drop and click and point their favorite commands, rather than having to write code), maybe add a few keyboard shortcuts or other (ahem) SyntacticSugar (?!?), and call it good. No need to wrap all of the API calls, just ones which are obviously public.

Voila! The user now has the same power, theoretically, as the programmer. (Or as a CommandLineInterface - command shells already provide this sort of functionality).

Not.

It's a fun bit of ThreeStarProgramming, a particularly pleasurable form of MentalMasturbation, and looks great on the resume. Clever programmers will use MetaProgramming and/or introspection to do this for them automatically - change a class to add a method, and the UI widget for that class changes automatically, too! Of course, for those shops that prefer their apps programmers not dabble in such domain-independent diversions, many tool vendors will provide programs which do all the dirty work for you, and package it up in a nice box with a pretty bow on top. Some even will tell you that it's an honest-to-goodness programming paradigm.

But what results from this technique is a UserInterface which is invariably UserHostile, ugly, inefficient, and a royal pain in the ass to use.

Reasons why the UserInstrumentedApi is generally a baaaad idea.

It doesn't consider the user's workflow, or the importance of different functions. Some functionality is highly important to the user; other functionality is not. (And some functionality is dangerous if exposed directly to the user, like a bare electrical wire that's connected to the mains). Likewise, users frequently will do sequences of tasks, which should be optimized. (Of course, many sequences in user-land can be automated, a further improvement). UserInstrumentedApi makes all of these things equal (unless the programmer adds metadata to the system to identify the important things from the unimportant).
Programmatic interfaces are not good user interfaces. The programmer, when interacting with the API in whichever programming language, will have the full facilities of the language at his disposal in creating higher-level abstractions, algorithms, and such. The API is generally designed to be a low-level, mechanism-rich-and-policy-free interface to enable the programmer. API functions seldom represent complete units of user functionality. The entire point of an API is for its primitives to be composed in this manner. Users, on the other hand, do not have the tools to do such composition. Users cannot (in general) create loops (UI macro systems are a very poor substitute for this), hook the input of one primitive to the output of another, or do numerous other things that programmers take for granted.
Too many choices. Good user interfaces benefit from simplicity; not from universality.

Examples

Any number of database query widgets, which allow end-users to graphically create arbitrary SqlLanguage queries without actually having to type SQL. While the syntax of SQL may be a barrier, a far greater barrier to the user's effective use of such a tool is his knowledge of the database schemata (which may change from time to time at the DBA's whim), and the behavior of complex (from the user's POV) database operations such as joins and such. (Of course, it should be noted that SQL itself suffers from UserInstrumentedApi syndrome; initially it was thought that managers and customer service types would be able to write SQL themselves, enabling the sacking of legions of applications programmers).
SqueakSmalltalk. At least according to Richard (see HowToPervertDirectManipulation). Indeed (ducking the flames), many Smalltalk environments are the holy grail of UserInstrumentedApi design. As long as the users are progammers (and have the full power of SmalltalkLanguage at their disposal - including the skills to use it effectively), this is OK.... but contrary to the deepest wishes of AlanKay and company, Smalltalk - nor any general purpose programming language - is not a suitable end-user interface. Smalltalk, I'll concede, comes as close to being user-useful as any language out there, with the possible exception of LogoLanguage - at least in terms of accessibility. (Of course, the general purpose language which is most often used by end-users rather than programmers is crufty old VisualBasic; which is truly unfortunate). But see the comments below.
NakedObjects. Also see below.

And now, the disclaimer

And now, a bit on the difference (where it exists) between this and DirectManipulation. Many consider the latter (NakedObjects and such) to be a rather advanced UI paradigm - whereas this page is making the bold claim that the UserInstrumentedApi is an AntiPattern.

From outward appearances, it looks as though the two pages are describing the same thing.

They're not, at least not in the general sense.

DirectManipulation interfaces (where the user has a rather large bunch of objects, and can manipulate them in numerous ways - often selectable from a menu, palette, or other such mechanism) are useful when:

The tool or program is a creation tool; allowing the user to create a complex work product out of their own intellect and/or appropriate source material. Examples include word processors, IDEs, photo manipulation tools, such. Examples exclude things like data entry systems, crud screens, computer games, MP3 players, and Web browsers. This is why NakedObjects got included on the bad list - the purposes to which it is commonly put (generation of business transactions and queries) are not creationary in their nature. The set of users in this domain who would benefit from the power of NakedObjects, but who wouldn't benefit more from being provided direct access to programming functionality, is vanishingly small.
The objects being manipulated (the system nouns), and the mechanisms provided (the verbs) are strictly in the user's domain. It is very useful to the user to be able to crop the photo here, retouch it there, and increase the blue contrast by five percent.
- By this measure, the UserInstrumentedApi as a general technique becomes useful when the users are programmers - IDEs, debuggers, refactoring browsers, and other programming environments can make effective use of this technique.
- Indeed, it bears repeating that the fundamental sin of the UserInstrumentedApi is that it confuses the programmers' needs with those of the end user. Except in the case (as in SW development tools) where the end users are programmers, the two communities have very different needs.
DirectManipulation is used as a means to greater programming efficiency, rather than a UI paradigm which is foisted off on Grandma. In other words, DirectManipulation is used by developers rather than end users.

That seems to make sense. A few points though:

web browsers are lobotomized versions of ObjectBrowsers and OBs use DM. In fact, the most loathesome way in which web browsers are lobotomized is the way they don't have DM. Does this mean that creating taxonomies is creationary in nature? Probably.
- Of course, users don't create taxonomies with an ObjectBrowser - at least not in the way that they create memos (I'll avoid the heavily-overloaded term "document"), letters, photographs, computer programs, or other creative works. Users seldom use web/object/file browsers to create anything at all. And the various object browsers that I've had the bad experience to work with don't support "plugins" (a means for subtype polymorphism in the browser context) very well; such experiences were part of the inspiration for the above rant. Perhaps I should rephrase the above to make it abundantly clear that DirectManipulation per se is not the target of my broadside; it's DirectManipulation when it's done badly. As it frequently often is done. Good DirectManipulation requires careful consideration and selection of the nouns and verbs by the designer; rather than frobbing an API and providing every mechanism in the world that happens to exist at the bottom of the SoftwareStack?.
- If you have an intermittent internet connection for any reason, you tend to store what you want to read off of the net. It also helps searching immensely if you've got everything you've read archived. To that end, I've got >2000 files in >150 directories of just one genre of fiction. I followed a simple algorithm and I've got a simple taxonomy. And actually, everything I've done and a hell of a lot more would've been handled automatically by a UniversalCatalog. But if I had had only an OB, it would still have been a hell of a lot easier to download and save a 50 part story off of fanfiction.net than it was as is.
- Other things that users could create using OBs is lists of interests (eg, bookmarks) and tracks (histories). They don't do this using web browsers because they're all useless (browsers, not users :).
many games are DM, the good ones at any rate. Starcraft is DM. So is BlackAndWhite. So are Myth and Populous 3. Even role-playing games now tend to be DM. The only genres that have no DM whatsoever are first-person shooters, racing games and so on. I'll skip the disparaging comments on those. Obviously, we've got plenty of games whose natures are creationary. In the case of Myth, it's concerned with the creation of tactics.
- UI/interaction design for games is, of course, a completely different kettle of fish than other types of software.
- Because it's critical to success and so tends to be better. But I don't see any other differences.
A really, really good example of creation in videos is Videonat's remixing of scenes from TNA to the music of Call On Me. Of course, that wasn't done with a player. Note that I often find myself wanting a video editor, but that would require either videos to be formatted intelligently (with different files for each scene and each audio or caption channel) or a really good editor that can undo the craptastic video formats. Which of course would mean massively cumbersome software eating up lots of CPU >> $$$$$$.
- Most video formats that you'll find on your PC (MPEG, avi, Windows Media, Real Video), are designed for one purpose and only one purpose: Canned playback of video using as few bits as possible. Some have auxillary purposes built in - streaming applications, efficient access to clips, and - lest we forget - DRM. Editing in these format is a bad idea, mainly because they all have had the hell compressed out of them (all common video codecs are highly lossy; for the simple reason that uncompressed HD video requires 1.5 gigabits per second to store. Broadcast-quality SD television is better; only 270 megabits per second. At any rate, there are lots of file formats useful for video editing. Most of them are proprietary to companies like Apple and Avid (who make the leading commercial-quality video-editing suites), though SMPTE is standardizing on this thing called XMF (Extensible Media Format). You don't want to know about it. :)
- Oh, I know. But I don't see any technical reason why scenes can't be separated. After all, it's not like you can compress across scene boundaries.
The same goes for music which really should be distributed in chunks, with lyrics, and references to originals. Basically, the same as videos. It would make a big difference for megamixes. I'd LOVE to be able to cut out the half of the songs that suck from the half that doesn't suck from one of my favourite megamixes; especially since they're interleaved together.
- Of course, the artistes (and their labels, and the big media companies that own all the record labels) don't want you to do that. Which is one reason (not the only one, of course), that music isn't delivered to you in a separated format, to be mixed and combined by winamp or whatever. You're expected to consume what is produced.

maybe an AntiPattern

SeptemberZeroFive

CategoryUserInterface