third chapter how to do it

There is no recipe for carrying out the process of design. The design process involves tradeoffs, conflicts, and objectives that can differ and can be influenced by both the application and the user community. This means that it always is somewhat of a creative and artful process. The best way to learn is by collaborative apprenticeship. That is, to actually design along with others, and for the participants to compare each other's work under the guidance of someone who has experience and knowledge in the area.

In this chapter, we will describe the specific key elements to be considered in a design. There might be a best order of consideration for these elements when evaluating a design; however, in the actual design process, the definition of these elements will actually cause the designer to go back through the process and make changes to earlier parts of his/her design. There is no single correct cognitive sequence for the problem solving process of design. The process is both iterative and recursive in nature.

In the beginning of this chapter we will take a specific example and explain how a designer might actually go through the mental process of creating the elements of the design. Surprisingly, we are not going to concern ourselves, in this first part of the design process, with how anything looks on the screen of an interactive system. This simpler part of the problem will be considered in more detail later. The most difficult part of the design process is deciding on the functionality and capabilities required of the system and how these will be structured.

Example

Our goal is to design a "recipe system" to be used by a person on a personal computer. This might seem easy because everyone should understand the ideas and concepts involved in dealing with recipes and the task of cooking. We do not have to educate users on what a recipe is. Interestingly, there are many highly developed and very convenient methods that humans have evolved in the non-computer environment to deal with recipes. There is a large host of cookbooks the average person can choose from and utilize. Many people who cook will have an index box with index cards upon which they write down recipes or tape recipes they cut out of a magazine or other source. Others keep binders full of recipes they’ve collected.

A recipe system on a personal computer has to offer the user some advantages and conveniences that exceed the flexibility provided by this combination of books, index card files, scissors, pencils, erasers, glue, copy machines, scotch tape, etc. Providing the same tool versatility on a computer is not easy to do and serves to set a real design challenge. Clearly, no one will use the computer version unless it offers significantly more benefits than these other mechanisms for handling recipes. Furthermore, the user effort needed to learn and take advantage of these benefits cannot exceed some acceptable level.

We will develop this design following the designer's mental process, as if we were conducing a Protocol Analysis (see chapter 4) on the designer's mental process. The designer will be verbalizing his or her thoughts as he or she conceptualizes the design.

Setting the Objectives

Before the actual design begins, some initial idea of what the objectives are must be known. It would seem that the following is in order:

The user should be able to handle thousands of recipes.
The system should provide ways of organizing the information that is superior to that provided by books and index card files.
We need to identify useful functionality that is easier to take advantage of on the computer.
We need to insure that individuals can learn to use this system very easily and be able to accomplish frequently occurring operations with a minimum of effort.
The user should be able to place his/her hard copy recipes onto the computer.

Designers thoughts on the objectives:

The ability of the computer to go beyond the fixed table of contents or index that is in a standard cookbook is one of the basic areas I have to look at. Anything that allows the users easier manipulation of the information needs to be considered. Clearly I have the advantage of the large memory capacity of the computer system, but how can I utilize the processing capabilities to dynamically restructure the data in new ways?

Another important aspect of setting the objectives is the characterization of the potential user population. In this case I am aiming at the person who takes cooking seriously and likes to collect and use recipes. We will be excluding professional cooks and restaurants from this first version of the system. We might also be catering to individuals that have special needs such as being on a diet or having certain food constraints. Maybe I will need to allow the user to establish a personal profile in the system. This population also includes individuals who wish to learn more about cooking. This means I really should add another objective.

The system should provide facilities for the user to be able to learn more about cooking.

That probably means I have to provide help on the application as well as the mechanics of the interface.

Developing the Pieces

First, how do I want the whole system to appear to the user? Do I wish to make it appear as a book or card file system? No, that might place some limits on the way the user thinks about the system and makes it difficult for the user to recognize some new and unique capabilities. At least I will put that issue off until I get further into the design. I will have to think of a good catchy name for the system as that is always critical. The concept of recipes is so well understood that maybe I don't need a more general metaphor. The concept of a recipe will already trigger many familiar concepts in the mind of the user and I can take advantage of this fact.

If I use a book as a metaphor, the user will expect the system to behave like a book. This might limit some of the new capabilities I wish to make the user understand. The same holds true with index cards. Maybe I can come up with something wild like a supermarket where the results of picking the food you wish are the recipes you can use them in. I will leave this issue for later. The thing I do have to specify initially is the objects that are going to make up the system and the data types that these objects contain.

Objects and their Parts

It is obvious that one of the objects I need is a "recipe." This will be the principal object the user will be concerned with. Obviously, this should have the following parts:

A "title"
A list of "ingredients" and the "amount" of each.
A set of "instructions" for the cooking process.

Now how can I improve on the above? I forgot the number of servings, (ureka!) I can allow the user to change the number of servings and have the system automatically calculate the amount of the ingredients needed. Hmm! That does raise a number of other possibilities. Perhaps the user is interested in the nutritional value of the recipe. Certainly there are measures for that (e.g., carbohydrates, fat, etc.). However, this might be very difficult to obtain for most recipes; therefore, what I need to allow is some set of qualitative classifications such as "low fat." I should talk to a nutritional expert or crack some books on this subject. I will mark this topic to be explored: "A set of classifications to use as a coding scheme for recipes with respect to nutritional types." Even if I come up with a reasonable default coding scheme, I should probably allow the user to modify or add to it. Hmm, if I had a database of ingredients I could keep nutritional information for any ingredient and have the computer estimate it for any recipe!

It occurs to me that when a user wants to "modify" a recipe I can present the parts of the recipe and let them designate what part of the recipe he or she wish to make changes to. I will have to be careful in the creation process and in the display process to cue the user about the parts of the recipe so that he or she learns them intuitively. The presentation format I adopt will have to be very clear as to what are the "natural" parts of the recipe.

Now it is becoming clear that the title of the recipe may not be unique. Certainly there can be several recipes for "apple pie," and different nutritional versions of the same basic recipe. Therefore, I will need to have the computer assign a unique id to each recipe that is entered into the system. Lets mark this one also for further consideration. If I assign the ids as the recipes are created, and I use numeric coding, there will be a match of numeric ordering with the creation. Or, do I want to come up with some sort of easier to remember id (e.g., the first letters of each word in the title followed by numeric qualifier starting from 1 on up). Right now I am leaning to the latter.

The recipes need to be classified in some ways. Recipe books usually have a table of contents based upon such things as desserts, soups, meat dishes, etc. I may have to provide some major familiar categories, but I think I will do this as a virtual table of contents out of a general purpose index. The more I think about it, there seems to be an almost unlimited range of different classifications people might be interested in with respect to recipes. There are ethnic and country based recipes. There are also holiday and religious recipes! Clearly, I have to provide the user a general approach to tailoring the index to his or her own preferences. That means the "index" has to be an object that the user can modify and tailor. The system will start up with some default entries and give the appearance of a table of contents. As the user masters the system he or she will discover the ability to tailor it.

We now have two major objects, the recipe and the index. Are there others as well? How do people utilize recipes? Well, come to think of it, recipes are part of a meal and a meal can be made up of many different recipes. I think I have another major object and I will call it a "menu." Maybe not, this might get confused with choice menus in the interface. I guess a "meal" is the best name for this object. This will allow people to store their favorite meal lists and be able to retrieve them. Meals would essentially be titled and indexed items with a list of the recipes they contain. I should provide some templates for different types of meals but also allow the user to create a unique meal structure. That does suggest some other useful things I can provide. For example, there could be a function to list all the ingredients and the amounts needed for the entire meal or for a set of meals. Then the cook can use it to plan their shopping list. Guess that has to be a general function for a set of meals and recipes. That means a process of marking things and collecting a marked list against which to apply such a function. I now have the "marked list" as another object the user can manipulate.

If I have a marked list, the user can use it for other things. The user could, for example, decide to "print" the list for a shopping trip. I will have to provide "reactive" functions to maintain the list, such as adding or removing items. For example, if our cook has an apple tree in his backyard, he won’t need to purchase apples for the pie. If I am careful, I can have the same set of functions apply to the general index as well as the marked list so the user does not have to learn two different interface approaches to deal with each list. Clearly this process of dealing with a list is a "shared process" in my design. I also have the "reactive" choices of marking and printing, as well as adding and removing items from lists. Do I need the merger and reordering of lists? I'll mull on that one for a while. How far can I go in providing the user a general "list processing" functionality?

I wonder, should I consider an inventory capability? Well, if I was doing this for a restaurant it might be a good addition, but I don't think a family would go to the effort of keeping their food inventory up to date on the computer. I will save that for the restaurant or "professional" version to design later! I will however provide that function for summarizing a list of ingredients and total amounts from a menu or the marked list as a potential "shopping list." I can even print it out in a form with the quantity needed and spaces to mark how much is already in the home and to check off each item as the shopping is done.

But that does bring up the question as to whether I should consider the list of all ingredients as a separate index from the general index. Either that, or I would have to create a multilevel index. Come to think about it, if I have an index of all ingredients, then I could have nutritional information on the ingredients and maybe from that be able to automatically infer some rating of the nutritional value of any recipe put in by the user. Maybe this is a feature for version two of this system. Will have to think about that some more. At this point I have a fairly good start on the objects, I had better try to work on the actions. I now have the following as potential objects:

Recipes
Meals
Key word index
Ingredients index
Marked list

That is certainly more than I initially thought and a sufficient starting point for the objects in the system. Can I have the marked list as part of the general index by allowing the user to just add the term "mark" to any item to any item anywhere in the system. Marking or unmarking becomes a reactive action. Logically, the internal general index can handle any sort of marking, key words, and/or ingredients, but it might be a little difficult to get across to the user as special features in a general index. Maybe I need to maintain the three facilities as distinct capabilities in the mind of the user. Clearly when it comes to searching I should treat the key word and the ingredient indexes as one index so the user does not have to worry which list certain things are on. That will be the default condition but the user will have the option to select only one of the indexes.

Actions, Functions, and Modifiers

It occurs to me that the "marked" list can be considered as a modifier to the basic set of recipes or meals. Do I need any other explicit subsets of objects or modifiers to create explicit object states? In message systems I can have a large variety (e.g., received, pending, urgent, etc.), but that does not appear to be the case here. However, now that I think of it perhaps the user wishes to establish recipes or meals he or she needs but does not yet have all the details. I think I should incorporate an "incomplete" state or modifier so that when one is creating the recipe or modifying it they can designate it as "incomplete" and be able to list incomplete items as a separate function. This will allow the user to include recipes they desire to obtain or further modify. I could also extend this to a list of "favorite" recipes or recipes that the user had tried (and liked or disliked).

Clearly the concept of marking can be viewed as a "modifier" capability which, for this application, I have extended to define a single object that is the collection of all marked items. I should think about allowing the ability to mark almost anything (e.g., an ingredient, a key, etc.) now that I have the marked list for the user to manipulate. Should I have an authored list so the user can gather those recipes that he or she has authored? Authored would then be another modifier. No, it would be better I think to have a source field that can be searched on. This would allow more flexibility.

Going back to "meals," I just realized that if the meal points to the recipes which are part of it, shouldn't I have the recipes pointing to the meals in which they are included. Clearly a user might like to call up a meal or meals that the recipe is part of when they are looking at the recipe. Therefore the meals which contain the recipes are part of the data presented with the recipe object. In addition, certain recipes have other dishes that go with them or represent alternative choices (e.g. a variety of sauces or stuffings). It seems as if I have a little "Hypertext" set of facilities here. I could have a flag (or icon) to designate that the recipe belongs to one or more meals and the user can trigger a list of those meals to decide at that point how to interact with the linked objects. The important thing is that I have links in both directions between meals and recipes and among recipes. It is very probable the user will wish to move in either direction when looking at one of these object types.

Hmmm! Sometimes recipes point to other recipes (e.g., using some sauce that is also a recipe). This is another "lateral classification" that I need. Yes, I think I need the backward pointers so a user can ask which recipes utilize this one. So I now have two types of explicit linkages besides the implicit ones such as ingredients. Maybe an ingredient is more than just a name. It could contain some descriptive material about the ingredient including some of the nutritional data I was considering before. That would probably be the way to handle a powerful nutritional analysis capability. Really sounds like something I will leave for version "2" of this system! This would be the "expert" system version to quote the current jargon in the industry. Also the ingredient descriptions should provide some information on possible substitutions.

It should not be surprising that Hypertext always seems to be a natural part of any user oriented system. Maybe Hypertext is a general concept of trying to determine what are the meaningful linkages to the user between the objects in the application. In fact, it seems that any application, past or present, has always had Hypertext in it whether it was called that or not. It is a rather basic capability:

What are the lateral linkages between objects in a user application that are part of his or her mental model of the application and/or tasks that make it up?

Now that I think of it, the recipe is a natural object for specifying a large number of relationships that express both lateral linkages and dynamic changes. I guess the recipe is an ideal "natural menu" or an application "metaphor menu". The ones I have thought of so are:

Meals linking to the recipes they specify
Recipes linking to the meals they specify
An ingredient that is itself a recipe
An ingredient linking to more detailed information about it.
The number of servings linking to a routine which allows me to change the number of servings and have those changes reflected in the amounts for the ingredients.
An ingredient linking to possible substitutions to use in the recipe.

Clearly some of these linkages are "one to many" which means when the person clicks on the item I need to provide a contextual menu of the different linkages to that item. So far ingredient has both the choices of "information" and "substitutions." Clearly this ability to click on specific items in the recipe is going to be helpful in accomplishing my objective of providing the ability for the user to learn more about cooking. Given the above thoughts it does cause me to think of some more linkages:

Linkages to added information about cooking methods and utensils.
Linkages to a glossary like more details on a particular cut of meat.
Any of the index keys in a recipe could allow the user to branch to a list of all other items indexed under that key that applies to ingredients so the user could ask for alternative recipes with that ingredient.
If it is a fatty recipe, the system could show what causes this classification.
Clicking on the title could produce a list of "similar" recipes or a menu to choose different forms of similarity (e.g., similar ingredients, nutritional value, taste).
Come to think of it, clicking on the title could also provide information on complement dishes for a complete meal and the choice of such things as alternative compatible wines.
Maybe clicking on the time to prepare a meal could give some indication of how to shorten it!

It seems that almost anything in the recipe could have some meaningful linkage attached to it. I bet I think of more of these before I am done.

Generic and Explicit Actions

Clearly for the principle objects that make up the system I need a set of "generic" commands or functions. Generic functions are those that can act on any object but may differ in what they do by the type of object they act on and the user interaction state. Let me take a first crack at listing what is needed:

GET: Get an object and display it on the screen. The form in which it will appear depends upon the user interaction state and the object type since this is a "generic" command. It might produce the short heading for the object or the full content of the object.

FIND: Trigger the appropriate search options for the particular object. The type of search most useful to the user will clearly depend on the interaction state.

CREATE: Establish a new instance of an object. This will differ by the type of object.

MODIFY: Modify an existing instance of an object. No matter what, there will always be a need to allow a user to modify whatever he or she has created.

DELETE: Remove an instance of an object from the system. This is one of those functions users typically avoid using until they run out of memory. I will have to find a way to make it easier for a user decide what can be deleted. Maybe I should keep a last accessed date on each recipe.

Clearly this is not a bad set of basic functions for any objects in any application. It is a pity so many applications use different terms for the same functions.

When the user gets an object, I have to allow any object of any reasonable size to have three different representations. First, if they are getting a set or list of objects, I should have a short version that allows the user to get the greatest number of objects displayed on a single screen or window. Then there is the "abstract" form that gives the user all the status information but not the full content. And finally, there is the full object with the content included as well as the abstract.

I will have to determine which places in the interaction to present which of these defaults as a result of the GET function. But, I will need to provide specific or "explicit" commands to allow the user to alter the format that is displayed or switch from one format to another. I think I will call these as follows:

LIST: To list the objects in the shortest form.

SCAN: To get the full abstract of each object.

VIEW: To view the full object.

Ideally I would not even need commands if I could provide some sort of "zoom" in and zoom out button or joystick. Clearly, moving between more details to less details is common to any type of information presentation. Now that I have some "explicit" commands to support the "generic" GET, I should examine the others. For FIND I could have a set of modifiers like "by_title," but I don't think I want to make it that complex for this application. I will try first a "form" to fill out that provides all the search qualifications a user might wish, and see if I can standardize that form. Then I can provide the appropriate pieces of that form in the various interaction states where the user might wish to do a search. This means that the FIND action will be both a "strategic" command and a "reactive" one at the same time. Strategic actions are major objectives and reactive actions are ones used in reacting to the current information on the screen. Furthermore, if the user points to an object or data field and does a FIND then I can probably infer exactly what parameters he or she wants to search on.

Now that I think of it, I should probably record the date a recipe was created and/or last modified. Definitely yes, since my recipe id will be symbolic rather than in the numeric order of creation. Providing a date search would probably be of direct aid to users. They often have a temporal sense of when they have added items or modified items in a personal database.

Indexes are somewhat more complicated because an index is made up of classification terms that are linked to objects. Obviously one always needs to create, modify, and delete objects and terms. Any object in the system like recipes and meals can be indexed under terms like "holiday meals". Therefore, I need a fairly rich list of explicit commands for dealing with indexes:

Explicit Indexing Commands


ADD INDEX (verb) CHANGE DELETE REMOVE MERGE SPLIT ORDER	To add a term to the index or to a list. To associate or link an object with a classification term in the index. To modify the term used in the index To delete a term from the index. To remove an object from the term it is associated or linked with. To create one term where two existed and merge the associated objects. To create two terms where one existed before and to assign some of the objects to the new term. To reorder the list according to various parameters

This is getting a bit complicated for the computer naïve user so I will have to introduce some of the common and simple operations as reactive functions (e.g. add and index). There will have to be a housekeeping menu somewhere which will provide access to all the indexing functions. Essentially this will be a free word index as objects can be linked to more than one classification term. The initial package should have a good file of index terms to allow the user to get off to a flying start. It will be critical how I layout the strategic screen(s) to convey the generality of the objects and actions.

I think now is the point to layout some of the above into the pieces that will make up parts of various screens. That will also summarize the above thoughts in a more condensed manner.

Strategic Choice Sets

The strategic screens are where the user makes a choice of a principle task to accomplish. A strategic choice is usually some combination of an object and an action that indicates a task. It may also include such things as a modifier. Modifiers are terms or phrases that qualify and object to select out a subset of all instances of an object type. For example, one might have mail that is "sent," "in draft", "read" or "unread." The strategic choice is the initial goal that the users set for themselves.

For this system, I should be able to design a single "strategic screen" or control panel for the user. To accomplish this I need two menus on the screen: one for objects and the other for actions. I will tell the user this is a "Chinese menu" (a pun!), pick one from column A and one from Column B to form their intended goal. Since I think I can get all my strategic choices on one screen I might call this "homebase" since it is the screen the user always returns to when they want to begin again at the top of the interaction tree. The interaction tree is something I can diagram to get an idea of what my design looks like.

Also, it is a good idea to provide some information on the status of the data base on the strategic screens. I think I will do that by giving the number of objects of each type. This one strategic screen should give the user an excellent overview of the system as a whole. It will give them an immediate list of the objects and generic actions as well as an idea of the size of the current database. In essence we have a "Chinese menu" with a choice from column A (objects) and column B (actions). Therefore, the central area of the strategic control screen should look like the following:

Objects	Number	Actions
Recipes	3,455	Get
Meals	238	Find
lists:		changes:
Keys	455	Create / Add
Ingredients	2,568	Modify / Change
Marked	35	Delete / Remove

The user will first pick an object either by moving the highlight cursor down the list of objects and hitting return, by choosing the capitalized letter (R, M, K, I, or M) and pressing enter on the keyboard, or by placing the cursor on the choice and clicking. Then he or she will make a choice of the action to go with the object chosen. The double click or enter key will cause the execution of the choices. The default should probably be Recipes and Get as the initial highlighted choices. Since some people cannot manipulate a mouse I need to make sure the keyboard interaction is easy to learn as well.

I will try to use the term "lists" to include the classification key words and ingredient's index without calling it an index. Hopefully, they will realize after some trial and error that "add, change, and remove" mean "create, modify, and delete" when they are applied to the "lists." Merging or splitting terms on the lists will have to be a reactive capability. They will be options under the modify choice. It would be useful to consider a hierarchical list structure particular for ingredients (e.g. meat which is made up of lamb, beef, etc.; beef which is made up of many different cuts of meat, etc.).

So far the strategic choices look straightforward and clear. Let's hope it can stay this way. None of the terms I am using at this point for actions are sacred and I can always decide to modify them after I do Protocol Analysis of the design on some potential users.

Come to think of it, there is an approach to a more general metaphor. Why not let the user think of the system as a library of books related to cooking. In fact, the user could create books. I could even have a visual strategic screen which was a collection of books about cooking techniques, ingredients, recipes, etc. I could have a cooking help visual image that is a kitchen where one can see different cooking utensils and tools and get help on each one. I could start out with books for recipes, meals, ingredients, and a dictionary of cooking terms for the categories.

Formats

When a user asks to get a recipe or a meal, the system will ask them to supply either a substring of the title or the beginning substring of the id. Certainly if they supply more it will be fine, but, in most cases this will result in more than one object being found. Therefore, the system should probably display the short form of each recipe or meal found and it might have the following tentative form:

RS.1         Rattlesnake Stew                       8/12/91 6/5/92

I think this should be enough to allow the users to recognize which recipe they want. The first date will be a creation date and the latter, if appropriate, will be a modification date. If the user wishes to see the full abstract, the SCAN command will allow him to do that from the reactive menu by placing the cursor on the recipe he wishes to scan. It should look like the following:

RS.1         Rattlesnake Stew                       8/12/91 6/5/92

             Keys: /meat.snake/exotic/American.southwest.Indian/rich/

Servings: 2    Preparation Time: 90 min.     Last Used: 12/8/92

Characteristics: High Fat, ,Stewed      Utensils: Simmering Pot

Comment:  Supplied by John Franklin from my National Guard unit.

          Tastes very much like rich oily chicken.

Why is it that whenever I start to lay out the "abstract" of an object I always think of other things to include. It dawned on me that the time to make a recipe is very important and is probably a good search criterion as well. Then it became obvious that recipes should indicate what type of cooking process is used (e.g., stewed, fried). Also, it occurs to me that many users may need a "comment" text to indicate notes such as the source and the taste of the recipe. Furthermore, it would seem that the last time a person used a recipe would be of interest for various search situations. This would allow me to perform tasks such as letting the user look at recipes they have not used in a long time. It is amazing, when and how ideas occur as one tries to layout a design.

I think I will allow multi-level indexing using the "." to indicate levels in a hierarchy of indexing keys. It seems to be very appropriate to the food area. The use of levels of indexing allows the user to distinguish between such things as Eastern.Indian recipes and American.Indian recipes or lamb.steaks and beef.steaks. The beginning user does not have to be able to use it, but I think with experience they will appreciate the advantage of multi-level indexing.

Reactive Choice Sets

Once the user has obtained a list of recipes we will need a "reactive menu," probably across the bottom of the screen, which provides the action choices the user would like to be able to use on this set of recipes. There are many possible things a user might wish to do but we have to limit ourselves to the most likely ones the user will want in this particular interaction state. It might look like this:

Scan/List/View Links Mark/unmark Remove Find Index Home Print

The "/" indicates the choice alternates that apply according to which mode the user or the object is in. For example, if the user is viewing the recipes in scan mode, clicking on the first function will shift to the list mode, or to the view mode to make the list into a list of the whole recipes. The same alternative type choices exist for the mark/unmark function. My first estimate is that the user needs the following reactive options:

View the list in different levels of expansion;
Mark or unmark objects in the list;
Find other related objects via links or searching;
Decide to make changes in the classification keys (index);
Return to "homebase" which is the strategic screen;
Print an object.

I have used "links" to ask to show links to other objects. I don’t want to exhibit all possible links, even by color, because it will interfere with the users ability to skim the list quickly. Therefore, the user chooses when he or she wishes to see the possible links he or she might make use of. I will probably think of more choices before I am done. I have tried to arrange these reactive choices in order of my estimate of decreasing frequency of use. That allows me to violate the 7 plus or minus 2 choices guideline which is based upon the capacity of short term memory.

The user will use the cursor to highlight the recipe he or she is interested in and then hit the capitalized letter of the command (or moving the cursor down and clicking with the mouse) to trigger its execution on that particular recipe.

I need to remind the user where he or she is in the interaction process and to let him know if there are more screens of material. So at the top of the screen I should set up a status line and use that location for status information no matter what interaction state the user is in. It might look like this:

Recipes.Get: 23 objects in list

That status indication might also serve to teach the user that he or she could enter "R.G" as a command at any point in the system and get back to this screen. That is if I decide to include commands in a modeless fashion. Why not, it is not that much more software effort to provide that capability.

So far I have one line at the top for the status, one or two lines at the bottom for the reactive menu and the rest is work space. I had better leave a blank line above the reactive menu to use for error or system messages. I could also use that blank line to explain the meaning (in a phrase) of each choice in the reactive menu.

Help and System Messages

I did forget to worry about HELP, I think I will just use the "?" as an icon symbol. The user can click on it for general help on that screen or they can put in a ? for any field on the screen he or she will get help on that field. If they enter the question mark followed by a term used in the interface, then they will get help on that term. Putting the "?" over any term used on the screen should give an explanation of the term.

Obviously, I have to continue to lay out all the alternative formats for all the objects and the appropriate reactive menus for each interaction state. But, I think the mind needs a rest and I will continue this when I am fresh.

Shared Processes

It occurs to me that both these indexes are going to be quite rich. The category of "fish" could have "tuna" under it, and if I were Japanese there might be very important distinctions in the varieties of tuna under that. This also means that there are linkages between the two different indexes and in examining one of the indexes the user might wish to see entries from the other. Also, users will need to have the ability to easily create new entries in both these indexes. Clearly, when creating a recipe, a new ingredient could be recognized at that point and the user asked to verify it as a new index item. However, dealing with the two indexes should be exactly the same and it should be looked at as a list processing task.

Users could start out at a very high level resembling the standard sort of cookbook (e.g., meat, fish, vegetables, etc.). If they choose to expand one of those categories they would see all the terms that appear under that term but as part of expanding (zooming in, blowing up, not sure what term I want) a single list. Then, of course any of those can be expanded or contracted in a standard outline form (+ or - functions on each entry at each level):

fish                                 250

meat                                 823

     veal                             58

     beef                            561

          red meat                   238

                 London broil         21

                 flank steak           9

          sweetbreads                  3

          brain                        2

In this example we have added a column that gives the number of recipes that make use of this major ingredient. One could actually click on the number and get a list of the recipes. Instead of the regular + and - expansions at any level one should be able to get a drop list and indicate which of the entries they want to expand to. List processing in most applications today still appears to be a relatively primitive process when in fact it is a good example of a potentially sophisticated and powerful shared process.

The user can go to quite a few levels of depth and needs to be able to zoom in and zoom out from this list. While the users are viewing the list, they should be able to make additions to it or even remove entries or change the terms. For example, the user may wish to modify the three recipes called "crab dip" to "hot crab dip," cold crab dip," and "faux crap dip." Each user needs to be able to adapt these indexes to their way of thinking about categorizing the recipes. A single recipe might occur at numerous points in this index. It also seems that a single index term could occur at different places in the index. Turkey could be listed under poultry and under the holidays of Thanksgiving and Christmas! As an ingredient it would have all recipes using it classified under it but as a subcategory under holidays it would list only those recipes that are appropriate for those holidays.

This index structure is hardly simple as the sequence determines the set of entries that occur and certain leaves at the end of the tree may be attached to more than one twig. It is not clear if I can make this easy to understand for the beginning user. Maybe I can get the user to think about primary keys and secondary keys and the ingredient links are secondary unless it is a "main" ingredient. Do I now need a modifier for the keys or is it only an implicit distinction? I could show primary and secondary keys on the recipe.

The main consideration here seems to be the reactive ability of the user to undertake a wide variety of actions as they go down through this index. When showing the index as a list I could also show how many recipes or meals are classified under that term. That would help them in deciding if they want to expand what is under that term. In fact, one could ask for an analysis of what other keys are used in the recipes that are under the given key. For example:

Turkey

Holidays

Thanksgiving

Christmas

Leftovers

This leads to a different type of expansion by keywords. It would seem there is a rather open ended set of options to consider just as a part of the indexing functionality. The more I think about this system the more complex it seems to become! How do I keep it simple to the user and let him or her grow into the sophistication when and if they need it? This seems to be an issue I am coming up against quite often.

It seems there are some very general functions having to do with handling a list that has structure. This seems completely independent of application. I have a very similar situation for handling an outline in a document. Certainly a document outline computer could be a lot more flexible than when it is on printed paper. For any outline there could be multiple dimensions along which the depth of an outline can be expanded.

Summary

The designer has gone through a thought process that seems highly unpredictable because it is impossible to forecast what any one designer will choose as his or her sequence in developing the pieces of the system. Ideas are generated by the stimulus of his or her current thoughts and not necessarily by an organized sequentially logical process. However, what is generated fits into a morphology of the elements of the interface design that becomes a useful tool or "checklist" to ensure he or she has put together a complete design. This structure for considering the design elements which are needed also serves as a stimulus to creativity.

In a very real sense this process is indicative of what any user might go through in any sort of creative task on the computer. What we term "cognitive variability" is exactly this example thinking process. If you can design a system to support the process of designing an interactive system, then you can handle the types of systems needed to support creative work by others. The key is the recognition of the structure that the user needs in order to fit the pieces of his or her creative process. It is the users "knowledge structure" that needs to be understood. The introduction of outlining in early word processors was a major shift to allowing users to express a knowledge structure for the subject of the composition they were writing. However, it is only one of a number of alternative tools possible for the facilitation of the creative composition process.

The structure for interface design presented here is one that was originally developed to teach students how to go about the process of design and it seems to work for that purpose. Recently there has been some work to develop and field test a system that could be used by designers in organizations (Balasubramanian and Turoff, 1975, 1978).

An application oriented version of this approach must allow individual designers to do some degree of tailoring of the structure itself. For example, a designer that is always working with database systems might extend this structure to incorporate specific items characteristics of data bases such as "relational tables" as a category of objects that is so frequent it deserves its own special recognition. Those designing group communication systems would add the concepts of human roles and privileges associated with individual roles.

The Checklist of Design Elements

The design process can start by considering the elements of a design in the same order presented below. However, each concept thought of can generate entries for the other parts. Also, after going through all the elements, it is very likely that the process will generate changes and additions to other parts of the checklist. The list of design elements contains an inherent set of levels to the structure from macro to more micro. Also the list is ordered from the most conceptual parts at the beginning to the most explicit design elements at the end. The designer can begin at the bottom levels and work up, at the top levels and work down, or move completely laterally between design categories at the same or different levels.

Objectives and Goals

The first thing the designer should attempt is a draft list of the objectives or goals for the system. Even for the recipe system there can be considerable differences in the resulting system if one is designing for restaurant cooking rather than home cooking. Designing is facilitated by understanding both the user and the application as a combination and to derive from that specific objectives that the design should meet. Usually the goals and objectives will be further refined as part of the design process, as one obtains an improved understanding of the user community.

Tasks and Requirements

This should be specific user tasks that the user or organization has to accomplish in order to satisfy the goals and objectives. They need to be expressed in terms of user terminology. They should include even those things that the user may have to manually as well as those things that might be put on the computer. There is a considerable literature on the detailed specification of tasks and systems that are designed to support such specifications that might trace document flow, work flow, transactions, etc. This is not our primary concern. More sophisticated systems to handle this can be integrated into the process we are elaborating on here. However, in the early stages of the process we would expect the potential users and others concerned with the requirements to often have to go through a creative planning phase similar to the one that we are discussing here for the design of the interface. The ideal situation is one where both efforts start planning and creative idea generation phase at the same time and as part of a cooperative effort between the designers and the users.

Metaphors

The metaphors of the interface design are the critical set of concepts in trying to design a system. They can be either very close to the user's mental model of the application, or they can be a new one which the user must learn and incorporate as a new mental model. Mental models and metaphors have their own chapter later in this book. The metaphor is what the designer is trying to present as a model of the system. The mental model of the user is what the designer expects the user to conceptualize about the system. It is not necessary that the metaphor and the mental model agree since users can change and involve their own mental model. The designer's objective should be to guide the user toward a mental model that reflects the system metaphors.

Users will always formulate a mental model of a system and it is far better that they end up formulating the one the designer had in mind rather than something else. Once the metaphors for the design become clear, the designer must consider how they can be conveyed to the user in terms of the specifics of the interface design. What are the cues (e.g., headings and terminology) in the interface that trigger learning aspects of the mental model? A design may have multiple metaphors and the likelihood of this goes up with the complexity or richness of the system. Those who have had some physics realize that traditionally Quantum Mechanics is explained as having both the metaphors of particles and of waves to explain Quantum Mechanical behavior

The example of the recipe system is an easy design problem, our potential users already have a mental model that incorporates recipes, meals, and indexes from their experience with cookbooks and index card files. In other words, we did not have to really create a new metaphor for this problem. We were able to tap their "familiarity" with this subject. However, this will not always be the case. Even with a recipe system the concept of meals and the ability to deal with them as lateral linkages to recipes may be a completely new functionality for even the experienced cook. We do not want metaphors to limit the ability of the user to discover new ways of doing things on the computer. Utilizing a cook book metaphor might have turned out to be too confining. In some sense, we sometimes desire to utilize the ambiguity in the language to allow people to learn new meanings to old concepts. For example, the verb clause "to message" did not exist before computer networks.

While there will be aspects in the electronic recipe that the user has no prior experience with, they will not affect those things we want the user to recall about recipes. For example, the ability to move between related items utilizing the Hypertext linkages between meals and recipes is not easily accomplished with a printed recipe.

Note that the designer did not choose to explicitly incorporate the concept of a "cook book" or a "card file" as part of the metaphor. In this case, the concept of recipes seems to be sufficient to make the system "familiar" to the user, and the concept of a "book" or "card file" adds no utility and might overly constrain the user in his or her thinking about the system. The high degree of lateral linkages or non-linearity of the recipe linkages is contrary to the traditional conceptions of a book. Sometimes metaphors that are too similar to manual processes can inhibit the learning of new concepts and facilities available in the system. Clearly this is one of the many tradeoffs in the design process.

Objects

The next most important element to consider is an explicit itemization of the objects that will make up the system. Although it is difficult to be exhaustive in the first try, this process will help stimulate the thoughts about the rest of the pieces and to further refine the metaphor itself. An object is a grouping and/or organization of data that represents a meaningful collection of information to be perceived and/or manipulated by the user.

Initially one tries to figure out the various data elements contained in the object. As one begins to examine the functions that are performed on the objects and the explicit layout of the short, abstract, and total object format, the usual result is the identification of additional elements. Also, the example of the recipe system did not deal explicitly with compound or embedded objects within objects except for the simple example of a meal. This can be far more complex in many applications. Consider a maintenance database for the parts that make up an automobile, not only do we have many levels of embedded objects but we can also have overlapping classifications of objects (e.g., the cooling system and heating system share objects).

The designer tries to define objects at the level where the user wishes to manipulate a collection of information. Unfortunately, there are differences among users as to what they see as the atomic or molecular particles of their problem. In the recipe system one could have considered the recipes at one level (molecular) and the ingredients (atomic) as another meaningful level. The ingredients were at such a primitive level we could treat the whole set as an index with data associated with each entry. Meals were higher level objects that contained recipes as sub-objects. Some times this choice of level is critically dependent of the expertise of the users. The more expert they are the more they need control over the primitive levels of the application. A nutritionist would want to want to consider the nutritional components of the ingredients as the atomic level objects. A doctor specializing in food allergies would wish to be able to deal with the organic chemical level below ingredients.

In the process of defining objects, the designer should find appropriate levels of abstractions that serve to group data together into meaningful packets of information of concern to the user and his or her application.

Heading

A heading is the shortest form of an instance of an object that serves to distinguish it from all other instances of that object. It is the form to be utilized when the user is presented with a list of instances of an object and the objective is to get as many entries as possible into the list that is on the screen. Headings would usually indicate some sort of title and/or id for the object and could information include information such as when the object was created or who created it. Usually headings are no more than one or two lines in size.

Abstract

The abstract is a grouping of all the data that relates to the status and/or history of the object. It would include the information already provided by the "heading." The abstract includes any data that is used to classify the object within the context of the application. It is, in essence, everything except the actual content of the object.

Object parts

Many objects have internal divisions into parts. These divisions are usually made explicit so that a complex object can be broken into parts for user comprehension and for user manipulation of sub-groupings of the data. A message could have text content and separately a binary file attachment. In our recipe example there is a part that is the ingredients and a part that is the preparation instructions. They are each a very different grouping and content of data that make up distinct parts of the total recipe. They serve different purposes for the user.

Sub-objects

A sub-object is one that can be extracted from the object and treated separately as an object to which all generic operations possible on objects can then be applied. A document, for example, may contain diagrams that can be treated as separate objects. A tabular report might contain a column of data that the user needs to extract for input into an analysis routine. Columns might be explicitly treated as vectors that the user can manipulate. In the recipe example a salad recipe may contain a recipe for a dressing. A menu for a meal may contain many recipes.

Links

Links are an expression of a relationship between two independent objects or between objects and sets or lists that they belong to. These links may be explicit or implicit in nature, depending on the extent the designer wishes to make them explicit. Links can be handled by internal linking of one object to another (e.g., hypertext approach) or by creating object groups to which objects belong (e.g., indexing). A recipe for kneading dough might link to a video clip demonstrating the technique of kneading.

Actions and Functions

Once we have some concept of the objects, the consideration of what functions the user can perform on those objects is a very easy extrapolation. There are three types of functions that need to be considered: generic, explicit, and control.

Generic

Generic functions have a common meaning but differ in the details of their execution depending on the object they are applied to and the interaction state of the user. The "creation" of an object is a clear example. The creation process triggers an input process that is unique to the type of object being created. Generic functions have the advantage of allowing the user to learn one concept that applies across a range of objects and tasks. Very common generic operations are:

Getting, Finding, Creating, Modifying, Deleting

Almost all the objects one can conceive require the above operations to be available to the user. Certainly they may be designated by other terms in the language (e.g., reading, searching, composing, etc.).

Finding something is a rather common generic task but how the search is done may depend upon the data structure of the particular object. Also the specific search criteria needed may be obvious from the interaction state. For example, when sending a message an obvious search is by name part to find the explicit identity needed to send the message to a given individual.

When getting a set of objects, if the number is sufficiently large the results might be presented in the "list" mode. If it is a small enough set which fits on the screen, the "scan" mode might be the default presentation form. And if it is only one object, the whole object would be presented. This might also be handled by giving the user a warning when an action is going to result in great mass of material so the user can reconsider his or her choice.

Defining a generic function means itemizing all the variations that can occur by type of object and by interaction state of the user. This definition process also involves the specification of any associated "defaults." A default is the most likely choice or the safest choice by a user in a given interaction state.

Explicit

Explicit functions have a specific meaning that never varies regardless of the interaction state. They may also be dependent or restricted to a single object. The function to "index" a recipe or a meal always adds terms to the index for the particular object it is applied to. While one might "modify" an object as a generic function, the process of "editing" a text object, such as a message, might be restricted to only changing the text of the object.

By examining each of the generic commands and object combinations, one triggers ideas of what specialized versions about the generic functions might be useful for the user. The concept of frequency of use is helpful in determining the need for specialized or explicit commands. For example, the explicit reactive "index" function that allows a person to simply modify the keys on an existing recipe is likely to be used quite frequently. If the user had to go through a complete process for modifying everything about a recipe when they only wanted to change a key, the net result would be that they would probably not bother to change keys very often. The ultimate result of this would be a gradual deterioration in the utility of the keys for effective searching.

Controls

Controls are those functions which control the interaction process and the resources allocation process of the computer facilities. They are the functions that are independent of any specific application and which can be generalized across all applications: e.g., printing, scrolling, help.

Returning to the starting point of the system interaction, being able to escape from performing a task, and getting help, are other important examples of control functions. Ideally, controls should be consistent across the entire system and available from any point in the interaction. This may not always be possible. For a particular application package, any functions that control or regulate the interaction process (e.g., mode the user is in) and are available in any user state are considered to be control functions.

In the evolution of interactive systems, controls often became keys on the keyboard (e.g., pgup, pgdn, escape, home, end, insert, etc.). Today they become click buttons on the screen. (e.g. minimize, maximize, close). One would like controls to become as automated or transparent as possible. In a single organization, one would expect that controls would be standardized across all applications that are developed in-house. Traditionally operating systems have been the highest level for control functions that interact with all applications (e.g., save, print). However, complete standardization is not always possible nor desirable because of the introduction of new functionality as interfaces evolve. Certainly many of the window control features such as scroll bars have become defacto standards. Things to open an close nested list elements are less standard but will probably reach a point of being an accepted standard at some point in the future. One would expect new standard control functions to evolve for such areas as the control of Hypertext linkages when this area becomes more mature.

Modifiers

Modifiers are terms that select subsets of objects. In our example we have divided recipes and meals into complete and incomplete. So this example has only one modifier. However, if we were to allow a full command structure we might allow index terms to become modifiers so that the user could directly say: "get Thai recipes." We have implicitly also allowed "marked" as a modifier; however, since we have made the marked list an object we do not have to explicitly break it out as a modifier. An excellent example exists in mail systems: message are either read (old, accepted, etc.) or unread (new, waiting, etc.). In a more sophisticated mail system there might be a list of shared modifiers between senders and receivers: urgent, personal, inquiry, etc.

In general, modifiers are the possible status states of objects within a given application. They may both be explicit and implicit in nature. Explicit modifiers can be directly chosen as explicit functions in the interface. Implicit ones might be available only through other functions such as "find" (e.g., finding unused recipes since some earlier date). In a personal budget system one would probably set up categories for expenses dealing with food, transportation, clothing, etc. These are very explicit modifiers of the general data type of expense items. On the other hand only when the user goes to find a particular collection of expenses does he or she get modifier choices like "regularly monthly" expenses to find the expenses which are repeated every month.

Modifiers provide the user natural (to the task) sub-groupings of instances of a given object. They create subsets and lists of objects that the user can manipulate by applying various actions. Many times what are referred to as filters are really just more specialized modifiers. Modifiers might be considered to be key word index terms which are built into the software design because they are applicable to that particular application and meaningful to most users who understand the application.

Strategic Choice Sets

The strategic menus and/or screens are where the user indicates a specific task that they wish to accomplish. It is the goal they have set for themselves in that part of their interaction. They may have to accomplish other tasks to reach the main goal but only as part of traveling the path to that goal. The designer needs to develop an understanding of what subtasks are likely to be needed in accomplishing the alternative strategic goals and what variations are possible in a given population of users. Usually strategic goals are a selected combination of an object, a modifier, and an action.

The strategic choice sets presented to the user provide a very important degree of comprehension of the range of user objectives the system can serve. This element of the design also serves to provide the user a sense of mastery over the system. By allowing the user to select and indicate to the system the ultimate objective or major task to be accomplished, it allows for a design that can guide the user through a process. The designer can make considerable utilization of these specific strategic tasks to design the screens to support the accomplishment of the process.

Reactive Choice Sets

When a user has obtained an object or a set of objects, the design question is: what sort of functions he or she most likely wants to perform on that object when they are part of that particular interaction state or carrying out a particular strategic task. The menus or alternatives that the users can utilize at any particular place in the interaction are the reactive functions and are usually presented in the menus available at that point. The reactive functionality is what really provides one of the key benefits or value added ability of interactive systems. This is what allows different users to make different cognitive choices as to how they want to proceed with their task from that point in the interaction. The designer must consider how actual instances of objects and the data they contain may trigger the need for certain choices. Successful design of these sets are very dependent upon the designers knowledge of expected human behavior.

This does not mean the system cannot be designed as "modeless" so that at any point any possible command or alternative is available. The experienced and power users will learn to remember commands they like to use frequently and can employ them even if they are not on the menu. The reactive menus are primarily for the casual users and those learning that part of the system. Also, if it is a "rich" system, even experienced users will not be able to remember those things they don't use frequently. It is possible the design of the reactive menus could differ for different types of users. One might have a facility for an experienced user to tailor his or her own reactive menus.

These sets of reactive capability also serve to guide users as to what may be the more desirable alternatives at a given point in the process. They are a way of educating a user who is not an expert in the particular solving problem process.

Reactive functions could have the default of working on the object or set of objects being considered at that point. However, in many cases the user needs to select objects specifically out of the list they are dealing with. For example, the "mark" function is a clear cut reactive function and requires that the user be able to specify which objects to mark. The implicit function that is always needed in reactive menus is the ability to "select" the items. This is often provided by being able to move the cursor to the item and hitting a key/button that selects the item or range of items. If the object has variable size one has to first do a select operation before performing an operation like mark or copy. This is still somewhat clumsy in that the natural cognitive mode is to first select all the things that one wants to mark or copy and then do the copy or mark in one operation. Even today’s generation of word processors have not overcome this limitation.

Strategic functions can also be reactive ones. The choice of a given set of reactive functions to make up a reactive menu is a difficult design choice, it can be influenced by the initial strategic choice, the interaction state, the information in the objects being dealt with, and the nature of the specific user. Clearly the final choice is a tradeoff situation. If there is one thing in the design that the designer would like to have the power to easily modify after some initial use of the system by real users, it is the reactive choice sets provided throughout the interaction. Any effort to make these choices easy to tailor at some future time is well worth the investment in the development of the system.

Shared Processes

In any system there are always macro level functions that can occur at a variety of different places in the interaction. In the above examples two clear cut shared processes are the "manipulation of a list" and the "marking" process. A third may be the "find" or search operation that still has to be investigated as a shared process relative to the current state of the above design.

The interface and interaction for shared processes should be the same regardless of where the user is in the interaction. Once, a user has mastered the process, he or she should not have to relearn a different version in a different part of the system. However, there can be situations where one has to violate that guideline. For example, if the general "find" function turns out to be quite elaborate, it may be that at some point in the interaction only a very small portion of the functionality is needed 99% of the time. In such cases it might be better to present only that subset as an explicit function at that point in the interaction.

In just about any application there are always some degree of list processing and some degree of searching that occur at numerous different points in the user interaction. One could assert that the scroll bars are one aspect of list processing that has become a standardized feature (e.g., viewing long lists). Therefore in any design it is useful to explicitly consider list processing and search functionality as potentially a shared process.

Searching

In designing a common approach to searching, there is more than the basic question of how one allows the user to request quantitative or textual oriented search criteria. There is the higher level question of how to handle the overall process that involves:

* Initiating the search and being informed of the results with respect to the amount of material found.

* Deciding and indicating what is to be retained or discarded in a search result.

* Whether to initiate a search of material found or to search the material not retrieved and how to combine this with the prior searches.

Searching is actually a highly iterative process and even more so when the material is largely textual. Note that it also has embedded within the process some demands for list processing functionality.

List Processing

There is a very large list of potential capabilities that can be associated with list processing:

* Adding and removing items from a list

* Dividing lists in to separate lists

* Merging lists

* Sorting and comparing lists

* Expanding and Contracting lists with level structures

* Marking items in a list

The process of "viewing objects" may be represented as a function of expanding a list of objects from the short form presentation to a full content presentation. Clearly, list processing is a general backbone for just about any application. Can we get users to adopt the general metaphor of list processing? If so, we could greatly increase the commonalty among all applications.

Ultimately, or at least within the context of the applications being developed within a single organization, one would hope to see a standardized approach to providing the users the fundamentals of list processing.

Lateral Classifications

Lateral classifications are common in most computer based applications regardless of whether they are referred to as a Hypertext capability or not. In this example, the meals link to recipes and the recipes will link to the meals they are part of. Therefore, the user looking at a meal can easily get immediately the recipes or visa versa. Some users will look for meals directly and others will look for meals by first choosing a recipe. We have no way of predicting which method an individual user will find most satisfying.

In any application, a user dealing with a given object may need to look at other objects of the same or of different types somehow related with the original. For example, in message systems there are original root messages and the replies to them. Clearly when the user is looking at one of the replies they may wish to see the original and the other replies at that moment. The user should not be forced to go through the strategic level of interaction to accomplish this. Ideally, the use of lateral classifications can be done reactively.

Any one who has used computer based tax forms quickly appreciates the fact that data elements on one form are automatically linked to the forms that utilize the data as input to another calculation. The ability of the computer to provide useful lateral linkages is one of the key value added features of computers over that of manual approaches to the problem.

Lateral linkages can also be provided by higher level constructs such as key word indexes. All recipes containing chicken as a primary ingredient are an obvious lateral classification. In many applications it is necessary to allow the user the flexibility of building their own lateral linkages.

Formats

Laying out the formats of objects, parts of objects, and menus are an important initial design objective. The process of carrying this out never fails to stimulate new ideas and considerations about other aspects of the system. Don't try to do any whole screens until there is a good feeling about a significant number of the possible formats. Screen design is better done after one has a good conception of the forms or screen parts that will be needed.

Formats are usually the first attempt to explicitly layout bits and pieces and usually result in stimulating more ideas about other requirements. As a stimulant to creativity it is better to focus on these very low level independent items rather then an entire screen. By looking at the parts of a particular object one usually gains more insight into that object. Whereas, trying to lay out a screen is functionally more like the final formatting of a completed document. Looking at a format at the level of an object or object part gives one a very tangible impression of how well structured the object is for comprehension and whether it is truly complete in terms of the data or information that has to be convey to the user. The format lets the designer place themselves in the role of the user and see the visualization that the user will see.

Object Lists and Sets

In just about any application, users will need lists and/or sets of objects. These lists are the natural consequences of many of the functions and modifiers needed to carry out the system tasks. Explicitly identifying these lists is one of the necessary design tasks and also serves as a stimulus to other design elements. By explicitly trying to enumerate all the instances of lists it is quite clear that missing options might be exposed. By comparing the lists for one type of object with those proposed for other object types it is very likely that gaps will become easier to perceive.

Interaction States

Both the designer and the user need to understand the interaction states that the user can be in. Clearly the highest level subdivision of the interaction states in the above recipe system was the state given by a combination of the strategic choices for objects and actions (Get Recipe, Create Meal, etc.). When the user is interacting with the system there should always be a clear indication to the user of the state they are in and how they got there.

Users may decide to leave a strategic state temporarily, such as deciding to do a "find" operation. While they are in the "find" state, the system should also show them where they came from because it is presumed they will go back there after the current operation is completed. Users can be interrupted at any time by phone calls, someone coming into their room or office, dinner, etc. As a result, they can forget how they got to that particular point and, as a result, why they are there. In fact, the user’s concentration on the immediate task can cause them to forget what they were doing previously. Therefore, the identification of interaction states and paths to them are important in insuring that the user does not have to repeat work.

In a well-designed system the user would be able to shut down the system and be able to return to exactly what they were doing when they started the computer up. This ability is dependent upon the nature of the operating system but is becoming a standard facility for multi-tasking operating systems.

Interaction states should be coded with easy to remember headings (i.e., get.recipes). The user will encode a given screen in their memory and if the designer does not provide a proper "heading" to use the user will find their own cue to encode with. The titles or headings of interaction states is also necessary for users to communicate to others about needed help, bugs, or problems.

Once a fairly good specification of the "reactive choice sets" is established, it becomes worthwhile to exhaustively express in a network diagram the different interaction states (nodes) and the transitions possible between the states (links). Furthermore, for each interaction state one should attempt to list the sequence of screens needed for that state and the principle objective for each screen.

Necessary Help

As a designer goes through the pieces of the design, he or she should carefully mark down anything that may not be relatively obvious to a number of users. These are the items for which the designer should try to write some help as the initial phase of the design process. Another item of necessary help is to try write a very concise explanation of the overall design or the "metaphor" of the system along with the primary objectives of how it will service the user. These help items should be part of any initial Protocol Analysis of the initial design. Also the Protocol Analysis study of the initial design will help to pin point where additional help material is needed.

Hopefully, in any given organization, there is at least a standard for how different applications should provide help while on-line. If not, the designer has to include his or her own approach to providing help as part of the initial design. It may also be that the application requires more help facilities than the minimum standard demanded in the organizational setting.

Trying to enumerate the objects, actions, modifiers, etc., that will not be obvious to the user usually provides considerable insight into the evolving design. This process is very likely to lead to some changes in earlier specifications.

Error Conditions

Clearly an understanding of where the user can make errors and how to handle the errors are also critical to the design. Errors are a normal part of human behavior and not a sign of "stupidity" as some computer people come to feel about users who make errors. A poor design can encourage the production of errors; however, even a good design contains points in the interaction where the probability of errors occasionally being made is rather high. Identifying such situations will be easier to do when we discuss later the nature the error types.

Screen Layout

Finally, the screen layout is also key to creating an easy to learn system. As with error handling, help and documentation, screen layout is treated in more detail elsewhere in this book. However, the segments of a screen that have been identified at this point are:

* Workspace: Where the information dealing directly with the task is handled.

* Control Area: Where the user may execute functions that he or she wishes to employ.

* Status Area: Where the users are informed of what they are doing and what the status of their work.

* System Message Area: Where messages from the system appear. These might be closure, notifications, help, and/or error messages.

This is the minimum number of screen areas needed for any application. More complex systems may require other types of areas and/or more areas such as different views or abstractions of a given application object.

System Messages

These are the messages issued by the system to explain errors or to notify the user of changes in the status of the tasks that he or she is doing. What transactions and status changes does the user need to know to aid in carrying out his or her tasks? Once again this enumeration may stimulate insight into missing features and functionality.

Summary

The result of the prior exercise and overview is a set of items that make up a checklist for the designer and for categorizing his or her ideas as they attempt to develop the concepts to go into the design of their interface. They are summarized as follows:

Designers Checklist

Goals	Functional objectives that may impose constraints upon the elements of the design
Tasks & Requirements	Specific users tasks in user terms
Metaphors	A holistic representation of the system that the users can understand and incorporate in their mental model of the system.
Objects	The collections of data at a level the user will wish to manipulate or that make up task related groupings of data.
Heading	The shortest possible form of an object that uniquely distinguishes it from other instances of that object type.
Abstract	All status, state, and relationship information about an object. Everything but content.
Object parts	Sub-groupings of data within an object that have some meaningful representation to the user.
Sub-objects	Objects contained within other objects.
Links	Potential relationships between objects that should be explicitly available to the user. Or, linked executable routines.
Actions	The operations performed on objects or parts of objects.
Generic	Actions dependent upon the object type and/or interaction state.
Explicit	Actions that are always the same regardless of object type or interaction state.
Controls	Meta actions to control the user's interaction with the system and which are consistent throughout the application and across applications.
Modifiers	To create specific subsets of objects that ¡¡reflect object states or status. Modifiers can be applied to objects and/or actions.
Strategic Choice Sets	Primary goals and objectives of the given user interaction. Usually composed of an object, action, and modifier combination.
Reactive Choice Sets	Actions a user needs in order to react to objects and lists resulting from the users current interaction or interaction state.
Shared Processes	A collection of functionality that is common to different interaction states.
Searching	A common shared process in most applications.
List Processing	A common shared process in most applications.
Lateral Linkages	Relationships between or associations among objects, object types, lists, and/or functions
Formats	Layouts of pieces: objects, parts of objects, abstracts, menus, etc.
Object Lists and Sets	The lists of objects the user will needor desire to manipulate.
Interaction States	The states a user can be in and needs be able to identify.
Error Conditions	Identification of possible errors that the usercould make.
Necessary Help	Identification of what is unclear or not selfevident in the interface.
System Messages	Notifications, Closures, Confirmations, and Error Messages.
Screen Layouts	How a given screen is structured.
Workspace	The part of the screen where the user carries out their task.
Status area	The part of the screen that identifies where the users are and how they got there.
Control area	The part of the screen where the user can trigger or execute functions to apply to the work area.
System Message area	The part of the screen where system and error messages appear.

It should be clear that if one is to design a system to aid the designer in accomplishing the creation of the above elements that the resulting system would be a Hypertext system with a considerable number of lateral relationships. Moreover, it would be extremely desirable to retain for the designer a record of the "path" of his or her thoughts in the creative process of design. Which particular design element stimulated an idea about another design element? A record of these implicit linkages would be extremely useful in documenting the reasoning that went into the design and perhaps serving to clarify the explicit nature of the tradeoffs being made in the mind of the designer.

Other Design Elements

For any particular application there may be additional specialized design elements that the designer should add as explicit elements to the prior checklist. Some examples of other types of elements include:

* Roles: In group communication systems it is very common to build special software tools that are only accessible to certain members that have been given "roles" or privileges to carry out as an explicit part of the group communication process. Also these roles might be very dependent on explicit privileges that are lower level functionality that the designer may wish to explicitly identify.

* Filters: In communication and other automated data delivery processes there is a general functionality to provide users which allows them to place filters on a stream of data or communications in order to redirect the data to where it should or should not go.

* Agents: These are executable programs that the user can trigger to carry out certain jobs when the user is not actually active or dynamically in control. It is a functional capability that can work for the user while they are sleeping.

* Anchors: In Hypertext, system specific symbols, fields, field types, and or sub-objects take on the role of place markers for Hypertext linkages. There might be a variety of these identified in a given application and furthermore, they may have semantic typing associated with them.

The designer should feel free to add elements to the design checklist according to whatever application they are concerned with and whatever meaningful breakdown of elements they feel is relevant to the situation.

Levels of Design Difficulty

The only way to learn to design is to do it and a course in this topic should make design assignments the key effort. There needs to be a common software package for the class as a whole where each student can prepare a mockup of the screens to present to the class for common review and critiquing. After such critiquing and an exchange of ideas, the learners should have a chance to both improve their designs and conduct a Protocol Analysis on them.

The process of becoming a good designer is a process of growing increasingly humble. Too many seem to feel it is a straight forward, based on guidelines, and a recipe following process. A learner in this area should go through increasingly difficult design processes in order to begin to appreciate the difficulties involved and the fact that the designer is always approaching a new learning plateau.

The following are the three levels of design difficulty that the learner should encounter in a course of study in this area:

Level One: Functionally Transparent

This is the situation where the existing mental model of the user and the system metaphor are similar. A clear example of this is the "recipe system" where there is a clear metaphor that the users are familiar with. A personal financial tracking system might be another such problem. This first level gives the learner a chance to focus on the learning of the generally accepted guidelines for things like screen layout, but usually does provide an interesting challenge in creating the functionality that would be more useful than the current approaches to the problem. Can the student come up with something that is more useful as well as well designed? When we introduce a high degree of linkage in the recipe system and turn it into a specialized Hypertext system we begin to diverge in terms of making the users mental model based upon cook books and the implementation model based upon Hypertext farther apart in a semantic sense.

Level Two: Functionally Fuzzy

In this situation the mental model of the user is only a subset of the interface metaphor. Assignments at this level should also have a clear cut metaphor that the designer can capitalize on but with significant differences between the way the application has been done previously and the way it can be done on the computer. An example of this would be a "group calendar." We will explicitly treat this type of system in the chapter on Computer Mediated Communications. Clearly all users understand how to use their personal calendar and they understand how to use various communication processes to establish group meetings, task deadlines, etc.; however, a "group" calendar is really something that can only be done through a shared computer network. As a result, the group calendar has functionality that is unlike anything available in the "manual" approach to the task. It also brings up some tradeoffs between issues like individual privacy and group facilitation in the scheduling process.

Furthermore the group calendar raises numerous issues about the social behavior of the group and issues of individual privacy. These require reaching compromises between rights of the individual and the efficiencies of the group. As we will see later, when we introduce a high degree of linkage in the group calendar it could become an interface to all the companies information resources. This is a far cry from the pocket calendar and if the user attempts to restrict his model of the system to the pocket calendar he may have considerable difficulty in using the system without proper training and learning aids.

Level Three: Functionally Opaque

Finally we have the case where there is no existing mental model to match to the interface metaphor. This is an application that could not be done without the computer and therefore there is no mental model that the designer can assume already exists in the mind of the user and hence, the designer must create a new metaphor. A true Hypertext system (not the simple WEB type) is a good example of this class of design problems. There are still many computer users who have had no real experience with reading or writing non-linear text. They have grown up in an environment where text was always presented as a linear arrangement of thoughts.

In this type of problem the designer comes face to face with the dilemma of trading off system opacity and functional opacity in the design of the system. That is a very humbling experience. This type of problem will be treated in the chapter on Hypertext. It will be seen there that knowledge of the implementation model can be extremely beneficial to the user in moving into the use of the system for new types of applications. Another interesting example is the teleportation facilities in some of the virtual worlds on the WEB.

Even after going through these three levels of design, until one actually implements systems for real user groups, there is a level of appreciation of the difficulty of design process that cannot be conveyed in only a learning process. What is even more enlightening is being in a design team and discovering that individuals can spend hours arguing about seemingly minute points in the interface.

Creativity in Design

"Imagination is more important than knowledge"

Albert Einstein

"Give me the young man who has brains enough to make a fool of himself."

Robert Louis Stevenson

"The sublime and the ridiculous are often so nearly related, that it is difficult to class them separately. One step above the sublime makes the ridiculous, and one step above the ridiculous makes the sublime again."

Thomas Paine

Some people are exceptionally creative and appear to do it with very little effort. However, just about any intelligent person who understands complex situations or has a degree of expertise about a given area can also exhibit creativity. There is a form of creativity that can be triggered by a combination of the right mind-set, knowledge, and associated effort. It is a process that frees an individual to create and examine the greatest number of alternative solutions to various design problems. It is a commitment where the designer must invest a great deal of cognitive effort and exclude other distractions for prolonged periods of time. Students, beginners, and apprentices often exercise a great deal of creativity in their process of learning and problem solving. Basic creativity is not a rare gift. Just like genius there may be extremes in creativity.

The Nature of Creativity

Having a unique definition for creativity seems to be considerably more difficult than recognizing a creative result in a particular situation. An excellent example of creativity was Dimitri Mendleleev's introduction of the Periodic table of the elements in 1869. This structure, in one stroke, brought order out of confusion. In creating this view he did not allow any of the usual inhibitors block his creative process. If he could not find an element to fit in a hole in his table he left it blank. When a given element did not appear to have the right atomic weight he challenged the accuracy of the current measurements (later he was proved to be right).

It is relatively easy to recognize the conditions that block the occurrence of creativity. There are many cultural myths, environmental distractions, and psychological blocks to creative thinking:

Imagination, fantasy, and reflection are a waste of time and sign of laziness.
Playfulness and humor are not for serious problem solving. Humor does not belong.
Rational reasoning, logic, quantification are all good; feelings, intuition, qualitative judgments are all bad.
Tradition is preferable to change and if it worked before why make a change now.
It is just a matter of effort and money to solve any problem.
Certain considerations about problem are taboo. (e.g., we are not in that business!)
Lack of cooperation and trust in a group.
Fear of appearing stupid, loosing face, or taking a risk.
Distractions and interruptions resulting in an inability to become immersed in the problem.
Domination, status, and authority inequalities emphasized in group processes.
Inability to tolerate ambiguity and a desire for order.
Preference for judging ideas.
A need to make decisions quickly.
A lack of interest in the problem.

Habits and fixations are the primary factors blocking creativity. A classic experiment involves individuals who are given three small open boxes, a few tacks, matches, and some candles. They are asked to mount the candles on a door. The solution was to mount the boxes on the doors with the tacks and use them to support the candles. Most people were able to recognize this use for the boxes and accomplish the task. However, when the matches, candles, and tacks were each placed in the boxes only 40% of the subjects were able to solve the problem. Having been presented the boxes in the context of being containers for the supplies, a great many people could not escape from that fixation and were unable perceive them as having another use in this situation.

Creativity is discouraged in work environments where everyone is assigned enough work to fill up all the available hours. When the pressure is on to get the code written it is very difficult to do creative design. The motivation of the those developing a system is critical to getting creative design done.

It is sometime far too easy to block creativity than it is to encourage it. According to Henle (1962), the three characteristics of a creative solution are:

Correctness: The solution is right in that it will solve the problem without the introduction of other problems created by the solution.

Novelty: It appears to be a novel or new way of handling the situation. Some people have equated creativity to "effective surprise."

Harmony: The solution seems to fit within a large ecological context or has a greater generality than prior approaches. Sometimes the word "elegance" is used instead of harmony.

Many view the concepts of association, analogies, and metaphors as key components and characteristics of creativity. Indeed, associations are one of the key elements in aiding the generation of creativity. The ancient Greeks recognized three distinct types or "laws" of association:

Contiguity: things that are close to one another (e.g., a shoe and foot). It can also refer to things that are next to one another either in physical position or in time.

Similarity: things that are alike based upon some principle dimension (e.g., dogs and porpoises as mammals with maybe similar intelligence).

Contrast: things that are associated because of the difference between them based upon some principle dimension (e.g., salt and sugar as having contrasting tastes).

The combination of associations and structure relationships between very diverse elements was a strong concept in Bertalanffy's formulation of General Systems Theory (1968). He was one of the first to observe that certain modeling concepts developed in the hard sciences and engineering could be applied to biological organisms and to social systems. He specifically defined the term "isomorphies" to describe the appearance of structural similarities across diverse and very different fields. He stated:

"the isomorphy is a consequence of the fact that in certain aspects, corresponding abstractions and conceptual models can be applied to different phenomena."

One might characterize General Systems Theory (GST) as a methodology of developing abstract associations and similarities about open systems. Since people, organizations, and information systems within the context of organizations are all open systems, GST can be a helpful theory for structuring problem solving in the design of systems.

Individual attributes aiding creativity

There are a number of conditions that underlie a person's ability to exhibit creativity about a problem.

Receptivity: A person has to have an open mind to ideas and allow them to flow unrestricted. Evaluating ideas during their generation may restrict their flow. Goethe described this process as one where ideas came "like a foreign guest." The most unexpected stimulus can cause a new idea if one has opened the mind to the possibility. There is an immediacy to the generation of ideas but also a deferral to the closing of the idea process. No one expects to have his initial and final ideas about a given problem at once. The process of letting ideas incubate is often referred to as a part of the creative process. The root to the noun "incubation" is the verb "to lie down" (e.g., sleep on it). For this reason, attempts to perform the creative part of a design in a single meeting are probably unwise.

Guilford (1959) referred to the ability to produce numerous ideas as a "fluency of thinking" or fertility of ideas. One might characterize this ability as "diarrhea of the mind." Another phrase used to express this is "copious ideation" as the process of thinking up all possible tentative ideas. An even stronger expression of this property is the concept of gullibility which is a willingness to explore everything, to be open, innocent, and naive before rejecting anything. On a group basis we characterize this component of creativity as "brainstorming."

Immersion: The problem, in this case the design, has to become the all consuming thing in a person's mind. Creativity means an intensity of effort in which all other considerations are excluded from the mind. Creative design is not an eight hour, five days a week job. It is a process so consuming that some ideas can be triggered in the designer's mind in the dead of the night or while eating dinner. When your spouse starts complaining about your forgetfulness and your lack of attention you have probably obtained the right level of immersion in your particular design problem. It goes without saying that one must enjoy the design process in order to be able to immerse oneself in it. Design can be an all consuming involvement. To some people the word immersion is not strong enough and creativity is characterized by passion, but balanced with decorum.

Insulating the ego: One has to accept the fact that one may think up many ideas that will turn out to be "stupid" upon more complete evaluation. Probably only one out of ten ideas will be the creative one. In the group design process the members must have the respect and fondness for one another that will allow them to exhibit various degrees of "stupidity" to one another. Some ideas can even pass evaluation by a group of designers and only turn out to be stupid when tried on users. Experience does not lessen the number of stupid ideas, it aids in the overall quantity of ideas, both good and bad, generated.

Detached Devotion: Not overly committed to any initial ideas. Perhaps the greatest inhibitor to creativity is experience. We tend to want to reuse the things that worked in the past. Return to the same fishing spot where we caught the most fish not realizing that we and others might fish it out. Experience can inhibit the development of new approaches. Therefore, we should not place to much devotion in any single approach or let a favored approach inhibit our ability to think of new approaches. In the group process one needs to insure to balance individual creativity with group creativity. The results of a group process should be set aside and the individual given a chance to exercise individual reflection before terminating the creative process. The individual needs to detach themselves from the group.

Seeking questions: Each idea must be utilized to raise other issues or questions. One needs to take the basic problem and try to reformulate the question being asked. Sometimes this is referred to as characterizing the problem in a new problem space. Reformulation of a problem may be that mysterious stimulus that generates an unexpected solution. Poincare (1905) spoke about rearranging things that "reveal to us unsuspected kinship between ... facts, long known, but wrongly believed to be strangers to one another." Generating different views of a problem can be a useful stimulus to its solution. The discovery of the periodic table of the elements was just such a restructuring of facts that provided tremendous new insights. This extends to the concept of connecting complete diverse areas through the use of metaphors, e.g., the window or spatial representation of an interface.

Utilizing Errors or problems to stimulate other solutions: There is a classical process in engineering design where one considers the possible solutions for a given problem, then takes each solution and asks what problems arise as a result of it, and then continues the process until the more viable threads of solutions emerge. The process of evaluating an idea in order to determine the problems it generates is turned around to be used as a stimulus for generating further solutions rather than rejecting the initial ideas. The management process of risk analysis, also used in some software development models, is a version of this method to try an sure risks will be adequately considered.

Structure: Having a structure that groups the ideas together in a more meaningful manner helps the creative process by making the holding and recording of ideas a quick process without added cognitive overload. If a structure is evolved that reflects the underlying dimensions of the problem then one can use the structure as a stimulus to creativity. The periodic table of the elements allowed chemists to predict the existence of elements that had not yet been discovered. The checklist developed in the first part of this chapter was intended to supply the same sort of creative stimulus to the interface design process.

Arthur Koestler (Henle, 1962) viewed creativity very much as a structure oriented activity where creativity was the bringing together of two prior unrelated elements in such a way that you get more out of the emergent whole than you have put in. He characterized this view of the creative process as having:

Artistic originality: The "ah!" reaction.

Scientific discovery: The "aha!" reaction.

Comic inspiration: The "haha!" reaction.

The last type usually results when creativity involves two mutually exclusive associative contexts or habitually incompatible frames of reference. Many creative techniques are based upon stimulating people to consider possible relationships by comparing objects or concepts that seem entirely unrelated to one another. Children are often more able to do this than adults because they have not yet been conditioned that certain things are not suppose to go together.

A specific structural approach to creativity is called morphological analysis and was developed by Zwicky (1969). As an example, one can consider a screwdriver as a device that has a handle by which it is grasped, a shank that is used to transfer force from the handle to the bit. Now we try and exhaustively list all possible types of handles, shanks and bits. One may then look at all possible combinations of these to discover if there is a new type of screwdriver that has not yet been created. The explicit procedure is as follows:

Morphological Analysis

1. List the attributes of the situation.

2. Below each attribute, place as many alternatives as you can think of.

3. When completed, make many random runs through the alternatives, picking up a different one from each column and assembling the combinations into entirely new forms of your original subject.

To some, the ability to combine metaphors is an analogous creative process. Most information systems today utilize a combination of metaphors, which is a standard way of guiding the creative process for determining interface functionality.

Roles and Viewpoints: Another approach to creativity is taking on different roles and trying to perceive of the problem from the viewpoint of others rather than yourself. In psychiatry this is known as role playing, in management analysis it becomes "stakeholder" analysis. For designers this the concept of taking on the viewpoint of the user and as a stimulus to that, actually attempting to carryout some of the work that your users do. Becoming a member of a user group and working with them formally is the technique of "participant observation" as employed by the anthropologists. Too often the obstacle to creativity is think about things the way you always have.

Thinking Strategies: It is possible for the individual to conceptualize ideas by first placing himself in a specific mode of thinking about a problem. The following are words that often allow people to adapt different problem solving strategies under various problem situations:

Possible Thinking Strategies

associate	assume	adapt	build up
classify	compare	commit	check
chart	copy	combine	change
cycle	defer	dream	display
diagram	define	eliminate	exemplify
expand	exaggerate	focus	generalize
guess	hypothesize	hold back	imagine
incubate	interpret	leap in	list
memorize	manipulate	organize	purge
question	relate	release	relax
recall	record	retrieve	randomize
search	select	symbolize	stimulate
substitute	systemize	text	transform
translate	understate	vary	verbalize
visualize	work forward	work backward

Typical of the above are the following three specific methods to evolve ideas:

Evolution is the process of migrating an idea.

Synthesis is the merger of different ideas into one.

Analysis is the decomposition of a complex idea into more understandable component ideas.

Synetic training (Gordon, 1961) is a commercialization of the notion that the essence of creativity is joining together different and apparently irrelevant elements. In interface systems the emphasis on analogy and metaphor is another expression of this. An example of a creative analogy made in a person's mind is one such as the dream that Kekule had of a snake swallowing its tail which allowed him to conceive of the benzene molecule as a ring rather than a chain of carbon atoms. Bells’ mental model comparison of the human ear to a machine was the analogy that resulted in the invention of the phone.

Basic mental abilities related to the creative process include:

Ability to concentrate
Accuracy in observation
Retentiveness of memory
Logical reasoning
Judgment
Sensitivity of association
Creative imagination

The classical structure of steps in the creative process are:

Orientation: Identifying and specifying the problem.
Preparation: Gathering pertinent or relevant information.
Analysis: Breaking down the relevant material.
Ideation: Enumerating alternative ideas.
Incubation: Letting the subconscious work on it, mulling it over.
Synthesis: Putting ideas together.
Evaluation: Judging the results.

As in our previous discussion of design, the above list does not imply a fixed order to the elements in this process. The true sequence will be highly iterative and cyclic in either an individual or group process.

Performing evaluation on a spectrum or evaluation scale is more desirable than attempting to classify ideas in a binary manner such as an idea is either good or bad. Ideas should be treated on a relative basis; an idea is better or worse than another idea.

Other ways and techniques that have been suggested for increasing creativity are:

Directing Interest: The formulation of specific needs and goals can serve as a series of stimulus for stirring ideas.

Shaping "filters:" These are the categories or structures used to decide what relevant information to call from memory and to decide on such parameters as the accuracy, scope, flexibility, ambiguity of what is recalled from memory.

Increasing knowledge: Gaining as much insight as possible can stimulate novel approaches. For this reason, it is recommended to understand the current application and gain insights from potential users of the application.

The above approaches imply prior evaluation efforts to gain a very broad understanding of the application, the users, and the organizational context prior to the creative part of the design process.

It is surprisingly easy to forget creative ideas. If we don't record them immediately they can become impossible to recall later. If they are truly novel linkages of concepts it is unlikely that we have encoded them well in our long term memory. Making notes and the use of check lists are both helpful, if not crucial, to the creative process.

Group processes

The concept of the group is that "n heads are better than 1." From the point of view of creativity, it is the concept that different backgrounds, expertise, viewpoints, and psychology provide a mixture that can allow a much richer creation of ideas than one individual alone. This seems to be true when the group is heterogeneous in nature and there are no natural inhibitions such as status and authority differences at work. When the group is too homogenous the commonalty of views may influence premature agreement on a limited number of alternatives.

Groups can develop very creative approaches to problem solving, sometimes without being aware they are doing so. Omar Kayan Moore (??) pointed out that an approach a primitive tribe in New Guinea had to choosing hunting sites was both creative and optimum. They would take the bones of their previous hunt, let them burn and crack in the fire and then throw them on the ground. The pattern they made would guide them to choose where to go to hunt the next day. In essence they had created dice for establishing a random hunting pattern. If they had relied upon their experience then they would have kept going back to the more successful hunting sites and would have exterminated the game in that area. Corporate executives who rely on the idea that the next product should be similar to the last because it was successful may have less sense than these primitives.

It is well known that twosomes can often be more creative with respect to generating ideas than one person alone. The literature on interface design often recommends that at least two individuals be involved in any design effort.

The amount of effort that should be devoted to the creative part of the design can be estimated after a group has had some experience working together on such problems. A relative assessment can be made of:

The complexities involved;
The number of separate factors, constraints, or dimensions to be considered;
The availability of supporting knowledge about the application.

The most popular group oriented approach to creativity goes under the name of "brainstorming. The three principles underlying this concept are:

Ideation can be more productive if criticism is excluded.
The more ideas the better.
Group ideation can be more productive than individual ideation.
Differences of viewpoints should be encouraged.

Conflict between individuals can be a stimulus to creative thought, as long as it is not destructive in nature. The role of devil's advocate should be a respected one in a group design activity. Teammates should, however, refrain from destructive argument. No one should ever be put on the defensive. Make sure everyone gets a chance to participate. Encourage individuals to express the different viewpoints that their experiences can bring to the problem.

When participating in a brainstorming session participants should have the problem explained at least a day before, so they have time to reflect on the problem.

Certain individuals in a group may be considerably more knowledgeable about the problem or a given aspect of it. The role of the expert in a creative group (Prince, 1970) is:

To make obvious that his task is to find useful ideas. Even a little thing like taking notes helps to prove that.
He does not put down the members of the group by using his superior knowledge.
He uses his expertise to help guide the directions the discussion should take.
He is a good listener.
He builds on what is suggested.
He helps promote more understanding about the problem.

In creative groups people with expertise or status need to act more like facilitators and/or good listeners in order to stimulate the free flow of ideas.

Social Inertia and Resistance to change

It has been hypothesized (von Fange, 1959) that one could actually calculate the amount of resistance to change that people or an organization will exhibit. That the appropriate unit for measuring resistance is the amount of time it takes to introduce the change.

T (years) = K (pride constant) * H (habit) * C(change) * sin(alpha)

The angle "alpha" is the angle between current way of doing things (habit) and the new creative alternative (change). It is certainly true that Information Systems introduce new ways of accomplishing the tasks that users have. The way a computer can accomplish a task for the user may result in improved performance. However, the greater the departure from the way the user has been doing the task in the past, the more difficult can be the introduction of new approaches. Kean (1981) pointed out that sometimes the resistance can be so great that the introduction of an Information System can be analogous to launching organizational wide warfare.

There are a great many experiments in the literature on information systems which show that the uncomfortable feelings that people have with new approaches often influence their judgment on the performance of their task. Often users are under the impression that they have done their task worse even when they did it just as well or better (Dickson, et. al., ??). The classic "Minnesota" experiments on the use of summary verses raw data to make management type decisions is one of the earliest examples.

Clearly the introduction of creative alternatives carries the burden of having to overcome potential resistance on the part of the user community. The single most important factor that has been demonstrated to significantly overcome this resistance is the involvement of the users in the design process and even in the creation part of the design process. Both protocol analysis (next chapter) and the use of focus type groups (evaluation section) have been typical approaches to this.

Another key element in negating resistance is the building of trust for the developers of the systems by the users. Each successful design builds that much more added trust and willingness on the part of the user to spend the time necessary to provide insights useful to the design process. Designers need to face up to user resistance, investigate it, and confront it as part of the design process.

Conclusion

Relationships and Hypertext

The approach we have presented in this chapter is closely related to Zwicky (1969) original concept of morphological analysis. It alleviates a great deal of cognitive overhead on the part of the designer so that they concentrate on idea generation. If they have learned the classification scheme it allows them to file ideas as rapidly as they occur without interfering with the train of thought devoted to idea generation. The structure itself points to the designer to what might be areas where related ideas can be generated by the obvious links that exist between these elements. In fact the morphology is actually a form of a Hypertext template for the design process (Balasubramanian and Turoff, 1975, 1978)

Hypertext network of user interface design tasks.

The relationships and their meanings will be discussed more fully as an example in the chapter covering advanced applications such as Hypertext. For the beginning designer and student the fact that any design task (node) above can trigger a relationship to any other node can make the process difficult to at first understand. Understanding comes with practice on different designs. However, there is an obvious level structure from the most general (higher level) concepts) to the most specific (lower level) concepts. The beginner should normally start with a high level item and work from it in any direction they wish till they run out of steam. If ideas are short than generally working down to a lower level indicated by the relationships is usually the most productive approach.

Just as morphological analysis intended the designer can take, for example, the list of objects and the list of actions and look at each possible combination that has not yet been made explicit and consider whether their should be. The same holds true for also comparing other element types with one another. Further situations like objects that are not linked to any actions immediately generate the need for thought and idea. For a rich system we are talking about many hundreds of elements in the morphology in terms of nodes and links. A general to detailed level structure to use in guiding ones way through the morphology follows.

                       LEVEL STRUCTURE

GENERAL                     SPECIFIC                     DETAIL

     Goals

                                  User Tasks

     Metaphors

     Objects

                                  Heading

                                  Abstract

                                                              Object parts

                                                              Sub-objects

     Actions

                                  Generic

                                                              Explicit

                                                              Controls

                                  Strategic Choice Sets

                                                              Reactive Choice Sets

                                  Modifiers

                                                              Object Lists and Sets

                                  Links

                                  Shared Processes

                                                              Searching

                                                              List Processing

                                  Lateral Linkages

                                  Interaction States

                                                              Error Conditions

                                                              Necessary Help

                                                              System Messages

                                                              Formats

                                  Screen Layouts

                                                              Workspace

                                                              Status area

                                                              Control area

                                                              System Message area

While it is common to teach top down design for software, that direction is not necessary in this form of design and one can work bottom up or sideways. In the idea generation phase the designer should follow any idea that is stimulated by his or her current position in the structure no matter what direction it leads. Evaluation can be done later and should be held off. One should not get side tracked in this phase to trying to immediately resolve conflicting ideas that may have occurred. What is true is that design is a very iterative process. In the design of a Hypertext composition system to support this process, the system should track the sequence by which elements are created so that the designer can go back and review his or her original thought process. In fact the resulting design may be more understandable to others if they are able to review the creation process.

The Software Development Life Cycle

The process we have described in this chapter has a very specific role in the Software Development Life Cycle (SDLC). A number of researchers have reported on methodologies to engineer the software design and development process as a whole (Humphrey, 1989; Jacobson & Jacobson, 1995). However, only recently have researchers started looking into structuring the user interface design process (Preece, et al., 1994), in particular. This morphological approach fits right in between the Requirements Analysis phase and System Design phase in the Software Development Life Cycle (SDLC) shown in the following figure. Our proposed design methodology applies to the planning and idea generation phase. Use of this methodology during the user interface design phase of the SDLC provides valuable feedback to the Requirements Analysis phase to better understand system requirements. Whereas prototyping has long been recognized as a useful technique to elicit user requirements, this approach during the early stages of design further reduces the risk of an a priori requirements list. We also believe that this will also reduce the "aimless" prototyping that often occurs in many system development efforts.

Note that the figure is a simplistic view of the SDLC. Our intention here is not to discuss the merits and de-merits of various forms of the SDLC such as waterfall, spiral, incremental, iterative, etc. Suffice it to say that we prefer iterative development which includes prototyping in order to augment the requirements analysis phase already carried out through traditional means. We consider the actual and final implementation of the user interface as a key initial component and an integral part of the development phase during the SDLC. We are very much in agreement with views in the literature (Carroll, 1982) that most of the interface should be designed in detail before the design of the implementation model is completed and certainly before a single line of code is written.

The User Interface Design Process within the context of the Software Development Life Cycle.

User Interface Design Phases	Simon’s Phases of Problem Solving	Foley’s Design Stages	Olson & Moran’s Design Stages	Couger’s Creative Problem-Solving Methodology
Planning and Idea Generation	Intelligence	Pre-design	Define problem; Generate design; Reflect on the design		Problem Definition; Compiling Information; Generating Ideas
Prototyping and Design	Design	Design	Building
Evaluation	Choice	Review and Fine Tuning	Testing		Evaluating & Prioritizing Ideas
Implementation not explicit till development phase	Execution of choice not explicit	Implementation	Deploying		Developing Implementation Plan

The user interface design process compared to other problem solving approaches.

The three phases of the user interface design process can be compared to a number of problem-solving techniques proposed by other researchers. The table below (Balasubramanian, V., Ullman, D., and Turoff, M., 1998) compares the user interface design process to Simon’s model (1960) of problem solving or decision making, Foley’s (1984) five stages of the design process, the seven design activities by Olson and Moran (1996), and the five phases of the creative problem-solving methodology by Couger (1995).

User interface design requires a judicious mixture of creativity, design knowledge, experience, task analysis and a thorough understanding of user and organizational behavior. The approach we have developed in this chapter should be linked to the process of gathering requirements and should be integrated with it. One can view this morphology an underlying group communication structure to organize the discussion on requirements between the design group and the user group in the development of a system. It only remains to link in a tool to automate the mock up of the interface based upon the specifications recorded in the discussion. This would allow the users to visualize the results of their inputs and the refinements and understandings made by the designers. This would swiftly remove the many ambiguities and uncertainties about specifics that now plague most such efforts.

Assignments

1. Design an interactive system interface to support your own design process for the assignments in this course. An initial approach is a data base to reflect the structures defined in this chapter.

2. Design a personal finance tracking system for checks, bills, and associated tax items.

3. Design a system for a professional writer to keep track of reference material different types. You might consider a historian or technical writer as a starting point model of your user.

4. Design an interface for an electronic book. What lateral connections can you introduce that are already not part of the mental model a user has of a book?

5. Define just the objects and their formats in any of the above applications.

6. Can you devise a standard set of controls that would apply across all the three above applications?

7. Design a general purpose list processing capability that could be utilized in a wide variety of applications. Consider a simplified and more sophisticated version of the same system.

8. What would be the make up of a creative design group for doing a specific application (you and/or your instructor should pick a specific application)? Consider different dimensions such as experience, expertise, psychology, etc.

9. What would you suggest as a schedule for the creative part of a design in terms of individual efforts, group efforts, and overall length of time passing? Consider this for the same application(s) chosen above.

10. Develop the table of contents for this book a decade from now. As a class compare and discuss the differences in each individual's contribution.

11. Identify some examples of personal creativity in solving problems during your education. It is very likely you remember those that were startling insights you had.

12. What sort of typical reactions can you expect to application functionality that presents the user entirely new ways of accomplishing his or her task? Under what circumstances are the reactions likely to be more negative or more positive? How can you overcome the negative reactions?

13. How can one tell when to terminate the creative process and move into a mode of evaluation and the development of the details?

14. Consider all possible forms of capturing data (e.g., paper, digital, film, etc.). Now make a matrix of these forms of data capturing or storing data with itself. What types of devices allow one to transform data from one form to another? To what extent are their devices that fit in more than one cell and can one hypothesize devices that would be significant new products in this area if they did exist. This exercise illustrates the use of morphological analysis to aid to stimulate ideas.

References

Ackoff, R. L., (1967), Management Misinformation Systems, Management Science, 14, December, 147-156.

Adams, James L. (1976), Conceptual Block busting: A pleasurable Guide to Better Problem Solving, San Francisco Book Company, CA.

Arieti, Silvano, (1976), Creativity: The Magic Synthesis, Basic Books, Inc., NY.

Balasubramanian, V., and Turoff, M. (1995). A Systematic Approach to User Interface Design for Hypertext Systems, Proceedings of the 28th Annual Hawaii International Conference on System Sciences (HICSS `95), Maui, Volume III, 241-250.

Balasubramanian, V., Ullman, D., and Turoff, M., 1998, A Systematic Approach to Support the Creative Phases of the User Interface Design Process, Proceedings 32^nd HICSS, January, Hawaii.

Bertalanffy, L. von, (1968), General Systems Theory, Braziller, NY.

Bruner, Jerome S., (1962), The conditions of creativity, in Contemporary Approaches to Creative Thinking, editors: H. Ruber, G. Terrell, M. Wertheimer, Prentice Hall.

Card, Newell & Moran, (1982), Human-Computer Interaction, Erlbaum Publishers.

Carroll, J. M., and Mack, R. M. (1985). Metaphor, computing systems, and active learning, International Journal of Man-Machine Studies, 22, 39-57.

Carroll, J. M., and Thomas, J. C. (1982). Metaphor and the Cognitive Representation of Computing Systems, IEEE Transactions on Systems, Man, and Cybernetics, Vol. SMC-12, 2, 107-116.

Carroll, J. M., (1989), Evaluation, Description and Invention: Paradigms for Human-Computer Interaction, in M. C. Yovits, ed., Advances in Computers, (29), Academic Press, New York.

Cherry, Colin, (1966), On Human Communication, MIT Press.

Christie, B., (1981), Face to File Communication: A Psychological Approach to Information Systems, John Wiley.

Coombs, M. J., & Alty, J. L., (1981), Computing Skills and the User Interface, Academic Press.

Couger, J. D. (1995). Creative Problem Solving and Opportunity Finding, Boyd & Fraser Publishing Company.

Foley, J. D. (1984). Managing the Design of User-Computer Interfaces, Computer Graphics ‘84, National Computer Graphics Association Conference Proceedings, Vol. 2, 436-451.

Gehani, N. H., (1982), The Potential of Forms in Office Automation, IEEE Transactions on Communications, com-30(1), January, 120-125.

Gehani, Marain H., (1982), High Level Form Definition in Office Information Systems, The Computer Journal, 25(1), 52-58.

Gomaa, H. (1990). The Impact of Prototyping on Software System Engineering, IEEE Computer, 543-552.

Goodwin, Nancy C., (1987), Functionality and Usability, Communications of the ACM, 30(3), March, 229-233.

Gordon, W. J. J., (1961), Synectics: The development of Creative Capacity, Harper and Row, NY.

Guilford, J. P. (1959), Traits of Creativity, in Anderson, H. H. (ed.), Creativity and it's Cultivation, Harper and Row, NY.

Henderson, & Nutt, (1980), The Influence of Decision Style on Decision Making Behavior, Management Science, 26(4), April.

Henle, Mary, (1962), The Birth and Death of Ideas, in Contemporary Approaches to Creative Thinking, editors: H. Ruber, G. Terrell, M. Wertheimer, Prentice Hall.

Humphrey, W. S. (1989). Managing the Software Process, Addison-Wesley Publishing Company.

Jacobson, I., and Jacobson, S. (1995). Series of articles on the Software Engineering Process, Object Magazine, January, March, June, and September 1995.

Keen, Peter, (1981), Information Systems and Organizational Change, Communications of the ACM, 24(1), January.

Lindblom, Charles E., (1959), The Science of Muddling Through, Public Administration Review, 19(2), Spring.

Lowe, David, (1985), Cooperative Structuring of Information: The Representation of Reasoning and Debate, Journal of Man-Machine Studies, 23(1), July, 97-111.

Lucas, & Nielsen, (1980), Impact of the mode of Information Presentation on Learning and Performance, Management Science, 26(10), October.

Martin, James, (1973), Design of Man-Computer Dialogues, Prentice Hall.

Mehlmann, Marilyn, (1981), When People Use Computers: An approach to Developing an Interface, Prentice-Hall, Inc. Englewood Cliffs, NJ.

Molich, Rolf, & Nielsen, Jakob, (1990), Improving a Human-Computer Dialogue, Communications of the ACM, 33(3), March, 338-348.

Oettinger, Anthony, (1965), Linguistic Problems of Man-Computer Interaction IBM Scientific Computing Symposium on Man-Machine Communication, IBM Publisher.

Olson J.S., and Moran, T.P. (1996). Mapping the Method Muddle: Guidance in Using Methods for User Interface Design, in Human-Computer Interface Design (eds.), Rudisill, M., Lewis, C., Polson, P.B., and McKay, T.D., Morgan Kaufmann Publishers, Inc., 269-300.

Orr, William, 1968, Conversational Computers, John Wiley.

Osborn, Alex. F., (1957), Applied Imagination: Principles and Procedures of Creative Thinking, Charles Schrbner's Sons, NY.

Preece, J., Rogers, Y., Sharp, H., Benyon, D., Holland, S., and Carey, T. (1994). Human-Computer Interaction, Addison-Wesley Publishing Company.

Prince, George M., (1970), The Practice of Creativity: A manual for dynamic group problem solving, Harper & Row, NY.

Rouse, William, (1975), Design of Man-Computer Interfaces for on-line Interactive Systems, Proceedings of the IEEE, 63(6), June.

Shackel, B., (1981), Man-Computer Interaction: Human Factors Aspects of Computers & People, Suthoff & Noordhoff.

Shneiderman, Ben, (1980), Software Psychology: Human Factors in Computer and Information Systems, Winthrop Publishers.

Simon, H. A. (1960). The New Science of Management Decision, Harper & Brothers, New York.

Taggart, W. M. Jr., & Carlis, J. V., (1977), A Survey of Information Requirements Analysis Techniques, Computer Surveys, 9(4), December, 273-290.

Von Fange, Eugen K., (1959), Professional Creativity, Prentice Hall, Englewood Cliffs, NJ.

Zwicky, Fritz, Discovery, Invention, Research (New York: Macmillan), 1969.