How a Customer's Question Frames the Definition of 'What Does a User Interface Architect Do?'

My title is Chief Architect, and the short description of what I do is that I designed the mCUE user interface and telephony middleware systems.

That's not a very satisfactory description for several reasons:

1. The product named mCUE is difficult to pin down: “Unified communications” and “middleware” are industry terms calculated to form meaning in the eye of the beholder.

2. When people hear “user interface” they think “draws pretty pictures”

3. The term “architect” is also nebulous – what is there to architect in a user interface? It's just presentation.

So, when asked, what can I say about the job I do? Recently, a customer's question brought the description of what I do in focus, and also helped clarify the nature of the product I designed. The question was:

How do you ensure consistency of customer experience from platform to platform?

The question was asked because we showed the customer our product in a very portable implementation that depends only on a reasonable Java VM and a small subset of the Java AWT classes, but they needed our product in an environment that requires use of that platform's UI classes and application framework. Why, in this new implementation, should they expect it to work like what they evaluated and liked?

That question gets right to the heart of what it means to design a mobile user experience, and, indeed, right to the heart of the whole project that I have been working on.

My work here started with discussions I had with D2 Technologies' founder David Wong, who is a pioneer in voice over IP technologies (VoIP) and DSP software, on the proposition that VoIP user interfaces were low-quality compared to mobile user interfaces, and that nobody had really thought about VoIP user interfaces the same way as mobile user interfaces.

That is, nobody had thought of VoIP user interfaces as a really important part of the product. VoIP users were fewer, and had fewer options than mobile users. VoIP users were generally enterprise users, accustomed to ill treatment by user-hostile software. VoIP user interface was immature because the resources applied to it were small, and the stakes in the market were correspondingly small. What if we took it seriously and put more mind-share and resources into it than our competitors? Could we make a breakthrough in VoIP user interface and, perhaps, ride that up the value hierarchy to a place among mobile handset technology providers, especially as they found they needed IMS endpoint technologies?

That is how the project that became the mCUE product started at D2 Technologies. It was about VoIP, but, specifically, about what we hoped would be the logical next step for VoIP endpoints: Instead of desk sets that tried to look like PBX phones, VoIP would logically be moving to mobile handset form factors and use WiFi to connect to VoIP systems.

That VoIP user interface market, however, proved to be too small even for a specialist company like D2: WiFi handsets are, still, a tiny fraction of VoIP endpoint market share, and desk sets are still saddled with crude user interfaces. Nor could we make an immediate jump to providing IMS endpoint technology. Only tier-1 OEMs were active in defining their IMS endpoint architectures, and these were mostly prototype efforts.

Nevertheless, we changed our design goals to aim at the intentions of IMS: To make every mode of communication a first-class citizen in the mobile endpoint. And, beyond that, we realized that IMS is not the be-all/end-all of mobile communication. We also made every service a user might want to use a first-class citizen alongside the mobile network. That is, we made IP communication in all modes and media able to either replace, as in a purely VoIP system, or stand alongside mobile service, without relying on an IMS network implementation to aggregate every conceivable IP communication service.

And that gets to the answer to our customer's question: How do we ensure consistency of customer experience from platform to platform? The answer is: we have to, otherwise we could not implement our goals. We must make a new “world” of communications objects that replaces the call-state management in a conventional mobile handset with a model of communication that encompasses all modes, all services, and all networks. And, if user interaction with this much-expanded communications model is consistent in all implementations, the user experience is consistent, no matter the UI toolkit we use to implement the presentation of the user experience.

So, what does an architect of mobile user interfaces do? He makes a model the user is comfortable manipulating, and presents that model in a consistent way across multiple platforms. This sounds a bit general, but aspects of this task are especially critical in mobile user interfaces: The mobile user interface is inherently a multimedia user interface – it used to be almost entirely presented as audible call progress tones and the billions of users of telephone systems worldwide have a strong expectation that the conventions of a telephony user interface and a mobile user interface will be preserved in an interface that brings in other modes of communication.

The mobile interface itself cannot be pulled in new directions very easily, yet assumptions have to be questioned: What, for example, can be done to enhance the task of starting a conversation? On-hook dialing was invented to keep the user off the precious resources of the mobile network until the last possible moment. Now that always-on data connectivity is inherent in VoIP networks and widely available in mobile networks, the “don't touch resources until you absolutely need to start signaling the network to connect a call” assumption is obsolete.

A mobile user interface designer not only makes the presentation of the user experience, he has to be able to design the model manipulated by the interface, and he has to know about the network, and even the business of operating the network, to make a presentation, a model, and a consistent set of functions that work together. And he has to know it all well enough to know the difference between a rule you have to observe and a rule you have to break in order to innovate.

This seems daunting. It is, at least one of the most interdisciplinary pursuits in software design. It is full of both constraints and opportunities. If you are unaware of the constraints you will make mistakes that make you look amateur. If you are unaware of the opportunities and what it takes to exploit them, you only advance by luck. The reward is that good work in mobile user interface design expands your mind the way few tasks can in the increasingly specialized world of software design.

Organizing the Pantheon of Multimedia Communication

Recently I heard Garrison Keillor quote Joseph Campbell, in one of his essays on writing: “A computer is like an Old Testament god, with a lot of rules and no mercy.”

It doesn't help that the rules are rational and sanitary. No stoning. No beheading. Bacon is not a problem. Just cold opprobrium that is made even colder by the certainty that You Did Something Wrong.

Fixing this is the central task of user interface designers.

Clearly, then, it isn't good enough to enshrine the olde thunderbolt-slinger in a fancy temple < cough >smartphone< /cough >. That won't make him any easier to deal with. We have to reform the rules. More, we have to reform the language the rules are written in and the definitions of the nouns.

That is what initiatives like MMTel and RCS require, but, so far, are not getting from user interface designers. Your 2.5G phone is a simple minor deity with simple rules. Everyone understands the propitiations and few are therefore intimidated. But the pantheon is getting crowded with both the bureaucratic jinns of IMS, and the anarchic dryads of the Internet.

Messaging is now multimedia messaging. Email and IM bring two other rites of messaging. IM presence and social network updates make it a group event, along with your push-to-talk circle of initiates. And plain old voice conversations can travel over the righteous roads of the synchronous digital hierarchy or the twisted but beguiling paths of the Internet.

Putting all this in separate little shrines, with separate sets of rules and liturgies is bound to put us at risk of hellfire and damnation, and the use of Strong Language. Consequently, the people are divided into the zealous, who are undeterred by complexity and proudly wear their scourges in a belt pouch, and the agnostic, who are driven to indifference.

The successful interface to IMS-based capabilities will solve this problem. It will put all the media for communication under a single set of simple rules and inside of one interface – not a set of applications, but one unified application for communication, just as using the 2.5G voice network requires just one user interface.

The problem is one of levels of abstraction. How can you take protocols as divergent as SIP, XMPP, a few dozen proprietary IM systems, some with VoIP and/or voice chat, push-to-talk, video calls, email, social network update feeds, and circuit switched telephony and give the user one set of tools, one set of contact information, one history, one set of shortcuts, and one consistent set of verbs and nouns for manipulating these capabilities?

The radio interface layer, and user interface on top of it, that turns your key presses into phone calls in one direction, and state-changes reported from the radio baseband into indications of call progress in the other direction is not enough. But how do you keep it just as simple for the user?

The notion of a conversation has to evolve to encompass the new media of communication. Key objects: people, conversations, connections, addresses, services, identities, status, and presence have to be made simple enough for humans to manipulate through the same 12 keys and handful of other buttons, and their visual manifestations have to fit on screens small enough to keep discreetly in one's pocket.

And this is the hard part: We have to create a new world of communications objects that spans media, networks, and protocols, and we have to make the human customer instantly fluent in the language of these objects. This layer, consisting of many new protocols, access to many new services, and quite a few fundamentally new capabilities has to be inserted between the keypad and the radio without the user noticing that the amount of software in the system has gone from bottle-rocket to space shuttle in one step.

The zealous don't care: They are happy to stuff a computer into a belt-pouch. Multimedia communication is easy if the user is comfortable with multiple applications. But, to give multimedia communication mass appeal, the masses must be appealed to: The result, for them, must be that their phones do more, but don't ask more from them.