Interface Prescripts
Interface prescripts are prescripts that make it simpler to create a text by taking away choices. Professional authoring software has many different tools and selections and a steep learning curve. Consumer software is easier to learn because the range of selections and possibilities is much smaller.
The main benefit of templates is that people who lack the skills to communicate effectively with computers can get the necessary confidence and head start to produce something they will be proud of. But the interface prescripts of the templates can influence:
- how often a text is updated,
- how long its elements will be,
- the number of links,
- the quality of input, and
- the use of multimedia.
The most important aspect of templates is that they make authors out of people who otherwise would never create anything. Templates enable but can only simplify the process by limiting the range of possible expressions. This results in the prescripts of interface. My research identified several interface prescripts, that is, ways the interface of a tool limits what may be written with it.
Frequency of updates
All the systems I studied made it fairly easy to create digital texts. There are some important differences in how easy it was to change these texts, however. In some systems, you had to go through major parts of the creation process all over again to make even a minor change. In other systems, changes were extremely quick to make. Eager authors may always be able to do the necessary work, but it seems safe to assume that frequent changes and updates are less likely to occur when it requires much work than when it is quick and easy to add or alter material.
The main difference is whether the system creates what is experienced as "live" documents or it exports static documents. To make a change in a program that exports documents, the user will make the changes within the system (or, more precisely, the system's native file format), and then export new files for reading. Tinderbox, PowerPoint, iMovie and iDVD were like this. In the program, the text is changed, and then exported as HTML files that have to be uploaded to a server, movie files that have to be exported to tape or some other distribution medium, or burned on a DVD disc which cannot be changed. (A possible advantage of the static document export is that both the old and the new version may be kept).
Technically, all the systems studied export files at the time of publishing, but several Web page tools (in my sample, Blogger, Movable Type, Geocities, HomePage, and Fotolog) are experienced as "live," in that the user may alter the text at any time, and watch the changes take place instantly. Live systems generally require much fewer steps and less waiting, and thus it takes less time and effort to change an existing document.
Even so, Geocities, for example, required that the user went through the same six-step creation sequence (six steps, even if only four are numbered) for every change.
The ease of change is not so much a question of skills. It is quite easy to export files with these systems, and a beginner could probably quickly learn the steps necessary. It is just that these steps take some time to perform, both for beginners and experienced users.
There are differences with different kinds of changes, however. In most systems it was easier to add chunks of new material (paragraphs, images or clips) than to edit and fine-tune what was already there. Especially the dedicated weblog tools (Blogger, Moveable Type, Fotolog) were designed to make it very quick to add a new post or photo to the collection. To change an earlier post was often a bit more difficult.
Length of elements.
Many of the interface solutions in an authoring tool will influence what is written. Jakob Nielsen (233) has noted how the width of a "search box" (the input field for a text search) will influence how many words most users type in for their searches. The same phenomenon can be observed in weblog tools. A small area in which to type a blog post invites shorter posts, probably because it seems to suggest a suitable size for a post.
Similarly, iMovie only had one container for all the clips a movie was assembled from, and only one timeline where the movie was assembled (in comparison, professional video editing systems allow the user to sort clips in different containers, and edit film sections that later are spliced together into a single film). This made it increasingly difficult to manage a project the more clips it contained, and the longer the resulting film was. Assembling a fifteen-minute film from a few dozen clips was a complex task in iMovie.
Number of links.
If it is easy to link, you link more. Having to manually type in the HTML code for a link in a Web page prohibits using a lot of links.
Geocities limited this even further, by just allowing four links.
Tinderbox allowed for interlinking between posts by clicking on a "link" tool, and then clicking and dragging a visual link arrow between two notes. Links to other Web sites were made by a simple cut-and-paste routine. Blogger made it even simpler to make external links. A JavaScript could be installed on the user's Web browser, making a link marked "Blog This!" always visible. Whenever the user found an interesting Web site, he or she could click the "Blog This!" link, and the browser automatically logged in to the user's Blogger account and created a new post with a link to the Web site.
Experiments with links in digital movies have been conducted since the 1980s, and is supported my most major digital file formats. iMovie did not support links in any form, however. iDVD supports links in the form of "chapter lists" in DVD movies. There were limitations to the use of chapters in iDVD, and we will discuss these under the heading "design prescripts" below.
Quality of input.
Some weblog systems (most notably Tinderbox, but also Moveable Type) gave authors the opportunity to save half-finished drafts. This tends to lead to more polished weblog posts, as they may be written, read, and re-written several times before being published. (Blogger did not have this option when the study was undertaken, but added it shortly after.)
Multimedia.
The most felt interface prescript may still be the restrictions of sign systems (what is also often known as media types). Home pages and weblog systems were primarily made to enable writing, where iMovie was for film only. Inserting an image in a Web page is often restricted to a limited collection, or it requires a rather more difficult procedure to upload. Below is a screenshot from .Mac, where only images that already were in the users "iDisk" or in Apple's stock art collection could be selected. Both collections were quite slow and cumbersome to navigate.
Inserting video or sound was rarely an option in the tools I studied. Fotolog was the other way around: it was made for digital photographs, and had very strict limitations to how much written text could be added. The video editing application iMovie had integrated fairly simple solutions for inserting music or photos, but written text was limited to a few words only, even if the end product was a DVD disc, a true multi-medium.
In these ways, and probably many others, interface prescripts reduce the complexity of creation software by eliminating the possible range of expressions.
Next: Design Prescripts >>