When Vector skin became the default, users continued to have preferences for other skins. That went extremely well, and did not negatively impact editing. (I'll note that there were comparatively few bugs reported when Vector became default, and none of them prevented people from doing *necessary* tasks, like referencing.) This was the first major all-sites deployment of new software in many years, and it was very successful. There are those who say it wasn't successful because so many people chose not to switch; however, there's been no research I'm aware of to figure out why people chose not to do so. (Myself, I still use monobook on enwiki because it opens large pages much faster, but I use Vector elsewhere.)
The logic that people are only avoiding VE because they hate change is faulty. They're not using it because it isn't fully functional yet. They're not using it because it can't handle edits that experienced users make dozens of times a day yet. And yes, some of them aren't using it because they hate change. But most of them have very good reasons not to want to debug software that was far too buggy to have been deployed as default. No explanation has ever been forthcoming of how we went from an alpha release that was so feature-deficient nobody was testing it to a default beta deployment with major features (i.e., referencing and templates) that were almost completely untested by those who were expected to use it. The result was not "many eyes find all bugs"....it was "most eyes stopped looking, and those that stayed have found a whole pile of bugs, some of which should have been caught before the software became default". This felt a lot like the kinds of releases the WMF did back in the 2000s when there were no resources at all. It's not really what people expect from an Engineering department with over 100 employees and a budget of $17 million. People have already written hacks to prevent the tabs from showing up. The majority of edits by people registered after July 1 are now being done using "edit source", as are IP editors; over 90% of edits by experienced editors are using source editing, and there are questions about even the 10% being done on VE because so many are testing it right now. I'm not going to go so far as to say we should go back to source editing as default; that decision is being made indirectly by every group that is editing. Please pay attention to these red flags. I think some goodwill can be done by reinstating the opt-out preference. It's happening anyway. A note about the bugzilla: there's a reason why people are commenting there. They're being ignored in every other venue, and WP:CONEXCEPT (exceptions to project consensus)[1] has been invoked in regard to this. Therefore the correct place to appeal the decision is with the community of Wikimedia developers and (maybe) WMF staff, and one of the most effective ways of getting the eyes of both groups is to launch and comment on Bugzillas. Risker [1] https://en.wikipedia.org/wiki/Wikipedia:CONEXCEPT#Decisions_not_subject_to_consensus_of_editors On 22 July 2013 12:51, Tyler Romeo <[email protected]> wrote: > On that note, I think we should start forcing MediaWiki developers to use > Eclipse for PHP. Of course some people prefer using just a text editor, but > I'm sure no matter what it'll be more efficient in Eclipse, and if it isn't > we can just have Eclipse fix it. > > Seriously, though, I understand why the VE team might want to force > everybody to use VE, because otherwise users just "give up", so to say, > because they don't like the change. But some people really just don't want > to use VE, and I don't see why we should be forcing that upon them, > especially if the community consensus is to add the user option back. > > > *-- * > *Tyler Romeo* > Stevens Institute of Technology, Class of 2016 > Major in Computer Science > www.whizkidztech.com | [email protected] > > > On Mon, Jul 22, 2013 at 12:47 PM, C. Scott Ananian > <[email protected]>wrote: > > > 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.htmlwillbemet > 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 > > > _______________________________________________ > Wikitech-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
