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 >=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

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 • 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

11. 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)

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

13. Abbreviation Guidelines • Simple primary rule • Secondary rule abbreviations should be denoted by some distinguishing character • Minimal use of secondary rule • Users should know the rules • Truncation should be used, except when too many similar actions • Fixed-length is preferable to variable length • Computer generated messages should NOT use abbreviations • Should be greater than >2 savings for abbreviations • Consider a command menu. • Ex. Imaging Control [really benefits only intermittent users] • 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.) • Can’t 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: • 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?

16. 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-prize.html) • researchers aren’t 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: • 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)

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 • What’s the source? • Database • Interactive system • Natural language could help doctors (they don’t want to switch gaze)

21. 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)