Charles Wiecha

Generating highly interactive user interfaces

Developers of User Interface Management Systems (UIMS) have demonstrated that separating the application from its user interface supports device independence and customization. Interfaces produced in UIMS are typically crafted by designers expert in human factors and graphic arts. Little attention has been paid, however, to capturing the knowledge of such experts so that interfaces might be automatically generated by the application of style rules to additional applications. This paper considers how toolkits and style rules can be structured so that the resulting interfaces take advantage of the best human factors and graphic arts knowledge, and are consistently styled.

Generating user interfaces: principles and use of it style rules

As application developers today we all face a problem of great complexity. Because of the diversity of our users, and the variety of their equipment, applications must run in many different configurations. They must support displays of varying size, resolution, and color depth. Different types of input devices are required, from keyboards to touch screens. Applications must run in different countries, being able to reformat messages in varying lengths in each language. Messages should be available in large font sizes for vision impaired users. Interface style should be consistent with other applications running on similar hardware. Style should at the same time conform to guidelines being developed by many organizations for presentation and interaction behaviors.

Transformations on a dialog tree: rule-based maping of content to style

Over the past ten years a broad consensus has developed that decomposing applications into separate computational and interface modules is desirable. The motivations for modularity in user interfaces are similar to those elsewhere in computer science, and center around the benefits of hiding internal implementations from other modules in a system. Modularity allows reuse of each component with compatible versions of the other components, and allows separate development processes for each component. In user interfaces, modularity allows the reuse of applications with different interfaces, perhaps for different user classes, window systems, or devices. Modularity also allows application and interface experts, including human factors engineers and graphic designers, to cooperate while minimizing the coordination required among them.

A REST protocol and composite format for interactive web documents

Documents allow end-users to encapsulate information related to a collaborative business process into a package that can be saved, emailed, digitally signed, and used as the basis of interaction in an activity or an ad hoc workflow. While documents are used incidentally today in web applications, for example in HTML presentations of content stored otherwise in back-end systems, they are not yet the central artifact for developers of dynamic, data intensive web applications. This paper unifies the storage and management of the various artifacts of web applications into an Interactive Web Document (IWD). Data content, presentation, behavior, attachments, and digital signatures collected throughout the business process are unified into a single composite web resource. We describe a REST-based protocol for interacting with IWDs and a standards-based approach to packaging their multiple constituent artifacts into IWD archives based on the Open Document Format standard.

Case study: using ITS style tools to implement IBM's CUA-2 user interface style

In an empirical case study of software tools, two participants used the ITS style designers language to implement a general purpose, executable, rule‐based user interface style. This language allows style designers to select, combine and modify rule prototypes in order to construct a rule‐based user interface style. The participants implemented the entire IBM CUA‐2 user interface style, plus nine additional human‐computer interaction techniques, in 5–7 person‐weeks. This is impressive productivity. Typically the time to complete a single CUA‐2 application is measured in person‐years, not person‐weeks. The style implemented here is reusable by any ITS‐implemented application. The achievement reported here shows that about half the work of all ITS‐implemented CUA‐2 applications has been completed in a few person‐weeks. This result demonstrates the power and productivity of the ITS approach and tools. The results of this case study showed that key ‘ready‐mades’ (e.g. named attribute groups) provided in the style designers toolkit could be used intact, which is important for importing or exporting interaction techniques from one style to another style. The results generalize to other computer‐literate designers who may want to use these tools to create other user interface styles.

Interactive Web Documents

Documents allow end-users to encapsulate information related to a collaborative business process into a package that can be saved, emailed, digitally signed, and used as the basis for interaction in an activity or an ad hoc workflow. While documents are used incidentally today in web applications, for example in HTML presentations of content stored otherwise in back-end systems, they are not yet the central artifact for developers of dynamic, data intensive web applications. This paper unifies the storage and management of the various artifacts of web applications into an Interactive Web Document (IWD). Data, presentation, behavior, attachments, and digital signatures collected throughout the business process are unified into a single composite web resource. We describe a standards-based approach to packaging multiple resources into IWD archives based on the Open Document Format, a REST-based protocol for interacting with IWDs, and an extensible interaction controller architecture.

ITS and user interface consistency: a response to Grudin

In his letter Grudin asks “Where do we get the false impression that every good design must somehow be ‘consistent’?” It has never been our intention in developing ITS to force a conformance to superficial consistency. On the contrary, our primary achievement has been to provide a tool to develop excellent interfaces by iteration through successive prototypes, each of which is subject to use, testing, and revision. By capturing the results of these evaluations in executable style rules we have provided a tool for developers to benefit by reusing the interaction techniques developed by ourselves and others. Below, I first answer a number of the detailed comments Grudin makes about ITS. Since I believe many of his comments are based on an inappropriate attribution of a stereotypical notion of consistency to ITS, I then briefly outline the sense in which we use the term consistency. This interpretation allows us to separate concerns about adherence to a style from concerns about the quality or usability of that style. Let’s begin with Grudin’s assertion that we “argue for establishing a set of design rules to cover all allowable interaction techniques and then prohibiting exceptions. ” The section he refers to, on page 233, is titled “Feedback into improved rules. ” Its focus is not on prohibiting exceptions to rules, but exactly the opposite: how to capture the rationale behind new rules so that they can be incorporated into existing styles, again for the benefit of future developers and users. The section argues that to make such exceptions in an ad hoc manner, and not to feed them back into improved rules, “would miss an opportunity to add the missing knowledge. No one else would benefit from our work.’’(p. 233)

Direct manipulation of programming: How should we design interfaces?

ion. There is a strong tendency to apply these notions to any problem area that we tackle, even if they are not appropriate. Our programming notations tend to be linear in nature, there is one thread of control through the entire program. In user interfaces there are typically multiple threads of control. This is very hard to describe in a textual notation. Many claims have been made for the textual description of user interfaces. Textual notations are more powerful than the existing graphical notations (a general programming language can do anything that is computable). There are user interfaces that can be described by programs that cannot be produced by existing graphical techniques. But, do we need this generality, and will it be effectively used? The problem with using programming languages is that vast amounts of code must be written in order to produce the user interface. Thousands of lines of code may be required to produce a user interface that could be constructed in 30 minutes with a graphical tool. Recently rule based techniques have been proposed as a way of designing user interfaces. These techniques can be characterized as a textual description with a high level of abstraction. This is a very nice approach (otherwise 1 wouldn’t be using it), since it allows us to capture some of the expertise of good designers. We can develop rules for the selection of interaction techniques, details of their graphicalion. This is a very nice approach (otherwise 1 wouldn’t be using it), since it allows us to capture some of the expertise of good designers. We can develop rules for the selection of interaction techniques, details of their graphical presentation (fonts and line styles, for example), and their placement on the screen. This removes control from the user interface designer, since he or she has no control over the rules that fire in the design of the user interface. It could be argued that the designer could edit the rule base in order to have some control over the design process, but this is not a viable solution. A realistic rule base will have a large number of rules (thousands?) and there will be subtle interactions between these rules. As a result., it may be very difficult to modify the rule base without introducing undesirable side

Collage: A Declarative Programming Model for Compositional Development of Web Applications

Collage is a declarative programming model and runtime expressly targeted at building and deploying cross-organizational software as compositions of web components. Collage is based on an RDF data model, data-driven execution model, and flexible support for cross-organizational composition of both application and UI components. In this paper we outline a uniform set of Collage language features addressing end-to-end application design, including business objects, but with particular focus on user interaction, and adaptation to current interaction platforms such as web browsers.

WSXL: A Web Services Language for Integrating End-User Experience

WSXL (Web Services Experience Language) is a web services centric component model for interactive web applications. WSXL is designed to achieve two main goals: enable businesses to distribute web applications through multiple revenue channels, and enable new services or applications to be created by leveraging existing applications across the Web. To accomplish these goals, WSXL components can be built out of three basic web service types for data, presentation, and control, the last of which is used to “wire together” the others using declarative language based on XLink and XML Events. WSXL also introduces a new description language for adapting services to new distribution channels. WSXL is built on widely accepted established and emerging open standards, and is designed to be independent of execution platform, browser, and presentation markup.