VisualEditor/Roadmap

From MediaWiki.org
Jump to: navigation, search

This is a quick set of bullets on the current and near-term work to make VisualEditor better. This is not set in stone, just an outline of our current thinking. Feedback, criticism and suggestions are welcome. See also the Editing Team's 2014-15 goals and the team's workboard on Phabricator.

VisualEditor-core VisualEditor-MediaWiki
Recently done
  • Blockquotes – Editors can create and edit <blockquote> paragraphs.
  • Consistent tool availability – Editors can edit sub-surfaces with only the appropriate tools for the context being made available, and others are blacklisted based on context. [1] [2] [3]
  • Tables – Editors can make basic table structure edits – insert a new table, add or remove one or more rows or columns, add, alter or remove a table's caption, and merge and un-merge table cells, and set cells, rows and columns as a header or content.
  • File insertion via drag-and-drop – Editors can drag a text or HTML file into the editor to insert the contents. Note: Media file insertion in VisualEditor-MediaWiki is blocked on UploadWizard improvements.
  • Detailed context – Editors can see more context about parts of the page they are editing without having to open a dialog or inspector, like the target of a link or language setting.
  • Draggable content – Editors can drag-and-drop arbitrary content, rather than just media items.
  • Media items – Editors can replace one media item with another using the dialog.
  • Mobile VisualEditor for tablets – Editors using the mobile site on tablets can use VisualEditor to make basic edits just like on desktop.
  • Editing surface – Editors can see that HTML comments have been added to the document, and can see their content, edit, remove or add them.
  • Internet Explorer – Editors who use Internet Explorer v. 10 or above are able to use VisualEditor without incident.
  • Media items – Editors can replace one media item with another using the dialog.
  • Categories – Editors have understand more details about categories so they can able to alter them without confusion, indicating for categories which are hidden why they don't show up at the bottom of the page in the category box, and in the search suggestions that they are hidden, and for categories which are redirects as such in the search suggestions.
  • Media items – Editors can modify existing media items using each item's dialog, setting: their precise size, to default size, to full size, alt text; changing location (left/right/centre/none), type (thumb/frame/frameless/inline) and border; inserting new images at default size unless adjusted.
  • Page settings dialog – Editors can make or edit a redirect, and set and change the common behavioural magic words in the page settings dialog.
  • Links – Editors can notice if they're linking to redirects or disambiguation pages when adding or editing an existing link.
Working on right now
  • Editing surface – Editors using "input method editors" get a reliable, stable editing experience.
    • YesY Done Major re-write of how input is handled to avoid pawns being inserted.
    • YesY Done Major re-write of how cursoring is handled to avoid snowmen being inserted.
    • YesY Done Build a testing framework for IMEs to understand their various input types.
    • In progress In progress Re-work how inserting text via the keyboard interacts with special kinds of content that the browser can't know about, like references.
    • In progress In progress Add on a case-by-case basis work-arounds for each language and each IME.
  • Indentable paragraphs – Editors can indent paragraphs if they wish, which are then transparently wrapped in <blockquote> tags as needed.
  • Citations – Editors can get their citations auto-filled in for them when they just paste a link or ISBN into a box.
    • In progress In progress Inserting the first citation on a page inserts a references list at the bottom of the page automatically.
    • In progress In progress TemplateData's parameter "type" support feature is used to provide rich helpers on parameters (e.g. date picker, link selector, image finder, …)
    • In progress In progress Provide a look-up service system and letting TemplateData hook into it (so the community can specify what parts of their templates get filled in)
    • YesY Done Deploy Zotero-based citoid for the look-up service portion
    • In progress In progress Integrate citoid client into VisualEditor
    • Integrate citoid client into WikiEditor
    • Discussions with Wikidata about structured reference storage
    • Discussions with COIBot maintainers about merging efforts
  • Media items – Editors can easily find images with a bigger, more pleasing design for finding items.
  • Table of Contents – Editors can see the Table of Contents as they edit.
    • YesY Done Table of Contents updates live as new headings are added and existing ones altered or removed
    • In progress In progress Table of Contents appears in default position, or where a __TOC__ is placed, and can be dragged to a new position if desired
  • Categories – Editors have more information about the different kinds of categories in the dialog so they're able to alter them without confusion.
    • In progress In progress Editors can drag a category to a new position to re-order them.
    • Show that a page inherits a category from a transclusion, so it shows in the bottom of the page in the category box, but isn't editable in-page.
  • References – Editors can set options like column width and list styling for reference lists in the dialog, and do not have to use {{reflist}} templates or the like.
    • In progress In progress This will involve extending the <references /> tag in the Cite extension to add these much-used but unsupported features.
  • Page settings dialog – Editors can set the title to display in a different form to the page name (using {{DISPLAYTITLE:…}}).
    • YesY Done … as wikitext.
    • … as a rich editable surface (blocked on Parsoid changes?).
    • … and it updates instantly, not just when you save the page.
Next up
  • Table content drag-and-drop – Editors can drag a column or row of a table to another position.
  • Progressive feature loading – Editors can edit the page immediately as soon as they click "edit", without loading the whole of the editing software; as they try to edit new types of content, they become available "just in time".[4]
    • Blocked on a plug-in architecture for VisualEditor's core modules [5]; blocked on only loading said modules as needed [6]
  • Nested surfaces – Editors can edit one or more surfaces within another surface with a shared toolbar and the nesting of content within content e.g. for template fields.
  • Multi-surface editing – Editors can edit the caption of an image or the contents of a reference directly inside the page they appear in, rather than by opening a dialog. [7]
  • Consistent transactions and wikitext – Editors can edit and save pages with the created wikitext being applied consistent, so that the wikitext shows up cleanly and transactions are as simple as possible. [8]
  • Safe transactions – Editors can do any edit and know that it won't break the editor, but at worst will just not work, never leaving the editor in an inconsistent state. [9] [10]
  • Scroll actions into view – Editors get the surface scrolling to the place where their action occurred as soon as they make them, such as "paste", "insert" or "undo" [11] [12]
  • More reliable typing – Editors get a more reliable typing experience by using browsers' native "MutationObserver" systems in place of the automatic polling in SurfaceObserver [13]
  • No hidden links, and better wikitext – Editors can make changes that are interpreted to what they meant rather than what they did, with the system cleaning up after them by e.g. removing hidden links that are applied only to a space character, or a bold space between two words. [14]
    • Blocked on re-writing the converter system to work bottom-up rather than top-down. [15]
  • Real-time collaboration – Editors can edit using VisualEditor with real-time collaboration, seeing each others' edits as they are made and being able to comment and alter them.
    • Blocked on finishing a series of reforms to allow operational transformation to always work consistent for all edits [16]; blocked on a simple system to consistently share the internal model inside VisualEditor between instances. [17]; blocked on a number of outstanding fixes in the transaction and converter systems [18] [19] [20] [21] [22] [23]
    • Note: This will not be available inside VisualEditor-MediaWiki as that will need significantly more work before it is available.
  • Media items – Editors can make changes to media items' display type to use standard 'styles' for consistency.
    • Redesign the media dialog, splitting the "style" and "specific" changes into groups, and making the common tasks more prominent
  • Mode switching – Editors can switching back and forth from wikitext to VisualEditor mode and back without loss of wikitext structure (so avoiding "dirty diffs").
    • More engineering research required on how to best achieve this.
  • Progressive edit loading – Editors can edit the page immediately as soon as they click "edit", without loading the whole page into the editor; as they try to edit new paragraphs, they become available "just in time".
    • Blocked on being able to load page-level items (like references) independently of the rest of the page; blocked on support from the Parsoid service.
  • Partial-page editing – Editors can edit bits of the page without needing to load the whole thing, making starting an edit much faster. [24]
    • Blocked on being able to load page-level items (like references) independently of the rest of the page; blocked on segments of the document being treated as proper portions of the document rather than faked sections [25] ; blocked on re-unifying the content of the page with the meta-data about the content. [26] [27]
  • In-flight document saving – Editors can edit long pages, making as many changes as they wish, and save the server-staged document near-instantly when they're done.
    • Blocked on only sending changed parts of the document back to the server [28]; blocked on support from the Parsoid service.
  • Mobile editing of MediaWiki features for tablets – Editors can do (almost?) anything they do on the desktop on mobile tablets as well.
    • Editors can add, alter or remove images, templates, references and reference lists.
  • Transclusions – Editors can easily and simply use non-template transclusions like variables and parser functions in the transclusion dialog, including in-context help.
  • Seeing red-linked images – Editors can see and fix links to images that aren't real (e.g. they were deleted and so the link doesn't work any more).
    • Blocked on dealing with universal types like mw:Error, mw:ExpandedAttrs, and mw:Placeholder inside VisualEditor [29]

Design/product work needed before it can be worked on

  • Character inserter – Editors can easily and swiftly insert characters they don't have available to them but need frequently (e.g. accents) or occasionally (e.g. mathematical symbols).
    • Needs follow-up design concepts based on the feedback from the first iteration of the inserter.
  • Editing surface – Editors can see the exact same view of items inside VisualEditor as in read mode, and can switch into a mode where some of the content is munged when they need to rather than have it on all the time.
    • Needs investigation of feasibility and an agreed design concept.
  • Visual histories – Editors can see changes to a page in visual HTML form, and play back the page's history, if the integration supports that.
    • Needs an agreed design concept.
  • Language tools – Editors can mark a block-level item (e.g. a list or a table) as having a different HTML content language or direction, e.g. <ol dir="rtl">* Hello</ol>.
    • Requires a block-level editing interaction concept
  • Editing surface – Editors can see a placeholder for templates that generate no visible output, and can interact with them to edit or remove them.
    • Needs an agreed design concept.
  • Galleries – Editors can add or alter a media gallery, consistently with the media item inserting and editing system, letting them set captions for each item, and gallery-level properties like display type.
    • Needs an agreed design concept.
  • Real-time collaboration in a MediaWiki context – Editors can edit using VisualEditor-MediaWiki with real-time collaboration, seeing each others' edits as they are made and being able to comment and alter them.
    • Needs major product decisions on identifying what problems this is trying to solve, and thus clarify open questions like multiple parallel vs. only one edit session, attribution of edits, nature of saving, openness of editing sessions, …
  • Visual histories in a MediaWiki context – Editors can see changes to a page in visual HTML (rather than source wikitext) form, and play back the page's history, without needing to know wikitext.
    • Needs an agreed design concept.
  • Edit notices – Editors can set and alter page-specific edit notices in-page, through the page settings dialog or similar.
    • Needs an agreed design concept; will involve extending MediaWiki's edit-notice system to add this much-used but unsupported feature (currently done with a parser function).
Blocked items
  • Remove buttons for nodes – Editors can easily remove any block node by clicking a "remove" button in their context menu.
    • N Blocked on ability for tools to set their own descriptions
  • Media items – Editors can make basic modifications to existing media items (move left, move right) without using the dialog, using a button in the surface instead.
    • N Blocked on ability for tools to set their own descriptions

Media items – Editors can modify existing media items using each item's dialog.

    • N Blocked on Parsoid support Set an item's size in "upright" terms
    • N Blocked on Parsoid support Set an item's link over-ride (with warning text about not doing this unless the image is PD or equivalent?)
    • Set an item's vertical alignment
  • Upload – Editors can upload a file to Commons and use it in the page without leaving the edit, including starting it with "drag-and-drop".
    • Requires some significant preparatory work from the Multimedia team; VisualEditor-end work mostly done.
  • Templates – Editors can edit templates' parameters as rich content when appropriate
    • Requires major work by the Parsoid team, currently underway.
  • Language variants – Editors in languages with automatic language conversion (e.g. Chinese or Kazakh) can see, add, alter and remove words and phrases' hinting as to how they should be converted.
    • Requires major work by the Parsoid team, currently underway.
  • Translate-able content – Editors of pages which use the Translate extension to provide parallel, translated texts
    • Requires very major work from the Language Engineering; not a priority.
  • Media searching – Editors can filter their searches for media items by translatable tag, so non-English editors can find items in their language, and possibly media type/length/etc.
    • Likely to be solved by the Multimedia team's efforts on structured data for Commons.
  • Natural template editing – Editors can edit those fields of a template which display directly without editing the template, but instead just by clicking into it in the main surface and editing away. [30]
    • Blocked on inventing a technology to make this possible in (?) Parsoid.
Lower-priority backlog
  • Internet Explorer – Editors who use Internet Explorer v. 9 are able to use VisualEditor without incident.
  • Definition lists – Editors can create, alter and re-structure definition lists (; Item : Definition) in their edits.
  • Draggable dialogs – Editors can drag on the title bar of a dialog to move it out of the way of content that it obscures, e.g. when writing an edit summary.
  • In-line HTML styling – Editors can set some text as having an arbitrary CSS style, like making the text red or having a certain font.
  • Table HTML styling – Editors can set an arbitrary CSS style on a table, a row, a column or a cell.
  • Layout HTML editing – Editors can insert or edit "layout" HTML items like line breaks (<br />s), horizontal rules (<hr />s), content blocks (<div>s), etc.
  • Release for third-party non-MediaWiki users – Developers of non-MediaWiki CMSes and other software can easily use and extend VisualEditor for their own applications.
  • Table styles – Editors can change general table styles (e.g. class="wikitable" or switching on sortable columns).
  • MediaWiki integration – Editors get a consistent offering of both "edit" tabs in all MW contexts, not just at the top of the page (e.g. in the diff viewer).
  • MediaWiki integration – Editors get a single "edit" tab with options to use either VisualEditor or wikitext editing mode, with a consistent user experience whichever they use.
  • Language links – Editors can add, edit or remove language links, either locally or on Wikidata.
  • ProofreadPage integration – Editors on Pages can use VisualEditor side-by-side with the page they are proofreading.
  • Code block editing – Editors can insert or edit <syntaxhighlight> blocks inside VisualEditor.
  • Release for third-party MediaWiki users – System administrators of third party MediaWiki installations can easily install and use VisualEditor on their wiki without needing support.

Notes:[edit | edit source]

  • This doesn't cover (anything like) all work of the developers; it misses out work on performance and stability, trivial changes, documentation, packaging, cross-team support, helping users, architectural changes without a user-facing component, …
  • Code should be shipped when ready[1], not to meet some arbitrary deadline.
  • Items are worked on in parallel and just because it's at the top of the currently-being-worked-on list doesn't mean it will ship first[2].
  • This list is about functionality, not deployment; however, some items here implicitly block useful deployment.
  • Suggestions about re-prioritising, changing the scope, and others are welcome!
  1. …which means it fulfils the targeted needs of the user, not that it's perfect in every way or serves every user's desires.
  2. or that it's more important.

Metrics[edit | edit source]

In progress

  • Load performance – Editors get a blinking cursor ready for them to edit very quickly and smoothly after pressing "edit".
    • No significant changes are expected in Q1.
    • Later planned changes include having read mode HTML being from Parsoid and loading that locally (anticipated ~Q4).
    • Baseline value: 3s 50%ile, 5s 75%ile, 25s 99%ile
    • Plausible end-Q1 value: 3s 50%ile, 5s 75%ile, 25s 99%ile
    • Plausible end-Q4 value: 2s 50%ile, 4s 75%ile, 20s 99%ile – Stretch: 1s 50%ile, 2s 75%ile, 15s 99%ile
  • Save performance – Editors get a readable page ready for them to continuing browsing very quickly and smoothly after pressing "save".
    • Planned changes include compressing save data before submitted for save (anticipated Q1)
    • Late planned changes include asynchronous save once HTML has been sent (Q3).
    • Baseline value: 4s 50%ile, 8s 75%ile, 15s 99%ile
    • Plausible end-Q1 value: 3s 50%ile, 6s 75%ile, 15s 99%ile
    • Plausible end-Q4 value: 3s 50%ile, 5s 75%ile, 12s 99%ile – Stretch: 2s 50%ile, 4s 75%ile, 10s 99%ile
  • Per-edit adoption – Editors choose to use VisualEditor over the wikitext editor for a %age of their main namespace edits.
    • No significant changes are expected in Q1.
    • Later planned changes include two-way switching between VisualEditor and wikitext editing (anticipated Q2), a consistent user experience between VisualEditor and wikitext editing (anticipated Q3), and a single edit tab providing both VisualEditor and wikitext editing (anticipated Q4).
    • Baseline value: 35% IPs, 20% post-default users, 4% pre-default users
    • Plausible end-Q1 value: 35% IPs, 20% post-default users, 4% pre-default users
    • Plausible end-Q4 value: 45% IPs, 25% post-default users, 5% pre-default users – Stretch: 65% IPs, 30% post-default users, 6% pre-default users

Archive of less-recently completed items[edit | edit source]

  • Toolbar – Editors now have all text styling functions collapsed into a single menu, because most edits don't involve changing the style of words very much.
  • Editing surface – Editors get much the same view of items in VisualEditor as in read mode, and block slugs ("extra whitespace") are not as large as real new lines until needed.
  • Editing surface – Editors can open a node's dialog by double-clicking on the node, or pressing "enter" when it is selected.
  • Templates – Editors can use a much-simplified transclusion dialog (and the ability to switch back and forth to the "advanced" one) to insert and edit templates.
  • Citations – Editors can use a button in the toolbar that launches a small list of citation templates, to easily and quickly insert new citations in the correct format.
  • Editing surface – Editors see red links for links to pages which do not exist, and light-blue links with an icon for external links.
  • Formulæ – All editors can edit formulæ on the page, without having to opt in to a Beta Feature.
  • Language tools – Editors can opt in to a Beta Feature that lets them set a selection of text as having a different HTML content language or direction, e.g. <span dir="rtl">Hello</span>.