Works of interactive fiction generally present their players with a stream of
text, usually in the form of a narrative.  Though this narrative is the primary
means by which the work conveys information about the model world, it is not the
only means.  At a minimum, a work presents certain elements of
"meta-information", such as the name of the player character's discreet location
within the model world, and some expression of the length of the current
play-session.
 Typically, this "meta-information" information is presented in a separate
element of the user interface, most popularly, in a region at the top of the
screen known as the *status line*.  Since the Interactive Fiction "renaissance"
of the 1990s, the overwhelming majority of works have emulated the user interface
paradigm popularized by Infocom.  However, other designs are possible, and many
works released during the era of commercial interactive fiction experimented
heavily with these. It is only in recent years that freelance authors have begun
to experiment seriously with alternate user interfaces.
 Before describing the user interfaces designed by various works of
interactive fiction, is is necessary to understand how a user interface is
composed.  At its most basic, the user interface to a work of interactive fiction
consists of a mechanism for input, and one for output.  Input into the program
can be generalized into three major categories:
<P>
*Textual input: This is by far the most prevalent form of input in interactive
fiction.  The player is allowed to type any text he chooses, though in practice,
constraints are placed on the total length of input.  This is generally how the
player enters commands to be executed by his avatar in the model world.  In
general, the work requests input from the player, usually by displaying a prompt,
and waits until the player has typed some amount of text and pressed the "enter"
key.  Most modern IF systems provide certain conveniences for this sort of input,
such as command-line history (the ability to recall previously typed text into
the current input area in order to repeat a prior command), "hot  keys"
(abbreviations for certain common commands), or spell-checking.
[Footnote: User-defined abbreviations for certain commands appears in *Frotz
interpreter by Stefan Jokisch.  Spell-checking is a feature of the *Nitfol
interpreter, by Evin Robertson.]
*Single-character input: Many works use a single-character method for collecting
supplemental input.  Here, the game waits only for a single keystroke, and
processes its results immediately.
*Mouse input:  A work may also accept positional input via a pointing device. 
Here, the player generally indicates some object on the screen -- a button or
menu option -- with his mouse.
[Footnote: Obviously, other forms of input exist.  *Computer Graphics using
OpenGL (Second Edition. F. S. Hill, Jr.  Prentice Hall, 2001) names five input
primitives: *string, *valuator (an input in the form of a real number within a
fixed range, based on the model of a turnable knob or slider bar), *choice (a
discreet selection among a number of options) *locator, and *pick (which we
combine into mouse input).  The *StoryHarp IF system by Kurtz-Fernhout software
(1998) allowed spoken input, using speech recognition software.  The system found
only limited success.  We consider spoken input to be equivalent to text input
for our purposes.  Some modern systems (Notably, HTML-TADS and Glulx) have a
notion of a *hyperlink, which is a string of text which may be "selected" by a
user action (typically, but not necessarily, a mouse click), and are intended to
be similar in appearance and function to a link in an HTML document.]
 It is generally the case that input is "bound" to an element of the graphical
display; for textual input, this is where the input cursor appears and the user's
input is displayed.  For mouse input, this is the area of the screen in which his
mouse activity will be registered.
 Output in the user interface is primarily visual, though some works
(Sherlock, Infocom, 1987; The Lurking Horror, Infocom, 1987; Frederik Pohl's
Gateway, Legend Entertainment, 1992; Exhibition, Ian Finley, 1999, Six Stories,
Neil K. Guy, 1999, Moments out of Time, L. Ross Raszewski, 2001) also incorporate
audio output in the form of background music or sound effects.
 The fundamental unit of the user interface display is a region we will call a
*pane [Footnote: Both the Z-machine and the Glk screen API call this unit a
"window".  We will use the term "pane" in order to avoid confusion with the term
"window" as it applies to many operating systems (With one exception: by
convention, the primary display area of an IF user interface is called the "main
window".  The author's unhallowed hands will not challenge this convention). 
Because most IF systems are portable to many operating systems, they generally
use the screen paradigm of  whichever system they are run on; on console-based
systems such as DOS, the UI of the work takes the entire screen.  On windowing
platforms such as Microsoft Windows, MacOS, and the Unix X-Window System, the UI
is confined to a window like any other application.  In other systems, such as
Windows CE, the UI of the work fills the entire screen apart from the taskbar and
the interpreter's menu bar.  We will use the term "frame" to describe the total
area of the screen devoted to displaying the work.].  A pane is a subdivision of
the UI's frame which contains some content.  Panes have the following attributes:
*Content: Due to the constraints of the underlying system, a pane may be
constrained in what sort of things it can contain.  A *text pane can contain only
printed text, while a *graphic pane may display images.  Many systems provide
*hybrid panes capable of displaying both text and graphics.  Hybrid panes tend to
place more constraints on the graphics they display than purely graphical panes;
graphics often can only be displayed as "inline" images, that is, they are
positionally bound to the surrounding text.
*Position: A pane must be spatially located within the frame of the user
interface.  A single pane may move throughout the course of the work, or it may
remain fixed in place.  A pane's size may or may not change.  Panes may overlap,
though, since this would obviously obscure other panes, overlapping is generally
only used with temporary panes.
*Scrolling: A pane may be *fixed or *running.  A fixed pane displays some text or
graphic which may be altered or erased.  Fixed text panes are usually realized as
a grid of characters, each location containing some printable character, and
likewise, fixed graphic panes are realized as a grid of pixels, each grid
location containing some color.  Running panes have a notion of "scrolling",
wherein the entire content of the pane is shifted upward to accommodate new
content.  Running panes are generally constrained to textual content, and often
place the restriction that new text may only be inserted at the end of the
current content.  All major IF development systems provide running text panes,
and the main game narrative appears in such a pane.  Some runtime environments
provide "scrollback" for running panes, which allows the user to view text and
graphics which have scrolled off of the screen.  A running text pane is intended
to emulate the stream of paper from a continuous-feed printer.  Fixed text panes,
which do not scroll, are often used for supplemental information such as a status
line, and for menus.
*Mutability: Some panes hold the same content from the time of their creation for
the duration of the work.  Others update very frequently, or very infrequently. 
Immutable windows can hold control elements, such as a persistent menu, some form
of graphical title for the work, or a decorative border.  Other windows may hold
content dependant on the player-character's position in the model world, such as
a textual (*Beyond Zork, Infocom, 1987) or graphical (*Frederik Pohl's Gateway)
representation of her surroundings.  Mutable windows may also have constraints on
how they may be changed; a running text pane can generally be cleared, or
appended to, but text already displayed cannot be altered.
* Transience: A pane may be *persistent or *transient.  Persistent panes exist
for the duration of the UI, while transient panes appear and disappear as needed.
 A "quote box" or special-purpose menu may appear in a transient frame [Footnote:
H. Joshua Field's *Stick it to the man (2001) uses a transient fixed text pane
for its conversation menus].
[Footnote: of the elements listed, scrolling, position, and content are most
often mandated by the platform, while mutability and transience are generally at
the discretion of the author.  HTML-TADS provides a running hybrid pane and a
fixed hybrid pane.  Glulx allows an arbitrary number of panes which may be fixed
text, running hybrid, or fixed graphic.  Panes may not overlap, but can be
resized.  Most versions of the Z-machine provide one running text pane and one
fixed text pane, the fixed text pane being located at the top of the frame;
version 6 of the Z-machine allows for multiple running hybrid panes, without many
of the usual constraints placed on running panes.]
**The Infocom Standard Layout
<P>
 Without a doubt, the most popular user interface design for contemporary
interactive fiction is based on the design popularized by Infocom during the
1980s.  Indeed, all of the major IF platforms available today (Hugo, TADS, the
Z-machine, Glulx) default to this UI, and many systems (some versions of the
Z-machine; TADS, barring the HTML extensions, AGT) are incapable of anything
else.
 The basic layout used by Infocom (hereafter the *ISL, or Infocom Standard
Layout) consists of two panes.  The lower pane, or *main window is a running text
pane, which contains the game narrative and interaction with the player.  Above
this is a fixed text pane known as the *status line.  The status line contains
supplemental information about the state of play.  Traditionally, the ISL status
line contains the name of the player character's current location, the number of
turns which have elapsed, and the player's score.  By convention, the status line
uses a color scheme which is the inverse of that used in the main text area,
though some systems prefer instead to denote the separation using a visible
border between the panes. Both panes stretch the entire width of the frame.
 Infocom itself did not adhere strictly to this layout, and the most common
form of customization within the basic framework of the ISL takes the form of
modifications to the status line.  *Suspended (Infocom, 1983) displays the name
of one of the player-character's six robotic assistants in place of the player's
location.  *Trinity (Infocom, 1986) omitted the turns/score counter, showing only
the current location, centered in the status line, a technique used recently by
John Ingold in *All Roads (2001).  Andrew Plotkin's *Spider and Web (1998) is
similar, but places the location to the left of the status line.  *Sherlock: The
Riddle of the Crown Jewels (Infocom, 1987) substituted the game's date and time
for the turn counter, a variation which also appears in contemporary games such
as Graham Nelson's *Jigsaw (1995),  Adam Cadre's *I-0 (1997), and Paul O'Brian's
LASH (2000).  Bureaucracy (Infocom, 1987), which billed itself as "A Paranoid
Fantasy", gave the player's blood pressure in it's status line.
 Several Infocom games extended the status line to occupy additional space on
the screen.  *A Mind Forever Voyaging (Infocom, 1985) added a second line.  The
upper line gave the current game time and described which of several "modes" the
player character (a sentient computer) was using.  The lower line gave the
player-character's location and the current game date.  A Mind Forever Voyaging
also extended the upper pane in one section to display inkblot-like designs
during a psychiatric evaluation of the player-character.  *Border Zone (Infocom,
1987) used the lower line to show a real-time display.
 In recent times, many authors have experimented with placing other
information in the status line.  Nick Montfort's *Winchester's Nightmare (1999)
displays the game title on the left, and the current location on the right.  Neil
Brown's *A Week In The Life (1997), a game with a highly abstract model world,
uses a two-line status bar to show the player's progress.  In the upper left, the
location, "Your Life" remains unchanging during the game.  Andrew Plotkin's *A
Change in the Weather (1995) gives the current atmospheric conditions in place of
a turns/score counter, his next game, *So Far (1996) is similar, presenting
messages such as "(hot, sticky)" or "(autumn, cool, smoky)".
 Only a handful of contemporary games have attempted even more complex status
lines. [Footnote: Part of the reason is technological; under platforms like the
version 5 Z-machine, *any customization of the UI must ultimately take the form
of modifying the status line]  L. Ross Raszewski's *Rox (2001), a IF adaptation
of the arcade game "Asteroids", enlarges the status pane to emulate a space
ship's command display.  Laura Knauth's *Winter Wonderland (1999) has a heavily
decorated status line, including a mapping display.
 By convention, the colors used by a work using the ISL layout are determined
by the player, rather than the author.  Following Infocom convention, many
interpreters defaults to a light gray foreground color, and a blue background,
though black-on-white is not uncommon.  Nonetheless, several games have made use
of specific colors.  Probably the most impressive use of color appeared in Adam
Cadre's *Photopia (1998), which used a different color scheme for each of the
game's major sections.  A similar technique appeared in his *Varicella (1999). 
Chris Klimas used an alternate color scheme to denote a computer interface in
*Mercy (1997).
[SIDEBAR: Menus and Quote Boxes
Though almost every recent game has adhered to the ISL for its primary UI, two
supplemental UI paradigms are extremely common.  It should come as no surprise,
however, that both of these alternate paradigms were used first by Infocom.
*Menus
 Infocom's "Solid Gold" releases featured built-in hint systems.  These were
presented using a menu-driven UI.  In the most common variation, the title of the
menu and a summary of its controls appears in the status line.  Below this, a
list of menu items appears.  The user navigates this menu using the keyboard in
most variations, though mouse-driven menus also occur.  These menus are most
commonly used for in-game hints and documentation.
 Recent public opinion has favored in-line menus for such things as
conversations.  Here, the contents of the menu are printed to the main window,
and the player is prompted to enter a numeric value corresponding to the menu
item.
 An alternate menu system was implemented by Chris Klimas in the Textfire game
*Once (1998).  Here, an untitled menu appears entirely in the status bar.  It is
navigated using the arrow keys.
*Quote Boxes
 Many games include one or more pithy epigrams (particularly on the title
screen), and a popular format for this is the "quote box".  Here, a transient
fixed text pane is placed over top of the upper portion of the main window.  By
convention, the quote box appears in inverted colors.  In the most common form of
this technique, once printed, the quote box's contents effectively become part of
the main window, and are scrolled upward with it.  This provides the visual
effect of the epigram having been "stamped" on top of the text in the main
window.  This particular form of the technique is highly specific to games using
the Z-machine; it relies on pane behavior which differs from most other
platforms.  In another variation of the technique (popular on platforms such as
Glulx, where panes may not overlap), the main window is temporarily reduced in
size to allow for a new pane between it and the status line, where the quote is
displayed.  The pane disappears again shortly thereafter.  The method is less
visually impressive, but avoids many technical problems associated with the
Z-machine window model.]
<P>
*A History of User Interfaces
 Of course, Infocom was not the first company to produce Interactive Fiction,
and in the history of Interactive Fiction, we find a much wider variety of UI
designs during the commercial era of IF.
 It should perhaps not be surprising that the earliest games used extremely
simple user interfaces.  Early versions of *Adventure (Crowther and Woods, 1976)
featured only a single running text pane.  These games were designed to be
playable even without a monitor -- the game text could instead be sent to a
printer at the end of every turn sequence.  In modern times, games using the
*Alan development system adopt this design.  A handful of other contemporary
games have used this technique: Sean Barrett's *The Weapon (2001) has no status
bar.
 Of course, it did not take long for more complex user interfaces to appear. 
Infocom's standard layout was used from *Zork: The Great Underground Empire
onward through most of the company's history, however, Infocom did not strictly
limit itself to this interface.  *Bureaucracy (1987) opens with a single
fixed-text pane containing a data entry form.  *Beyond Zork (1987) offered a
three-pane textual interface.  The lower half of the frame is filed by a running
text pane, where player input occurs and the main game narrative is displayed. 
Above this are two fixed text panes.  On the left, a pane displays infrequently
updated information, usually the description of the current location.  The
rightmost pane shows a text rendering of the game map.
 Though some consider the inclusion of graphics in Interactive Fiction to be
anathema, there is much historical precedent for "illustrated text adventures". 
In Interactive Fiction, graphics may be presented in a pane of their own, or may
be drawn "inline", among the running text of the narrative.  Separating graphics
into a distinct window appears earlier in IF history (presumably because of the
difficulties involved in formatting text around images), with the addition of
inline graphics becoming popular with HTML-TADS.
 Earlier games integrating graphics tended to opt for a split-screen layout. 
The lower half of the frame is occupied by a running text pane, the game's main
window.  Above this is a fixed graphic pane.  An image in the graphic pane
typically corresponds to the player character's location.  Often, a fixed text
pane is also present, similar to the ISL status line.  This may occur at the top
of the screen, or between the graphic pane and the main window.  This layout was
used extensively by Tellarium, in such games as The Wizard of Oz (1985),
Fahrenheit 451(1986) and Rendezvous with Rama (1985).  More recently, Kent
Tessman's *Guilty Bastards (1998) and Marnie Parker's *Carma (2001) used this
basic layout.  
 It is easy to draw an evolutionary line from the split-screen layout to the
earliest graphical adventure interfaces, such as Sierra's AGI platform (first
used in *King's Quest (1984)).  This interface uses only transient fixed text
panes for textual output.  A pane at the top of the frame acts as a status line,
and a single-line pane at the bottom of the screen allows the player to enter
commands.  The middle of the frame is filled with a fixed graphic pane, showing
the player's avatar and his surroundings.
 However, the move toward graphical interfaces was slower in some parts than
others. Later commercial games produced complex interfaces while retaining text
as the primary output medium.  Infocom's *Journey (1988) used a three-pane UI. 
The lower part of the frame contained a fixed text pane featuring several menus. 
Above this were two further panes.  On the right, a graphic pane showed the
current illustration.  On the left, a running text pane contained the story
narrative.  Input was constrained to the menu.  
 Even more exotic interfaces were explored by other companies.  Tass Times in
Tonetown, released in 1986 by Interplay, but authored by Mike Berlyn of Infocom
fame, used a clear evolution from the split-screen design.  The lower half of the
frame is occupied by a text pane which contains the main narrative.  Above this,
a second text pane contains a compass rose.  In the top half of the screen are
two graphic panes.  On the left, a pane shows an illustration of the current game
location, while on the right, an iconic menu allows easy access to common game
verbs.  Textual input is supported, but the game also relies heavily on the
mouse, which, in addition to working in the iconic menu, can be used to select
objects from the scene illustration.  That same year, ICOM Simulations released
*Shadowgate, a game which has the dubious distinction of being one of the few
adventure games released for the Nintendo Entertainment System.  The interface
has a text pane at the bottom of the frame, containing the game narrative.  Above
this, to the left, a graphic pane contains the current scene illustration.  Above
the graphic pane, a status line names the location.  Further up, a textual menu
offers the game verbs.  A graphical banner fills the remaining space at the top
of the frame.  Two further panes occupy the right side of the area above the main
window.  In the middle of the upper portion of the frame, a graphical inventory
is displayed, and beside this, a graphical map.
 Probably the most complex user interfaces in the commercial era of text
adventures were those constructed by Legend Entertainment.  Their games, such as
Spellcasting 101: Sorcerers get all the girls (1991) and Frederik Pohl's Gateway
(1992) used a highly complex user interface.  The games all feature similar
interfaces, though the level of ornamentation and specific style of graphic very
from game to game.  However, elements of both the ISL and the split-screen
interface are visible.  The right side of the frame is clearly based on the older
split-screen layout.  The top half of the frame contains an image of the current
game location.  Items appearing in the image can be clicked with the mouse to use
them as an object of the current verb (clicking when no verb has been selected
results in examining the object).  This pane can also be configured to display
textual information: the player's inventory, the room description, the player's
score, etc.  Below this are a status line and main window very similar to the ISL
paradigm.  The left side of the frame contains menus and other interface items
laid out in four panes.  The top two panes contain a clickable compass rose and
buttons for controlling the interface (the exact location varies; in
Spellcasting, the compass is on the left, while in Gateway, it is on the right). 
Below these are two text menus.  On the left, a menu contains common verbs. 
After a verb is selected, this menu changes to display prepositions.  On the
right, a menu lists the objects obviously in scope to the player.  A player may
type commands into the main window, or may compose them using the menus.  The
Legend interface is unique among IF interfaces in the complexity of commands
which can be entered using only the mouse.  Some panes can be hidden according to
the player's preference.
 Legend games also frequently used alternate interfaces when dealing with, for
example, pieces of technological equipment.  These interfaces were generally
totally graphical, with clickable regions.  Gateway 2: Homeworld (1993) also used
an alternate interface for conversations with non-player characters.  The usual
interface is replaced with a black screen.  A picture of the NPC appears to one
side, and choices of dialogue or lines of conversation appear on the other.
 Sidestepping somewhat, several games remained almost purely text, but
retained graphical "decorations".  The majority of Zork Zero: The Revenge of
Megaboz (Infocom, 1988) uses a decorated variant of the ISL.  The status line
itself is superimposed on a graphic banner, and images of columns line the sides
of the frame.  Infocom's adaptation of James Clavell's *Shogun (1988) also
featured decorative images at the sides of the frame.  Both games are also early
examples of the use of inline graphics.  In recent times, Adam Cadre's 2001
re-release of *Photopia features a graphical border which surrounds the main game
area.
<P>
*Modern Explorations
 As explained earlier, most contemporary games adhere closely to the ISL
design, with variations occurring primarily in the content of the status line. 
There are, however, some exceptions.  
 Most IF has used continuous displays for the primary narrative.  In recent
times, several; games have broken with tradition, using a fixed text pane for
their primary display, which is cleared after each turn.  Most examples of this
technique occur in games designed to be played in a web browser.  One notable
exception is Andrew Plotkin's *The Space Under The Window (1997), a Z-code game.
 Other games have experimented with departures from the ISL which are still
text-based.  John Ingold's *My Angel (2000) features a unique "novel mode"
interface.  The main window is used exclusively for game narrative.  Player input
and the messages from the parser occur in a separate pane at the top of the
screen.  L. Ross Raszewski's *Moments out of Time (2001) adds a menu bar to the
bottom of the screen.  Accessed via the function keys, it allows quick access to
common game verbs, nouns, and other features.
 The addition of graphics to contemporary IF has occurred slowly.  The release
of HTML-TADS, and later TADS 3, sparked the IF community to begin small-scale use
of graphics.  Neil K. Guy's *Six Stories (1999), Ian Finley's *Exhibition (1999),
and Stephen Granade's *The Arrival (1999) all feature inline graphics.
 A few games go still further, though few approach the complexity of, for
example, the Legend interface.  Mike Snyder's 1999 game *Lunatix: The Insanity
Circle uses a five pane interface.  The lower half of the frame is occupied by a
running text pane containing the game's responses to player interaction.  Input
occurs in a separate single-line pane below this.  In the upper half of the
frame, a pane on the right contains the room description, and above this is a
status line.  On the left, the current illustration is shown.
 Marnie Parker's *Just a Dream (2001) demonstration game also uses five panes.
 The bottommost pane spans the frame, and shows a graphical listing of the
objects in the current location.  Above this is the main window.  At the top of
the frame is a traditional status line.  Between the status line and the main
window are two further panes, both graphical.  On the left is a scene
illustration, and on the right, a graphical inventory.
 Adam Cadre's *Zeta Space (still in development) also features a complex
interface. The main window, like in many graphical examples, is located at the
bottom of the frame.  Above it are two graphic panes.  On the left, a scene
illustration is show, while on the right, dialogue is graphically rendered in a
font appropriate to the speaker.
 *Balances, Graham Nelson's Inform demonstration game, was recently ported to
Glulx by L. Ross Raszewski (2001), as a demonstration of the GWindows user
interface library. The user interface is highly graphical, featuring a woodgrain
border around the main window, which is located on the right side of the frame. 
Below this, spanning the bottom edge of the frame, a graphic pane shows clickable
icons of the spells currently available to the player.  On the right side of the
frame are two further graphic panes.  The lower pane contains eight buttons, most
of which activate a textual menu.  The menu is contained in a fixed text pane
which appears to the right of the main window when it is active.  Above the
buttons, a graphical inventory is shown.  When  inventory items are clicked,
their names are inserted into the current line of player input.  At the top of
the frame, a standard status line is shown.
 A highly atypical interface is used by Morten Rasmussen's *Invasion of the
Angora Fetish Transvestites from the Graveyards on Jupiter (2001).  The main
window is at the top of the frame.  Below this are no less than 8 further text
panes.  On the left, a pane lists the visible exits.  Right of this, another pane
lists the characters present.  Below these, a pane is reserved for player input. 
To the right of this group, a text pane lists the player's inventory.  At the far
right is a cluster of navigation buttons.  Along the bottom of the frame are
panes giving the player's hit points (the game features randomized combat), the
funds available to him, and the current game time.  Two buttons are also at the
bottom of the screen for controlling the game's audio and real-time.  The space
between panes is filled with a color pattern.
<P>
 For those wishing to experiment with exotic user interfaces, the technologies
now available to hobbyists have finally reached a state in which such things may
be practical.  HTML-TADS allows users to include more complex screen effects by
encoding them in HTML.  Version 6 of the Z-machine, and the Glulx virtual machine
allow extremely complex user interfaces, but these necessitate a somewhat more
difficult programming approach.  However, high-level libraries exist to
facilitate programming for these systems.  Jason C. Penney's V6Lib is a
high-level interface to the version 6 Z-machine screen model, and L. Ross
Raszewski's GWindows provides similar functionality for Glulx.  The latter
includes a large number of class libraries defining common interface components,
such as a status line, menu, or quote box.  Even today, most games rely on the
ISL, however, the prevalence of more complex UIs is increasing, and if the
current trends continue, future revisions of this article may be