User Interface Service Software Developerís Guide - Hitech Projects
User Interface Service Software Developerís Guide - Hitech Projects
User Interface Service Software Developerís Guide - Hitech Projects
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
January 2008<br />
Public<br />
• Operation mode: The interaction has been initiated by the user. He wants to change<br />
something. So the goal of the interaction has to be told to the system or has to be<br />
discovered by the system. Using a GUI or speech the user has to select the operation<br />
out of the offered functionalities of the whole services. He has also to specify values<br />
needed for the responsible service. Because there could be more than one hundred<br />
functionalities offered by the services of one home, these functions have to be sorted<br />
into groups and an arbitrary number of subgroups to give the user a structured<br />
overview. The functions and its groups could then be represented for example by a<br />
menu hierarchy either by GUI or speech. The operation mode includes also the<br />
possibility to check the status of different services and the values of parameters of this<br />
service. To be used by the operation mode a service has to describe itself, to define<br />
possible user interaction functionalities and to give a model of its internal structure to<br />
the UIS. The UIS will use data models, dependency-graphs and user dependent menu<br />
logic descriptions to build a personalised menu structure.<br />
• Event mode: The event mode offers the system the possibility to initiate an interaction<br />
with the user. The dialog flow and the requested input parameters are fully controlled<br />
by the application interacting with the user. The event mode can be used for warnings,<br />
messages, questions etc.<br />
3.3.3.2 Integration with the Context Management <strong>Service</strong><br />
<strong>User</strong> interactions form relevant context information, especially when considering implicit user<br />
interactions. For instance, an application can react to specific contextual information, including<br />
user location, but also user gestures and user speech. Two options may thus exist: the first<br />
one is that every user interaction service implements the Context Source interface. We have<br />
not opted for this solution, as this may impact the performances of the overall UIS.<br />
Furthermore, it dramatically increases the variety of context sources related to user interfaces,<br />
and context consumers may have difficulties to choose the most relevant one.<br />
The second option consists in providing only one context source, namely the dialogue<br />
manager. Then, every user interface provider and consumer interacts with the dialogue<br />
manager, which centralizes all the contextual information related to user interaction.<br />
A typical usage scenario can take the form (Figure 2):<br />
Figure 2. Typical DM user scenario.<br />
Possible issues: The time delay induced by the CMS broker and the web service eventing<br />
mechanism may not be acceptable from the user point of view<br />
Amigo IST-2004-004182 84/114