@prefix vivo: . @prefix edm: . @prefix ns0: . @prefix dcterms: . @prefix skos: . vivo:departmentOrSchool "Science, Faculty of"@en, "Computer Science, Department of"@en ; edm:dataProvider "DSpace"@en ; ns0:degreeCampus "UBCV"@en ; dcterms:creator "Kersten, Mik"@en ; dcterms:issued "2011-01-27T19:23:43Z"@en, "2007"@en ; vivo:relatedDegree "Doctor of Philosophy - PhD"@en ; ns0:degreeGrantor "University of British Columbia"@en ; dcterms:description """By making information easy to browse and query, current software tools make it possible for knowledge workers to access vast amounts of information available in document repositories and on the web. However, when displaying dozens of web page search hits, hundreds of files and folders in a document hierarchy, or tens of thousands of lines of source code, these tools overload knowledge workers with information that is not relevant to the task-at-hand. The result is that knowledge workers waste time clicking, scrolling, and navigating to find the subset of information needed to complete a task. This problem is exacerbated by the fact that many knowledge workers constantly multi-task. With each task switch, they lose the context that they have built up in the browsing and query views. The combination of context loss and information overload has adverse effects on productivity because it requires knowledge workers to repeatedly locate the information that they need to complete a task. The larger the amount of information available and the more frequent the multi-tasking, the worse the problem becomes. We propose to alleviate this problem by focusing the software applications a knowledge worker uses on the information relevant to the task-at-hand. We represent the information related to the task with a task context model in which the relevant elements and relations are weighted according to their frequency and recency of access. We define operations on task context to support tailoring the task context model to different kinds of knowledge work activities. We also describe task-focused user interface mechanisms that replace the structure-centric display of information with a task-centric one. We validate the task context model with three field studies. Our preliminary feasibility study of six industry programmers tested a prototype implementation of the task context model and task-focused user interface for an integrated development environment. Our second study involved sixteen industry programmers using a production quality implementation of the task context model; these programmers experienced a statically significant increase in productivity when using task context. Our third field study tested a prototype implementation of the task context model for a file and web browsing application. The results of this study showed that task context generalizes beyond programming applications, reducing information overload and facilitating multi-tasking in a cross-section of knowledge work domains."""@en ; edm:aggregatedCHO "https://circle.library.ubc.ca/rest/handle/2429/30897?expand=metadata"@en ; skos:note "Focusing knowledge work with task context by M i k Kersten B . S c . (Computer Science) , Univers i ty o f Br i t i sh C o l u m b i a , 1999 A T H E S I S S U B M I T T E D I N P A R T I A L F U L F I L L M E N T O F T H E R E Q U I R E M E N T S F O R T H E D E G R E E O F Doctor of Philosophy in T H E F A C U L T Y O F G R A D U A T E S T U D I E S (Computer Science) The University of British Columbia January 2007 © M i k Kers ten, 2007 Abstract B y m a k i n g information easy to browse and query, current software tools make it possible for knowledge workers to access vast amounts o f information available in document repositories and on the web. However , when d isp lay ing dozens o f web page search hits, hundreds o f files and folders in a document hierarchy, or tens o f thousands o f lines o f source code, these tools overload knowledge workers wi th information that is not relevant to the task-at-hand. The result is that knowledge workers waste t ime c l i c k i n g , sc ro l l ing , and navigat ing to find the subset o f information needed to complete a task. This problem is exacerbated by the fact that many knowledge workers constantly multi-task. W i t h each task swi tch , they lose the context that they have built up in the browsing and query v iews . The combinat ion o f context loss and information overload has adverse effects on product ivi ty because it requires knowledge workers to repeatedly locate the information that they need to complete a task. The larger the amount o f information available and the more frequent the mult i - tasking, the worse the problem becomes. W e propose to alleviate this problem by focusing the software applications a knowledge worker uses on the information relevant to the task-at-hand. W e represent the information related to the task wi th a task context model in w h i c h the relevant elements and relations are weighted according to their frequency and recency o f access. W e define operations on task context to support ta i lor ing the task context model to different kinds o f knowledge w o r k activities. W e also describe task-focused user interface mechanisms that replace the structure-centric display o f information wi th a task-centric one. W e validate the task context model wi th three f ie ld studies. Our pre l iminary feasibi l i ty study o f s ix industry programmers tested a prototype implementat ion o f the task context model and task-focused user interface for an integrated development environment. Our second study invo lved sixteen industry programmers using a production quality implementation o f the task context mode l ; these programmers experienced a statically significant increase in productivi ty when using task context. O u r third f ie ld study tested a prototype implementat ion o f the task context model for a file and web b rows ing applicat ion. The results o f this study showed that task context generalizes beyond programming applications, reducing information overload and facil i tat ing mult i - tasking in a cross-section o f knowledge w o r k domains. i i Contents Abstract ii Contents iii List of Tables vii List of Figures viii Acknowledgements x 1. Introduction 1 1.1 Scenario 2 1.2 Thesis 5 1.3 Previous Approaches 7 1.3.1. Modu la r i t y Mechan isms 7 1.3.2. Annotat ions , Tagging , and E x p l i c i t Context M o d e l s 9 1.3.3. Impl ic i t Context M o d e l s 9 1.3.4. E x p l i c i t Task M o d e l s 10 1.4 A p p r o a c h 10 1.5 Example 12 1.6 O v e r v i e w 15 2. Model & Operations 16 2.1 Encod ing Interaction 18 2.1.1. Interacti on Events 18 2.1.2. Element Identity 19 2.1.3. Event Class i f ica t ion 19 2.2 Task Context Const ruct ion 21 2.3 Task Context Operations 24 2.3.1. Compos i t i on 25 2.3.2. S l i c i n g 26 2.3.3. Man ipu l a t i on 27 2.3.4. Induction 28 2.4 Task A c t i v i t y Context 29 2.5 M o d e l Summary 30 3. Implementation 31 3.1 Archi tecture O v e r v i e w 31 3.1.1. Br idges 34 3.1.2. M a p p i n g to Interaction His tory 36 i i i 3.1.3. Interaction M o n i t o r i n g 37 3.2 Integration 38 3.2.1. Task Context Projections 38 3.2.2. Task-Focused U I Mechan i sms 39 3.2.3. Task Management 41 3.2.4. Interaction His to ry Storage 43 3.3 M y l a r I D E Implementation 43 3.3.1. Task-focused U I for Programming 44 3.3.2. Inducing Interest 47 3.3.3. A c t i v e Search 48 3.3.4. Context Test Suite 50 3.3.5. Context Change Sets 51 3.4 M y l a r Browser Implementation 52 3.4.1. Nav iga t ion Support for Fi les and W e b Resources 53 3.4.2. Captur ing Interaction wi th F i les 53 3.4.3. Captur ing Interaction wi th W e b Resources 54 3.5 Implementation Summary , 55 4. Validation •— 56 4.1 Me thodo logy 57 4.2 Study I: Programmer Feas ib i l i ty Study 58 4.2.1. Subjects 58 4.2.2. M e t h o d and Study Framework 59 4.2.3. Results: Usage statistics 61 4.2.4. Results: Ed i t Ra t io Change '. 62 4.2.5. Results: M o d e l Feedback 63 4.2.6. Results: V i e w Feedback 64 4.2.7. Threats 64 4.3 Study II: Programmer F i e l d Study 65 4.3.1. Subjects 65 4.3.2. M e t h o d and Study Framework 67 4.3.3. Resul ts : A n a l y s i s and Ed i t Ra t io 68 4.3.4. Results: Qual i ta t ive analysis 69 4.3.5. Threats 71 4.4 Study III: K n o w l e d g e W o r k e r F i e l d Study 72 4.4.1. Subjects 73 4.4.2. M e t h o d and Study Framework 74 iv 4.4.3. Results: Task A c t i v i t y 74 4.4.4. Results : Task Context and F i l e Structure 76 4.4.5. Results: Task Context Contents 78 4.4.6. Results: Task Context M o d e l A c c u r a c y 79 4.4.7. Results : Feedback 80 4.4.8. Threats 82 4.5 Summary 83 5. Discussion 84 5.1 Improving Task Support and Context A c c u r a c y 84 5.1.1. W o r k i n g on M u l t i p l e Tasks Concurrent ly 84 5.1.2. Rela ted Tasks 84 5.1.3. Task Context L i f e c y c l e 85 5.1.4. T u n i n g the Sca l ing Factors 85 5.2 Improving the Task-Focused U I 86 5.2.1. Decorat ing Elements to Indicate Interest L e v e l 86 5.2.2. E x p o s i n g the Interest Thresholds 86 5.3 Co l l abora t ing w i t h Task Context 87 5.4 V i s u a l i z i n g Task Context 90 5.4.1. Spr ing Graph o f Task Context 92 5.4.2. Seesoft V i sua l i z a t i on o f Task Context 93 5.4.3. Interaction His to ry Chart 94 5.5 Future W o r k 95 5.5.1. Transforming and d i sp lay ing interaction history 95 5.5.2. Ex tend ing Support to Other Domains 96 5.5.3. Improving Interaction wi th Fi l tered V i e w s 96 5.5.4. U n i f i e d Interaction, Context , and State M o d e l 97 5.5.5. Cascad ing Contexts 97 5.5.6. Focus ing the W o r k w e e k 98 6. Related W o r k 100 6.1 Mechan isms for Identifying Relevant Structure '. 100 6.1.1. Query and Concern Management Too l s for Programmers 100 6.1.2. Search Engines and Col labora t ive F i l t e r ing 101 6.2 U s i n g Interaction to Create a Context 102 6.2.1. D i s p l a y i n g Usage-Based Context 102 6.2.2. R a n k i n g Search Results 103 6.2.3. Impl ic i t Search and Usage-Based Scop ing 103 v 6.2.4. M i n i n g User Interaction 104 6.3 Task Management Too l s 105 6.4 Information Focus ing User Interfaces 106 6.4.1. Information Vi sua l i za t ion 106 6.4.2. Software Vi sua l i za t ion 107 7. Conclusion 108 Bibliography 110 Appendix A User Studies 116 Ethics Cert if icat ions 116 Study I Questionnaire 1.18 v i List of Tables Table 2.1: D O I value intervals 17 Tab le 2.2: Task context operations overv iew 18 Table 2.3: Interaction event schema 19 Table 2.4: Interaction event classif icat ion schema 20 Table 2.5: Sample interaction history 21 Table 2.6: Illustrations o f topological properties o f the task context 24 Table 2.7: Compos i t i on operation 25 Table 2.8: S l i c i n g operation 26 Table 2.9: Man ipu la t ion operation 27 Table 2.10: Induction operation 29 Table 3.1: M y l a r frameworks 32 Table 3.2: Sca l ing factors used in M y l a r implementat ion 37 Table 3.3: Thresholds used in the M y l a r implementation 38 Table 3.4: Task context projection 39 Table 3.5: Task-focused U I mechanisms for exposing interest 40 Table 4.1: Subject comments related to information overload in Ec l ip se 58 Table 4.2: Demographics o f the ninety-nine participants 65 Table 4 .3: F i e l d study data and percentage improvement 69 Table 4.4: Accep ted subjects in knowledge worker study 73 Table 4.5: Task context activation 75 Table 4.6: W o r k items reported by subjects to be associated wi th tasks 75 Table 4.7: Task context content structure measurements 77 Table 4.8: Task context content size measurements 79 Table 4.9: Proportions o f task context model slices (direct interest on ly) 80 Tab le 4.10: Feedback on how much information relevant to the task was displayed 80 Table 4.11: General feedback 81 v i i List of Figures Figure 1.1: Information overload in the Ec l ipse I D E 3 Figure 1.2: Information overload when browsing files and web pages 4 Figure 1.3: N u m b e r o f files versus check- in transactions for Ec l ipse and M o z i l l a 8 Figure 1.4: Illustration o f task context 11 Figure 1.5: Task context wh i l e w o r k i n g on T I (above), and shortly after act ivat ing T 2 (below) 13 Figure 1.6: B r o w s i n g wi th task context 15 Figure 2.1: Const ruct ing and projecting a task context 17 F igure 2.2: C o m b i n i n g task context operations 27 F igure 2.3: Illustration o f task activity context 29 Figure 3.1: M y l a r architecture showing O S G i plug-ins and their dependencies 33 Figure 3.2: M y l a r p lug- in architecture and Java bridges 35 Figure 3.3: Task management facili t ies for activating and edit ing tasks 42 Figure 3.4: Decorat ion, f i l ter ing and ranking o f Java elements 45 Figure 3.5: Decorat ion, f i l ter ing and ranking o f various program artifacts 46 Figure 3.6: Automat ic fo ld ing and content assist ranking in Java editor 47 Figure 3.7: Propagated interest o f errors in the Package Exp lo re r 48 Figure 3.8: Propagated interest o f superclasses in the A c t i v e Hierarchy v i e w 48 Figure 3.9: Degrees-of-separation for A c t i v e Search 49 Figure 3.10: Elements and relations wi th predicted interest in the A c t i v e Search v i e w 50 Figure 3.11: Au tomat i c context test suite 51 Figure 3.12: Au tomat i c context change sets 52 Figure 3.13: M y l a r B rowse r showing Task L i s t and embedded E x c e l document 54 Figure 4.1: R a n k i n g o f elements, usage statistics 60 Figure 4.2: M y l a r 0.1, used for I B M study 61 Figure 4.3: M y l a r v i e w vs. standard Ec l ip se v i e w selections across subjects 62 Figure 5.1: M o c k u p o f threshold control U I 87 Figure 5.2: Context sharing initiated from the Task L i s t 88 Figure 5.3: M o c k u p o f overlay showing overlap between two team members ' contexts 90 Figure 5.4: Table layout showing interesting files 91 Figure 5.5: Task context tree v i ew showing relations o f elements 92 Figure 5.6: Force-directed layout o f task context 93 Figure 5.7: Seesoft v isua l iza t ion o f task context 94 v i i i Figure 5.8: V i sua l i za t i on o f interaction history wi th decay ignored 95 Figure 5.9: Focus ing the work week 98 Figure 6.1: Separation o f interaction-specific rankings from structure-based rankings 103 i x Acknowledgements M y deepest thanks go to m y supervisor, G a i l M u r p h y . G a i l has fueled my ideas, directed my efforts, and taught me the value o f research. Her incredible m i x o f unwaver ing encouragement, cr i t ical questioning, and insightful advice were key to the success o f this work. G a i l ' s clear pr inciples and empir ica l approach to creating and val idat ing new technologies w i l l continue to guide me and provide an example that I hope to emulate throughout m y career. I also thank Gregor K i c z a l e s and Tamara Munzne r , whose questions and feedback have helped shape the directions o f this work. I am grateful to the other members o f my supervisory and examin ing committee who have generously contributed their t ime and expertise: E r i c h G a m m a , D a v i d Poole , Y a i r W a n d and V i c t o r i a Be l lo t t i . Th i s effort w o u l d not have been possible without the advice and perspective o f m y wife , A l i c i a Kersten, w h o supported me throughout. I w o u l d also l ike to thank the rest o f my fami ly ; our ki tchen table arguments were my introduction to cr i t ica l th inking . In particular, I thank m y father, Gregory Kers ten , who convinced me to do my doctorate, and w h o inspires me more than anyone I k n o w . I thank Jul ie Waterhouse o f I B M for m a k i n g the feasibil i ty study possible and the I B M Centre for A d v a n c e d Studies and N S E R C for supporting this work. F i n a l l y , I thank the M y l a r user and developer communi ty , whose feedback and efforts continue to help the technology grow. M i k Kers ten The University of British Columbia, January 2007 x 1. Introduction K n o w l e d g e workers develop and use information in the workplace [19]. The software tools that knowledge workers use to browse and query the information systems wi th w h i c h they work make the structure o f those information systems expl ici t . A s one example, file browsers enable the hierarchical navigation o f directory structure. A s another example, W e b query tools often rank the hits they return using properties o f the hyper l ink structure. However , when used on very large information systems, these structure-centric v iews can overload the user wi th information because the relevant subset o f information is often scattered across the structure. Whether browsing the hundreds o f files and directories in a document repository for a few key files o f interest or l o o k i n g through dozens o f web search hits for a particular page, users must manual ly sift, sc ro l l , and c l i c k through deep hierarchies and long lists to f ind the subset o f information relevant to the task-at-hand. This information overload problem is inherent to tools that display information based on structural properties instead o f focusing* on the subset o f the information that is relevant to the user's task. Information overload problem: Many knowledge work tasks cut across the structure of an information system. As a result, tools for browsing and querying system structure overload users with information that is not relevant to the task-at-hand. I f knowledge workers a lways completed the current task before proceeding to work on another, perhaps they cou ld commit a l l o f the relevant information to their memory or manual ly maintain a l i s t ing o f the artifacts o f interest. However , one study found that a group o f knowledge workers performed ten tasks a day on average, spending only eleven continuous minutes on any particular task before swi tch ing to another [26]. A l l too often, before comple t ing the g iven task, a worker must swi tch to a higher priority task that requires immediate attention. There is a concrete cost to such task switches; w i t h each switch, workers waste t ime repeatedly ident ifying the relevant information. Th i s loss o f context complicates mult i - tasking, w h i c h is further exacerbated by the t ime it takes users to recreate their context manual ly in the presence o f information overload. Context loss problem: Browsing and query tools burden users with finding the artifacts relevant to the task-at-hand. This context is lost whenever a task switch occurs. When multi-tasking, users continually waste time recreating their context. 1 1.1 Scenario The larger the information system that needs to be accessed by the knowledge worker , the more onerous the information overload and context loss become. In the software development domain o f knowledge work , the information systems o f interest are the software applications and frameworks that programmers create and integrate. M a n y modern applications and frameworks consist o f mi l l i ons o f lines o f code' . Current integrated development environments ( IDEs) , such as Ec l ipse I D E 2 and V i s u a l S tud io 3 , make these mi l l i ons o f lines o f code instantly accessible to the programmer through sophisticated indexing and search facil i t ies. However , when w o r k i n g on any particular task, such as adding a feature to an applicat ion, the programmer is only interested in a very smal l portion o f the code on w h i c h he is bu i ld ing . H e may try to use query tools to help identify the information relevant to the task, but as this information often cuts across the system structure, it is diff icult to formulate adequate queries wi th in a reasonable amount o f t ime. Al te rna t ive ly , he may try to tag parts o f the structure w i t h bookmarks or other annotation mechanisms, but constant tagging and searching is burdensome. L o n g lists o f tags can also contribute to information over load when a new and higher priori ty task needs attention, since they may not be relevant to the new task. Cons ider the concrete example o f a programmer t ry ing to understand w h y some o f the test cases for de-serial izat ion are fa i l ing in the moderately s ized W e b Services Invocation Framework ( W S I F ) 4 . T o complete this task, the programmer must examine the test cases, the classes that are fa i l ing to de-serialize, and the serial izat ion po l i cy employed in the system. U s i n g the Ec l ipse I D E , the programmer decides to f ind a l l subtypes in the W S I F code base that implement the S e r i a l i z a b l e interface, and to inspect the setter methods in those classes. Figure 1.1 shows a snapshot o f the Ec l ipse I D E after the programmer is part way through comple t ing this task. 1: The Package Explore r v i e w has become difficult to use because it includes thousands o f nodes—a result o f only a handful o f navigat ion c l icks through project files and related library classes. Hierarchica l relationships are no longer v i s ib le without manual sc ro l l ing through the tree. 2: In part thanks to how easy Ec l ipse makes navigat ing structural relations, the number o f open editors can qu i ck ly bloat to several dozen when w o r k i n g on a moderately-sized task, m a k i n g the editor list a poor 1 The full set of Eclipse frameworks is 7M lines of code and the Windows Vista OS is 50M, http://en.wikipedia.org/wiki/Source_lines_of_code [verified 2006-10-02] 2 http://eclipse.org [verified 2006-10-02] 3 http://msdn.microsoft.com/vstudio [verified 2006-10-02] 4 http://ws.apache.org/wsif (1,897 classes) [verified 2006-10-02] 2 representation of the files currently relevant to the task [14]. Although using the \"Close all editors\" command cleans up this list, it also discards the editors that are relevant to the task. 3: Using Eclipse's Java5 Search to look for references to S e r i a l i z a b l e within the project has returned 144 items. There is no convenient way to search for only those elements related to the task of fixing the failing test cases. Instead, the search result list requires manual inspection to find elements of interest. 4: Even though the Outline view only shows the structure of the current file, it is overloaded with dozens of elements that are not relevant to the task. 5: The Type Hierarchy view shows all types in the project that extend S e r i a l i z a b l e , and contains thousands of elements that must be manually inspected to identify those relevant to the task. 03 Java - WSIFMessage.java - Eclipse Platform Fte Edit Source Refactor Navigate Search Project Run Window Help J n - o I * * o ~ a * ] os # @ * j * # | :* Package Explorer : \" 3 iii WSIFSer,.. Ii WSIFMes... .1 WMF Ses. ElWSIFReq.., + foib ObjectOutput,class *V •+ ObiectOutpur.5tream.ck + Ob)ect5r.reamClass.clas: ;+ foi} ObjectStrearnConstants + fa,) Ob)ect5treamException f u Ob jectStrearnFleld, class '+ foj OpttonalDataException. * V » OutputSr.ream.dass + j § Outpur.StreamWrlter.cla + \\ „ PipecHnputStream.class + PipedOutputStream.cIa; + 'cip PipodReader.class + o,e PipedWnter.class + ; y , PrintStream. class / ^ \\ * PrintWriter.class f J J + fjiip PushbacUnputStrearVw-^ + OK PushbackReader.dass * (HI RaodomAccessFile.class * Reader.class + \\ t i SequeneelnputStream.c + o, Seriali?able.class < oio Ser.ali.'ablePernussion.cl + f«H StreamCorruptedExcept * ,.t StreamTokenlzer.class * f»r* StringBufferlnputStrean * ; 0,', StnngReader.class * 31* SMngWnter. class & f»ii SyncFailedException.cIa !+ K,t UnsupportedEncodingE> it {ojf UTFDataFormatExceptk + f0|', Win32FiIeSystem.class i| $ WinNTFileSystem. class * mf WriteAbortedException. + Writer.class t£j JavaJang £*} Java.lang.ref ttl Java.lang.reflect ££1 Uu> rut-h [> m * Q a u t h o r O v e n B u r r o u g h s - c o w e r i b Q a p a c h e . orgj> * a u t h o r A n t E l d e r < a n t e l d £ r B * r . < « c h e . & r g > « < ? n i t h o r J e r e m y H u g h e s Z> * t r l a u t h m H a r k W h i t l o r k < w h i t l o c r k S a p - a t r h e . o r g v v v p u b l i c i n t e r f a c e W S I F H e s s a g e e x t e n d s j a v a . i o . S e n a l i z a b l * o e t t h e name ot t h i s m e s s a a e . p u b l i c S t r i n g g e t N a m e ( ) ; • S e t ':h-s name ot t h i s r ue ^ s - t y e . V p u b l i c v o i d s e t N a m e ( S t r i n g n a m e ) ; H & M y t a r ! ^ J 3 a v a * Hierarchy S3 a • Hierarchy : Serializable L. a t ^ » • i \" R e t u r n l i s t o t p a r t n a m e s . * ; p > - : t ' > N O T E : < / b : p o r t n a m e s a r e p u b l i c I t e r a t o r g e t P a r t N a m e s ( ) ; &•• © A Abstract Action C | ExitAction / ^ \" N . (J LoadXMLAction f C ) 8 i c ) A Atistr^ctListModel V 3 / Q s StackTraceListModel $ © CflfaUtTaUmxW © LogTableModel © FlteredLogTaoleModel Q MyTableModel B © ArrayLsi; © ArraytistExtension © HandlerChainlmpI 0 Attribute © BeanDesertaHzer © BeanSerializer iti (g i* Calendar <& s Char Token 0 i £ ClosureToken © ComplexContent © ComplexTyp© C r e a t e a n i t e r a t o r o f Problems Javadoc Declaration Search F* Edt VMW fsvomet rob H j 0Wi * W ' iii* V ' > i M n *i j'jg; r u d e r * jTH]-* t - f - * . C : K o M ¥ » * r « T « e M o d e l F o l d c r i P j^ j Mvkw-rYtfnatJtodal m | * w x f i i s c a . n a . u a , ( 0 J 6 s e c o n d s ) Official Guido to Canadian Law Schools SOWUHI-MI Lttu B e c a m e ( h e n u m b e r o f p r a c t i c i n g l a w y e r s i r C a n a d a c o n t i n u e s t o i n c r e a s e , i t m a y b e c o m e m e r e d i f f i c u l t fat r e c e n t g r a d u a t e s : o f i n d j o b s in s o m e f i e l d s in ... w w « . ! « a t M i / C A n a d i r i i K ^ C.Virti)»(at*2 r ^ p T u r i • i a w C r w i w n u n • - tdBfeM • SfflftLMBM Canada irrv'iifjnljr: V/hy Hue -m rr-r-.qraTi-m Lawyer - Ca'ia Ji rin _ A l a r g e n u m b e r c f i t s c u r r e n t m e m b e r s h i p c o m p r i s e o f f o r m e r i m m i g i a i i o n o f f i c e r s w h o h e i ... S e m e a* I s m e m b e r s a r e Qirebec Lawyers L o c a t e e x p e r t l a w y e r s i n Q u e b e c V i s i t L a w y a r s . c o m & s e a r c h f r e e Number O f L a w y e r s I T s F r e e ! G e t t h e I n f o Y o u N e e d More m o u s e c l i cks to re-search G o o g l e t h a t o f f e r s a t e g u l a r c o u r s e K o r e a n L a w ... A i . a n d p r a c t i c i n g ... i> • )• i ru Lawyers.. | e w y e ' L o o k u p l i n t \" P r o v i d e s n a n p r a c t i c i n g s l e i u s . . . F i g u r e 1.2: I n f o r m a t i o n o v e r l o a d w h e n b r o w s i n g f i l e s a n d w e b p a g e s 4 1.2 Thesis The tools that knowledge workers use for w o r k i n g wi th information systems understand the structure o f those systems and make that structure easy to navigate. Fo r example, a Java I D E understands method ca l l syntax and makes it navigable; an H T M L browser understands hyper l ink syntax and makes that navigable. Incorporating an understanding o f information system structure into tools assists users by m o v i n g the burden o f identifying the structural elements and their relations from the user to the tool . The tools that knowledge workers currently use do little to assist them wi th understanding the content o f an information system. Instead, knowledge workers rely on semantic memory to recall and identify the parts o f the system relevant to a particular task. Semantic memory requires mult iple exposures to each referent, wi th each exposure updating the memory [61]. Semantic memory is w e l l suited to w o r k i n g wi th smaller information systems where knowledge workers can become famil iar wi th a substantial port ion o f the system in a reasonable amount o f t ime. However , when w o r k i n g wi th a large system, the l imitations o f semantic memory become apparent. It is not possible to remember everything when w o r k i n g wi th such a system and the information that is remembered can qu ick ly become obsolete. The result is that knowledge workers spend an inordinate amount o f t ime reminding themselves o f the bits and pieces o f an information system that they need to understand to complete a task. There is another k ind o f memory at a knowledge worker ' s disposal . Ep i sod ic memory is referred to as a one-shot learning mechanism, in w h i c h only one exposure is required to remember the event, and is described as a map that ties together semantic memories [61]. Our goal is to increase the complex i ty o f the information systems wi th w h i c h knowledge workers can work effectively. Our approach is to off- load semantic memory and to leverage episodic memory. A c o m m o n form o f episode for knowledge workers is the tasks that they perform, where a task is defined as \" a usual ly assigned piece o f w o r k often to be finished wi th in a certain t ime\" [1]. R e c a l l i n g tasks worked on previously uses episodic memory, mak ing tasks inherently easier to recall than the semantics o f a complex information system. Our approach makes tasks an expl ic i t part o f knowledge work. Instead o f forcing knowledge workers to recall system structure, we provide a facil i ty for recal l ing a task worked on previously and we then automatically present the system structure that was relevant to that task. B y capturing the interaction the user has w i t h the structure o f an information system dur ing each task episode, we br ing together the parts o f the information system that are relevant to the task. W e ca l l this subset o f information relevant to a task the task context and fo l l ow the semantic memory concept o f reinforcement [55] by automatical ly weight ing the pieces o f information according to frequency and recency o f access. The only burden that we impose on knowledge workers is the need for them to indicate the episodes by defining and act ivat ing the tasks on w h i c h they work . 5 Thesis: A model of task context that automatically weights the relevance of system information to a task by monitoring interaction can focus a programmer's work and improve productivity. This task context model is robust to both structured and semi-structured information, and thus applies to other kinds of knowledge work. W e present a model and mechanism for creating a task context, w h i c h captures and persists the elements o f information and relations between elements o f information that are relevant to a task, and weights the relevance o f each according to the frequency and recency o f access. W e create a task context by moni tor ing a user's activity and extracting the structure o f the under ly ing information system's elements and relations. Operations on task context integrate the model w i t h knowledge work applications, p rov id ing features such as automatic search, automatic change management and context display. Together, the model and operations enable an applicat ion to present on ly the information relevant to the task-at-hand. This focus reduces information overload and prevents context loss when mult i - tasking. T o test the task context model , we conducted f ield studies wi th professional programmers and other kinds o f professional knowledge workers. Since the work items invo lved in programming are wel l -def ined and broad, inc lud ing adding code for features and edi t ing code to f ix bugs, we were able to define a measure o f programmer productivi ty cal led edit ratio. W e have shown wi th statistical s ignificance that the edit ratio o f sixteen programmers in our field study improved wi th the use o f our task context model . Our field study i n v o l v i n g knowledge workers was qualitative. For eight subjects representing a cross-section o f professions ranging from administrative assistants to a C T O , we found that task context supports the information artifacts wi th w h i c h they work and that the frequency and recency-based weight ing can reduce information overload in a cross-section o f knowledge w o r k domains. The key contribution o f this thesis is a generic task context model that represents interaction w i t h any structured or semi-structured information, where the weights i n the model correspond to the frequency and recency o f a user's interaction wi th the information. W e demonstrate that this weight ing reduces information overload and that capturing context per-task reduces context loss when mult i - tasking for both programmers [39] [41] and other k inds o f knowledge workers [40]. Our secondary contributions are a real izat ion o f task context col laborat ion facili t ies [38] and a study framework suitable for moni tor ing product ivi ty and tool usage in the field [52]. W e have deployed our implementat ion o f task context for Ec l ipse as an open source framework cal led M y l a r 6 , a programming tool cal led M y l a r I D E , and a prototype file and web brows ing tool cal led M y l a r 6 \"Mylar\" is a) an aluminized film used to avoid blindness when staring at a solar eclipse b) a focused user interface used to avoid information blindness when staring at Eclipse. The latter is hosted as an open source project led by the author http://eclipse.org/mylar [verified 2006-10-02] 6 Browser . W e estimate that tens o f thousands o f programmers 7 currently use the M y l a r I D E tool . The M y l a r f ramework is also being used to support task context i n other domains 8 . 1.3 Previous Approaches W h e n w o r k i n g wi th a smal l information system, whether it is an example program or a smal l co l lec t ion o f web pages, information overload is rarely a problem because the information relevant to a task can be recalled. A s the size o f information systems has grown, several approaches have been introduced to help knowledge workers manage the increase i n complexi ty . E a c h approach supports the capture o f a subset o f the system. The more a subset lines up wi th the structure a user needs to k n o w about to perform a task, the more effective the mechanism is at he lp ing the user work on the system. In this section, we describe approaches that apply to both programmers and other kinds o f knowledge workers . W h e n a dis t inct ion is needed, we identify programmers expl ic i t ly . W e use the term system to refer to both software systems and other kinds o f information systems, and specify the scenarios where a dis t inct ion matters. 1.3.1.Modularity Mechanisms The better the modulari ty o f a system, the more loca l ized code changes become [3]. B y enabling encapsulation and po lymorph ism, object-oriented programming ( O O P ) [13] helped local ize many changes to one or a smal l number o f places wi th in the type hierarchy o f a software system. A s software systems continued to grow, aspect-oriented programming ( A O P ) mechanisms made it possible to encapsulate parts o f the system that crosscut the object hierarchy [42]. A l t h o u g h modulari ty approaches have increased the system complex i ty that can be managed by a programmer, they have not so lved the problem o f information overload. They assume that a programmer w i l l often be able to find a desired piece o f the system by traversing the modular structure and that modif icat ions w i l l often fit w i th in the modular structure so that once the point o f interest is identified, it w i l l be relat ively easy to perform the desired modif ica t ion. W e have observed two problems wi th these assumptions. First , many modificat ions to a system are not l imi ted to one module. For example, we found that over 9 0 % o f the changes commit ted to the object-7 Each monthly release of Mylar IDE is installed by thousands of users from the main http://eclipse.org/mylar install site, and is also redistributed by commercial vendors. Links to vendors, user blogs, as well as articles citing productivity improvements are at: http://eclipse.org/mylar/archive.php [verified 2006-12-12] 8 The CHISEL group at the University of Victoria uses Mylar's task context model for adaptive ontology visualizations in a Swing-based RDF/OWL browser: http://www.thechiselgroup.org/diamond [verified 2006-10-02] 7 oriented Eclipse and Mozilla 9 source repositories, over a period of one year, involved changes to more than one file [51] (Figure 1.3). We then randomly selected twenty changes from Eclipse and found that 25% of these transactions involved significantly non-local changes. Second, even when the actual changes related to a modification are within some form of module, say one Java package, a programmer often needs to know how this module works within the system, requiring him to access many other modules and understand their interconnections [58]. While A O P can help by improving the system's modularity, we have observed that there will still be tasks that are not localized in a single aspect, for example involving multiple classes, aspects, and extensible markup language ( X M L ) files [39]. As such, modularity approaches alone are not sufficient for defining and managing the subset of information relevant to the various tasks on which a programmer works. The result is that a programmer must spend a substantial amount of time navigating around a system's modularity to identify the relevant information. 16000 14000 12000 10000 8000 6000 4000 2000 0 1 F 1 • . 1 • eclipse • rrozilla 1 2 3 4 5 6 > 7 Figure 1.3: Number of files versus check-in transactions for Eclipse and Mozilla IDE support for modularity mechanisms makes the structure of the modularity easily navigable by a programmer. Early versions of such tools made it possible to follow hyperlink-style references to other parts of the program. Current IDEs have augmented this support, providing views that make the entire object-oriented and aspect-oriented structure of the system navigable through structure views. For example, all subtypes of a given type may be found using a type hierarchy tree view. Another common mechanism for exposing modular structure is query and cross-reference support. For example, O O P tools commonly support a query to show all methods that could override the selected method. Similarly A O P tools display cross-references from a method to all of the advice that could apply to it [35]. Structure views and queries have made it possible to navigate the structure of a software system. As shown in Figure 1.1, these structure views typically show thousands of elements, only a small number of which are relevant to the task-at-hand. Similarly, query results often have hundreds of matches. The result 9 http://mozilla.org [verified 2006-10-02] 8 is that programmers can spend more time sc ro l l ing and navigat ing then programming. K n o w l e d g e workers w o r k i n g wi th file and web pages face a s imi lar situation when using recommender systems and search engines that provide heuristics for ordering or f i l ter ing results o f searches. Heuris t ic rankings based on structural information, such as the l ink structure between documents [8], are ignorant o f the user's task and thus include elements irrelevant to the task. A l t h o u g h recent research in search engines has attempted to address this l imi ta t ion by using personalization data in rankings, these rankings are biased by a l l o f a user's past act ivi ty and are not focused on her current task (Sect ion 6.2.2). 1.3.2. Annotations, Tagging, and Explicit Context Models One way to describe the addit ional properties o f an information system is to use metadata. The metadata facil i t ies exposed by current development environments for software systems vary in how closely related the data is to the program code and in the amount o f structure present in the result ing metadata. Fo r example, the Java and . N E T 1 0 platforms' textual annotation mechanisms a l l ow addit ional properties to be declared on program elements. The subset o f the software system defined by annotations that match a particular property can then be operated on by annotation processing tools and exposed in the I D E ' s structure v iews (e.g., to show al l methods marked © T r a n s a c t i o n a l ) . Mechan i sms for ' tagging ' or ' b o o k m a r k i n g ' elements through the I D E ' s editor and v iews can be used in a s imi lar way to annotations to mark the elements that should form a particular subset o f interest, w h i c h can then be v iewed . Ec l ipse ' s support for w o r k i n g sets is a good example o f how such a subset can be integrated into an I D E . Entire system components can be tagged as belonging to a particular w o r k i n g set. V i e w s that show the hierarchical structure o f the system can then group the system by w o r k i n g sets. Annota t ion and tagging mechanisms do provide a way to identify relevant elements. However , they are not sufficient for capturing task context. The key problem is that they require manual work from the programmer to do the tagging. A second problem is that when used more heavi ly , for example wi th support for col laborat ive tagging [63], or as manifest by the behavior o f Ec l ipse ' s automatically reported source code comments matching a particular pattern (e.g., \" / / T O D O : f i x \" ) , v iews that report these tags become overloaded when used on large systems. 1.3.3. Implicit Context Models A n alternative to hav ing the user manual ly create a context is to use interaction wi th the tool to define the context. The simplest examples are tools that use the currently selected element to show related elements, or iginat ing wi th Interlisp's Masterscope [67]. The Edi t & Read Wear [31] document edi t ing tool 1 0 http://microsoft.com/net [verified 2006-10-02] 9 formal ized this concept in the document processing domain by h ighl ight ing selection patterns across a document. A s a programmer works in an I D E , the files that have been opened, often v is ib le through the editor tabs s imi lar to those in tabbed browsers\", also reflect a context created from the programmer 's interaction. Such imp l i c i t l y determined models can be used to focus the user interface to show only the subset o f information that is in the context. The key benefit o f an impl ic i t approach is that it removes the burden o f creating the context from the user. However , consider ing the amount o f interaction that a knowledge worker produces in a typical week [30], and the fact that it is typ ica l for them to work on many tasks in a single day [26], a s imple model o f this form does not scale to resolving the information overload that occurs on long-running tasks and to the context loss that results from task switches [39]. 1.3.4. Explicit Task Models A task corresponds to a unit o f w o r k (Section 1.2). Fo r a programmer, a typica l task is a bug to f ix or a feature to add. For another k ind o f knowledge worker , such as a lawyer, a typica l task is complet ing a contract or drafting up a w i l l . Approaches that make a representation o f task expl ic i t can provide a natural scoping mechanism to address some o f the problems wi th the approaches described above. For example, some tools a l l ow files to be attached to tasks, such as the B u g z i l l a bug tracker used by programmers 1 2 . However , this approach places the same burden on the user as expl ic i t tagging. T o address this burden, the TaskTracer tool [18] provides an alternative by combin ing expl ic i t tasks wi th an impl ic i t per-task tagging o f resources, such as the files opened when w o r k i n g on a task. However , TaskTracer adds information to a task in a monotonica l ly increasing fashion. In terms o f reducing information overload, this approach assumes the information accessed for a task is wel l -scoped, w h i c h may not be the case for long-running or recurring tasks. It also assumes that a user w i l l not make any missteps in dec id ing what information is relevant to the task. I f the user does accidentally select the w r o n g resource, or i f a resource loses relevance over time, this approach burdens the user wi th manual ly indicat ing w h i c h resources are no longer relevant to the task. 1.4 Approach Our approach involves moni tor ing the user's activity wi th a software applicat ion in order to create an interaction history for a particular task. A n interaction history is comprised o f a sequence o f interaction events, each o f w h i c h captures a user's interaction wi th the specific elements and relations in an information system. The moni tor ing faci l i ty needs to report the elements and relations that are the target ' 1 Browsers, such as Mozilla, provide tabs that allow one window to nest multiple pages. 1 2 http://bugzilla.mozilla.org [verified 2006-10-02] 10 of the interaction, as well as the kind of interaction. We focus on capturing interaction events corresponding to the user's selections, edits, and commands. To support associating interaction histories with tasks, we also require a mechanism for determining task boundaries. Given an interaction history for a task, we transform the sequence of interaction events into a task context, which weights each element according to its relevance to the task. Our task context model uses a degree-of-interest (DOI) [45] weighting for each element and each relation based on frequency and recency of access. Different kinds of events can correspond to different weightings. Our goals are to make the model predictable to the user and to ensure that the DOI values capture the relative relevance of elements and relations over the lifecycle of a task. The frequency portion of the weighting ensures that elements and relations accessed most have the highest interest weighting, while the recency weighting ensures that the interest of elements not accessed recently decays. To integrate task context with the various activities that a user performs when working with an application, we have defined operations on task context. The slicing operation can gather a subset of the context, such as the elements above a particular DOI threshold. The composition operation makes it possible to combine multiple task contexts when an activity involves interaction with multiple tasks. We also provide an induction operation for propagating interaction events to structurally related elements; this adds the structurally related elements to the task context even though the user has not interacted with them directly. For example, when a user selects a file, an induction operation can propagate interest to each of the folders in the containment hierarchy of that file. Operations such as induction need to understand the structure of the underlying information system. Each information system can be composed of one or more kinds of domain structure, such as a Java program and a file hierarchy. We define bridge mechanisms that map between domain structure and interaction events. The more detail the bridge understands of the domain structure, the higher the fidelity of the task context model. For example, if an application supports monitoring interaction with elements within a file, such as the classes and methods in a Java file, the task context model can weigh the relevance of that structure, rather than just weighing interactions at the level of the file and the folder hierarchy containing the Java class. F i g u r e 1.4: I l l u s t r a t i o n o f t a s k c o n t e x t 1 1 Figure 1.4 illustrates a task context as a graph in w h i c h the heights o f the elements represent their D O I weightings. The Java class node at the top o f the diagram is most interesting because the programmer has selected and edited it the most. A l o n g the left o f the figure, we see that interest has propagated to two superclasses that the user has not yet selected (indicated in the figure wi th lower saturation). W e also see that a method in the model has decayed in interest to the point that it is be low the D O I threshold depicted by the gray plane. T o focus an applicat ion on a particular task, the task context model needs to be displayed. W e cal l the mechanisms that display the task context model the task-focused user interface (UI). W e have defined several task-focused U I mechanisms that support the display o f task context in exis t ing applications, inc lud ing D O I filtering, ranking, decoration, expansion management, and appl icat ion w i n d o w management (Section 3.2.2). A s one example, a structure v i e w that normal ly shows the entire system structure can be focused to show only the elements wi th in the task context that are above a particular D O I threshold. T o display task context in an applicat ion 's exist ing structure v iews, the appl icat ion needs to support one or more o f these mechanisms. F o r example, i f a file browser has a mechanism to filter elements pr ior to display, this mechanism may be extended to support f i l ter ing based on D O I values. 1.5 Example In this section, we demonstrate how expl ic i t task context and task-focused U I mechanisms address the information overload problem, us ing as an example the M y l a r code base, w h i c h contains over a thousand Java classes. Cons ider the scenario o f a programmer w o r k i n g on a s imi lar task to that presented earlier: refactoring a po l icy defined by a class, w h i c h affects uses o f that class in the system. However , this t ime the programmer uses a Task L i s t to indicate the task on w h i c h he is currently w o r k i n g (v ia the \"radio button\" indicator v is ib le in Figure 1.5-1 to the left o f the task o f interest): T I : Refactor ResourceStructureBridge Th i s task involves ident ifying, inspecting and changing al l o f the clients o f R e s o u r c e S t r u c t u r e B r i d g e . A c t i v a t i n g the task causes the task context model to track the parts o f the system artifacts—the program elements and relations—that are accessed wh i l e the programmer works on this task. 12 Demo - ResourceStructureBr idge. java - Eclipse SDK U S B File Edit Source Refacjor Navigate Search Project Run Window Help 7~ ^ r ^ ^ H j s a n H n n m m n H n r — « f* Package Expl... Bs Navigator • : -. v | t a^ j p a ^ S ko org.eclipse.mylar.ide [dev.edipse.o ET 4 JDemo ResourceStructure... 1 Task List S3 IB S \\ \" I 00 O - : t f i org.eclipse.mylar.internal.ide Ei yj ResourceChangeMonitor.ja Ei ^ ResourceChangeMonito * setEnabled(boolean; - L i ResourceStructureBridge.]; - ResourceStructureBi 5,' CONTENT_TYPE People - Rob [bugs.e a as Products - Eclipse [btivj [L] Outline 3 Active Search (... U \\ 1 = 1 D I ... J * ' % ' \" p u b l i c Jb j ec t g e t C b j e c t F c r H a n d i j v ; [»1 Problems = u Synchronize K • CVS {/org.eclipse.mylar, /org.eclipse.mylar-feat...lar.z6 5° ' Cfi 0 0 S I i f (\"jj SB * ! J> | 43 B 4S T I : Refactor ResourceStructureBridge [3j»> ResourceStructureBridge.java - /org.eclipse.r @| ResourceStructureBridge B H<* tested by « ; e testOecrementAcrosJi §L a % referenced by B plugin.xrnl: Ant Structure Bride ; ; 8l plugin.xrnl: structureBrldge l l plugin.xrnl; Java Structure Brit : 8l plugin.xrnl: PDE Structure Brid H *S> referenced by e. getlmageJIMylarElement) & getChildHandles(String) * qet'TextHMylarElement'. IF S Demo - SynchronizeReportsAct ion.Java - Eclipse SDK File Edit Source Refacjor Navigate Search Project gun Wjndow Help rS ' i | J P- * O \" «4 » | (•» | '£[ \" j ; r *J o •» B Package Expl... Si .Navigator = Q : |T| SynchronizeReport... 'VI \\ \" l ; * i ' s f t T i a ^ l fcj org.eclipse.mylar.bugzilla.ui [dev.ei FUJ org.eclipse.mylar.java.tests [dev.ee . B £S src B ftj org.eclipse.mylar.java.tests |g B Iiitere-stMampulationTestjiIS B-% InterestManipulationTes 5j S testDecrementAcrosN : t n org.eclipse.mylar.tasklist [dev.edip:ji : - src - fcu org.eclipse.mylar.internal.taskjj™ - [*} SynchronizeReportsAction. - SynchronizeReportsActi i'» run() p u b l i c S y r . c h r o t i z e R e F c r t s A c t i o i p r i v a t e v o i d c h e c k S y r c R e s u i t ( f i p u b l i c v o i d r o a n ( i f (query '.\" n u l l ) ! Abs t r a c t R e p e a l tcryCor.r.< q u e r y . g e t R e p c s : i f (car .r .ector ! • n a i l ) c o n n e c t o r . syr.cir.roni } e l s e i f ( T a s k L i s t V i e w . g e : I S e l e c t i o r . s e l e c t i o n -f o r (Ob jec t o b ; : I ( I S i i f {obj i n s t a n o e o f f i n a l A b s t r a c t I A b s t r a c t R e p o s i t i v j i] Problems go Synchronize t3 CVS (/org.eclipse.mylar, /org.eclipse.mylar-feat.Jar.ze \"•' s° -1* I o 0 a i -f S8 • • jfl r i 4> T I ; Refactor ResourceStructureBridge (J*' ResourceStructureBridge.java - /org.e - ?.r! B 4i T2: Fix NPE in SynchronizeReportsAction Q [JS> SynchronizeReportsAction.java - /org., ^se. [ < L _ H ,) IS i % JDemo 3 O Fl Task List S3 * r \" v - » \" * Rnd: F T2: Fix NPE in S Description , * fit < | Outline Z i T 2 : FK NPE in Synchi Q ! T I : Refactor Resource: Mylar - All Mine [bug: People-Rob [bugs.e^ Active Search {.. run() - 1% referenced by & openEditQuervQialog! Abstract 4k rum'lAction; > 50Mof87M i Figure 1.5: Task context while working on TI (above), and shortly after activating T 2 (below) 13 M y l a r displays the task context wi th in exis t ing Ec l ipse I D E structure v iews in order to focus the programmer on the task-at-hand. The source code editor folds away al l uninteresting elements and ranks content assist matches, v i s ib le in the popup w i n d o w , to indicate those that are i n the task context (Figure 1.5-2). Even though the code base contains over one thousand classes and numerous other kinds o f artifacts, on ly the artifacts determined to be relevant to the current task context are v i s ib le in the Package Explore r v i e w o f the system (Figure 1.5-3). Structurally related elements that have not yet been interacted wi th , but have predicted interest, show in the A c t i v e Search v i e w (Figure 1.5-4). W h e n w o r k i n g wi th task context and the task-focused U I , the entire I D E becomes focused on the task instead o f showing al l o f the parts o f the system's structure, as was v i s ib le i n Figure 1.1. Since the task context is act ively t r immed to show only the most relevant elements, the programmer w i l l rarely see a scrol lbar in many o f the task-focused v iews , reducing information overload in those v iews . W h i l e w o r k i n g in this focused way on T I , a new high priori ty bug is assigned to the programmer and must be attended to immediately . T 2 : F i x N P E in Synchron izeRepor t sAct ion . U s i n g M y l a r ' s Task L i s t v i ew, the programmer activates the second task (Figure 1.5-5), causing the context o f the first to be stored and al l files in that context to be closed. A s the programmer works on the new task, a new context starts bu i ld ing up for the new task. M y l a r tracks all o f the files that the programmer modifies when w o r k i n g on each task, and groups outgoing changes by task (Figure 1.5-6). A l l that the programmer needs to do to return to the first task is to reactivate it, causing the v iews and editors to return to the state v i s ib le on the top o f Figure 1.5. In an almost identical way , task context enables knowledge workers to regain access almost instantaneously to the information that they need when mult i- tasking. W h e n a user returns to a task on w h i c h he worked previously , our focused file and web brows ing tool displays the files and web pages related to that task in the Naviga tor v i e w (Figure 1.6) and re-opens the most interesting documents for easy access. Instead o f seeing a l l o f the files in the v i s ib le directories, or a l l o f the web pages they had vis i ted as part o f this task, the knowledge worker only sees the information most relevant to the task and is able to multi-task without los ing context. 14 : O Working - http://www.google.caV • Mylar Browser j File E_dir_ Navigate Search Window Help Task List Find: J ff X O - 00 |£f| ^ 134: write CHI paper on know! Description Mylar - Inbox [bugs.ectpse.org] 143626: Landmark decoration is not p 159135: Automatic resolution of links People-Rob [bugs.eclipse.org] 1 154390: Allow to \"bind\" a product to < 157579: Retrieve context dialog shou Thes i s [qua l i cum.cs .ubc .ca] 134: wr i te CHI p a p e r o n know lec 102: section 4: discussion A r c h i v e (al l t a s k s ) bwk frl'SD PC r a t i n g trip. *,,^•|A<>'i>£,'' 4 CHI 2007 Reach Be.., It =S] \"Usage - Mylar.xls \" l 1 = 1 O V J B ^ i http://www.chi2007.org/welcome/cal( v ! >^ K | Submission and Notification Dates Submission Type Courses 8t Wo-1- -ric Archival: . 8. Contemporary Trends: Experience Reports, Interactivity, a Interactive Sessions Submission Dates September 01, 2006 September 29, 2006 October 20th, 2006 Camera-ready course notes and December 01, advance program descriptions 2006 Contemporary Trends: • •• P r o g r e s s . S t u d e n t D e s i g n C o m p e t i t i o n , s j f i s . , D o c t o r a l C o n s o r t i u m January 12, 2007 XS. Resources find: i ££f j (Tj Working ; Planning ^ Web Context B Q Htp ; / /www.goog le .c« ; [5j task tracer - Google Search [s\\ acm paper guidelines - Google Search & Q bttp://'A».vw,chii007.org [*j CHI 2007 Reach Beyond | welcome >> S Q htfp://ews.oregonstare.edu [*j T a s k T r a c e r P r o j e c t : : H o m e IB? My Documents Protects Q & Thesis ( s H f e User Study • B H 5] Usage-Mylar.xls 9 & PubfcaWoins £ & 2006 CHI - Mylar Desktop $H m y l a r - c h i - s t u d y . d o c ^1 TaskContextsForKrowledgeWorker & £006 C5CW - Mylar Celiac-•^j mylar-cscw-wyniwyg.doc : £5» 2006 FSE • Mylar •3] Figure - Mylar Architectur^fjTN Figure 1.6: Browsing with task context 1.6 Overview In Chapter 2, we present the task context model and operations. In Chapter 3, we describe the task-focused UI mechanisms that support integrating this model with IDE and browsing applications, and describe our implementation of task context for the programming and generic knowledge work domains. In Chapter 4, we present our validation in the form of three field studies of professional knowledge workers. We discuss potential improvements to the task context model and integration with collaboration and visualization tools in Chapter 5, overview related work in Chapter 6, and provide concluding remarks in Chapter 7. 15 2. Model & Operations For a programmer, typical tasks include bug fixes, feature additions, and code base explorations. For other kinds o f knowledge workers, tasks include other work activities that need to be tracked and pr ior i t ized [4]. For example, for lawyers, tasks can consist o f creating contracts or researching prior cases. Some tasks are short- l ived, requir ing only a few minutes to complete; others are longer- l ived, requir ing some t ime each day over the course o f weeks or months. Our model considers a task to be an atomic unit. Higher - leve l abstractions and organization o f tasks, such as categorizations, hierarchies and sequences, may be layered on top. The examples we give in this chapter are for interaction wi th a software system, except where special provis ions are made in the model to handle less well-structured information. W e define a task context as the information that a knowledge worker needs to k n o w to complete a particular task. The information consists o f a graph o f the parts o f artifacts (elements) and relations between artifacts. E a c h element and relation in the graph has a weight ing that defines its relevance, a degree-of-interest ( D O I ) , to the task. O u r approach forms a task context based on the interactions that a programmer has w i t h system artifacts and from the structure o f those artifacts. Spec i f ica l ly , the information in a task context is defined entirely by an interaction history, w h i c h is comprised o f a sequence o f interaction events that correspond to the direct interaction that a programmer has wi th a system, and the indirect interactions that a tool can have on behalf o f the programmer (each described i n Sect ion 2.1.1). Direc t interactions include a programmer 's edits and selections; indirect interactions include predictions and propagations that cause elements to be added to the interaction history that have not yet been interacted wi th directly in the task context. F igure 2.1 provides a conceptual overv iew o f this approach. A s a knowledge worker works , interaction history is captured (Section 2.1) and is used to produce a task context graph (Sect ion 2.2). The nodes and edges in this graph reference concrete elements and relations in the target information system, in this case different kinds o f Java declarations (M=method, C=class, l=interface). A s the interaction history is processed, our D O I function (Sect ion 2.2) assigns a real number weight ing to each element and relation, corresponding to the frequency o f the access to the element or relation, less a decay factor that corresponds to the total number o f interaction events processed. A c c e s s i n g an element increases its weight, whi le accessing other elements decays the weight o f infrequently accessed elements. V a l u e ranges on the D O I specify wh ich elements and relationships are interesting and uninteresting (Table 2.1). Interesting elements or relationships are those wi th a posit ive D O I value. Uninteresting elements or relationships are those wi th a negative or zero D O I value, wh ich occurs either through decay or because the element or relation has never been the target o f an interaction. 16 Table 2.1: DOI value intervals Interval Description (0 , oo] Interesting [-co, 0] Uninterest ing A task context can be operated upon and displayed. For example, the bottom o f Figure 2.1 shows, from left to right, a display o f a l l elements that have changed in a system as part o f a task regardless o f D O I , a display o f only elements o f predicted interest, and display in w h i c h an exis t ing v i e w o f system structure has been filtered to show only interesting elements. Since the task context model is typ ica l ly over la id on exis t ing v iews o f system structure tailored to specific activities, such as b rows ing the hierarchy o f a Java program, we ca l l these display mechanisms projections o f task context, and describe them in the next chapter. Interaction history • InteractionEvent stream • Origin, handle, type, date Context (Core) • Degree-of-interest graph • Degree-of-separation scope • Scaling factors Projections (Ul) • Views, editors, files interest t a--4S 113470: apply mylar to task list i+ h> org.eclipse.mylar.tasklist B ~ # improve sorting: org.eclipse.mylar.tasklist E r src/org/eclipse/mylar/intei a G | TaskStructureBrklge B • % referenced by • ® plugin.xml: s t n . ; : B n d g e frMkLisO^bteSorter B a o tested by I © TabelSorterTest.testRootTasI\" 3-$% referenced by • e. Teskliaview.ci 'eaieFartContrc - o \".'idgetSefectedtSslsctionEveni '• • a Tas!:Lis!View.res;oreState() B - e j org.eclipse.mylar.tasklist f S 8 sre • 3 •% org.eclipse.mylar.imarnal.tasWist B 13 TaskListTableSorter.java B - C J TaskListTableSorter ©c TaskListTableSorter • e .compareElements 13 build.wnl Figure 2.1: Constructing and projecting a task context This chapter describes our core model and the m i n i m a l set o f operations that we have defined to support integrating this model w i t h exist ing information sources and user interfaces. W e describe interaction 17 history in Sect ion 2.1. W e describe how to construct a task context from an interaction history in Section 2.2. W e define task context operations in Sect ion 2.3. T o help guide the descript ion o f these operations, we provide an overv iew o f the four operations in Table 2.2: the composition operation supports d i sp lay ing and w o r k i n g wi th mult iple task contexts concurrently, the slicing operation creates a new smaller context from an or iginal context by app ly ing a constraint that determines w h i c h elements and relations should be included in the resultant context, the induction operation induces interest on structurally related elements to support indirect interaction, and the manipulation operation supports direct manipulat ion o f the D O I o f elements by a user. Table 2.2: Task context operations overview Input Operation Output l . . n contexts composi t ion N e w context composed o f input contexts context, constraint s l i c ing N e w context resulting from app ly ing constraint context manipulat ion Events appended to interaction history for exis t ing context induct ion Our defini t ion o f task context is not coupled to any particular k ind o f information source, applicat ion, user interface or task defini t ion. However , an implementation o f task context must provide bindings for each o f these. W e discuss our implementat ion o f task context for an I D E and for a file and web b rows ing applicat ion in the next chapter. 2.1 Encoding Interaction W e derive a task context from an interaction history, defined as a sequence o f interaction events that describe accesses o f and operations performed on artifacts wi th in a user's w o r k environment. 2.1.1. Interaction Events Each interaction event captures four pieces o f information (Table 2.3). The time f ie ld stamps the event w i t h the moment that it occurred. The kind classifies the event according to a schema representing the k i n d o f interaction that occurred, such as a selection (Table 2.4). The content type provides an identifier that binds the element to a particular domain structure (e.g., \"text/html\"). The handle is an identifier that uniquely identifies that element for the g iven content type. This is the min ima l schema needed to uniquely 18 associate typed events i n t ime wi th structured elements, assuming that element identity is unique per content type. Table 2.3: Interaction event schema T i m e The t ime o f the event occurrence K i n d Class i f ica t ion o f event (Table 2.4) Content Type Identifier descr ibing the k ind o f element operated upon Handle Identifier for the target element A n interaction history is naturally ordered by t ime. Events can be appended to the sequence. Delet ions and insertions are not supported since the interaction sequence is a historical record and, as such, events cannot be \"undone\". 2.1.2. Element Identity Interaction events are created by an interaction moni tor ing faci l i ty , such as the M y l a r M o n i t o r (Section 3.1.3), w h i c h is responsible for populat ing them wi th the k ind , and wi th the identifying information o f the concrete element corresponding to this event (i.e., the content type and handle). The content type and handle identifier fields b ind the abstract task context elements (i.e., nodes in a graph) to domain structure elements (e.g., Java methods). The concrete relations between elements (e.g., method a \" c a l l s \" method b) are defined at the domain level . A relation in the task context model is defined by an edge connecting the corresponding elements. O v e r the course o f an interaction history, the identity o f an element can change. For example, i f a file is renamed, and the identity is derived from the name, the handle f ie ld on past interaction events may not correspond to future interaction events. T o preserve identity the interaction history supports updating the identity associated wi th past events. A l l other fields on an interaction event are considered immutable. 2.1.3. Event Classification Table 2.4 summarizes our classif icat ion o f interaction events. Some interaction events are the result o f a programmer 's direct interactions wi th program elements. Fo r instance, a programmer may select a particular Java method to v i e w its source, edit it, and then save the file containing it. Each o f these actions corresponds to an event o f a different k ind being created and added to the sequence o f interaction events for the task context, as demonstrated by the sample interaction history in Table 2.5. 19 Other interaction events are indirect, where program elements and relations are affected without being directly selected or edited by the programmer. For example, when w o r k i n g on T l (Sect ion 1.5), the programmer refactors the name o f the R e s o u r c e S t r u c t u r e B r i d g e class, causing a l l o f the elements referring to that class to be updated. Each referring element updated through the refactoring results in an indirect propagation event o f the edit to be appended to the interaction history. W h e n the programmer direct ly selects the g e t C o n t e n t T y p e method (Figure 1.5-2), each parent o f that method (its class, source fi le, package, source folder, and containing project) becomes relevant to the context, and a propagation event for each parent element is appended to the interaction history, so that a v i e w can display these as i f they had been interacted wi th direct ly. Table 2.4: Interaction event classification schema Event kind Interaction Description selection direct Ed i to r and v i e w selections v i a mouse or keyboard edit Textual and graphical edits command Operations such as saving, bu i ld ing , preference setting and interest manipulat ion propagation indirect Interaction propagates to structurally related elements predict ion Capture o f potential future interaction events W e also support prediction events, w h i c h describe possible future interactions that a tool anticipates the programmer might perform. A n example o f prediction is an event descr ibing that a test may be o f interest to the current task because it references a class in the task context. Whereas direct events are caused by user interaction, the indirect predict ion and propagation events are issued by the induct ion operation, discussed in Section 2.3.4. The key differentiator between propagation and predict ion events is that the former indicates an expl ic i t intention o f the programmer to interact w i t h the elements invo lved in the propagation. In contrast, predict ion events are a mechanism for capturing recommendations wi th in the interaction history. Table 2.5 provides an example o f the sequence o f interaction events that result from the programmer 's ini t ia l work on T l (Sect ion 1.5). Fo r s impl ic i ty , we use an event number to stand in for the time field o f an interaction event. The programmer first selects a class. The selection event propagates to structurally 20 related elements, such as the file containing the class, the package containing the f i le , and so on 1 3 . The programmer then invokes a rename operation, and edits the name o f the class. Th i s edit propagates to each o f the files that are subsequently renamed by the refactoring c o m m a n d 1 4 . T h e user then c l i c k s a U R L in the Java editor, opening the browser. Th i s causes a selection o f a web page, wi th another propagation to the web site that contains the web page. Table 2.5: Sample interaction history Event Kind Target(s) 1 selection ResourceStructureBridge class 2..5 propagation .java fi le, package, source folder, project 6 command ResourceStructureBridge class 7 edit ResourceStructureBridge declaration 8..16 propagation 4 X M L and 5 Java references to ResourceStructureBridge 17 selection U R L to documentation page, reference to section 18 propagation U R L o f web site containing documentation 2.2 Task Context Construction W e derive a task's context by processing an interaction history that describes the activity performed for the task. Each event from the port ion o f the interaction history related to the task contributes to a graph that represents the task context. I f the handle o f an event being processed refers to an element not yet represented in the graph, a node for the element is added to the graph. A selection event from the interaction history contributes an edge to the graph when the target element o f the current selection event is structurally related to the target element o f the last selection event processed. Fo r example, i f a programmer navigates from a method ca l l to its declaration, the interaction history w i l l contain the selection o f the caller fo l lowed later by a selection o f the callee. The result is an edge representing the Java reference relation between the two corresponding element nodes. The graph o f task context can contain cycles (e.g., as a result o f navigat ing recursive method calls) and can have mult iple edges between nodes (e.g., both reference and inheritance). 1 3 This propagation will cause each of those elements to become interesting and to show in the Package Explorer view (Section 3.3.1). 1 4 This propagation causes the context change set to include the refactored files (Section 3.3.5). 21 We use a task's interaction history to compute a weighting for each element in the task context. The weighting is a real number value representing the element's degree-of-interest (DOI) for the task. This DOI value is based on the frequency of interactions with the element and a measure of the interactions' recency. The frequency is determined by the number of interaction events that refer to the element as a target. Each event kind has a different scaling factor constant, resulting in different weightings for different kinds of interaction. Recency is defined by a decay that is proportional to the position in the event stream of the first interaction with the element; like frequency, recency is also scaled. Since decay is proportional to the number of interaction events, it is independent of actual amount of wall clock time spent working with an element or relation. Instead, decay is based on the amount of interaction as punctuated by the events. Algorithm 1 describes how we compute a DOI value for an element, given an interaction history represented as a sequence that contains one or more events with the element as the target. We iterate over a subsequence consisting of just the events involving the element (line 4), increment the interest value of the element based on the kind of the current event (line 5) and if the interest has not offset the decay, reset the decay to start at the last interaction with the element (lines 7-9). This algorithm ensures that elements that have decayed to a negative interest have their interest become positive when interacted with again. D O I ( e l e m e n t , e v e n t s ) 1 e l e m e n t E v e n t s = WITH-TARGET(element, e v e n t s ) 2 d e c a y S t a r t = e l e m e n t E v e n t s [ 0 ] 3 i n t e r e s t = 0 4 f o r e a c h e v e n t i n e l e m e n t E v e n t s 5 i n t e r e s t += S C A L I N G ( K I N D ( e v e n t ) ) 6 c u r r D e c a y = D E C A Y ( d e c a y S t a r t , e v e n t , e v e n t s ) 7 i f i n t e r e s t < c u r r D e c a y t h e n 8 d e c a y S t a r t = e v e n t // r e s e t d e c a y 9 i n t e r e s t = S C A L I N G ( K I N D ( e v e n t ) ) // r e s e t i n t e r e s t 10 t o t a l D e c a y = D E C A Y ( d e c a y S t a r t , L A S T ( e v e n t s ) , e v e n t s ) 11 r e t u r n i n t e r e s t - t o t a l D e c a y D E C A Y ( f r o m E v e n t , t o E v e n t , e v e n t S e q ) 12 d e c a y E v e n t s = SUB S E Q ( f r o m E v e n t , t o E v e n t , e v e n t S e q ) 13 r e t u r n | d e c a y E v e n t s | * SCALING(KIND-DECAY) Algorithm 1: DOI for Task Context The S C A L I N G function returns the constant associated with each event kind and with the K I N D - D E C A Y constant. The D E C A Y function computes the decay to be proportional to the size of the subsequence 2 2 from d e c a y S t a r t to the most recent event and includes events not i n e l e m e n t E v e n t s . A s an example, consider h o w the interaction history from Table 3 contributes to the weight ing o f the R e s o u r c e S t r u c t u r e B r i d g e element at the end o f the interaction history. The element is most recently edited at event 7. A s s u m i n g S C A L I N G returns 1 for selections, 0 for commands, 2 for edits, and 0.1 for K I N D - D E C A Y , and noting that there were no propagated events w i t h that element, the three iterations through the loop w i l l result in 1+0+2 = 3 for interest, and (18-1)(0.1) for t o t a l D e c a y , result ing in a D O I o f 1.3. I f 30 more interactions happened w i t h another element, the D O I value w o u l d become-1 .7 . A subsequent selection w o u l d cause the D O I to be reset to 1 - 0 . 1 =0 .9 . A relation in the graph is composed o f a source and a target element. The D O I o f a relation is computed using the same D O I algori thm, but us ing the relation's target element: DO\\-R(relation, events) = DOI (TARGET( re / a<7 ' o« ) , events) For example, i f a programmer navigates repeatedly between a method cal l and its declaration, the D O I o f that relation w i l l increase from repeated selections o f the declara t ion 1 5 . I f the programmer navigates ' back ' and ' fo rward ' between the two several times, the two resulting directed edges w i l l both have the same D O I . O u r construction algori thm for task context takes as input any sequential stream o f interaction events whether it is being gathered on-l ine (e.g., when the user is w o r k i n g on a new task), or was stored off-l ine (e.g., when resuming a previously worked-on task). A t any point in the construction process, each node and edge in the task context 's graph can be queried for its D O I value. Th i s value is computed from the interaction history that is associated wi th the task context when the query is made. Task context can thus be buil t interactively as a programmer works , or recreated by parsing a previously stored interaction history. The result ing task context is a graph representing each element and relation in the context. The weightings are not exp l ic i t ly stored in the task context, and instead the D O I o f each element and relation is computed from al l the interaction w i t h that element to date 1 6. Note that for some domain structures or usage scenarios it may be impossible to determine the relation between two elements that are consecutively navigated (e.g., a navigation that results from a suggestion made in a phone conversation). For such cases, the relation is an arbitrary navigation, with no binding to a concrete relation in the target domain. The DOI algorithm can be computed frequently in a typical application (e.g., in Mylar IDE thousands of DOI computations happen in what needs to be an instantaneous view refresh, where instantaneous is defined as <200ms by the Eclipse UI). An implementation can cache previous computation values or use a data structure that optimizes for the DOI computation. Optimizations for parsing long interaction histories are discussed in Section 3.2.4. 23 B y capturing and weight ing the interaction o f both elements and relations that have been interacted wi th directly and indirect ly, the task context exhibits topological properties that can be leveraged by operations (Sect ion 2.3) and by projections that display the task context (Sect ion 3.2.1). A s illustrated in Table 2.6, these properties include groupings, paths, and interest propagations (Sect ion 2.3.4) that emerge from the way that the D O I algori thm derives the interest o f relations from interaction wi th elements. These properties can be displayed directly in graphical v iews o f task context (discussed in Sect ion 5.4). The set o f properties described here is not intended to be comprehensive, but to illustrate the behavior o f the algori thm when processing interaction sequences for structurally related elements. Table 2.6: Illustrations of topological properties of the task context P r o p e r t y D e s c r i p t i o n I l l u s t r a t i o n groupings Elements worked on in conjunction w i l l have s imi lar D O I values (e.g., an A P I method, X M L fi le, and web page a l l referred to wh i l e edi t ing a method). D O O paths W h e n elements are frequently navigated between v i a less interesting elements, the end-points and path w i l l have a h igh D O I (e.g., when w o r k i n g on two ends o f a method ca l l chain). propagations Repeated interaction wi th an element increases the D O I o f structurally related elements (e.g., when edit ing a class the containing method and superclass w i l l gradually increase in interest). 2.3 Task Context Operations W e can use a task context as input to various operations that support integrating task context into applications. Sometimes a single task context may not contain a l l o f the relevant information needed for an act ivi ty, such as a code review. W e use the term composition to refer to operations that produce a composi te task context from indiv idua l task contexts. Sometime the converse is true and a subset o f the context may be relevant. E v e n though the size o f a task context is typ ica l ly smaller than the size o f the system, it can st i l l be too large or contain too many different kinds o f elements and relations to assist w i th other activities, such as the unit testing that is done by programmers, or the searches that are performed by query tools. W e use the term slicing to refer to an operation that produces a subset o f a g iven task context (i.e., a subset o f the elements and relations, w h i c h can result in one or more sub-graphs depending on the properties o f the sl ice). T o enable a user to tai lor a task context manual ly we also support manipulation operations. In order to g row the task context to encompass structurally related elements, the induction operation supports indirect interactions in the form o f predicted and propagated interactions. 24 A l l operations on a task context take one or more contexts as input (as w e l l as other arguments) and either update that context or produce a new context. This ensures that a l l o f the operations are orthogonal and can be applied or combined in any order. Since a task context is defined by the set o f interaction events associated wi th it, a l l o f the operations are expressed i n terms o f adding or r emoving interaction events to form the output context. Since events cannot be removed directly from a context, operations that go beyond appending interaction events produce a new context (referred to as a context ' below). 2.3.1 .Composition Each task context 's interaction history corresponds to a single task. However , some activities can require d i sp lay ing the contexts o f several tasks simultaneously. Fo r example, a programmer might want to create a composite context f rom T I and T 2 (Section 1.5) to perform a code rev iew o f the work that was done on those two tasks and have the element highlighted according to each context. The composi t ion operation takes as input one or more task contexts, and combines them to form a single composite context ' 7 . The composi t ion operation combines each o f the interaction event sequences o f the input contexts (Table 2.7). Task contexts maintain the sequence o f interaction events in time-sorted order, ensuring that the D O I algori thm can process the events from a composite context identical ly to a non-composite context. W h e n the D O I algori thm is run on the composite context it returns a D O I corresponding to the interest o f the element representative o f what it w o u l d be i f a l l o f the tasks had been performed as a single task. The resulting composite context is identical to a non-composite context, other than the fact that it is composed o f an aggregate sequence o f interaction events. Table 2.7: Composition operation Input Output Description l . . n contexts context' C o m b i n e the interaction events o f each context to form a single time-sorted sequence R u n the D O I algori thm on the merged sequence Since a composite context is s imply the combinat ion o f the interaction events o f each composed task context, a composite context can be the target o f interaction just as a single task context can be. The interaction mirrors the effect o f the composi t ion operation: interaction events are duplicated across each 1 7 Our implementation treats composite contexts identically to regular contexts, having each implement the same interface. Mylar's task-focused UI is always operating on the currently active composite context, which by default only has one context that it is composed of, but enables additional contexts to be activated. 25 o f the contexts that make up the composite context. The identity o f interaction events plays an important role in supporting a user's interaction wi th a composite context, for example, when the user is interacting wi th more than one task concurrently. W h e n the D O I algori thm is used on such a composite context, it needs to treat identical interaction events distributed across compos ing contexts as a single event. Otherwise w o r k i n g wi th three tasks active w o u l d cause the D O I o f one interaction wi th one element to be three times that when a single context is active. A s such, supporting this distr ibution o f events in an implementat ion requires either a data structure that is aware o f interaction event identity (as in our implementation), or for the composi t ion operation to discard duplicate events. 2.3.2.Slicing Task context s l i c ing is an operation that takes as input a task context and outputs a task context containing al l elements and relations o f the input context that meet a particular constraint (Table 2.8). A constraint tests one or more o f the kinds o f interactions associated wi th an element or relation (e.g., includes only predicted ones), D O I values (e.g., include elements and relations w i t h a h igh D O I ) , or the under ly ing domain structure (e.g., include elements that are Java methods). A n example o f a sl ice that tests the interaction events but ignores the elements' contents and D O I is to gather a l l interesting files that have interaction events o f the k ind edit; this sl ice can be used to determine w h i c h files to include in a source code commi t (Sect ion 3.3.5). A n example o f a sl ice whose constraint tests both the under lying structure and the D O I is to gather all interesting test cases for running a test suite o f the active context (Section 3.3.4). Table 2.8: Slicing operation Input Output Description context, constraint context ' For each element, relation, and interaction event apply the test to determine i f the corresponding element or relation should be included in the output context. I f test passes, include a l l interaction wi th the element/relation in the interaction history for the output context. Whereas composi t ion produces a context that defines a superset o f the interaction, s l i c ing is an operation that defines a subset. These operations can be combined. For example, consider the depict ion o f the interest o f two tasks that have a large number o f interesting elements, represented by the two lines in Figure 2.2. C o m p o s i n g the task contexts creates a union o f the elements in each, result ing in elements that occur in both contexts having a D O I corresponding to what it w o u l d have been i f they occurred in a single context (l ine A in Figure 2.2). I f a l l we are interested in is the intersection o f the two task contexts, we can sl ice the composi te context to include only the elements in both (l ine B in Figure 2.2). Such an 26 intersection can be used to identify 'hot spots' in code when compos ing a large number o f contexts that result from the dozens or hundreds o f tasks performed dur ing a phase o f software development. Task 1 Task 2 Figure 2.2: Combining task context operations 2.3.3. Manipulation Our D O I function provides an approximation o f interest and can produce a value that does not match the user's expectation either by being tuned incorrectly or by fa i l ing to capture a relevant interaction. W e provide a mechanism for directly manipulat ing a task context by a l l o w i n g the user to issue command events that result in predictable changes to the task context. Fo r example, i f an element is interesting but should not be, a \" M a k e Less Interesting\" command can issue the interaction events needed to reduce the interest o f that element and make it disappear from a v iew, leaving only interesting elements v is ib le . Since we assume that interaction cannot be undone, it is not possible to delete elements from a task context. A s such, m a k i n g an element uninteresting is supported v i a an interaction event based operation cal led task context manipulat ion (Table 2.9). Table 2.9: Manipulation operation Input Output Description Example context context A d d the command interaction event(s) to the task context User exp l i c i t ly marks an element as a uninteresting v i a a U I affordance A manipulat ion operation adds one or more interaction events to the task context so that the context is updated in order to match the user's expectation o f the operation (e.g., in our implementat ion an element can be made exp l ic i t ly interesting or uninteresting (as described in Section 3.2.2). Man ipu la t ion 27 commands differ from other interaction events because their processing must have not only a predictable effect on the task context, but one that causes a precise change in the DOI of the target element. For example, if a document has a DOI of 10, and the user issues a manipulation event that should make this element have a negative interest (i.e., disappear from view), the interaction must contribute -10 to the DOI. To avoid having the algorithm include a special rule for such events, a number of command manipulations corresponding to the right decrement can be issued 1 8, effectively undoing the interest contributions of the other interactions with that element. 2.3.4. Induction A significant fraction of the commands executed by a user are commands related to searching for structurally related elements that need to be edited or referenced in order to complete a task [52]. We can use the information in a task context to predict what elements might be relevant to completing the task, but with which the user has not yet interacted directly. For example, if a programmer is working on a Java class, which is referred to by an X M L element, the X M L element can have a predicted interest if a tool determines it is likely to be part of the task context at a future time. By \"predicted interest\", we mean a DOI that results entirely from interaction events with the prediction kind (Table 2.4) and not by other events such as selections. Such predictions can come from running automatic searches on the programmer's behalf, for example using context slices as both input and scope for the searches (Section 3.3.3). We can also use existing interaction information to propagate the interaction to structurally related elements. For example, if a programmer selects a class, events can propagate to elements directly related to the class, such as its parents in the containment hierarchy. The propagation events differ from the predicted events because they express an intention of the user to select structurally related elements known by the domain mapping to be structurally relevant, whereas the prediction events express a recommendation of elements that may be relevant. We call the operation that adds both prediction and propagation events induction because it results in interest being induced on structurally related elements. The output of the induction operation is a set of interaction events that contribute to the task context, with an event kind of prediction or propagation indicating the indirect interaction (Table 2.10). As with the manipulation operation, these events are simply appended to the task context's interaction history. This approach enables the use of the DOI This can cause a large number of manipulation events if a high DOI element is reduced in interest. However, an implementation can compensate for this by accounting for the redundancy, e.g., by collapsing repeated events (Section 3.2.4). 28 algorithm to rank related elements, with the DOI of less frequent results decaying and more recent and more frequent results producing a higher DOI. Table 2.10: Induction operation Input Output Description context context Use domain-specific relations or heuristics to find related elements, and add them to the context via prediction or propagation events. 2.4 Task Activity Context To correlate each context to a particular task and to support multiple task contexts, we need a mechanism to associate interaction events with a task. We achieve this association by capturing a separate stream of interaction events in which the target elements are tasks instead of system artifacts. This stream of interaction events can be used to form an interaction history over tasks instead of system artifacts. This parallelism to how a task context is defined means that we can apply the same model and operations to this separate interaction stream, forming a meta task context. We call this the task activity context. As depicted in Figure 2.3, at the base level, the nodes in a task context are resources, and the interaction history contains events such as selections and edits of the corresponding files or web pages. At the meta-level, the nodes in the task activity context are the tasks, and the interaction history contains events such as the selections and edits of those tasks. Task activity T2 T l R l R2 R3 R2 R4 R5 Example events : select T l , edit T l , select T2, select T l c task DC J Figure 2.3: Illustration of task activity context We process the interaction history for the task activity context the same way that we process a task context. For example, a programmer can indicate that work should be associated with a particular task by opening a bug report; this action causes a selection event on that task. Commenting on the bug report causes an edit event. The act of a programmer switching to another application window causes a command event that indicates work on a task has stopped. Supporting this meta-context ensures that the 29 D O I algori thm and operations that we have defined w o r k for the task act ivi ty context just as they w o r k for the base task contexts. K e e p i n g this interaction history separate from the task context interaction history ensures that w o r k i n g on tasks does not cause the D O I o f the elements in the active task context to decay. The task activity context also enables an implementat ion to focus the U I on the highest D O I tasks, as we discuss in Sect ion 5 .5 .6 . 2.5 Model Summary O u r goal wi th the task context model has been to make it as s imple as possible, whi le ensuring that we cou ld capture any k i n d o f interaction that a user could have wi th p rogramming and file and web brows ing applications. W e have described a set o f operations intended to focus an appl icat ion on task context, and discuss our implementat ion o f task context and operations in the next chapter. 3 0 3. Implementation There are two key challenges to implement ing task context for a particular appl icat ion: determining the mapping from applicat ion usage to the more abstract interaction history, and implement ing the necessary task context operations to integrate task context w i t h the applicat ion. W e implemented task context on the Ec l ipse platform, wh ich is a generic appl icat ion framework used to bu i ld applications that include the Ec l ipse Java I D E . Ec l ipse provides several mechanisms that support integrating task context: a unif ied selection service for moni tor ing user interaction 1 9 , extensible U I mechanisms 2 0 that support a modular implementat ion o f the task-focused U I , and the O S G i p lug- in mechanism 2 ' that supports a loose coup l ing o f mappings to different domain-specif ic artifacts (Sect ion 3.1.1) and enables deployment to different appl icat ion configurations. Task context can be implemented on another appl icat ion platform i f equivalent mechanisms are available on that platform. In this chapter we describe the architecture in terms o f our Ec l ipse and Java-based implementat ion, but the concepts are generic and have been implemented by another research group on a different applicat ion platform [12]. In this chapter, we describe the M y l a r architecture that supports integrating task context wi th a diverse set o f domain structures (Sect ion 3.1). W e define the user interface mechanisms that present task context to the user (Section 3.2) and we describe our two implementations o f task context: one for an I D E applicat ion cal led M y l a r I D E (Section 3.3) and one for a fi le and web brows ing appl icat ion cal led M y l a r Browser (Section 3.4). 3.1 Architecture Overview T o adequately test task context, we needed an implementat ion that cou ld scale to handle very large systems wi th several kinds o f structured and semi-structured artifacts, that could support task management and that cou ld integrate wi th exis t ing tools used by knowledge workers. The M y l a r Archi tecture supports these cri teria by prov id ing three frameworks (Table 3.1): M o n i t o r , Context and Tasks. E a c h framework is broken into two parts. The \"core\" part provides a model and operations not 1 9 http://eclipse.org/articles/Article-WorkbenchSelections/article.html [verified 2006-10-02] 2 0 http://eclipse.org/articles/Article-UI-Workbench/workbench.html [verified 2006-10-02] 2 1 The OSGi plug-in model is a component model that allows a number of Java classes to form a single component and supports the loose coupling of components: http://eclipse.org/osgi [verified 2006-10-02] 31 coupled to any particular applicat ion platform and suitable for use i n server-side applications or for embedding in another appl icat ion framework, whereas the \" U I \" part is coupled to the Ec l ipse U I framework. A s we describe each o f the three frameworks, we also discuss h o w to extend each framework component 2 2 . The M o n i t o r framework transforms a user's interaction wi th the appl icat ion into the interaction events that are processed by the Context framework. The M o n i t o r may be extended by user study plug-ins to support measuring usage statistics in f ie ld studies, as described in the next chapter. The Context F ramework implements the task context model , inc lud ing interaction histories and task context operations. The Context Framework requires a defini t ion o f tasks and is f lexible in this definit ion because it is not coupled to the Task framework. A s such, an alternative task management framework can be used for task management and activation purposes. The U I portion o f the Context framework implements the task-focused U I (Section 3.2.2) w h i c h we implemented both for programmers and for knowledge workers (Sections 4, 4.4). The core o f the Tasks framework provides the definit ion o f tasks that maps user-defined w o r k items to tasks. The U I port ion o f the Tasks framework provides task management facil i t ies (Section 3.2.3). Table 3.1: Mylar frameworks Framework Core UI API clients M o n i t o r Interaction history Interaction moni tor ing Mon i to r s Context Task context Task-focused U I mechanisms Bridges Tasks Task management Task v iews and editors Connectors Each framework supports a different k i n d o f A P I client. The M o n i t o r Framework supports monitors that observe user interaction. For example, user observation mechanisms described in the next chapter incorporate monitors for the purpose o f measuring productivi ty and reporting on task act ivi ty. The Context framework supports bridges, w h i c h map between the abstract elements in the task context model and the concrete elements in some domain , for example, the Java programming language. The Tasks The Mylar 0.7 implementation is 82,684 source lines of Java code (SLOC), 8,042 lines of X M L and X M L schema, 107 packages, 950 classes, and 50 interfaces. The Mylar framework components are 3,695 source lines of code, 24 packages, 399 classes, and 40 interfaces. I implemented over 80% of the total code in Mylar 0.7, the entire Context and Monitor frameworks, and led the implementation of the other components, such as the Tasks framework. Credits to the many open source contributors are summarized at: http:// eclipse.org/mylar/team.php [verified 2006-12-20] 32 Framework supports connectors, which define the unit that makes up a task. For example, the Bugzilla connector defines tasks as bug reports or enhancement requests. f r a m e w o r k c o r e m o n i t o r . c o r e i n te rac t ion h is tory c o n t e x t . c o r e t ask con tex t t a s k s . c o r e k 1 bugz i l l a .core t a s k s , repos i to r i es i — » — i — + — I —I— f r a m e w o r k UI m o n i t o r . u i v i e w a n d ed i to r m o n i t o r i n g c o n t e x t . u i v i e w s , ed i to rs , f i l ters t asks .u i t ask l ist, t ask ed i to r k — - -c l ien ts t r a c . c o r e bugzilla.ui t rac .u i s t u d y m o n i t o r < — - ~ \" > f i les J ' •» w e b 1 V 1 i s I J a v a v c s / l 1 I i i CVS >. s u b v e r s i o n Mylar c o n n e c t o r s Browser • J Mylar IDE br idges Monitor Framework Context Framework Tasks Framework Product Figure 3 . 1 : Mylar architecture showing OSGi plug-ins and their dependencies Figure 3.1 demonstrates our component model, with each box corresponding to an Eclipse OSGi plug-in 2 3 . The key property of this architecture, that is needed to support our validation, is the loose coupling of the framework components. For the IDE study, we required the ability to deploy only the monitoring facilities to support gathering baseline data of Eclipse IDE usage (i.e., the m o n i t o r . c o r e , and m o n i t o r . u i components). We then needed to deploy the full Mylar IDE integration and a mechanism for integrating the Bugzilla task repository used by programmers (all components listed in Figure 3.1). For the knowledge worker study, we needed to deploy the Mylar Browser without any of the IDE-specific components or the Bugzilla Connector, and to integrate task context with a subset of the Eclipse platform An Eclipse-based application, such as the Mylar Browser, is a collection of OSGi plug-ins. 33 that was suitable for file and web browsing . The other plug-ins v i s ib le are the T r a c 2 4 connector (Sect ion 3.2), and the vers ion control system ( V C S ) bridges used for integrating change sets support C V S 2 5 and Subvers ion 2 6 (Sect ion 3.3). In the next section, we zoom into part o f this diagram to show how bridges integrate wi th the under ly ing appl icat ion. 3.1.1.Bridges W h i l e our task context model is defined in terms o f a generic set o f interaction events, the actual events need to be issued by a mechanism that understands both domain structure (e.g., Java) and the U I o f the tool for w o r k i n g wi th that structure (e.g., the Ecl ipse U I for Java development). W e ca l l this mechanism a bridge from the task context model to the domain structure. Each bridge handles a single content type. W e have created bridges for Java, two X M L dialects ( A n t 2 7 and Ec l ipse p lug- in descriptors), files, web resources, and the tasks themselves. A structure bridge is responsible for mapping elements and relations i n the task context to and from the domain structure o f a particular content type. This involves mapping context elements to domain model elements and resolv ing relations between elements. Structure bridges must also update the identity o f elements in the model when elements move wi th in the domain structure as a result o f refactoring. For example, the Java structure bridge integrates wi th Ec l ip se ' s Java model (derived from a Java A S T ) , and is able to map between the handle identifiers o f Java elements in the task context and the objects corresponding to those elements in the I D E . It resolves the relations between Java elements inc lud ing references, inheritance, and read/write access o f fields. W h e n elements are moved or refactored and their handle identifier changes, the Java structure bridge notifies the task context model so that the identity o f those elements, and the previous interaction wi th hose elements, can be preserved. The implementat ion o f a structure bridge defines the level o f granularity o f domain structure supported, w h i c h can include both well-structured and semi-structured data. For example, the Java structure bridge is http://trac.edgewall.org [verified 2006-10-20] http://www.nongnu.org/cvs [verified 2006-10-20] http://subversion.tigris.org [verified 2006-10-20] http://ant.apache.org [verified 2006-10-02] 34 well-structured and maps the identity of elements down to the member level 2 8. In contrast, the file structure bridge is only aware of the file and directory structure, and not of the contents of files. This means that it works equally well for both binary images and Microsoft Word 2 9 files. However, if semi-structured data is interacted with inside such a file, for example, a section in a Word document, the interaction will only be registered at the level of the file. The finer the granularity of structure bridges in an application, the higher the fidelity of the task context model (discussed further in Section 5.5.2). A UI bridge is responsible for monitoring interaction with the parts of the IDE for which it is implemented, such as Eclipse's Java tools in the case of the Java UI bridge. It maps the programmer's interaction with the UI to the interaction history schema of selections, edits, and commands. These can include keystrokes in the Java editor, refactoring commands, and element selections. Each UI bridge also specifies which views and editors participate in task context projection (Section 3.2.1). o rg .ec l i pse .my la r | o rg .ec l i pse co re m o n i t o r . c o r e c o n t e x t x o r e J a v a j d t . c o r e interaction history m o d e l ope ra t i ons s t ruc tu re b r i dge : e l e m e n t a n d re la t ion --> java model m a p p i n g UJ. • 1 m o n i t o r , ui 1 contex t .u i i . 1 s jd t .u i view and editor monitoring 6 -d isp lay ope ra t i ons ui b r i dge : v i e w a n d ed i to r m a p p i n g s -> java and junit views and editor Figure 3.2: Mylar plug-in architecture and Java bridges Figure 3.2 shows the dependency structure of a bridge implemented as an Eclipse plug-in, with arrows corresponding to plug-in dependencies. The c o n t e x t . c o r e and c o n t e x t . u i plug-ins provide the structure and UI bridge extension points that the j a v a plug-in uses to map and display the concrete Java elements on which the programmer is working. Bridges for other languages may exist alongside the bridges for Java. Bridges can also be composed. For example, the j a v a structure bridge3 0 extends the It is feasible to implement an even finer-structured bridge, which maps identity down to the statement and expression level. However, as the structure views in IDEs, such as Eclipse, show structure only down to the member level, this was not necessary. http://office.microsoft.com [verified 2006-10-02] It is also possible to implement bridges as separate core and UI plug-ins, for example, if the core plug-in is to be reused in a non-UI application. 35 resource structure bridge responsible for understanding fde and directory structure (not shown in Figure 3.2 for the sake o f s impl ic i ty ) . 3.1.2. Mapping to Interaction History Bridges should not issue interaction events d i r e c t l y 3 1 , but instead provide the identity and relations between elements. The moni tor ing framework issues interaction events corresponding to the concrete domain elements specified by the bridges. Fo r example, when a propagated event needs to be issued for the parent o f a selected element, the bridge corresponding to the element is asked for the identifier o f the parent, and the interaction history faci l i ty uses the induct ion operation to issue the event. Since bridges can be composed, the induct ion operation can involve mult iple bridges. Fo r example, i f a Java method is selected, the Java structure bridge provides the class containing the method. W h e n the next propagation needs to occur, from the class to the file containing the class, the file structure bridge provides the identity o f the fi le. The same is true for predicted events where the relations may be all Java references to a particular method. In this case, resolv ing the relation involves performing a Java search and returning the results, w h i c h the induct ion operation then appends to the interaction history. T o support voluntary use o f the tool for dai ly work on real systems, we needed to ensure that the interaction event architecture scaled to large systems without excessive memory or performance overhead. Task context grows wi th the amount o f interaction, not wi th the system size, ensuring scalabi l i ty for large systems. Scalabi l i ty to large or long-running tasks results from the relat ively smal l amount o f interaction that users perform in relation to the system size (Sect ion 3.2.4). Since the number o f propagation events can vary wi th system size, the number o f propagation steps is bounded by an exponential drop o f f w h i c h l imits the number o f events issued from each interaction. The search scopes used for prediction are based on context slices and scale w i t h the size o f the context. Fo r example, whereas a user-driven search through the workspace might include every resource and can be s low to run on a large workspace 3 2 , a context search can query only the slice o f interesting elements (Sect ion 3.3.3). This is not yet strictly enforced by the Context framework to support flexibility and experimentation, but would be beneficial to prevent a poorly implemented bridge from issuing an unrepresentative number of interaction events. Although Eclipse provides rich text indexing facilities, making many searches fast, the size of an enterprise programmer's workspace is still too large for such searches to constantly run in the background on current commodity PCs (e.g., 2GHz CPU 2GB RAM). 36 3.1.3.Interaction Monitoring The M y l a r M o n i t o r component provides interaction moni tor ing. The M y l a r M o n i t o r is a separately installable component that collects information about a user's activity in Ec l ipse . Cl ients o f the monitor include the Context UI and user study plug-ins, w h i c h can report on Ec l ipse usage trends [52]. The m o n i t o r p lug- in accepts listeners to different Ec l ipse events, inc lud ing preference changes, perspective changes, w i n d o w events, selections, and commands invoked through menus or key bindings and U R L s v i ewed through the embedded Ec l ip se web browser. The I n t e r a c t i o n E v e n t class used by the monitor encapsulates direct and indirect interactions. Since the monitor encapsulates the mapping between user interaction and the interaction history, consistency between how different kinds o f affordances generate interaction events is important. Sca l ing factors are used to determine the bias between different kinds o f interactions (e.g., bias o f edits vs. selections). W e have used a single set o f scal ing factors throughout the study versions and latest released vers ion o f M y l a r 0.7, listed in Table 3.2. W e discuss the formulat ion o f these scal ing factors in Sect ion 5.1.4. Table 3.2: Scaling factors used in Mylar implementation Factor Value selection 1 edit 0.7 decay 0.017 command 0 (ignored) propagation 1 predict ion 1 The m o n i t o r . u i p lug- in supports the transparent capture o f these events into a local file and the upload o f these events to a web server. The uploading mechanism includes functionality to track anonymous IDs for users, to obfuscate the handles o f targets o f selections and other such user data, and to prompt the user to v i e w and send the log to a web server. The M o n i t o r also detects and reports when there has been a per iod o f inactivi ty w i t h Ec l ipse . User study plug-ins that extend the monitor were used for the val idat ion o f both the M y l a r I D E and M y l a r Browser applications. T o help wi th the analysis o f traces col lected wi th the M y l a r M o n i t o r , an addit ional m o n i t o r . r e p o r t s p lug- in provides an A P I to process records for a user across one or more interaction histories, enabling the analysis o f interaction history data (Section 5.4.3). 37 3.2 Integration Integrating task context into an appl icat ion requires mechanisms to project the context onto exis t ing data structures and U I facili t ies to present these projections to the user. Together we refer to these mechanisms as the task-focused U I . T o support task context, the task-focused U I mechanisms must be combined wi th task management facili t ies that a l l ow a user to indicate on w h i c h tasks w o r k is occurr ing. In addit ion, a mechanism for storing and retr ieving contexts is required. These mechanisms, described in the f o l l o w i n g sections, are c o m m o n to any appl icat ion supporting task context, inc lud ing our M y l a r I D E and M y l a r B rowse r implementations. Each o f the integration mechanisms relies on one or more o f the task context operations described in Sect ion 2.3. Projections rely on slices, task-focused U I mechanisms rely on both slices and manipulat ion, and task management mechanisms rely on composi t ion . The A c t i v e Search faci l i ty , discussed in Section 3.3.3, uses the predict ion mechanism. The integration mechanisms also use a categorization o f elements and relationships based on their D O I . Table 3.3 defines the two thresholds we use to define three categories. Interesting elements (and relationships) are a l l o f the elements wi th a non-zero D O I , meaning a l l elements (and relationships) that have been previously selected and have not decayed to be uninteresting (Sect ion 2.2). Landmark elements (and relationships) are elements (and relationships) that are considered very interesting because their D O I has passed a threshold. Uninteresting elements (and relationships) have a negative D O I . A l l o f the task-focused U I mechanisms that we have implemented rely on f ixed thresholds. Later in this thesis, we discuss alternative implementations o f thresholds, inc lud ing the poss ibi l i ty o f implement ing adaptive thresholds, w h i c h can be combined wi th filtering and tree expansion management to implement features such as the guaranteed v i s ib i l i t y [50] o f landmarks in a filtered v i e w (Sect ion 5.5.3). Table 3.3: Thresholds used in the Mylar implementation Threshold Value interesting 0 landmark 30 3.2.1.Task Context Projections Task context projections use the task context to decorate an exis t ing data structure (Table 3.4). Projections use the D O I values from the task context to display a weighted vers ion o f the data structure. Projections can be combined wi th the task context s l i c ing operation i f the display mechanism is focused on d i sp lay ing one k ind o f element or one k i n d o f relation. For example, we project a task context onto a 38 hierarchical v i e w o f system structure (the Package Explorer , F igure 1.1) to show only elements w i t h a posit ive interest in the current task context, filtering a l l uninteresting elements. S imi l a r l y , a projection o f a task context onto a table can be used to sort elements by interest. T o integrate projections without needing to modify the or iginal data structure, the user interface facili t ies o f the under ly ing platform must support third-party extensions. For example, the Ec l ipse user interface a l lows decorators, filters, and sorters to be added to any v i e w in Ecl ipse . Table 3.4: Task context projection Input Output Description Example context, data structure decorated data structure F o r each element and/or relation in the data structure decorate it w i th the interest level S h o w only interesting elements, and m a k i n g the most interesting elements bold Projections can support any v i e w o f the structure in the task context. In this chapter, we describe projections onto tree and list v iews . Graph ica l layouts are also possible and are discussed in Sect ion 5.4.2. 3.2.2.Task-Focused UI Mechanisms Task-focused U I mechanisms (see Table 3.5) integrate task context wi th the exis t ing U I facili t ies in an appl icat ion framework. The goal o f each mechanism is to focus the U I by projecting the task context onto a particular U I faci l i ty; for example, ensuring that only the elements wi th in the context are v is ib le in a structure v i e w and that the interesting elements are a lways expanded. In this section, we describe the task-focused U I mechanisms that we defined for the Ec l ipse framework. These mechanisms generalize to other appl icat ion frameworks that use s imi lar U I mechanisms 3 3 . M y l a r implements each mechanism listed in Table 3.5, using either the entire task context or a slice o f the task context as input. For instance, in M y l a r I D E , the filtering, sorting, h ighl ight ing, text folding, and tree expansion management facil i t ies use a sl ice o f a l l interesting elements as their input. The editor management uses a sl ice o f a l l interesting files. The Ec l ipse perspective 3 4 management uses a sl ice o f a l l v iews last v is ib le in the context 3 5 . It is not necessary for an implementat ion to support a l l o f these A key difference between Eclipse and window managers such as Microsoft Windows is that Eclipse uses views, editors, and perspectives in place of windows. As such, the \"application window\" section of Table 3.5 describes mechanisms for managing each. The same facilities could also apply to managing windows. An Eclipse perspective is a layout of structure views and editors that can be changed and later restored. View opening and closing issues command interaction events. 39 mechanisms. The choice of mechanisms can be tailored to the particular activities supported by the implementation. For example, an implementation of task context for a text viewer could use the interest decoration mechanism alone to help the user pick out relevant regions of text. Table 3.5: Task-focused UI mechanisms for exposing interest Target Mechanism Description Applies to Filtering Elements below a certain DOI threshold are excluded List, tree, or graphical view Ranking Elements are ranked or sorted by their DOI List views, child nodes within tree views structure views Decoration Foreground or background color of elements indicates DOI Any view, can be continuous (e.g. background gradients) or discrete (landmarks are bold) expansion management Tree nodes are automatically expanded to correspond to a slice of interest Text corresponding to uninteresting automatically elided Any tree view (e.g. landmark nodes always expanded) Any text viewer supporting folding view management Automatically apply focusing mechanisms to a view on task context activation Any structure view application window editor management Editors corresponding to uninteresting elements are automatically closed Any editor listing (e.g., open fdes in an application) perspective management The views associated with a context are automatically restored on activation Any view management facility (e.g. Eclipse's view groupings) The first four mechanisms listed in Table 3.5 can be applied to any structure view, where a structure view is defined as a UI mechanism that displays elements and may additionally display relations between elements. For example, the \"Focus on Active Task\" button that Mylar can add to any structure view in Eclipse causes all four of these facilities to be enabled. The filtering causes any element without a positive DOI to be removed from the view. The ranking causes items within the view to be ordered according to DOI value. Decoration provides a visual representation of DOI level with one or more of foreground color, background color, font, textual annotations and iconography. Expansion management causes the nodes in a view with nesting, such as a tree, to be automatically expanded according to some task context slice. For example, Mylar's extension to the Package Explorer has a mode where it keeps all of the 4 0 interesting elements expanded. The text fo ld ing mechanism is analogous to the tree expansion management but works for text editors that support fo ld ing (Sect ion 3.3.1). The three appl icat ion w i n d o w management mechanisms listed in Table 3.5 enable the v iews and editors v is ib le in the appl icat ion w i n d o w to match those relevant to the context. W h e n a task is activated, M y l a r automatical ly opens a l l o f the v iews that were last used when the task was active (perspective management), opens editors for a l l interesting elements (editor management) and applies the v i ew focusing mechanisms to each v i e w (v iew management) 3 6 . A s the user works wi th editors, other editors for elements that have sufficiently decayed in interest are automatical ly closed. W h e n a task is deactivated, a l l editors are closed and v iews are returned to their or iginal configuration. The goal o f each o f these mechanisms is to focus the applicat ion on showing the task context, without requir ing manual effort from the user. 3.2.3.Task Management T o properly associate task contexts wi th tasks, we required a means for a user to specify w h i c h tasks are being worked on and when that w o r k occurs. The goal o f this integration is to ensure that users w o r k w i t h tasks wi th in the monitored applicat ion, such as Ec l ipse and M y l a r , where their interaction is monitored and contributed to the task context. W e implemented the Tasks U I to support task management for Ec l ipse . Th i s UI supports both programmers w o r k i n g wi th bug reports, and personal tasks used by both programmers and other kinds o f knowledge workers. The Tasks UI includes the Task L i s t v i ew , shown in Figure 3.3. Th i s v i e w a l lows users to create, organize, edit and share the tasks on w h i c h they work. The Task L i s t a l lows tasks to be created, and their descript ion, priori ty, personal notes and schedul ing information to be edited. Tasks worked on previously can be recalled either by browsing or querying their description or other attribute such as comple t ion date. Since teams often use a shared repository for tasks, the Task L i s t connects to various task repositories, w h i c h support the sharing o f tasks. Fo r example, for programmers, M y l a r 0.7 integrates tasks stored in the B u g z i l l a , Trac, and J I R A 3 7 web-based repositories. These are used by programmers for w o r k i n g wi th bug reports and feature enhancements. T o enable moni tor ing o f a l l o f a user's interaction wi th tasks, M y l a r ' s task management support a l lows the properties and comment threads on tasks to be edited directly from wi th in Ec l ipse . This faci l i ty ensures that when a programmer works wi th a bug report a l l interactions are monitored, such as interactions between the structure o f the system and the task (e.g., navigating a l ink The view management and perspective management mechanisms were added after the Mylar 0.3 release used for the programmer field study (Section 4). All mechanisms were available in Mylar 0.5. http://www.atlassian.com/software/jira [verified 2006-10-02] 41 from an exception stack trace in a bug report to the corresponding Java element). Tasks can be organized via categories, or by using queries over a shared repository. In Figure 3.3, the queries and repository tasks are identified by the small blue server image that is overlays the bottom of their icon. To support task context, the implementation's task management needs to enable a mechanism for the user to indicate which task is currently active. We use a \"radio button\" style toggle for this indicator (Figure 3.3, task with bold font38). This task management integration indicates to the task context model which interaction history events to associate with which task. If more than one task is activated, the composition operation associates the interaction events with each task that is active. Task activation can be streamlined further; for example, the opening of a task can automatically trigger the activation39. For the purpose of our validation, the task management facilities had to be of sufficient fidelity for participants to use them for their daily task management. Additional details of the task management that we implemented are available in the Mylar user documentation [36]. Monitoring interactions with the tasks themselves allows the task activity context (Section 2.4) to be used for focusing the Task List to reduce information overload when working with large numbers of tasks (Section 5.5.6). £ 3 *117517: add supp... £5 \\ 3 ID: I 117517 O p e n e d : ITue Nov 22 11:18:00 PST 20C.1 f ! > Attributes * Description • Attachments Description Type CowmitTeirplatesForMyiar Patch ~~ patch CommitTemplatesForMy lar. patch (now with... patch • Comments » New Comment R e v i e w i n g n o w . . . p r o b l e m s im i l a r to b u g 154324 1>] Planning Bugzilla Browser @ Task List £2 , Gj o ^ • 00 £ 1 Find: 117517: add support 8 i^r S Sft a S $ e Eft 8 & * PJJ * a Description Mylar - All Mine [bugs.ecli... 155044: show completed/atchi... 152416; consider increasing irn... * 117517: add support for co... * Search for duplicates should be... People - Rob [bugs, eclipse. org] 155906: Spelling error underlin... Products - eclipse [bugs. eclips... £} O * 154100: Platform level proxy s. O-J 9 98707: [Patch] Apply Patch sho. Products - jira [developer. atla.. JDB-29: Support Jira 3.4 rende.. Review review Eclipse 3,3 pious > Figure 3 . 3 : Task management facilities for activating and editing tasks Categories and queries are also decorated bold when they contain a task that is active. This is a user-configurable option in our implementation, turned off by default in order to match the expectation task opening with that of file opening. 42 3.2.4.Interaction History Storage A storage mechanism is required to enable persistence and recal l o f task contexts. Since the interaction history particular to each task encapsulates a l l o f the information that is needed to derive the task context, the task context model i tself is not persisted. Instead, when a task is re-activated, the corresponding interaction history stream, stored as an X M L fde, is re-processed. W e also store a single X M L file o f the same form for the task activity context. In memory , we maintain the meta-context and a single composite context that a l lows any number o f task contexts to be loaded concurrently. A s the user works , interaction events are appended to the corresponding event stream, w h i c h is per iodica l ly externalized as an X M L file. I f more than one context is active, the interaction events are distributed equally among the streams (Sect ion 5.1.1). The approach o f storing only the interaction insulates the storage mechanism from the implementat ion, a lgori thm, and processing method. It provides f lex ib i l i ty for operations on task context, as discussed in Sect ion 2.3. Ear ly benchmarks indicated interaction history file sizes o f 1 - 1 0 M B for a ful l workday o f interaction. However , g iven our field study data we estimate that programmers w o r k i n g full t ime should generate only around 1 M B o f interaction history information per month. The difference comes from the large redundancy in interaction histories that result from repeated interaction w i t h the same elements. T o address this redundancy, M y l a r ' s persistence support can collapse the interaction history for any context. Col lapse can be lossless i f it uses run-length encoding, or lossy i f it produces aggregate events for a l l interactions o f one k ind w i t h a single element. O n average, the latter reduces file sizes by ten times. Our remaining size differential comes from storing interaction histories as X M L text files, and text compression yields another ten times file size reduction. A s an example, the largest o f the 1,166 task context files in the author's task context store is 2 0 4 K B . The result is that even though a large amount o f interaction may need to be read for very long-running tasks, the performance o f act ivat ing a task is dominated by the t ime that it takes Ec l ipse to open editors, not the t ime that it takes to load the context. 3.3 Mylar IDE Implementation T o support investigations into the effect that an expl ic i t task context has on programmer productivi ty, we needed a high-f idel i ty integration o f task context wi th an I D E . M y l a r I D E implements the task context model for the Ec l ipse I D E , enabl ing programmers to w o r k in a task-focused way in every commonly used 4 0 part o f the Ec l ipse I D E . W e provide a thorough descript ion o f a l l M y l a r I D E features in the 0.7 and We report Eclipse usage statistics elsewhere [52]. These results are unrelated to this thesis, but provide data that indicates the most commonly used parts of the Eclipse IDE. 43 later versions elsewhere [36] [37]. In this section we describe how we integrated the task-focused U I mechanism wi th the Ec l ipse I D E and overv iew the features that were present in the M y l a r 0.3 field study release 4 1 (Sect ion 4). 3.3.1.Task-focused UI for Programming T o focus the I D E ' s user interface on the elements relevant to comple t ing the programming task, we project the task context onto the I D E ' s structure v iews . Decorat ion is supported by every structure v i e w that shows Java elements. Interest filtering is supported by the Ec l ipse I D E ' s Package Explorer , Project Explore r , Navigator , Document Out l ine , Debug , Search, Member s , Types , Problems, and Tasks v iews . Focus ing these v iews involves adding DOI-based decoration, filtering, automatic expansion, ranking, fo ld ing , and editor management (Table 3.5). W h e n browsing , edit ing, or debugging Java programs, M y l a r I D E decorates elements in any currently active task context wi th their interest level . This decoration is v i s ib le i n the Search v i e w (Figure 3.4 bottom right) where the gray elements are uninteresting, b lack elements are those wi th a direct interest, and bold elements are landmarks. Th i s decoration scheme indicates the D O I o f elements consistently regardless o f the v i e w in w h i c h they are displayed. F i l t e r ing has the effect o f removing the uninteresting elements from v i e w and works consistently for v iews that show the elements direct ly, such as the Package Explore r (Figure 3.4 top-left), and those that show proxies for the elements, as in execution stacks in the D e b u g v i e w (Figure 3.4 top right). F i l t e r ing is toggled using the right-most \"Focus on A c t i v e Task\" button v i s ib le as the rightmost icon on the toolbars o f those v iews . 4 1 Mylar 0.1, described in Section 4.2, provided only task-focused UI mechanisms and no explicit support for tasks. Although it was available with Mylar 0.3, we do not describe the working set management integration here. Working sets are user-defined groups of files, folders, and project. The facility was not used either due to a cumbersome UI or to the fact that Mylar already provides a lighter-weight version of working sets. Its role was to define a scope based on interest in a way that integrates with Eclipse's working set management. Conceptually this is identical to the change set management integration described in Section 3.3.5. 44 Package Explorer —^ . j_—_______— S Task List ^> Debug a 3= tqjj org.eclipse.mylar.ide.tests [dev.eclipse.org] m - (28 see m org,eclipse,mylar.ide,tests 9\"Qj_ ChangeSetManagerTest.java - ChangeSetManagerTest t e s t D i s a b l e d M o d e ( ) 9 Plug-in Dependencies Q _r>| org,eclipse,team,core_3.2,0.I200606( S £ 0 org.eclipse.team.internal.core,sut S ChangeSetManager. class Q (j? ChangeSetManager add(ChangeSet) OB* fa 3 . c5> „(£ 3?1 Jij Context [Mylar Active Suite] - (IH? org.eclipse.core.launcher,Main at localhost: 1 t>® System Thread [Finalizer] (Running) i>® System Thread [Reference Handler] (Rur 8 a ? Thread [main] (Suspended (breakpoint at == jCnangeSetManagerTest.te^ is.® System Thread [Signal Dispatcher] (Runn p,® Thread [Framework Event Dispatcher] (R, •, ~ ® T h K o a r l TCKa^h I aval P ^ o r ^ D i m a h ^ k d CD V f Search S3 Synchronize a B 'org, eclipse. team. internal, core. subscribers, ChangeSel o o x * EB 8 {^5)ai % • • • p r o t e c t e d v o i d t e a r D o w n ( ) t h [J p u b l i c v o i d t e s t D i s a b l e d M o d e C h a n g e S e t [ ] s e t s = c o l l e S° f o r ( i n t i = 0 ; i < s e t s c o l l e c t o r . r e m o v e ( s e t j v ^ \\ ^ ] Ei £BQ org,eclipse.mylar.ide.tests - sre - org,eclipse.rr Q 0 N ChangeSetManagerTest « testDisabledMode() • testSingleContextActivation() $n org,eclipse,mylar.internal.team - sre - org.eclip I f>] Figure 3 . 4 : Decoration, filtering and ranking of Java elements Interest filtering and decoration work for all of the Eclipse IDE views that are used to navigate system structure, not only for views that show Java elements. If a view shows a file, such as the Project Explorer, interest filtering works whether the file is structured and has contents for which a structure bridge is registered, or whether the file is unstructured, as in the case of the \"refresh.gif image file (Figure 3.5 top left). For structured files, the Outline view, which provides a structural view of the file being edited, filters all uninteresting X M L elements from the build.xml file (Figure 3.5 bottom left). The Problems and Tasks views, which show static checker or annotation-determined items in a list (Figure 3.5 bottom right) can also be filtered to show only the items relevant to the task context. 45 Project Explorer S3 E l S \" f e f i org.eclipse,mylar-site [dev.ec : I a bu i l d . xm l 0 | build-lib.xm '-' t j j org. eclipse, my lar. tasks, ui [de Q £ j eld 16 *rj refresh.gif •5^ plugin.xrnl a 0 1 Outline • U A ^ ^ \\ ^ (Jjj build.xml A. < p r o j e c t d e f a u l t = \" s o i . i r c e \" n a i r i e=\"build\"> = < t a r g e t n a m e =\"source\"> • a < p d e . e x p o r t P l u g i n s d e s t i n a t i o n s \" ? e x p o r t S o u r c e = \" t r u e \" e x p o r t T y p e = \" z i p r f i 1 e name=\"my 1 ar - a r c h i v e - Q . 6 . 2 p l u g i n s = \" o r g . e c l i p s e . m y l a r , o r g . e c l i p s e .mylar.bugs i l l o r g . e c l i p s e . m y l a r . b u g z i l l o r g . e c l i p s e . m y l a r . b u g z i l l o r g . e c l i p s e .mylar. context. llll a - S t ] build £D source [default] < > ;pde,exportPjuginsj 8 §) target < > pde.exportPlugins I Problems £3 1 error, 47 warnings, 0 infos Tasks S3 ^ j |Filter matched 100 of 357 items I i T>M*f * * **•! JB!*^ Description * © Duplicate target \"plugin_e & The serializable class BugzillaRi K l ' > Description TODO : all of this should be £ Figure 3 . 5 : Decoration, filtering and ranking of various program artifacts Tree views support the automatic expansion mechanism. For example, when interest filtering is on, the Package Explorer always has all of its nodes expanded to avoid the user needing to repeatedly expand and collapse nodes. Auto expansion is always enabled when the view is filtered, meaning that the user cannot manually collapse the tree. Removing this ability from the user is acceptable because decay ensures that interest-filtered views do not show a scrollbar when working on a typical task and when used on a sufficiently large display (e.g., 1000 pixels tall and higher). The task-focused UI mechanism that corresponds to filtering and automatic expansion for editors is automatic DOI-based text editor folding. For example, when editing Java code, Mylar makes task context explicit by automatically unfolding the interesting elements and folding all uninteresting elements (Figure 3.6). 46 [jj *ContextChange5etM,. . S3 2) ChangeSetManagerTes... jojip ChangeSetManager.class + private void initContextChangeSets() {Q [*] © * For t e s t i n g . [ ] public void clearActiveChangeSets() { activeChangeSets.clear() ; > <& interestChanged(Llst elements A © dearActiveChangeSetsQ void - ContextChangel ^ S public IResource[] getResourc B getTask(IMylarContext context) ITask- Contex-+ public void c o n t e x t A c t i v a t e d ( • activeChangeSets Map < Java, lang, String, org. < a CHANGE_SET_LISTENER IChangeSetChangeLi ^ + public void c o n t e x t D e a c t i v a t e D collectors List • TASK_ACTIVITY_LISTENER ITaskActivityLister v f < ) \"» 1 > private ITask g e t T a s k ( I H y l a r C Press 'Ctrl+Space' to show Template Proposals List activeTasks = TasksUiPlugin. getTaskLis tManag i f (activeTasks.size() > 0) { fvj [ referenced by © getChangeSetManager() ; run() 8 ChangeSetManagerTest 8 <5^ . referenced by : suite() 9 Q% CvsRepositoryProvider 8 referenced by 2] plugin.xml: repository Figure 3.10: Elements and relations with predicted interest in the Active Search view 3.3.4.Context Test Suite Eclipse provides an integrated JUnit43 facility, used for running unit test suites. A unit test is defined by being a subclass of j u n i t . f r a m e w o r k . T e s t C a s e . When using Eclipse, the programmer will specify a test suite or collection of test suites to run. On a large system, such collections can involve a large number of slow-running tests. The context test suite uses a slice that gathers all subtypes of j u n i t . f r a m e w o r k . T e s t C a s e in the task context. Since elements of a predicted interest are part of the context, this includes all test cases interacted with directly and those that have a predicted interest because they are structurally related to elements with positive DOI. For example, when editing a method, the method can become a landmark, which causes the Active Search facility to find all unit tests for that method; these tests become a part of the task context. Running the context test suite is identical to running a regular test suite (Figure 3.11), but does not require the programmer to indicate which test types should be run. http://www.junit.org [verified 2006-10-02] 5 0 LJ m K B > • 1 Name: Test Active Context (plug-in) type filter text | § JUnit Q | Main (*)= Arguments > 5 S 9 Eclipse Application ^ Equinox OSGi Framework EE Java Applet Subclasses of TestCase in the active task context automatically added to suite, LTJ Java Application J u JUnit J u JUnit Plug-in Test S Jv j Mylar Context Plug-in Test J i j jTest Active Context (plug-in)l 8 J v j Mylar Context Test Jvj Test Active Context 4 ^ Remote Java Application 3 SWT Application A p p l i '• ; Revert Figure 3.11: Automatic context test suite 3.3.5.Context Change Sets In Eclipse and other IDEs, change sets are groupings of outgoing or incoming revisions to files. A programmer can set up change sets manually to perform revision operations (e.g., commits, updates) on parts of the system rather than on the whole system. Mylar IDE's automatic change set management creates a change set for each activated task and populates that change set automatically with a slice corresponding to all of the fdes modified as part of the activity associated with the task. These slices differ from other slices presented by the task-focused UI because they ignore decay and because they persist when a task is no longer active. For example, if outgoing changes remain when the programmer switches to a new task, the previous task's context change set will continue to contain the outgoing changes until they are committed (Figure 3.12 left). This support enables the programmer to switch between multiple tasks without committing the code modified as part of the current task before switching to another. As with other facilities that are automated by task context, the change set management removes the burden of manual change set creation from the programmer. The explicit association between change sets and tasks also supports automatic commit messages, which can then be used to navigate back to a task from a commit of the context change set, as visible in the History view (Figure 3.12 right). 51 B 1- ' Synchronize Change Sets for CVS (Workspace) ni Hi + 4-\" , 117517: add support for commit comment templates 3 43-j 155044: show completed/archived tasks worked o - t 7 org,eclipse,mylar.tasks.ui [dev.eclipse,org] • '<© src/org/eclipse/mylar/tasks/ui TaskListManager.java Q % [reives] (Sep 5, 2006 2:43:19 PM) Progress on: 156104: Er - org,eclipse,mylar,context,core [dev.eclipse,org] S ^ src/org/eclipse/mylar/internal/context/core/util [Jj» DateUtil.java * fc? org,eclipse,mylar,tasks,ui [dev.eclipse.org] IS 45 [reives] (Sep 5, 2006 4:42:25 PM) Completed: 155469: res i l ' History £2 TaskiistMa r'' =\"' 1 , ir J A W A Revision < 0 0 u 0 0 0 n jflj. Show Annotation (^ r Refresh View QL Open Corresponding Task 8/.. 8/.. 8/„ 71.. 71.. reives Pt reives Pt mkersten Pr mkersten G reives PrC Progress on: 152234: Commands for quick Open/Activate/Deac tivate Tasks v F i g u r e 3 . 1 2 : A u t o m a t i c c o n t e x t c h a n g e se t s 3.4 Mylar Browser Implementation To validate task context for the more generic knowledge work domain, we needed an implementation of Mylar that supported the resources commonly accessed by knowledge workers: files and web pages. Email is another medium used by knowledge workers for defining work items, and approaches such Taskmaster [5] have demonstrated that tasks can be made a more primary part of the email inbox. In order to make tasks the central mechanism for interaction, our approach is to enable collaborations around tasks and task context via the Task List (Section 5.3) rather than integrating task management into existing tools such as email readers. Unlike Mylar IDE, which is integrated with the Eclipse IDE, the Mylar Browser is a standalone application composed of the parts of the Eclipse platform that support working with files and Eclipse's embedded web browser. We created a new view, called Resources, which supports the display of files, folders and web site U R L s 4 4 . The task management and task-focused UI features were identical to those of the Mylar IDE. Unlike the Mylar IDE, which provides additional task context integration facilities such as change set management, the Mylar Browser is a simpler application that provides only task-focused UI integration. The task context model, operations, scaling factors, and thresholds, and all other parts of the Mylar frameworks were unchanged in Mylar Browser. The Myiar Browser is an Eclipse Rich Client Application that uses the file management features from the Eclipse Platform, but excludes any programmer-specific features: http://eclipse.org/rcp [verified 2006-10-02] 52 The key difference in the integration o f task context wi th a b rows ing tool is the difference in the structure o f information that knowledge workers v i e w and create. A program has an expl ic i t pr imary structure. The task context model i n M y l a r I D E is aware o f interaction w i t h the program's expl ic i t pr imary structure down to the c o m m o n l y used and fine-grained member level o f granulari ty 4 5 . In contrast, the documents that knowledge workers use often have a less apparent structure. 3.4.1. Navigation Support for Files and Web Resources T o support users navigat ing wi th files and web resources, we created a Resources v i e w (Figure 3.13). Th i s v i e w a l lows the user to l ink in any folder from their file system or from a network drive (e.g., the \" M y Documents\" folder). Each folder l inked is a root node in the tree. B y default, the tree is in focused mode, showing only interesting resources in the current task context. A n addit ional root node cal led \" W e b Contex t\" contains all o f the web pages in the task context. 3.4.2. Capturing Interaction with Files Knowledge workers browse and edit a variety o f files. Some o f these have a wel l -def ined structure that is understood by M y l a r (e.g., X M L documents); others have a structure, but the structure is not understood by M y l a r Browser (e.g., Mic rosof t W o r d documents wi th sections); and f inal ly some do not have a w e l l -defined structure a l l (e.g., images). M y l a r Browser monitors selections d o w n to the file level o f granularity. The more a file is selected the more interesting it becomes (i.e., toggl ing between two v is ib le editors w i l l increase interest identical ly to how it w o u l d when toggl ing between elements v is ib le in a structure v i e w in M y l a r I D E ) . M y l a r Browser also understands directory structure, and propagates interest to directories containing the file when a file is selected. I f an Ecl ipse-based editor is available for the file, selections in the editor are also captured. I f the Ecl ipse-based editor supports mod i fy ing the resource, and M y l a r supports the editor, edit interaction events are also captured. Since many o f the documents that knowledge workers edit are Mic roso f t Off ice based and not Ec l ipse based, we needed to ensure that interaction wi th these editors was monitored sufficiently. T o support this requirement, we relied on the S W T 4 6 too lk i t ' s abi l i ty to embed Mic roso f t Of f ice documents. Implementing a structure bridge specific to the contents wi th in Microsof t Off ice or other semi-structured documents is technical ly possible and w o u l d result in addit ional selection and edit events for parts o f a For Java, this is members such as classes and methods, for X M L it is elements. The same level of granularity is commonly shown in IDEs' structure views. http://eclipse.org/swt [verified 2006-10-02] 53 document, such as outline section headings. We did not implement this bridge as we did not require this level of support for our validation of the Mylar Browser (Section 4.4). Figure 3.13 shows the author's workspace with the Mylar Browser when working on this dissertation. The Task List is identical to that of Mylar IDE and shows both shared tasks (those with 'incoming arrows') and personal tasks, such as \"book F S E trip\". The editor pane shows an embedded Microsoft Excel document and the Resources view shows the files and pages that are part of the task context. J Resource - Thesis/Study 2 - Field/fse-usage-subjects.xls - Eclipse SDK Fife E.drt Navigate Search Project Run Window Hep B Task List a \\ C ET\\ oo|£fj~I Find: 98: Ante thesis Description • i Q * * 1488-U: [connector] Mercury TestDirector £ 159706: instalkng or updating to 0.7.0 cause; People • Rob [bugs.edipse.org] a ~ I * 152272: Can't save new bugzilla issue withcx. * 159693: Offline replication broken? * 15S906; Spelling error underline n editor sho Ij-fK-usage-subjec.,. U j io • B / e ! rB ! i-Cj Resource j Planning '.Resources Project Explorer 8 ic> Private - Business Qt book AOSD PC meefcng trip book FSE trip S Q$j Products - Aspect; [begs.eclipse.org] 5^ * 141497: Prototype phoenix look and feel for i 8 ^fl Theses [Guafiajm,cs,i&c-aj % 98: write t h e m rTj 102: section 4: discussion < 1 Z I A _ _ i _ i c D E i luserid ratic ratio-mylar ratio-improv filtered-e 2 j 970 2 9 7.841154 171 98029 0 25393 3 1660 10 26 394806 161 38777 0.15768 4 1548 14 35 951595 155 81554 5 1565 2.6 5 4034406 111.3392 0 18319 6 1752 2 7 5 4415116 102 31863 0 02905 7 ' 2194 1.7 33242264 91.673164 8 2364 8 8 12 986942 47.690014 0.3009 9 1735 5.8 3 210892 42 11159 0 32402 10 936 11 14 30483 30 750698 0.080 11 1803 6.7 8.7107725 30 724312 0 27006 12 2007 68 7 4337964 9.738513 0.1418 1208 4.1 4 339939 5 392221 0 01507 j 1 4 1684 2.2 2 229797 3.461457 0.05948 919 7.7 6 882239 -10.189491 0 24701 16 2041 16 13.547705 -14.723473 17 1174 11 8 0757065 -26 617714 18 j 19 Edit ratic (no 0 0436876 20 Edit ratio 0 0033825 21 22 Selections 153645 23 interesting 84 17% 24 predicted S 32% 25 decayed 2 06% 26 new 3 45% 27 23 H < Averaqe task! 18 5625 • • i \\Sheet l / S h e e t 2 / S h e e t 3 / S '% Web Context 0-1 file: S new-0.3.html B Q nr!p;/.'googe,com @ http://gpogle.com/ 8 k j local - Publications 6 & 2005 AOSD - Mylar my l a r - ao sd2005 v28- submi t ted .doc a S> 2006 CHI - Mylar Desktop « | ] T a s k C o n t e x U F o r K n o w l e d g e W o r k e r s - S t l B l & 2006 DevWorta • Myar *S[j part2-active-views.psd 8 ta- 2006 F5E - Mylar ^3} my l a r - f se - submi t ted -doc IeJ org.eclipse.mylar.browser-feature [cascade.cc.ubc.c - 't^ n Thesis [Thesis] '\" i^ b Figures ^ mylar-0.1-monitor.gif * ^ mylar-0.7-browser.gif C-fr References B l=% Study 2 - Fleki ™ 3 f se -usage- subject s .x i s '5 i c t Study 3 - UBC £ j Elves SB Metrics.xls •i 'Sji^ttheste^doc S° Synchronize History i Search Error Log : (Ci Progress i I 69M of 129M Figure 3.13: Mylar Browser showing Task List and embedded Excel document 3.4.3.Capturing Interaction with Web Resources To support interaction with web resources, we needed a mechanism for monitoring web browsing activity. To maintain a similar level of granularity to file navigation, we chose the U R L 4 7 as the element of interaction. The monitor was extended to capture successful retrieval of U R L contents for any click http://www.w3.org/Addressing/URL/Overview.html [verified 2006-10-02] 54 made wi th in the browser embedded wi th in Ec l ipse (Internet Exp lo re r on W i n d o w s 4 8 or M o z i l l a on L i n u x 4 9 ) . The only structural relations that we infer form U R L s is the web site from w h i c h the relation originates. The result is that the task context capture and display used for web documents looks and feels consistent to that used for fdes. U n l i k e its abstractions for w o r k i n g wi th resources such as files, the Ec l ip se Platform provides no support for handl ing or d i sp lay ing web documents. In this respect, the integration o f web resources differs from other kinds o f files: when a task context is active, the Resources v i e w shows al l o f the web resources in the context. W h e n a task context is not active, no web resources can be shown because they only exist in the context 5 0 (i.e., are stored in the interaction history). 3.5 Implementation Summary The pr imary goal o f our implementat ion was to support the study o f how the task context model supports programmers and other kinds o f knowledge workers. W e implemented a generic task-focused U I and task management facili t ies to support both kinds o f users. W e integrated M y l a r I D E deeply wi th almost every part o f the Ec l ip se I D E , to ensure that the entire user experience when programming wi th Ec l ipse could be re-focused around task context. Th i s i nvo lved using each o f the operations defined in Section 2.3. W e then extracted the parts o f M y l a r I D E that were generic to w o r k i n g wi th files, added support for web browsing , and, without altering any o f the task context model or task-focused U I , created the M y l a r Browser . In the next chapter, we discuss the val idat ion o f task context v i a field studies performed on these two applications. http://microsoft.com/windows/ie [verified 2006-10-02] http://mozilla.org and http://linux.org [verified 2006-10-02] A n alternative approach would have been to store al l o f the web navigation history in the user's workspace, and then to use a filtering mechanism similar to files. This kind o f global persistence o f web navigation information was beyond our validation needs. However, we did have to implement a cache for all page titles in order to ensure that context activation did not require waiting for frequent round-trips to the server. 55 4. Validation T o validate our thesis, we needed to test how the use o f task context impacts the productivi ty o f programmers and to test whether the task context model generalizes to other kinds o f knowledge work . In this section, we describe two f ield studies we performed o f programmers us ing task context for w o r k i n g on well-structured software systems and a third f ie ld study that invo lved a more generic class o f knowledge workers using task context for a broader set o f less structured artifacts. Our first f ie ld study was a prel iminary feasibil i ty test o f task context i n v o l v i n g the M y l a r 0.1 prototype, w h i c h added the task-focused U I and a single task context model to the Ec l ipse I D E . Th i s study invo lved s ix professional programmers at I B M w h o were w i l l i n g to try M y l a r 0.1 for one week [39]. The data from this study showed that programmers voluntar i ly used and l iked M y l a r 0.1 (Sect ion 4.2). In addit ion to gathering qualitative data, we also measured the impact that M y l a r 0.1 had on the I B M programmers ' product ivi ty . T o measure the effect on productivi ty, we devised a s imple metric cal led edit ratio, the proport ion o f edits over selections. A l t h o u g h the number o f subjects was too smal l to y i e l d statistical significance, the usage data from the I B M study indicated a p romis ing average increase in the edit ratio o f the participants (Section 4.2.4). The study results also indicated that task management and a better integration o f task context wi th Ec l ipse was required for the programmers to use M y l a r on an ongoing basis. Our second field study o f programmers invo lved the use o f M y l a r 0.3. Th i s version o f M y l a r supported task context for mult iple tasks, provided a v i e w for swi tch ing between tasks, and integrated a B u g z i l l a cl ient to support programmers us ing B u g z i l l a repositories for their task management. T o recruit study subjects we presented a preview version, M y l a r 0.2, at the E c l i p s e C o n 2005 conference 5 1 . W e then released a standalone M y l a r M o n i t o r (i.e., no M y l a r UI components) to the 99 programmers who signed up for our study f o l l o w i n g E c l i p s e C o n . W e measured the edit ratio o f the programmers in the study dur ing approximately two weeks o f ful l- t ime programming. After they passed a pre-determined threshold o f act ivi ty, we a l lowed programmers to install M y l a r 0.3. W e required approximately three weeks o f fu l l -t ime programming wi th M y l a r to accept their usage data in the study (Sect ion 4.4.2). A t the end o f the study, we had sixteen accepted subjects. Our analysis o f this usage data showed a statistically significant improvement in the edit ratio o f these subjects (Sect ion 4.3.3). 1 http://eclipse.org/mylar/publications.php [verified 2006-10-02] 56 The first two studies tested the task context model on programmers w o r k i n g wi th software systems, w h i c h have a clear and expl ic i t structure. T o test whether task context supports other kinds o f knowledge workers w h o interact wi th less structured information, we deployed a field study o f the M y l a r Browser , w h i c h supports task contexts for file and web brows ing act ivi t ies . The M y l a r Browser uses the same task context model , algori thms, and task-focused UI facili t ies, but does not include programmer-specific features. The study invo lved eight participants wi th a broader range o f professions. A l l o f the participants used Mic roso f t W i n d o w s , Mic roso f t Off ice and web browsers for their knowledge work activities. W e asked them to try to use the M y l a r B rowse r to work wi th these applications. The results o f the third study demonstrate that the task context model generalizes to supporting file and web brows ing activities (Section 4.4). The usage data indicates that when used for file and web brows ing the task context tends to represent a smal l subset o f information from the large set o f information available on shared document repositories and on the internet. W e conclude that our interaction-based frequency and recency based weight ing was effective at showing the relevant information to knowledge workers authoring and brows ing documents and web pages. W e also found that a key component o f our approach for these works is the decay mechanism that prevents v iews o f task context from becoming overloaded. 4.1 Methodology W e chose to validate the task context model through f ield studies because val idat ing the c la ims made about this mode l required observing the effects o f the model on the performance o f knowledge work . K n o w l e d g e work typica l ly occurs in a demand and deadline-driven, col laborat ive, and mult i - tasking environment [26]. W e d id not believe that we could reproduce this environment wi th sufficient fidelity wi th t ime-constrained and mocked-up laboratory studies. In addit ion, we d id not have evidence that the inherently non-expert student subjects who were available to us for longer-running laboratory experiments w o u l d provide a sufficient approximat ion o f experts w o r k i n g in the field. F i n a l l y , we wanted to ensure that we tested the effects o f subjects' voluntary use o f task context for dai ly work over the course o f many days and weeks, not just over the t ime-constrained per iod o f a laboratory study. A s a result, the field studies on w h i c h we report invo lve moni tor ing subjects in their o w n work environment. The moni tor ing facili t ies we designed and used a l lowed us to interpret the activity o f the workers without affecting their work process and without requir ing them to send company-private informat ion 5 2 . For each o f the three studies described in the f o l l o w i n g sections we describe the methodology used (in the M e t h o d and Study Framework section for each study). W e also describe any shortcomings or factors that cou ld affect the va l id i ty or accuracy o f our results ( in the Threats section for each study). The My la r Monitor uses a one-way hash function to obfuscate the handle identifiers o f elements. 5 7 4.2 Study I: Programmer Feasibility Study O u r first study sought to gather data about how programmers might use task context and whether programmers l iked w o r k i n g wi th an expl ic i t task context. 4.2.1.Subjects The participants in our study were s ix senior I B M Toronto L a b programmers w o r k i n g in Ec l ipse 3.0 on projects i n v o l v i n g WebSphere 5 3 , X D E 5 4 and Ec l ipse plug-ins. W e also invo lved a summer intern for the purpose o f having a more interruptible subject w h o could test any patches and releases made during the study. W e did not include the intern's data in the results we report; the results presented are for the s ix experienced professional developers. Before the study, subjects were g iven a questionnaire asking about their experiences and problems using Ec l ipse (Append ix A ) . The problems cited included a d is l ike o f the way in w h i c h editors and files were handled, and overpopulat ion o f tree v iews , such as the Package Explorer . Table 4.1 lists the answers that the subjects had to the question o f \"gripes that y o u have wi th Ec l ipse ' s current support for your navigation needs\". The responses o f subjects 1, 2, 4 and 5 are indicat ive o f the problem o f information overload and the need to scope down the amount o f information presented. Table 4.1: Subject comments related to information overload in Eclipse Subject Answer 1 \"I w i s h the content in the navigator v i e w and the package explorer v i e w can be more condensed, e.g. reducing the vertical spaces between each package. So that the more [sic] information can be displayed in a v i e w wi th the same s ize .\" 2 \"I l ike to collapse the tree that I have finished look ing at and only expand those that I need at the moment. It may be complicated i f I have many Java projects in the workspace . . . . User has to filter out unwanted files e x p l i c i t l y . \" 3 \"I am a s imple user, does not l ike fancy stuff, just basic functions are fine wi th me.\" 4 \"Ex t remely s low. For instance, unfolding or fo ld ing the tree . N a v i g a t i n g between open editors using keyboard. D o quick fix us ing keyboard so that I don ' t have to change to different v i e w s \" 5 3 http://www.ibm.com/software/infol/websphere [verified 2006-10-02] 5 4 http://www.ibm.com/software/awdtools/developer/rosexde [verified 2006-10-02] 58 5 \"I w o u l d l ike to have a blank v i e w w h i c h I cou ld drag files and bookmarks onto w h i c h w o u l d serve as a navigator. That way I don't have too be confined to packages, projects, etc . . . I don ' t l ike managing the expansion state o f trees\" 6 \"Sor ry , none o f f the top o f my head.\" 4.2.2. Method and Study Framework W e used a diary study format to gather feedback from the subjects [57]. The programmers were asked to use the M y l a r 0.1 prototype and to provide dai ly qualitative reports about their experiences. The study required that programmers work wi th plain Java code since M y l a r 0.1 only provided a structure bridge for Java. W e augmented the diary study format wi th the M y l a r M o n i t o r ' s quantitative measurement by recording the programmers ' act ivi ty. For the duration o f the study, a researcher was co-located wi th all but one participant. However , to m i n i m i z e the time taken from the participants, support and interaction over the week was kept to a m i n i m u m and was provided through emai l . D u r i n g the five-day study, the programmers used a configurat ion o f Ec l ip se 3.1 that included the M y l a r Package Explore r , Out l ine , and Problems L i s t . Programmers were g iven the suggestion to try, but were not forced, to use the M y l a r v iews . T o support our goal o f producing an intuitive user interface that exposed D O I , without d iverging too much from the feel o f Java v i ews or requir ing too much time from the subjects, we provided no t raining and only required the programmers to read a single page o f documentation. Before the week o f the study, we collected baseline data about the programmers ' Ec l ip se usage, logging their edits and selections as they worked , and capturing summary data. The total amount o f t ime that Ec l ipse was active on the programmers ' machines was 25.45 hours for the three days o f baseline moni tor ing. The M y l a r M o n i t o r provides a moni tor ing framework that reports some low- leve l summary statistics (e.g., F igure 4.1 right side) as w e l l as export ing this usage from the programmers ' desktop. The M o n i t o r also exports this information to a log fi le. A n addit ional v i e w also a l lowed us to inspect the subjects' single task context model dur ing the exit interviews (e.g., F igure 4.1 left side). 59 rff DOI Model ?1 Outline • t l Usage Statistics 2Z ^ edit ratio: 0.05 jjj 4IP RemoteException,class (137.59964 A 111 WSIFOperation_.Jms.java (112.40C a setPropertyValues (112.40016) G WSIFOperationJms (112.40016) tfi org.apache.wsif (91,90017) | WSIFService. Java (91.90017) V? RemoteException (75.60011) WSIFDeFaultCorrelationService (60 a checkForTimeouts (60.500053) tfi- org. apache. wsif. base (60.500053) Li] WSIFDeFaultCorrelationService, jav 0 ©put (59.70004) i l l WSIFResponse. Java (54.200096) B setUpBindingNamespaceURIs (43.7 H setUpAddressNamespaceURIs (43. ..get (39.400047) [p WSIFServicelmpI. Java (33.400116) 2) WSIFInterceptorConfig. Java (32,7( CO WSIFServiceFactory. Java (32.5001 S . WSIFConstants. Java (32,200066) HI PopulatedlnstanceExtensionRegisti r t l • •«• II ,XZJ < I \\> f g nurnKeystrokesJavaEditor: 54 ^/numSecondsElapsed: 2318 2) numSelectionsJavaEditor: 45 2] numSelectionsJavaEditorAutoFold: •!:numSelectionsJavaOutline: 0 g*_ numSelections JavaOutlineMylar: 1 * L a numSelectionsOther: 11 t^nurnSelectionsPathfinder: 0 B numSelectionsPkgExplorer: 25 J^numSelectionsPkgExplorerMylar: 8 EinumSelectionsProblems: 1 ^numSelectionsProblemsMylar: 1 ) numSelectionsSearch: 3 ^numSelectionsSearchMylar: 0 ^s ta r tDa te : 2004-09-20 ^/startTime: 20:3:15 Figure 4.1: Ranking of elements, usage statistics This study was performed using Mylar 0.1. The most notable differences between this early version of Mylar and later versions are that it supported only one task that was always active and that it did not provide task management support. In addition, the task-focused UI provided replicas of the Eclipse views rather than integrating with the existing Eclipse views and did not allow the highlighting scheme to be turned off. Figure 4.2 depicts how Mylar 0.1 presented task context for each of the three views visible in Eclipse's default Java perspective. The highlighting scheme used color to decorate elements with interest level, with deeper hue indicating a higher DOI\". Since Eclipse already uses highlighting to indicate the currently selected element, Mylar 0.1 used bold font to indicate the currently selected element. There are several items to note in Figure 4.2. 1) Mylar Package Explorer: Interest-based filtering is enabled, resulting in only the files and libraries relevant to the task being displayed. The number of filtered elements is indicated on the parent label. For example, the o r g . a p a c h e . w s i f package in Figure 4.2 shows eight interesting files of the fourteen files in that package. The filtering mode reduces the need to manually expand and scroll the tree by 5 5 The color and icon scheme metaphor in Mylar 0.1 was that of a bathygraphic map, one of the original inspirations for the task context model, where uninteresting elements were 'sunk underwater'. 6 0 actively maintaining the visibility of high-interest elements; this helps keep hierarchical relationships visible, such as the package structure. A highlight-only mode can be toggled in which no elements are filtered and items of interest stand out through highlighting. 2) Mylar Problems List: Problems of interest are highlighted to stand out from the large number of items typically populating this view. This view is populated identically to the JDT problems list, but corresponding program elements are additionally displayed and used to highlight the DOI of the problem. Mylar 0.1 did not provide filtering in this view. 3) Mylar Outline: Interest filtering and highlighting shows only the members related to the task. The Mylar editor has an option to actively fold and unfold elements according to interest, reflecting the filtering state of the Mylar Outline. • Mylar - WSIFRequest Java - Eclipse Platform E.ile Edit Source Refac_or __avigate Search Project Run Wjndow yelp ^ P a c k a g e Explorer (Mylar) ZZ Hierarchy \" • ^Ser ia l i . . . ^JMSMana. . . Message... i [tj WSIFReq... £_ \"\" •. w56 ^ p u b l i c c l a s s U S I F R e q u e s t i m p l e m e n t s S e r i a l i z a b l e ( 'CJ Figures-test - wsiF-2.0 - ;*src |5..35| - j\"B org.apache.wsif |8.,14| !+:• jij WSIFConstants.iava jjj WSIFInterceptorConfig.iava J . WSIFMessage.java !+! ii) WSIFRequest.java !+; [f] WSIFResponse.java [Jj WSIFResponseHandter.Java +•• |?j WSIFServlce.java ill WSIFServicefactory-Java - (B org.apache.wsif .providers,jms |6.,6j \\S\\ JMSFormatter.java [.}. HMSMessageJava ! [j) PrimitiveTypeFormatHandler.java f *l\\ UJ WSIFDynamicProvkler_Jrn5.]ava V I / j / ; WSIFOperation_Jms,java : * \"]} WSIFPor.Jms.java ~ £Jj org.apache, wsif .providers, soap, apachec WSIF3msSender.]ava - -jjjf org.apache.wsif.providers.soap.apaches [J] SOAPJMSComection.java - ft; org.apache.wsif .schema |4..i.| Si \\)j Attribute,Java +; j $ ComplexType.java ii] SchemaType.java *i [/j 5imple Type, Java - JRE System Ubrary [j2rel -4,2_05] \" set IncomingMessage( i # setOutputName(String) • se.Inpu.Name(String) A inputName A contextMessage F i g u r e 4.2: M y l a r 0 . 1 , u s e d f o r I B M s t u d y 4.2.3.Results: Usage statistics The study ran for five business days. During the study, we logged a total 56.99 hours of Eclipse usage across subjects. At the end of each day, we asked the subjects to send their usage data and answers to a 61 one-page survey of their day's experiences. At the end of the week, we conducted half-hour wrap-up interviews in person with each of the subjects. 2500 2458 2000 1500 1000 500 0 1121 750 editor outline mylar outline 323 package mylar package explorer 56 problems list 101 mylar problems list 138 search 79 other Figure 4 . 3 : Mylar view vs. standard Eclipse view selections across subjects For all but the Outline view, when a Mylar view was available as a replacement for a plain Eclipse view, the programmers used the Mylar view more than the plain Eclipse view (Figure 4.3). The view used most by the programmers was the Mylar Package Explorer, which is consistent with the baseline ratio of view usage where the participants used the regular Package Explorer most. The reason for the Outline's lower use is that the most active programmer, who contributed to 80% of that statistic, had not read the page of documentation and had not enabled the Mylar Outline view (enabling this view was the only configuration required of the study subjects). Once enabled, the subject used the Mylar Outline almost exclusively. The complete usage statistics for the week using Mylar are visible in Figure 4.3. Note that the \"editor\" selections are the result of following references and links in the Java editor and are independent of the Mylar views. The \"other\" selections are dominated by use of the Type Hierarchy view. 4.2.4.Results: Edit Ratio Change To measure any effects that an explicit task context could have on the subjects' productivity we defined the edit ratio measure. The edit ratio is the number of keystrokes in the editor over the number of structured selections made in the editor and views. We hypothesized that if the elements relevant to a task are visible and highlighted in the IDE views, programmers should spend less time trying to find those elements and more time working on their task. The improvement we observed in edit ratio between the baseline usage data and the Mylar usage data was encouraging. Finding a meaningful statistic of this ratio was challenging not only due to the small sample size, but also due to the short duration of the study. From the daily diary responses, we learned that several subjects switched tasks between the baseline week 62 and the study week (e.g., one stopped developing code and moved to a debugging stage). A s imi lar factor was a change in the amount o f t ime o f active Ec l ipse development between the baseline and M y l a r week (e.g., two programmers spent less than one half-hour in Ec l ipse dur ing the baseline week) . A l t h o u g h the sample size in this study was too smal l to y i e l d any conclus ive results, the 15% average edit ratio improvement across subjects was promis ing . A l s o , the single most active subject, w h o actively worked in Ec l ip se for nineteen hours dur ing the week and accounted for 4 0 % o f the act ivi ty across both weeks, reported that she worked on s imi lar tasks both weeks. Her edit ratio improved by 4 9 %. D u r i n g the wrap-up interview, we asked the subjects i f the significant increase in the edit ratio was consistent wi th their impressions. A l l o f the subjects agreed, stating that they d id not need to navigate or search for elements as much as they d id wi th the pla in Ec l ipse v iews . 4.2.5.Results: Model Feedback A l l o f the subjects reported that the task context model accurately represented the information relevant to their work. D u r i n g the wrap-up interviews, we showed them the hidden D O I M o d e l v i e w (Figure 4.1) and asked how closely the ranking matched their work over the week. A l l reported that it c losely represented the parts o f the system on w h i c h they had worked . W e had buil t this v i e w for internal debugging and inspection purposes. Some programmers were surprised by the accuracy o f this v i ew and expressed interest in us ing it for their p rogramming activi ty. M o s t o f the subjects stated that the predictabil i ty o f the model was important to them; for instance, they knew that c l i c k i n g on a method in the editor w o u l d make it appear in the filtered Out l ine v i ew . The key shortcoming reported was the inabi l i ty o f the model to understand task swi tching. For example, the subjects compla ined that to start on a new bug report they w o u l d have to clear the model , even though that model may be needed again. T w o subjects asked for a \"silent ac t iv i ty\" mode in w h i c h usage w o u l d not be recorded when the current task diverged momentar i ly . They wanted M y l a r to better support debugging act ivi ty , w h i c h overpopulated the model (e.g., s ingle-stepping caused too many irrelevant elements to become interesting). Overpopula t ion was also reported when code not relevant to the current task was accidentally explored; the U I for manual ly reducing interest was not intuitive enough for some o f the programmers. F r o m our o w n early use, we knew that the stability o f the D O I function could be a problem, causing the D O I o f interesting elements to fal l too qu ick ly . A s a result, we decided on an over ly conservative tuning that lead to the overpopulat ion. 6 3 4.2.6.Results: View Feedback A l t h o u g h a l l o f the subjects l iked the task context model that the task-focused U I v iews exposed, there was a mixed response to the h ighl ight ing scheme: three programmers l iked it, one felt neutral, and two programmers found it v i sua l ly loud and d i s l iked the intensity o f the color added to the v iews . Fo r the purpose o f consistency, the programmers cou ld change neither the co lor used in the h ighl ight ing nor the text annotations on the elements. The M y l a r Package Exp lo re r v i e w was l iked the most. Subjects found the automatic f i l ter ing and auto-expansion mode i n the Package Exp lo re r useful because it drastically reduced the amount o f sc ro l l ing and inspection they needed to do. Some l iked the auto-expansion idea but found that the U I interaction differed too much from a typica l tree v iew. A s one example, users cou ld not collapse nodes containing chi ldren o f high interest since the collapse function was not mapped to an interest operation on the model . Contrary to our intuit ion, most o f the programmers were not interested in seeing the annotation o f how many elements were filtered, and explained that they were used to elements miss ing from the Package Exp lo re r since they regularly used structure-based fi l tering mechanisms. The M y l a r Problems L i s t was also l iked , w h i c h was surprising because in the baseline study only five Problems Lis t selections were made over a l l o f the programmers. The subjects reported that the interest h ighl ight ing helped wi th the overpopulat ion o f the list and some asked for interest-based sorting o f that list. The persistence o f the model was l iked by a l l the subjects because when they restarted Ec l ip se after a long break, the last w o r k i n g context was retained. The most commonly asked for feature was a M y l a r version o f the Type Hierarchy v i e w and the Content Ass is t popup v i ew . A l l o f the programmers expressed interest in using future releases o f M y l a r 5 6 . 4.2.7.Threats One key threat to the results o f this study is the short amount o f t ime that the programmers used the tool . Fo r example, a subject may have worked on only one particular task for the duration o f the week, such as testing a feature. In such a case, we w o u l d not have observed a sufficient amount o f that programmer 's act ivi ty to determine the effect on the programmer 's productivi ty. T o mitigate this risk, we asked the programmers about the kinds o f tasks on w h i c h they worked each day and found that most worked on Since we wanted to focus development effort on incorporating study results and not on supporting the My lar 0.1 release, we asked the subjects to uninstall the tool at the end o f the week. The fol lowing week we were forwarded an email stating that one o f the programmers found the tool too useful to uninstall and continued to use it. 6 4 various tasks. A related threat is that, for the period of one week, the programmers were willing to try the tool and have their behavior affected by using this new tool in a way that is not representative of their normal work practice. We could not address this threat in this preliminary study but addressed it in our second field study by using a study period that was several times longer. Finally, the number of subjects was too small to gather enough data for a statistically significant test of the edit ratio change. We also addressed this threat in our follow-up study by using many more subjects. 4.3 Study II: Programmer Field Study Our initial study exposed a single primitive DOI weighting across all of a programmer's work. From this experiment, we learned that programmers need separate contexts for the different tasks on which they work and that a simple weighting of the frequency of element selection is not sufficient. Although the first study suggested our basic approach had potential, we learned it was not ready for daily use and lacked specific evidence that it improved programmer productivity. To answer the question of whether an explicit task context improves programmer productivity, we conducted a much larger field study. Again, we chose a field study because the time-constrained tasks performed on medium-sized systems possible in a laboratory setting are not representative of the real long-term tasks performed on large systems in industry. 4.3.1.Subjects The target subjects for our study were industry Java programmers who used the Eclipse IDE. To solicit participation, we demonstrated the Mylar 0.2 tool at an industry conference (EclipseCon, March 2005) and advertised on a web page. Early access to Mylar was only possible by signing up for our study through a web form. Ninety-nine individuals signed up for the study over the eight months between the announcement and the conclusion of the study. As visible in Table 4.2, the majority of these individuals were industry programmers, about half of them worked in organizations with more than fifty people and most identified their industry sector as software manufacturing [52]. Table 4.2: Demographics of the ninety-nine participants •• : / ' - V - V JO!) • % Application developer 65 One individual 19 Academic 13 65 Application architect 12 Manager/CIO/CTO 4 Other 6 ' . . ; Organization Si/e Fewer than 50 employees 32 50 to 500 employees 26 More than 500 employees 23 Sector : Software manufacturing 48 Academic 19 Financial/retail 13 Communications/networking 7 Government 5 Other 8 To study whether and how Mylar affects programmer productivity, we needed to be able to compare activity during a subject's baseline period, in which they used Eclipse in their normal configuration, with their treatment period in which Mylar was also installed into their Eclipse; For instance, if a subject was mostly coding during the baseline period and mostly testing during the treatment period, the activity in the two periods would not be comparable. Since we were interested in comparing activity as a participant worked on multiple tasks, we also needed to ensure that both periods were long enough to encompass typical tasks. Based on these goals, we defined criteria for a participant to be included in our analysis. The first was to ensure an appropriate amount of programming by setting thresholds on the amount of editing; only after a participant had reached a certain number of edit events was he moved to the treatment period. The second was to ensure that the effects of learning to use Mylar did not overly bias the usage data. To meet these criteria, our threshold of acceptance of a participant was triple the number of events (i.e., 3000 events) 66 needed to move from the baseline to treatment periods (i.e., 1000 events 5 7). A s the A c t i v e Search and A c t i v e Hierarchy features required the use o f addit ional v iews , we d id not a l l ow subjects to install this feature until they had crossed the 1500 event threshold in the treatment period, in order to avo id creating too steep o f an ini t ia l learning curve. Subjects thus progressed through the study as fo l lows. F o r the first 1000 events, participants were monitored only. Af te r they crossed this ini t ial threshold, they were g iven an opt ion to download the tool . Af te r they downloaded the tool and used it for another 1500 events, they were g iven the option to install the additional v iews . Af te r that, i f they accumulated 1500 or more events, their data was accepted for analysis. W e refer to individuals accepted for analysis as subjects, and use the term participants for the entire set o f individuals who registered. W e standardized on the number o f events rather than the t ime spent programming to account for variations in the rate at w h i c h different programmers work . O f the ninety-nine ini t ia l participants, sixteen met the cri teria to be considered subjects. Th i s one-in-six ratio is indicative o f the challenge we had in recruit ing subjects: industry developers typ ica l ly have little t ime to try out new tools unless they perceive an immediate and concrete benefit. The m i n i m u m two-week delay in getting the M y l a r U I was one contribution to the drop-off, as was the need to use M y l a r and continue participating in the study for several weeks to reach the 3000 edit event acceptance criteria. Participant feedback indicated that those w h o dropped out d id not program as much during this period, d id not use B u g z i l l a (the only task repository M y l a r 0.3 supported), or stopped using the tool after they encountered a bug or incompat ibi l i ty wi th another Ec l ipse p lug- in they were using. 4.3.2. Method and Study Framework W e designed our field study to measure the effects o f our tool w i th in subjects. Participants j o i n i n g our study were asked to install a subset o f the tool , cal led the M y l a r M o n i t o r , w h i c h captured and stored their interaction history without affecting how they normal ly work wi th Ec l ipse . The monitor was extended wi th a module that w o u l d per iodica l ly prompt the participant to upload their interaction history as an X M L file to a server at U B C , a long wi th exception logs and feedback. T o ensure anonymity, each participant was assigned a unique identifier. T o ensure pr ivacy , any part o f the interaction history referring to the elements in the system on w h i c h the participant worked , such as Java type names, was obfuscated using a one-way hash function. W e refer to this period o f a participant 's involvement in the study as their baseline period. Af te r the participant reached a certain threshold o f work , w h i c h we chose to be 1000 edit events over no less than two weeks, the participant was prompted as to whether they wanted to install the M y l a r task 1000 edit events corresponded to approximately 1-3 weeks o f full-time programming based on trials o f individuals in our lab. 6 7 context and task task-focused U I features. Install ing these moved a participant into the treatment phase o f the study. A s before, the M y l a r M o n i t o r w o u l d continue to prompt the participant to upload their interaction history to a server at U B C . A participant was also notified when there were updates available for M y l a r , inc lud ing both feature additions and bug fixes. W e ran the study for four months, July 6 to October 28, 2005 using M y l a r 0.3. The task context model , scal ing factors, and U I thresholds were frozen for the duration o f the study (and for subsequent releases up to the latest M y l a r 1.0). T o analyze participants' interaction histories, we created a reporting framework that a l lowed us to play back interaction to reproduce usage patterns and gather statistics. W e used this framework to analyze the effect o f M y l a r on what programmers d id and how they d id it. W e discuss the tuning o f the scal ing factors and thresholds for the study in Sect ion 5.1.4. 4.3.3.Results: Analysis and Edit Ratio O u r focus for this f ie ld \"study was to measure the effect o f task context on programmer product ivi ty . W e approximate product ivi ty by compar ing the amount o f code edi t ing that programmers do wi th the amount o f b rowsing , navigating, and searching. T o capture this behavior, we refined the edit ratio metric from the pre l iminary study to use an abstract notion o f edits instead o f keystrokes, but kept the same equation (i.e., Uedits I ^selections). The abstract edits corresponded to a sequence o f characters before a pause in a text editor (e.g., a w o r d written), and to manipulat ions in a graphical editor, such as changing a table value in the visual representation o f Ec l ipse ' s p lug- in editor, wh ich results in an automated textual change o f the under ly ing fi le. Ed i t ratio treats interaction consistently across different kinds o f artifacts, whether the artifact is source code, another k i n d o f f i le , or a binary l ibrary. Ed i t ratio also a l lows us to measure p rogramming behavior independently o f the task management features that M y l a r provides since only interaction wi th program structure affects the ratio. Th i s is important because edit ratio assumes that on ly edits o f the system resources contribute to our productivi ty metric and not edits o f tasks (e.g., comments on bug reports). Fo r this study, we ignored interaction events that resulted from edi t ing and selecting the tasks themselves since our goal was to validate how w e l l task context represents the artifacts relevant to the task. The next study reports on interaction wi th tasks (Section 4.4). Table 4.3 shows the edit ratios for each o f the subject's baseline and treatment periods and highlights percentage change in the ratio. T o determine whether there was statistical significance in the changes o f edit ratios we normal ized the edit ratios across subjects by taking the log o f each and performed a paired t-test. The result is statistically significant w i t h p = 0.003, indicat ing that the use o f our M y l a r tool improves edit ratio. G i v e n that our choice o f acceptance cri teria for a participant to be considered a subject in the study was pre-defined and somewhat arbitrary, we also wanted to see i f there was stability in this result for different acceptance criteria. W e thus analyzed the edit ratios o f programmers wi th a range o f both lower and higher thresholds o f baseline/treatment edit event cut-offs. Statistical significance 68 of the t-test (p < 0.05) holds until lowering the threshold results in inclusion of subjects whose usage data indicates that they did not use Mylar for their daily work (i.e., they are far below our acceptance criteria), and until raising the threshold is increased to the point where only six of the sixteen subjects remain. Table 4.3: Field study data and percentage improvement edit ratio filtered selections activity id baseline treatment delta explorer outline problems hours tasks 3 2.9 7.8 172.0% 25% 7% 0% 91.3 61 8 10.1 26.4 161.4% 16% 0% 0% 71.3 30 6 14.1 36.0 155.8% 0% 0% 41% 64.7 23 7 2.6 5.4 111.3% 18% 5% 3% 44.4 54 12 2.7 5.4 102.3% 3% 0% 0% 24.4 5 15 1.7 3.3 91.7% 0% 0% 0% 25.3 3 16 8.8 13.0 47.7% 30% 14% 0% 35.1 7 10 5.8 8.2 42.1% 32% 22% 40% 11.3 6 2 11.3 14.8 30.8% 8% 1% 0% 27.5 11 9 6.7 8.7 30.7% 27% 0% 0% 43.4 12 13 6.8 7.4 9.7% 14% 3% 0% 48.5 4 5 4.1 4.3 5.4% 2% 3% 0% 6.5 12 11 2.2 2.2 3.5% 6% 0% 6% 12.4 7 1 7.7 6.9 -10.2% 25% 5% 0% 62.5 52 14 15.9 13.5 -14.7% 0% 0% 0% 66.2 9 4 11.0 8.1 -26.6% 0% 0% 0% 17.1 1 4.3.4.Results: Qualitative analysis Our main hypothesis is that task context improves programmer productivity by making it easier for programmers to find the information that they need to complete a task, whether that is done by focusing a view in the user interface or by running only the tests relevant to changes made during the task. The edit 69 ratio analysis described in the previous section provides evidence that, for at least one measure, task context improves programmer product ivi ty . In this section, we further analyze the content o f the task contexts created by the programmers to determine whether the contexts were capturing the appropriate information. W e consider the f o l l o w i n g questions: H o w accurately d id the model capture the context o f programmers ' tasks? D i d the programmers create and perform mult iple tasks to w h i c h they returned? H o w much and in w h i c h v iews was fdtering used? Accuracy Across the sixteen subjects, we observed three notable trends i n the selection o f elements: 84 .2% o f the selection events were o f elements in the model wi th a positive D O I (i.e., the elements were v is ib le in a filtered v i ew) ; 5.3% o f the selections were o f elements that had only a propagated or predicted interest (i.e., not previously selected or edited, but v is ib le in either a fdtered v i ew , A c t i v e Search, or A c t i v e Hiera rchy) ; and 2 . 1 % o f the selections were o f elements wi th a negative D O I (i.e., the elements had decayed out o f v i s ib i l i t y in a filtered v i ew) . The first trend is indicative that programmers w o r k on only a subset o f the system artifacts and provides evidence to conf i rm that a task context does capture the majority o f the elements often used as part o f a task. The number o f propagated and predicted element selections is s l ight ly lower than expected due to our decis ion to not a l l ow subjects to install the A c t i v e Search v i e w until they had used M y l a r for ha l f o f the treatment period 's threshold, specif ical ly 1500 events. W e delayed the introduction o f this v i e w to avoid an overly steep ini t ia l learning curve. Once it was introduced, A c t i v e Search was not used as much as the other facili t ies and was used repeatedly by only five users. Quali tat ive feedback indicated several reasons for lack o f use: performance problems, not hav ing screen real estate available for another new v i e w , and the v i e w reporting too many matches 5 8 . The number o f decayed selections indicates that the decay scal ing factor may have been set too high. In contrast, usage data o f the \" M a k e Less Interesting\" action indicates that at times too many elements were being shown, since two o f the more active users frequently used this action (225 times for subject 3, 210 for subject 7, none for al l others). This tension between data indicat ing that in some cases too much was shown, and in others too little, highlights the diff icul ty o f p rov id ing one set o f scal ing factors for a l l tasks and a l l users (see Sect ion 6.2.1). The degree-of-separation value needed to be decreased manually as the number o f interesting elements within the default degree-of-separation (interesting files) grew large. The number o f landmarks growing too large was not a problem because the landmark threshold was tuned so that no matter how long-running a task was there would not be a large number o f landmarks. 70 Task Activity W e designed our study around measuring the effects o f task contexts, and unfortunately d id not include sufficiently r ich moni tor ing o f the meta-context to determine when the subjects recalled a specific previously worked-on task. However , we do k n o w from the task act ivi ty how often subjects switched tasks (Table 4.3). A l t h o u g h M y l a r is designed around facil i tat ing work w i t h mult iple tasks, it can be used wi th one active, often long-running task (i.e., subject four, whose usage data indicates he or she worked wi th the same task active across eight Ec l ip se sessions). W e are encouraged by the fact that most subjects used the task swi tch ing facili t ies regularly and those wi th the largest improvement in edit ratio used them heavi ly . The hours co lumn in Table 4.3 is an indicat ion o f the total t ime a subject worked wi th some task active, approximated by issuing a timeout event when no interaction events had been observed for three minutes. View Filtering Usage Whenever a task was active in the treatment period, a task context was being formed and the U I o f the I D E w o u l d show w h i c h elements were interesting through interest decoration. T o inform and guide the effectiveness o f U I mechanisms by w h i c h we project the interest model onto the I D E , we also analyzed usage trends related to the v i e w fi l tering and predicted interest facil i t ies. The percentages o f selections made wi th the v i e w in filtered mode are vis ible in Table 4.3 (for Package Explorer , Out l ine , and Problems v iews) ; the relat ively frequent use o f filtered selections is encouraging. Unfi l tered selections result from either no task being active or the task being active but the v i e w being in unfiltered mode. W h e n a v i e w is in unfiltered mode, many more selections are typ ica l ly required to f ind the same information than when filtered; this causes the percentage o f selections in filtered mode to appear lower than a subject might actually perceive. 4.3.5.Threats O n e threat to the accuracy o f the study results is that the subjects are not representative o f typica l industry programmers. The incentive to participate in the study was ga in ing access to a preview release o f M y l a r , and as such, this selection process was l i ke ly biased to early adopters o f new programming technologies. Our study results must be v iewed in terms o f this potential weakness. Ano the r threat is that we had no control over the tasks performed by subjects between baseline and treatment periods so their activity may have varied wide ly . Th i s threat is addressed by the large amount o f both baseline and treatment interaction we had for each subject. I f programmers had worked on a single task across the baseline and treatment periods, changes in the edit ratio across the l i fecycle o f a single task could have been a problem. However , we have evidence that most subjects switched tasks' mult iple times dur ing a workday (on average 2.3 tasks switches per active hour). F i n a l l y , bugs in interaction history creation, parsing, and 71 analysis could skew results. Our bootstrapping, testing, and ongoing use o f the M y l a r M o n i t o r framework by ourselves and others is cont inuing to harden it against such errors. A n objective and generic measure o f industry programmers ' product ivi ty is diff icult as it depends on how a developer works (i.e., their process), what they work on (i.e., their domain) and how quali ty is measured in that domain . A l t h o u g h a definit ive measure o f product ivi ty is elusive, edit ratio provides us wi th a measure o f effort spent wr i t ing code versus effort spent l o o k i n g for the information needed to write code. Since programmers chose to use the tool voluntar i ly , their choice to continue using it is also a posit ive indicator that the edit ratio metric approximates programmer product ivi ty . 4.4 Study III: Knowledge Worker Field Study T o test whether the task context model supports more generic knowledge work , we adopted the same user-monitoring framework used for the programmer study. In particular, we wanted to investigate whether the model could accurately reflect the information needed to complete a task when the interaction was occurr ing wi th less structured information than in the programming domain . The goal o f this study was not to determine whether task contexts make knowledge workers more productive, since the product ivi ty o f generic knowledge workers cannot be as easily approximated as that o f programmers, whose productivi ty is typ ica l ly defined by how much code they produce (Sect ion 4.2.4). Instead, our goal was to gather usage data on how knowledge workers use task context. W e also wanted to learn whether or not knowledge workers w o u l d exp l ic i t ly mark their task boundaries voluntar i ly us ing the task management facil i t ies, how accurately task context represented the file and web documents wi th w h i c h they work , and how necessary the support for decaying uninteresting items is for supporting file and web b rows ing activities. W e refer to the configuration o f M y l a r used for this part o f the study as the M y l a r B rowse r (Section 3.3). Rather than performing ad-hoc tuning o f the task context model for knowledge work , we wanted to gather usage data to test how w e l l this model worked for less well-structured data. F o r this reason, we left the sca l ing factors and al l other implementat ion aspects o f task context identical to those offered in the programmer study. The only substantial addit ion to the implementat ion o f the tool is that it provided an addit ional structure bridge to support interaction wi th web documents. W e also removed al l o f the programmer-specif ic features from the tool (e.g., Java development tools, M y l a r Java Structure and U I bridges). 72 4.4.1.Subjects The participants that we targeted for this study were knowledge workers within and related to our university that were not programming as part of their work activities. We advertised the study to approximately two dozen individuals who had heard of the programming tool. In all, eight individuals installed Mylar Browser, used it, and responded to our follow-ups for gathering usage data and feedback. The job descriptions, activities, and desktop applications other than the common ones listed below are summarized in Table 4.4. Table 4.4: Accepted subjects in knowledge worker study Job Description Activities Desktop Apps WebApps 5 9 SI Technology transfer officer Technology assessment, literature reviews, patent search, market analysis patent search patent search, marketing search S2 M.Sc. student in Biology Literature/database search, grant proposals gene search gene search, spreadsheet S3 Secondary School Teacher Lesson planning, Financial planning finance finance management S4 Instructor Teaching, managing administrative assistants n/a calendaring S5 C E O Manage operations of small company n/a contact management S6 Project coordinator Project management, hiring, reporting web authoring finance, student management S7 Student services coordinator Coordinating undergrad programs, student advising n/a student management S8 Communications coordinator Organize publicity and publish documents graphic design, web authoring n/a Most of the individuals used the Firefox/Mozilla web browsers. Some used Mozilla and Thunderbird 6 0 for email, others used Microsoft Outlook 6 1. A l l used Microsoft Office 2003 with the exception of S3 who A l l reported using Google as the primary search engine, http://google.com [verified 2006-12-21] http:// mozilla.com/thunderbird [verified 2006-10-02] 73 used the Mic roso f t Off ice 2007 beta. The c o m m o n l y used Mic roso f t Off ice applications were, in order, W o r d , E x c e l , and PowerPoint . 4.4.2. Method and Study Framework Participants were asked to use the tool as they saw fit for their dai ly work . E a c h was g iven a thirty-minute tutorial on how to use the tool by one o f the researchers. Questions that arose about the usage o f the tool dur ing the study were answered by emai l and in person. Participants were provided bug f ix updates o f the tool . S ince participants j o ined the study over a period o f s ix weeks, the per iod over w h i c h we col lected data for each participant var ied. Subjects S2 , S4, and S5 signed up in the last two weeks o f the study. M u l t i p l e subjects had vacat ion days over the study period, or were out o f the office, so we report days act ively us ing the M y l a r Browser in Table 4.5. O v e r the study period, we col lected subjects' usage data. A t the end o f the study, we conducted exit interviews. 4.4.3. Results: Task Activity The active workdays in Table 4.5 indicate the number o f days in w h i c h subjects activated tasks. Subjects sometimes worked on tasks without act ivat ing them, for instance, i f the task represented a work item that d id not correspond to files or web pages. The broad spectrum in the number o f active workdays is in part due to some subjects s ign ing up at the tai l end o f the study period (S2, S4, and S5), and, in one case, due to a lack o f use o f the tool (S7). A l t h o u g h there is a broad spectrum in how many workdays subjects activated tasks, the table indicates that subjects w i l l voluntar i ly indicate w h i c h tasks they are w o r k i n g on when us ing M y l a r Browser . W e believe this occurs because the automatic creation o f task context supported by the M y l a r Browser provides users wi th an incentive to activate tasks. The tasks/day co lumn indicates how many unique tasks were activated that day. The activations/day co lumn is higher in a l l but the S7 case, indicat ing that most subjects returned to tasks on w h i c h they had worked earlier that day. Th i s indicates that subjects used task contexts for the purpose o f restoring context when mult i tasking. 6 1 http://microsoft.com/outlook [verified 2006-10-02] 74 Table 4.5: Task context activation Active Workdays Total tasks activated Tasks/day Activations/day SI 25 26 5.0 7.0 S2 5 5 2.8 9.0 S3 8 22 5.6 11.0 S4 4 9 2.75 3.8 S5 4 5 2.5 6.8 S6 26 41 1.8 2.2 S7 1 1 1 1 S8 14 29 3.4 3.8 Mylar's task management facilities do not impose any process for how tasks are defined. For this study, we also did not provide subjects with guidelines on how tasks should be defined. Al l subjects used personal tasks, not shared tasks (Section 3.2.3). Table 4.6 reports the kinds of work items that subjects managed with Mylar's tasks and the items for which they did not choose to use Mylar Browser. Table 4.6: Work items reported by subjects to be associated with tasks Used Mylar for Did not use for SI most work items very short tasks, phone calls, meetings S2 scholarship applications literature/database search S3 some work items, web research working in quicken, phone calls S4 most work items, personal tasks quick email messages, new documents first without task then made them S5 some work items, personal tasks tasks defined in email S6 most work items task defined in email, meetings S7 one work item paper tasks, web application forms S8 some work items desktop publishing, web authoring 75 4.4.4.Results: Task Context and File Structure T o determine how the information v is ib le in the task context corresponded to the under ly ing information that knowledge workers access, we devised several methods o f measuring the contents o f the subjects' task contexts. O u r goal was to understand how effective our approach was at gathering and showing the relevant information compared to other c o m m o n methods o f organiz ing information, such as hierarchical f i l i n g or the use o f consistent naming or tagging approaches to facilitate query-based retrieval. I f workers were already organiz ing their information in a way to make relevant information to a task easy to f ind wi th exis t ing mechanisms, we also wanted to k n o w how much irrelevant information the Resources v i ew , w h i c h showed files and web documents relevant to the task, was h id ing wi th its interest f i l tering faci l i ty . Th i s f i l tering faci l i ty was a lways on 'by default. The methods presented in this section consider on ly files. For web documents, since the amount o f information available onl ine dwarfs what a subject accesses in a typica l task, the majority o f available information is always hidden. The degree to wh ich M y l a r B rowse r helps f ind and filter files depends on the size and structure o f the fi le systems being used. Four subjects ( S I , S4, S6 and S8) accessed shared document repositories that contained at least tens o f thousands o f files. Three subjects (S2, S3 , and S5) accessed local folders that contained at least hundreds o f files. Subject S7 d id not use the fi le b rows ing feature. The mechanism by w h i c h we measured these metrics differed from al l the other quantitative measurements we made because they required measuring the subjects' file systems and the M y l a r M o n i t o r preserves file system pr ivacy. A s a result, we performed the measurement on a l imited sample due to subjects' t ime constraints. W e did not take any measurements for subject S5 because that subject's file system was not available to us. Fo r measurement, we chose the last two tasks that the subject had activated and that contained files in the context. W e defined four metrics to determine the relationship between the subset o f the information in the task context and the information that w o u l d normal ly be shown through structure-centric v iews , such as through a tree v i e w o f directory structure or as the results o f a query over a l l files tagged v i a naming conventions. 1) Average path length. Th i s metric captures the average path length o f a l l interesting files (i.e., files in the context wi th a posi t ive D O I ) to the root folder. The higher the number o f nested folders that are used to file relevant information to the task, the higher the value o f the hierarchy metric. The higher the value o f this metric, the more folders the user w o u l d need to c l i c k and open in order to get to the file(s) o f interest when resuming a task, unless they manual ly created and managed expl ic i t l inks to folders, as subjects S I and S5 had done prior to using M y l a r Browser . 2) Average directory density. Th i s metric captures the average ratio o f interesting files in every directory wi th in the context to a l l other files w i th in that directory. The lower this number, the 76 more irrelevant information being hidden by the task context. For example, S6 frequently used shared directories that contained hundreds of Microsoft Office documents. However, S6 typically required only a few of those documents for her tasks. 3) Scattering62. This metric captures the average distance of an interesting file to a common parent directory. The higher the value of the scattering metric, the larger the number of places in the hierarchy that contain files of interest. For example, if the subject were.working on a file a/b/c/foo.doc, and a second file in a/d/bar.doc, the scattering measurement would be (3+2)/2) = 2.5. A scattering of 0 means all files were in the same directory. 4) Tagging ratio. This metric captures a ratio of the number of interesting files that share a common tag in the name of the file to the number of all interesting files in a context. For example, \"Casel\" might be the tag used in two files, such as \"Casel-Intro.doc\" and \"Casel-Data.xls\". Table 4.7: Task context content structure measurements Avg . path length Avg. directory density Scattering Tagging ratio SI 5.5 0.1 1.5 0.3 S2 2.7 0.2 1.1 0.9 S3 3 0.1 1.4 0.4 S4 2 0.3 0 0 S5 n/a n/a n/a n/a S6 1 0.01 1 0.4 S7 n/a n/a n/a n/a S8 n/a n/a n/a n/a As discussed above, the subjects with \"n/a\" values did not use the file browsing feature sufficiently to produce data for the tasks we sampled or we were unable to measure the contents of their file systems. For the other subjects, Table 4.7 indicates that the path metric was highest for SI, who worked on the largest network file system shared across dozens of employees, whereas the others had relatively short We use the term \"scattering\" from A O P , where it connotes the amount o f structure not cleanly modularized within the dominant decomposition. In the case o f a file system, the dominate decomposition is the directory structure. 77 paths to interesting f i les 6 3 . S I used the richest hierarchical structure and tended to organize a l l files a long wi th tasks. Since the subjects were able to map any file system folder into the M y l a r B rowse r and since we performed the measurements w i th in the M y l a r Browser , i n each case the path length is shorter than it w o u l d have been i f accessed direct ly v i a the W i n d o w s file system. For example, S6 mapped only the few parts o f the shared network drive that contained documents relevant to her into the M y l a r Browser , using this as a shortcut to avo id needing to browse through additional path segments (e.g., omit t ing the first drive letter and two directories i n \"Z : \\Document s \\P lann ing \\New Project\" and mapping \" N e w Project\" direct ly into M y l a r Browser) . A l l o f the subjects' task contexts exhibi ted a low density over the file system structure. The low density measurement demonstrates a key benefit o f task context; the vast majority o f files w i th in a directory were uninteresting and the task-focused U I showed only the few interesting ones. Scattering was present in every case other than S6, who mapped the parts o f the file system containing her files, result ing in a flat structure wi th hundreds o f files in each directory (with only a 0.01 density). Tagg ing was done by S I , S2, S3 , and S4. The ratio o f tagged files was 4 0 % or less, indicat ing that tagging was not a reliable way to identify a l l files relevant to a task. 4.4.5.Results: Task Context Contents In addi t ion to gathering data about the relation o f the context to the structure, we also wanted to understand what was contained in the task contexts. Table 4.8 summarizes the task context contents. This data includes a l l files wi th w h i c h interaction occurred, even i f the file had decayed out o f the Resources v i ew . The unit o f measurement for the two size columns are elements; for example, on average S i ' s contexts referred to 69 web pages The total number o f tasks for each subject is lower than that the total listed i n Table 4.5 because subjects per iodical ly created tasks that had neither a web or file context. For instance, some created a task for the purpose o f an appointment and used the personal note feature o f tasks (Sect ion 3.2.3) to capture information relevant to the appointment. Th i s data indicates that both web and file contexts had a non-tr ivial size. Some task contexts accumulated many documents, as in the case o f S I , w h o for long-running tasks accumulated 239 files in one context and 317 web pages in another. It also indicates that subjects used task context for w o r k i n g wi th files and for browsing , sometimes simultaneously. S i x out o f the eight subjects worked wi th task contexts that had both web and file elements, and for S I and S5 most task contexts had both a web and file elements. Th i s S1 had been creating shortcuts to each directory he worked with frequently on his desktop in order to avoid having to browse to the directories o f interest each time. SI had dozens o f such shortcuts on his Windows desktop. 78 indicates that task context model ' s abi l i ty to uni formly represent interaction w i t h various kinds o f artifacts is useful, since many tasks invo lved both file and web resources. Table 4.8: Task context content size measurements Web contexts File contexts Tasks with both Tasks Avg. size Max size Tasks Avg. size Max size SI 7 69.1 239 16 42.7 317 6 S2 4 5.3 8 5 4.0 14 2 S3 9 17.8 96 2 3.0 4 1 S4 2 3.0 4 1 3.0 3 0 S5 5 32.2 125 4 68.8 225 4 S6 5 5.2 12 2 2.0 2 1 S7 1 5.0 5 0 0 0 0 S8 9 4.9 13 3 4.7 9 2 4.4.6.Results: Task Context Model Accuracy T o determine how accurately the task context model represented what users were interested in , we gathered data on the landmark, interesting, and decayed elements w i th in the model , consider ing work done across al l tasks (Table 4.9). This data indicates that in most cases more web pages and files were being filtered from the U I than were v is ib le . Th i s leads us to assume that the task context 's abil i ty to decay low D O I elements out o f v i e w is key to accurately representing the elements relevant to the task. Since some subjects had very long-running tasks (e.g., S I ) , our D O I ranking can change substantially over the course o f the task. I f not for the frequency and recency based D O I , the Resources v i e w w o u l d l i ke ly have been so populated wi th elements that it w o u l d have not provided the task-focused U I benefits o f being able to select an element o f interest without sc ro l l ing or expanding a tree structure to f ind it. C o u p l e d wi th the general feedback that the task context represented what subjects worked on (Section 4.4.7), we conclude that capturing an interaction-based weight ing, and only showing the most relevant elements based on that weight ing, provides an automated mechanism for focusing knowledge workers on their task and for faci l i tat ing mult i - tasking. 79 Table 4.9: Proportions of task context model slices (direct interest only) Web (%) Files (%) Landmark Interesting Decayed Landmark Interesting Decayed SI 1 10 89 3 8 89 S2 0 73 27 5 50 45 S3 1 30 69 45 55 0 S4 0 100 0 0 75 25 S5 2 13 85 2 19 79 S6 4 96 0 0 1 0 S7 20 60 20 0 0 0 S8 3 52 48 3 34 63 4.4.7.Results: Feedback With both a large amount of interaction recorded and a high occurrence of decay, the question that remained was how accurately the visible elements represented what was relevant to the subjects' tasks. To judge this aspect, we asked each of the subjects about the accuracy of the task context model that was presented in the Resources view. Table 4.10 summarizes their assessments. Table 4.10: Feedback on how much information relevant to the task was displayed Too much Too little About right Comments SI X Some web documents disappear from context too quickly after reactivating context S2 X Page redirects sometimes pollute the web context S3 X Initial navigation puts too much uninteresting information in the context S4 X Sometimes too much was shown initially in web context S5 X X Sometimes too much shown initially, not always a reflection of how time is spent 80 S6 X Since it is not the default browser some relevant web context miss ing S7 X D i d not use enough S8 X Init ial ly web context tracks too many wrong site visi ts A l l o f the subjects were very posit ive about the idea o f context being tracked automatically as they worked , expressing that the task context represented what they worked on and that they l iked seeing only the files and web pages relevant to their task. However , when asked how accurately the task context model portrayed the files and web pages i n w h i c h they were interested, almost a l l recalled cases where either too many or too few elements were filtered away. C o m m o n feedback indicated that web contexts often get overpopulated at the beginning o f a task when nothing has decayed but many l inks have been c l i cked in search o f something, especially when performing a web search. Some reported that, in many cases, only the last pages browsed were h ighly relevant. A l s o , some subjects reported that interaction wi th web documents could cause files to prematurely disappear from the context. F i n a l l y , we asked subjects whether they l iked us ing the tool and asked i f they w o u l d continue using M y l a r Browser . W e are encouraged that a l l stated they w o u l d continue using it (Table 4.11). Table 4 . 1 1 : General feedback Like Dislike Did not use enough Will continue using SI X X S2 X X S3 X X S4 X X S5 X X S6 X X S7 X X S8 X X W e conclude that task context can be integrated into knowledge work applications. If provided wi th the benefit o f the task context, knowledge workers w i l l voluntar i ly indicate on w h i c h task they are work ing . A l t h o u g h the tuning o f the scal ing factors and thresholds could have been more precise, feedback from 81 subjects indicated that integration with other applications (e.g., email, better Windows integration) was far more important to the subjects than task context model tuning improvements. Based on the low task activation usage and task context model contents of the S 7 subject, whose occupation involved the highest proportion of data entry, we hypothesize that the task context model may be more useful for knowledge workers needing to access a large amount of information than for those spending most of their workday in a single data entry application. In terms of task context model implementation, the key lesson we learned is that differences between structure bridge implementation and monitoring can have a major impact on how task contexts evolve when they contain aggregations of different kinds of resources. For example, when a context had a lot of web interaction, interesting files decay out of the context too quickly. This situation happened because the Mylar Browser monitored more interaction with web pages (every click) than with Microsoft Office documents. Extending monitoring facilities to include scrolling or time-based interaction events for semi-structured resources could improve the accuracy. However, we believe that the existing scenario, where different structure bridges provide different levels of structural awareness, will be common. We discuss approaches of addressing this issue, such as normalizing or scaling the relative amount of interaction, in Section 5.1.3. 4.4.8.Threats The number of subjects in our study was small, and these subjects may not be representative of any interesting class of knowledge workers. Given that the subjects fulfill a variety of roles, the results may generalize to an interesting population, although further study with a better sampling across a wider population is warranted. The generalizability of our results is also limited because the amount of data collected for four of the eight the subjects corresponded to one workweek or less. Another threat to our results is that the subjects may have only used the Mylar Browser for tasks well suited to the tool. We do not know what percentage of their daily tasks for which they used the tool. The heavy use of the tool by some participants suggests that it does fit some work patterns; for example, one participant (SI) even stopped using M S Outlook task management in favor of the task-focused desktop. Future studies should consider which tasks our task context model supports and which it does not and why. 82 4.5 Summary Our user studies have validated that an explicit task context makes programmers more productive. We have shown with statistical significance that productivity, as defined by the amount of time spent navigating versus editing, increases for programmers when they work with explicit task contexts. We also demonstrated that task context generalizes to file and web browsing activities. As a result, we believe this is a promising technology for reducing information overload in the knowledge work domain. 83 5. Discussion In this chapter, we discuss potential improvements to the task context model to better support both programming and other kinds o f knowledge work. M a n y o f these potential improvements are based on experiences from the f ie ld studies and on the feedback from the user communi ty o f M y l a r I D E 6 4 . In this chapter, we review ways to improve the accuracy o f the task context model (Sect ion 5.1) and the task-focused U I (Section 5.2). W e then describe and discuss support in M y l a r I D E for task context col laborat ion (Sect ion 5.3). W e also present methods o f v i sua l i z ing task context (Sect ion 5.4) and conclude this chapter wi th a discussion o f future w o r k (Section 5.5). 5.1 Improving Task Support and Context Accuracy 5.1.1. Working on Multiple Tasks Concurrently Our prel iminary study data indicated that programmers needed support for w o r k i n g on mult iple tasks concurrently. W e interpreted this input as programmers needing to have mult iple tasks active and implemented support for mult iple active tasks in M y l a r 0.2-0.3. Th i s implementat ion distributed interaction events among al l active tasks. The fact that no M y l a r I D E users compla ined when we eventually removed this feature has indicated that our interpretation was wrong . A l t h o u g h our exis t ing user base needs support for w o r k i n g wi th many tasks concurrently, for the c o m m o n cases, they do not need support for w o r k i n g w i t h tasks in parallel . Use o f this feature also makes the interaction wi th task activation considerably more complex . A s a result, we removed the capabil i ty o f act ivat ing mult iple tasks in M y l a r 0.4, and instead we have focused on making swi tch ing between tasks easier. 5.1.2. Related Tasks Our model treats a task as an independent atomic unit. In practice, tasks are often related. Cons ider a programmer w o r k i n g on f ix ing a bug. The programmer creates and activates a task for the bug. A s w o r k progresses on the bug, the programmer identifies and begins work on a related bug before the first bug can be resolved. W i t h our current model , the programmer has two choices: deactivate the first task and In the 11 months since the conclusion o f the programmer field study (Section 4), My la r I D E users have filed 260 enhancement requests and 928 integration and bug reports: http:// eclipse.org/mylar/bugs.php [verified 2006-10-12] 84 recreate the context when starting work on the bug, or do both tasks under the context of the first. Both choices are problematic, and while the latter is easier, it causes a potential loss of context as the programmer cannot return to the context for just the second bug. We believe that addressing this problem will require extending the model to support schemas for tasks (e.g., subtasks, sequences) and allowing the programmer to have one or more related task contexts active by means of context composition. For example, if a user activates a task with three subtasks, each of the contexts of the subtasks could be activated simultaneously, so that the parent task includes all of the contexts of the subtasks. This technique would also support pre-populating the context of a new task, for example, with the composite context of a parent task. Pre-population is a commonly requested feature. This feature requires careful UI design to avoid the complexities that arose in our previous attempts to support multiple simultaneous active tasks. 5.1.3. Task Context Lifecycle Our task context model is oblivious to the lifecycle of a task. We use the same scaling factors and apply the same algorithms for operations whether a task is near its start and has a sparse context, or near its completion and has a rich context. Making the model sensitive to a task's lifecycle could further improve accuracy. For example, at the beginning of a task, it may be beneficial to have a slower rate of decay, and suggestions for related structure could come from a broader degree-of-separation when the task context is small. Near the end of a task, the core set of information in the context has stabilized and the context contains more information. The size of the task context could be used to adapt the DOI function, scaling factors and degrees of separation, helping tailor the contents of the model to the task's lifecycle. 5.1.4. Tuning the Scaling Factors A concern we had prior to starting the field study was that poorly tuned scaling factors could prevent the task context model from capturing the information programmers needed and that scaling factors might need to be personalized for different tasks types, programmers, and display resolutions. We decided not to expose a mechanism for a programmer to change the scaling factors because we believed that the problem of information overload was so severe for large system development that an approximate tuning would suffice. We chose an order of magnitude value for each scaling factor and used it in our daily programming with Mylar. This resulted in only slight variations within those orders of magnitude being set for the Mylar 0.3 field study release (Section3.1.3). We did not focus our validation on the settings or tunings of these parameters because they only play a minor role in the overall effect of adding task context into an application. For example, if we turned up the decay several times higher, task context would still help, but would show fewer of the relevant 85 elements. I f we turned it d o w n several times lower, the user w o u l d have to scro l l more but w o u l d st i l l see the information relevant to the task. A l t h o u g h we expected to change the sca l ing factors and thresholds based on feedback from the study participants, the values continue to w o r k and remain unchanged through to the 1.0 release. A s a result, we believe that a substantial improvement may require a more sophisticated tuning approach that adapts to properties such as the task's l i fecycle , the type o f task and programming domains, and the user's profi le. Further study is necessary to determine how vary ing and adapting scal ing factors affects the accuracy and precis ion o f the task context model . 5.2 Improving the Task-Focused UI 5.2.1. Decorating Elements to Indicate Interest Level A notable change we made between M y l a r 0.1 and 0.3 was to remove the forced highl ight ing scheme (Figure 4.2) as a default. In M y l a r 0.7, the h ighl ight ing was removed entirely from the M y l a r distr ibution. W e had in i t ia l ly thought that using a background color to indicate how interesting an element was w o u l d help dist inguish elements that were most interesting, or that were about to decay out o f the v i ew . W e supported both a discrete and a continuous h ighl ight ing scheme and a l lowed the assignment o f highlighters per-task. The user study data we col lected d id not show much use o f the h ighl ight ing scheme. Feedback from users also indicated that they found the highlighters to be v i sua l ly distracting. Since neither we, nor the user communi ty , expressed a need to be able to dis t inguish beyond the three levels o f interest (e.g., uninteresting, interesting, landmark), we removed this faci l i ty . One o f the reasons we thought that the foreground h ighl ight ing w o u l d be necessary was to a l l ow mult iple active tasks (Section 5.1.1) to be dist inguished v isua l ly . A l t h o u g h that support is gone from the programming parts o f the U I , the h ighl ight ing idea may be useful for support ing other activities that invo lve mult iple contexts being active, such as code reviews (e.g., inspect a l l contexts for a release) and context comparison (e.g., compare remote context wi th local workspace ' s context). 5.2.2. Exposing the Interest Thresholds A n alternate approach to creating smarter threshold levels and scal ing factors is to expose these to the user for manual tuning. W e prototyped this support in the U I and occasional ly st i l l use it for debugging purposes. W e have chosen not to expose it to avo id compl ica t ing the U I wi th manual tuning facil i t ies. W e believe that this approach could be useful in some situations, for instance when v i e w i n g large aggregations o f contexts (e.g., for code review). 86 A n example UI to allow direct manipulation of thresholds is shown in Figure 5 . 1 . This context slider enables the programmer to directly manipulate the thresholds for encoded interest visibility and predicted interest visibility. The former can control the interest filtering threshold for elements with a direct interest (e.g., allowing more task context to be shown on larger displays). The latter can be used to define how much predicted context is made visible to the user (e.g., more can be shown when exploring, less when working on a well-defined task). Sliding the left slider to the left will show more of the past interaction history, while sliding the right slider to the right will show more of the potential future interaction history. Sliding them both to the centre will result in only the current selections being visible. Two or more programmers often end up working on the same task. This kind of collaboration can occur in at least three different ways: programmers may huddle around the same computer, they may pass the task back and forth with one programmer making progress and then delegating it to another, or they may work on the task at different times and in different places, such as when one programmer revisits a task completed previously by a colleague. Mylar helps programmers in each of these scenarios. When multiple programmers work on a task simultaneously at one computer, the focus provided by the task context can make it easier for the programmers to discuss the software and for the non-driving programmers to follow the actions of the driving programmer on the screen. Mylar provides assistance for the other two scenarios by facilitating the sharing of task context. We have experimented with two means of sharing task context. Most commonly, we attach the context used in solving a bug to the task describing the bug in a shared task repository. Second, a context for a task can be passed through email. We use the former approach in the Mylar project, since we promote transparency in the development process by making our task contexts openly available. direct £ r ^e_nL . „ , predicted Figure 5 . 1 : Mockup of threshold control UI 5.3 Collaborating with Task Context 87 PI Task List U • ) Find: De 3 m S Oft a Q3s o f§ Commit Context. . . I Q_ Clear Context 43 Attach Context. . , M y I i j Retrieve Context 1 5 5 0 4 4 : s h o w c o m p l e t e d / a r c h i v e d t a s k i . ^ Task Repository Seat Peo| R e t r i e v e c o n t e x t Loads context from repository task into the workspace Task: 155135: add support for changing ticket status in Trac rich editor Repository: https: / /bugs. eclipse. org/bugs Select context below: Date Author Comment 2006-08-24 21:28 mik, kersten@eclipse. org mylar/context/zip 12006-08-24 20:30 steffenp@gmx.de mylar/context/zip i (?) Finish Cancel Figure 5.2: Context sharing initiated from the Task List A programmer who wishes to work on a task unfinished by another programmer or who wishes to see how a bug was resolved, can import the context for that task into his or her workspace (Figure 5.2). Just as one programmer can switch between tasks, a programmer importing a task context can switch to that context thereby accessing just that subset of the software system that the original programmer had considered in completing the task. When contexts for tasks are stored in a shared repository, such as the Bugzilla repository used for the Mylar development itself, the repository becomes a richer source of knowledge about how to complete problems. Currently, the Mylar source repository has contexts attached for 253 tasks (as of September 14, 2006). These shared contexts have made it much easier for Mylar's developers to work on reopened bug reports and to delegate partially completed tasks. The Mylar open source project also has a policy of requiring task contexts to be submitted as patches. This policy has made it easy to apply dozens of patches contributed each month. Mylar also helps focus communication between multiple programmers by providing an Eclipse-based user interface for working with repository tasks via the Mylar Task List. In particular, Mylar supports the use of queries to watch for changes in particular categories of tasks (Section 3.2.3). For example, a query may be added to watch all updates made to a task by a particular colleague. When the colleague adds a comment to a task, the programmer will see the task appear under the query in the Mylar Task List and 8 8 will see an incoming arrow to represent the changes that have been made. When the programmer opens the task, the editor for the task highlights the incoming changes and unfolds all new comments. Another way to add more collaborative support for working with task context is to provide recommendations. Mylar provides an experimental form of recommendation called Active Search, which for resources of landmark interest, automatically runs and displays reference-based searches. For example, the Active Search may display the callers of a particular method that have a high-degree of interest. By knowing the context of a task, when a programmer begins work on a new bug report, it is possible to similarly recommend previous bugs completed in the past and to provide rich support in suggesting which parts of the system may be relevant to solving the problem [51]. These recommendations provide focus when they are sufficiently accurate; inaccurate recommendations would reduce the focus of the programmer. At times, it would also be useful for programmers to know which parts of the system are being worked on in parallel by other team members. One way of presenting this information is through decorations to resources in the IDE [10]. This decoration can be overwhelming when applied to all resources in the system. By knowing the current task contexts of other programmers, it may be possible to scope the collaboration information presented to provide more focus. For example, Figure 5.3 is a mockup UI that could be used to show a programmer that the bug she is fixing is also active in a team members' task context (via the bug icon on the left of Figure 5.3). Clicking this icon would then bring up a dialog with the bug details that could show the overlap between the two programmers' task contexts. The presence of overlap could serve as a warning to prevent a conflict that could result from their simultaneous editing of the same code, or as a prompt to share expertise. 89 [i] *FigurePanel. java £3 • ; l i c f e t o add a p o i n t or l i n e ' class ButtonsPanel extends JPanel { private JLabel msgs = new JLabelf public ButtonsPanel () { setLayout(new FlowLayout(FlowLayout.LEFT)); add(new JRadioButton(new AbstractAct ion(\"HistoryUpdating\") addfnew JRadioButton(new AbstractAction(\"ColorHonitoring\") add (msgs) ; ^ b u g 4 3 6 5 : a d d history updating } public void log(S msgs.setText( } last comment fixed capture policy, and updated ButtonPanel to include new actions. Make sure to add the... < task context overlap - FigurePanel S afterReturning(FigureElement) $ moves(FigureElement) S & icons E & action £y history-action.gif F i g u r e 5 . 3 : M o c k u p o f o v e r l a y s h o w i n g o v e r l a p b e t w e e n t w o t e a m m e m b e r s ' c o n t e x t s 5.4 Visualizing Task Context Our implementation and validation focused on displaying task context within the existing display facilities offered by modern IDEs. For the field studies, we targeted a 1280x1024 screen resolution. Even at this resolution, we received feedback that programmers did not have enough screen estate to show a view such as the Active Hierarchy even if they found it useful65. In the knowledge worker study, the situation was worse because some subjects had 1024x768 screen resolutions and were accustomed to a full-screen browser. The My la r 0.7 documentation recommends not using Act ive Search or Act ive Hierarchy with screen resolutions lower than 1920x1200, a typical maximum resolution available on today's developer workstations. 90 However, larger screen resolutions are becoming more common. We have experimented with several graphical views of task context. We have found these visualizations of task context useful for our own internal experimentation. Our first attempt at depicting interaction history was called Pathfinder, which used a grid layout where interesting files were arranged horizontally according to the package in which they were contained. Rather than sorting files in descending interest, this view placed the most interesting files in the middle, and sorted less interesting files in descending order above and below those. The intent was to allow a ridge of the most interesting paths through the package navigation to form, as visible in Figure 5 .4 . In addition to the background highlighting, the border of the file node was decorated to indicate with decreasing luminosity the place that this file had in the interaction history in order to make it easier to know where the \"Back to previous file\" navigation would lead. The problem with this view was that when many files within a single package were selected it required either too much vertical space or forced scrolling. We discarded this visualization and instead tried to show the same structure using the existing Package Explorer view. From this start, we came up with the idea of filtering existing tree views to focus on the task context. \" ^Pa th f inder £ T \\ org. apache, wsif .providers..., org. apache, wsif .base org, apache, wsif org dp :; jJJ PrimitiveTypeForrnatH,.. y j WSIFServicelmpl.java (?) WSIFInterceptorConfi... Q J i . JMSFormatter.java 1 WSIFDefaultMessage... [ U_ WSIFService.java < J WSIFDynamicProvider... [7) WSIFServiceFactoryl . . . [ [J] WSIFRequest.java \"] ! • / * * • A \"^public class W S I F R e q u e s t implements S e r i a l i z a b l e { private s t a t i c f i n a l long s e r i a l V e r s i o n U I D = I L ; • / * * • = • public U S I F R e q u e s t (QNarne s e r v i c e l D ) {p • / * * • ^ public void s e t l n c o r n i n g M e s s a g e ( W S I F M e s s a g e i n c o r o i n c j M e t h i s . i n c o r n i n g M e s s a g e = i n c o r n i n g M e s s a g e ; > • w »„.,,..,„„....„....,.. . „.,„ . „.„„......,....,„ „.,, „ „ V l<] 1 [>] EwSIFReq... 2Z ^ S e r i a l i . . . PjWSIFPor... ! 2) WSIFOpe.. . ^4 • F i g u r e 5 .4 : T a b l e l a y o u t s h o w i n g i n t e r e s t i n g files Unlike the Pathfinder view, the visualizations we describe below are actively in use for the purpose of debugging or inspecting the task context model and for the purpose of continued experimentation with 91 task context visualization techniques. Those that refer to the \"Sandbox\" in their view title indicate that they are in the developer part of the Mylar open source repository66. 5.4.1.Spring Graph of Task Context For the purpose of debugging and inspecting the task context model, we use a view called the Context Tree (Figure 5.5). This view shows all of the elements and relations in the task context. It also shows, through annotations, the DOI level of the elements and relations. This view is similar to Active Search, but takes the slice of all elements and relations in the model, regardless of DOI. The problem with this view is that it is difficult to get an overall sense of the relations in the model. For example, Figure 5.5 shows a cycle in the task context graph that causes the tree view to expand indefinitely. (Jj Foo.java iZ jT| Bar.java p a c k a g e o r g . j a v a t x ; • 0 p u b l i c c l a s s F o o { v o i d b a r { ) { b a z ( ) ; } v o i d b a z () { b a r ( ) ; } } , Sandbox: Context Tree S3 l+J fc? mvlarfilter [52.51999] i+J \\3 src/main [50.038994] El ffl org.javatx [43.018997] S iH) Foo.java [46.202995] IB © Foo [38.091995] 1* SE? java [15.694998] El A barQ [13.134] 9 r e f e r e n c e d by [0.91499996] El * A bazQ [11.217] Q referenced by [0,966] & A barQ [13.151] ffl ^ referenced by [0.9149 Si & Java [12.722999] <1 F i g u r e 5 . 5 : T a s k c o n t e x t t r e e v i e w s h o w i n g r e l a t i o n s o f e l e m e n t s To address this issue, we created a force-directed or spring [25] layout of task context that uses the DOI of each relation as a weighting for the layout algorithm, as show in Figure 5.6. A higher the value of the weight corresponds to a greater the tension on the spring, resulting in the closer the proximity of the corresponding elements. This view explicitly displays the task context model's interest groupings and propagations that we discussed in Section 2.2. A key property of this visualization of task context is that it exhibits high stability as interaction is processed. Thanks to the frequency and recency weighting, task context tends to contain a small number of landmark elements with high interest, as well as high interest relations connecting those elements. This results in a high spring tension between those elements. Only small local disruptions occur to the layout when a new element is added. http://eclipse.org/mylar [verified 2006-10-02] 92 Our spring layout can also be adapted to other visualizations that show elements and relations, such as Unified Modeling Language ( U M L ) static structure diagrams. Although this layout requires considerably more screen estate than the tree views we currently rely on, we believe that it may be an effective task context display mechanism once larger screen resolutions become more common. f I-*' J j £ Sandbox: Context Graph V • o © © • ^ _ ^ [ # D a v o r 0 Rob Suzanne [ n Maleh © P e t e r Simon B Tricia 0 Chris Q Casey ] F i g u r e 5 .6 : F o r c e - d i r e c t e d l a y o u t o f t a s k c o n t e x t 5.4.2. Seesoft Visualization of Task Context The Seesoft layout provides a view of system structure that can be used to highlight changes [22]. We wanted to test how well task context supported this layout. Figure 5.7 shows a Seesoft visualization of task context67 where the vertical bars correspond to the slice of interesting files and the highlighted regions correspond to the slice of interesting elements within those files (e.g., Java methods). Our own experience using this view indicates that its information density is likely to be too low for most programming activities. However, we do make it available for experimental use in the Sandbox. We believe that such a view could be useful for other activities such as reviewing code to find \"hot spots\" that could, for example, be candidates for refactoring. For this we use Visual iser component provided by the http://eclipse.org/ajdt project [verified 2006-10-06] 93 !I Package Explorer S3 Wsualiser 'ii Visualiser Menu Visualiser - Mylar Planning Provider -_j 9 ijj o'g.KapJej-'-Ylar,context.ui iatv.tdv9t.arg] - i $ sic - { j | 9 [|i IMylarUiBridge.java S € | IMylarUiBridge *& getContentOutlineViewersflEditorPart) I I ir! \"0$ org,eclipse.mylar,tasks.core [dev.eclipse.org] S 0} src 6 3} org.eclipse.mylar.tasks.core 9 fjjj ITask.java S € | rtask ® getUrlQ © hasvalidUrlQ •r. org.eclipse.mylar.tasks.ui [dev.eclipse.org] \" Stsrc 0 {Jb org.edipse.mylar,internal.tasks.ui.editors i v ! Figure 5.7: Seesoft visualization of task context 5.4.3. Interaction History Chart In addition to prototyping views to improve how task context is displayed to the user, we also created visualizations to improve our understanding of the massive amounts of usage data that came from our field studies. One example of such a visualization is shown in Figure 5 .8 , where the task context algorithm was run on a user's data to simulate what would be visible in their Eclipse if he had been working with a single task active for the entire duration. This visualization ignores decay and depicts a few elements that gradually gain landmark interest, and the large number elements with low interest. We have used these visualizations for to look for trends such as frequency of landmarks and the range of their interest, and believe that such visualizations have potential for future work in identifying patterns in interaction histories. 94 1208's Events Aggregate DOI 0 1 . 0 0 0 2 . 0 0 0 3 , 0 0 0 4 , 0 0 0 5 , 0 0 0 6 , 0 0 0 7 , 0 0 0 8 . 0 0 0 6 . 0 0 0 1 0 , 0 0 0 1 1 . 0 0 0 1 2 . 0 0 0 1 3 . 0 0 0 Events F i g u r e 5 .8 : V i s u a l i z a t i o n o f i n t e r a c t i o n h i s t o r y w i t h d e c a y i g n o r e d 5.5 Future Work We have defined a model of task context and validated an instance of the model for a development environment and for a file and web browsing application. Our implementation is one particular point in the design space of using interaction to scope down the information presented in an application. In this section, we discuss alternative approaches and future work that could improve task context accuracy and applicability. 5.5.1.Transforming and displaying interaction history Alternate implementations of task context could use different schemas for representing interaction, different algorithms for transforming interaction history into a task context and different data structures and operations for modeling task context. As one example, a simplified model could ignore interaction with generic relations as elements in the model and make the common containment relation (i.e., hierarchy) a first-class part of the model. Another could make relations more prominent, if the domain made relations a direct target of interaction (e.g., an interactive visualization tool that allows direct selections of the edges between elements). 9 5 We have defined a set of task-focused UI mechanisms, suitable for use with Eclipse and similar UI frameworks. Different task-focused UI mechanisms could be used to display task context. For example, in addition to sorting or using force-directed layout to focus a view, groupings or visualizations that cluster elements with related interest values could show additional properties of the task context model. Navigation patterns present in the interaction history could also be overlaid on task-focused UI displays in order to further highlight elements interacted with recently (e.g., building on the simplistic shading in the Pathfinder visualization described in Section 5.4). 5.5.2.Extending Support to Other Domains Our implementation for task context targeted an IDE and a file and web browsing tool. Task context could also be applied to other application domains. Extending task context to domains that have a well-defined notion of task and structure is straightforward, but more work is needed to determine how the task context model could be extended to support domains where tasks and structure are less well-defined. In a domain where tasks are less structured, entire activities, such as listening to music, could correspond to a task context. Supporting such domains would also involve exploring integration with artifacts that are typically considered unstructured, such as images, audio, or video files. What would be required to integrate with such artifacts is a notion of identity of the elements in those artifacts. For example, the identity of the elements in an audio file could be time ranges. Alternatively, the identity of elements in a video file could come from the metadata for that video. Once such a notion of identity is defined, the interaction monitoring and structure bridge frameworks could be used to focus interaction with these kinds of resources. 5.5.3.Improving Interaction with Filtered Views Knowledge workers tend to use a variety of displays ranging from mobile devices to high pixel count desktop or wall-mounted displays. A l l of the task-focused UI mechanisms that we have defined have used fixed threshold values. These thresholds determine which.elements are landmarks, and when elements decay out of a view. Consider a programmer working on a task on his 1024x768 laptop. Given our current tunings, it is likely that this programmer will see a scrollbar in their Package Explorer and will need to do some scrolling to find landmarks of interest. Conversely, a programmer working on a 2048x1536 display is likely to see a considerable amount of unused space in their Package Explorer. The thresholds for tree views could be adapted to the available vertical space in the views. As the context grows, the threshold for an element to be interesting could be gradually raised from -oo in order to fill the visible area of the view without adding a scrollbar. Coupled with the automatic view expansion (Section 3.2.2) this technique could be used to ensure the guaranteed visibility [50] of landmark elements. The tradeoff with 96 this technique is that it would set the threshold per-view, which would come at the cost of different views showing different slices of the context. 5.5.4. Unified Interaction, Context, and State Model Task contexts provide a full history of the interaction with a task. When considered along with a representation of the changing state of information, such as a version-aware document repository, task contexts could enable \"rewinding\" both interaction and state concurrently, enabling a worker to easily return to a previous state in their work history. Our usage metrics indicate that programmers generate roughly 1-10 Megabytes of interaction information per month. This means that it could be feasible to maintain a unified model of all of the interaction all users have and link this with the state changes, without adding substantial overload to document repositories, which are often measured in terms of Gigabytes. Such a unified interaction and document storage facility could support rewinding the state of a system across one or more tasks. Our current model has no support for undoing interaction, and supporting this might require the ability to fork interaction histories. A related challenge is handling resources that change beyond of the reach of the interaction monitoring framework. For example, currently it is possible for the task context model to be updated by all the changes in a software system as long as the source code repository tracks those changes (e.g., by storing the refactoring information that details how elements are renamed). For this to be feasible for web pages, the task context model would need to be notified of changes to the structure of the internet, or of a particular intranet of interest. 5.5.5. Cascading Contexts We have ignored the schemas that knowledge workers use to define their tasks, such as grouping tasks by project or structuring them into subtasks, sequences, or dependencies. Since the task repositories with which Mylar integrates support such task structuring, Mylar IDE users have made frequent requests to allow tasks contexts to contain other tasks and their contexts. For example, if task A has subtasks B and C , the context of task A could be the composite context of task B and C. Mylar can be extended to support this kind of flexible cascading of task contexts using the composition operation. Support for cascading contexts could have a profound effect on the representation of the task context model. For example, instead of storing individual contexts and requiring composition of those contexts, a task context could be identified by a set of spans of an interaction history and relations to other such spans. Activating a task context could then involve \"swapping in\" the corresponding segments of interaction. A simplistic version of this is approximated by our current implementation, which always maintains a composite context of the activated tasks in main memory. However, due to disk space and memory constraints we discard repeated 97 events with the same element corresponding to the same task context's interaction history (Section 3.2.4). More availability of main memory and disk space could remove this restriction allowing the model to have access to all previous interaction, enabling facilities such as interaction pattern detection and the ability to rewinding interaction across one or more tasks. 5.5.6. Focusing the Workweek Once task management becomes an integral part of the work process, it is possible for the Mylar Task List to become inundated with tasks. For example, the author's task list currently contains 2394 tasks, 677 of which are incomplete. In realizing this, we initially became concerned with the profound irony of having moved the information overload problem from the structure views to the task management view. However, we then realized that we could apply task context to tasks (Section 2.4). We use the same operations and similar task-focused UI mechanisms to filter tasks that are not relevant to a slice of the context for the current workweek (Figure 5.9). Tasks that are not scheduled for this week are uninteresting and filtered. The slice of tasks scheduled for the current workday is highlighted in blue, and the slice of those overdue is highlighted in red. Tasks of a high interest, such as those with incoming comments, are always visible (blue arrows in Figure 5.9). The Mylar bug database indicates that a substantial number of users work in this \"Focus on workweek\" mode in order to manage the large number of tasks in their Mylar Task list. U Task List £3 Find: • Description - dD S tqj 0—1 e e lements)^ : O clearActiveChangeSets() void - ContextChangej = I • getTask(IMylarContext context) ITask - Contex ° activeChangeSets Map Press 'CtH+Space' to show Template Proposals Figure 6 . 1 : Separation of interaction-specific rankings from structure-based rankings 6.2.3. Implicit Search and Usage-Based Scoping Implicit or automatic query facilities can provide a mechanism for driving search without the explicit need for the user to invoke the search. Such facilities can use detailed information about the user's environment. For example, just-in-time information retrieval agents use keyword occurrences within 103 currently-selected documents to drive an implicit search and can recommend relevant web pages [56]. As implemented by our Active Search (Section 3.3.3), task contexts provide two additional facilities to such mechanisms. First, by virtue of defining a set of the most interesting elements in a particular context, a slice of the context, such as all landmarks, can be used as an input to implicit search. In the Active Search view, this provides stability, since the set of landmarks changes much less frequently than the currently selected element. Second, a broader slice of the context can be used to provide a usage-based search scope that is task-specific. 6.2.4.Mining User Interaction Hilbert provided a framework for monitoring application events to determine which information was the target of interactions. He also identified the challenge of determining which parts of the interaction were relevant when monitoring is done at a fine-grained level of detail [30]. Mylar addresses this problem by providing weightings based on interaction frequency and recency. Machine learning or user modeling can also be used to determine the relevant parts of a user's interaction history. Such learning approaches have been implemented for the purpose of monitoring web-based document navigation [71]. One approach used mouse movements to determine interest in the relevant area of a web-based document [11]. More recent work has extended this mouse tracking approach to create a model from additional interaction such as tracking UI commands, scrolling, and the time spent on particular pages [29]. TaskTracer has additionally used the time that a page is open, the execution copy commands, and the occurrences of words in the contents of the page to determine relevance [44]. These above approaches employ Bayesian networks or other classifier and machine learning techniques to predict the relevance of documents and other information to the user [72]. Although Mylar has rich facilities for monitoring user interaction, a driving design goal is to make the transformation from interaction to the model predictable to the user. Additional study is needed to determine whether predictability can be preserved when employing finer-grained and more sophisticated monitoring mechanisms such as cursor position, time spent on a document, or the visible areas of scrollable pane, as has been done by the above approaches. In addition, our choice not to use sophisticated and statistical learning models for creating a task context was deliberate. We wanted to ensure that the task context model did not exhibit the failures of adaptive and adaptable menus [23], whose lack of predictability made them difficult to use. However, there are other areas of where adaptability could potentially enhance task context model accuracy. Additional testing will be needed to determine if machine learning approaches can provide improved accuracy while maintaining predictability. 104 6.3 Task Management Tools Some of the foundations on managing the context of documents in a task-centric way come from the Placeless and Presto projects from Xerox P A R C [17], which supported a flexible configuration of documents and provided the \"Vista\" display of tagged. This supported organizing and browsing files by user-defined categories and topics, making it possible to avoid navigating through deep hierarchies. This approach is now available in the Microsoft Windows Vis ta 6 8 operating system. However, these approaches require users to manually categorize their files rather than building up context implicitly. Additional early work in supporting task models and task switching focused on the definition of explicit structure for the tasks (e.g., [9]). Other systems have taken the approach of extracting the definitions and contents of tasks from relevant information sources, such as email (e.g., [5]). Our approach is most similar to those that make the association of information with a task and the determination of the tasks themselves as unobtrusive as possible (e.g., U M E A [34] and TaskTracer [18] [64]. U M E A and TaskTracer both monitor the user's interaction and create a listing of the elements interacted with as part of each task, in the case of TaskTracer, and as part of each project, in the case of U M E A . In these systems, the resources associated with a task increases with the amount of interaction unless a user takes explicit action to delete information from the task. Various mechanisms for determining relevance of a piece of information with a task are discussed in this earlier work, but little empirical evidence of experience with these mechanisms is provided. Our work differs in providing DOI values for each piece of information accessed and in maintaining structural links between information traversed, based on the frequency and recency of the interaction during the task. This makes it possible to present a display of task context that does not grow indefinitely on long-running tasks, since the least relevant elements are decayed out of view automatically. The only other work we are aware of in trimming the documents associated with a task automatically is by Lettkeman et al. [44]. They tested, within the TaskTracer environment, whether machine learning could predict which web pages accessed as part of a task were likely to be revisited. Their work did not consider file interactions as part of tasks; however, we have shown these interactions to be useful in our field study of knowledge workers. In the future, it would be interesting to compare the precision of a decay feature based on interaction with a statistical approach. http://microsoft.com/windowsvista/ 105 6.4 Information Focusing User Interfaces The idea of using a DOI function to control which parts of a large set of structured data should be displayed to the user originated with Focus+Context and fisheye views [45]. In this section, we discuss how our work relates to information visualization in general and to related efforts in software visualizations. 6.4.1. Information Visualization One goal of task context is to improve the density of IDE and information browsing views. However, whereas Card's DOI [9] is purely a function of the tree structure used to determine which parts of the structure to display, the DOI function for task context is based on a user's interaction history and supports a graph structure. Task context extends the notion of DOI beyond navigation by supporting the encoding of the interest of relationships and interaction-based manipulation of DOI values. By virtue of providing a DOI function that defines the elements of high interest, task context is related to Focus+Context views, such as those used for navigating large hierarchies [43]. Our DOI function provides weightings based on interaction with structure, not on a weighting that is purely defined by structural properties alone, as is the case with the above approaches. Task context employs a general interaction-based DOI that can provide an alternative input to such Focus+Context visualization, as discussed in Section 5.4.1. Force-directed graph drawing [21] [25] provides some of the basis for how interest is induced along relationships since task context treats the transitive effects of the induction operation similar to the way force-directed graphs compute layout. The use of force-directed techniques has been demonstrated for rendering diagrams of software structure with a U M L representation [20]. The notion of weighted relationships, used in task context by the DOI level of relations, is also used in the VisualThesaurus tool [24]. However, similarly to the other existing DOI work, the underlying model that these existing approaches take is a function of the structure and not of the interaction history. Part of the original inspiration for task context was to make navigating software structure as intuitive as it is to navigate physical topographies6 9. As such, concepts from wayfinding and cognitive maps are represented in Mylar's UI mechanisms. The ideas of landmarks and paths originate from Kevin Lynch's work on urban planning [47], Lynch's work has been adapted to navigating information by Vinson, who also used the ideas of landmarks and paths for navigating virtual information spaces [69]. Vinson discovered that paths are an emergent phenomenon and arise from the development of spatial knowledge Our original term for task context was \"taskscape\" in order to connote this topographical property. Since we have de-coupled the model from its visual representation, we now only use the term taskscape for topographical visualizations o f task context. 106 for virtual environments in a very similar way to how they emerge for real environments. This implicit representation and emergence of paths is also present in the task context model (Section 2.2). Moonen extended the idea of wayfinding in cities to exploring software systems, but his work focused on not on interaction history but on relating software structure to the concept of landmarks, nodes, paths, districts, and edges [49]. 6.4.2.Software Visualization In addition to the generally applicable information visualization approaches described above, some software visualization tools have used related Focus+Context ideas to reduce information overload in displays of large software systems. The A r g o / U M L visualization tool has a notion of mapping \"to do\" items to files, but these all fall short of a task representation as they only provide program element specific tags [65]. A structure-based notion of DOI has been used for distortion-based techniques of visualizing system structure in terms of data flow and entity-relationship diagrams [68]. These tools manifest the same limitations of structure-centric approaches as discussed above. The work on Instability Visualization and Analysis [7] bears some similarity to our own because the visualization of version control information takes the shape of a surface, and because this surface is constructed with a force-directed mechanism that is based on the structure of the revisions. This use of revision history provides a very coarse form of interaction that is not suitable for an interactive tool (e.g., an element may not populate the context until it is committed to revision control). Our task context model provides a finer-grained representation of interaction. 107 7. Conclusion Information overload and loss of context are a bottleneck on the productivity of knowledge workers. Current tools make it easy to browse and query the structure of the information that knowledge workers need to access. However, given the complexity of today's information systems, knowledge workers end up spending an inordinate amount of time looking for the information relevant to the task-at-hand. As they are constantly multi-tasking, they are also burdened with repeatedly creating and recreating the context they need to get work done. Our approach is to move the burden of finding and identifying the relevant information from the user to a software tool. We leverage users' episodic memory by having them indicate and recall the tasks that form their units of work. In support of this approach, we have created a model of task context, defined user interface and interaction mechanisms for integrating this model with knowledge work applications, and implemented it for an IDE and for a file and web browsing tool. Through a field study of professional programmers, we have demonstrated with statistical significance that an explicit task context makes the programmer class of knowledge workers more productive. Through a study of knowledge workers from a cross-section of professions, we have demonstrated that the model generalizes to supporting interaction with less well-structured information systems and that, when provided with the benefits of an explicit task context, knowledge workers will voluntarily indicate the tasks on which they work. This thesis makes the following contributions to the field of software engineering, and the broader field of knowledge work. First, we provide a generic task context model that represents interaction with any structured or semi-structured data that can be represented as elements or relations. The elements and relations in this model are weighted based on the frequency and recency of interaction with those elements and relations. We demonstrate that this weighting is key to reducing information overload and that capturing context per-task is key to reducing loss of context when multi-tasking. Second, we provide operations on task context that support composing and slicing task contexts in order to integrate the model with views and tools that display system structure. We provide the induction operation for growing the model to encompass structurally related elements and to support implicit search facilities. We also provide operations that support direct manipulation of the interest levels in the model. We demonstrate with our task-focused UI mechanisms that these operations support making task context explicit in an IDE and in a file and web browsing application. 108 Third, we provide a specific instantiation of the model for Java, X M L , generic file and web document structure, as well as tasks themselves, and provide an architecture that supports integrating the model with various other kinds of domain structure. Our model can be extended to other kinds of domains and application platforms, and has already been implemented for a different application platform by another research group7 0. Fourth, we provide a monitoring and reporting framework that can be used for studying knowledge work, as has been demonstrated by the other research groups that have reused this framework71. We have deployed our implementation of task context for programmers widely; tens of thousands of programmers now use Mylar IDE daily, presumably because it gives them productivity benefits as we saw in our field study. In the future, we hope to see widespread adoption of this technology for facilitating knowledge work across a broad spectrum of domains. We also hope that capturing knowledge in the form of task contexts will provide long-term productivity and knowledge sharing benefits to both individuals and organizations. See footnote 8. 7 1 http://wiki.eclipse.org/index.php/Mylar_Related_Research_Projects [verified 2006-10-02] 109 Bibliography 1. Merriam-Webster's collegiate dictionary, Merriam-Webster, Springfield, M A , 2003. 2. Agichtein, E . , Brill, E . , Dumais, S. and Ragno, R. Learning user interaction models for predicting web search result preferences. Proceedings of the 29th Annual International ACM Conference on Research & Development on Information Retrieval, A C M Press, Seattle, Washington, U S A , 2006, 3-10. 3. Backus, J.W. Automatic programming: properties and performance of F O R T R A N systems I and II. Proceedings of the Symposium on the Mechanisation of Thought Processes, A C M Press, Los Angeles, California, U S A , 1958, 165-180. 4. Bellotti, V . , Dalai, B., Good, N . , Flynn, P., Bobrow, D . G . and Ducheneaut, N . What a to-do: studies of task management towards the design of a personal task list manager. Proceedings of the SIGCHI conference on Human factors in computing systems, A C M Press, Vienna, Austria, 2004, 735-742. 5. Bellotti, V . , Ducheneaut, N . , Howard, M . and Smith, I. Taking email to task: the design and evaluation of a task management centered email tool. Proceedings of the SIGCHI conference on Human factors in computing systems, A C M Press, Ft. Lauderdale, Florida, U S A , 2003, 345-352. 6. Berners-Lee, T. Semantic Web Road Map, http://www.w3.org/DesignIssues/Semantic, 1998. 7. Bevan, J. and Whitehead, E.J . Identification of software instabilities. Proceedings of the 10TH Working Conference on Reverse Engineering, IEEE, Victoria, Canada, 2003, 134-144. 8. Brin, S. and Page, L . The Anatomy of a Large-Scale Hypertextual Web Search Engine. Computer Networks and ISDN Systems, 30 (1-7). 107-117. 9. Card, S.K. and Jr., A . H . A multiple, virtual-workspace interface to support user task switching. Proceedings of the SIGCHI/GI conference on Human factors in computing systems and graphics interface, A C M Press, Toronto, Canada, 1987, 53-59. 10. Cheng, L . - T . , Hupfer, S., Ross, S. and Patterson, J. Jazzing up Eclipse with collaborative tools. Proceedings of the 2003 OOPSLA workshop on eclipse technology eXchange, A C M Press, Anaheim, California, U S A , 2003, 45-49. 11. Claypool, M . , Le, P., Wased, M . and Brown, D. Implicit interest indicators. Proceedings of the 6th international conference on Intelligent user interfaces, A C M Press, Santa Fe, New Mexico, U S A , 2001,33-40. 12. d'Entremont, T. and Storey, M . - A . Using a Degree-of-Interest Model for Adaptive Visualizations in Protege. 9th Intl. Protege Conference, Stanford, California, U S A , 2006. 110 13. D a h l , O . - J . , M y h r h a u g , B . and Nygaa rd , K . Some features o f the S I M U L A 67 language. Proceedings of the second conference on Applications of simulations, Winter S imula t ion Conference, N e w Y o r k , N e w Y o r k , U S A , 1968, 29-31. 14. de A l w i s , B . and M u r p h y , G . C . U s i n g visual momentum to explain disorientation in the Ec l ipse I D E . Proceedings of the IEEE Symposium on Visual Languages and Human-Centric Computing, Br igh ton , U K , 2006 ,51 -54 . 15. D e L i n e , R. , C z e r w i n s k i , M . and Robertson, G . Eas ing Program Comprehens ion by Shar ing Nav iga t i on Data. Proceedings of the Visual Languages and Human-Centric Computing, Dal las , Texas, U S A , 2005, 241-248. 16. D e L i n e , R. , K h e l l a , A . , C z e r w i n s k i , M . and Robertson, G . , Towards understanding programs through wear-based fi l tering. Proceedings of the 2005 ACMsymposium on Software visualization, (St. L o u i s , M i s s o u r i , U S A , 2005), A C M Press, 183-192. 17. Dour i sh , P. , Edwards , K . W . , L a M a r c a , A . and Sal isbury, M . , U s i n g properties for uniform interaction in the Presto document system. Proceedings of the 12th annual ACM symposium on User interface software and technology, (Ashev i l l e , Nor th Caro l ina , U S A , 1999), A C M Press, 55-64. 18. Dragunov, A . N . , Diet ter ich, T . G . , Johnsrude, K . , M c L a u g h l i n , M . , L i , L . and Her locker , J . L . , TaskTracer : a desktop environment to support mult i - tasking knowledge workers. Proceedings of the 10th international conference on Intelligent user interfaces, (San D i e g o , Ca l i fo rn ia , U S A , 2005), A C M Press, 75-82. 19. Drucker , P . F . Managing the knowledge worker. M o d e r n Off ice Procedures, 1979. 20. D w y e r , T. , Three dimensional U M L using force directed layout. Proceedings of the 2001 Asia-Pacific symposium on Information visualisation - Volume 9, (Sydney, Aus t ra l i a , 2001), Aus t ra l ian Computer Society, Inc., 77-85. 21. Eades, P. A Heuris t ic for Graph D r a w i n g . Congressus Numerantium, 42. 149-160. 22. E i c k , S . G . , Steffen, J . L . and Sumner, E . E . Seesof t~A tool for v i sua l i z ing line oriented software statistics. Proceedings of the SIGCHI conference on Human factors in computing systems, 18 (11). 957-968. 23. Findlater, L . and M c G r e n e r e , J . , A comparison o f static, adaptive, and adaptable menus. Proceedings of the SIGCHI conference on Human factors in computing systems, (Vienna , Aus t r i a , 2004), A C M Press, 89-96. 24. Fowle r , R . H . , Fowle r , W . A . L . and W i l s o n , B . A . , Integrating query thesaurus, and documents through a c o m m o n visual representation. Proceedings of the Nth annual international ACM SIGIR conference on Research and development in information retrieval, (Chicago , I l l inois , U S A , 1991), A C M Press, 142-151. 25. Fruchterman, T . M . J , and Re ingo ld , E . M . Graph D r a w i n g by Force-directed Placement. Software -Practice and Experience, 21 (11). 1129-1164. I l l 26. Gonzales, V . M . and Mark, G . \"Constant, constant, multi-tasking craziness\": managing multiple working spheres. Proceedings of the SIGCHI conference on Human factors in computing systems, A C M Press, Vienna, Austria, 2004, 113-120. 27. Hammond, T., Hannay, T. , Lund, B. and Scott, J. Social bookmarking tools (I). D-Lib Magazine, 11 (4). 1082-9873. 28. Harrison, W., Ossher, H . , Tarr, P., Kruskal, V . and Tip, F. C A T : A Toolkit for Assembling Concerns, IBM, Yorktown Heights, New York, U S A , 2002. 29. Hijikata, Y . , Implicit user profiling for on demand relevance feedback. Proceedings of the 9th international conference on Intelligent user interface, (Funchal, Madeira, Portugal, 2004), A C M Press, 198-205. 30. Hilbert, D . M . and Redmiles, D.F. Separating the wheat from the chaff in Internet-mediated user feedback expectation-driven event monitoring. ACMSIGGROUP Bulletin, 20 (1). 35-40. 31. Hill , W . C . , Hollan, J.D., Wroblewski, D. and McCandless, T. Edit wear and read wear. Proceedings of the SIGCHI conference on Human factors in computing systems, A C M Press, Monterey, California, U S A , 1992, 3-9. 32. Jacobs, T. and Musial, B., Interactive visual debugging with U M L . Proceedings of the 2003 ACM symposium on Software visualization, (San Diego, California, U S A , 2003), A C M Press, 115-122. 33. Janzen, D. and Voider, K . D . , Navigating and querying code without getting lost. Proceedings of the 2nd international conference on Aspect-oriented software development, (Boston, Massachusetts, U S A , 2003), A C M Press, 178-187. 34. Kaptelinin, V . , U M E A : translating interaction histories into project contexts. Proceedings of the SIGCHI conference on Human factors in computing systems, (Ft. Lauderdale, Florida, U S A , 2003), A C M Press, 353-360 35. Kersten, M . Lessons learned building tool support for AspectJ. AOSD Conference Industry Track, Bonn, Germany, 2006. 36. Kersten, M . Task-focused programming with Mylar, Part 1 Streamline your work with integrated task management for Eclipse, IBM DeveloperWorks, 2006. 37. Kersten, M . Task-focused programming with Mylar, Part 2 Enhance your productivity with automatic context management for Eclipse, I B M DeveloperWorks, 2006. 38. Kersten, M . , Elves, R. and Murphy, G . C . W Y S I W Y N : Using Task Focus to Ease Collaboration Submitted to CHI 2007, 2006. 39. Kersten, M . and Murphy, G . C . Mylar: a degree-of-interest model for IDEs. Proceedings of the 4th international conference on Aspect-oriented software development, A C M Press, Chicago, Illinois, U S A , 2005, 159-168. 112 40. Kersten, M . and Murphy, G . C . Task Contexts for Knowledge Workers: A Field Study. Submitted to CSCW Workshop on Supporting the Social Side of Large-Scale Software Development, Banff, Canada, 2006. 41. Kersten, M . and Murphy, G . C . Using Task Context to Improve Programmer Productivity. To appear in proceedings of the 14th ACM SIGSOFT Symposium on Foundations of Software Engineering A C M Press, Portland, OR, U S A , 2006. 42. Kiczales, G . , et al, Aspect-oriented programming. Proceedings of the European Conference on Object-Oriented Programming, (Jyvaskyla, Finland, 1997), Springer-Verlag, 220-242. 43. Lamping, J., Rao, R. and Pirolli, P., A focus+context technique based on hyperbolic geometry for visualizing large hierarchies. Proceedings of the SIGCHI conference on Human factors in computing systems, (Denver, Colorado, U S A , 1995), A C M Press/Addison-Wesley Publishing Co., 401-408. 44. Lettkeman, A . T . , Stumpf, S., Irvine, J. and Herlocker, J. Predicting Task-Specific Webpages for Revisiting. Proceedings of the Twenty-First National Conference on Artificial Intelligence, Boston, Massachusetts, U S A , 2006. 45. Leung, Y . K . and Apperley, M . D . A review and taxonomy of distortion-oriented presentation techniques. ACM Transactions on Computer-Human Interaction (TOCHI), 1 (2). 126-160. 46. Linden, G . , Smith, B. and York, J. Amazon, com recommendations: item-to-item collaborative filtering. Internet Computing, IEEE, 7(1). 76-80. 47. Lynch, K . The Image of the City. M I T Press, Cambridge, U S A , 1960. 48. Majid, I. and Robillard, M.P. , NaCIN: an Eclipse plug-in for program navigation-based concern inference. Proceedings of the 2005 OOPSLA workshop on Eclipse technology eXchange, (San Diego, California, U S A , 2005), A C M Press, 70-74. 49. Moonen, L . , Exploring software systems. International Conference on Software Maintenance (ICSM), (Amsterdam, The Netherlands, 2003), 276-280. 50. Munzner, T., Francois Guimbretiere, Tasiran, S., Zhang, L . and Zhou, Y . TreeJuxtaposer: scalable tree comparison using Focus+Context with guaranteed visibility. ACM Transactions on Graphics (TOG), 22 (3). 453-462. 51. Murphy, G . , Kersten, M . , Robillard, M . and Cubranic, D., The Emergent Structure of Development Tasks. Proceedings of the European Conference on Object-Oriented Programming, (Glasgow, Scotland, 2005), 33-48. 52. Murphy, G . C , Kersten, M . and Findlater, L . How are Java software developers using the Eclipse IDE? IEEE Software, 23 (4). 76-83. 53. Parnin, C . and Gorg, C . Building Usage Contexts during Program Comprehension. Proceedings of the 14th IEEE International Conference on Program Comprehension, I E E E , Athens, Greece, 2006. 113 54. Pitkow, J., Schutze, H . , Cass, T., Cooley, R., Turnbull, D., Edmonds, A . , Adar, E . and Breuel, T. Personalized search. Communications of the ACM, 45 (9). 50-55. 55. Plotnik, R. Introduction to Psychology. Wadsworth Publishing Company, 2004. 56. Rhodes, B.J. and Maes, P. Just-in-time information retrieval agents. IBM Systems Journal, 2000, 685-704. 57. Rieman, J. A field study of exploratory learning strategies. ACM Transactions on Computer-Human Interaction (TOCHI), 3 (3). 189-218. 58. Robillard, M.P. , Automatic Generation of Suggestions for Program Investigation. Proceedings of the Joint European Software Engineering Conference and ACM Symposium on the Foundations of Software Engineering, (Lisbon, Portugal, 2005), 11-20. 59. Robillard, M.P. and Murphy, G . C , Concern graphs: finding and describing concerns using structural program dependencies. Proceedings of the 24th International Conference on Software Engineering, (Orlando, Florida, 2002), A C M Press, 406-416. 60. Shepherd, D., Pollock, L . and Vijay-Shanker, K. , Towards supporting on-demand virtual remodularization using program graphs. Proceedings of the 5th international conference on Aspect-oriented software development, (Bonn, Germany, 2006), A C M Press, 3-14. 61. Snowden, J.S. Semantic-Episodic Memory Interactions in Semantic Dementia: Implications for Retrograde Memory Function. Cognitive Neuropsychology, 13 (8). 1101-1139. 62. Spertus, E . and Stein, L . A . Squeal: a structured query language for the Web. Computer Networks, 33 (1-6). 95-103. 63. Storey, M . - A . , Cheng, L . - T . , Bull, I. and Rigby, P., Waypointing and social tagging to support program navigation. Proceedings of CHI '06 extended abstracts on Human factors in computing systems, (Montreal, Canada, 2006), A C M Press, 1367-1372. 64. Stumpf, S„ Bao, X . , Dragunov, A . , Dietterich, T . G . , Herlocker, J., Johnsrude, K. , L i , L . and Shen, J.Q. Predicting User Tasks: I Know What You're Doing. 20th National Conference on Artificial Intelligence (AAAI), Pittsburgh, U S A , 2005. 65. Taylor, R. and Redmiles, D. A r g o / U M L . ACMSIGSOFT Software Engineering Notes, A C M Press, 2000, 97. 66. Teevan, J., Dumais, S.T. and Horvitz, E . , Personalizing search via automated analysis of interests and activities. Proceedings of the 28th annual international ACM SIGIR conference on Research and development in information retrieval, (Salvador, Brazil, 2005), A C M Press, 449-456. 67. Teitelman, W. and Masinter, L . The Interlisp programming environment. IEEE Computer, 14. 25-34. 68. Turetken, O., Schuff, D., Sharda, R. and Ow, T .T . Supporting systems analysis and design through fisheye views. Communications of the ACM, A C M Press, 2004, 72-77. 114 69. Vinson, N . G . , Design guidelines for landmarks to support navigation in virtual environments. Proceedings of the SIGCHI conference on Human factors in computing systems: the CHI is the limit, (Pittsburgh, Pennsylvania, United States, 1999), A C M Press, 278-285. 70. Weiser, M . Programmers use slices when debugging. Communications of the ACM, 25 (7). 446-452. 71. Widyantoro, D . H . , Ioerger, T.R. and Yen, J., A n adaptive algorithm for learning changes in user interests. Proceedings of the eighth international conference on Information and knowledge management, (Kansas City, Missouri, U S A , 1999), A C M Press, 405-412. 72. Wolverton, M . Task-based information management. ACM Computing Surveys (CSUR), 31 (2es). 10-10. 115 Study I Questionnaire Subjects of Study 1 (Section 4.2) answered the following questions before starting the study. • How much development experience do you have? How much Java development? • Briefly describe your development responsibilities. • Would you describe yourself as an Eclipse beginner, intermediate, or expert user? How much of your day do you spend in Eclipse? • What do you like about Eclipse's navigation mechanisms and tree views? What don't you like? • Do you find that views such as the Package Explorer and document outline contain too much information? Is it cumbersome to manage the large trees? • For browsing class members do you use the Document Outline, the Package Explorer, both, or something else? • What do you think of Eclipse's current support for presenting and managing open editors? • Do you use the navigation history commands? Are you ever unclear about where the back or forward command will take you? • Do you use the editor's folding feature? If so, does it cause you problems when code you were expecting to see is folded away? , • Please list anything else particular about your navigation style, and any gripes that you have with Eclipse's current support for your navigation needs. 118 "@en ; edm:hasType "Thesis/Dissertation"@en ; edm:isShownAt "10.14288/1.0302110"@en ; dcterms:language "eng"@en ; ns0:degreeDiscipline "Computer Science"@en ; edm:provider "Vancouver : University of British Columbia Library"@en ; dcterms:publisher "University of British Columbia"@en ; dcterms:rights "For non-commercial purposes only, such as research, private study and education. Additional conditions apply, see Terms of Use https://open.library.ubc.ca/terms_of_use."@en ; ns0:scholarLevel "Graduate"@en ; dcterms:title "Focusing knowledge work with task context"@en ; dcterms:type "Text"@en ; ns0:identifierURI "http://hdl.handle.net/2429/30897"@en .