1 / 65

What Users Want

What Users Want. Daniel Weld University of Washington. Variation. 4x. 625x. Two Interface Trends . Usage. Need Increased Customization Beyond changing buttons on the toolbar Overriding inappropriate adaptation High-level functionality Programming by demonstration.

yoshi
Download Presentation

What Users Want

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. What Users Want Daniel Weld University of Washington

  2. Variation 4x 625x Two Interface Trends Usage Daniel S. Weld / Univ. Washington

  3. Need Increased Customization • Beyond changing buttons on the toolbar • Overriding inappropriate adaptation • High-level functionality • Programming by demonstration “Steelcase-Inspired Software” -- David Gelernter • One Size Fits All • Need Increased Adaptivity • Beyond inconsistent defaulting • Adapt to available devices, connectivity, … • Adapt to user location • Adapt to user tasks & goals • Adapt to user calendar & current time (Some overlap with Contextual Computing) Daniel S. Weld / Univ. Washington

  4. Adaptivity & Customization • Deep Deployment ~ OS layer • Consistent Across Applications • Adaptation in every ‘dialog’ • Bridging Applications • Data gathering • Transformations Daniel S. Weld / Univ. Washington

  5. High-level Customization Pure Adaptation Outline • Motivation • Deliberative Software Agents • Programming by Demonstration • Adaptive Websites • Adaptive User Interfaces Daniel S. Weld / Univ. Washington

  6. Genesis: Internet Softbots [Etzioni & Weld CACM 94] • Interface Principles: • Goal-Oriented • Integrated • Balanced • Safe • User says what she wants • Agent determines how & whento achieve it •  planning-basedsoftbots Single, expressive & uniform interface E.g., printing files vs. FTPing them DT-lite: “Softbot must balance the cost of finding information on its own with the nuisance of asking the user.” Asimov’s first law… Safety, tidiness & thriftiness constraints in planner Daniel S. Weld / Univ. Washington

  7. Softbot Project Observations Rodney BargainFinder ILA Simon MetaCrawler Grouper Ahoy Info Manifold • Natural language interfaces • Popescu et al. • Yates et al. • Programming by demonstration ShopBot Occam Wrapper Induction } LSD Wed 10:15 Razor Mulder … Tukwila GLUE Piazza Gplex UW Softbot Family Tree • Specifying goals is bottleneck • Logical spec. language ?!$@#! • Forms interface • Limited to anticipated use • Not scalable • Often easier to just do task! • Except: data integration tasks Daniel S. Weld / Univ. Washington

  8. High-level Customization Pure Adaptation Outline • Motivation • Deliberative Software Agents • Programming by Demonstration • Adaptive Websites • Adaptive User Interfaces Daniel S. Weld / Univ. Washington

  9. Programming by Demonstration [Lau & Weld IUI-99] [Wolfman et al. IUI-01] • If it’s too hard for users to specify goals • Let’s watch them… • And try to help • Like plan recognition • Initial domains: • Email • Text editing • Cross domain [Lau et al. ICML-01] Daniel S. Weld / Univ. Washington

  10. Gentle-Slope Systems C Click’nCreate (Multimedia Fusion) VBasic Hypercard MFC C C Plugins kCmds Difficulty of use Hypertalk Ideal Basic Sophistication of what can be created Adapted from Myers et al. Daniel S. Weld / Univ. Washington

  11. VBasic Turing Cplt Robust Programing None Previous PBD Little Varying Varying Lots SmartEdit SmartPython On / Off Loops,Cond Robust Minimal Objectives Demand on user Expressiveness Domain engr Robustness Macro Record None On / Off Straight Ln Brittle Daniel S. Weld / Univ. Washington

  12. SmartEdit 1 [Lau et al. ICML-01] Daniel S. Weld / Univ. Washington

  13. 2 Daniel S. Weld / Univ. Washington

  14. 3 Daniel S. Weld / Univ. Washington

  15. 4 Daniel S. Weld / Univ. Washington

  16. 5 Daniel S. Weld / Univ. Washington

  17. 6 Daniel S. Weld / Univ. Washington

  18. Move to next <!-- Delete to next --> PBD as a learning problem • Action is function : input state ® output state • Editor state: text buffer, cursor position, etc. • Actions: move, select, delete, insert, cut, paste,… • Given a state sequence, infer actions • Many actions may be consistent with one example • Challenge: Weak bias + low sample complexity Daniel S. Weld / Univ. Washington

  19. Version Space Algebra • Version space = set of complex functions • Define version space hierarchically • Combine simpler version spaces with algebraic operators • Union È: analogous to set union • Join : cross product with consistency predicate • Transform: convert functions to different types • Can factor a version space Daniel S. Weld / Univ. Washington

  20. … … … … SMARTedit's version space Daniel S. Weld / Univ. Washington

  21. Action Move Paste Insert Copy Cut Select Delete Fast Consistency • Test consistency of example against entire version space • Quickly prune subtrees • Innovations: • Independent join allows BSR representation Daniel S. Weld / Univ. Washington

  22. Preliminary User Study • 6 undergrad CS majors • 7 repetitive tasks with & later w/out SMARTedit • Tasks: 4 to 27 iterations, 1-5 min to complete • Evaluation metrics: • Time saved completing task with SMARTedit's help • % user actions (keyboard + mouse) saved • User feedback Daniel S. Weld / Univ. Washington

  23. Time saved using SMARTedit Time (sec) Cost Saved Six Users X X Task Number Daniel S. Weld / Univ. Washington

  24. Action Savings with SMARTedit Six Users Percent of Actions Cost Saved XXXX X X Task Number Daniel S. Weld / Univ. Washington

  25. Observations from PBD • Overhead of macro recorder UI is high • Most repetitive tasks short • How many shell scripts do you write / day? • Focus on pure adaptivity • E.g., automatic segmentation Daniel S. Weld / Univ. Washington

  26. High-level Customization Pure Adaptation Outline • Motivation • Deliberative Software Agents • Programming by Demonstration • Adaptive Websites • Adaptive User Interfaces Daniel S. Weld / Univ. Washington

  27. Early Adaptation: Mitchell,Maes • Predict: Email message priorities Meeting locations, durations • Principle 1: Defaults minimize cost of errors • Principle 2: Allow users to adjust thresholds Daniel S. Weld / Univ. Washington

  28. Adaptation in Lookout: Horvitz Adapted from Horvitz Daniel S. Weld / Univ. Washington

  29. Resulting Principles [Horvitz CHI-99] • Decision-Theoretic Framework • Graceful degradation of service precision • Use dialogs to disambiguate (Considering cost of user time, attention) Adapted from Horvitz Daniel S. Weld / Univ. Washington

  30. Principles About Invocation • Allow efficient invocation & dismissal • Timeouts minimize cost of prediction errors Daniel S. Weld / Univ. Washington

  31. Adapting to Small Screens Daniel S. Weld / Univ. Washington

  32. Visitor Proteus Web server Web Site Adaptation in Proteus [Anderson et al. WWW-01] • Architecture • Personalizing in two steps: 1. Learn model of visitor from access logs • Transform content per learned model • Hill-climbing thru space of websites • Transforms: shortcuts & elision • Decision-theoretic guidance Daniel S. Weld / Univ. Washington

  33. Guiding the Search • Expected utility based on model of visitor • Model learned by mining server access logs • Sum value of each screen of each page • Discount by difficulty of reaching screen from p • Depends on how manylinks followed and howmuch scrolling required = p Daniel S. Weld / Univ. Washington

  34. Proteus Empirical Study • Observe real users on the desktop • Info-seeking goals drawn from random distribution • Personalize based on observations • Measure performance on mobile device • Number of links and scrolls, amount of time • Compare unmodified and personalized sites • Half users did unmodified first, others vice versa Daniel S. Weld / Univ. Washington

  35. Average number links followed Daniel S. Weld / Univ. Washington

  36. Analysis of Proteus • Why Proteus worked well • Suggested useful shortcuts • Elided mostly unnecessary content • Why Proteus worked poorly • Sometimes elided useful content • Users didn’t find shortcut, tho it existed • Flaws with implementation more than concept Daniel S. Weld / Univ. Washington

  37. Principles • Saliency of new UI operations is crucial • How name shortcuts? • Eliminating features is dangerous • Must partition dynamicity • Maintain separate dynamic & static “areas” • Always allow previous navigational methods • Duplicate functionality if necessary • Accurate prediction also crucial Daniel S. Weld / Univ. Washington

  38. Partitioned Dynamism Daniel S. Weld / Univ. Washington

  39. Partitioned Dynamism Daniel S. Weld / Univ. Washington

  40. Partitioning Failure Daniel S. Weld / Univ. Washington

  41. Principles • Must partition dynamicity • Accurate prediction also crucial Daniel S. Weld / Univ. Washington

  42. Predicting User Behavior [Anderson et al. IJCAI-01] • Model as Sequential Process • Markov Models • Mixtures of Markov Models • Second-Order… • Conditioning on Position in Trace • Etc. # times sd was followed P(sd) = Total # visits to s Daniel S. Weld / Univ. Washington

  43. Weakness of Markov Models • Each state is trained independently • Abundant training data at one state cannot improve prediction at another state • Large state models require vast training data • Problematic since Web trace data is sparse • A single visitor views ~0% of any site • New & dynamic content not in training data Daniel S. Weld / Univ. Washington

  44. DPRM RMM Reasoning about Uncertainty PRM Bayes Net DBN Structure Relational Sequence MM Daniel S. Weld / Univ. Washington

  45. Relational Markov Models [Anderson et al. KDD02] • Domains often contain relational structure • Each state is a tuple in relational DB sense • Structure enables state generalization • Which allows learning from sparse data ProductPage ProductName StockLevel Apple_iMac in_stock Palm_m505 backorder Daniel S. Weld / Univ. Washington

  46. D: a set of hierarchical domains Defn: Markov Model Relational • Q: set of states • Pages in a web site • Each state ~ a relation ProductPage(Apple_iMac, in_stock) • p: init prob distribution • A: transition probability matrix • R: a set of relations Daniel S. Weld / Univ. Washington

  47. AllProducts … AllComputers … AllPDAs AllDesktops … AppleDesktops … … iMac … Domain Hierarchies ProductName Instance of relation with leaf values is a state, e.g. ProductPage(iMac, in_stock) Daniel S. Weld / Univ. Washington

  48. AllProducts … AllComputers … AllPDAs AllDesktops … AppleDesktops … … iMac … Domain Hierarchies ProductName Instance of relation with non-leaf values is a set of states: an abstraction, e.g. ProductPage(AllComputers, in_stock) Daniel S. Weld / Univ. Washington

  49. RMM MainEntryPage() ProductPage(AllProducts, AllStockLevels) CheckoutPage() … ProductPage(AllProducts, backorder) … ProductPage(AllProducts, instock) E-commerce Site: Markov Ver. m505_backorder.html main.html checkout.html iMac_instock.html dell4100_instock.html Daniel S. Weld / Univ. Washington

  50. s  d s d RMM generalization • Want to estimate P(sd) … but no data! • Use shrinkage • Can do this with abstractions of d and s • Let  be an abstraction of s and  of d   ? Daniel S. Weld / Univ. Washington

More Related