< VisualEditor

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. The left-hand column deals with work items in the core VisualEditor software itself, which are usable by all others, and generally cover "how the editor works"; the right-hand column addresses work items in the MediaWiki-specific implementation of VisualEditor, only usable by those installing or using VisualEditor on a MediaWiki install, and generally cover "what the editor can do".

Last updated: 2017-03-20.

See also Special:MyLanguage/VisualEditor/Roadmap/Update 2016-06-23 for a prose over-view from June 2016.

VisualEditor-core VisualEditor-MediaWiki
Working on right now
  • Visual histories for stand-alone only – Editors can see changes to a page in visual HTML form, and play back the page's history, if the integration supports that.
  • Real-time collaboration for stand-alone only – 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. Currently working through a number of outstanding fixes in the transaction and converter systems ​​gerrit:114355 ​gerrit:148690 ​gerrit:114357 ​
    • Note: This will not be available inside VisualEditor-MediaWiki as that will need significantly more work before it is available there.
  • 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, , and a consistent offering of the/both "edit" tabs in all MW contexts, not just at the top of the page (e.g. in the diff viewer).
  • Wikitext source mode – Editors get a consistent, familiar interface through which they can edit wikitext or visually; See 2017 wikitext editor.
  • 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.
  • 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.
Stalled
  • Indentable paragraphs – Editors can indent paragraphs if they wish, which are then transparently wrapped in <blockquote> tags as needed.
  • 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".
    • Blocked on a plug-in architecture for VisualEditor's core modules ;
    • Blocked on only loading said modules as needed.
  • 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 some content directly inside the page they appear in, rather than by opening a dialogsuch as:
    • Yes Done The caption of an image
    • The content of a reference
  • Templates – Editors can add or alter a template transclusion, letting them set values for each parameter without knowing or seeing any wikitext.
    • … for narrowly-defined TemplateData 'typed' inputs with rich helpers on parameters (e.g. date picker, link selector, image finder, …).
    • … for general "rich text" editing, including sub-templates.
  • ProofreadPage integration – Editors on Pages can use VisualEditor side-by-side with the page they are proofreading.
  • Table of Contents – Editors can see the Table of Contents as they edit.
    • Yes 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
  • Citations – Inserting the first citation on a page inserts a references list at the bottom of the page automatically.
  • Page settings dialog – Editors can set the title to display in a different form to the page name (using {{DISPLAYTITLE:…}}) … as a rich editable surface (blocked on Parsoid changes?).
    • … and it updates instantly, not just when you save the page.
Next up
  • Consistent transactions and source – 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.
  • No hidden links, and better source – 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.
    • Blocked on re-writing the converter system to work bottom-up rather than top-down.
  • Remove buttons for nodes – Editors can easily remove any block node by clicking a "remove" button in their context menu.
  • Table content drag-and-drop – Editors can drag a column or row of a table to another position .
  • 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.
    • 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  ; blocked on re-unifying the content of the page with the meta-data about the content.
  • Partial document saving – Editors can edit long pages and their changes save very quickly because the software only sends up changed parts of the document back to the server ; blocked on support from the Parsoid service.
  • 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.
  • Mobile editing of MediaWiki features for tablets and phones – Editors can do (almost?) anything they do on the desktop on mobile tablets and phones as well.
    • Editors can add, alter or remove images, templates, references and reference lists.
  • Non-template transclusions – Editors can easily and simply use non-template transclusions like variables and parser functions in the transclusion dialog, including in-context help.

Design/product work needed before it can be worked on

  • 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.
  • 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
  • Definition lists – Editors can create, alter and re-structure definition lists (; Item : Definition) in their edits.
  • Media item standard styles – 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
  • 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).
  • Citations – Agreeing a future direction for citations in MediaWiki.
    • Discussions with Wikidata about structured reference storage
    • Discussions with COIBot maintainers about merging efforts
  • Categories – Editors can see that a page inherits a category from a transclusion, explaining how it shows in the bottom of the page in the category box, but isn't editable in-page.
  • 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 Parsing team, currently underway, and a design concept for how this can work (there's no known equivalent elsewhere from which we can learn).
Blocked items
  • Real-time collaboration for stand-alone only – 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.
  • 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
  • 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.
    • Blocked on inventing a technology to make this possible in (?) Parsoid.
Lower-priority backlog
  • 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 ("1.0") – Developers of non-MediaWiki CMSes and other software can easily use and extend VisualEditor for their own applications.
  • 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, …
  • Language links – Editors can add, edit or remove language links, either locally or on Wikidata.
  • Release for third-party MediaWiki users ("1.0") – System administrators of third party MediaWiki installations can easily install and use VisualEditor on their wiki without needing support.

See also the team's workboard on Phabricator.

Notes:

  • 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.
This article is issued from Mediawiki. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.