Command and Natural

Languages
Human Computer Interaction
CIS 6930/4930
Section 4188/4186
► Languages are a natural way to
communicate Intro
► Communication with systems
 Initially, programming languages
 Scripting languages
 Database query
 Command languages
► With menus and DM, why have
languages? For some tasks,
 Natural
 Faster
 For tasks with many options, most
effective
 Small footprint (screen, power, size)
 Logistics: Generating help,
verification, etc.
► Languages negatives?
 User memory Intro
 Could be cryptic
 Retention, learning, frustration
► Ex. Web addresses
 Class web page
► Initiate vs. respond (ex. Unix)
Functionality to Support Users’ Task
► People use systems to
accomplish a task.
► How do you build a
command structure to
support this?
► Identify user tasks
 Usually create 1 to 1 for
functionality with actions
and objects
 Common error: Too many
actions and objects
► Overwhelms users
► More code, more errors,
more clutter
 Insufficient actions: very
frustrating!
Functionality to Support Users’ Task
► Create a list of tasks
 Use a column for frequency
of expected use
 High frequency tasks should
be easiest to remember and
carry out
► Careful thought into user
base
 Ex. do you need macros?
► Transition diagram helps
(Fig 8.1)
 Command-Organization Strategies
► Strategies to create commands
► Agreeing on a interface concept aides
retention, learning, and problem solving
► Not that straightforward
 Ex. Load/Save, Read/Write (notes vs. folders),
Open/Close (files vs. notes)
► Common mistake: Choose a computer
metaphor instead of a domain metaphor
 Ex. e-mail
► Simple Command Set
 # of commands = # of tasks Command Organization
 Ex. MUDs
► Ex. Look, go, move
 Cons: Large # of commands
Strategies
► Ex. VI
► Commands plus
arguments/options
 Each command is followed by >=0
arguments
► Ex. Copy X Y
► Include keyword labels: Copy From=X
To=Y
 Pros: readability, fewer semantic errors,
better for novices
 Cons: increased syntax errors, slower
for experts
► Hierarchical command structure
 Tree structure of commands (like
menus)
 Let’s create one for files
► Create,display,remove,copy, move
► File, process, directory
► File, printer, screen
 Easy to write tutorials
 Benefits of Structure
► Study: Error rates for UNIX
 3 to 53% (Hanson ’84)
 Common commands too! (18% for mv, 30% for cp)
 Experts gain some (perhaps sadistic) fulfillment and club ‘inclusion’ by
understanding complex command languages
► Benefits
 Learning
 Memory
 Problem solving
► Elegancy vs. Consistency
 Apply ‘edit’ vs. ‘revise, change, replace’, etc.
 Reduces error
► Other examples
 Some commands are two characters, others not
 What is a binary decision? On/Off, True/False, etc.
 Multiple design groups
► Solution: Create a guidelines document. Good for managers and
designers
 Benefits of Structure
► Study: Benefits to argument ordering consistency (Barnard ’81)
 Ex. Source or ID is always a certain argument
► Symbols vs. Keywords
 Which is better: FIND:/TOOTH/;-1 or BACKWORD TO “TOOTH”
 What about for different grade of users? (Novice, Familiar, Expert)?
 Study: Table 8.1 (Ledgard ’80)
 Clarity overrides speed
► Study: (Carroll ’82)
 Effect of congruency [meaningful pairs] and hierarchies on performance
 Ex. Open/Close Left/Right
 Memory and problem solving improved w/ congruency
 Error rates reduced w/ congruent hierarchy
 Results:
► Congruency = very good
► Hierarchy = good for large command sets
► Good things to have: positional and grammatical consistency,
congruent pairing, hierarchical form
 Naming and Abbreviations
► Let’s look at UNIX
 mkdir (make directory)
 ls (list directory)
 cd (change directory)
 rm (remove file)
 pwd (print working directory)
► What’s wrong with these abbreviations?
 No standard method to derive them!
 Standards are important aid
 Specificity vs. Generality
► Specific – more descriptive
► General – more familiar and easier to understand
► Study: 2 week training session
 Resulted in specific > general (Barnard ’81)
► Study: (Black and Moran ’82) – pg. 328. Different terms
for insert/delete
 Infrequent, discriminating: insert/delete
 Frequent, discriminating: add/remove
 Infrequent, nondiscriminating: amble/perceive
 Frequent, nondiscriminating: walk/view
 General: alter/correct
 Nondiscriminating nonwords: GAC/MIK
 Disciminating nonwords: abc-adbc/abc-ac
 Best = infrequent, discriminating words
 Worst – general
 Not bad – nonsense
 What does this teach us? (distinctive-ness is a plus)
 Abbreviation Strategies
► Should be easy to express with input device
 Keyboard, pen (PDA), speech recognition, mouse
► Error rates increase w/ more complex commands
 Shift, Ctrl (plus harder for disabled or motor-damaged users)
 Brevity is good, but must weigh w/ retention and learning
 Study: (Landauer ’83) novices don’t mind typing out full names
[increases confidence] (<5 to 7 uses)
► Abbreviation Strategies
 Simple truncation – commands must be distinguishable
 Vowel drop
 First and last letter
 First letter of each word
 Standard abbreviations – familiarity
 Phonics – XQT
 Abbreviation Guidelines
1. Simple primary rule
2. Secondary rule abbreviations should be denoted by
some distinguishing character
3. Minimal use of secondary rule
4. Users should know the rules
5. Truncation should be used, except when too many
similar actions
6. Fixed-length is preferable to variable length
7. Computer generated messages should NOT use
abbreviations
8. Should be greater than >2 savings for abbreviations
9. Consider a command menu.
1. Ex. Imaging Control [really benefits only intermittent users]
10. Underscore critical letter (like in Windows)
Natural Languages in Computing
► One(popular) trend is to communicate with the
computer using natural languages
 This involves both input and output
► Why is this hard?
 Subtleties (mood, accent, culture)
 Context sensitive
 Large user base
► Currently:
 Very restricted domains (stock trading phone system)
 Processed input and/or output
 Formatted texts (weather reports, tech reports, etc.)
 Can’t do: poems, freeform conversations
 Rough translations help w/ getting the ‘jist’ of most things
► Ex. language learners
 Natural Language Interaction
► NLI – Star Trek-type cognition
► Pros:
 Don’t have to remember syntax or menu conventions
► Cons: (besides harder)
 Not necessarily faster
 Not necessarily a goal for every type of app.
► Ex.Air traffic control
► Not knowing the extent of capabilities hampers novice or intermittent
► Experts like precise commands
► Data input/output types and rates vary greatly! 1:1000
► Combine with the OAI model and provide a visual
representation of options
► Overzealousness is hampering
► How can a system handle the high error rates with most
NLI?
 Natural Language Interaction
► Ex. Use NLI for finances
(Shneiderman ’80)
 ‘Pay $33 to University of Florida’
 91% accuracy
 Why isn’t it used now?
► Quicken, et. al., doesn’t use NLI
► Faster, easier to understand, visuals help
► Loebner Prize (’91) – Turing Test
 (
www.loebner.net/Prizef/loebner-priz ►Summary: sometimes developers
e.html believe NLI should operate w/o Direct
) Manipulation. This would be a
 researchers aren’t that enthusiastic mistake for many apps
► Mainstream – HAL, ELIZA
► Current:
 Dialog interaction is too difficult
 Rigorous evaluation of NLI
 Identify keywords in documents
 Visual recognition is just faster
 Speech Rec
► Problems: Predictable responses
 Natural Language Queries and
Question Answering
► Instead of full NLI, look at a subset
 Natural Language Queries
► Easier to parse
► Ex. AskJeeves
► If input to a database, it could be constrained enough
 But is it better than SQL?
► Study: SQL was faster (Small ’83, Jarke ’85)
► Case study: INTELLECT
 Search financial mainframe databases in the 80s)
 400 installations
 Text input for query
 Helps because keywords are well defined (like cities)
 Used fields to help structure input
 Used structured output to help train users on structured input
► Ex. PRINT THE CHECK NUMBERWS WITH PAYEE = MICROSOFT
 Novices still had a hard time, ideal user: knowledgeable intermittent
user
 Natural Language Queries and
Question Answering
► Other products:
 Symantec’s Q&A (late 80s)
 Microsoft’s English Query (’99)
► NLQA (Answering)
 Return a set of potential
answers
► Instead of an natural
language answer
► Reduce accuracy of response
► Let the user hunt
 Requires users to be domain
knowledgeable
 Domain of search could make
things difficult (terms like year
or pay)
 Questions need to be well
formed (not guaranteed)
 Text-Database Searching
► Text-Database searching using NLQ
 Court documents
 Photo/multimedia
 News
► Spectrum of approaches
 Understanding Query
► Finding synonyms
► Reduce noise words
► Handling singulars vs. plurals (stemming)
► Misspellings, pronouns, specific words
 Extraction
► Breaks down query into fields, does typical database lookup
► Good for large databases (legal, medical, etc.) with formatted queries
 Study: (Voorhees ’02), NLQ seems to provide rapid learning and
progress
 Provide more relevant searches vs. just keywords
 Still not returning exact search result
 Potentially faster (ex. user has partial information)
 Natural Language Text Generation
► Prepare structured reports using NL
► Goal: create stories?
► Sports game recaps, wills
► What’s the source?
 Database
 Interactive system
► Natural
language could help doctors (they
don’t want to switch gaze)
 Adventure Games and
Instructional Systems
► Recall old Zork or King’s Quest games?
 Problems: didn’t get the phrasing just
right…
 Pros: The ‘exploration’ is a plus since it
aids to the experience
 Cons: Too much exploration is frustrating
► Instructional Tutorials
 AutoTutor (Glassner) pg. 340
► Uses agents to help students
► A better interface for learning?
 Cognitive Tutor (Carnegie Learning)
► Teach math, geometry, algebra, etc.
 Provide feedback and guidance w/ NL
using accepted pedagogy approaches
► Helps students (Study: Di Eugenio ’02)