Automatically generating personalized user interfaces with Supple
Fig. 5. This simple FTP Client UI illustrates the Action type in Supple’s functional specification.Fig. 6
Download 5.78 Mb. View original pdf
|
| Fig. 5. This simple FTP Client UI illustrates the Action type in Supple’s functional specification. Fig. 6. Presentation of a list widget and a checkbox widget for different values of (left) the minimum target size s t , and (right) the minimum visual cue size s c parameters. type is used to invoke an application’s methods. For example, the Login button in the FTP Client Login interface (Fig. a) is represented as an action. Its parameter is a container holding the User, Password, and Host elements, while its output is the container type describing the FTP Client interface (Fig. b, which appears after the successful execution of a login action. The parameters and the return type of an action type can be null if the action has no parameters or causes no new interface elements to be created. For example, the New action in the Email client (Fig. a) has null parameter type, and the Search action in the Amazon Web Services client (Fig. a) has null return type because it only alters the contents of the existing Search Results part of the existing interface. 3.2. Device capabilities and constraints ( D) We model a display-based device as a tuple: D ≡ W , C D where W is the set of available user interface widgets on that device and C D denotes a set of device-specific constraints. Widgets are objects that can turn elements from the functional specification into components of a rendered interface. There are two disjoint classes of widgets: W = W p ∪ W c . Those in W p can render primitive types, and those in W c are containers providing aggregation capabilities (i.e. layout panels, tab panes, etc.). Like the interface constraints, the device-specific constraints in C D are simply functions that map a full or partial set of element-widget assignments to either true or false. For example, a constraint is used to check whether the interface exceeds the available screen size. Common widget toolkits are often a poor fit for unusual interactions (e.g., trying to control a mouse cursor with a laser pointer) or abilities (e.g., for people with impaired dexterity or low vision. To accommodate such unusual interactions and abilities, we extended one standard widget toolkit in two ways by adding new widgets and by parametrizing each widget with two continuous parameters, the minimum target size, s t , and the minimum visual cue size, s c . The minimum target size parameter—used only on devices that support D pointer control—constrains the minimum size of any widget component that can be controlled with a pointer. Examples include a button, a list element, or a slider, as illustrated in the left pane of Fig. 6. The minimum visual cue size constrains the size of important visual cues, such as fonts and icons (the right pane of Fig. 6). 918 K.Z. Gajos et al. / Artificial Intelligence 174 (2010) 910–950 Download 5.78 Mb. Share with your friends:
|