Mark Baker has posted some further thoughts on the related issues of addressability and interface uniformity. He writes:
The moment your interface includes a method which is not uniform to all things, then you lose something because some aspect of identification is removed from the identifier, and moved to the method. [ Mark Baker]
Elsewhere Mark illustrates using this progression:
getSunwStockQuoteRealtime()
getIbmStockQuoteDelayed()An obvious next iteration would be;
getStockQuote( "SUNW", "realtime" );
getStockQuote( "IBM", "delayed" );However, generalization doesn't have to stop there. We could do this;
getQuote( "Stock", "SUNW", "realtime" );
Eventually however, generalization has to end. I suggest that this is as far as one can go with it;
get( http://nasdaq.org/quotes/stock/realtime/sunw )
otherwise known as;
GET http://nasdaq.org/quotes/stock/realtime/sunw
OK, now let's switch the focus slightly. In the realm of desktop productivity apps, we have a pretty well-known set of primitive and universal verbs: SELECT, CUT, PASTE. No matter what the object -- a paragraph, a range of cells, a region of a photograph, a segment of audio or video -- we understand how to use these primitives. So life is good, right? No, life sucks, according to Bill Gates. When interviewed on Charlie Rose last night, he said that interface complexity is the most critical problem that the next generation of Windows ("Longhorn") is tackling. There are too many things for users to learn, he admitted, and as a result they are able to use only a fraction of the capability presented to them. He explicitly cited interface uniformity as the strategic objective.
Since Windows arguably already has, in SELECT/CUT/PASTE, a uniformity equivalent to HTTP's GET/POST, what could this mean? Let's think in terms of user scenarios. Recently, for example, I have been exploring audio processing for the first time. Once I've captured a stream of audio, I find myself fiddling around trying to improve its quality. I make constant use of the SELECT/CUT/PASTE primitives, but they do not correspond to my notion of the task at hand. If there were verbs that did correspond more closely, they might be called ANALYZE and IMPROVE.
As I perform the analysis and improvement, I see analogies to other application realms. Filters that remove noise and hiss from a voice recording, for example, are clearly analogous to filters that sharpen or color-correct an image. Making those analogies more explicit could help users more quickly get up to speed. But the knowledge brought to bear in these scenarios, and the skills that embody that knowledge, differ in exactly the ways that make the audio domain different from the raster-graphics domain.
This is my beef with the argument for a small set of verbs that apply uniformly to everything. Sure, you can achieve that effect, for some definition of "everything" -- but that doesn't make scenario-specific complexity go away, it just pushes it somewhere else.
The XML support in the next version of Office raises this same issue. If I suck an XML file into Word 11, it's a document. The ANALYZE and IMPROVE scenarios might include formatting, or table-of-contents generation. If I suck that same XML into Excel 11, it's data. Here the ANALYZE and IMPROVE scenarios could include sorting or the construction of pivot tables.
It's a great idea to push the abstraction of the core primitives above the level of SELECT/CUT/PASTE. But there's little to be gained by pretending that a table of contents is a pivot table.
Walking the line between the specific and the general always was, and always will be, a science and an art.
Former URL: http://weblog.infoworld.com/udell/2002/11/08.html#a504