Corporate identity is often represented by a similarity of appearance of documents, products, images, etc. Typically, such similarity is based on style rules which are applied to corporate artifacts. Often these rules are complex and interrelated. This can cause difficulties for a designer who is trying to determine their applicability. This is especially the case for conditional rules which may only be relevant in certain circumstances. Consider a rule that states that, for WWW pages, the name of the institution must appear immediately below the institution logo unless the institution name appears in the page title. It is quite likely that a user may forget the conditionality of the rule, especially if the institution name appears in the title as a result of a late modification, after the rest of the page has been designed.
Sometimes we apply the term 'style' to system properties which are more abstract than either text properties or corporate logos. In Macintosh(TM) applications, the File and View menus appear in the same relative position in the menu bar, possess a subset of choices which are always present, and associate these choices with similar functions in each application. Sometimes this style of menu representation is violated, usually resulting in disorientation of experienced users. A trivial example is the puzzle application found on early Macintosh computers. The Clear option in the Edit menu for this puzzle causes the puzzle pieces to toggle between a pictorial and a numeric representation, which is not the conventional semantics of the clear option as found in most other applications. Consistency, in the sense of maintaining the command name semantics of the Macintosh menu style, would have prevented this problem.
Each of these three examples, widely different though they are, capture
ordinary uses of the notion of style. In this paper we will argue that they all
represent variations of a single concept, a concept which is central to the
process of design. We will present a general theory of style which explicates
the advantages of the use of style, such as in our examples above, and we will
suggest ways in which a proper understanding of style may lead to better
assistance to the designers and users of interactive systems.
We propose that style is any set of decisions or constraints fixed before a
particular stage of the design process, e.g., dictated to a designer as part of
her brief. Furthermore, a family of designs sharing the same set of constraints
are likely to look similar to observers - styles are often recognisable. We
argue that there is such a common property, that it is relevant, indeed
central, to design, and that it may be used as the basis for a representation
of style in computerised design support tools.
Design has both a search space and a sequence, or at least a partial time ordering, of decisions. Design methods and interactive system architectures both have features intended to enforce or allow for the separability of design and specification decisions, but there are actually two aspects of this. One is being able to take decisions independently in any order; the other is being able to take later ones with no backtracking i.e., no interaction or repercussion on ones already taken.
Traditional top down design methods in computing are only viable if in fact there is an order that allows the latter: taking decisions with no backtracking; and that this order is from top to bottom, from high level specifications to low-level code. This actually seems plausible because or when a) programming is seen as converting functional specs to code b) computers are Turing equivalent, so there will always be an implementation of any function or component function found in the specification or derived during design.
However in real life, whether in commercial programming or in undergraduate Pascal exercises, the actual specification (i.e., including the implicit specifications as well as the written ones) almost always includes non-functional requirements. Principal among these is a specified machine, language, and often support software (e.g., the X window system and its widget toolkits). This latter type of specification means that most design is not building out from a single fixed point at the top (the function to be computed) but from two fixed points -- the function and the implementation platform (top and bottom). In general there may be any number of fixed points, as becomes clear in cases where re-use of code is emphasised and programming is explicitly a matter of glueing together old code for new uses, e.g., using Rexx.
Reflecting on this draws attention to the temporal dimension in design. Some
decisions are taken early on, e.g., in the requirements, and may not then be
changed (more accurately, the costs of changing them are hugely greater than
for changing other decisions). A given designer, then, is usually operating
with what for her are fixed points that have been decided earlier. Even within
an individual's design activity, there may be a more or less full ordering of
decisions: top down methodologies imply a full ordering, while successes at
separation, e.g., in UIMS and CAL authoring, allow a substantial degree of
parallelism or independence in decision making (e.g., in deciding separately on
screen appearance and on underlying functionality).
Designs produced with the same style often have a family resemblance - they "look" or "feel" the same to people. They are recognisable. They have something in common that other designs, from a wider design space, do not have. This recognisability decouples style identification from a knowledge of its development history or its design-oriented justification. Styles not only serve designers, but their recognisability can also be used by users; this identifiability gives users cues as to the meaning or expected behaviour of artefacts which exhibit a style they know.
A style apparently cannot be defined without tacit contrast set(s): a larger set of alternatives of which it is one, from which it is chosen. But how then can we recognise a style bottom up? Only because, or when, we have seen other solutions to the same larger design space. It is of course possible to be familiar with a style, but not be aware of it as a style until one sees a contrasting example. For instance, pie menus are called 'pie menus' while vertical menus are just 'menus' and tiled windows are called 'tiled windows' while overlapping windows are just 'windows'.
The term 'style' as used here is neutral with respect to the particular type of
design space structuring which it provides. That is, it may refer to choices
which flow from a coherent principle or principles, like metaphorical
representation, or it may refer to choices which are simply related due to
common practice or convention, like visual style for menu items.
Furthermore, concentrating on the relationship between design rationale and style obscures the other ways in which the concept of style influences design. Menus are devices for making choices from a set of items, just those where the choices are presented to user at the time the choice is to be made. Central questions then become: (i) how the choices are presented, and (ii) how the choice is made. Peripheral, though still important, are decisions about the length of time to display the choices, how to indicate selection, how to handle nested structures of choices. Equally, we may identify the "near neighbours" of menus: command languages, data-entry forms and scrollable lists but not video sequences or icon images. Scroll bars and editable text fields perhaps lie somewhere between forms and images in their relation to menus. The important point here is that the concept of a menu adds a structure onto the features of a design, a structure which partially orders those features with respect to potential design decisions. Such structuring, which may be captured via style definitions, need not include the reasons for the decisions. Although important for software engineering reasons, the justification is separate from, or rather exists on top of, the structures offered by styles.
The grouping of choices as a style coexists with, but is distinct from, design reasoning. The work of justifying the set of choices may be carried out independently of the rest of the design and indeed, prior to the particular design enterprise. Style guides and uses of style in guidelines capture this pre-justification by giving conditions in which the selection of a style is appropriate; the justification is often absent and assumed (or its existence flagged by references to relevant studies). In fact, the absence of facilities to incorporate styles by grouping named, and perhaps parameterised, design rationales for selected sets of choices is a notable failing of current work on design rationale notations.
We thus reject Newman's assertion. Design rationales relate to one important
part of design reasoning, but "styles" refer to a distinct and broader class of
structures that are important in design independently of whether their
justification is recorded and used.
Since changing a style is done much less often than other design decisions, it
can be harder work. On the other hand since, as argued earlier, a given human
designer may well have some time-ordering constraints on their design work; in
this case a given individual may design a style and then work with it as part
of a project. Thus the interface to design specification must be usable by the
designers / programmers, not only by special experts.
The class structure among widgets reflects an inheritance hierarchy and does not correspond, except by chance, to any other categorisation of interaction objects according to style or use. For example, MenuShell and ScrollingList, two of the widget classes in the Open Look(TM) widget set which support selection (a characterisation in terms of rationale) do not have a common parent class; their common class ancestor is the Composite widget class. Thus, the fact that they are both instances of a style of selection device is not reflected in the hierarchy.
Second, the widget's parameter space is entirely flat. There is nothing to indicate that setting one parameter is more or less important, from a design point of view, than another. As a convenience, most widget parameters have a default setting, so that a designer may safely ignore most of a widget's parameters. But which ones? There is no differentiation among the parameters to help.
The resource mechanism provided by X and similar window systems (Davison et al
1992) enables the values of some attributes of a widget to be determined,
leaving other attributes to be set by default or by other resource
specifications. Other systems take a similar approach to style, like HUMANOID's
templates (Szekely et al 1992). Thus, styles which can be expressed as default
parameter values to widgets are supported, but others are not, e.g.,
metaphorical styles and many aspects of house styles designed for usability.
Also missing is any way of representing differences in degree of fixedness of
choices.
Two types of fixed design decision can be identified in these systems. First, the conceptual model constitutes a set of fixed choices and, in terms of our definition of style, forms a style. This seems reasonable, since systems belong to recognisable categories with respect to the objects and operations which make up their conceptual model. However, this suffers from the problem identified in section 3.1, viz., that decisions about the conceptualisation of the application are fixed before, and independently of, decisions about the user interface's appearance and behaviour. This does not take into account the way decisions about the hardware/system software/ basic interaction style may restrict choices about the application's conceptual structure.
Second, the rules by which the user interface are generated are a fixed set of
design choices, albeit ones (usually) without alternatives. This approach has
been demonstrated to produce acceptable results when applied to limited domains
of design choices, but its assistance fades as the range of design choices
increases in scope; it is unlikely that, given current models of application,
interface and style, the same technique will work for more sophisticated styles
and application domains, such as metaphorical representation of a wide range of
types of data and input techniques. Furthermore, the rule-based approach has so
far focused solely on the generation of presentations based on the
specification of the application and has ignored other types, such as
"corporate" style.
The solution which we propose to the problem of style-based support for design is to model design-time constraints on interface specifications: this is information about design significant properties which fixes the choices which a designer may make, and indeed sometimes forces additional design decisions to be made. The role of such constraints is to impose a structure, or indeed a variety of structures, on the various attributes which make up the interaction object's definition, ordering them with respect to the design considerations in terms of which the interaction object properties are specified. Facilities can then be included in design tools for defining and resolving these constraints.
Consider the Macintosh Finder icon discussed earlier. Design-time constraints one might place on such an object include:
Additionally, one may wish to include annotations to the constraints, such as
the rationale for them. The constraint that the image be representational might
include an annotation asserting that this property enables inferences about the
type of the underlying object to be drawn from the nature of the
image.
A corporate house style might be based on the incorporation of some features of
the company's logo in the artefact being designed (Mahony & Gower 1991).
Which features may depend upon a number of other design considerations. What is
important here is to include a constraint on the properties of the object such
that they satisfy the logo incorporation requirement. The means of doing so is
not part of the constraint. It may be satisfied, perhaps, by using company
colours, or by including the logo in the widget's area, or by including the
logo in a component part of the object. Such a constraint is likely to be
satisfiable only as the result of the activity of designers trying out
alternatives, comparing them for adequacy against a variety of criteria and,
finally, asserting a solution by including its specification in the design. In
cases of this sort, the relationship of design rationale to style application
becomes central.
Finally, as illustrated in the corporate logo example, some design constraints may force the designer to assert that certain design conditions or requirements are met. A central feature of these design constraints is that their satisfaction may require the intervention of a human designer. We cannot assume that (i) we can produce a constraint satisfaction engine sufficiently sophisticated to resolve constraints without such intervention and (ii) we can represent the knowledge to resolve the constraints in a design knowledge base. More importantly, the resolution of the constraints may be essentially unresolvable until a designer decision is taken, perhaps as the result of further reasoning or empirical investigation.
As the previous section suggested, sets of design-time constraints may be
definitive of a set of solutions to a design problem. Thus, the notion of a map
defines a class of solutions to the problem of displaying multi-dimensional
data. A corporate "style" is a family of solutions to the problem of making
artefacts identifiable as representing an institution. A representational or
interaction object may satisfy more than one set of constraints at the same
time and thus may belong to more than style.
This may appear an unlikely method of modelling style in a user interface
design tool. However, if we conceive of a style as placing restrictions upon
the degree of freedom which with certain features of a specification may be
modified interactively by a designer, then the concept of a constraint appears
more appropriate. A style, then, consists of a set of relationships, each a
tuple of system property and conditions on that property, perhaps modified by a
degree of fixedness (here represented by 'must' or 'should', cf. "glue" in
Knuth's TEX box and glue model). In the Macintosh icon example, its style
consists of:
Determining if the sixth constraint is satisfied is more difficult. First, the constraint specifies a "should have" relationship between the attribute and its value. Second, it may be impossible, in the absence of a knowledge-base which holds information about the representational properties of images, for the system to tell if a given image is representative of a given file object type. Thus, the satisfaction of this constraint may well require input from a designer in the form of an assertion that the constraint has or has not been satisfied. This forces the designer to consider whether other factors influencing the design make necessary the inclusion of pictorial representation of type. The purpose of the constraint is to guarantee that the decision is made.
Constraint satisfaction occurs at different points in the process of specification. Thus, the constraint on representation type (i.e., element of a collection) will require satisfaction when an attempt is made to change the type of the representation, typically by restricting the choices available to the designer. The constraint on the label attribute of iconic elements must be satisfied when an instance of the specification is linked to a source domain and the name of source domain entities is mapped onto iconic elements.
The degree of fixedness of a style is modelled in the notion of style
application permissions. When a designer applies a style to a specification,
she may state whether that style may be removed from the specification or
relaxed (temporarily made inactive). Styles which can be neither removed nor
relaxed constitute the "givens" of a design, beyond the control of the designer
to modify, perhaps because of project requirements which cannot be negotiated.
Relaxable constraints represent those which are a central feature of the
design, but may be "traded off" against other features. Removable constraints
are those which are part of the current design hypothesis, available for
retraction if evaluation shows they are not desirable.
As demonstrated earlier, one specification may exhibit, or possess, a number of
different styles. If styles were structured in a single hierarchy, this would
result in redundant constraints being applied. The constraint satisfaction
mechanism must be able to remove such redundancies. More seriously, it is
possible that inconsistent or mutually unsatisfiable constraints be applied to
a specification. The constraint satisfaction mechanism must be able to handle
such cases. Alternative techniques include disallowing more than one constraint
applicable to the same attribute for the same relationship type (pre-emptive)
or determining constraint conflicts and asking the designer to "relax"
constraints until satisfaction is possible (interactive).
There are three types of style-oriented assistance which can be offered by a computer based tool:
These requirements suggest significant limitations in what is currently available. Current facilities mainly revolve around what is easy to implement (e.g., word processor styles) or fixed UIDE architectures (e.g., X widgets) or support for design justifications. They do not, we have argued, correspond to the decisions designers actually have to fix, and therefore wish to record, at the early stage corresponding to designing a "style." However, by drawing on the mechanisms for constraint resolution including prompting the designer through structured judgements where these cannot be automated, a much more advanced facility could be implemented.
Such a design tool must benefit the designer by allowing and supporting a
better ordering of design decisions that corresponds more nearly to the order
of fixedness of decisions given the requirements, however heterogeneous those
decisions are. Benefits to the end user will be limited inevitably by our
understanding of what really matters to users. Styles for designers correspond
to consistency for users; both refer to the issue of similarity across
different designs, but not all similarities turn out to benefit user
performance. While the work on Task Action Grammar (Payne & Green 1986) has
demonstrated some of the issues that matter to users, Grudin (1989) shows that
not all kinds of "consistency" do benefit users. However, as we learn more
about the relationship of consistency to user performance, we will have an even
greater need for tools such as we propose with which designers can directly and
re-usably express these as constraints on design.