1. Cloud platforms Lead to Open and Universal access for people with Disabilities and for All Implementation plan for A102.1 - “Basic profile parameters” Vassilis Koutkias, CERTH

2. A102.1 in the DoW

3. A102.1 in the DoW (highlights)

4. Task Analysis: Storage format  Approach:  Needs to be in accordance with the work of the architecture team, which elaborates on a JSON-based structure:  http://wiki.gpii.net/index.php/Simplifying_Preferences_Documents #Index_Preferences_by_Term_Name http://wiki.gpii.net/index.php/Simplifying_Preferences_Documents #Index_Preferences_by_Term_Name  Closely related with the user preference sets:  http://wiki.fluidproject.org/display/ISO24751/2012-07- 24+Meeting+on+Context+Description http://wiki.fluidproject.org/display/ISO24751/2012-07- 24+Meeting+on+Context+Description  We are exploring the potential of developing a mechanism to convert the user N&P sets from the User Profile Ontology (instances) to the agreed JSON format  Status: In progress.

5. Task Analysis: Connection between user N&Ps with the adaptable interface parameters  Approach: Work in continuation from A101.2 A UserTask requires a UserInterface to be performed. The UserInterface makes use of UserInterfaceComponents.  Status: In progress.

6. Task Analysis: Connection between user N&Ps with the adaptable interface parameters Indicative set of parameters for expressing N&Ps (based on the consolidation of the settings collected from SP3 developers) associated with user interface elements, interaction channels, etc.

7. Task Analysis: Connection between user N&Ps with the adaptable interface parameters Example individuals defined for the UserInterfaceComponent class

8. Remarks in association with the term “Basic Profile Parameters”  We need to define the criteria for “basic profile parameters”:  applicability, coverage, importance/priority ???  The above material may provide a basis for defining the “basic” profile parameters based on coverage & applicability:  however, it needs to be reviewed!  The DoW explicitly refers to ETSI ES 202 746:  we have all the preferences incorporated in the ontology! Would that be sufficient at this stage?

9. Remarks in association with the term “Basic Profile Parameters”  Material also considered for use:  Some N&Ps from the literature that we collected for either specific platforms (e.g., JavaME phones) or generic ones.  The user interviews documented in D101.1.  Considerations:  Is there any chance to get further information from the users?  How can we make sure that these parameters are sufficient?

10. Task Analysis: The algorithms to create/edit/store/access the profile data  Remarks:  We have to define the “logic” of the various tasks concerning profile management  The most important/complex part: profile creation/initialization!  We have collected hundreds of properties!  BUT: For profile initialization it is not applicable to ask the user for all potential need & preferences…  Status: In progress.

11. Approaches for User Profile Initialization 1.Define/select core set of “basic profile parameters” that will be used for guiding the profile construction in a wizard-like fashion 2.Exploit the content of the User Profile Ontology to provide additional configuration options, related with the values of the “basic profile parameters” core set AND/OR 2.Match the values of the “basic profile parameters” core set with profile stereotypes (to be stored in the ontology) and prompt the user for additional input, according to similar options that have been set in the stereotypes  Options for simple/advanced setup could be applicable Approach #1: Wizard-like UI based on the Basic Profile Parameters

12. Source: ISO/IEC 24751-2, page 93. Approaches for User Profile Initialization Approach #1: Similar with the approach described in ISO/IEC 24751-2

13. Profile stereotypes based approach:  a set of profile stereotypes will be defined, in order to cover the widest possible spectrum of interaction requirements  the user (and/or his/her care-giver?) would be asked to pick the stereotype that matches him/herself most closely and then get the opportunity to fine-tune this basic profile to his/her own N&Ps Approaches for User Profile Initialization Approach #2: Selection from Existing Profile Stereotypes

14.  Requirements:  Concrete knowledge/information to define the stereotypical profiles:  Sources considered (cf. the latest email exchange):  The interviews conducted in A101.1  Personas provided by AEGIS and Accessible  Profiles (stereotypes) from the Multireader project  How will we make the “match” between the available stereotypes and the respective user? Is there some initial information or procedure that will trigger this selection? May be involve care-givers/relatives?  Enrichment/advancement of the Registry content  How will we assure that the coverage of the employed stereotypes is sufficient? Approaches for User Profile Initialization Approach #2: Requirements

15.  Definitions and the/a set of “basic profile parameters”  Definitions and specs concerning the user preference set storage format (in accordance with the Architecture team)  The “logic” for creating/editing the profile data  Updated version of the User Profile Ontology Expected Outcomes from A102.1

16.  Consider the Context Toolkit: http://www.contexttoolkit.org/http://www.contexttoolkit.org/  More than prototyping, simulation in fact:  Other options? Tools for Prototyping