Ziel des Mylar-Projekts ist die Entwicklung einer Task-orientierten Benutzeroberfläche für die Eclipse-Plattform. Das Hauptziel von Mylar besteht dabei darin, den Informationsfluss zu reduzieren und einfaches Multitasking zuzulassen. Hervorgegangen ist Mylar aus Mik Kerstens Doktorarbeit. Mik ist der Kopf des Mylar-Projekts und Committer bei den AspectJ- und AJDT-Projekten. Zuvor hat er bei Xerox PARC den IDE-Support für AspectJ und Plug-ins für JBuilder, NetBeans, Visual Studio und Emacs entwickelt. Im Moment schließt er seinen PhD an der Universität von British Columbia ab und konzentriert sich darauf, Eclipse dabei zu helfen, den Informations-Overload zu verringern, indem der Kontext der Tasks, mit denen gearbeitet wird, deutlich gemacht wird.

Mit dem Eclipse Magazin hat Mik über die zentralen Vorteile von Mylar, über Neuerungen zum erst jüngst veröffentlichten 1.0-Release gesprochen sowie darüber, wie Mylar zu einem markttauglichen Produkt werden soll.

Es gibt einige Research-Tools, die dem Programmierer dabei helfen, Elemente explizit zu Bestandteilen der Arbeitsaufgabe zu erklären. Inwieweit unterscheidet sich das Angebot von Mylar von dem anderer Produkte? Was sind die zentralen Vorteile von Mylar?
Mik Kersten: Mylar hat zwei zentrale Features, die es, wenn diese Features in Kombination auftreten, von anderen Ansätzen unterscheiden. Mylar bündelt die Interaktionen mithilfe einer IDE um Tasks herum. Ähnlich wie IDEs Source-Files zu einem wichtigen Bestandteil der Interaktion gemacht haben, hat Mylar Tasks zu einem wichtigen Bestandteil der IDE gemacht. Das Task Management von Mylar integriert sowohl persönliche als auch von vielen genutzte Aufgaben, die in Repositories wie Bugzilla, JIRA und Trac verankert sind. Sind diese erst einmal integriert, funktionieren die Aufbereitung und die Navigation zwischen Aufgaben und Sourcecode nahtlos. Sobald mir beispielsweise ein Bug Report in Bugzilla zugeteilt wird, erscheint auf meinem Screen eine Erinnerung und leitet mich zum neuen Bug Report in meiner Task-Liste, wo ich ihn direkt bearbeiten und auf Einträge im Stack Trace klicken kann, um zum Sourcecode zu gelangen.

Nachdem die Aufgaben einmal eingegeben sind, arbeitet Mylars automatischer Kontextmanager daran, den Informations-Overhead in der IDE zu reduzieren, indem er dir zeigt, woran du gerade arbeitest. Wir glauben, dass weniger mehr ist - wenn man in einem riesigen System arbeitet, braucht man nur die Teile des Systems zu sehen, die mit der eigenen Task zu tun haben. Anstatt dich mit der manuellen Definition solcher Teile zu belasten, wie es viele andere Werkzeuge tun, beobachtet Mylar deine Programmieraktivität, um automatisch den Kontext zu deiner Task aufzubauen. Es analysiert diesen Kontext aktiv, sodass dir nur die wichtigsten Teile gezeigt werden - das in einer sehr vorhersagbaren Weise, und zwar anhand eines Rankings, das den Grad des Interesses anzeigt.

Der Aufgabenkontext wird dann dazu genutzt, das gesamte Eclipse UI auf die aktuelle Aufgabe zu fokussieren. Anstatt beispielsweise hunderte von Elementen zu zeigen, den Package Explorer, zeigt Mylar dir nur diejenigen, die du selbst ausgewählt und bearbeitet hast. Das Beste daran ist, dass diese Kontexte mit einem einzigen Klick gespeichert bzw. mit anderen geteilt werden können. Wenn ein neues Patch hinzukommt, während ich gerade dabei bin, ein Feature hinzuzufügen, aktiviere ich einfach die Task mit dem Patch, rufe das Patch und seinen Kontext aus dem Bugzilla-Report wieder auf und sehe genau das, was der Mitarbeiter gesehen hat, als er das Patch entwickelt hat. Wenn ich mir das Patch dann angesehen habe, braucht es nur noch einen Klick, um zum Kontext der vorherigen Task zurückzukehren, wo Mylar all die Editoren, die vorher geöffnet waren, wiederherstellt, d.h. die für die Task genutzte Perspektive wieder öffnet und mich zu meinem Ausgangspunkt zurückbringt. Häufig arbeiten wir an einem Tag an verschiedenen Tasks, wobei Zusammenarbeit und sich ändernde Prioritäten eine ständige Quelle der Ablenkung darstellen. Mylars Support für die Kontexte von Tasks vereinfacht dieses Multitasking enorm.

Beim ersten Prototypen hatte jeder Eclipse Workspace einen einzigen Mylar-Kontext, aber die Programmierer haben dann den Wunsch geäußert, Mylars Modell so zu erweitern, dass die Unterstützung multipler Tasks möglich ist. Gibt es Pläne, das Mylar-Modell in diesem Sinn zu erweitern?
Kersten: Wir haben die frühe Version Mylar 0.1 mit einer kleinen Gruppe professioneller Programmierer bei IBM getestet. Sowohl unsere eigene Arbeit mit Mylar als auch das Feedback der User-Studie haben gezeigt, dass die Unterstützung von Multitasking ein Schlüsselthema ist. Also haben wir es mit dem Bugzilla-Plug-in, das an der University of British Columbia für ein Forschungsprojekt namens Hipikat entwickelt worden war, kombiniert. Das gab uns eine ausreichende Plattform, um die neue Idee der Task-Kontexte auszuprobieren.

Wir haben Mylar 0.2 für unser eigenes Bootstrapping entwickelt und es auf der EclipseCon 2005 präsentiert, um Teilnehmer für eine User-Studie zu finden. Dann haben wir ein privates Release von Mylar 0.3 für jeden gemacht, der bereit war, an der Studie teilzunehmen. Mylar 0.3 hatte bereits den heutigen Task-Kontext implementiert. Wie die Statistik bestätigte, macht Mylar Programmierer produktiver. In Kürze werden die Ergebnisse der Studie zum Download auf der Mylar-Homepage zur Verfügung stehen.

Obwohl die meisten Anwender von Mylar die Vorführungen gut fanden, gab es ein gemischtes Feedback in Bezug auf das Highlighting-Schema. Einige fanden, dass es visuell gesehen "laut" sei. Werden im Hinblick auf spätere Releases diesbezüglich Änderungen vorgenommen?
Kersten: Das Highlighting des Interessegrads schien zunächst eine gute Idee zu sein, um durch die Änderung der Hintergrundfarbe der Elemente das Spektrum des Interesse-Levels im Task-Kontext anzuzeigen. Allerdings ist zu viel Farbe in einem UI eine andere Methode, den User mit Informationen zu überladen. Also haben wir uns für den Weniger-ist-mehr-Ansatz entschieden und das Schema vereinfacht, wobei die interessantesten Elemente jetzt fett markiert erscheinen, als eine Art implizites Bookmark, das wir "Landmark" nennen. Die uninteressanten Elemente werden in grau dargestellt.

Mylar kann auch von Nicht-Programmierern genutzt werden, um die Files des Users und die Internet-Suchen verfolgen zu können. Inwiefern können individuelle Computernutzer von Mylar profitieren?
Kersten: Zusätzlich zu den User-Studien, die wir mit Programmierern durchgeführt haben, haben wir noch eine andere Studie gemacht, bei der wir die zentralen Teile von Mylar genommen haben und sie in ein Prototyp-File und eine Web-Browsing-Anwendung integriert haben. Wir waren höchst erfreut zu sehen, dass explizite Tasks und Kontexte auch eher generelle Arten von Wissensarbeit unterstützen können und dass die meisten Teilnehmer an unserer Studie freiwillig auf Task-fokussierte Weise gearbeitet haben, wenn man ihnen Tool-Support für die Task-Kontexte gegeben hat.

Zahlreiche Unternehmen haben ihr Interesse an Mylar bekundet. Was für Unternehmen sind das und wie sehen die Pläne hinsichtlich der Umwandlung von Mylar in ein markttaugliches Produkt aus?
Kersten: Mylar ist ein Open-Source-Framework und wird es immer bleiben. Es wird Integration mit dem Eclipse SDK und Task-Repository-Konnektoren, die durch Open-Source-Beiträge unterstützt werden, zur Verfügung stellen. Was wir als Projekt machen wollen, ist sicherzustellen, dass Mylar-Konnektoren auch für eine große Bandbreite von kommerziellen Tasks und Source Repositories entwickelt werden, um die vielen User zu unterstützen, die diese Konnektoren brauchen, um mit Mylar zu arbeiten. Einige Unternehmen, die Issue Trackers zur Verfügung stellen, haben Interesse an einer Integration mit Mylar bekundet, da es garantiert, dass sie beim Entwickeln von gut integriertem Task Manangement für Eclipse nicht das Rad neu erfinden müssen. Unsere Gruppe an der Universität von British Columbia wird eine Firma gründen, um die von diesen Unternehmen gewünschten Consulting- und Training-Services zur Verfügung zu stellen.

Außerdem kann Mylars Kontext-Framework erweitert werden, um es besser mit Programmier-Tools, beispielsweise für die Java EE-Entwicklung, abzustimmen. Auf diese Weise planen wir, Unternehmen Services zur Verfügung zu stellen, die Mylar in Eclipse-basierte Tools integrieren oder einbetten wollen. Schließlich bekommen wir viele Anfragen von Usern, die Mylar auf kommerziell operierende Systeme, E-Mail-Clients und andere Informationsmanagement-Tools abgestimmt haben wollen. Es ist geplant, Konnektoren für solche Tools zur Verfügung zu stellen. Ich erwarte, dass die Tools, die wir auf Basis von Mylar entwickeln, sowie die Integration und die Einbettung von Mylar durch andere Unternehmen die Verbesserung innerhalb des Mylar-Frameworks und der zentralen Tools vorantreiben werden.

Während diese Kommerzialisierung die Reichweite der Mylar-Technologie erweitern wird, wird das Mylar-Projekt weiterhin als offen entwickeltes, transparentes und sehr durchdringbares Projekt existieren. Wir schaffen damit eine neue Technologie, und die Abstimmung dieser auf die unterschiedlichen Arbeitsweisen könnte nicht so schnell vorangehen, wenn es nicht die vielen tausend eingereichten Bug Reports gäbe, die dabei geholfen haben, die Art und Weise, wie Mylar arbeiten sollte, zu definieren, und die vielen hundert Patches, die uns geholfen haben, diesen Stand zu erreichen.

So mancher fragt sich sicherlich, welchen Plan das Mylar-Projekt bezüglich der reibungslosen Zusammenarbeit von Issue-Trackern, Projektmanagement und Entwicklungsumgebung hat ....
Kersten: Mylar ist durch die Integration von Issue-Trackern auf das Projektmanagement der Entwickler abgestimmt. Wenn man beispielsweise Projekte mit Target Milestones managt, kann man Queries in der Task-List erstellen, um diese Milestones hervorzuheben. Ein UI für das Arbeiten mit auf Eclipse abgestimmten Tasks zu haben ist hierbei der zentrale Punkt, weil Entwicklungs-Tasks eng mit Sourcecode verbunden sind. Folglich brauchen wir reichhaltige Unterstützung für die Navigation zwischen diesen beiden Elementen. Auf der anderen Seite kann man Projektplanung leicht unabhängig vom Sourcecode durchführen, weshalb ein Web UI für die Projektplanung oft ausreicht, besonders, seit der Output der Planungs-Sessions durch unsere Synchronisation mit dem Task Repository unmittelbar in der IDE des Entwicklers auftaucht. Wir fokussieren uns darauf, die Erfahrung des Entwicklers zu rationalisieren und sicherzustellen, dass wir das Projektmanagement und die Planungs-Tools der Projekte aufeinander abstimmen.

Abgesehen von Mylar gibt es eine Menge verwandter Projekte, die entweder auf Mylar aufbauen oder es erweitern. Kannst du einige dieser Projekte wie Bug Triage etwas näher beleuchten?
Kersten: Mylar stellt drei erweiterbare Frameworks zur Verfügung - das Task-Framework zur Abstimmung auf die Repositories wie beispielsweise Bugzilla, das Kontext-Framework zur Erweiterung des Task-Kontext-Modells auf andere Arten von Ressourcen und das Monitor-Framework für den Lauf von User-Studien. Teile des Frameworks können "headless" genutzt werden, beispielsweise in einer serverseitigen Anwendung.

Das Bug-Triage-Projekt der Universität von British Columbia hat sich für das Task-Framework und den Bugzilla-Konnektor entschieden und diese als Java-API für den Zugang zu Bugzilla genutzt. Danach hat es ein sehr elegantes serverseitiges Tool implementiert, das Anwendern automatisch Bugs zuweist, die auf vorangegangenen Aufgaben und anderer Heuristik basieren.

Du hast Erfahrung damit, IDEs für AspectJ zu bauen. Eclipse und NetBeans zum Beispiel.
Kersten: Ja, und außer für Eclipse und NetBeans habe ich auch noch Plug-ins für andere IDEs gebaut. Dazu gehören JBuilder, Visual Studio, IDEA und Emacs. Was ich über die übliche Swing/SWT-Debatten hinaus aus diesen Erfahrungen gelernt habe, ist, dass es ein riesiges Spektrum gibt, Erweiterungen für eine IDE zu bilden. Die Mühelosigkeit dieser Erweiterbarkeit erfordert, dass der Sourcecode der IDE zur Verfügung steht und leicht navigierbar ist, weil die Sourcecodes die beste Dokumentation darstellen, wie die APIs zu nutzen sind, besonders, wenn man sie so verwendet, wie von den IDE-Entwicklern ursprünglich nicht vorgesehen war. JDT von Eclipse erleichtert das Browsen der Eclipse-Plattform.

Ein anderer, sehr wichtiger Faktor ist die Modularität der IDE. Je besser die Modularität, desto leichter ist es, die IDE zu erweitern. Ein Beispiel: Mithilfe der Eclipse-Abstraktionen für Views, Filter und Decorators können wir uns auf jede View oder jeden Task-Kontext durchweg konzentrieren. Der OSGi-basierte Plug-in-Mechanismus ermöglicht es, Teile der Plattform lose zu koppeln und unsere eigenen Plug-ins leicht erweiterbar zu machen.

Schließlich ist die durch die Eclipse Plug-in Development Environment (PDE) gegebene Fähigkeit zur Selbstverwaltung der Schlüssel zur Produktivität, wenn es darum geht, Plug-in-Erweiterungen zu entwickeln. Andere IDEs verfügen über verschiedene Kombinationen dieser Features. Allerdings hat die Tatsache, dass Eclipse-Entwickler über so lange Zeit ihre Produkte selbst genutzt haben, zu einer sehr reifen und eleganten Plattform und Tool Support für Plug-in-Entwickler geführt.

Seit der Präsentation auf der EclipseCon haben sich über 75 Leute für die Sommer-User-Studie verpflichtet, die die anfängliche User Community ausgemacht haben. Welchen Input hast du durch die Studie bekommen? Inwiefern hat dies bei der Feinabstimmung für die späteren Mylar-Releases geholfen?
Kersten: Die anfängliche User-Studie war entscheidend dafür, dass wir verstehen konnten, wie man die neue Idee des Task-Kontexts mit Eclipse abstimmen kann. Das ist mit dem heutigen Feedback immer noch so. Wir haben eine Menge darüber gelernt, wie sorgfältig und konsistent der Task-Kontext auf die IDE abgestimmt werden muss. Die Idee, dass Change Sets - also die hereinkommenden und hinausgehenden Kontrolländerungen der Version - sehr viel einfacher genutzt werden können, wenn sie automatisch mit dem Task-Kontext gemanagt werden, stammt beispielsweise aus der User-Studie.

Aus der Studie ging zudem eine interessante Information hervor. Während wir dachten, es wäre klar, dass es nicht sehr nützlich wäre, mehr als eine Task aktiv zu haben - es ist jetzt übrigens nicht mehr auf dem UI - wollten die User die Fähigkeit zum Multitasking ganz besonders, während sie keinen Wert auf die Fähigkeit legten, an zwei Aufgaben zugleich arbeiten zu können.

Zusätzlich zur Validierung der Technologie liefern uns die User-Studien und das ständige Feedback Input darüber, welche Features wir hinzufügen und welche wir vermeiden oder rausnehmen sollten.

Zusätzliche Mylar-Tools erweitern das Kernmodell und die Möglichkeiten des UI und fügen Tool-spezifische Interessen-Codierung und Suchmöglichkeiten hinzu. Es wird angenommen, dass die zukünftigen Erweiterungen Debugging Support, Dynamic Help Integration, die Visualisierung von Interessenmodellen und Unterstützung für die C/C++-Entwicklung mit einschließen werden. Kannst du etwas im Hinblick auf die Entwicklung dieser Aspekte sagen?
Kersten: Unser Ziel ist eine komplette Implementierung für den Task-Kontext für das Eclipse-SDK. Wir haben es fast geschafft, aber wir müssen beispielsweise die Debugging-Integration noch erweitern, um automatische Aktivierung und Deaktivierung von Break Points mit der Task-Aktivierung zu unterstützen. Nach Help Integration wurde bisher nicht viel gefragt, aber wenn man die Größe von Eclipse-Dokumenten berücksichtigt, könnte sie von der Fokussierung auf Task-Kontext profitieren. Wir werden Erweiterungen für andere Sprachen unterstützen, beispielsweise für C/C++, die auf Mylar aufgebaut werden, und wir ziehen den Java- und XML-Support für Ant und PDE als Referenzimplementierung in Betracht.

Was sind die entscheidenden Grenzen von Mylar? Welche Herausforderungen wurden von den Usern ans Licht gebracht?
Kersten: Die entscheidende Herausforderung bestand darin, eine neue Art von Benutzeroberfläche und Interaktion so zu integrieren, dass sie sich nahtlos auf die existierende IDE abstimmen lässt. IDEs hatten noch nie eine erstklassige Vorstellung von User-definierten Aufgaben, und die Idee mit dem Task-Kontext ist vollkommen neu.

Die gesamte Mylar-Implementierung seit dem anfänglichen 0.1-Prototypen ist mit Mylar durchgeführt worden, und dieses Bootstrapping hat uns dabei geholfen, die Integration zu verbessern. Aber ohne eine lebendige User Community wäre es lediglich von der Arbeitserfahrung der Committer beeinflusst worden. Das Ergebnis ist, dass wir durch den ständigen Fluss von Bug Reports weiterentwickeln können und erfahren, wie wir besser integrieren und Mylar verbessern können. Dank Mylars Fähigkeit, mit Bug Reports zu arbeiten, Patches zu entwickeln und Kontexte zu teilen, die das Reviewen von Patches vereinfachen, haben wir die Wege, zum Projekt beizutragen, sehr vereinfacht. Durch den sehr dichten Feedback-Kreislauf, den wir den Nutzern durch unsere Bugzilla-Integration und die Vereinfachung der Beiträge liefern, ist die Bewältigung der Herausforderung und die Reduzierung der Zeit, die man benötigt, um von einer neuen Technologie zu einem gebrauchsfertigen Tool zu gelangen, in einer sehr kurzen Zeit möglich gewesen.

Die Version 1.0 von Mylar gibt es seit dem 8. Dezember. Worauf können wir uns bei dieser Version freuen? Und kannst du uns etwas über die künftige Zielrichtung von Mylar sagen?
Kersten: Ich möchte erwähnen, dass wir alle wöchentlichen Builds von Mylar seit 0.1 als "stabil" ansehen. Und es ist unsere Praxis, niemals zu destabilisieren. Das ermöglicht uns, stets unsere eigenen Produkte zu nutzen - die Committer und Mitarbeiter von Mylar arbeiten direkt mit der letzten Version des CVS. Was sich aber in den letzten zwölf Monaten seit dem ersten öffentlichen Release rapide entwickelt hat, ist das Task- und Kontext-Framework, die Flexibilität und die Integration der Unterstützung für das Task Management und die fortlaufende Integration von Task-Kontext durch das Eclipse-SDK. Zudem stellt der Bugzilla-Konnektor mittlerweile all die Kernfunktionalitäten zur Verfügung, die durch das Web UI erhältlich sind, der Trac-Konnektor verfügt über nahezu alle der von Bugzilla bereitgestellten Fähigkeiten, wie beispielsweise reichhaltiges Editieren und Offline Support, auch der JIRA-Konnektor wird diese Unterstützung bald haben. Mylar 1.0 wird einen Grad an Ausgereiftheit in unserem sich ständig verbessernden UI markieren, was das zur Verfügung stellen von Task Management und die Reduzierung von Informationsüberschuss in Eclipse angeht. Da wir erwarten, dass unsere User Community weiterhin rapide wachsen wird, werden die Prioritäten nach dem 1.0-Release größtenteils durch das künftige Feedback und die Bedürfnisse derer bestimmt werden, die das 1.0 Release übernehmen.

Mik, wir bedanken uns für das Gespräch.