Presentation of Eric Sherman and Edward Shrotliffe A User-Adaptable Interface to Predict Users' Needs presented by: Laconya Ruby (Nov 11) UIMS User Interface Management System - set of tools used to support UI design and implementation Used to: * speed and improve the process of UI design * make it easier to adopt user models into the design of UIs * automate the integration of user models into UIs * allow experts in human factors design to create UI * incorporate user knowledge into the design of a UI automatically PODIUM Personalized Designer: An intelligent user-interface manager Purpose: to show that a UIMS that is supplied with a UI automatically designed for a large and diverse user community can tailor that UI automatically for each of may subgroups of a large user community Current problems with User Modeling: * Match between user and application through interface is impossible * User modeling requires generalization * No such thing as an average user * User knowledge is not static * Inability to create accurate models * Not practical with large user communities Solution to User Modeling Produce a generalized UI that can satisfy the needs of many users * less expensive * less efficient * more features than any single user or community needs Because of weaknesses in User Modeling and Generalization: the process of building the UI has been speeded up to allow for more time to model and test - therefore, getting the information needed >from the most logical source, the user. Trend in UI Design (one) - toward the non programmer and greater involvement of human factors experts with potentially more efficient UI and more closely based user models 3 Classes of UIMS: * Language based UIMS (programming) - HYPERTEXT - Rapid/USE - Sassafras * Graphical Specification UIMS (graphical tools) - Trillium - Menulay - HyperCard - NeXT Interface Builder - Peridot * Automatic Creation - designer specifies application semantics and then to automatically build the UI by associating procedures with graphic representations - Control Panel Interface Trend in UI Design (two) - toward involving the user PODIUM * User Adaptable UIMS * Domain - clinic chart for physician's workstations - physicians make up a large, diverse user communities which are easily divisible Which parts include the user in the design process and which parts are left to the UI designer? * Users are allowed to custom-tailor parts where they have expertise * Users are allowed to custom-tailor parts where they have an opinion Under the physician's clinic chart, users are experts in the area of task concepts Includes: how information is displayed (i.e. tables versus graphs) adding data ordering tests Use of PODIUM PODIUM asks the user 2 questions: Name Specialty PODIUM uses this information to: * identify the user's community * locate the ideal user map * proceed to build the UI UI Building tools: UI Generator - builds the UI from a single user map UI Generator comprised of: * Glue System - builds the UI * Libraries - contain data used to build UI - Task Library - contains all the tasks in the complete generic UI (code and graphics) - Module Library - contains templates used to build tasks in the task library * Task Builders - build new data and graphics to be included into the library After the UI has been built, The user can at this point use the editing tools to custom-tailor the default UI. The user is then offered the opportunity to include in his/her final version the most recent edits by others in the specialty. Testing of PODIUM 1. Can users designate their user characteristics and use PODIUM's editing tools to alter the user map and custom-tailor their UI? 2. Can PODIUM represent the UI so that it can use the information obtained through its experience to redefine the initial, generic UI? 3. Will the results of PODIUM and its users produce UIs that are improvements over what would exist without PODIUM? Methods Specialties chosen: 4 - internal medicine 4 - urology (Chosen because they have different information needs) Each physician was given a 5 minute overview of PODIUM and its purpose. Physicians were then told they could make changes to the interface or leave it as it was. Upon completion, physicians were asked questions about the experience and specifically about the adequacy of the UI they created. Results PODIUM does have the ability to incorporate user's knowledge and opinions into the design process 1. Can users designate their user characteristics and use PODIUM's editing tools to alter the user map and custom-tailor their UI? Not clear Although the concept of editing was introduced in the five minute introduction, users often needed further assistance. Responses from the questionnaire also indicated that the users had difficulty understanding the concept of editing. There were mixed reactions as to whether they had difficulty actually editing the UI. 2. Can PODIUM represent the UI so that it can use the information obtained through its experience to redefine the initial, generic UI? Yes 3. Will the results of PODIUM and its users produce UIs that are improvements over what would exist without PODIUM? Yes - when asked whether the final version was easier to use than the initial version, users preferred their final version. Users also preferred their final version to the generic version. Questions 1. Would this type of UIMS work for communities that did not have specific subgroups? If so, how? 2. Should PODIUM always default to the initial UI or should it at some point default to incorporate the changes that have been added per specialty? 3. How do you avoid the inevitable problem of physicians needing to access information from other specialties?