InformationWeek
Defining The Business Value Of Technology
March 22, 1999
Developments:Principled Interfaces
User interfaces can learn to create themselves, but only if we reorganize the apps they depict
By John Tibbetts and Barbara Bernstein
ith visual layout tools and user-interface components proliferating, why are user interfaces
still such a mess? It seems the more gadgets that programmers have to play with as they
compose the screens users will see, the more dense and confusing these screens become.To be sure, style guides have emerged to impose some standardization, and even elegance, but this approach depends on programmers' understanding the rules and being willing to apply them. Stroll through a complex application with hundreds of screens that look and behave differently, and see how far counting on programmer cooperation gets you.
So here's a radical question: Why are programmers laying out user-interface screens, anyway? It's time-consuming and costly to have developers hand-placing every scroll bar, wiring up every check box, and inventing labels for every text field. The result, as we have seen, is haphazard at best, putting a heavy burden on users and the people who train them.
We're in the business of automating repetitive human activity. Can't we automate user-interface creation? There's actually an encouraging precedent involving the back ends of these same systems. In the old days, network or hierarchic databases were handcrafted, and they were as idiosyncratic as user interfaces are now-full of expedient shortcuts, ad hoc linkages, and personal quirks. When relational technology arrived, it brought formalism (what we call architecture) to this free-for-all, and took data-structuring decisions out of the hands of programmers.
What would it take to work a similar revolution at the user-interface end? One clue comes from those few interfaces that are already self-rendering. We find them in simple two-tier systems where the interface is close enough to the database to "see" the principles that structure the database tier. This metadata-information such as the size and shapes of fields, naming conventions, relationships between tables, etc.-is used to generate user interfaces automatically.
Unfortunately, this works only when the user interface is right up against the back end. As soon as any significant application intelligence is inserted between them, as happens in any real-world system, the interface loses touch with the metadata it needs to self-render. This is why we see "data-bound controls" so often in demos and so seldom in production apps.
Self-generating user interfaces work by piggybacking on the architecture of the layer they're representing. Databases are architected; applications seldom are. Thus, a user interface that fronts "unprincipled" application code has nothing to work with. Our ad hoc application logic forces us to build ad hoc user interfaces.
The user-interface problem, then, is symptomatic of a middle-tier problem. Solving it means restructuring the applications whose face the interface presents to the world. We must replace this maze of improvised, application-specific code with a series of generic objects-objects trained to know about their own structure and content. Such self-aware objects can
easily lend their metadata to a user-interface engine that will generate an accurate and internally consistent front end automatically.
The idea is to replace custom work with principle, expediency with architecture. Then we'll have user interfaces that can pick up metadata and create themselves on the fly.
Does this mean a world in which every application looks exactly the same? Not at all. Companies, departments, and even individual users can come up with templates reflecting their own preferences, and the application will pour itself into these templates automatically at run time.
Programmers, meanwhile, would be freed to work on the functionality of the system, rather than fussing with how this functionality gets expressed to the user.
John Tibbetts and Barbara Bernstein are partners in Kinexis, a San Francisco consulting firm. You
can visit them at their Web site at www.kinexis.com.
Back to Columnists
Send Us Your Feedback
Top of the Page
