05-830, User Interface Software, Spring,
  2000
  Lecture 6,   February 14, 2000
  Copyright © 2000 - Brad Myers
  
        Previous
Lecture     . . .     
Next Lecture
  
  
(Show Videos of SILK.)
  
  - 
    Just show what looks like
    
  
- 
    Note: differentiate from term "rapid prototyping"
  
- 
    Some support for behavior: typically changing screens
  
- 
    Like a movie of the interaction
  
- 
    Goal: see some of interface very quickly (hours)
  
- 
    Often no possibility of migrating to real application
  
- 
    May not use "real" widgets
  
- 
    "Low Fidelity" Techniques
  
- 
    Just use paper and/or overheads
    
      - 
	Experimenter "plays computer"
      
- 
	Ask the user "what would you do now"
      
- 
	Experimenter shows the computer's expected response
      
- 
	Very cheap and easy and gets surprisingly good results
      
- 
	Find out if users understand organization, how to find desired operations,
	if understand menu names, etc.
      
- 
	Easy to change between sessions
    
 
- 
    Can make a movie of the paper using a regular video camera
    
      - 
	To demonstrate/explain the interface
    
 
- 
    For Character Screens
    
      - 
	24x80 DOS, often no mouse
      
- 
	Especially for forms-based applications
      
- 
	Examples: Bricklin's Demo (PC), Protoscreens for PCs from Bailey&Bailey.
      
- 
	Specify characters for each position of screen, or a "character graphics"
      
- 
	Can specify fields that are editable text
      
- 
	Can specify that clicking on an area causes changing to a new screen.
      
- 
	Also menus
    
 
- 
    Card Programs
    
      - 
	Examples: HyperCard and SuperCard for Mac; Toolbook and OWL's GUIDE for PCs
      
- 
	Early Research systems:
	
	  - 
	    Menulay: vector screens, widgets, sounds, text, output C code and tables
	  
- 
	    Trillium: Xerox copier interfaces; interpreted Lisp
	
 
- 
	Sequence of cards
      
- 
	Paint program (not "draw")
      
- 
	Draw pictures on each card
      
- 
	May be multiple layers
      
- 
	Buttons can transition to another card
	
      
- 
	Single window
      
- 
	Buttons can start running a script ("HyperTalk")
	
	  - 
	    Script can move objects, change cards, animate, compute, etc.
	  
- 
	    Code management: who changes what; finding the script
	  
- 
	    Not good for dynamically created graphics
	
 
- 
	Complete control of individual pixels
	
	  - 
	    Graphic designers have complete control
	  
- 
	    Design new widgets
	
 
- 
	Can be "real" application if sufficient power/speed
    
 
- 
    Animation Programs
    
      - 
	Example: MacroMind Director
      
- 
	Also control individual pixels
      
- 
	Individual paintings can be specified as animation elements
	
	  - 
	    E.g., characters
	  
- 
	    Each can be instantiated, moved, etc.
	
 
- 
	Good control over timing, synchronization
      
- 
	Scripting language
	
	  - 
	    Can program that when a mouse button is clicked in an area, start an animation
	    or transition.
	  
- 
	    Scripting language even more primitive than HyperTalk
	
 
- 
	Good for "Future Scenarios" when want good fidelity with real look.
      
- 
	Obviously not for final (real) interface.
    
 
  Silk Examples:

 
  Interface Builders
  - 
    Lay out widgets to make dialog boxes, menus.
  
- 
    Have a palette or menu of kinds of widgets
  
- 
    Select widget, place with mouse in a window  
  
- 
    Set some properties  
  
- 
    Design menus, palettes, dialog boxes, controls  
  
- 
    Put in ``graphics'' pane for main application window  
  
- 
    Easy to use, but limited  
  
- 
    Connect call-backs with each widget
  
- 
    Generates C code directly or intermediate language
  
- 
    Sometimes connected to an intepreter so can execute call-backs.
    
      - 
	If not, some call-backs can be simulated, e.g. transition to another window;
	pop-up error.
    
 
- 
    Layout mechanisms
    
      - 
	usually a complication
      
- 
	X's row and columns stuff
      
- 
	Galaxy's struts and springs
    
 
- 
    "Resources"
    
      - 
	store information in special files rather than in source code
      
- 
	positions, colors, text labels, etc.
      
- 
	allow for easier modification for users, internationalization, etc.
    
 
- 
    Usually don't support:
    
      - 
	Error checking of values, e.g. for text input fields
      
- 
	Greying of widgets depending on values and other widgets
      
- 
	Default values of widgets
      
- 
	Dynamic changing of widgets (e.g., add more items)
      
- 
	Dynamic changing layers (groups) of widgets (visibility) depending on values
	and other widgets
      
- 
	Any dynamically created graphical objects.
    
 
- 
    Examples:
    
      - 
	Menulay (1983-research system)  
      
- 
	NeXT Interface Builder (NeXT)  
      
- 
	UIMX (X)  
      
- 
	BlueSky's WindowsMaker (MS Windows)  
      
- 
	Visual Basic  
      
- 
	... (literally hundreds of others)
    
 
- 
    Large commercial market
    
  
Back to 05-830 main page