Design Once
and Render Everywhere?
Krishna
Vedati
kvedati@covigo.com
Abstract
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).
Device Independent View Design in MVC based applications
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.
·Functionality
of the underlying application: If the application
is very simple and text-oriented, the application can be easily built without
compromising the user experience.
Are the current set of standards enough for a “Design Once and Render Everywhere” paradigm?
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?
Currently, many working groups at the W3C are making progress toward
either a universal markup language or technologies that will easily translate
one markup language to another. A
syntactic translation scheme, such as a mapping between one markup language
primitive to another may not help because of various other constraints (e.g.
personalization based on channel, delivery context); these translation
mechanisms fail to achieve the best user experience. For example, a simple
paragraph element in HTML may need to be split into a series of decks requiring
many round trips on a WAP phone due to bandwidth and deck-size
constraints. Presentation-centric
markup languages did not restrict users from introducing layout; therefore,
translating just markup elements will not directly result in better
presentations between channels. For example, a multi-column layout in HTML may
not easily be made available on a WAP phone.
Many companies have tried, with mixed success, to design universal
markup languages. Covigo believes the
W3C is moving in the right direction in terms of evolving one universal markup
language with extensions, such as XHTML with modules.
What would Covigo like to see the Device Independence working group achieve
to make “Design Once and Render Everywhere” paradigm possible?
·
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
·
…
References:
1
“Current Technologies for Device Independence”, Mark H
Butler, HP Labs Technical Report HPL-2001-83 4 April 2001
http://www.hpl.hp.com/techreports/2001/HPL-2001-83.html
2
Device Independence Principles,
W3C Working Draft 18 http://www.w3.org/TR/2001/WD-di-princ-20010918/
3
Modularization
of XHTML, W3C Recommendation 10 April 2001 http://www.w3.org/TR/xhtml-modularization
4
The
Extensible Stylesheet Language (XSL),
W3C Document Formats Domain http://www.w3.org/Style/XSL/
5
XSL
Transformations (XSLT) Version 1.1, W3C Working
Draft 24, August 2001 http://www.w3.org/TR/xslt11/
6
Covigo Presentation Server, http://www.covigo.com/products/products_presentation_server.shtml