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.
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:
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:
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.
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:
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:
The tools and possibilities for creating hypermedia are virtually endless, and require a great deal of sophisticated knowledge about:
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.
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.
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:
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:
We are looking for practical solutions.
Building the community
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:
Keep abreast of the community
Suggestions for the next Hypertext Writers Workshop included:
Suggestions for the overall HT01 included:
Propose a panel--Present works in progress and show software problems with the works
Suggestions for a workshop after the HT01 included:
Related websites and resources