GUI Design

Seventh Meeting, Wed. July 29, 1998, at 1:00 PM

Main Functions

Layout

Viewport
- location
  Decision: top and center
- size
  Decision:Window and Image height fixed at 400 pixesl
  Window width 600 pixels, and Image width 600 pixels or greater
Dashboard
- layout
  - Decision:Must have a text box for typed speech
  - Inventory "tiles" arranged horizontally, below Viewport
  - Instrument "tiles" arranged vertically, to the right of the Viewport
  - Status windows, with a tab selector, to the left of the Viewport
  - Static Buttons for Help, Score, in the lower right-hand corner
  - Decision:Must have a 'home' button or a 'main' button, WHAT?, that will return the player to the staging area
- function
  - Click vs. Double-Click on Tiles
  - Click vs. Double-Click in Viewport

Navigation

Local zooming (achieved with scaling)?
- Decision:There will be 'scaling regions' in each room
- There will be a .scale_zones property defined on each room containing a list of objects of type $g.scale_zone
- The $g.scale_zone object will be defined as a child of $g.game_exit
Global (aerial view)
- support for beaming
- using a personal map
- using a global map
- back to the spaceship
  Decision: we must support this, we claim it, in proposals, as one of the uniquely "virtual" functions
- partial beaming (i.e back to a previously visited room), this is probably implied by the previous point
- Decision: There will be a map object
  - the map will serve as a teleporter
  - players will get the map from Crazy Eddie
  - the map will appear in your inventory, and it will WEIGH MERE OUNCES
  - players will double-click on the map to get a full-screen version
  - the full screen map will either slide up over the viewport, or will appear in it's own window, depending on user feedback
  - the map is totally unlabeled at first
    - as players visit different places they will become labeled on the map
    - the map LABELS will be clickable, which will teleport a player to that location
    - thus, a player will only be able to teleport to places they have already explored on foot
  - the map will display other connected players (as little itty bitty pellets or other such icons) -- To preserve the navigational consistency, clicking on little itty bitty pellets should NOT teleport a player to a location unless they've already explored there on foot
  - the map object will support selective operations: for example, only teleporting a player if they've reached a certain graduation level, or only teleporting a player if they are carrying less that N pounds of equipment (as per the decisions of the Rules Committee).
  - Additional DecisionThere will be a "topographical" option which will allow users to see an altitude overlay
Roomal
- clicking (single vs double)
- arrow keys
- onscreen direction buttons

Communication

communicator device (@page in LambdaMOO)
text balloons
scrolling text window
mouse-over status
note windows (ala the Retailing Game)

Operations
- Experiments
  - Choosing a "weapon"
    - A nose, fingernail, tongue, and teeth, must automatically appear in everyone's inventory
    - There will be a drop-down selector on each instrument to give verb choices (if the player wants to perform a non-standard experiment, like scratching a sample with a compass)
    - The results of all experiments will appear in speech balloons
  - others
    - The 'lantern' instrument is 'on' if selected and dropped, otherwise 'off'
- Customization
  - what to allow
  - how to save
- Error Messages
- Notebook Function
- Online Workbook
- Type-able balloons to suport the 'whisper' function
Context Setting
1. There are no right answers in GUI design -- only tradeoffs that are better or worse -- we must balance aesthetics vs. playability vs. authenticity
2. There is nothing more emotional than User Interface Design
3. GUI design is a group process, and ultimately depends on user feedback
4. We now have an initial prototype, and we're about to design a second. We must respect the work of the previous designers (John Bauer, pretty much single-handedly)
5. The overriding principle is "design to function" -- first decide the functions to support and then work them together.
6. A wise saying (made up by me): We move a ton to save users an ounce of effort
Major Topics

Interface Conventions
Evaluation Plans

GUI Design

Main Functions

Context Setting

Major Topics