Author: kcoombe2@illinois.edu

Date: June 29, 2016

Location: University Library, Room 225b

Attendees:
Jon Gunderson; Nick Hoyt; JaEun Ku; Kate Coombe

Meeting Topics

Introduction

• Due to commitments, William has adjusted his role to assisting with the integration of the final product, once created, into WordPress
• Jon has sent a link regarding CKEditor and potential heading restrictions (automatically hides prohibited heading settings)

Main Discussion

• Due to time and resource constraints, there was a motion to make a final decision regarding which editor would be chosen- TinyMCE or CKEditor
• Final Decision: While both have similar abilities, CKEditor has a rich API, straightforward coding, and is better documented online than TinyMCE
• Discussion regarding block level content (heading, paragraph, references); a need to collect information about user navigation of current editors and how editor interface affects what decisions they make

Action Items

• Nick and John conduct research: Identifying content and editing features, semantic features in CKEditor
  • Nick: Evaluate user interface and how to better organize it, evaluate OneNet
• JaEun: Examine content type menus for toolbars; laundry list for what we want people to do and be able to do
  • Find a student worker programmer in regards to CKEditor project coding
• Create a list of all formatting options that people want or need and why
  • Jon: Emphasis on making only semantically meaningful options available rather than current CKEditor toolbox (massive)
  • Nick: Needs to be a balance, since it is not necessarily possible to understand what every person may need to get across their individual meanings. Needs to be simple, but not overly simplified or restrictive

 

 

 

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

Date: February 15, 2016

Location: University Library, Room 323C

Attendees:

Ku, JaEun, Gunderson, Jon R, Weathers, William Fletcher, Lane, Lori, Hoyt, M Nicholas, Chapman, Suzanne, Pionke, Jj

Interpreter: Bunita L Berg

Meeting Topics

• A recap of library content example
• Discuss:
  • Control for a11y inhouse plugin vs installed plugin
  • A Style guide, put through an accessibility check list
  • An Accessible text editor to ensure the a11y
  • What text editor component will be important
  • How we can improve editing or new text editor in WordPress
  • What components are unnecessary

Links

• CK editor: http://wordpress.ckeditor.com/?page_id=16
• CK editor – Accessibility checker  demo: https://cksource.com/a11ychecker/demo/

Discussion Items

Time	Item	Who	Notes
15min	Recap of library content example	JaEun	Library content review page
5min	Style guide / a11y check for plugin	JaEun	Brief intro for project items
10min	Accessible text editor demo	JaEun	Text editor example (1, default editor, CKEditor, accessibility CKEditor)
20min	Accessible text editor discussion	Jon	·  What text editor component will be important? ·  How we can improve existing or new text editor in WordPress? ·  What components are unnecessary?
10min	Brainstorming for action items/project direction	JaEun/Jon	What is next?

Action Items

1. Regarding text editor tool bar structure (put heading structure first and in-styling next; editing the configuration file in TinyMCE); assign this to William and JaEun
2. Inserting image ui – ie. Consider what title is needed and used for, look at different ways of tagging images (for training or tagging example), SEO for alt image tag-tool tip, in red warning, just time in training, or block inserting the image (easily restrain image)
3. Image, links (list), heading
4. Jon will contact Mike Scott, DHS for State of Illinois for accessible editor – One Net – regarding heuristic approach for list items. Description for link rather than “click more”