Last April, David Green, Principal Tools Architect at Make Technologies, started a conversation with me about how neat it would be to have Mylyn’s task editor support markup for descriptions and comments. David is a long-time Mylyn user, and we brainstormed about providing this as a new feature for Bugzilla users in addition meeting the expectations of those who already have rich markup supported by their task repository, such as JIRA. In his spare time, David had created the Textile-J open source project, which provided Eclipse-based rich viewing and editing of Textile dialects such as MediaWiki and Confluence.
Rich editors are extremely tricky to get right. I learned about that from my old boss, Charles Simonyi, the former Chief Architect of Microsoft who helped create Word. I was trying to design a WYSIWYG UI for Intentional Software’s domain-specific programming tool and noticed that one of the hardest things about implementing visual editors is attempting to recreate the flexibility of textual editing. Consider some of the AJAX-based editors you have used. I frequently use Confluence’s wiki editor, and while it provides the benefit of seeing the formatting, I constantly end end up jumping back into the wiki markup view. A full-functioned rich editor is a tremendous implementation effort and inherently lacks the freeform flexibilities of text, such as e/images/figures/eclipse-structured-rror tolerance and cut-and-paste. To address this, modern IDEs like Eclipse provide lightweight structured editors, which have all of the flexibility of textual editing, while still providing do what I mean (DWIM) facilities and structured editing. One of the best examples of this is Eclipse’s in-place rename and refactoring facility:
What makes David’s approach to wiki editing so compatible with Eclipse and Mylyn is that it follows and builds on this lightweight rich editing trend. Instead of providing you a restrictive and fully structured editor with toolbars and commands for formatting, you simply edit text in your wiki dialect of choice (e.g., Confluence or Eclipsepedia’s MediaWiki) and the rich formatting gets applied as you type. In the screenshot below, as soon as I typed “h2”, the text immediately became formatted as a heading. This provides both the benefit of WYSIWYG editing, since I see the formatting as it will appear when rendered with a stylesheet, and the flexibility of textual editing, which means that I don’t have to mouse to a toolbar to make something a heading, or be restricted when cutting and pasting sections. Reuse of Eclipse’s content assist to show the formatting facilities of the wiki dialect is the final usability ingredient, since it means that you don’t have to remember syntax.
Today we are announcing that David’s Textile-J project has been approved as a Mylyn contribution and incorporated as an incubation component in the Mylyn project. David and Steffen Pingel have been working hard throughout the summer on integrating this component with Mylyn in order to provide rich editing facilities for tasks. As part of his Google Summer of Code project, Owen Ou has made some great progress on the UI end of the integration and related Mylyn task editor updates. We’ll post more on that soon. Expect rich task editing to start showing up in weekly builds in October, in preparation for our goal of releasing this with Mylyn 3.1 in December. Here’s a preview of Owen’s efforts:
As with the other Eclipse and Mylyn frameworks, the WikiText component is split into UI and core APIs. This means that integrators can reuse the rich formatting of WikiText in order to process wiki pages. For example, for the next release of Mylyn we plan on automatically converting selected Eclipsepedia wiki pages on into Eclipse Help format. We hope to see both users and integrators benefiting from this cool new component.
