The Hypertext writers workshop brought hypertext content and system developers together to explore hypertext writing strategies and discuss specific tools and techniques to create quality hypertexts.

The workshop broke into four tracks:

1. WRITE NOW: A hypertext writing exercise to explore ways to write hypertext and demonstrate the concepts and thought techniques involved

2. WRITE WITH WHAT?: A discussion designed to further expand existing lists of specific tool requirements--and determine where these are available or how we can get them

3. WRITE HOW?: A discussion designed to further expand our existing lists of strategies and techniques--and determine how these techniques are being used and could be used in future hypertext literature.

4. TALK ABOUT WRITING: A discussion designed to explore the role of literary criticism in hypertext and determine how to adapt the tools of literary criticism to analyze and discuss hypertext literature.

After these sessions, participants met to define recurring issues and challenges and to plan on what we can do as a community to promote hypertext and hyperliteracy. The following items and ideas were mentioned in our discussions. However, this paper by no means suggests that all the participants held these ideas or agreed with these positions.

Recurring Issues

Defining Hypertexts

What a hypertext is has never been clearly laid out, and has changed drastically over the past few years to include blended media, imagery, sound, programming elements, structure, and more. We discussed why definitions are needed, what we would do with a definition of ht if we had one, and what the boundaries of hypertext literature are. Some practical needs for definitions emerged, such as:

• Teaching hypertext as a genre (What genre is is a dicey question as well. However,university and other curricula need some sort of guidance).
• Defending a thesis or publishing other academic work (What department is the work in?)
• Promoting and judging hypertext literary prizes (How will contests such as trAce, New York University, Electronic Literature Organization, etc. be organized?)
• Determining how to list hypertexts in databases, publishing catalogues, and other formats (where do hypertexts belong on the shelves?).

Hypertext definitions depend on the context they are used in, and will change to meet the changing literature, systems, and situations. A universal definition will be inaccurate, and is not really necessary. Questions that each definer will need to ask include:

• Do hypertexts require a computer, or can they be conceptual or on paper or other media?
• Should we distinguish between hypertext, cybertext, blended text, or ergodic text?
• Can hypertext be text-free? How do images convey meaning in hypermedia?

We can find "over the line" examples that are clearly "not hypertext." Yet we cannot exclude an entire media from being a hypertext media--webshows can range from obviously linear to obviously hypertextual. Drawing the line depends on individual uses of hypertext and individual perceptions of what a hypertext must contain.

Audience:

Hypertext audiences are elusive. Tracking web hits or other user statistics does not provide a clear picture of who is accessing the work, why they are accessing it, or what they think of the work. The questions still remain:

• Who are we talking to?
• Who supports our work and our jobs
• How do we target our audiences?
• How are our works selected to be read and accessed?
• How do I convince others to accept hypertext as a literary and artistic form?
• How do I get people to read hypertexts?
• How do we keep people's attention for an indepth look at what we are doing?

Conventions

Readers rely on conventions. We have none yet--or few. Websites are developing conventions that are akin to print conventions and may not be (or may be) appropriate or valuable in hypertext literature. The web has had a major impact not only in defining these conventions, but in shaping the way we write to accommodate the browser and other technical limitations. We need more work such as Mark Bernstein's paper "Patterns of Hypertext, HT98" to classify stages of texts as well as characteristics of media, link, structure, and navigation. Authors need to define:

• Who decides how readers use links and
• What levels of efficiencies--or inefficiencies--we will obtain.

Production Models

The tools and possibilities for creating hypermedia are virtually endless, and require a great deal of sophisticated knowledge about:

• The platforms, software, and hardware (which changes rapidly)
• Programming and pseudo code
• Imagery and graphic design
• User interfaces
• Sound and sound design

Two production models have emerged:

The Renaissance Man Model where a writer develops the expertise in all the hypermedia areas to create a single-vision work. Yet asking a single author master all techniques is growing less realistic, as computer systems, graphic and sound capabilities and other media become more complex. Can the author realize his or her vision with the tools and abilities at his or her disposal? Do we require authors now to be as competent programmers and graphic designers as they are writers?

The Game Development Model which features several people, at least a core programmer, visual designer, content producer, and a money man. This model takes money and a clear, collaborative vision. The team needs to determine what the process will be, and grapple with questions like: What comes from the conflicts of vision? What will the final product look like and why? The creative process of production comes into play here as well. Authors vary from knowing exactly what their work will be like before it is started to those who let the story develop slowly. Collaborations can range from a writer dictating the precise color of yellow to use or a group brainstorming on the color yellow and what it means in the work. Collaborators are usually separated by geography and culture--we have to break those barriers both technologically and culturally. We need software that promotes long distance collaboration both synchronously and asynchronously.

Developing tools

The tools available to a large extent determine the look and feel of the work, the media used, and even the genre classifications. Writers need to research to determine what tools fit their vision, are accessible to their readers, and can be adaptable to future technologies so that their work can survive.

Working with software developers

The available tools may not reach the audiences that we want to reach or do what we need them to do. We know what the run time should be, and how the works should react to variables. How do we work with other artists including programmers to realize these visions? We need to get programmers involved in the story and the work to explain how the work should run and what is needed. We need to explain precisely what behaviors are expected, and detail this to at least the level of psuedocode. The lines between programming and writing are rapidly becoming very blurry.

Keeping in contact with developers and engineers is critical--it's one of the most important collaborations to pursue. It seems like the chances of artists taking on the language and thought processes of engineers and developers is slim (The Renaissance Man Model). Some tools will be built (like HyperCard) to support a single poet or artist. The more complex visions will require more complex production models (the Game Development Model). We have identified a way of thinking about the production of digital art. It may be a good reference point for both camps. Given a general set of tools (whether different programs or a set of tools within one program) there is a lot of room for exploration. Photoshop for instance uses a pretty small number of general tools (layers, paintbrush, filters, select etc...) that when used in combination (and there are an infinite number of combinations I am sure) make such a powerful tool. We need to carry the discussion from specific single tools to the interaction of many different programs and analog tools (string and paper).

Module oriented approach to tools

Most of the practical problems of transporting work between softwares, browsers, and platforms has disappeared--we can share output across applications. This allows us to take a modular approach to tools and use the specific strengths of many tools. We can manipulate images in one software, text in another, and sound in still another.

Using Tools

Writers bend the boundaries of tools, and thus must become familiar with the idiosyncrasies, nuances, and potentials of each tool. New and more complex software is being developed all the time, so working on the edges becomes more challenging. Writers need to decide whether the newest tool offers enough advantages to invest the time to learn it. Each tool has its power users who use specialized tools for and with specialized skills, and we need to collaborate with these power users to determine what can -- and cannot-- be done.

We are using tools such as:

• Internet software development tools such as MOOs, e-mail, DHTML, PERL, HTML, CSS, JAMBA, Java, and Javascript
• Web building commercial software such as Dreamweaver, Go Live, Cold Fusion
• Inform
• Oracle Meeting objects
• Write Now
• Installation works
• Windows Help workshop
• Hypertext systems such as StorySpace, ToolBook, Director, HyperCard
• Graphics programs such as Paintshop Pro, Real producer, Flash, Photoshop, Corel Draw, llustrator, Superpaint,
• Editing programs such as BBEdit, Quark Express,

Often, we use tools in succession. For example, we might plan the work in Storyspace and use Dreamweaver and other software to ensure it looks good on the web. We would like to have tools available to use, but these are in development or on hard to obtain platforms:

• PAD (Research technologies)

Requirements list

We are looking for practical solutions.

• Accessibility--Writers want works to be as accessible to as many people as possible. Thus hypermedia systems need to work on simple, low end machines.
• Collaboration--We need to have tools that can function as production studios, that allow many people to work on the same material from many geographical locations.
• Flexibility--People approach the same idea and task in many different ways

Building the community

Communicate

Writers cannot develop hypertexts in a vacuum. We need to be a vibrant part of larger communities of programmers, graphic designers, sound designers, and others. Ways to do this include:

• Find a common language of production with various communities. (This involves learning their terminology, history, and perspectives. We need to coach ourselves to talk in their language and shape these discussions to share ideas and find ways to realize visions.) Communicate in ways other communities can access such as position papers, summary papers, article in the SIGWEB newsletter, papers and panels in SIGGRAPH conferences and other conferences. Write trip reports when attending other conferences.
• Get involved in the working groups that are deciding our future such as the W3C, OHS computing groups, Open Ebook Standard. (Find out when the meetings happen and when input is needed. Respond to requirements queries directly and immediately.)
• Develop a list of groups we should watch, data we should gather
• Work with our friends in these places
• Learn to formulate our results to produce documents programmers, designers, etc. can use
• Develop a useful rhetoric for talking about hypertext in the academic spheres.
• Develop a clearinghouse to share news about software and tools, tips and war stories, problems we have encountered for advice or solutions. Have threaded conversations organized by tools.
• Act as betatesters
• Summarize the available literature and programs
• Give readings

Keep abreast of the community

• Go on the web to discover the new ezines, journals, websites, and other resources for hypertext. Much of the hypertext literature is being developed outside of this community.
• Read other writers
• Collaborate with other writers and programmers
• Helen Whitehead will work on consolidating a list of listservs, and will look at using Zope to archive lists.
• Send events to ht kitchen
• Contribute to trAce's electronic abstract journal

Next conference

Suggestions for the next Hypertext Writers Workshop included:

• Do a usability session the night before the workshop
• Reformulate groups so that participants change groups
• Wrap around the conference to provide time to share perspectives and insights
• Go for a full day both before and after
• Break up into sessions
• Go through all sessions first then come together
• Discuss:
  • Writer vs. reader perspective
  • How do we interact with readers?
  • How do we approach tools?
  • How do tools affect HT?
  • What is the place of HT in academia
  • The problem of tools
  • How to manage large scale organization
  • How to teach hypertext literature
  • How to teach hypertext writing
  • How do we gauge and engage reader reaction
  • Research and display technologies from other conferences (e.g., narrative intelligence symposium, List Chi, display text)
• Have another Write Now exercise--this was fun and provided teaching methods

Suggestions for the overall HT01 included:

• Display works in progress and software in a reading room so we can spend more time looking at works.
• Demonstrations using hypertext tools--both from current research and historic programs

• Propose a panel--Present works in progress and show software problems with the works

Suggestions for a workshop after the HT01 included:

• Come up with ideas that don't have tools
• Work directly with the programmers on specific problems and applications
• Brainstorm around these tools.

Related websites and resources

• HT Kitchen provides news and a calendar of events
• Electronic Literature Organization explains what hypertext literature is and provides a database for electronic literature
• trAce