How can we make the Visual Editor as efficient as, or more so than, wikitext editing when it comes to handling complex tasks like citations, templates, etc.? I know it's a bit early to talk about detailed aspects of the editing surface, but this may have some impact on architectural considerations for plug-ins and such, so I wanted to raise it on this list.
I don't think it's that much of a stretch goal to be more efficient than wikitext editing for a lot of common cases. For example, using complex templates manually is extremely inefficient, usually requiring a visit to a Template: namespace to read the template documentation, then apply the correct syntax and hope you're not making a typo in the process.
A few models:
* Wikia's current-generation visual editor offers panels with access to templates and categories, autocompleting as you type. If our goal is to create an editing surface that focuses on the content and gets out of the way (and IMO it should be), these types of panels add clutter which is likely unacceptable.
* Most RTE editing surfaces have toolbars, and some also add desktop application style pulldowns. The pulldown/toolbar combination has many known usability issues as software complexity increases -- they become cluttered, and keyboard shortcuts for anything but the stuff you use all the time become hard to remember.
* Code IDEs use a lot of hinting/autocompletion based on intelligence gathered from parsing the file you're editing, or any other files. This works well when what gets rendered in the editing surface is identical to what the user is typing. It's easy to auto-complete "myObject.getSomeStuff()", but it's less discoverable that I should start typing "{{Infobox country" to get a beautiful right-aligned table.
* vi is the best example of a powerful modal editor which can perform complex operations by essentially entering an in-editor command-line. It's also well-known to be very difficult to learn and master, in large part because its UX is so different from other applications people commonly use.
What other models ought to be/are being considered?
A couple of ideas:
== Inline menus ==
You could have a menu key, say Ctrl+I or, if we want to be more radical, a single compose key like "", which triggers an in-editor menu structure with associated keyboard hints.
E.g. if the user types <menu key>c, they see an overlay expanding at cursor position:
w - cite a website b - cite a book n - cite a newspaper j - cite a journal
So by typing: <menu key>cw, I could enter whichever the appropriate dialog is for citing a website (which itself could be rendered in-line if that gives us additional efficiency).
This type of system could intelligently trigger auto-completion where appropriate. Say "y" is the shortcut for category, and I type:
<menu key>yChurches in <cursor down><cursor down><cursor down><enter/tab>
to insert the category "Churches in the United Kingdom".
Or say "t" is short for template, so I could type:
<menu key>tInfobox a<cursor down><cursor down><enter/tab>
to insert the template "Infobox album" and invoke the appropriate dialog.
One could make such a feature discoverable by adding hints to the UI in appropriate places, e.g. if the most obvious invocation method is through a tabbed dialog, each dialog could have a small hint indicating how to quickly invoke it inline.
== Inline markup completion in visual mode ==
Another option would be to just intelligently detect use of existing markup, e.g. to magically complete "[[Category:Churches in" or "{{Cite web" or "{{Infobox co" even when in visual mode. This is beneficial for people who already know wiki markup, but is arguably less efficient/user-friendly than a menu/command structure that's designed from scratch to be maximally efficient, discoverable and intuitive. It also would tie us permanently to wiki markup.
What do you think? How can we make the visual editing surface maximally efficient for frequent use?
All best, Erik