Mylyn Tutorial - part 2
In the first half of this article, I explained how Mylyn's task management facilities make it easy to focus on tasks relevant to a given day or week. Once tasks become an integrated part of your Eclipse experience, you'll likely notice that many of your repetitive actions center on the context of the tasks you are working on. Multitasking is such a prevalent part of knowledge work today that it's often necessary to create and recreate the context of what's relevant to the task at hand. Your task's context is all of the files, search results, and other relevant information you need to refer to while working on the task. For example, when programming, you might want to see only the Java elements related to a bug that you are fixing. When you're done with the fix, you might want to commit those changes independently of other tasks that you've worked on today. Or you might want to save time by running only tests related to what has changed as you've worked on a task.
What makes Mylyn feel "smart"
Mylyn is often called a smart user interface, but it doesn't actually have any real smarts of its own: it simply reuses yours. Mylyn does this by leveraging the fact that the episodes that make up your work -- the tasks you work on -- are much easier to recall than the details of what was involved with each task. It automatically captures in a predictable way all of the details of what you work on so that you needn't go through the tedious process of recalling or refinding them. Rather than using a learning model that can be hard to understand, Mylyn's task contexts are a predictable projection of your interaction with the system's elements and relations. The model is flexible and is being extended to a broad range of knowledge-work tools. See Resources to learn more about Mylyn's internals and architecture or about extending Mylyn for your project.
Just as Mylyn can help you focus on the tasks that make up your workweek, it can focus your Eclipse workspace on artifacts relevant to the task at hand. With Mylyn's Task-Focused UI installed, all you need to do is indicate which task is active, and all the files that you work with are automatically added to that task's context. The context is managed to represent your evolving interest in various artifacts as you work, even on very long-running tasks. When you switch tasks, the context is saved, enabling you to multitask with a single click and to share task-specific knowledge easily with others.
This article explains how Mylyn seamlessly layers over the Eclipse UI to surface the context of your programming tasks. It starts by explaining Mylyn's mechanisms for managing context and then introduce UI facilities such as interest decorations, view filtering, editor management, and context-driven unit test suites. The article concludes by demonstrating how Mylyn's task management and context management can work together to facilitate team collaboration.
The numbered areas in Figure 1 show some of Mylyn's context-management facilities in action:
- Clicking the Focus on Active Task button causes the Eclipse Package Explorer to show only elements in the active task's context.
- Switching active tasks is done through the Task List.
- Once switched, Eclipse views and editors focus on the context of the newly activated task.
- Change sets are automatically managed to reflect changes in task context.
- Folding and context help focus views on relevant elements.
Figure 1. Focusing Eclipse on task context
Imagine that you're wrapping up your changes to a new feature to meet an impending code-freeze deadline. As you work, you build up valuable knowledge of all the classes and methods you've modified and APIs you've accessed while creating this feature. Because you're using Mylyn, this knowledge is captured automatically in your task context. As you near completion of the task, a critical bug comes in that demands immediate attention.
With a single click, you activate the bug report and begin investigating the problem. As you browse the bug's hyperlinked stack traces using Mylyn's rich task editor, a new task context is populated with your exploration and diagnosis. When you click Mylyn's automated Context Test Suite, which runs unit tests structurally relevant to the context you've created, you discover that the bug is in a colleague's code and not yours. Thanks to Mylyn's linking of revision histories to tasks, you immediately see the colleague's task that corresponds to the problematic change. With another click, you reassign the bug to your colleague and share the task context that results from your diagnosis. You've done all this without leaving Eclipse, so a click of your Task List's Back button instantly restores the context of your previous task. Your colleague, meanwhile, gets to pick up that bug report exactly where you left off. This is just one scenario of the ease with which programmers using the Task-Focused UI work and collaborate.
Similarly to how it requires connectors to integrate with task repositories, Mylyn uses bridges to integrate its context model with domain-specific tools. A core set of bridges for the Eclipse SDK is provided with Mylyn and includes support for Java code, JUnit, the Plug-in Development Environment (PDE), Ant, and plain files. For a fully integrated experience, Mylyn requires a bridge to all the tools and languages you work with (such as Ruby and JSPs). If you lack a bridge specific to the programming language or other file type that you work with, Mylyn still provides focusing down to the file level but can't monitor your interaction with the structure within the files (such as editing particular declarations). This means that you'll see only the interesting files show up in the Package Explorer but won't have the fine-grained declaration filtering (for example, in the Outline view), the automatic folding of declarations in the editor, or advanced features such as task Context Test Suites.
To provide automated change-set management, Mylyn also requires an extension to your version-control integration. CVS is supported out of the box, whereas support for other version-control systems such as Subversion can be installed separately. See the Mylyn Extensions listing in Resources to download additional bridges and version-control integration for Mylyn.
The sections that follow show how you can leverage Mylyn's context management facilities to work in this task-focused way. While the examples are based on Java development, the concepts and most features apply to any file-based artifacts you might work with.
The degree-of-interest model
Task context management in Mylyn is based on the idea that your interaction with a system can be transformed into a degree-of-interest model, where each element in the system is weighted according to its relevance to the task at hand. This degree-of-interest weighting forms the context of all the elements relevant to the task. The task context can then be used to focus the UI by highlighting the most important elements, filtering the unimportant ones, and allowing you to perform operations on elements of interest (for example, committing only relevant changes). Task context is built up in a predictable way as you work: when you activate a task, every element that you select or edit -- such as a file or a Java method -- becomes part of the task context. The more you interact with the element, the higher its degree of interest to the task becomes. If an element's interest ranks high enough, it becomes a landmark, which is an implicitly created bookmark. Each interaction also causes the accrued interest of all the elements a task comprises to decay gradually, so that the set of interesting elements matches what's currently interesting rather than expanding indefinitely.
The key characteristic that makes the task context model intuitive to work with is the fact that it is predictable and obvious: What you expect to see is there, and whenever you start working on an element, you immediately see it populate the context. You can also manipulate the elements' degree of interest directly, either forcing them to be uninteresting or explicitly marking them as landmarks. In other words, nothing is taken away from the bookmark/starring/tagging UIs that you may already be accustomed to. However, once you get accustomed to working with Mylyn, you're likely to find yourself relying much less on such manual mechanisms for managing your task context.
Interest decoration and filtering
Mylyn's context management facilities use traditional Eclipse views to surface information in a new way. All you need to do is activate the task with a click to focus the Eclipse UI on that task. After that, every element you interact with becomes part of the task context. Mylyn's interest decorator then uses font coloring to highlight the level of interest each element has accrued from your interaction. Uninteresting elements are shown in gray, interesting ones in black, and landmarks in bold.
While highlighting alone has limited utility in reducing information overload, it is consistently applied to all views where you see elements such as Java members and files. This makes it easy to pick out elements that are in the task context when you scroll through a long list of elements. For example, when scrolling through search results, you can instantly pick out the most interesting ones because they're decorated in bold as landmarks (see Figure 2).
Decoration alone isn't sufficient for reducing information overload in massive workspaces containing tens or hundreds of thousands of files. Structured views, such as Eclipse's Project Explorer, have become incredibly efficient at letting you browse through large hierarchies. The problem of overload isn't with such views, but with the mismatch between the huge size of the information systems that developers work on and the relatively small size of the information that's relevant to any given programming task. One of the most noticeable manifestations of this mismatch is the time wasted on repeatedly scrolling through and expanding/collapsing large tree views to find the information needed to get work done.
Tip: Unfilter child nodes
To reduce how often you need to turn off the focused mode, Mylyn provides the Alt+Click mechanism to let you temporarily unfilter the children of a node in a tree view. For example, to select a method that's not visible, Alt+Click the class and select that method to add it to the task context. If you Alt+Click the whitespace in the view, all of the root nodes (such as projects) are shown. If you continue to hold down the Alt key, you can navigate quickly from a project node right down to a method of interest.
Mylyn's goal is to stop all of this needless scrolling and clicking. To do this, the Task-Focused UI provides interest-based filtering and structured view management. Toggled with the Focus on Active Task button, these have the effect of filtering away all uninteresting elements, thereby focusing the corresponding view on the active task context. For example, the focused mode ensures that the Package Explorer shows you only what you are working on: all the source and library files and methods that are a part of your task. In addition to filtering, when focus is applied, Mylyn maintains the expansion state of tree views automatically so you don't need to expand and collapse tree nodes manually to reveal interesting elements.
Once you start using the focused mode on views, you'll notice the way that the interest model evolves as you work. The more you select an element, the more interesting it becomes, until it becomes a bold-faced landmark. Elements with a low interest, such as search hits selected only once, decay in interest and disappear from filtered views, ensuring that views don't become bloated with uninteresting elements. Because task context is managed for you actively in a predictable manner, it should contain only elements of interest even on long-running tasks. While Mylyn's task context model is designed always to reflect what's currently relevant to a task, you can also increase or decrease the interest of an element manually (for example, by using either context menu actions on an element or Ctrl+Alt+Shift+up/down arrow keyboard shortcuts).
The task-focused workspace
Before I dive into the advanced integration that Mylyn offers to support Java development, you need an overview of the key contributions that the Task-Focused UI makes to the Eclipse workspace when you're working with plain files. Figure 2 demonstrates the key concepts:
- On the left, the Project Explorer view is focused on the active task, showing only the interesting files and highlighting the landmarks. Here the Alt+Click mechanism has been used to show temporarily all the files in a directory called presentations so that another file of interest can be selected.
- On the right, the Task List shows the active task. Once the task is deactivated, the focus on the Package Explorer view is turned off and all currently open files are closed. If a new task is activated, focus is reapplied, and all the editors that were open for working on that task are instantly restored.
Figure 2. The task-focused workspace
The remainder of the article provides considerable more detail on how to work in a task-focused way, using Java development as an example. However, the concepts of task activation, view focusing, and editor management are the key and most noticeable aspects of using Mylyn. You only need to buy into the concept of task activation to start working in a task-focused way. This small but significant change in the way you work yields an immediate benefit: All the valuable context you build up as you work is no longer lost when you switch tasks.
Tip: Configuring the Task-Focused UI
While most of the Task-Focused UI features are on by default, all of them can be toggled off through the corresponding button in a view or editor or through preference settings. For more detailed information, refer to the Mylyn FAQ (see Resources).
Using Mylyn in Java development
Developers using Mylyn for Java coding typically keep the Package Explorer in focused mode. So, by default, the Focus on Active Task button automatically toggles on when you activate a task and toggles off when you deactivate a task. When it's toggled on, you see only the Java elements that are in your context. As soon as you select a Java class, either by browsing to it or with the commonly used Open Type mechanism (Ctrl+Shift+T), the type becomes a part of your context and shows in the filtered Package Explorer. Each method you select and edit is added to the task context and thus appears in the Package Explorer. Figure 3 shows the Package Explorer in focused mode. Note the interest-based decoration of Java elements and the active filtering in the Package Explorer and Debug views.
Figure 3. Focusing Java element views on task context
Eclipse's facilities for opening elements work well in conjunction with having navigator views in focused mode (use Ctrl+Shift+T for opening a type, Ctrl+Shift+R for a resource, Ctrl+O for the in-place outline, and Ctrl+-T for the in-place hierarchy). To make selecting types in the Open Type dialog easier, interesting types are automatically placed at the top of the list. When you switch tasks, the list contains the interesting types for your new task. When no task is active, the list reverts to Eclipse's global list of recently used types.
If you use the Java Browsing perspective, you can use the window's toolbar button to toggle all three Java element views into focused mode with a single click rather than focusing each view individually.
Tip: Quick views
If you use a perspective that doesn't have a visible navigator view (Debug, for example) or if you have the editor area maximized, you can still navigate your context from Navigate > Quick Context View (shortcut is Ctrl+Shift+Alt+right arrow). As with other quick views such as the Quick Outline (Ctrl+O), this pop-up view has the additional benefit of letting you type so you can navigate to the file or element of interest.
Automatic folding and content assist ranking
Eclipse's state-of-the-art Java editor makes it possible to do much of your structure navigation within the editor itself. Mylyn assists this by providing automatic folding and content assist ranking to help the Java editor focus on what's relevant to the task at hand. If you toggle Mylyn's Automatically Fold Uninteresting Elements button in the window's toolbar, only interesting elements are unfolded in the editor. This increases the editor's information density and makes it easier to navigate declarations in large files without having the Outline view open. As soon as you select an element, it becomes part of the task context and unfolds. Note in Figure 4 that most elements are folded because they haven't been selected or edited; meanwhile, the active element is unfolded, and the left editor gutter indicates that the corresponding element is a landmark:
Figure 4. Automatic folding and content assist ranking
Similarly to how it filters in views, Mylyn also ranks Java content assist proposals according to their interest level. All items below the interest separator are sorted using the Java Development Tools' standard ranking heuristics. This means that you can often select the proposal of interest with only a few presses of the down-arrow key. If you start typing before selecting a proposal, the list reverts to the typical ranking. Also note in Figure 4 that interesting methods such as getTask() are unfolded in the editor. Consistency among the various mechanisms that expose elements' interest levels helps make the Focused UI predictable and easy to use.
Automatic editor and perspective management
Mylyn also uses the task context to manage actively the number of open editors related to a task. When the elements in a file decay beyond your interest, that editor automatically closes. When you deactivate a task, all of its editors close and then reopen upon task activation. Reducing an element's interest closes its editor and, conversely, closing a file reduces its interest. This can take some getting used to, but it means that you no longer need to manage open editor state yourself and that the number of open editors you have doesn't bloat. Ensuring that all open editors correspond to interesting elements also enables you to use Eclipse's editor-navigation facilities for navigating among files of interest. For example, the Ctrl+E and Ctrl+F6 shortcuts can be convenient for switching between editors if a navigator view such as the Package Explorer isn't visible.
In a similar way, Mylyn can also manage Eclipse's perspectives by restoring the perspective that you last had active when working on a task (enabled by clicking Window > Preferences > Mylyn > Context). This can be useful when different tasks correspond to different views offered by Eclipse (for example, some tasks corresponding to Java development, others to PHP). It works particularly well when you use Mylyn's Planning perspective. If you switch to the Planning perspective when no task is active, you're automatically switched into that perspective when you deactivate the next task that you work on. Using the Planning perspective can make it easier to figure out which task to work on next because this perspective maximizes the area available to the task editor and Task List.
Working with Ant, PDE, and other source files
Mylyn's focusing facilities can be applied to all the views that show context in the Eclipse SDK: Package Explorer, Navigator, Project Explorer, Outline, Problems, Tasks, Debug, Packages, Types, and Members. The focused mode of any tree view, such as the Project Explorer, adds interest decoration, filtering, and expansion management. List views, such as Problems, are also sorted by interest when focused. Thanks to this generic support, you can use Mylyn for non-Java projects, such as PHP development, even if your tool is not supported with a custom bridge (see Supported tools). This section is a brief overview of what it's like to use Mylyn for programming with other languages and tools. For more information, see the Mylyn Extensions link in Resources.
As an example, consider developing an application using Ant and PDE. In this scenario, your Eclipse workspace might look something like Figure 5, with multiple views open and showing context:
Figure 5. Focusing generic IDE views on task context
Tip: Clean up to-do markers
In contrast to Mylyn's Task List view, the Eclipse SDK's Tasks view shows markers such as to-do tags, which indicate a local problem with a resource and are similar to a compiler warning. These markers are at a much lower level of granularity than Mylyn's tasks because they correspond to lines of source code, and one Mylyn task could involve multiple markers. Because the Tasks view quickly becomes overloaded, using the focused mode can be a convenient reminder to clean up your to-do markers before committing.
Note that the Project Explorer view in Figure 5 shows only files that are in the task context; in this case, some images and XML files. The open file is build.xml, which comprises dozens of Ant declarations. In the Outline view, you see only the declarations you are working on instead of dozens of uninteresting ones. The Problems view is also focused on the active task, so instead of having it overloaded with hundreds of irrelevant warnings, you only see those of interest (such as all errors and any warnings or other markers for elements in the task context). Finally, the Eclipse Tasks view is focused as well, so rather than seeing hundreds of to-do markers that you won't get to immediately, you only see those relevant to the task context.
The Context Test Suite
Programming in a task-focused way makes it easier to run unit tests frequently. Typically, unit-testing practice has you create a new test launcher for one or more tests that you are currently working on, which can be tedious. The alternatives are to run all tests in a project, which can miss some relevant tests, or to run a whole suite, which can be slow. To address this, Mylyn automatically maintains a unit-test suite of the elements in your task context -- called a Context Test Suite (see Figure 6) -- and makes it easy to run it repeatedly (with the F11 shortcut) when you're working on a task:
Figure 6. Context Test Suites
To enable this feature, create a Context Test Suite for either JUnit Plug-in tests or plain JUnit tests. The Context Test Suite is automatically updated to include all the test cases in the currently active context.
Collaborate with context
Collaborative tools are all about sharing information, and task context can focus that information to prevent overload and distraction. Developers continually send e-mail, instant messages, and files back and forth to exchange the information necessary to perform daily tasks. While Mylyn doesn't remove the need for instant messages or e-mail, it can reduce it and simplify some of your collaborative activities by anchoring them around tasks. Because tasks define a clear, well-understood unit of work and task context defines the information relevant to that work, the ability to share task context with a single click can reduce collaboration's communication burden.
I demonstrated in Part 1 how Mylyn's task management can integrate with Web-based repositories such as Bugzilla to provide the level of collaborative integration and responsiveness that you have come to expect from e-mail clients. This section explains how Mylyn's automated support for tracking change sets and task activity, combined with its support for context sharing, can further facilitate teamwork and capture expertise. As usual, you can pick and choose which features you use based on your needs and on the level of Mylyn's integration with your source and task repositories.
Automated change sets
Tip: Change-set modes
Eclipse has two modes for CVS change sets: the model-based one new in 3.2 and the standard mode. While these modes are practically indistinguishable, the models-based mode is preferred because it shows both incoming and outgoing changes. For details on switching between modes, refer to the Mylyn FAQ (see Resources).
A change set is a built-in Eclipse facility for grouping resources. You operate on it in the Synchronize view for the purpose of committing, updating, or creating patches. Unless you're working on a static project, manually managing change sets is often more trouble than benefit. Mylyn helps you work with source repositories by managing change sets for you automatically. Once you activate a task, a change set for the task is added and then displayed in the Synchronize view (see Figure 7). Changes you make when working on the task are added to that change set. You can use the context menu on the view's Change Set node to override, commit, or create a patch. Incoming changes made by team members show up grouped by task, and you can right-click an incoming change set to open the corresponding task. If you have changes and deactivate a task, the change set persists, allowing you to work with multiple outgoing changes concurrently. Mylyn ensures a one-to-one mapping between the context and change set, so if you manually add a file to a change set (through the context menu in the Synchronize view), the file is also added to the context. Currently supported source repositories are CVS and Subversion (both Subclipse and Subversive).
Figure 7. Change-set management and mapping to tasks
Tip: Associating projects with task repositories
To enable hyperlinking of text and Java editors' references such as "see bug 123" for Bugzilla or "ABC-123" for JIRA, you must associate the project corresponding to the resource to a task repository. Do this by right-clicking the project, selecting Properties, then Task Repository. This project to task repository association is used whenever Mylyn resolves references to tasks from a resource, so it is needed for History or Team Annotation hyperlinks as well. You can check this setting into your version control if the project is shared.
While the effects may be subtle at first, Mylyn's use of context to tie together tasks and resources can have a fundamental impact on the way you work. For example, on the Mylyn project itself, we don't write commit messages because they are automatically generated by Mylyn's change-set integration (use the Window > Preferences > Mylyn > Team page to edit the template used to generate automatic commit messages). This lets us navigate from the History view to the task corresponding to a revision with a single click, which saves time in tracking changes and revisions to their originating task. Conversely, it enables all of the files that have changed for a particular task to be queried from the CVS logs. This, combined with Eclipse's facilities for showing Team Annotations and Mylyn's pervasive hyperlinking (see Figure 8), means you'll spend a lot less time looking up the bugs or tasks related to a change, because they're usually just one click away. (Note that you must press Ctrl for hyperlinks to show in pop-up and textual editors, and that pressing F2 is required to bring the pop-up to the foreground first.)
Figure 8. Hyperlinking and team annotations
Task context captures the knowledge that has been created when a task is performed. Reactivating a task immediately puts you back in that task's context, rather than forcing you to recall the parts of the system relevant to the task. If you turn over a task to a team member partway through, your task context provides him or her with a starting point. Because context is created from interaction -- not just from changes -- every task context includes relevant information, such as APIs accessed and documentation referenced when you worked on the task. To support this and similar collaborative scenarios, such as pair-programming, context can be easily shared. You can activate context sharing through the context menu in the Task List (see Figure 9) or by clicking the corresponding check box in the task editor:
Figure 9. Context sharing via task attachments
As long as you're using a task repository connector that supports attachments, you can easily share task context by attaching it to a bug report. When retrieving a shared context, you can select from those available if more than one is present. On the Mylyn project, for example, we attach a context to every bug report that is resolved and request that a context be attached with every patch that is contributed. This sharing of expertise through task contexts makes it much easier to apply patches, collaborate on bug reports with team members, and clean up code after a pair-programming session. The fact that all of our resolved bugs have a context stored means that we can instantly recall and use past expertise whenever a bug is reopened or similar tasks arise.
What about performance?
Mylyn is designed to ensure that its context management facilities don't impact Eclipse's performance. This is possible regardless of the size of the system you work on, because task context scales with the relatively small amount of interaction you do, not with the large size of the systems you work on. Any noticeable effect of Mylyn on memory or speed overhead is considered a bug and should be reported with high severity. Furthermore, when no task is active, Mylyn's task context management is completely dormant. To learn more about Mylyn's performance profile, read the Mylyn FAQ (see Resources). To turn on Eclipse's memory monitor, use Window > Preferences > General > Show Heap Status.
In this two-part article, I introduced you to task-focused programming with Mylyn. I've shown you how Mylyn can make your work considerably easier by treating tasks as a first-class part of Eclipse. I've also shown you how Mylyn uses Eclipse views to help you focus on the task at hand and surfaces the context of those tasks for both individual and team use.
The philosophy behind Mylyn is that less is more. Mylyn's integrated task management and automatic context management work in tandem to enable you to multitask without losing context and to ensure that you see only the information that you need and no more. Mylyn's task context model has been validated by a field user study conducted on industry developers using the tool for their daily work (see Resources). A statistically significant productivity increase was measured with those users, and thanks to thousands of bug/enhancement reports, Mylyn 2.0 has matured quickly around the needs of its rapidly growing user community. I have been using Mylyn for all my work since creating the 0.1 prototype in August 2004. Like many other Mylyn users, I can no longer imagine needing to find and identify manually the information relevant to what I'm working on. I depend entirely on Mylyn to manage the large amount task-focused interaction and multitasking that makes up my workdays.
If Mylyn supports your task repository, it can make your workday considerably easier, more productive, and more focused. If it does not support your repository, you can still use it with personal tasks. Either way, use the Bugzilla integration to give feedback and to vote for additional connectors that you would like to see supported (see Resources). Your input helps us further refine Mylyn as it continues to evolve rapidly around the tight feedback loop that the tool itself has enabled us to establish with our user community. The other Mylyn committers and I look forward to hearing from you.
Mylyn's success and advancement up to this point are largely the result of input from the numerous users who have reported bugs and contributed patches. This collaboration has helped Mylyn evolve from a research prototype to something that a significant portion of Eclipse users now rely on for their daily work.
Athen O'Shea, Robert Elves, Gail Murphy, and Ducky Sherwood provided helpful feedback on this article.
For more information, see Resources.