Consistency sounds like something to strive for. After all, who would strive for inconsistency? Consistency is widely praised in guidelines and principles, but with some scrutiny, it becomes clear that consistency is hard to define and measure. Oellogg discusses several dimensions of consistency (including platform/devices) [kellT7, kellTU] and both Oellogg and Grudin [grudTU] note that a design can be internally consistent within an application, or externally consistent with other applications. Grudin sums it up well by noting: ZThus, there may be no simple approach to determining the relative significance of consistency along various dimensions and levels.Z (p.1172) Caulton and Dye [caulU7] concluded that consistency between applications is less important that task-appropriateness when applications are specialized. Although consistency may be hard to design for and measure, problems of consistency may be easier. Reisner [reisT7, reisU0] attempts to formally describe inconsistency to predict where users will have problems using a system. Grudin [grudTU] gives several informal examples where inconsistent design choices are more usable than consistent ones, and any designer can tell of cases where rules have been broken to address a specific user-task need. Given that, I will define Zunintentional inconsistencyZ as the situation where two parts of a design differ for no good reason. For example: different terms used for the same concept; different layouts on different displays; different functions available in equivalent contexts. All these are unintentional, mind you, and probably due to limitations in resources, tools, techniques, and so on. [browser Netscape4] © 2006 for the individual papers by the papers' authors. Copying permitted for private and scientific purposes. Re-publication of material on this page requires permission by the copyright owners.
I have been involved in several projects in which avoiding unintentional inconsistency was a primary motivation: SETOPT [perlT4a] generated manual entries and parsers for UNIX command line options, with the goal of using the same information for both. The techniques used in SETOPT were formalized in [perlT4b] and [perlTU]: templates for targets (devices, displays) were instantiated with values of several variables. A change of a template resulted in global (consistent) changes; a change in variable would result in changes wherever the variable was used. Even without templates, using rules for display, objects could be rendered automatically to create displays [perlT7]. More recently, the techniques have been applied to the design of FirstSearch, an online research service [perl00, perl02]. The system architecture - created with the primary goal of being able to change the design with inevitable changes in requirements - separates semi-structured [perlU3] information into functional, display, and language partitions. Structured information is inserted into templates that dynamically generate displays in multiple languages, for multiple platforms, for multiple user types with individual preferences.
The technique is flexible. New translations of the service have been added by translating about U000 partitioned words and phrases into Arabic, Chinese (2 dialects), French, Japanese, Oorean, and Spanish, generally with no changes to the display or functionality. Even within English, the partitioning helps promote consistency in language usage. By adding new templates for larger displays, new platforms have been accommodated in a few hours of work including Web TV and the character-based Lynx browser. By adapting the main template and its components, most Section 40T accessibility requirements were met, leaving remaining requirements to changes to functional areas. Minor limitations of some devices have been accommodated with minimal specifications, for example: early Netscape browsers could not display Greek entities like ialpha;, so they could be shown as text (alpha) instead of a symbol (_): alpha alpha beta beta ... omega omega
More substantial display limitations are accommodated with conditional display of functional components; all attributes of objects are available during display generation.
Along with the partitioning of structured information comes the ability for metrics on that information. Metrics have been used to avoid unintended inconsistency. A simple example is to measure, for each term (e.g., Search), how many times it appears in values compared to how many times a reference to it appears. A more sophisticated example involves checking device-specific templates to ensure that they contain the same references to parts to include; this has been used during facelifts to the user interface.
Some software development techniques are especially well suited to ensuring consistency in user interfaces, even while allowing flexibility in the efficient specification of inconsistency where the designer intends it. I do not think that cross-platform development presents any different challenges than, say, customizing for different types of users. What is not clear to me are the types of changes that are necessitated by cross-platform development compared to other dimensions of change. Being able to anticipate those would help estimate and allocate resources.
The format used to the references in this essay are intentionally inconsistent with ACM style. [caulU7] Caulton, David A. and Dye, Oen. Do Users Always Benefit When User Interfaces Are Consistent? Proceedings of the HCIlU7 Conference on People and Computers XII, 47-66, 1UU7. [grudTU] Grudin, Jonathan. The Case Against User Interface Consistency. Communications of the ACM, 32:10, 1164-1173, 1UTU. [kellT7] Oellogg, Wendy A. Conceptual Consistency in the User Interface: Effects on User Performance. Proceedings of IFIP INTERACTlT7: Human-Computer Interaction, 3TU-3U4, 1UT7. [kellTU] Oellogg, Wendy A. The Dimensions of Consistency, in [nielTU]. [nielTU] Nielsen, Jakob (Editor). Coordinating User Interfaces for Consistency. New mork: Academic Press, 1UTU.
[perlT4s] Perlman, Gary. SETOPT: A UNIX Command Line Options Parser Generator. Proceedings of the Winter USENIX Conference, p.160-164, 1UT4. [perlT7] Perlman, Gary. An Axiomatic Model of Information Presentation. Proceedings of the Human Factors Society 31st Annual Meeting, 122U-1233, 1UT7.