In the mid 80s, X Window system enabled network-independent graphics. In the 90s, scripting and next-generation languages such as Java, Tcl, Perl, Python, etc. made “design once and run everywhere” programming models possible. In all these efforts, the device independent presentation problem was inherent. With the ubiquity of the Web, current standards are now striving toward solving problems related to universal presentation – e.g. device-independence, or the ability to access a given application on any device. Will these standards succeed?
User experience on a given device may vary across several different dimensions, including:
§ terminal capabilities (screen characteristics, operating system, hardware capacities, etc.);
§ physical channel (wireline, cellular, POTS, etc.);
§ sensory channel (auditory, visual, touch, etc.); and
§ mode (online, offline, asynchronous alerts).
Producing the optimal user experience across so many dimensions poses a challenging problem. The functionality of an application may differ across different devices. And even when the functionality remains the same, the design and interaction may still vary. Covigo believes that designing an application using the Model-View-Controller (MVC) paradigm can solve this problem. When properly applied, the MVC paradigm enables us to build one application for any combination of dimensions. This position paper outlines our views on various presentation design (View) paradigms, such as “design once for all channels and modes” (one-to-many) or “design views specific to each channel or mode or a combination there of” (many-to-many).
To create complex multi-channel, multi-modal applications, yet still provide for efficiency and ease in both development and maintenance, we would like to call attention to two things.
The first is the use of the MVC architecture for application construction. MVC separates the data, presentation and logic of an application into three independent, manageable and modular parts. Thus, while multiple terminals may call for multiple systems of presentation for an application, great efficiency comes from being able to use a single controller and a single data model.
The second is a means of creating universal presentations/user interfaces/views. Universal views can be translated into many terminal-specific views, based on the following:
§ specification (mark-up language, programming language)
§ content (static or dynamic text, images, media)
§ graphic design (lay, visual design)
§ supported interaction (buttons, hyperlinks, forms, scripts).
As shown in Figure 1, MVC separates the presentation (View), the underlying logic of any application (Controller), and the data (Model).
Figure 1: Model-View-Controller Paradigm
The Model represents the data in the application. It manages all the transformations of data. The model does not need to have any information about the view or controller. It can be queried by all the views associated with it through the controller.
The View represents the user interface of the application. It maintains the look of the application and presents the data to the user. The view does not act on the data or change it. It simply forwards any user input to the controller. The view further updates the user interface when it receives notifications from the controller that the data has changed.
The Controller represents a mapping between the user interaction from the view and application actions and business logic. It is typically specialized and is designed to work with interactions from a particular view. The controller translates the user input into operations on the model data and selects which view to display, based on user input and actions on the model.
For multi-modal, multi-channel applications, the controller can itself be designed as a finite state automaton using a set of application states. For example, Figure 2 displays a controller for simple portal application, where a user may enter through either a data or voice channel to access e-mail or voicemail, respectively.
Figure 2: A sample portal application interaction flow
Note that a state may exist for one dimension of the application and not another. For example, the states with red labels only exist when the application is accessed through a voice channel. Assuming each state of the controller has a one-to-one mapping between user interaction and business logic, each state in the controller may have a view associated with it. Now the central question is: how should the views be designed? Can a single view be rendered to multiple channels in multiple modes, or should different dimensions require their own views? In building multi-channel, multi-modal applications, Covigo has found that good user experiences are produced by highly customized, device-specific views. States that exist in multiple dimensions, such as the login state in Figure 2, can be associated with multiple views, but then a problem arises in maintaining the application.
Figure 3: A set of views associated with a login state in the sample application
For each state, a run-time controller can decide which view to render based on the delivery context (channel, mode, connection speed, security requirements). The run-time controller can only act on the options made available during design time. If there is only one universal rendering rule, then the controller can apply one-to-many transformations to the view using the delivery context and render it appropriately to the particular channel or mode. On the flip side, if there are multiple views for a state as shown in Figure 3, then the controller can decide which view to render based on the delivery context and many-to-many transformation scheme. What factors drive a developer to use a many-to-many transformation scheme vs. a one-to-many transformation model?
Many-to many: Currently, many people design one view per dimension. This is costly in both money and time, but may be the best option for the following reasons:
· Delivery preferences: Users can choose to receive the information in a specified format, and converters from a standard format to the user-specified format may not exist. For example, a Java-enabled device that does not have a standard browser may not be able to render HTML or WML correctly.
· Number of channels to render to: The interaction in different channels may be different. For example, in a voice application, misrecognitions are a common phenomenon, and the states that try to correct misrecognition may not exist in visual applications.
· Functionality: Different channels and modes dictate the need for different functionality. For example, web-based, real-time interactions can display graphics and Flash interfaces, but WAP-enabled cell phones cannot.
· Integration with existing infrastructure: If a particular application is designed in a programming language that does not have tools to facilitate a one channel-to-many channel transformation, developers are forced to design for every channel separately.
One-to-many: In an ideal world, everybody wants to design once and have the ability to render that content to every dimension the application persists in. This can be achievable if all of the following constraints are met:
· Limited set of channels and modes to support: If the application is required to support only a few channels in a single modality, then the problem of real-time translation can be simplified.
· Good one-to-many markup language transformations: If the underlying programming system provides tools and primitives to translate one markup language to another, then developers can design a view once and have it rendered to many dimensions with minimal effort.
· Complexity of maintenance: The complexity of maintaining many views for every dimension may force developers to reduce the functionality of the application so that a one-to-many presentation scheme can be adopted.
of the underlying application: If the application
is very simple and text-oriented, the application can be easily built without
compromising the user experience.
Terminal and application specific UI is always desirable from an end-user perspective. If a UI is tailored to the screen or channel and the mark-up language and capabilities of the device, it will always be better than a one-size-fits all solution. But such a system is not attractive to those paying for builders and maintainers of these applications, because it can be complex and large; the work necessary to construct and maintain it is impractical. Can there be a universal presentation system that will get you close to terminal-specific presentation and still provide great, relevant amounts of information with ease and efficiency?
· Design standard Markup Language to Markup Language transformations between all known, standard presentation-based markup languages using CC/PP & UAprof-based standards
· Describe more vocabularies for all device contexts so that application-level infrastructure can easily contend with contextual issues, while rendering content to multi-channel, multi-modal devices
“Current Technologies for Device Independence”, Mark H
Butler, HP Labs Technical Report HPL-2001-83 4 April 2001
2 Device Independence Principles, W3C Working Draft 18 http://www.w3.org/TR/2001/WD-di-princ-20010918/
6 Covigo Presentation Server, http://www.covigo.com/products/products_presentation_server.shtml