Command and Natural Languages

1
Command and Natural Languages

• Human Computer Interaction
• CIS 6930/4930
• Section 4188/4186

2
Intro

• Languages are a natural way to communicate
• 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.

3
Intro

• Languages negatives?
• User memory
• Could be cryptic
• Retention, learning, frustration
• Ex. Web addresses
• Class web page
• Initiate vs. respond (ex. Unix)

4
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!

5
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)

6
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

7
Command Organization Strategies

• Simple Command Set
• of commands of tasks
• Ex. MUDs
• Ex. Look, go, move
• Cons Large of commands
• Ex. VI
• Commands plus arguments/options
• Each command is followed by gt0 arguments
• Ex. Copy X Y
• Include keyword labels Copy FromX ToY
• Pros readability, fewer semantic errors, better
  for novices
• Cons increased syntax errors, slower for experts
• Hierarchical command structure
• Tree structure of commands (like menus)
• Lets create one for files
• Create,display,remove,copy, move
• File, process, directory
• File, printer, screen
• Easy to write tutorials

8
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

9
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

10
Naming and Abbreviations

• Lets look at UNIX
• mkdir (make directory)
• ls (list directory)
• cd (change directory)
• rm (remove file)
• pwd (print working directory)
• Whats wrong with these abbreviations?
• No standard method to derive them!
• Standards are important aid

11
Specificity vs. Generality

• Specific more descriptive
• General more familiar and easier to understand
• Study 2 week training session
• Resulted in specific gt 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)

12
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 dont mind typing
  out full names increases confidence (lt5 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

13
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 gt2 savings for
   abbreviations
9. Consider a command menu.
10. Ex. Imaging Control really benefits only
    intermittent users
11. Underscore critical letter (like in Windows)

14
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.)
• Cant do poems, freeform conversations
• Rough translations help w/ getting the jist of
  most things
• Ex. language learners

15
Natural Language Interaction

• NLI Star Trek-type cognition
• Pros
• Dont 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!
  11000
• 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?

16
Natural Language Interaction

• Ex. Use NLI for finances (Shneiderman 80)
• Pay 33 to University of Florida
• 91 accuracy
• Why isnt it used now?
• Quicken, et. al., doesnt use NLI
• Faster, easier to understand, visuals help
• Loebner Prize (91) Turing Test
• (www.loebner.net/Prizef/loebner-prize.html)
• researchers arent that enthusiastic
• 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

• Summary sometimes developers believe NLI should
  operate w/o Direct Manipulation. This would be a
  mistake for many apps

17
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

18
Natural Language Queries and Question Answering

• Other products
• Symantecs QA (late 80s)
• Microsofts 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)

19
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)

20
Natural Language Text Generation

• Prepare structured reports using NL
• Goal create stories?
• Sports game recaps, wills
• Whats the source?
• Database
• Interactive system
• Natural language could help doctors (they dont
  want to switch gaze)

21
Adventure Games and Instructional Systems

• Recall old Zork or Kings Quest games?
• Problems didnt 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)