Systems are complex IDEs surface all of the complexity Result is information overload

1. Taskscapes:a topographical model of task contextPh.D. Thesis ProposalMik KerstenSupervisor: Gail MurphyCommittee: Gregor Kiczales, Tamara Munzner, Erich GammaJune 1, 2005 Thesis proposal defense, June 1, 2005

2. Systems are complex IDEs surface all of the complexity Result is information overload Thesis proposal defense, June 1, 2005

3. Existing approaches • Make systems less complex with better modularity • Optimists think AOP or MDD could reduce size by 1/3 • Helps, but not enough • Focus the relevant structure with multiple views • Contents of each become overpopulated • Filters are hard to manage and keep up-to-date • Make the structure easier to access with queries • Burden of formulating queries is on the programmer • Each approach focuses on the system structure Thesis proposal defense, June 1, 2005

4. What if we focus on task structure? • While system complexity continues to grow, the complexity of tasks programmers perform is limited • Current tools make system structure explicit • As a result end up showing too much • Programmers waste time looking for the subset of information relevant to the task at hand • Why not make the task context explicit, so programmers see only what the are working on? Thesis proposal defense, June 1, 2005

5. Thesis statement Automatically encoding and displaying task context makes programmers more productive • This presentation discusses • How to encode it, and operate on the resulting model • How to display it in current IDE views and visualizations • How to measure and study effects on productivity Thesis proposal defense, June 1, 2005

6. Thesis proposal defense, June 1, 2005

7. Thesis proposal defense, June 1, 2005

8. Approach • Making task context explicit • Model should be easy to display and operate on • Predictable and transparent to the programmer • Represent elements, relations, paths, groupings • Information: interaction history • Selection, edit, command and query events • Model: taskscape • A map of information relevant to the task • Relevance is defined by degree of interest [Furnas 1986] • Function not of structure but of interaction history Thesis proposal defense, June 1, 2005

9. Degree of interest DOI(e) =A*(e.selections) + B*(e.edits) – C*(e.decay) public WSIFMessage[] getOutputs() { return outputs; } public WSIFMessage[] getOutputs() … return verify(outputs); Thesis proposal defense, June 1, 2005

10. Once task context is explicit… • Treat parts of your system as a unit • Do operations on them • Work with multiple tasks contexts • Save and restore • Union and intersect • Predict interest of related elements • API clients • Overriding methods • Advice c c d a b b Thesis proposal defense, June 1, 2005

11. Taskscapes • History • Event stream • Taskscape • Height: interest of elements • Arrangement in plane: interest of relations • Projections Thesis proposal defense, June 1, 2005

12. Implementation: Mylar • Prototype built on Eclipse platform • Eclipse provides extensible abstractions for selections, editing, search, and display • Interaction history encoding • Monitors selections, editing, navigation, and commands • Task context display • Filtering, highlighting, sorting, folding, update • Predicted interest • Active search and degrees of separation • Active structure views Thesis proposal defense, June 1, 2005

13. \ Thesis proposal defense, June 1, 2005

14. Validation • Thesis: automatically encoding and displaying task context makes programmers more productive • Can it be extracted and surfaced effectively? • Does it make programmers more productive? • Need productivity measure • Higher ratio implies more time working on task and less time looking for information needed for task • Less browsing elements and scrolling • Less search invocation and result selection • Additional measures • Quantitative usage data and qualitative feedback edits edit ratio = selections Thesis proposal defense, June 1, 2005

15. User studies • Preliminary study • 6 senior IBM enterprise app developers used early Mylar version • Used Mylar views more than standard Eclipse views, liked it • Edit ratio improved 15% across, 40% within most active programmer • Big study • 104 developers signed up so far • 10 day study periods for baseline, interest, and predicted interest • Statistics collected via taskscapes • Element handles are obfuscated for privacy • Answer additional questions about • Task management work practice • Predicted interest and active search (measured with hit ratio) Thesis proposal defense, June 1, 2005

16. Related work • Interaction history (implicit interest model) • App event monitoring [Hilbert 1998], Smalltalk history navigator [VisualWorks] • Query tools (implicit interest model) • FEAT [Robillard 2005], JQuery [Janzen 2003], automated [Ye 2002] • Task management (no mapping to structure) • UMEA monitors desktop apps [Kaptelinin 2003], WorkingSpheres discuss task context [Gonzales 2004] • Visualization (limited interest model) • Focus+context [Furnas 1986, Card 2002], edit & read wear [Hill 1992], wear-based filtering [DeLine 2005] • Taskscapes • Tasks and interaction history are first class • Interest of arbitrary structural elements and relations • Topographical representation, interest propagation and prediction Thesis proposal defense, June 1, 2005

17. Contributions • Primary • Implicitly encoded, topographical model of task context • Integration of model into IDE views that make task context explicit • Secondary • Focus+context visualization of task context • Mechanism for sharing task context Thesis proposal defense, June 1, 2005

18. Timeline Thesis proposal defense, June 1, 2005

19. Thesis proposal defense, June 1, 2005

20. Thesis proposal defense, June 1, 2005

21. Architecture Thesis proposal defense, June 1, 2005

22. mumble Thesis proposal defense, June 1, 2005