Erik Moeller | 24 Apr 2012 04:26
Picon
Gravatar

Editing surface/UX: Inline menus

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.
(Continue reading)

Adam Wight | 24 Apr 2012 10:54
Favicon

Re: Editing surface/UX: Inline menus

The fewest possible keystrokes is one worthy goal.  Adaptibility to
the user's preference is another, so if we wanted to support multiple
surfaces, the question becomes whether a vi- or bbs-style edit surface
would map well to an elaborate, visual toolbar edit surface.  It seems
reasonable to ask that editor plug-ins target a specific surface, but
you would definitely want the base editors to use the same api in each
case.  Luckily, the only real variability to plan for is how to feed
data and variables to a zoo of templates, which is sort of a generic
task and I believe can be contained in a single feature, eventually
merged into something like the WikiData initiative.

+1 for the wacky Inline Menu idea, it runs smooth at 2400 baud!
(S)eriously, that could almost serve as the SMS read-write gateway...

-Adam

erik <at> wikimedia.org:
> 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.
(Continue reading)

Christian Williams | 4 May 2012 22:49
Favicon

Re: Editing surface/UX: Inline menus

Wikia has hackathons every quarter or so and I once built a keyboard shortcut legend interface. It could either supplement the toolbars or stand on its own. I stress, this is a hack (not localized, not optimized, may not match your keyboard layout, might not work in your browser, etc). :)


To use the keyboard shortcuts, hold Ctl-Alt-[key]. To make text bold, use Ctl-Alt-B. If you hesitate for too long (holding only Ctl and Alt), the keyboard shortcuts legend will appear.

-Christian

On Apr 23, 2012, at 7:26 PM, Erik Moeller wrote:

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

--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate

_______________________________________________
Wikitext-l mailing list
Wikitext-l <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitext-l

_______________________________________________
Wikitext-l mailing list
Wikitext-l <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitext-l
Erik Moeller | 4 May 2012 23:11
Picon
Gravatar

Re: Editing surface/UX: Inline menus

On Fri, May 4, 2012 at 1:49 PM, Christian Williams
<christian <at> wikia-inc.com> wrote:
> Wikia has hackathons every quarter or so and I once built a keyboard
> shortcut legend interface. It could either supplement the toolbars or stand
> on its own. I stress, this is a hack (not localized, not optimized, may not
> match your keyboard layout, might not work in your browser, etc). :)

Definitely nifty! I like the affordance that it comes up if you're
hesitating for a long time, indicating that you've forgotten the
correct keyboard shortcut. :)

For VE, I think coming up with a single coherent & efficient
interaction model for completing some of these actions (e.g.
templates) will be important for it to gain acceptance among markup
editors (which in turn would help its continued evolution and
success).
--

-- 
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate

Gmane