|
Which files was I working with before lunch?
In the course of a day of programming developers often work on many tasks, where each task involves a different set of methods or files. This constant shifting between tasks causes two problems for the developer. First, when working on a particular task, the developer is often interacting with views that contain 90-99% irrelevant information*, causing him to constantly scroll and search.
 | Information Overload: All of the classes relevant to a task may not fit in the visible area of the PackageExplorer view. In the view to the left, only one of the two relevant classes (in green) shows without scrolling. The dotted line represents the bottom edge of the view; elements below this line are not visible. |
Second, when switching back to a task previously worked on, the developer must recall the details of the previous task, including re-finding the relevant files, in order to restart work on the task.
 | Context Loss: Developers often forget which classes (files) were relevant when returning to an existing task. |
Tasktop helps developers by reducing information overload and eliminating context loss. Developers can focus on the high-level problems, knowing that Tasktop is tracking the details for them.
 | Tasktop: Shows only relevant files during tasks and recalls files relevant to previous tasks. |
Working Task-Focused
Working task-focused with Tasktop requires only a small adjustment to most developers workflow. Here we present an example workflow that developers may follow when working task-focused. When working task-focused, a developer must activate a task before beginning programming for that task. This is the only required deviation from most developers normal workflow. To activate a task you can (A) press the Activate button in the task editor, (B) click on a task’s context icon in the Task List, or (C) use the recent task selector in the Task List.
Once you activate a task you will notice that the Package Explorer is now empty except for the phrase Empty task context, alt-click or unfocus. Your files are not missing. Tasktop has filtered your view to show only the files that are relevant for the task. Because you have not yet worked on this task, the set of relevant files is empty. There are several ways to find files and begin working on your task:
| Structured | Open a file using the Open Type dialog. |
| Click on a file in a stacktrace. | |
| After opening at least one Java file, use Open Declaration or the Call Hierarchy to open other Java elements. |
| Exploratory | Alt+Click in the Package Explorer and the filtered elements will temporarily become visible. Alt+Click on a specific element and its children will become visible. Open elements of interest and they will remain visible. |
| At anytime you can unfocus the Package Explorer and all elements will become visible. To unfocus the Package Explorer press the Focus button, whose icon consists of three purple contexts (represented by circles), at the top right. |
If the user chooses to start by using Open Type, and opens class X, class X becomes visible in the Package Explorer because the developer has expressed interest in it by viewing it. As a developer views and modifies this and other files, Tasktop automatically determines which files are most relevant, based on a degree-of-interest model, and displays only those files to the user. The degree-of-interest model behaves as one might expect, marking files the developer views and modifies as relevant. However, as the number of files with which the developer has interacted grows, the view could become cluttered, so Tasktop systematically prunes and modifies the set of relevant files. For instance, files that the developer viewed only once will eventually drop out of view as the developer views and modifies other files.
On the other hand, files that the developer modifies or views extensively will appear as bold in the Package Explorer, denoting their importance to the given task. The table below shows an example of developer activity and the corresponding elements that Tasktop would display as a result. Note that because class B was only viewed once, and never revisited, it has dropped out of view. In practice, it takes more activity to cause a file to drop out of view than the activity shown in the example.
| Developer Activity | Files showing in Package Explorer |
View class A View class B Modify class A View class C Modify class C Modify class A Modify class C View class A View class D
|
|
Working with the Package Explorer focused can feel like a major step for some developers. For developers that want to experiment with working focused without this step we recommend unfocusing the Package Explorer. Files that are viewed or modified many times during a given task will appear as bold in the Package Explorer, to indicate their unusually high importance to the task. When working with a task, notice how often that you return to the same few files. If you find yourself continually visiting the same set of files for a given task try focusing the Package Explorer. Tasktop will then focus you on that set of relevant files and eliminate extra scrolling and searching.
Multitasking
Tasktop helps you focus on completing individual tasks, but most developers spend their day moving between several tasks. Multitasking is where Tasktop really shines. Consider working on task A and populating your Package Explorer with relevant files. After working on this task for an hour you are interrupted by a high priority task B, which involves a different set of files. Upon finishing task B you return to task A. When you activate task A you will notice that the Package Explorer is populated with the exact same files as when you left the task. The diagram below illustrates the Package Explorers response to these task switches. 
Repopulating the Package Explorer helps you restart your task with a minimum of searching and manual recollection. Often, developers will also put additional notes on the task itself, reminding them of the next step in completing the task, further reducing the cost of the context switch.
Managing Change Sets
Working task-focused with Tasktop has many additional advantages. For developers, one of the chief advantages is automatic change set management. As you work on a task and modify files Tasktop creates a change set for that task. Then, upon task completion, developers can submit exactly the files changed to address the given task, eliminating the need for manual tracking. Offloading this tracking allows the developer to work on more tasks in parallel, because she has confidence that there is a record of which changes go with which task. Managing change sets in this way virtually eliminates unintentional commits of unrelated files, which often cause problems in a source repository (e.g., compilation errors due to incomplete commits).
More Focus
Once you are comfortable working with the Package Explorer focused there are many other ways that Tasktop can focus your work. Here are a few highlights for you to explore:
| Focus your assist menus: Tasktop will place relevant elements at the top of content assist and Open Type selection menus. |  |
| Focus your source code editor: Tasktop can be set to fold all elements that are not relevant in your source code editor. |  |
| Focus across all views: Tasktop focuses many other code views, such as the outline view, providing the same focus consistently throughout the IDE. |
|
Working Task-Focused
Currently most code views in Eclipse are ineffective… they show too many files or elements to be usable. Tasktop reclaims these views by limiting their scope to the current task and the relevant files. Task-focused code views reduce clicking and scrolling during individual tasks and ease the transition between two tasks by serving as the programmer’s memory of relevant files. Tasktop tracks the details of programming tasks so you can focus on being more productive.
*This estimate was calculated using the authors workspace and the authors average number of relevant files.
