1. Adaptive User Interface Modelling for Web-environments T-121.900 – 15.10.2002 Antti Martikainen antti.martikainen@helsinki.fi

2. Contents Requirements for Adaptation Device Independent UI Languages UI Models Model Mapping Conclusions

3. Scope This presentation is not about –Intelligence in adaptation –Adaptation based on users behaviour Rather it is about –Modelling principles to enable a single application to adapt to different kinds of devices, and –Finding balance between usability requirements and development times and maintenance costs

4. Screen resolution WAPPDAComputer 48x48256x3641024x768

5. Adapting applications to devices Managing bi-directional interactions requires device specific adaptation to –Screen resolution –Connection speed –Different Markup languages –Rendering capabilities –Functional capabilities

6. Language/Device specific capabilities Visual rendering –Colours –Tables –Frames –Images Voice detection vs. Visual input Scripting capabilities –Javascript Style sheet usage –CSS (  XSLT) …

7. The Common Multi-channel Delivery Mechanism

8. Device Independent UI languages

9. PDA

10. WAP

11. Voice System: "Masters Scores. Please select one of the following for player: Tiger Woods, David Duval, Phil Mickelson, Mark Calcavecchia..." User: "Tiger Woods." System: "Please select one of the following for Tiger Woods or say "all" to listen to all of available information: Player, Tournament Score, Round 1, Round 2, Round 3, Round 4." User: "Tournament Score." System: "The Tournament Score for Tiger Woods is 16 under." User: "Lookup." System: "What information would you like?" User: "Can I have the Round 3 score for Chris DiMarco?" System: "The Round 3 score for Chris DiMarco is 69. What information would you like?" User: "Goodbye."

12. Web browser

13. Windows CE

14. Examples of Device Independent UI languages UIML (User Interface Markup Language) –Does not allow implementing device specific features MAXML (Multi-channel Access XML) –Engine implements device specific features automatically  designer cannot affect usability

15. Common Problems with Abstract Languages Applications built with abstract languages are either –Implemented to match the capabilities of the “weakest” device (lacking required functionality), or –Not usable, at least concerning some devices

16. User Interface Modelling systems UIM languages consist of models –Task –Presentation –Domain –Device –Dialogue –User

17. Task model Describes how users do their tasks in a certain application Contains the task structure, and the order and division of interactions between user and system Formal task descriptions should work as a device independent starting point for the UI Task model could support a more straight forward flow in realizing user requirements in the UI

18. Presentation model Represents the visual and auditory elements provided to the user by the user interface. Presentation elements give abstract tasks a concrete form May also contain stylistic properties, such as colours and font size Example: –Define that a persons name is shown in an input field

19. Domain model Defines the underlying objects that the user can indirectly see and manipulate through the user interface Commonly attached to (abstract) task elements to achieve UI code reuse Example: –A product has certain attributes; These attributes are managed through certain actions

20. Device model Presents the capabilities, such as the used UI language, connection speeds and other properties of a device Example: –Can the device handle JavaScript? CC/PP –W3C standard for device capabilities –Incomplete does not define all necessary elements does not say what UIM systems should do with device properties

21. Dialogue model A more concrete approach to task model Defines interactions in cases of technical forces Example: –How to implement a confirmation, when one device is Javascript enabled and another is not?

22. User model Defines the attributes and roles of users Can be used to provide a way to model UI preferences for specific users or groups of users Examples: –Exclude a group of users from some task –Show all possible data attributes to company management

23. Mapping problem

24. Combining Separate Models Location, available services etc...

25. Transforming the UI

26. Conclusions Model-based UI development strives for –Systematic and faster UI development with UI code reuse –Serving all existing devices Difficulties –How to proceed from abstract to concrete UIs without compromising aesthetic design –Required models and mappings are not completely clear –Development tools are important (no commercial products) –New UI design methodology