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.

Recently done[edit | edit source]

  1. Page settings dialog – Editors can make or edit a redirect, and set and change the common behavioural magic words in the page settings dialog.
  2. Links – Editors can notice if they're linking to redirects or disambiguation pages when adding or editing an existing link.
  3. 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.
  4. 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.
  5. Editing surface – Editors can open a node's dialog by double-clicking on the node, or pressing "enter" when it is selected.

Working on right now[edit | edit source]

  1. Citations – Editors can use a much-simplified transclusion dialog (and the ability to switch back and forth to the "advanced" one), and a button in the toolbar that launches a small list of citation templates, to easily and quickly insert new citations in the correct format without having to know what templates there are, or even what a template is. See design plans.
    • YesY Done Major re-write of transclusion dialog to enable changes
    • YesY Done Create a "simple" transclusion dialog (without support for non-template transclusions, multiple templates or content blocks), and let editors switch between "advanced" and "simple" transclusion dialogs and back (when possible)
    • YesY Done Simplifying the design of the transclusion dialog, especially the "simple" transclusion dialog
    • Doing... Using more TemplateData features in the transclusion dialog (order of parameters, required parameters, suggested parameters, parameter type support)
    • YesY Done Citation-inserting widget for the toolbar (not in the "Insert" menu) that gives some (locally-definable) options of citation templates
    • YesY Done Citations on opening/insert, open the simple transclusion dialog for the citation's template directly, without multiple clicks/confusion.
    • Doing... Inserting the first citation on a page inserts a references list at the bottom of the page automatically.
  2. Media items – Editors can modify existing media items using each item's dialog.
    • YesY Done Set precise size, set default size, restore to full size button, set alt text, change location (left/right/centre/none), change type (thumb/frame/frameless), set border, insert new images at default size unless adjusted
    • Doing... Enable editing of inline images; set link over-ride (with warning text about not doing this unless the image is PD or equivalent?); set size in "upright" terms
  3. 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
    • Doing... Table of Contents appears in default position, or where a __TOC__ is placed, and can be dragged to a new position if desired
  4. 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.
    • Doing... Re-work how inserting text via the keyboard interacts with special kinds of content that the browser can't know about, like references.
    • Doing... Add on a case-by-case basis work-arounds for each language and each IME.
  5. Categories – Editors have more information about the different kinds of categories in the dialog so they're able to alter them without confusion.
    • YesY Done 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.
    • Doing... Indicating for categories which are redirects that they are a little different in the search suggestions.
    • 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.
  6. Internet Explorer – Editors who use Internet Explorer v. 9 or above are able to use VisualEditor without incident.
    • Doing... Continued exploration of what doesn't work and why.
  7. Editing surface – Editors see red links for links to pages which do not exist, purple links for links to pages which are stubs, and light-blue links with an icon for external links.
    • YesY Done Building an item-hinting service as the cached HTML from Parsoid is not re-generated to have time-variant data in it.
    • YesY Done Using the hinting for links' existence status, showing them as red.
    • Use the hinting for links' stub status, showing them as purple.
    • Use the hinting for external links, showing them as light blue, with an icon if they are not interwiki links, and other icon if they are to an HTTPS server.

Next up[edit | edit source]

  1. Citations – Editors can get their citations auto-filled in for them when they just paste a link or ISBN into a box.
    • Requires building/re-using a look-up service system and letting TemplateData hook into it (so the community can specify what parts of their templates get filled in)
    • Planning to investigate Zotero for the look-up service portion
    • Discussions with Wikidata about structured reference storage
    • Discussions with COIBot maintainers about merging efforts
  2. Media items – Editors can make basic modifications to existing media items without using the dialog.
    • Some very basic operations, like "make right-aligned" for left-floated images and vice versa, have a button to change them in the editing surface.
  3. Formulæ – All editors can edit formulæ on the page, without having to opt in to a Beta Feature.
    • Some minor code clean-up needed before "graduation".
  4. 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.
    • This will involve extending the <references /> tag in the Cite extension to add these much-used but unsupported features.
  5. 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.

Design/product work needed before it can be worked on[edit | edit source]

  1. 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.
  2. Language tools – Editors can set a selection of text as having a different HTML content language or direction, e.g. <span dir="rtl">Hello</span>.
    • Needs some sane, lay language to describe what this is for initial release as a Beta Feature (possibly only to RTL environments where this is a common need?).
  3. Editing surface – Editors can see that HTML comments have been added to the document, and can see their content, edit, remove or add them.
    • Needs an agreed design concept.
  4. 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.
  5. 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.
  6. Tables – Editors can make basic table structure edits – insert a new table, add or remove a row or column, add, alter or remove a caption, and change general table styles (e.g. style="wikitable").
    • Needs an agreed design concept.
  7. Tables – Editors can make advanced table structure edits – merge or split a given table cell, set a given row or column as a header, set a column as sortable.
    • Needs an agreed design concept.
  8. Editing surface – Editors the exact same view of items in 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.
  9. 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
  10. Real-time collaboration – Editors can edit using VisualEditor in 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, …
  11. Visual histories – 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.
  12. 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 the edit-notice system to add this much-used but unsupported feature (currently done with a parser function).

Blocked items[edit | edit source]

  1. 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
  2. Templates – Editors can edit templates' parameters as rich content when appropriate
    • Requires major work by the Parsoid team, currently underway.
  3. 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.
  4. 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.
  5. 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.

Lower-priority backlog[edit | edit source]

This is not complete, just a quick place to see some asked-for features.

  1. 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).
  2. 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.
  3. Page settings dialog – Editors can set the title to display in a different form to the page name (using {{DISPLAYTITLE:…}}).
  4. Definition lists – Editors can create, alter and re-structure definition lists (; Item : Definition) in their edits.
  5. 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.
  6. Language links – Editors can add, edit or remove language links, either locally or on Wikidata.
  7. Draggable content – Editors can drag-and-drop arbitrary content, rather than just media items.
  8. Indentable paragraphs – Editors can indent paragraphs if they wish, which are then transparently wrapped in <blockquote> tags as needed.
  9. ProofreadPage integration – Editors on Pages can use VisualEditor side-by-side with the page they are proofreading.
  10. Code block editing – Editors can insert or edit <syntaxhighlight> blocks inside VisualEditor.
  11. Media items – Editors can replace one media item with another using the dialog.
  12. Transclusions – Editors can easily and simply use non-template transclusions like variables and parser functions in the transclusion dialog, including in-context help.
  13. 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.
  14. Table HTML styling – Editors can set an arbitrary CSS style on a table, a row, a column or a cell.
  15. Media items – Editors can replace one media item with another using the dialog.
  16. 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.
  17. 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.
  18. 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.

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.