Using HyperText to Create Design Programming Databases

Using HyperText to Create Design Programming Databases

Duncan Case, Ph.D. Abstract

A recent information technology innovation that holds particular promise for use in design problem solving is HyperText. Within the context of a course on design methods, HyperText was used to create a programming database for an elderly retirement community. In this course students learned techniques and methods for collecting, analyzing, and synthesizing design information into a database of design guidelines. HyperText was used to assist in this process and to create an electronic programming notebook. Two strategies were employed for incorporating HyperText into the course, one that “automated’ the creation of the database, and another that gave substantial “computer programming” responsibility to the student. Only the latter approach worked. This paper reports the results of this experience, illustrates different ways HyperText can be applied to design program databases, and examines different instructional strategies for incorporating HyperText into a course on design methods.

Indiana University Bloomington, Indiana

Rationale: Design Methods, The Computer, and HyperText

Courses in design methods are relatively new to most design cumc- ula. They are part of an effort to for- malize instruction on the design process, augmenting the often intuitive

designers. Design methods are intended to increase the likelihood that

@Copyright, 1990, Interior Design Educators upon by Council, Journal of interior Design Education and Research 16 (1): 37-52.

there will be a better fit between user needs and built form (Alexander, 1964; Jones, 1972). Programming research in particular is intended to supplement the sometimes incom- plete or inaccurate assumptions held by designers about their users.

Design methodologists seek to achieve these improvements by making explicit the way designers use information. The result is a formal- ized design process, one in which specific information needs and methods are associated with specific steps in design problem-solving.’ For each stage in the design process, design methods can be identified to assist in determining what information is needed, where and how to get that information, how to analyze it, and how to translate or synthesize it for, use in a succeeding stage.

The common link between design methods and computer technology is the organizing and processing of information. Design methods are, at heart, techniques for information processing. Computers can be used to process information beyond the limits of the human mind. As it has for other information-based disci- plines, the computer and information technology have extended the capabilities of design methods. Tradi- tional areas of application include survey research data collection and analysis and three-dimensional mod- eling. Computers have also been used to examine relationships between sets of design requirements, grouping them into compatible clus- ters (Alexander & Chermayeff, 1963).

HyperText is a relatively new information technology with promising

37

Figure 1 Illustration of Hypeffext Interconnectivity Capabilities for Organizing A Design Guideline Database (Author)

applications for design methods. HyperText has the capability of crest- ing interdependent relationships within an information set. HyperText allows one to connect information from one part of a document with information located in another part of the same document. It is even possible to make links between documents. The “link” is electronic and is activated by pointing or clicking on a computer screen. Fundamental examples are footnotes and bibliographic references. When reading a HyperText document, it is not necessary to “look up” a footnote or a reference. A user points to the citation and the note or complete reference 38

appears superimposed on the screen. A more sophisticated use of Hy-

perText is to have the referenced work itself brought to the screen. Theoretically, it is possible to have the entire contents of a library placed on the computer with all documents electronically linked to one another? Whether viewing a footnote, a card catalog, or a bibliographic citation, the user can immediately access the referenced material with a click on his or her screen. Since graphics and sound can also be included in a Hy- perText document, art. design, music and video are as easily incorporated as text?

HyperText is of particular value to

design because design information is best urganized in an interdependent manner. The designer’s task is to divine patterns of relationship among human activities. These patterns must allow for accessibility among certain activities and separation from others. A mere listing of design guidelines, though useful, is not as helpful as ones that have already built into them inclusive and exclusive linkages. HyperText offers this pos- sibility. Design criteria databases, both text and graphics, can be organized electronically to reflect the functional relationships that ultimately must be accommodated in space and form. Figure 1 on handicapper acces-

sibility shows a simple example of how HyperText could be used to display this interdependence among related design ideas.

Because of the potential of this new information technology, Hy- perText was incorporated into a course on design methods. With sup port from a University Instructional Development Grant? this effort was undertaken in the Fall of 1988 with a class of 32 third-year interior design students. The focus of the course was programmatic research for an elderly retirement community. Students learned techniques and methods for collecting, analyzing, and synthesizing design information into a database of design guidelines. They also learned how to program HyperCard, a version of HyperText that runs on the Apple Macintosh. Using HyperCard, students converted their program databases into an electronic notebook. Two different strategies were employed for incorporating HyperText into the course, one that “automated” the creation of the database, and another that gave substantial “computer programming” responsibility to the student. This paper reports on the relative merits of these two approaches as well as ways HyperText can be used to create design programming databases.

Using HyperText to Collect, Analyze, and Synthesize Design Programming Information

Course Context A “design firm” scenario was used

as the context for teaching design methods and introducing the use of HyperText. Students playing the role of new employees were assigned to four-person teams. They were charged with conducting program: matic research for a new project, an elderly retirement community. The resulting program was to be placed on the firm’s con~puter.~ An early pioneer in CADD, the firm wished to keep up-toAdate with computer technology. The firm expected to realize similar productivity gains in comput- erizing program information as they had with CADD by eliminating the

need to reinvent or re-research an idea that was found to work in previ- ous design projects. HyperText was the application program the firm settled on for implementing this new objective.

Course instructional content was inserted into this scenario. “Events” were scheduled that roughly approxi- mated “steps in the design process.” Each event required completion of a task that acquainted students with an appropriate method for that step in the design process. The results of these efforts were documented in the form of office reports, memoranda, and staff meeting presentations. Such activities _took the place of conven- tional class exercises. Data generated from these activities became input for the initial application of HyperText in the course.

Incorporating HyperText Hypeflext was integrated into the

course by creating a program that “semiautomated” the processing of design programming information. This program, called “Programming Tools,” recorded data findings, trans- formed these findings into design criteria, and assembled the results into a programming notebook.6 “Program- ming Tools” consists of four interre- lated application programs: Note Card, Design Notes, Program Sum- mary, and Program Notebook. Illus- trations from each are shown in Fig- ure 2. A student enters his or her research information through the Note Card program. The example shown is of data obtained from a literature search. The usual note card categories are present (subject heading, reference citation, and notes) as well as some unique features that take advantage of the computer’s capabilities. These include a “find” and “sort” routine. Also included is an “electronic drawing board” hidden behind the “notes” text field.

The most sophisticated feature of the electronic note card is its ability to “export” data to another note card set known as Design Notes. In the lower right of each note card is a place for translating research notes into design criteria (design implications). This information can be electronically transferred to the Design Notes program. This program shares many of

the features of the original Note Card program (sort, find, graphic). Its unique HyperText feature is an electronic link back to the original note card on which each design note card is based. It may be accessed by sim- ply clicking on the word “Source” on each card.

The third application program, Program Summary, aggregates design criteria by common space or area. It does this by “importing” design criteria from Design Notes according to pre-specified categories (e.g., common “activity” and/or “location” and/ or “user”). All criteria found are placed in a common scrolling field in Program Sqmmary. For example, the dining room summary card would list the design criteria found on all the design notes cards with the words “dining room” or “dining” listed on them. The student then chooses from among these the five most important criteria. These are known as the summary criteria; from these a “Summary Graphic” is created. Like the Note Card and Design Notes programs, an electronic drawing board is hidden behind the text for this purpose. It is also possible to prepare a summary profile of the space, giving an overview of its use and user(s). The resulting format is modeled after an early “pattern language” format developed by Alexander and Cher- mayeff (1963). The fourth application program “Animated Summary,” demonstrates how to make “animations” from the Program Summary application.

The intended outcome of this information collection and aggregation is the creation of a composite “programming notebook.” It is shown as the last illustration in Figure 2. Tabs on the bottom edge of the notebook provide electronic links to its contents. For example, clicking on “site,” “community facilities,” or “dwelling units” takes the reader to design criteria related to that design component. Other sections of the notebook provide information developed at earlier programming stages, such as a “client profile.”

Implementation Problems Despite the logical appeal of this

initial strategy, a number of factors worked against its successful im-

39

Figure 2 HyperCard ‘‘Programming Tools” Applications (Author)

plementation. The major problem was conceptual: students failed to grasp the HyperText concept and hence its justification for use in the course. The application program Programming Tools was a significant source of confusion. Written in Hy- percard, this program simulated both HyperText and nonHyperText applications, obscuring the HyperText concept. Further, Hypercard is not a pure HyperText program. It’s au- 40

thors envisioned it as, an all-purpose application program, first, and as a HyperText application, second. Since the pure HyperText qualities of Hypercard were not to be demonstrated until later in the course, this confusion was likely to continue for some time unless an immediate ad- justment was made. The initial action taken was to suspend further use of the Programming Tools program, resorting to traditional paper and

pencil approaches to processing design information.

An Alternative Approach: Explaining the HyperText Concept and Justifying its Applicability to Design Programming

In considering a new strategy for the course, it was apparent that an

explanation and demonstration of the Hypeffext concept was the fmt order of business. This would be followed by justifying the use of HyperText in design programming. This latter task was addressed by the introduction of three complimentary ideas: 1) design methods as tools for finding “paths” through information; 2) HyperText and print material as alternative media for “structuring” paths through information; and 3) HyperText as a superior medium for organizing design programming information. It was also considered important that students learn to program Hypercard for themselves. Having suspended use of the semiautomated application program, Programming Tools, students were now responsible for crest- ing their own HyperText program notebooks?

Focusing On The HyperText Concept

To introduce the HyperText concept, an exemplary program was demonstrated, Znigo the Car, a children’s story written by Amanda Goodenough (1987).8 Selecting from on-screen picture cues (the story has no text) the reader leads Inigo on an adventure. Alternative adventures are possible as screens often provide multiple choices. Figure 3 shows an example from this program. Students learned from this that HyperText is interactive (user responsive) and interdependent (allows multiple choices or relationships). They also learned that Hypeffext could be both graphic and text based. Asked to consider whether the story could have been written as a book (to which most re- plied no), students began to realize that HyperText possessed properties uniquely different from print media.

With their interest aroused, students were then provided with a more traditional explanation of HyperText, i.e., the ability to link footnotes and bibliographic citations electronically to the text of a document, instantane- ously accessible by clicking or pointing. This example was supplemented with readings about HyperText by noted pioneers in the field: Vannevar Bush (“AS We May Think,” 1945) and Ted Nelson (Literary Machines, 1987). With this initial background, students began to receive instruction

on how to program Hypercard for themselves.

Design Methods as Tools for Finding “Paths” through Information

Since the main topic of the course was design methods and programming research, it was important to show students how these ideas related to HyperText. A conceptual link was sought among information use, design problem solving, and information technology. The solution was a metaphor that likened the use of information for solving design problems to “designing paths through knowledge.” This metaphor sub- sumes three related metaphors:

1. Locating information to solve design problems was likened to “designing paths of inquiry .” (Methods for acquiring information were explained as information “pathfinding” techniques. These included the use of reference bibliographies, card catalogs, books, jour- nals, and articles.)

2. Keeping accurate mords of references and methods used in collecting information was likened to “docu- menting paths of discovery.”

3. Organizing results into an overall report, or in this case, a programming document, was likened to “designing paths of delivery.”

Successful utilization of information for designing would depend on how well the paths for discovery, docu- mentation, and delivery were defined.

Extending this path analogy to HyperText was relatively easy since its underlying principle is the creation of “links” between information pieces. Following these links is like following paths. To demonstrate that this path analogy was valid for both HyperText information and printed information (books, articles), students were given exercises for discovering these paths. Provided with a printout of the screens for “Inigo Gets Out,” students were asked to “map” all the possible adventures. Multiple paths were possible, but because the stories were interconnected, the resulting

41

“map” took the form of a “network diagram” diverging and converging from several common nodes. Similar mapping exercises were conducted for print media (e.g., novels, dictionaries, telephone books,- thesaurus, and university course catalogs) with similar results: path-like maps. Addition- ally, students recognized that finding paths through print media depended on recognizing path markers: indices, footnotes, cross references, and key words.

Comparing Information Structure of Print and HyperText-based Documents

This demonstration of paths through knowledge served as a lead- in to the general question of how information is organized. Students were asked to examine the maps they had created to see if they could find any patterns. They discovered that there were two general forms of in-

formation organization, linear and nonlinear. Linear information is accessed sequentially, sentence by sentence, page by page. Its “map” is a straight line, hence the label “linear.” Common examples are storybooks and novels. Nonlinear information is accessed by selective jumping and skipping between different information topics. Its map is a “network diagram.” Common examples are reference works like dictionaries and university catalogs. Both forms were found to exist in print and HyperText media. However, print versions of nonlinear information depended on elaborate and detailed cross-referenc- ing systems like section-tabs, indices, and footnotes.

To determine which “media” was better for the two types of information structure, students were given two new exercises. The first was to create a computer “book” version of the children’s story, Inigo the Cat (Goodenough, 1987). The second

was to simulate HyperText versions of “print”-based reference materials. The charm, flow, and adventure of the original “Inigo” storyline was all but destroyed by the artifice of tabs and footnotes necessary for creating its “printed” equivalent. On the other hand, the cumbersome task of jumping and skipping in “print” versions of reference works became effortless and quick when envisioned as a Hy- perText document. Students began to see that perhaps there were some real advantages to be gained in using HyperText to organize nonlinear information. It was concluded that books were effective for linear information but that ByperText was a superior medium for nonlinear information. In HyperText, merely clicking on an index item or text reference would instantly take you to information located elsewhere in the document, eliminating the need to deci- pher tab titles or keywords to locate what one wanted to know.

Figure 3 Path Choices h “Inigo Gets Out” (Amanda Goodenough, modified by Author)

42

Justifying Use of HyperText to Create a Programming Notebook

Having demonstrated that Hy- perText is a superior medium for pre- senting nonlinear information, discus- sion turned to consideration of its suitability for conveying design information. Since structure was found important in selecting a medium, students examined the structure of design information. “Maps” were drawn of design guideline references, such as A Pattern Language (Alexan- der, Ishikawa, & Silverstein, 1977). The tell-tale “network diagram” appeared, indicating nonlinear organization. As further evidence of the nonlinear strudure of design information. students compared these diagrams with the “bubble” or “functional diagram.’’ familiar tools from studio. They found a striking similarity. Recognizing the inherent nonlinear property of design information, students could now see that HyperText was an appropriate medium for their term projects. Class attention now turned to ways of using HyperText to create a programming notebook.

The HyperText Programming Notebook

Development of the HyperText programming notebook was done in two stages. The first used an easily understood note card format to ensure student mastery. The second chal- lenged students to revise this initial format into one that best demonstrated the HyperText context.

Stage One: The Note Cqrd Notebook

As part of the switch in strategies, the initial design firm scenario was dropped and with it the four-person project teams. The class now worked as a whole to complete the elderly retirement community project. The project was divided up into 32 different areas, one for each student in the class. The first step in creating the programming notebook involved each student developing design criteria for their assigned activity area. These design criteria were based on the research information each student

collected during the semester. The resulting criteria were placed into a Hypercard document using a note card format. Figure 4 shows an example of this format for a residential entry area. The note card format was adopted because it was easy to com- prehend and because it is the native format of Hypercard (which explains why “card” is included as part of its name).

These compilations of design criteria for individual spaces or activity areas are called “Individual Criteria” documents. Note that the total set of criteria for one space is divided up among several cards by common functional properties, i.e., lighting, storage, accessibility. These functional categories are the same for all Individual Criteria documents. Movement among cards within a given document is via “tabs” or “buttons” placed at the bottom of each card. These tabs correspond to common functional properties. For example, if an individual wished to get to “security” criteria from “accessibility” criteria they “clicked” on the “security” tab at the bottom of the card.

To get between documents, that is from one program area to another, tabs are provided at the top of cards. Clicking on one of the three level categories - Site, Building, or Dwelling - provides you with a directory listing of the spaces for the selected category. The second screen in Figure 4 shows this directory for dwelling spaces. Selecting a space from this list takes one to the corre- sponding “individual criteria” document. For example, clicking on the first item, “Dwelling Fmtry” takes you to the initial card illustrated in Figure 4.

Thirty-two of these documents were created, one by each student in the course. While relatively complete, these documents are ponderous to use. There is no prioritization of criteria and no description of intended space use. The reader is confronted with an undifferentiated list of criteria. To handle this problem, each student summarized their criteria, identifying the five most important or critical problems a designer should

43

Figure 4 “Note Card” Format Hypeflext Programming Notebook: Individual Criteria, Directory, and Summary Criteria Cards (Author)

know. These are supplemented with a written profile of the space and a summary pattern language. This document is known as the “Summary Criteria” document. The remaining four screens from Figure 4 are Sum- mary Criteria cards. The cards shown am for the same residential entry described in the Individual Criteria cards. Note that in addition to the five summary criteria there is a “profile” of users, activities, and purposes

of the space as well as a functional diagram of its relationship to other areas. Pattern languages are developed to graphically illustrate these summary design criteria. Movement within and among the Summary Cri- teria documents is similar to the ar- rangement of buttons and tabs used with Individual Criteria. These thirty-two sets of Individual and Summary criteria became the initial programming notebook for the class.

Stage Two: Revising the Programming Notebook into a Purer “H yperText” Format

Exploring Alternative HyperText Formats. Though the class suc- ceeded in creating a programming notebook using Hypercard, its reli- ance on a note card format was not a sophisticated application of the Hy- perText concept. Similar in use and appearance to a “printed” equivalent, this use of HyperText offered little

44

comparative advantage over a real note card-based notebook. The challenge now placed before the students was to revise the format of their notebook into one that better demonstrated the HyperText concept.

The students examined three examples of good HyperText documents. They were asked to identify the methods each used to present information to see if they could extract principles or ideas applicable to their programming notebooks. Three HyperText documents were reviewed: “Inigo The Cat”, “The Neuro Tour”? and “Context 32”.”

In “Inigo The Cat” the viewer chooses from several different story lines. Placed in Inigo’s shoes, s h e must divine what “path” to investigate next. As there are no words, the cue’s are entirely visual (Figure 3). One of the compelling qualities of “Inigo” is that each screen invites your curiosity to explore something new. Different readers can experience different adventures, depending on what peaks their curiosity.

The second example, “The Neuro Tour,” shares many similarities with “Inigo.” “The Neuro Tour” is a tutorial about the brain’s neurological structure. Like “Inigo” it is nonver- bal, using strategically designed screens to maintain interest. The opening screen is a profile of the human head. When clicked on, the screen dissolves into a brain, darkens, and then zooms down to the level of a single neuron. The neuron illustration has labels on important features. Selection of these items results in an even more detailed close-up where more structures are identified. A scrolling text appears describing what is seen on the screen and how it works. How much of this information is explored is up to the individual. Figure 5 shows representative screens from “The Neuro Tour.”

The final example reviewed, “Context 32,” provides a different approach to creating HyperText documents. “Context 32” is a Hyper- Card prototype of a much larger HyperText database developed at Brown University for an undergradu- ate course in English Literature.” This program presents students with “profiles” of major English literary

Figure 5 Zoom Sequence from “The Neuro Tour” (Jim Ludtke)

45

Figure 6 Context Diagram from “Context 32” (N. Yankelovitch)

figures. Through exploratory questions strategically inserted into short essays about these figures, students are encouraged to explore “contex- tual’’ factors that influenced the author’s literary thought, e.g., the works of other contemporary figures, contemporary historical events, paral- lel developments in the visual arts. One can even investigate interrelationships among the author’s own works. Clicking on these questions takes one to an appropriate “contex- tual” essay. Examples from “Context 32” are shown in Figure 6.

The intent of the “Context 32” format is to teach students how schol- ars research ideas, i.e., by asking questions about interrelationships and context. This approach is referred to as the “scholarly inquiry” format (Yankelovich, Landow, & Cody, 1987). me advantage of using Hy- perText for this strategy is that the laborious process of physically finding one’s way from original document footnotes, to card catalog, to interlibrary loan, etc., is supplanted by instant electronic links.

From “Context 32,” students in the design methods course discovered that HyperText paths can be more “open-ended” than those found in “Inigo’, and “The Neuro Tour.” While “Inigo” and ‘”’he Neuro Tour” provided path alternatives, they are structured and limited. “Inigo” and “The Neuro Tour” follow what is known as the “tutorial model” of instruction (Siege1 & Davis, 1986).

The tutorial model is best used when the instructional objective is to com- municate (or teach) a delimited set of information and ideas. The “Context 32” format, the “scholarly inquiry model,” is most useful when it is important to give the user/reader control over what is to be explored or learned. It is possible, however, to have both formats coexist within the same material.

From these three examples, students extracted four principles which could be applied to their programming notebooks:

1. Involve the user in creating or discovering a path through the document.

2. Makepaths inviting, give them storylines.

3. Provide visual, non-verbal cues to path options.

4. Provide different paths for different types of users: a) well defined tutorial

paths for those seeking guidance.

those exploring ideas. In thinking about the purpose of a

programming notebook, the class concluded that a tutorial and a scholarly inquiry format would both be desirable. On the one hand, it would be important that schematic designers be exposed to the most critical design criteria, thereby justifying use of a tutorial format. On the other hand, as more detailed questions arise and as users become more familiar with the

b) openendedpathsfor

document, the designer needs to review or explore specific ideas in more detail, justifying the desirability of an open inquiry format.

With these insights, students un- dertook the task of revising their programming notebooks. Each student wrote a tutorial, inviting and instruc- tive to users, for the space(s) they were assigned. They then connected them to the Individual Criteria and Summary Criteria fdes of the original note card format notebook. The big- gest challenge was to find a way to tie all this information together into a comprehensive document. A subset of students volunteered to investigate how this might be done using Hy- perText.”

The Student-Generated Solutions. The resulting Hypeffext document is best explained in terms of how it appears to a user. Though the individual tutorial modules were created first afid the overall organizing structure last, presentation of the composite class document is in reverse order to its development.

The students who worked on the overall structure of the programming notebook were most influenced by “The Neuro Tour” project. Using site plans and floor plans, they created a series of “zoom” sequences to take the user to selected spaces or activity areas. Figure 7 shows a typical screen sequence. The first screen shows the site view of a hypothetical retirement community including roadways, parking, the community

46

building, and residential buildings. Clicking anywhere on this screen produces a zoom into the core elements. Clicking on one of these core elements results in a further zoom to a floor or sire plan. The example shown in Figure 7, a residential floor plan, is the result of clicking on the “residence” element. Selecting one of the spaces from this floor plan

takes a user to a tutorial on that space. Figure 8 shows sequences from a

tutorial about bedroom design criteria. At the end of the tutorial the user may repeat the tutorial, view a detailed listing of design criteria for this space, or return to the residential floor plan. It is also possible to take a tutorial of the dwelling facilities as a whole. This is done by clicking on

the “tour” button found at the right of the residential floor plan screen (Fig- ure 7).

Also at the right of the floor plan screens are the essential navigation tools for moving about the programming notebook. There are four other essential icons: a “return” button, an “info” button, a “central directory” button, and a “?” button. The return

Figure 7 Opening Sequences for Hypeffext Prcgramming Database for an Elderly Retirement Community Created by Student Lew Neuman, Fall 1988.

47

Figure 8 Bedroom Tutorial by Student Kathy Skimos, Fall 1988.

button, which appears at every junc- ture in the database, returns you to the last floorplan you departed from. The info button provides written texts or lists of guidelines about the current level you are at in the program. The central directory button places you at the overall site plan, the root directory to the entire document. The ? button gives you a help screen (not shown) which explains the buttons just described.

Students were given considerable freedom in creating their tutorials. The results were quite varied and innovative. Many animated their tutorials, allowing the viewer to follow a resident on foot or in a wheelchair as they negotiated spaces, pointing out design features that would make life safer and easier.

Figure 8 shows selected screens from a typical tutorial. This one is about the bedroom. The opening screen provides an overview of the five criteria that this tutorial covers.

Each criterion is first explained in words and then illustrated graphically. Figure 8 shows this format for the criteria “entrance widths” and “visual access” to outdoors. Screen readability is enhanced by masking all but the areas where the criteria apply. The tutorial ends by “review- ing” the criteria presented. From this point the user may return to the house floor plan or to detailed information about each of the five criteria.

Figure 9 shows a tutorial that has been animated. The subject of this tutorial is external site security. The format is the same as in the tutorial for Figure 8: overview of principle criteria, illustration of each criteria, summary/review of criteria. The principle difference, difficult to con- vey in “printed” graphics, is the movement of vehicles and people used to illustrate each design criteria. The result is a clearer and more inter- esting explanation of essential design criteria. Nearly half the students cre-

ated animated tutorials. Since only a subset of the students

worked on assembling the completed notebook, the last class meeting was devoted to a group presentation of the assembled notebook. Using an LCD overhead display, each student had the opportunity to access their tutorial through the floor plan screens. Stu- dents,were able to see how their tutorial fit into the overall HyperText notebook. As part of a take-home final exam, students were asked to reflect on the use of HyperText to create a programming database. Re- sponses indicated that a conceptual as well as practical grasp of HyperText had been achieved by a majority of the class.

Conclusion and Summary Points

This article has described the experience of integrating HyperText

48

into a course on design methods. Recognizing that design methods are a form of information processing, it was considered advantageous for students to learn how information technology can help “process” design information. HyperText was selected as the application program because it is well suited to handle design information in both text and graphic formats.

The specific problem addressed in the course was programmatic research for an elderly retirement community. The computer was used to assimilate information generated from literature reviews, question- naires, and observation. The computer was also used to organize the resulting information into a programming notebook.

Two strategies were employed for integrating the computer into the course. The first used “semiautomated” programs to handle initial

information processing. An electronic “note card” program was used to record initial findings. From these, a “design notes” program extracted “design guidelines.” A “summary” program compiled these guidelines by activity spaces. These in turn were organized into an electronic notebook written in Hypercard, a HyperText program for the Apple Macintosh.

Though well intended, this initial strategy had to be abandoned. For technical and conceptual reasons, it interfed with the student’s ability to grasp the Hypeffext concept. Thus, a second strategy was devised that focused exclusively on HyperText. Students were shown examples of how HyperText could link diverse types of information. Comparisons were made with “print- based” means of organizing information, especially design information. Through these comparisons and hands-on experi-

ences students mastered the Hy- perText concept. To reinforce this understanding, students were given responsibility for “programming” their own HyperText notebook. In- stead of using the application programs the author had written, students learned how to create their own Hy- perCard documents.

Two formats were used to create the HyperText notebook. The first used a “note card” format. This is the native format of Hypercard, an ex- tension of the “desktop” analogy used by most Macintosh programs. It was used to facilitate initial mastery of the program. 4 note card format, however, does not take full advantage of HyperText’s potential. Three exemplary HyperText programs were reviewed in search of a better format. Four ideas emerged from this review:

1. Involve the user in creating or discovering a path through the document.

Figure 9 Site Security Tutorial by Student Jennifer Swindeman, Fall 1988.

49

Figure 10 Bed and Breakfasts HyperText Programming Notebook by Student Laura Berry, Fall 1989.

2. Make paths inviting, give them storylines.

3. Provide visual, non-verbal cues to path options.

4. Provide different paths for different types of users: a) well defined tutorial

paths for those seeking guidance.

b) open ended paths for those exploring ideas.

The resulting HyperText notebook took the form of a set of tutorials gra-

phically linked by floor plans and site plans of a prototypical elderly retirement community. Clicking on a given space in these floodsite plans activated a tutorial about that space. Visual effects, including zoom sequences and animations, were used extensively, making its use very intuitive and appealing. No longer a book-like document, the student's HyperText program provided a unique and effective means for organizing design information.

There are several lessons to be learned from this experience. The first is the risk one takes in working with new and relatively unknown computer applications. Problems may arise that necessitate shifts in strategy. This is likely to test student patience, let alone their understanding. In this course it became necessary to switch from a strategy intended to make the introduction to computing easier, the "semiautomated" programs, to one that required

'

50

individual responsibility for programming HyperText. Though more difficult to do, this latter strategy resulted in better student understanding and mastery of HyperText.

Other outcomes were less fortu- nate. The strategy switch forced for- feiture of student exposure to other forms of design information processing. This included the data manipulation and transformation capabilities of the semiautomated programs. This in turn made the creation of functional linkages across common criteria difficult. As a result, linkages like the ones suggested in Figure 1 (i.e., all instances requiring handicapper accessibility) were not implemented. Had the databases created by the semiautomated programs not been abandoned, it would have been possible to search keywords to find those relationships and to create the necessary electronic linkages.

Postscript: The 1989 Experience

In planning the course for Fall 1989, an effort was made to apply the lessons learned from this experience. Since the conceptual approach worked best in Fall 1988, the 1989 version of the course started off di- rectly with an explanation of Hy- perText and its relevance to design programming. The first half of the course was used to teach the funda- mentals of design programming and HyperText. At midterm students were given the same exam admini- stered at the end of the 1988 course. Having been instructed on how to program Hypercard since the begin- ning of the semester, they were also able to produce a note card format HyperText programming notebook at this midpoint of the course.

The extra time gained by covering the essentials early in the course al- lowed some modifications. The principal change was to assign students responsibility for choosing and programming their own design problem, rather than dividing up a common class project. This made for a more comprehensive learning experience for students both in terms of practic-

ing their design programming skills as well as their HyperText skills. It was also during the latter half of the course that “purer” HyperText formats were explored, i.e., “The Neuro Tour” and “Context 32.” Students added tutorials, special visual effects, and floor plan directories to their programming notebooks. The more effective HyperText projects incorporated both a linear book format and a nonlinear network format. Figure 10 shows screens from one such programming notebook. While the resulting programming documents were not as long or as elaborate as the single document created in the Fall 1988 course, students in the 1989 course appeared to have had a more comprehensive and coherent understanding of what they had undertaken.

Notes

‘A classic example of this formalization is Christopher Jones’ input-output matrix (Jones. 1972).

%‘he actual scope and potential of HyperText extends far beyond this description. The reader is referred to Ted Nelson’s Literary Muchines (1987) for a more detailed and complete explanation. Ted Nelson, initiator of the Xanadu project, is considered by some to have authored the definitive HyperText program.

3This ability of HyperText to handle more than one mode of information has led many to refer to it as hypermedia

4 ~ s competitive grant was jointly sponsored by the Dean of Faculty, Dean of Academic Computing, and Learning Resources. It was specifically intended for the exploration of HyperText. As part of the award, the author participated in a year-long seminar with three other faculty awardees, sharing experiences and insights gained from working with Hy- perText.

’”IIe “design firm” scenario was used to demonstrate the practical value of what they were learning as well as to enlighten students on the range of uses to which computers can be put. Most design students will work in offices equipped with computers. However, most assume their primary use will be for CADD. Students also need to realize the computer’s potential for organizing and using other forms , of design information. The design products industry is already aware of these other capabilities with many offering their products via on-

51

line databases. Though in part graphic, they also include text and data formau. These databases are “interactive,” allowing inquiries and manipulation of information by the user. Within the CADD industry, at least one firm has acknowledged the importance of Hy- perText. AutoDesk, publishers of AutoCAD, recently purchased he rights to Ted Nelson’s Xanadu project. (See note 2 above.)

6Written in Hypercard, these programs are operated by selecting options from an on- screen menu. With only half the students in the course computer-literate, it was considered prudent to make use of the computer as simple as possible. The lack of computer literacy was a function of transition between an old and a new program. In the new program all fresh- men master McDraw in the introductory design course. About half the students in the course were n?gisted in the new program and half in the old. --

’Computer-literate students in the class had also commented that lack of control over the “semiautomated” program was hampering their ability to understand it. This suggested that “learning by doing” could be crucial in mastering the Hypeflext concep~ This would mean extra effort for the noncomputer-literate students in the class, but not as much as some expected. Hypercard is fairly easy to learn since it can be programmed entirely from menus and on-screen prompts.

81n early demonstrations of Hypercard. Bill Atkinson, author of HyperCard. liked to show “Inigo Gets Out” as an example of how some- one with no computer background could easily learn to use this new program.

’Written in Hypercard. “The Neuro Tour” is a product of Stanford University.

loUcontext 32” is a ~ y p e r ~ a r d Simulation of a much larger project written using the ‘Tnterme- dia” program developed at Brown University’s IRIS center. ( See Yankelovich et. al., 1987.)

“The group of student volunteers responsible for this overall structure were: Lew Neuman, Rose Tejeda, Sue Cuffia, Kathy Skimos, Eliza- beth Castaldi, Jenny Merryfield, and Melissa Cook. Principal credit is due Lew Neuman for conceptualizing the opening sequence and the “mom” floor plans.

References

Alexander, C. (1964). Notes on the Synthesis of Form. Cambridge. MA: Harvard Uni- versity Press.

Alexander, C.. & Chermayeff, S. (1963). Community and privacy. Garden City, N Y Doubleday.

Alexander, C., Ishikawa, S., & Silverstein. M. (1977). A pattern language. New York Oxford University Press. .

Bush, V. (1945, July). As we may think. The Atlantic Monthly, pp. 101-108.

Goodenough, A. (1987). Inigo the cat. (Self- published).

Jones, J. C. (1972). Design methods. Lon- don: Wiley-Interscience.

Nelson. T. (1987). Literary Machines. (Self- published)

Siegel, M., & Davis. D. (1986). Undersrand- ing computer brred education. New York: Random House.

Yankelovich. N., Landow, G. P. & Cody, D. (1987). Creating hypermedia materials for english literature students. SIGUE Out- look, v01.20. p 5.

52