If you would like to see a 2 minute video showing several quick workflows, please scroll to the end of this blog.

Editing math: How lazy can our interface be and still be really useful to authors?

My team (in conjunction with several other projects) is creating a web based editor for creating open education resources (OER) that can be adapted and remixed easily. My post from a design and coding sprint in Berlin details some of the principles we are using to keep the editor easy to use, easy to learn, and easy to customize.

For teaching math and science, being able to include equations that display well online and in print is critical. We do have ways of including math in OER that display well online and in print via MathML and tools like MathJax. We still need a way, though, to make it relatively easy for authors to create and edit those equations. Along the way we have learned a few lessons, and come up with a few things we think are true.

Lessons

1. It is hard to build a WYSIWYG math editor that is easy for novices to learn and use, and efficient for experts. More importantly, we aren’t likely to be the ones that get it right. Mathematica, Design Science, Google, or Daum Equation are much more likely than us. So, ultimately, we hope they solve the problem in a way that can be used in our editor.
2. Integrating someone else’s editor has a bunch of technical fiddly bits that are just not doable, … yet. It might not be open source, or it might not have have an API we can easily apply. It might be hard to get the math out in a format that we need. We need MathML, because it works with screen readers and with a bunch of other tools we use to produce online versions as well as epub, kindle, and pdf formats. Or it might not be complete enough to satisfy authors teaching advanced mathematics.
3. Math authors are used to compact notation and are willing to learn new ones. Thus we are conjecturing that they don’t require an equation editor that is fully WYSIWYG and drag and drop. In fact we are conjecturing that they would be willing to use one of two math notations, LaTeX and ASCIIMath. College faculty and upper level students often already know LaTeX.
4. Live or really fast preview is still important. One of our partner projects, Siyavula, has done workshops with high school teachers and found that they are indeed willing to learn a new math notation. But being able to see that what they are typing is correct is really important. Even experts benefit from live preview. (For a really cool look at what instant feedback does for programmers, watch Bret Victor’s talk and demo, “Inventing on Principle”.)

How we have applied these lessons.

Modest ambition and live preview: First, we aren’t trying to build a WYSIWYG math editor. Instead we are building an editor that will accept LaTeX or ASCIIMath notation and will produce a live preview of how the math will look. We use MathJax to do most of the heavy lifting.

Make it easy to learn: For authors who don’t know the notations, we are providing a cheat sheet with common notation that can be cut and pasted into equations. In future versions of the editor, these cheat sheets can be specialized by scientific or mathematical domain. We are also thinking of recommending Daum equation editor as a way to create LaTeX that can be cut and pasted into our equation editor. We will be testing how to make that workflow as efficient as possible.

Click to see a larger view.

Support varied workflows: Authors can enter equations in two different ways. They can click on the math button and a preview and entry box will appear where their cursor is in the document. Or they can just type in one of the two legal codes (ASCIIMath or LaTeX), highlight, and press that math button to automatically convert it to math and show the preview. Finally, math in the document hightlights and shows a small plus sign as authors get near them in the document. Clicking on them brings the editor back up for adding and improving the equation.

Click on the image to see a short video (less than 2 minutes) with three ways to edit math. 1. Edit an existing math equation. 2. Highlight some text written in one of the supported codes, and turn it into math. 3. Add a new bit of math. For the last example, the preview will be live as you type, but the mockup doesn’t show the live preview. Also, the video capture doesn’t show the tooltips that pop up as you hover over the math.

Credits

All of this work has depended on the creative and technical talents of our user experience team (Adrian Garcia, Max Starkenburg, Esther Luk), our incredible student interns that have appeared in other posts (Max Grossman, Gbenga Badipe), and the participants at the sprint we had in Berlin, especially Nicola du Toit of Siyavula who shared her experience working with teachers and Mihai Balaceanu of Sourcefabric who created the original math demo.

Source: Public domain

We are building the latest and greatest authoring tool for creating textbooks and other educational material and we need to decide how important it is to support simultaneous collaboration on documents and how important it is to support the ability to edit offline. We also have to decide whether both have to be supported at once. The real question is about priorities. Which have to be done first? Are there shortcuts we can take in early versions, that still provide real value to authors?

So, first, we need to understand how real authors work and how these features help. At the development sprint in Berlin this past July, we came up with the following ways that authors use collaboration and offline editing. We used our own experience, but we are mostly programmers and techies. Luckily, we also had Siyavula’s experience running workshops where teachers collaborate to write aligned textbooks, as well as Booktype’s experience with documentation sprints, and also the experience of open journals and newspapers.

Collaboration benefits (How simultaneous must collaboration be?)

• One version to rule them all: One of the most important benefits of online document editors is that you don’t have multiple versions of documents being emailed around and dug up from many people’s computer hard drives. Everyone can see and access the current version. This suggests that a single online version would be useful, even if only one person could make changes at a time.
• Simultaneous edit, but different jobs: One person may be creating and another one editing for style. Or one person may be authoring text while another finds images and media. This suggests that it would still be useful if the editor”locked” small regions of a document and let only one person be in a region at a time. 
• Commenting: In many authoring workflows, reviewers make comments, but are not actually responsible for implementing the changes. The author retains that right/responsibility. Annotation systems can serve this need well, without requiring synchronous editing.

From this use case analysis, we think we see ways to make collaborative editing work well for authors without using sophisticated conflict-resolution techniques needed for true simultaneous editing. You can allow true simultaneous editing within text-only portions of the content (because open-source libraries exist for that). But you can use locking on the structure of individual semantic units so that two authors can’t change the same figure/exercise/glossary entry at the exact same time. And therefore you don’t have to write custom conflict resolution. But then to complicate things, what about offline editing?

Offline editing

• Internet access is not ubiquitous everywhere. Offline editing really can be critical in places where authors may go home from a workshop and not have high-speed access.
• Productive use of wait time: Offline access is extremely useful for editing and composing while travelling and waiting. Life provides us all many opportunities to wait. OER could benefit from all that wait time.

Offline editing can be supported by HTML5’s ability to store data locally in the client browser. Upon reconnect, the changes are applied to the document.

Both simultaneous editing and offline editing have important use cases. But if you allow offline editing AND collaboration, then the lazy collaboration we propose above won’t work, because the structural locking can’t be done. And we want to be as lazy as possible so we can get the most functionality out to authors as soon as possible.

The big question: Is it possible to provide authors the ability to do offline editing OR collabrate, but not both? 

For single authors, offline editing could be enabled, and collaboration disabled. That gives them the ability to write whenever and wherever. But if they want to get reviews or work on content as a team, then offline editing would have to be disabled. Would this work?

P. S. How important is Revision history?

• Source-code style revision not used by most authors: From our observations of our own behavior with tools like Google Docs that support fine-grained document revision histories, and from observing teachers at workshops, most people are not using the revision history to find out what changes happened when and trying to apply source-code like merge/accept/reject. For contracts these functions are used extensively, but for educational content, not so much.
• Seeing what the last editor did is useful. When someone makes edits though, being able review just their edits is extremely handy. But this feature is frustrating if you have to scroll through a long document to find those edits. And often there appear not to actually be any changes. 

For now, we are not planning to tackle revision histories. But we are interested in techniques that others come up with, especially if they are author-centric : designed and tested with real authors. I just don’t think that the same things that work for programming will work for writing.

Authoring with meaning and style. 

A group of 18 met on Monday in Berlin to discuss the ideal authoring tool for creating rich content that travels well. By travels well, we all meant slightly different things. In the world of Open Education Resources (OER) we care about content that is easy to share, mix, adapt, translate, and improve. Projects helping groups create books or helping authors self publish, traveling well means content that can be made effective online, in print, and in mobile formats of various sizes and capabilities.

The day was organized as a brainstorming session in 5 groups, twice over, with pens and paper for drawing concepts as well as paper prototypes. Then we had lunch. And then the groups presented ideas and people wrote ideas, questions, issues on sticky notes, which we then sorted into major categories.

Join our discussion!
Principles: We all agreed on a surprising number of principles that appeared from the groupings and commonalities:

• An editor/authoring tool must show authors, editors, and designers what the finished project will look like in various formats. WYSIWYG is necessary, even though some of it will necessarily be in selectable previews
• The model that works best for creation of content is a clean canvas (blank page like) with a simple set of tools that are there when you need them, but not ever overwhelming. 
• Content is created in workflow phases that may alternate in time, but are distinct in the operations that are needed. Content goes through creation, enhancement, review, basic styling, and finishing for distribution. If those phases can share an editor, but customize the interface and supported operations, the natural workflow will be supported in a fluid, dynamic way.
• Tools should be contextual. 
• Training should be integrated and contextual (angry-birds style!)
• A very clear separation between structure and style is needed to support documents that travel well.

Day 2

Future

• Semantic editor
• An OER client that is incorporating the editor

Marvin Reimer, Ying Jin and I were recently in Edinburgh giving a workshop and talk related to our work with SWORD and OER. We have an extension called OERPub that adds defined metadata and specific mechanisms for making new versions and new derived copies of content using the Dublin Core metadata fields.

The party on Wednesday at the Edinburgh Museum.

The Open Repositories conference last year (2011) is where Ross Reedstrom and I confirmed SWORD as a great way to get a publishing API for OER. We went to the workshop given by Richard Jones and Stuart Lewis and also managed to snag Stuart as a reviewer on our extension and first server and client implementation.

The meeting this year was focused mainly on the academic community that builds, uses, and extends repositories like DSpace, Fedora, and EPrints. The focus is on Institutional Repositories and the archiving and preservation of scholarly works. In some sense, our OER work is an outlier at the conference, but it fits in well with the learning repositories supported by JISC, JORUM, and Open University’s Lab Spaces.

We gave a workshop on depositing to Institutional Repositories and OER repositories at the same time using SWORD and OERPub. Faculty authors of textbooks, courses, and, educational journals fit nicely into both worlds. The presentation we gave reviewed the motivations and use cases and we also provided a handout to get started technically. During the main conference, Marvin and I presented an overview of the extensions to SWORD to support OER.

One of the projects we found especially interesting from the conference was the Edina Repository Junction Broker. The RJ Broker is designed to help scholarly publishing houses archive authors’ copies at their respective institutions, but it would be a really nice way to do IR deposits of OER also. We could hook RJ Broker into our client and then allow authors to archive their textbooks and courses at their institutional repositories through RJ Broker.

By David Plotzki (cropped from Museumsinsel) [CC-BY-2.0], via Wikimedia Commons

 Come brainstorm, design, and sprint with us in Berlin, July 23rd to 27th at the Sourcefabric offices. 

Day 1: A free, one-day event for designers, writers, educators, journalists and anyone who produces text in the browser. What is the future of the wysiwyg editor? Work with developers to shape future web tools that make producing text online an easy, powerful and even fun experience.

It’s an open event and all are welcome. All levels of technical virtuosity can contribute, from the web illiterate to the super geek.

Days 2-5: If you are indeed a super geek or interaction designer, you may wish to stay for the next 4 days and work with others to take the ideas of the first day and try and do something with them. Stay to experiment with user interface designs and code, extending existing browser-based editors. We will have developers from OERPUB, Booktype and Connexions who have already started experimenting and building.

Lots of ways to indicate interest, find out more, or sign up:

• Lanyard
• Sourcefabric blog
• Facebook event
• Google+