Published on

Presentation of the Imhotep framework in the IWAAL 2010 conference. Imhotep is an user-centric framework for adaptative interfaces.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. A user-centric approach to adaptable mobile interfaces<br />Aitor Almeida, Pablo Orduña, Eduardo Castillejo, Diego López-de-Ipiña<br />DeustoTech –Deusto Institute of Technology<br />Avenida de las Universidades 24,<br />48007 Bilbao (Spain)<br />{aitor.almeida, pablo.orduna, eduardo.castillejo, dipina}<br />Marcos Sacristán<br />Treelogic<br />Parque Tecnológico de Asturias · Parcela 30E33428 Llanera · ASTURIAS (Spain)<br /><br />
  2. 2. Need for adaptative interfaces<br />Framework architecture<br />Preprocessor directives<br />Fuzzy Knowledge-Eliciting Reasoner<br />Conclusions and future work<br />
  3. 3. Need for adaptative interfaces<br />Less technology users among elderly and people with disabilities <br /> Kaye, H.S., Computer and Internet Use among People with Disabilities, in Disability Statistics Report 2000, Department of Education, National Institute of: Washington D.C.<br />
  4. 4. Need for adaptative interfaces<br />This user base is going to grow even more with the increasing of average age in Europe.<br />Andrew Arch. A Review of Literature Relating to Web Accessibility and Ageing.<br />
  5. 5. Need for adaptative interfaces<br />Developers traditionally tend to ignore or neglect this user base<br />The individual user groups (each disability have different requirements) may not be big enough to justify the additional development costs<br />Developing accessible applications can be difficult.<br />
  6. 6. Need for adaptative interfaces<br />Our hypothesis: “Providing tools that ease the development of adaptative, user-centric applications will encourage the creation of accessible AAL applications”<br />
  7. 7. Framework architecture<br />To this end we have created the Imhotep framework<br />Design objectives:<br />Make the framework platform independent<br />Reduce the adoption costs<br />Help AAL programmers without expertise in accessible applications <br />Practical down-to-earth approach<br />
  8. 8. Framework architecture<br />Composed by three main elements:<br />The preprocessor directives<br />The adaptation server<br />The fuzzy knowledge-eliciting reasoner (integrated in the adaptation server)<br />
  9. 9. Framework architecture<br />
  10. 10. User capabilities<br />Initially divided the user capabilities into four groups: Sensorial, Cognitive, Physical and Communicational.<br />Later we added the Combined group to represent the synergies generated by the accumulation of various disabilities.<br />
  11. 11. Device capabilities<br />We have used WURFL 2.9.5 to identify the device capabilities.<br />An open source XML database containing the data about the features and capabilities of a large number of mobile devices.<br />
  12. 12. Preprocessor Directives<br />Used to annotate the code to state which part should be executed. <br />Based on the J2MEPolish approach to preprocessor directives.<br />Identified by:<br />//# in languages such as Java, C# or C++,<br />#// in languages such as Python or Perl<br />‘// in VB.NET. <br />Three types of directives:<br />Conditionals<br />Error handling<br />Code parameterization<br />
  13. 13. Preprocessor Directives<br />Conditional directives can be used to avoid the compilation of fragments of code if certain conditions are matched. These conditions can include calls to functions provided by the framework.<br />
  14. 14. Preprocessor Directives<br />Error handling directives can be used to report an error in order to manage unhandled situations. <br />
  15. 15. Preprocessor Directives<br />With the code parameterization developers can directly store in code variables the system ones. <br />
  16. 16. Fuzzy Knowledge-Eliciting Reasoner<br />Objetives<br />To infer new user and device capabilities from those specified in the profiles.<br />To enable the AAL developers to abstract from the crisp values (the user has less than 3 dioptres) in favor of more natural concepts (the user can see without a significant problem).<br />
  17. 17. Fuzzy Knowledge-Eliciting Reasoner<br />The developer might only want to establish high level asserts such as "is the screen big?" or "is the processor fast?“<br />Problem  some of these asserts depend on the global market of mobile devices at a particular moment in a particular place<br />Solution use popularity metrics (Google Trends) to estimate the market share of the devices.<br />
  18. 18. Fuzzy Knowledge-Eliciting Reasoner<br />First we apply a decay mechanism to the trend data to take into account the “age” of the values (data from 2005 is not as relevant as data from the previous month).<br />We establish the distribution of the relevance of each technical detail (for example, the screen resolution)<br />We divide the universe into different linguistic terms defined by the user ("big screen", "normal screen" and "small screen”)<br />With this division the membership function for the screen resolution for each term is defined.<br />
  19. 19. Fuzzy Knowledge-Eliciting Reasoner<br />An example of popularity calculation for all the screen resolutions of all the mobile devices in the WURLF database<br />
  20. 20. Fuzzy Knowledge-Eliciting Reasoner<br />Membership functions for the terms small, normal and big<br />
  21. 21. Fuzzy Knowledge-Eliciting Reasoner<br />Results can be localized<br />SpainJapan<br />
  22. 22. Fuzzy Knowledge-Eliciting Reasoner<br />Higher level terms can be built by the developer on top of others terms.<br />IF screensize IS big AND resolution IS normal <br /> THEN videoCapabilty IS high;<br /> <br /> IF screensize IS big AND resolution IS big <br /> THEN videoCapabilty IS very_high;<br />
  23. 23. Fuzzy Knowledge-Eliciting Reasoner<br />To ease the development of the rules and the membership functions we have created a wizard ( that assists the developers in this task<br />
  24. 24. Fuzzy Knowledge-Eliciting Reasoner<br />
  25. 25. Future Work<br />Makethe framework more developer friendly.<br />Use additional device databases to improve the devices’ data.<br />Improve the creation process of the membership functions.<br />Make the framework available as an Open Source project by the end of the year.<br />Evaluate the framework with the AAL projects we are involved.<br />
  26. 26. Thanks for your attention<br />Questions?<br />This work has been supported by project grant TSI-020301-2008-2 (PIRAmIDE), funded by the Spanish Ministerio de Industria, Turismo y Comercio<br /><br />