|Not only did Aspiration invite us to the
SanFrancisco Nonprofit Technology Center, but
Allen Gunn (Gunner) gave us (4 of the 5) the
scenic tour on the way, stopping at Twin Peaks.
This past week a group of 5 of us met to embark on the future of OER content creation — authoring that is easy, fun, rich, and remixable. Specifically we were here to experiment with five existing open-source HTML editors (TinyMCE, Mercury, Proper, Aloha, and Wysihtml5). We plan (with help from several other projects) to adapt one to create structured educational content.
For the first two days, we got some existing projects complete (a more stable document conversion system) or more complete (a continuous integration system). We also defined a set of technical challenges for the editing software. From our own experience and the designs of a user experience team, we knew that we wanted authors to be able to learn while creating, and we wanted them to immediately see the benefits of describing educational features like exercises, terminology and definitions, and even headers that serve as learning guides. So we took user interface designs and ideas, and created a set of technical challenges to apply to the editors. The technical challenges were designed to see if the editor was easy to manipulate in ways that will be needed to support authors creating their content, learning the tool, and using the features easily. They ranged from ensuring that conventions that author expect to work do indeed work — like simple to create paragraphs and the ability to cut and paste text anywhere — to making sure that it will be possible to do smart context menus and smart cut and paste of structured content. In addition to the challenges, we listed the ways we would evaluate the different editors.
|Only 2 of 5, because I
forgot to get a picture
earlier. But you can probably
imagine what 5 people with
laptops look like around
this excellent table at the
So after all this prep, the four developers set out to read docs, look at API’s, and do the qualitative part of the evaluation for all five editors. Editors got significant bonuses for understanding HTML5 documents (because the educational format will be HTML5), having good support for tables and images already (so we don’t have to build that), supporting XHTML (because both projects sprinting use XSLT extensively in tools for importing and exporting), and having broad browser support (because teachers need to be able to use the browser they have). We also looked at the existing community of developers, because we want help and longevity. Based on the qualitative evaluation, Aloha had an edge on all other browsers with the trifecta of HTML5, XHTML support, and IE support.
Phil Schatz had already worked extensively with TinyMCE and Proper and had a good feel for their inner workings (both strengths and weaknesses). Gbenga Badipe and Max Grossman (interns from Rice University) investigated Mercury. Marvin Reimer investigated wysihtml5 and then moved over to Aloha after deciding it didn’t yet have enough supported features. Phil worked with Aloha. Phil implemented challenges 2 and 4 and some of 7 in Aloha in a relatively short time.
So there you have our sprint in action. Did we meticulously fill out the entire matrix of challenges and qualitative evaluations? Nope. But we did determine that one editor, Aloha, with the most qualitative evaluation points, was also relatively easy to extend. We got two developers that will be full time on this project aligned and prepped. We engaged the interest of our interns in this next phase of the project. We got to spend an awesome four days in San Francisco, eating delicious food, experimenting with editors, discussing ideas, and sharing space at the Tech Center, one of SF’s fine co-working spaces.
Onward to Berlin, July 23rd – 27th, where we are co-hosting WYSIWHAT, a day for designers, writers, and educators to envision the future of the wysiwyg editor, followed by 4 more days of developer sprinting. If you are in the area and interested, please join us.