Comparative analysis of treatment of “paragraph” / “norrmal” behavior

Summary:

In the July 21 meeting, we decided to compare different editor interfaces’ behavior around  what happens when things with different levels of block formatting and inline formatting are tagged with Normal / Paragraph styles.

I compared Word Online, Word desktop, Google Docs, Gmail, Adobe Dreamweaver, the Confluence Wiki (used by wiki.illinois.edu), Drupal 7’s CKEditor implementation, Publish.illinois.edu’s TinyMCE implementation, and Box Note.

The analysis of the findings are below, followed by a table of data.

Strong standards:

  • Every editor surveyed files “normal” (or “body” or “paragraph”) with the headings.
  • Every editor surveyed changes “headline” to its “normal” style when that is selected.
  • Every editor surveyed doesn’t remove a link that’s in place when “normal” is applied over something with a link in it.
What this result suggests:
  • These are behavior standards that people have reason to expect everywhere they see editor interfaces. That provides a strong established-behavior-based reason to follow these standards.
  • These behavior standards don’t cause accessibility problems that we’re trying to actively change people’s behavior with.  So we don’t have correspondingly strong behavior-altering reasons to break these standards.
  • We’re not trying to specifically block people from being able to create paragraphs the way we’re trying to specifically block people from being able to use the phrase “read more” in a link. “Read more” is getting active programming countermeasures to combat people’s link-making behavior. But we don’t have an accessibility problem caused by people using paragraphs to try to prevent.
  • Providing interfaces that follow established expectations does provide an accessibility benefit for people with cognitive disabilities, in addition to a usability benefit for everyone.

Moderate standards:

  • The majority of editors don’t remove “bold” formatting when “normal” is applied over something that is bold. 
  • Word and Google Docs both do remove “bold” formatting.
There are two ways to look at this result:
  • CKEditor’s default behavior mirrors the numeric majority of editors, so staying with its default behavior will reinforce the numeric majority’s definition of standard behavior.

(or)

  • Word and Google Docs have a large amount of user mind share between them, and people likely spend more time in Word and Google Docs than the other editors (giving them a higher “time percentage” than “number percentage” of behavior-setting exposure time).  

No standards:

  • Different editors disagree in 4 different ways on how to handle it when a “bulleted” item is then assigned to “normal.”
  • With no clear standard set, we wouldn’t be breaking any  clear expectations with whatever decision we make. 
There are two ways to look at this result:
  • We can choose to leave CKeditor’s default behavior as the default here.

(or)

  • If we’re looking to establish A11yFirst as something that’s clearly different than unmodified CKEditor, following Word’s behavior rather than unmodified CKEditor would be a way to emphasize the difference.

The raw data

What it’s called
Headline 
Bulleted list
Inline bold / link
Word Online
“Normal”
(found in same group as headings)
Becomes “normal” style
Becomes “normal” style
Bold is removed and becomes “normal”. Link is not removed.
Word Desktop (Windows)
“Normal”
(found in same group as headings)
Becomes “normal” style
Becomes “normal” style
Bold is removed and becomes “normal”. Link is not removed.
Google Docs
“Normal text”
(found in same menu as headings)
Becomes “normal” style
Font and size become “normal” but list is still bulleted
Bold is removed and becomes “normal.” Link is not removed.
Gmail
“Normal” (found in same menu as headings)
Becomes “normal” style 
No change
No change
Adobe Dreamweaver
“Paragraph” (found in same menu as headings)
Becomes “normal” style
Paragraph tag is nested within LI tag
No change
Confluence Wiki
“Paragraph” (found in same menu as headings)
Becomes “normal” style
No change
No change
Drupal 7 CKEditor 
“Normal” (found in same menu as headings)
Becomes “normal” style
Paragraph tag is nested within LI tag
No change
Publish. illinois WordPress WYSIWYG
(TinyMCE Editor)
“Paragraph” (found in same menu as headings)
Becomes “normal” style
No change
No change
Box Note
“Body” (found in same menu as headings)
Becomes “normal” style
No change
No change

Lessons Learned – Usability Testing

Participants

  • Nick Hoyt
  • Dena Strong
  • JaEun Jemma Ku

Discussion Topic

  1. Review/analyze three usability testing sessions – result patterns
  2. UX lunch club idea/feedback regarding UI design
  3. Block format discussion regarding Library requirements

Resolution

  • Change/improve vague ” remove format” to specific ones such as “remove heading” or “remove style”
  • Change in tool bar configuration in the second row as the order of
    •  Bold button, Italic button, Inline style menu, remove format button, divider, Special character button, language button (see the attached image below)
  • Gather info about “review format/normal” from other editors such as google doc, MS word, Box) -> comparative analysis by Dena Strong
  • Next “lessons learned meeting from the rest of usability testing” will be on the week of August 14, in which all the usability testings are done.

Discussion and Suggestions from Usability testing

  • Users are confused how to remove “block quotation” style ->redundancy of ” “remove format” function throughout User interface such as “remove format button”, “T” with underline and x mark
  • “inline style” can become “menu” button” not “richcombo” button in CK source function for the consistency
  • Feedback to CKsource -> Language menu button is icon only label, which appears to be kanji character, user thinks that the icon
    • will translate the existing language, not tagging it
    • will add special characters
  • Discussed adding “Normal” menu option under “heading” menu. “Normal” menu is the same function as “remove format” under heading menu
  • Adding font size options such as ” larger” or “smaller” rather than pixel size would help to prevent the users using heading level as a visual style. -> need to confirm its implementation with the rest of group members
  • Trying to find a way to give users ability to remove specific formats in consistet and intuitive way