Jump to content

Page Curation

From mediawiki.org
Revision as of 00:16, 20 September 2011 by Jorm (WMF) (talk | contribs) (Work VERY much in progress but I wanted to get something up.)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

This document is a work in progress. Comments are appreciated but this is not a final draft.

A mockup of a "zoom" interface for New Page Patrol

This document describes the design of a new interface for "New Page Patrolling". This document is a work in progress. Feedback is welcome on the talk page.

This project is envisioned with multiple phases. By necessity (both of resourcing and change control), the project has been split into sections.

The design as published is incomplete and has many holes. This document is intended as a starting line for discussion about improving the overall experience of New Page Patrol.

Notes on Nomenclature

This document will refer to "New Pages" as any page that has not been marked as "Patrolled". Edit count on the page is not taken into consideration.

Further, pages that are marked for speedy deletion will be simply referred to as "marked for deletion"; these pages are also technically marked as "patrolled".

For the sake of verbiage, this document will assume three states of an article:

  • Unpatrolled - The article has not been marked patrolled.
  • Marked for Deletion - The article has had one or more speedy deletion criteria applied.
  • Patrolled - The article has been marked as "patrolled". Zero or more tags requesting improvement may have been applied.


Rationale

  • New Page Patrol is a complicated process that is poorly supported by the MediaWiki software itself.
    • No two patrollers seem to utilize the same process.
  • Users who perform New Page Patrol report high levels of frustration and burn out due to feeling overworked:
    • Because young/inexperienced patrollers aggressivly over-template, requiring work to be rechecked;
    • Because too few users choose to become patrollers
      • Because education about the patrolling process is difficult
      • Because optimizing a system for page patrol is a "Power User" job, requiring greater-than average computer savvy as well as (oftentimes) downloading of third party software

Hypotheses

  • Providing a native, easy-to-use interface for New Page Patrol will increase the number of users who choose to become patrollers, reducing workload
  • Providing a native, easy-to-use interface will help to establish better education about the process as is, resulting in lower "false positive" rates
  • Providing a native interface will allow future expansion and modification of the system to support different backend systems and logic screens
  • Providing a native, easy-to-use interface may prove to serve as an engagement point for mobile and tablet users, for whom editing is currently not feasible
  • Providing a native interface that utilizes positive messaging features will reduce new editor bite, thus promoting editor retention

Feature Requirements

  • Provide a list view of New Pages.
    • This list must be filterable.
  • Provide a pagable, easy-to-use, and intuitive "zoom" interface that allows page examination and tagging in situ
    • This interface must provide meta-data about the article
    • This interface must show the article in the interface
    • This interface must be pagable without leaving the interface
    • Ideally, the interface's "paging queue" will be smart and modify itself according to behaviors of other patrollers and their work.

User Experience: List Interface

User Experience: Zoom Interface

Future Phases and Thoughts

I think we should aim for the following goals:

  • New users would be gradually taught to patrol correctly and could work with what they feel comfortable with, eventually graduating up to areas of additional difficulty
  • Includes automated systems to aid in patrolling
  • Includes a more crowd-sourced, moderation-queue like process
    • This will increase work-load overall, but probably decrease it per-user
  • Has multiple flags other than simply "patrolled" vs. "not patrolled"
  • Allows for the re-viewing and flagging of an the article in situ
  • Could easily be used on tablets and mobiles
    • Gesture support would be awesome

For initial phases of the implementation, the tool can work within the existing template/tag system by automatically adding templates to the article

Currently:

  • No way to tag an article for improvement but not mark it as patrolled. Is this even desired?