doc/release-1.0.html - gerrit/www.eclipse.org/mylyn - Git at Google

 <html>
 <body>
 <h2 align="center">About Mylar 1.0</h2>
 <p>Mylars task-focused user interface is a new technology that represents a
 fundamental shift in the way
 <a href="http://en.wikipedia.org/wiki/Integrated_development_environment">IDEs</a>
 work. Todays applications and frameworks are composed of millions of lines of
 code, and what state-of-the-art IDEs have done is made all of that code
 instantly accessible. But when used on large systems, the IDE view and search
 facilities often contain thousands of elements. The result of this
 <a href="http://en.wikipedia.org/wiki/Information_overload">information overload</a>
 is that developers often spend more time repetitively scrolling, searching, and
 navigating code than they do programming.&nbsp; The key intuition behind Mylar is that for any task that we do, any bug that
 we fix or feature we add, we only care about a subset of the system.
 Mylar makes this subset explicit by transforming our programming activity into a
 <a href="http://kerstens.org/mik/publications/2006-11-mylar-fse.pdf">task
 context</a> model.&nbsp; The result is that structure views show only
 the relevant information, changes are grouped by task, multi-tasking only
 requires a single click, and expertise becomes easy to share and recall.&nbsp; </p>
 <h3>History </h3>
 <p>In 2003, I was working on integrating new modularity technologies with IDEs.
 Model-driven and <a href="http://aosd.net/">aspect-oriented programming</a> tools
 showed promise in removing significant
 amounts of the <a href="http://en.wikipedia.org/wiki/Accidental_complexity">
 accidental complexity</a> that creeps into our systems. But even with improved
 modularity, it became clear that the
 <a href="http://en.wikipedia.org/wiki/Essential_complexity">essential complexity</a>
 of systems would continue growing, while our ability to deal with that
 complexity would not. I had noticed interesting research on the
 <a href="http://www.cs.ubc.ca/labs/spl/projects/feat/">FEAT</a> and
 <a href="http://www.cs.ubc.ca/labs/spl/projects/hipikat/">Hipikat</a> projects,
 and realized that <a href="http://www.cs.ubc.ca/~murphy/">Gail
 Murphy</a>, a professor at the University of British Columbia, had a deep
 appreciation for this problem and a uniquely practical and empirical
 approach to finding solutions. She convinced me that the best way to to tackle
 the problem was by doing a PhD.
 </p>
 <p>I have loved programming since I was ten years old, when I learned English
 from a <a href="http://www.computercloset.org/TimexSinclairZX1000.htm">Sinclair
 ZX1000</a> BASIC manual. After completing my undergrad and joining the
 <a href="http://www.eclipse.org/aspectj/">
 AspectJ</a> team at <a href="http://www.parc.com/">Xerox PARC</a> I got infected
 with a passion for building tools that make people more productive. What would
 sometimes slow me down is
 <a href="http://en.wikipedia.org/wiki/Repetitive_strain_injury">RSI</a> that
 resulted from very long workdays. The start of my thesis gave me a chance to
 reflect on what the underlying problem was: I was constantly clicking the mouse
 and keyboard to find and re-find the information I needed to get work done. What
 I hadnt noticed before is that I was always browsing and searching for the same
 elements because the tools I was using buried them within deep hierarchies instead of grouping them
 in a more reasonable way. Gail and I brainstormed weekly on how the structure
 relevant to developers tasks could be identified and presented. She instilled
 in me the need to validate any whacky ideas that we came up with via user
 studies, and in August of 2004 we installed
 <a href="http://www.eclipse.org/mylar/publications/2005-03-mylar-aosd.pdf">Mylar
 0.1</a> on six IBM developers desktops. We measured their usage patterns before
 and after they had Mylar, and found that when the IDE views were focused on
 task, they would spend more time programming and less time clicking around
 looking for the information they needed to program. </p>
 <p>We presented
 <a href="http://www.eclipse.org/mylar/publications/2005-03-mylar-eclipsecon-web.ppt">
 Mylar 0.2</a> at the EclipseCon 2005 conference in order to find more study
 subjects. This caught the eye of <a href="http://eclipse-projects.blogspot.com/">
 Bjorn-Freeman Benson</a>, who got the idea instantly, and suggested that we
 propose Mylar as an eclipse.org project. On July 4th, 2005 we released
 <a href="http://www.eclipse.org/mylar/doc/new-0.3.html">Mylar 0.3</a> to the
 first hundred developers who were willing to participate in our user study. Four
 months later we had collected enough data to validate with statistical
 significance that <a href="http://kerstens.org/mik/publications.html">Mylar
 makes programmers more productive</a>. Thanks to the constant releases and the
 fact that all work done on Mylar was done with Mylar, by that time we had produced a
 reasonably well-integrated tool that we were happy to share with others.
 <a href="http://www.eclipse.org/mylar/doc/new-0.4.html">Mylar 0.4</a> was our
 first public release on eclipse.org, and happened on November 4th, 2005. </p>
 <p>At that point, an amazing thing happened, and has continued happening since.
 Developers kept getting
 <a href="http://jroller.com/page/eu?entry=the_most_addictive_eclipse_plugin">
 addicted to Mylar</a>. Like us, they couldnt imagine working without it, and
 became as passionate about having it support their workday as we were. A steady
 stream of bug reports started rolling in, and defined how programmers needed
 Mylar to work in order to support their development process. Many bug reports
 were accompanied by patches that helped Mylar evolve to meet these ever
 increasing needs. Since then we have resolved 1826 bug reports, over 200 of
 which were resolved by community contributions. </p>
 <p>The result is <a href="http://www.eclipse.org/mylar/doc/new.php">Mylar 1.0</a>,
 which integrates task context seamlessly across the Eclipse IDE, and brings
 developers tasks into Eclipse from repositories that include
 <a href="http://www.bugzilla.org/">Bugzilla</a>,
 <a href="http://www.atlassian.com/software/jira/">JIRA</a>,
 <a href="http://trac.edgewall.org/">Trac</a>. More importantly, Mylar 1.0 provides
 frameworks to integrate task context with other kinds of artifacts and task
 repositories, which enables integrators to provide Mylar's benefits to a rapidly growing number of developers. </p>
 <h3>Credits </h3>
 <p>Gail Murphy and the <a href="http://www.cs.ubc.ca">Department of Computer
 Science</a> at the University of British Columbia created the academic
 environment that made it possible to bring Mylar from blue sky brainstorming, to
 a tool used daily by thousands of developers, in less than 3 years. The
 <a href="http://www.ibm.com/ibm/cas/">IBM Centre for Advanced Studies</a> and
 <a href="http://www.nserc-crsng.gc.ca/">NSERC</a> funding of my PhD made it
 possible for me to focus all of my energy on the implementation and validation
 of Mylar. </p>
 <p><a href="http://robertelves.com/">Robert Elves</a>,
 whom Gail and I discovered after seeing his research on using Eclipse navigation
 to rank editors by relevance, is the main reason that the Tasks framework works as well
 as it does today. His relentless drive and tireless effort have single-handedly
 supported the requests and needs of hundreds of Mylar users.
 <a href="http://steffenpingel.de/">Steffen Pingel</a> and
 <a href="http://www.jroller.com/page/eu">Eugene Kuleshov</a> have provided
 countless valuable contributions to Mylar, and thanks to the eclipse.org process
 of <a href="http://www.eclipse.org/projects/dev_process/">meritocracy</a>, have become committers on the project without ever meeting face-to-face with the other members of the team. The following individuals have also
 made substantial contributions leading up to Mylar 1.0 (in order of bugs
 resolved): Shawn Minto, Ken Sueda, Jeff Pound, Wesley Coelho, Willian Mitsuda,
 Brock Janiczak, Lean Findlater, Nathan Hapke, Raphael Ackermann, Meghan Allen,
 and Gunnar Wagenknecht. </p>
 <p>Mylar would not have been possible without the remarkable extensibility of
 the <a href="http://www.eclipse.org/">Eclipse Platform</a>. We extend a huge
 thank you to the teams that created the Eclipse SDK, and to their
 self-hosted and open philosophy of building tools. Their work has resulted in
 the most extensible and comprehensive tool framework, a vibrant user community
 and a platform for innovation.</p>
 <p>Finally, the seeds of these ideas came from
 <a href="http://www.cs.ubc.ca/~gregor/">Gregor Kiczales</a> constantly repeating
 less is more over my shoulder when I was getting buried in complexity, and
 first things first when I was mismanaging my tasks. It brings me great
 satisfaction that Mylar provides tool support that automates his advice.<br>
 </p>
 <p>Happy coding,<br>
 </p>
 <p>Mik Kersten, project lead<br>
 2006-12-11</p>

 </body>
 </html>
	<html>
	<body>
	<h2 align="center">About Mylar 1.0</h2>
	<p>Mylars task-focused user interface is a new technology that represents a
	fundamental shift in the way
	<a href="http://en.wikipedia.org/wiki/Integrated_development_environment">IDEs</a>
	work. Todays applications and frameworks are composed of millions of lines of
	code, and what state-of-the-art IDEs have done is made all of that code
	instantly accessible. But when used on large systems, the IDE view and search
	facilities often contain thousands of elements. The result of this
	<a href="http://en.wikipedia.org/wiki/Information_overload">information overload</a>
	is that developers often spend more time repetitively scrolling, searching, and
	navigating code than they do programming.  The key intuition behind Mylar is that for any task that we do, any bug that
	we fix or feature we add, we only care about a subset of the system.
	Mylar makes this subset explicit by transforming our programming activity into a
	<a href="http://kerstens.org/mik/publications/2006-11-mylar-fse.pdf">task
	context</a> model.  The result is that structure views show only
	the relevant information, changes are grouped by task, multi-tasking only
	requires a single click, and expertise becomes easy to share and recall.  </p>
	<h3>History </h3>
	<p>In 2003, I was working on integrating new modularity technologies with IDEs.
	Model-driven and <a href="http://aosd.net/">aspect-oriented programming</a> tools
	showed promise in removing significant
	amounts of the <a href="http://en.wikipedia.org/wiki/Accidental_complexity">
	accidental complexity</a> that creeps into our systems. But even with improved
	modularity, it became clear that the
	<a href="http://en.wikipedia.org/wiki/Essential_complexity">essential complexity</a>
	of systems would continue growing, while our ability to deal with that
	complexity would not. I had noticed interesting research on the
	<a href="http://www.cs.ubc.ca/labs/spl/projects/feat/">FEAT</a> and
	<a href="http://www.cs.ubc.ca/labs/spl/projects/hipikat/">Hipikat</a> projects,
	and realized that <a href="http://www.cs.ubc.ca/~murphy/">Gail
	Murphy</a>, a professor at the University of British Columbia, had a deep
	appreciation for this problem and a uniquely practical and empirical
	approach to finding solutions. She convinced me that the best way to to tackle
	the problem was by doing a PhD.
	</p>
	<p>I have loved programming since I was ten years old, when I learned English
	from a <a href="http://www.computercloset.org/TimexSinclairZX1000.htm">Sinclair
	ZX1000</a> BASIC manual. After completing my undergrad and joining the
	<a href="http://www.eclipse.org/aspectj/">
	AspectJ</a> team at <a href="http://www.parc.com/">Xerox PARC</a> I got infected
	with a passion for building tools that make people more productive. What would
	sometimes slow me down is
	<a href="http://en.wikipedia.org/wiki/Repetitive_strain_injury">RSI</a> that
	resulted from very long workdays. The start of my thesis gave me a chance to
	reflect on what the underlying problem was: I was constantly clicking the mouse
	and keyboard to find and re-find the information I needed to get work done. What
	I hadnt noticed before is that I was always browsing and searching for the same
	elements because the tools I was using buried them within deep hierarchies instead of grouping them
	in a more reasonable way. Gail and I brainstormed weekly on how the structure
	relevant to developers tasks could be identified and presented. She instilled
	in me the need to validate any whacky ideas that we came up with via user
	studies, and in August of 2004 we installed
	<a href="http://www.eclipse.org/mylar/publications/2005-03-mylar-aosd.pdf">Mylar
	0.1</a> on six IBM developers desktops. We measured their usage patterns before
	and after they had Mylar, and found that when the IDE views were focused on
	task, they would spend more time programming and less time clicking around
	looking for the information they needed to program. </p>
	<p>We presented
	<a href="http://www.eclipse.org/mylar/publications/2005-03-mylar-eclipsecon-web.ppt">
	Mylar 0.2</a> at the EclipseCon 2005 conference in order to find more study
	subjects. This caught the eye of <a href="http://eclipse-projects.blogspot.com/">
	Bjorn-Freeman Benson</a>, who got the idea instantly, and suggested that we
	propose Mylar as an eclipse.org project. On July 4th, 2005 we released
	<a href="http://www.eclipse.org/mylar/doc/new-0.3.html">Mylar 0.3</a> to the
	first hundred developers who were willing to participate in our user study. Four
	months later we had collected enough data to validate with statistical
	significance that <a href="http://kerstens.org/mik/publications.html">Mylar
	makes programmers more productive</a>. Thanks to the constant releases and the
	fact that all work done on Mylar was done with Mylar, by that time we had produced a
	reasonably well-integrated tool that we were happy to share with others.
	<a href="http://www.eclipse.org/mylar/doc/new-0.4.html">Mylar 0.4</a> was our
	first public release on eclipse.org, and happened on November 4th, 2005. </p>
	<p>At that point, an amazing thing happened, and has continued happening since.
	Developers kept getting
	<a href="http://jroller.com/page/eu?entry=the_most_addictive_eclipse_plugin">
	addicted to Mylar</a>. Like us, they couldnt imagine working without it, and
	became as passionate about having it support their workday as we were. A steady
	stream of bug reports started rolling in, and defined how programmers needed
	Mylar to work in order to support their development process. Many bug reports
	were accompanied by patches that helped Mylar evolve to meet these ever
	increasing needs. Since then we have resolved 1826 bug reports, over 200 of
	which were resolved by community contributions. </p>
	<p>The result is <a href="http://www.eclipse.org/mylar/doc/new.php">Mylar 1.0</a>,
	which integrates task context seamlessly across the Eclipse IDE, and brings
	developers tasks into Eclipse from repositories that include
	<a href="http://www.bugzilla.org/">Bugzilla</a>,
	<a href="http://www.atlassian.com/software/jira/">JIRA</a>,
	<a href="http://trac.edgewall.org/">Trac</a>. More importantly, Mylar 1.0 provides
	frameworks to integrate task context with other kinds of artifacts and task
	repositories, which enables integrators to provide Mylar's benefits to a rapidly growing number of developers. </p>
	<h3>Credits </h3>
	<p>Gail Murphy and the <a href="http://www.cs.ubc.ca">Department of Computer
	Science</a> at the University of British Columbia created the academic
	environment that made it possible to bring Mylar from blue sky brainstorming, to
	a tool used daily by thousands of developers, in less than 3 years. The
	<a href="http://www.ibm.com/ibm/cas/">IBM Centre for Advanced Studies</a> and
	<a href="http://www.nserc-crsng.gc.ca/">NSERC</a> funding of my PhD made it
	possible for me to focus all of my energy on the implementation and validation
	of Mylar. </p>
	<p><a href="http://robertelves.com/">Robert Elves</a>,
	whom Gail and I discovered after seeing his research on using Eclipse navigation
	to rank editors by relevance, is the main reason that the Tasks framework works as well
	as it does today. His relentless drive and tireless effort have single-handedly
	supported the requests and needs of hundreds of Mylar users.
	<a href="http://steffenpingel.de/">Steffen Pingel</a> and
	<a href="http://www.jroller.com/page/eu">Eugene Kuleshov</a> have provided
	countless valuable contributions to Mylar, and thanks to the eclipse.org process
	of <a href="http://www.eclipse.org/projects/dev_process/">meritocracy</a>, have become committers on the project without ever meeting face-to-face with the other members of the team. The following individuals have also
	made substantial contributions leading up to Mylar 1.0 (in order of bugs
	resolved): Shawn Minto, Ken Sueda, Jeff Pound, Wesley Coelho, Willian Mitsuda,
	Brock Janiczak, Lean Findlater, Nathan Hapke, Raphael Ackermann, Meghan Allen,
	and Gunnar Wagenknecht. </p>
	<p>Mylar would not have been possible without the remarkable extensibility of
	the <a href="http://www.eclipse.org/">Eclipse Platform</a>. We extend a huge
	thank you to the teams that created the Eclipse SDK, and to their
	self-hosted and open philosophy of building tools. Their work has resulted in
	the most extensible and comprehensive tool framework, a vibrant user community
	and a platform for innovation.</p>
	<p>Finally, the seeds of these ideas came from
	<a href="http://www.cs.ubc.ca/~gregor/">Gregor Kiczales</a> constantly repeating
	less is more over my shoulder when I was getting buried in complexity, and
	first things first when I was mismanaging my tasks. It brings me great
	satisfaction that Mylar provides tool support that automates his advice.<br>
	</p>
	<p>Happy coding,<br>
	</p>
	<p>Mik Kersten, project lead<br>
	2006-12-11</p>

	</body>
	</html>