1 / 21

Command and Natural Languages

Command and Natural Languages. Human Computer Interaction CIS 6930/4930 Section 4188/4186. Intro. Languages are a natural way to communicate Communication with systems Initially, programming languages Scripting languages Database query Command languages

Download Presentation

Command and Natural Languages

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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)

More Related