Tectonic shift think tank/Tech requirements

From WikiEducator
Jump to: navigation, search

MediaWiki as core technology and ecosystem around it

Strengths

  • Skinnability for views, general hackability :-)
  • Community of users and developers; strong brand
  • Wide range of tools, extensions
  • Proven scalability & usefulness in all environments
  • Cross-browser compatibility
  • Standard dependencies (LAMP)
  • Sustainable development model (Wikimedia Foundation fundraising)
  • FLOSS
  • Existing capacities (Wikimedia, Wikia, WikiEducator & other communities)
  • History - remembers information
  • Text format is transparent
  • Namespaces distinguish policy, content, media, etc.
  • Templates allow content, structure, metadata, layout modularity
  • Active developer community, esp. extensions, bots, tools, JavaScripts
    • Exciting developments around structure, metadata
  • Access to shared media repository
  • UI localized
    • UI localization & customization through the wiki (MediaWiki: namespace)

Weaknesses

  • Interface not simple/audience-customizable enough
    • Training period about two weeks+
    • Including document history
    • People are used to MS Word
    • Specifically history, watchlist, diffs, templates, tables,...
  • Lack of social functionality -- better userpages, discussion, etc.
  • No online & offline capabilities (syncing)
  • Limited version control capabilities & concurrency control
  • No change annotation
  • No service-driven gated (completely non-public) development communities
    • Small group does initial work before open collaboration
  • No ability to save from Word into MediaWiki
  • Metadata closely tied to content
  • MW API incomplete (limited read/write features)
  • Backend format very limited
  • Heavyweight (should load quickly on low-end devices)n
  • Content addressability only to section level
  • Limited native RSS support
  • Lack of packaging, export & print functionality (PDF, IMS, etc.)
  • Limited mobile access (stylesheets for mob. devices, editing)
  • Some technologies immature
  • Quality assurance & heuristics; stable versions & endorsements
  • Limited documentation, mentoring/capacity building
  • Limited multimedia capabilities & interoperability

Requirements

Structured by:

Within each of these sections, we should identify functionality according to its a) significance for educational users (high vs. low impact), b) complexity of implementation.

Which features can and should we implement in 6 months, 12 months, 18-24 months?