=Paper=
{{Paper
|id=Vol-407/paper-15
|storemode=property
|title=Designing Usable Applications based on Web Services
|pdfUrl=https://ceur-ws.org/Vol-407/paper15.pdf
|volume=Vol-407
|dblpUrl=https://dblp.org/rec/conf/iused/PaternoSS08
}}
==Designing Usable Applications based on Web Services==
https://ceur-ws.org/Vol-407/paper15.pdf
Designing Usable Applications based on Web Services
Fabio Paternò, Carmen Santoro, Lucio Davide Spano
HIIS Laboratory – ISTI-CNR
Via Moruzzi 1
56126 Pisa, Italy
{fabio.paterno, carmen.santoro, lucio.davide.spano}@isti.cnr.it
ABSTRACT in model-based user interface design and development because
One trend in software development is to implement application logical descriptions allow designers to better manage the
functionalities through Web services. This eases the possibility of complexity of multi-device environments (see for example [1],
developing interactive applications exploiting functionalities [4]). This is usually obtained by exploiting XML logical
implemented by others. In this paper we discuss the issues raised descriptions and associated transformations for the target devices
when designing user interfaces for these types of applications. In and implementation languages. Having the possibility of
particular, we describe a possible approach to address them based specifying a user interface at different levels has several
on the use of model-based user interface descriptions with the advantages: it helps designers because the separation in different
possibility of obtaining versions adapted to different types of abstraction levels provides different “views” of the same user
interactive devices. The development of the final user interface is interface, and the selection of the most appropriate view is
supported by a semi-automatic process in which at first the performed by the designers depending on the specific aspects they
designers take benefit of an authoring tool able to automatically are currently interested in, and/or on their specific skills. In
generate the first version of the user interface and then, after an addition, it is worth pointing out how not only designers can be
evaluation phase of of the resulting user interface, they can involved in the approach, but also other stakeholders can play a
manually make further modifications and refinements in order to relevant role in the process. Indeed, as the method is supposed to
obtain highly usable user interfaces. be iterative and refinement-based with a semi-automatic approach
there is enough room for even an early intervention of evaluation
in the process, to the aim of identifying usability problems and
Categories and Subject Descriptors include the design of their solutions as soon as possible in the user
H5.m. Information interfaces and presentation (e.g., HCI). interface software lifecycle.
General Terms In addition, the information contained in the models can be
Design, exploited both at design and at run time. Therefore, the use of
models does not pose any particular constraints to when and how
the models should be used. Maintaining links among the elements
Keywords in the various abstraction levels enables e.g. linking semantic
Model/based design. Usability, Web services. information (such as the activity that users intend to do) with more
concrete levels, up to the implementation levels, and this can be
1. INTRODUCTION exploited in many ways. For instance, such links can be
One current trend in software development is the use of Web automatically supported by suitable transformations, which are
services. They have been introduced to better support useful for obtaining a description in a specific abstraction level,
software−to−software communication. This is achieved through once a description in a different level is available, not forcing
the WSDL (Web Service Description Language) description designers to build all the different descriptions or to use any
associated with each service, an XML-based description of the specific model.
possible operations, and input/output parameters. The basic idea is If we consider the abstract level, it is generally recognised that the
to ease the development of applications based on the SOA main benefits in using an abstract description of a user interface is
(Service−Oriented Architecture) approach in which often for the designers of multi-device interfaces, because they do not
applications developers have to design access to services and their have to learn all the details of the many possible implementation
compositions developed by others. languages supported by the various devices. Thus, one advantage
of using the abstract levels of a user interface is that designers can
Meanwhile, recent years have also assisted to a renewed interest
reason in abstract terms without being tied to a particular
platform/modality/implementation language. In this way, they
Permission to make digital or hard copies of all or part of this work for have the possibility to focus on the 'essence' of the interaction
personal or classroom use is granted without fee provided that copies are (e.g.: what is the intended effect the interaction wants to
not made or distributed for profit or commercial advantage and that achieve/support?), regardless of the details and specificities of the
copies bear this notice and the full citation on the first page. To copy particular environment considered. In addition, considering the
otherwise, or republish, to post on servers or to redistribute to lists, abstract level of the user interface appears to be particularly useful
requires prior specific permission and/or a fee.
when the user interfaces are aimed at handling Web Services.
I-USED’08, September 24, 2008, Pisa, Italy
Indeed, WSDL files provide a description of the operations
supported by the Web Services. The relationships of such
descriptions of the operations (contained in WSDL files) with the
abstract user interface objects expected to support them in the is that designers and developers have to create interactive
resulting user interface (contained in the abstract user interfaces) applications accessing application functionalities developed by
is an interesting issue to investigate, and appears to be promising others. Thus, they have to focus their effort on how to take into
in helping to solve the problem of generating user interfaces for account the specific requirements that the application interface of
Web Services. the existing Web services pose. In addition, they also have to
This is a novel problem. Indeed, most model-based approaches indicate how to compose functionalities implemented in different
have not addressed the specific issues related to Web-service Web services.
based applications. Work on generating user interfaces for Web
services but without using model-based approaches has been Our approach (see Figure 1) is to have first a bottom-up step in
carried out at Dresden [6] and Yonsei [5] universities. The order to analyse the Web services providing functionalities useful
limitation is that such works usually consider direct mappings for the new application to develop. In this phase an analysis of the
between Web services functional interface and an implementation operations (OP1, .. OP4 in Figure 1) and the data types (DT1, ..,
language for user interface, which cannot be exploited when DT4 in Figure 4) associated with input and output parameters is
carried out in order to associate them with abstract interaction
devices supporting different implementation languages are
considered. objects suitable to support presentation of their values and their
modification.
Figure 1. The Proposed Approach.
Work by Vermeulen et al. [7] aimed to solve such issues by
extending Web services with OWL-S combined with task and For example, a Boolean can be represented by a button, an
enumeration type by a list or a radio button depending on its
layout model. This approach requires a lot of manual work by the
designers. cardinality. Thus, for each Web services we can have a
corresponding abstract description of the user interface.
In general, the type of issue that we have to solve is how to
associate information regarding the data types and information on Then, we can use the task model expressed in ConcurTaskTrees
the user interface. Indeed, while the semantic Web has mainly (CTT) [3] for describing the interactive application and how it
focused on the data semantics through the use of ontologies and assumes that tasks are performed. This notation is a standard de
languages that allow for more intelligent processing, user interface facto in the area of task model representations, and it also under
models allow designers to consider the semantics of interaction, consideration for standardization in the W3C consortium. CTT
which is related to the tasks to support in order to reach the users’ provides a first classification of tasks depending on the agent
performing them: the user (in case of only internal cognitive
goals. Thus, we need to link these two types of information.
activity, such as making a decision about how to carry on a
In this paper we discuss how to address the issues introduced by session), the system (completely automatic task) or interaction
proposing a specific approach and a language and the associated (involving both the user and the system). Web services are
environment, which builds on our previous experiences but aims application functionalities, thus they are associated with system
to provide better support when designing interactive applications tasks. Another issue is what level of granularity to reach in the
based on Web-services, we also report on how the approach can task decomposition. There are mainly two possibilities:
be applied in an application in the home domain and how it associating the system basic tasks to the web services or reach a
supports the interplay between software development and further detail in order to associate each system basic task with the
usability evaluation. operations of the web services. Thus, if a Web Service supports
three operations, then there would be three basic system tasks.
2. METHODOLOGICAL APPROACH The latter solution allows for a more detailed and flexible
specification.
A traditional top-down approach going through the various
abstraction layers that have been considered useful in HCI (task, The next step is to obtain first an abstract, and then a concrete,
abstract interface, concrete interface, implementation) does not platform-dependent, user interface description of the user
seem particularly effective in this context for various reasons. One interface. To this end we have to consider information derived
from the task models and the various pieces of abstract interface aspects such as correlation between the value of interface
associated with the various Web Services. The information elements, conditional presentation connections, conditional layout
coming from the task model is useful in order to identify how to of interface parts, etc.
structure the presentations of the interactive applications and The data model is described using the XSD type definition
define the navigation model through them. The information language. In MARIA there is the possibility to define the data
coming from the abstract interface excerpts are mainly useful to manipulated by the user interface both at the abstract level
identify the interface elements to include in each presentation and (through an abstract data model) and at the concrete level (a
their type. Defining the structure of a presentation mainly means concrete data model, which is a refinement of the abstract one).
to identify the logical groups of elements inside it, and whether The introduction of a data model at the abstract level also allows
there are particular relations among some of such groups The for having more control on the operations that will be done on the
structure of the Web services can be useful for this purpose different data types. In addition, the data model is also useful for
because we can think of ‘groupings’ associated with each specifying the format for values: the format specification for a
operation (indicating how to represent their input and output value can be expressed in MARIA by bounding the concrete data
parameters), and higher level groupings associated with the Web model with the editing interactor used for getting the input value
services. from the user: if the editing object is bound with a date, the
The use of an automatic tool and, consequently, automatic underlying implementation will have the needed information for
transformations, has several advantages: it allows for generating validating the value that will be provided by the user. The
usable and consistent user interfaces by incorporating already in MARIA data model can be the same as the types part of the
the transformation rules some design guidelines/rules for WSDL description of the service, or it can be mapped on a more
obtaining usable interfaces. In addition, it also allows for ensuring UI oriented description using an XSLT style sheet. The new
that some minimal consistency overall the pages is automatically authoring environment for MARIA XML is currently being
kept (eg: ensuring the consistency of the title label or the style of developed to support this operation. The problem of mapping
the presentations overall an entire user interface application). fields to services parameters is also supported by the MARIA
However, very often the results of fully automatic authoring tools environment: the mapping is obtained by performing the inverse
for user interfaces are not very satisfactory from a usability point operation of the process described before: another XSLT style
of view, even when some good design rule have been incorporated sheet performs the mapping from the AUI data model to the
in the transformations. WSDL one.
To this aim in our approach a semi-automatic process has been Figure 2 shows a graphical representation of an abstract interactor
proposed. Such a process provides also space for (a manual) of type only_output in MARIA XML abstract user interface
intervention, an evaluation phase carried out on an initial version description (the description has been unfolded only for the higher
of the user interface that has been automatically generated. levels).
Therefore, in order to improve the usability of the final results, an
evaluation feedback from a HCI expert can be envisaged so that a
consequent manual refinement and modification of the user
interface which has been automatically obtained with the
authoring tool can be carried out accordingly.
3. MARIA
In order to obtain a more powerful description language able also
to satisfy the new requirements posed by service/oriented
architectures, and modelling the new forms of human-computer
interaction, we are developing a new UI specification language,
which will take also into account the new technical requirements
raised by the issue of generating usable interfaces for Web
Services. The new language name is MARIA (Model-bAsed
descRiption of Interactive Applications) XML and it can be used
for the abstract and concrete user interface definition. Its
development takes into account our previous experiences with a
previous language (and the associated tool) for designing multi-
device user interfaces, TERESA XML [4].
There are many differences between TERESA XML and MARIA
XML. For example, MARIA supports also an abstract description Figure 2. The specification of the only_output element
of the underlying data model of the application. The interactors
(namely, the elements of the abstract or concrete user interface)
which compose an abstract (resp.:concrete) user interface, can be The only_output interactor models the possibility for the user to
bound to a type or an element of a type defined in the abstract receive information from the application, and, depending on the
model. In this way, a change of application status is modelled as a type of information received (text, object, description, feedback,
change of one or more values in the abstract data, which will be alarm), suitable interactors should be used.
reflected on the interface (abstract or concrete) status. This is a
powerful feature that can be used to express in a natural manner
In the same way, within MARIA XML an abstract interactor
allowing the user to interact with the underlying application is
refined into different objects depending on the type of activity
which is supported: selection (select an object within a set of Figure 4 shows how it is possible, with MARIA XML, modelling
objects), edit (modifying an object), control (activating a a concrete user interface object (for the desktop platform)
functionality), and interactive description (a combination of both allowing for editing a textual value. More in detail, in the figure it
only_output and interaction objects). is visualised the hierarchy of concrete interactors unfolded only
for the branch of textfield objects, which allow editing text-based
Figure 3 presents a graphical representation of an abstract values. Textfields have a number of attributes, label (the label of
interactor of type interaction in MARIA XML abstract user the interactor), length (the length of the field), and the information
interface description (the description has been unfolded only for about whether the field is aimed at accepting passwords (therefore
the higher levels). the object should have a special behaviour in the feedback -eg: in
a graphical platform it will not visualise the inserted value).
Figure 3. The specification of the interaction element
The corresponding excerpt of MARIA XML Schema for the
abstract user interface description of the abovementioned
interaction object (only for the first level) is visualised, together
with the specification of the two possible types an interactor can
assume (interaction and only_output):
Figure 4. The specification of the textfield element
In Figure 4 below the objects derived from refining the interactor
object down to the textfield object have been highlighted with a
different colour, in order to make clearer to the reader such
decomposition.
…
Below there is the corresponding MARIA XML specification single input/output operation: as a consequence, the same
excerpt for the textfield object interactor will be used for supporting the input and output
operations. Otherwise the two operations will remain distinct and
different interactors will be used for accessing the two operations.
As an explanatory example of the above concept, we could
consider a mobile user interface in which screen space is limited,
and therefore it may be useful to have a single interactive element
able to cover both aspects (possibility of changing the state and
developed a heuristic indicating that when in the WSDL we find
set and get, like e.g. setSensorStatus and
getSensorStatus before) associated to one device, then they are
mapped onto one element able to support both methods instead of
two separate interface elements.
Enumeration data type, with high cardinality
Abstract User
Interface
4. AN EXAMPLE APPLICATION
We have applied our approach to the design of a home Concrete
application. This is an application domain that is raising an Desktop
more populated with interactive, intelligent devices. In this case
we have used a home server able to support interoperability
(X10, UpnP, Konnex, …). The functionalities of the domestic elementName
appliances are made available through a standardised set of Web
services exposed by a home server [2] [Other elements]
This case study has also provided us with the possibility to define
an algorithm for generating a default user interface for accessing a
Web service operation. The idea is that the generated UI can then Concrete
be refined by a designer with an authoring environment, but we Mobile
For the sake of simplicity, in order to illustrate the algorithm we
elementName
and data types.
The algorithm has a first step that aims to extract an object [Other elements]
oriented model of the operations: each operation is associated to a
data type (the type “owner” of the operation) defined in the types
part of the WSDL file, checking the operation parameters.
Concrete
Vocal
input and output operations that read or write the same properties.
• Boolean GetSensorStatus(Sensor s) [elementName]
These two operations are bound to the Sensor data type, the first
[Other elements]
one is an input operation that writes a value in the status field and
it is marked as input, while the second is a read operation and it is
marked as output (it delivers as a result a Boolean data, as you can
see from its specification). When the parameter that represents Figure 5. Examples of mappings
the value of the input operation matches with the read value of an
output operation, their names are checked using the following
heuristic: if the names are similar enough, they are merged into a
The next step is the creation of the abstract user interface using 5. CONCLUSIONS AND FUTURE WORK
the collected operation information. The table shown in Figure 5 In this paper we have discussed a method for the model-based
describes an example of the main mapping rules in the case of an design of interactive applications based on the use of Web
enumeration data type with high cardinality, by showing an services. We have also briefly reported on the development of a
abstract single_choice element and the corresponding concrete new XML specification language, and the associated authoring
elements for the desktop, mobile, and vocal platforms. environment, to better support the method, and, more generally,
to provide more flexible support to UI designers. We have also
In this way it is possible to obtain an application able to support illustrated the approach with a specific example in the home
access through multiple types of devices. For example, it is domain.
possible to generate versions for a PDA and a desktop system, but In addition, we pointed out how our approach leverages an easy
other device types can be considered as well. In the case of the coupling between on the one hand software design and
PDA access, we consider the possibility of generating an development and, on the other hand, usability evaluation. Indeed,
application in C#, even able to support libraries for vocal and the approach is supported by a semi-automatic process in which
multimodal access. This application has to be downloaded and an initial version of the user interface is expected to be obtained
installed in the mobile device. In the case of a desktop access, we through the use of automatic tools in which some guidelines for
consider the generation of a Web application able to support good UI design are already incorporated (eg within the
access, through some servlets, to the web services associated with transformation rules). Therefore, the initial results automatically
the domestic appliances. Whatever interaction device is actually obtained should already be compliant with principles of good
used, then the user can freely choose one domestic device and design if they have been incorporated in suitable transformations
perform the desired information, usually check the state of some (which, if not hard coded in the automatic tool can be even subject
parameters (such as temperatures or alarms) or change some of of an usability evaluation as well). Afterwards, the preliminary
their values. versions of the user interfaces so obtained are supposed to be
analysed and evaluated by HCI experts: the feedback of such an
evaluation can be included through a manual refinement which
can affect (and, hopefully improve) the result not only at the final
UI level but also at more abstract UI levels, depending on their
skills.
Future work has been planned for applying the presented approach
to more complex case studies, in order to test the generality and
the flexibility of the method.
6. ACKNOWLEDGMENTS
This work is partly supported by the ServFace EU ICT project.
Figure 6. The Desktop User Interface.
7. REFERENCES
[1] Abrams, M., Phanouriou, C., Batongbacal, A., Williams, S.,
The different screen space implies substantial differences in the Shuster, J. UIML: An Appliance-Independent XML User
generated user interfaces. In the desktop interface (see Figure 6) Interface Language, Proceedings of the 8th WWW
it is possible to show the various rooms, select a device and access conference, 1999.
the associated controls in one single presentation. [2] Miori V., Tarrini L., Manca M., Tolomei G. - An open
standard solution for domotic interoperability. In: IEEE
Transactions on Consumer Electronics, vol. 52 (1) pp. 97-
103. IEEE, 2006.
[3] Paternò F., Model-based Design and Evaluation of
Interactive Applications, Springer Verlag, November 1999,
ISBN 1-85233-155-0.
[4] Paternò F., Santoro C., Mantyjarvi J., Mori G., Sansone S.,
Authoring Pervasive MultiModal User Interfaces,
International Journal of Web Engineering and Technology,
N.2, 2008
[5] Song, K., Lee, K.-H., 2007. An automated generation of
Figure 7. The PDA User Interface. xforms interfaces for web services, Proceedings of the
International Conference on Web Services, 856-863.
All these possibilities are still available in the PDA interface (see
Figure 7) but they require multiple presentations and the addition
of navigation capabilities among them.
[6] Spillner, J., Braun, I., Schill, A., 2007. Flexible Human Services with User Interface Models, Proceedings
Service Interfaces, Proceedings of the 9th International Engineering Interactive Systems 2007, Salamanca, Springer
Conference on Enterprise Information Systems, 79-85. Verlag.
[7] Vermeulen J., Vandriessche Y., Clerckx T., Luyten K. and
Coninx K., Service-interaction Descriptions: Augmenting