Command Natural Languages Human Computer Interaction CIS 69304930

Command Natural Languages Human Computer Interaction CIS 6930/4930 Section 4188/4186

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

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

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 Command Organization Strategies § # 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

Benefits of Structure ► Study: Error rates for UNIX ► Benefits § 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 § § § Learning Memory Problem solving ► Elegancy vs. Consistency ► Other examples § Apply ‘edit’ vs. ‘revise, change, replace’, etc. § Reduces error § § § ► 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) ► Symbols vs. Keywords ► § Ex. Source or ID is always a certain argument § § 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 § § § 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: Study: (Carroll ’ 82) ► ► ► 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 ► Study: (Black and Moran ’ 82) – pg. 328. Different terms for insert/delete § Resulted in specific > general (Barnard ’ 81) § § § 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 ► Error rates increase w/ more complex commands ► Abbreviation Strategies § Keyboard, pen (PDA), speech recognition, mouse § 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) § § § 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. 2. 3. 4. 5. 6. 7. 8. 9. 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. 1. 10. Ex. Imaging Control [really benefits only intermittent users] 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: ► Cons: (besides harder) § Don’t have to remember syntax or menu conventions § 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 ► Experts like precise commands ► Data input/output types and rates vary greatly! 1: 1000 intermittent 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 ► Current: § (www. loebner. net/Prizef/loebnerprize. html) ►Summary: sometimes developers § researchers aren’t that enthusiastic believe NLI should operate w/o Direct Manipulation. This would be a mistake ► Mainstream – HAL, ELIZA for many apps § § § 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. Ask. Jeeves ► 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 80 s) 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: ► NLQA (Answering) § Symantec’s Q&A (late 80 s) § Microsoft’s English Query (’ 99) § 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 § Auto. Tutor (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)