On Mon, Jul 22, 2013 at 12:37 PM, Bartosz Dziewoński <matma.rex(a)gmail.com>wrote;wrote:
Just to accomodate people too lazy to chase through two links, in the
interests of having a synchronized discussion I'm cut and pasting from the
rationale given there:
{{Ping|Adam Cuerden}} Thanks for the thoughtful note. Some initial thoughts
-- I'll jump in more when I can, but also pinging
[[User:Okeyes
(WMF)|Oliver]] and [[User:Whatamidoing (WMF)|Whatamidoing]] who can help
with clarifications.
Our overall concern, and the reason we did not offer a preference, is that
"out of sight, out of mind" makes it very
hard for us to address the kinds
of efficiency issues you mention. It makes it too easy for us to ignore the
needs of users such as yourself as we improve VisualEditor. I actually do
''not'' agree that the kind of task you describe needs to be inherently
less efficient in VisualEditor, but I do agree that it'll take us a while
to make VisualEditor a good tool for that case.
I really would like us to be increasingly scientific and systematic about
this -- enumerate the types of tasks that users
perform frequently, and
measure the relative task performance in VisualEditor and source mode. I
will personally not be satisfied with the product until we can exceed task
efficiency in the vast majority of cases.
If you've followed the deployment a bit, you'll note that even this week,
we've made some changes to improve task efficiency
for templates and
images. Inserting an image used to take two clicks; now it takes one.
Filling in a template used to require manually selecting all parameters;
now required parameters (as defined by templatedata) are pre-selected, and
it takes a single click to add a new parameter. Etc.
So, in other words, we ''do'' care, a lot, about making this not only an
easy-to-use tool, but an efficient one. Many of us at
WMF are Wikipedians,
and we hate tools that don't do the job. Where VisualEditor doesn't get the
job done, we need to know. Our hypothesis is that we ''can'' build a
tool
that's both powerful and discoverable, not just a nice UI for newbies.
And to be honest, we made the mistake of offering a quick and easy "out of
sight, out of mind" preference before. When we
did the Vector skin rollout
in 2010, we offered a trivial "Take me back to the old look" option --
which lots of users took. Almost any change to a user interface [
http://www.designstaff.org/articles/how-to-avoid-mitigate-change-aversion-2…
be met with resistance and objections]. As a recent non-WMF example,
did you see the reactions to Flickr's design change? I've rarely seen so
much hatemail for a company in one place.
By making it easy to switch back, we effectively created two generations of
users: the pre-Vector generation and the post-Vector
users. Pre-Vector
users, by and large, stayed with Monbook; post-Vector users stayed with
Vector. There may have been legitimate efficiency reasons to stay with
Monobook - things we could have improved in Vector, but didn't. In our
drive to increase usability, we didn't pay sufficient attention to the
needs of advanced users. And because of the "out of sight, out of mind"
effect, we didn't have to.
To avoid this effect, with VisualEditor, you can't make it disappear
completely without resorting to gadgets or user
scripts. You don't have to
use it, but we encourage you to give it a try every once in a while to see
the improvements and changes, and to point out those annoying bugs which we
should have long fixed and haven't. And to the extent that there are things
about the new default user experience that we have to fix to not interfere
with normal editing (the current section editing behavior is definitely
still not ideal), please keep us honest and remind us about it.
I hear you on the subject of muscle memory and confusing edit tabs. There
are a couple of things I'd say right now which may
help mitigate this issue
going forward, and I'd appreciate your suggestions as well.
1) We can reduce the issue by avoiding inconsistency between "Edit" and
"Edit source". I believe this is already on
[[User:Jdforrester
(WMF)|James']] agenda, and there was some community energy around this as
well on [[WP:VPT]]. What I mean here is that right now, some namespaces
still use wikitext by default. If those namespaces consistently had the tab
labeled "Edit source", visually scanning for the right tab to click would
be a lot easier. (Having VisualEditor on all Wikimedia projects, as it soon
will be, will also help with those consistency issues.)
2) This is more of a personal tip for you: To support muscle memory, we
ensured that VisualEditor does not take over the
existing keyboard shortcut
for editing in source mode. If you've never given keyboard shortcuts a try,
I strongly suggest it; they should work in all modern browsers. When you
mouse over the tab, it gives you the shortcut indicator. So, I can just
press Alt+Shift+E on any page to edit, and it will always edit in wikitext
mode (Alt+Shift+V will edit in VisualEditor).
Finally, on the earlier point of measuring task efficiency -- this is
something anyone can help with. We may do some
specific community outreach
around this, but any efforts to document "It takes me X steps/seconds to do
this in VisualEditor, Y steps/seconds in wikitext" helps ''a lot''.
It's
worth noting that VisualEditor has its own set of keyboard shortcuts, which
can help with common tasks such as linking (which I actually already find
faster in VE). And I do think tasks like updating image links should
ultimately be well-supported in VE (even if it's by means of plugins), so
we should start tracking these types of use cases in Bugzilla.
--[[User:Eloquence|Eloquence]][[User:Eloquence/CP|*]] 07:19, 17 July 2013
(UTC)
--
(
http://cscott.net)