Mylar, the task-focused UI for Eclipse, released version 1.0 recently and InfoQ sat down with Mik Kersten, Project Lead to talk about the release, adoption, and future directions of Mylar.
Mylar has generated a lot of interest as it neared the 1.0 release. Wayne Beaton describes his first two weeks with Mylar and Mark Watson has been using it for Ruby work in Eclipse. InfoQ asked Mik Kersten what was new and interesting in the 1.0 release:
If you've been working with Mylar, you'll notice a slimming and streamlining of the UI. Our design philosophy is that less is more, and so we've taken away experimental views, simplified menus, and most importantly reduced the number of clicks for the common workflows. The result is that most of what's new is centered around single view called the Task List. Beyond that, Mylar integrates and reuses all of the existing facilities in Eclipse to focus you on task context.
The conversation then moved on to the question of adoption. Kersten described the mind-shift and how long it takes new users to get a handle on a task-centered development experience:
There is a mind-shift, because re-aligning the entire programming experience around tasks is a fundamental change in the way we work. There isn't a commonly-used Eclipse view that Mylar doesn't re-focus around tasks. The navigator views filter away uninteresting elements, the editor automatically folds uninteresting methods, and the debugger's thread tree hides irrelevant stack frames. On top of that, the moment you de-active your task all of the editors get closed and won't reopen until you re-activate it. But we let you adopt each of these features incrementally. If you have no task active, Mylar will be completely dormant. Once you active the task, every part of the Task-Focused UI is optional and can be turned off, from editor management to automatically restoring perspectives along with tasks. So you can tailor the tool to meet your needs, and get your feet wet gradually. What we have noticed is that it only takes people a couple of weeks to realize how much easier it is to work in this way, and at that point, as many blogs point out, it becomes very difficult to go back.
Next Kersten talked about the future of Mylar:
Our goal on the outset was to get rid of the scroll bars in structure views, and we have largely been successful at doing that. To do it effectively we had to bring the various kinds of tasks that you worked with into Eclipse. We always use Mylar bootstrapped so we did all of the integration bits that made us and our early adopters more productive, such as adding offline editing and change notification for tasks. As a result, around Mylar 0.7 we lost all dependence on the web browser and email inbox for tracking our tasks, and got to work entirely in Eclipse where we are most productive.
The thing that I'm most excited about in the 1.0 release, which was not on the drawing board when we started, is to take the Focused UI idea up one level and apply it to the Task List itself. While integrating task management with Eclipse worked out very well, our Task Lists ended up with huge scrollbars. My Task List currently contains 3000 tasks, 900 of which are not yet complete, and many of which involve collaborations with other people. So we took Mylar's context model and wrote some simple bridge code to invoke it on the Task List itself. The result is that if you click the "Focus on Workweek" button you'll see just the tasks that are relevant to you that week, whether it is because they're assigned to you or because they're bugs that you reported and need to follow up on. While the benefits of working in this way are longer-term, they can be as substantial as those of the resource view focusing. Post 1.0, we will be improving on the way that this personal planning functionality meshes with project-specific workflows and task management.
Asked about the next big shift in how we develop software, Kersten replied:
What I see happening is that the knowledge currently trapped in individual developers' heads will become much easier to share and recall, making it easier for distributed teams to interact and for newcomers to come up to speed. Consider what's happening in Mylar's Bugzilla repository on eclipse.org. Every significant bug that we resolve has a task context attached. If a bug is reopened a couple months later, you instantly see the code and APIs that were changed when it was last worked on, and immediately recall what was going on because your memory of that problem has been externalized. If we didn't complete a bug, but the solution is needed by some user, they can easily pick up where we left off. That's why we require that a task context is attached along with every patch that we apply. We get dozens of patches monthly and they have been critical to evolving Mylar. Having that expertise shared makes patches dramatically easier to review.
Kersten described developing on the Eclipse platform and having to push it forward to create Mylar.
We will always be running up against limitations in the platform - the one that you may have noticed is that we are encouraging source repository providers to standardize on a change set API and UI so that the many developers who use more than one kind of source repository don't end up with a disjointed and cumbersome workflow. There are always limitations in any platforms we build on, and the main question I have asked myself when deciding on platforms is whether it have enough extensibility to support building novel extensions in a robust and modular way. The fact that we have been able to build Mylar without requiring changes from the core platform is a huge testament to Eclipse's extensibility and the quality of its modularity. And in my opinion, the OSGi and plug-in model are simply the best component model we have ever had. Consider that you can run Mylar with all the Java integration missing if you're not doing Java development, or that you can remove all the UI plug-ins altogether and use it as a headless API to Bugzilla on the server side.
The kind of unforeseen extensibility that Mylar needed is something that is already built into the Eclipse development process. For example, the core platform has a policy of exposing its internal packages, which do not follow the strict Eclipse API contract which ensures backwards compatibility. So the platform give us all some rope to hang ourselves with, but in this way it also fosters unforeseen innovations, the most successful of which can then help the core framework evolve further to support new technologies. For example, with Eclipse 3.2 we saw the content assist internals stuck in the Java tools become available to all, which was key for the JSP people, but which Mylar was also able to leverage for interest-based proposal ranking. This careful balance of supporting creativity while being an extremely robust platform for commercial tools is part of the beauty of Eclipse, and what I believe will establish it as the de facto platform for innovation.
