Monday, June 25, 2012

Evaluation Criteria for Choosing an Editor to Customize

Regarding the challenges proposed in the previous post, we have been working on a list of questions to ask of each editor. Here is what we have devised. Feedback always welcome.


Evaluating the editors:

Questions to answer when looking at documentation, code, API’s, and when using the editor as an end user would.

  • Is there support for XHTML5 documents?
  • Does the editor support all the fairly modern browsers?
  • How is the table support? Below are some tables to try (HTML not HTML5)
  • What is the support for undo and redo?
  • What community exists around the editor?
  • How well does the editor support cut and paste from Word/LibreOffice/Google Docs
    • Fidelty of the pasted code
    • Cleanliness of the pasted code
  • Does the editor have support for linking things (browse to select, url handling)?
  • Does the editor have native support for adding and embedding media?
  • Is there any existing support for collaborative editing? What kind of support? For example, proper provides hooks for restricting what can be edited, which can then be used to lock small portions of documents while they are being edited.
  • Will collaboration be supportable. (nice to have, can be phased in, but needs to be possible eventually).
  • What language and back end support is needed for the editors. For instance Mercury needs Ruby on Rails.
  • What support is there for third-party javascript.
    • Can you use third-party javascript in the editor.
    • Does the editor use iframes that can make it impossible to save data that a third-party javascript library creates? Can the iframing be made optional?
    • On the other hand, will third-party javascript that the editor relies on conflict with the same libraries that the site using the editor uses? For instance, if both use jquery, then both must use the same jquery version which could be problematic.

Questions to answer by implementing the challenges

  • Which of the challenges are
    • possible
    • easy
    • hard
  • How easy is it to extend the editor and add plugins?
  • How fun is it to work with -- recruitment issue?
  • How well is validation supported?
  • How easy would it be to make specialized versions of the editor for different author audiences?

Sunday, June 24, 2012

Can your editor do this? Take the challenge!

We are spending the weekend in San Francisco investigating open source web authoring tools. Our goal is to specialize one of them for creating OER that has rich structure (exercises, glossaries, etc), all that can be beautifully displayed online, in print, and on mobile devices. Requirements: ease of use, ability to customize sensibly, support for document structure.

We had a user experience (UX) team brainstorming ideas for how to enhance an authoring tool so that is incredibly easy to use to create OER AND also supports adding interesting structure to the document that enriches learner experience. Ideally we want authors to learn new features naturally as they are writing (just-in-time training) and we want the benefits of the new structure to be immediately obvious (immediate reward).

After having seen a plethora of ideas from the UX team, we wanted to distill some technical challenges to try with different web authoring tools. The challenges are supposed to capture technical features that will be necessary to implement interaction designs that help authors learn and use the editor. The challenges themselves are not intended to be fancy user interactions. They will instead help us decide which editors are easiest to customize in ways that will probably be needed to support authors.

Editors: We know that we want to test a few specific editors, but if any readers want to post solutions to some of these challenges and suggest other editors, please do.


The Challenges: Note that some of these will already be supported in a given editor, and so they will be easy to meet. But how easy things are depends on the model that the editor uses. Also, remember, these are technical challenges to help evaluate editor suitability. Usable interactions will need some of these techniques, but the implementations here are not intended to demonstrate usability directly.

  1. Easy Paras: To get a new paragraph, hit return. Backspace/delete to join paras. Structural editors sometimes make this hard.
  2. Help with Headers: Recognize something that might be a header or the start of a new section of a document and decorate it with something that can be used to go back and make it a header or the start of a section.  For instance, if someone has bolded a whole line of text, put a squiggly line under it. And then if the author clicks anywhere on the phrase, a menu pops up that says “Make me a header”.
  3. Count the Cool: Provide a running count of semantic features that have been added to the document. The intention is to count glossary terms, exercises, examples, proofs, etc. Might be able to test this technically by just counting headers, lists, images.
  4. Smart highlighting: When I highlight some text, I get a target (decoration) that will provide a drop down menu. (For now, it could say “Emphasize” and “Add to Glossary”).
  5. Math editing: The editor should be able to accept LaTeX math and ASCIIMath and convert them to browser displayable math. Add the ability to type in LaTeX math into an input box and save MathML into the document at the cursor with the source LaTeX stored on a MathML annotation.  If you edit the math, you should be able to edit the LaTeX source again.
  6. Simple cut and paste should be simple. It should be easy to cut and paste text from anywhere to anywhere. It should be possible to cut part of a list and put it somewhere else. It should be possible to cut or copy a paragraph and part of the next paragraph and move them.
  7. Complicated cut and paste should be possible and safe.  Because we are allowing authors to create structure that can be broken, we need to make sure that we can modify the editor to preserve that structure. The exact details of what should happen when might change with more usability analysis, but the idea here is to show how you do this in the various editors.  
    So add a new structure to the editor. For instance, add an ‘exercise’ that looks like this 

    <div class=’exercise’>
         <div class=’problem-statement’> arbitrary stuff here </div>

         <div class=’solution’> more arbitrary stuff here </div>

    </div>.
  8. Let me select and cut/paste the whole exercise.
  9. Let me select the arbitrary stuff out of either the problem or solution and cut/paste.
  10. Don’t let me paste an exercise into another exercise. Instead show that it will go beneath that exercise.
  11. Don’t let me select part of an exercise that captures the structure, but not all of it. Instead select the whole exercise.