TinyMCE vs CKEditor

Date: June 8, 2016

Attendees:
Robert Slate; Jon Gunderson; Nicholas Hoyt; JaEun Ku; Katelyn Coombes; William Weathers.

Introduction : Report Research Findings on Editors

  • Mike: regarding contentEditable: difficult to work with; more familiar with CKEditor regarding accessibility than TinyMCE
  • Nick: as gathered notes and resources on contentEditable. Using contentEditable as a foundation from which to build new accessible authoring tool is possible, but would take tremendous work. More feasible to pick an open source editor which has already dealt with the inherent problems in contentEditable and build from that
    • Recommends “Fixing contentEditable” by Koszulinski
  • John: reports that CKEditor has an approachable tutorial about how to build a time stamp plug in which can be included into any tool or toolbars. With a few weeks of work, it may be possible to replicate OneNet’s features with CKEditor
  • JaEun: concerned about the accessibility of the array of small buttons and functions in TinyMCE; would have to remove unneeded functions

Evaluating Information and Planning Next Steps

  • JaEun: discuss TinyMCE features versus CKEditor. The need to check whether there is something desirable in TinyMCE which is not workable in CKEditor
  • Resolution: settle tentatively on using CKEditor due to mature API and extensive documentation
  • JaEun: consider accessibility checker and whether it would work in CKEditor. In contentEditable, the html is different between browsers. Need to check whether the html would be consistent between browsers in CKEditor and TinyMCE
  • Important to remember that another goal of project besides accessibility: Helping non-technical people create web documents; reduce training and problems
  • Create comparison table for CKEditor and TinyMCE as well as more detailed wish list document which sorts what is required from what is just desirable
    • Include: what can support real time accessibility; potentially create plug in which can periodically inspect changes in the content of the editor and then run it against established accessibility guidelines; certain specified elements will trigger an accessibility check
    • Robert: wish list could be divided into three different categories of functional requirements: things which are built into the user interface, what occurs in real time checks, and what occurs in manual checks

Specific Suggestions

  • John: important to create an editor which doesn’t prevent people (could cause frustration) but rather encourages
  • An ideal editor will not let the problem elements build up, but rather evaluate as you go. Maybe prevent certain things, but offer a wizard style set of questions which will present alternative formats or suggestions
  • Robert: note that the side bar design is important to guiding users. For example, OneNet is broken up into simple categories which the editor walks one through. Toolbar designs in both TinyMCE and CKEditor mix up buttons and functions rather than sort by priority. Think specifically about a way to give editor a framework
  • Consider ways accessibility checker provides feedback, such as whether it would be more effective in context (highlighting actual text) or from a side bar, or even a combination

Deliverables

  • Proposed Schedule:
    • By June 18: Formally decide which editor to use
    • Between June 18-30: Have a work item list, including what is to be in real time as well as what features are necessary and which are desirable
    • In July: Design user interface
  • Specific Instructions
    • Create a more detailed wish list for a future editor, noting what is required and what is desirable but non-essential
    • Create a comparison table for TinyMCE and CKEditor in response to this wish list