Proposal:Editing usability improvements

From Strategic Planning
Jump to: navigation, search
Status (see valid statuses)

The status of this proposal is:
Request for Discussion / Sign-Ups

Every proposal should be tied to one of the strategic priorities below.

Edit this page to help identify the priorities related to this proposal!


  1. Achieve continued growth in readership
  2. Focus on quality content
  3. Increase Participation
  4. Stabilize and improve the infrastructure
  5. Encourage Innovation



Emblem-star.svg This is a featured proposal.
This template automatically categorizes into Category:Featured proposals. All proposals marked by this template should be on this list too.

Editing is the source of content, and content is the heart of Wikimedia. If editing is difficult, improving Wikimedia is difficult. Currently, the usability of editing pages on Wikimedia projects is poor, a symptom of the current state of the MediaWiki software.

Summary

Problems

These editorial actions currently suffer from low usability:

  • Text - Writing paragraphs of text, where that text may contain italics or bold.
  • Minor fixes - 1 small part of a page, e.g. 1 typo, 1 table cell, might need editing.
  • Images - Inserting images and tagging them with licenses and rights.
  • Tables - Inserting and editing tables

Causes

The low usability is a result of:

  • Markup - Italics, bold, tables, etc., require markup. Having to learn a computer code, however simple, is a barrier.
  • Wiki code - Code contained in articles, e.g. for references, templates, make edit box text boggling.
  • Coarse-grained editing - Sections are the smallest editing unit. Text in the edit box doesn't match the text you read, so it's difficult to find the area you wished to edit.
  • File upload separated - Uploading images and inserting them into pages are 2 completely separated processes, when they ought to be just 1.
  • Legalese - License options by the millions when uploading imagery burdens the user (and the servers).

Solutions

Possible solutions include:

  • WYSIWYG - A WYSIWYG editor.
  • Instant editing - Edit pages directly from the same page that you read them on.

Proposal

Editing is instant, done inline on the page, with some elements of WYSIWYG.

WYSIWYG

Problems with WYSIWYG editors

WYSIWYG editors are notoriously hard to tame:

  • Incorrect HTML inserted all over the place
  • Complex pages become impossible to edit and unwieldy

Ideal WYSIWYG editor

The "ideal WYSIWYG editor" overcomes these problems and allows the user to edit all parts of a page's content, in a visual way. This is the optimal solution.

Partial WYSIWYG

Short of the ideal WYSIWYG editor, an element of WYSIWYG ought still to be added to the current edit box:

  • Edit box font to match article font, i.e. not use monospaced font.
  • Italics and bold visible when editing.

It is acceptable that the WYSIWYG editor shows placeholders - icons of some kind - for complex elements like tables and templates. Editing these elements requires a further action, and isolates that element for editing.

Plain text editor

When WYSIWYG is unavailable, e.g. on mobile phones, older machines, older browsers, a plain text editor is available. This editor is precisely the same as the WYSIWYG editor except for:

  • Plain text used throughout
  • Placeholders rendered as textual tags rather than icons

Instant editing

Smallest unit

The smallest editing units should be:

  • 1 paragraph
  • 1 table cell

Editing procedure

Editing should be instantly available while reading, as this is the moment at which potential edits occur to the user.

  • Edit buttons accessible for each individual editing unit.
    e.g. point at a paragraph, and an edit button hovers to the right.
  • Edit buttons accessible in similar way for larger editing units, e.g. section or page.
  • Editing unit replaced with edit box, without the page changing, when edit button activated.
  • Save/Cancel buttons now available.
  • Multiple edit boxes can be opened concurrently, saved asynchronously.

For older devices not supporting this behaviour, an editing mode where the page changes is acceptable.

Motivation

Editing is currently too difficult. The code visible in most edit boxes is boggling and a major barrier for many editors. I've seen people with great contributions to make to Wikipedia completely refuse to do so, believing the learning curve to be similar to learning a programming language. Unfortunately, they're not too wrong.

Key Questions

  • Is the "ideal WYSIWYG editor" in fact feasible? (e.g. Microsoft is implementing Word online)
  • Compatibility of these additional features with legacy devices.

Potential Costs

  • Development of WYSIWYG editor
  • Upgrades to MediaWiki allowing instant editing

References

Community Discussion

Do you have a thought about this proposal? A suggestion? Discuss this proposal by going to Proposal talk:Editing usability improvements.

Want to work on this proposal?

  1. .. Sign your name here!