On Mon, Jul 22, 2013 at 12:37 PM, Bartosz Dziewoński <[email protected]>wrote:
> The bug for that patch was just WONTFIXed, synchronizing information. > https://bugzilla.wikimedia.**org/show_bug.cgi?id=50929#c16<https://bugzilla.wikimedia.org/show_bug.cgi?id=50929#c16> 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-2012-04-24.htmlwill > 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) _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
