A few weeks ago a car salesman came to us and said: 'You will get a new car.' We were able to do some test drives with it before it got delivered and noticed that the car still needed doors and a steering wheel, but the idea was great! We reported to the manufacturers that some essential things weren't ready, like the doors, safety bumbers and steering wheel and the manufacturers said that they will make sure that that will be ready when the car is delivered. They also said that in a month time the car will be delivered, and we said - seeing the car - that the timeline is too short in regards with the things that needed repair.
In the past week we got the notice that the car will be delivered this week. Again we did a full check, and while a lot of things were changed, still our reported essential things weren't ready. When we asked about this, we got a car salesman who tried to sell the car even harder and pushed as much as he could to sell the car. We all together discussed the situation and came to the conclusion that the car would damage the people and damage the road, and that local people afterwards can solve the problems what the car causes. The onliest thing we good do, for the sake of the people and the roads, is to refuse to receive the car. When that came clear to car manufacturer, they started to threaten us, that we must use it, no matter if it caused many damage or not.
The car salesman told us in the mean while that the delivery is delayed for two days and that the car for 5 days only should be used by adult users and later children may also use it. He also told us that the main reason to deliver the car too early was because of that the manufacturer made for himself a too short time schedule to get it finished, it hired its personnel for a too short time and that it shortly after would go produce something else, instead of delivering a fully functional car.
When other people heard about the this story and the worse policies of the manufacturer, they got angry as they think that the safety and health of the local people and environment are more important than the goal of the manufacturer, while the manufacturer does not respect that.
---------------------------------
This story is in fact the story what happened on the Dutch Wikipedia in the past weeks, the car is the visual editor, the manufacturer is WMF, the salesman is the liaisons hired by WMF. In the past days the Dutch community held a voting that very clear explained what the situation is, what the problems are and asked the community if they considered the issues of the visual editor as a problem that needs to be fixed first or that the visual editor should be launched already.
About 80% of the users is for delaying the visual editor as this software is **not** ready and causes too many problems in articles. Among the 20% of users were also users who dislike the visual editor completely and do not like it to be deployed at all.
In general the Dutch community likes the idea of getting an visual editor as they like the idea that (new) inexperienced users will be able to edit the articles, but at the moment it is too soon as the software is not ready.
Some reactions I have seen (roughly translated): * Seems to buggy. The WMF has product managers... If managers can be paid, why not pay programmers to do their work properly? * A worse product from the developers. If they do something, they must do that in a good way. * Not yet stable. * Multiple times crashed with the visual editor. * Switch off until all problems have been solved. Wikipedia has no need for its own OV-chipkaart (Dutch card to travel with public transport with so many bugs with the launch): something that is finished half, not been tested sufficiently and still pushed through your throat. Njet ! * First the teething troubles out * It's a very good alpha, but it should never have been launched outside of a test deployment. ( https://en.wikipedia.org/wiki/Software_release_life_cycle#Alpha )
Conclusion: if software is launched for everyone, communities want a finished product. If not it is respect-less for local communities who daily do the actual work: writing, updating and improving articles. Communities want respect and taken serious. The current communication wasn't that, it was mainly one way communication as WMF doesn't listed to our concerns. At least since 2007 there are complaints about the communication of WMF, sure you are trying to improve, but hiring liaisons but not listing yourselves to what communities have to say is still a problem.
This is not about small things, it is about damaging articles due software that doesn't understand all wikisyntax. We have these problems black on white but we are ignored.
We care very much for the articles in Wikipedia, we explained again our problems today to WMF, and instead of being listened to us we got threatened.
Is that the way how the Wikimedia Foundation works? Forcing things whatever it takes?
Romaine
Hello Romaine,
Speaking only for myself, I appreciate detailed feedback like this. Could you link to the local votes and today's discussion?
SJ
Hi,
I found the vote to be a poll here: http://nl.wikipedia.org/wiki/Wikipedia:Opinielokaal#Tijdelijk_uitschakelen_v... (some 50 people voted in favor of hiding the visual editor from all editors). Romaine seems (I only scanned it quickly) to have summarized the gist of the atmosphere correctly. To be totally clear: the poll is to make the visual editor *invisible*, with an opt-in for testing purposes. I am assuming this was to be achieved through either not rolling it out on nlwiki, or through js/css.
I must say I find especially this email very unspecific with regards to what would exactly be the problems. The poll gives more specific examples (although I myself don't really agree this weighs against the advantages, clearly for many they are significant enough).
Best, Lodewijk
2013/7/22 Samuel Klein meta.sj@gmail.com
Hello Romaine,
Speaking only for myself, I appreciate detailed feedback like this. Could you link to the local votes and today's discussion?
SJ
Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Lodewijk wrote:
To be totally clear: the poll is to make the visual editor *invisible*, with an opt-in for testing purposes. I am assuming this was to be achieved through either not rolling it out on nlwiki, or through js/css.
It's incredibly frustrating and upsetting that VisualEditor already has this functionality built in to it.
When VisualEditor was first introduced on the English Wikipedia, this was the behavior: it was completely opt-in based on a user preference in Special:Preferences. This user preference was subsequently hidden in order to force users to either try VisualEditor or add additional JavaScript via an unsupported JavaScript gadget to disable VisualEditor altogether. This has further eroded both community support for VisualEditor and trust between the Wikimedia Foundation and editors.
There's an active discussion on wikitech-l about this.
MZMcBride
It seems there was a problem in what the definition of success is. For the WMF success was to deploy the VE according to the plan and budget and to reach certain usage percentage. For the community it was a different kind of metric, maybe a more thoroughly tested product or a slower and progressive deployment?
These kinds of misunderstandings are not uncommon, and no bad faith or negligence should be assumed from either side: http://www.cio.com/article/440721/Common_Project_Management_Metrics_Doom_IT_...
If the deployment had been delayed or slowed down, the WMF would have considered it a failure according to their metrics, but maybe the comunity would had taken it better according to theirs...
Micru
On Mon, Jul 22, 2013 at 4:29 PM, MZMcBride z@mzmcbride.com wrote:
Lodewijk wrote:
To be totally clear: the poll is to make the visual editor *invisible*, with an opt-in for testing purposes. I am assuming this was to be achieved through either not rolling it out on nlwiki, or through js/css.
It's incredibly frustrating and upsetting that VisualEditor already has this functionality built in to it.
When VisualEditor was first introduced on the English Wikipedia, this was the behavior: it was completely opt-in based on a user preference in Special:Preferences. This user preference was subsequently hidden in order to force users to either try VisualEditor or add additional JavaScript via an unsupported JavaScript gadget to disable VisualEditor altogether. This has further eroded both community support for VisualEditor and trust between the Wikimedia Foundation and editors.
There's an active discussion on wikitech-l about this.
MZMcBride
Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On 23 July 2013 07:10, David Cuenca dacuetu@gmail.com wrote:
It seems there was a problem in what the definition of success is. For the WMF success was to deploy the VE according to the plan and budget and to reach certain usage percentage. For the community it was a different kind of metric, maybe a more thoroughly tested product or a slower and progressive deployment?
These kinds of misunderstandings are not uncommon, and no bad faith or negligence should be assumed from either side:
http://www.cio.com/article/440721/Common_Project_Management_Metrics_Doom_IT_...
If the deployment had been delayed or slowed down, the WMF would have considered it a failure according to their metrics, but maybe the comunity would had taken it better according to theirs...
Micru
I believe this is a pretty accurate analysis.
The concern is not about the validity of the Visual Editor project, or the quality of the work being done, but about the deployment process. Unfortunately, the rollout schedule for the visual editor was determined by the WMF senior management months and months ago. The "1 July defaut for en.wp" deadline was set in stone independently of the status/stability of the software, merely to meet a self-set and arbitrary reporting deadline. Presumably this is the same for the rest of the rollout schedule too. The WMF engineering department have been criticised for delays in the past so I presume the management decided to set a firm deadline in order to avoid this critisim being made again. Unfortunately this opens them up for justifiable criticism of releasing unfinished software. I feel very sorry for the developers and liaison staff who have to respond to the community's frustrations - they're doing the best they can under the circumstances that have been forced on them - crushed between a legitimately frustrated community an immovable management.
I recall back to the "Usability Initiative" and their designing of the "Vector" skin. What that team did was to measure the retention rate of registered wikimedians who were using the opt-in Beta: http://usability.wikimedia.org/wiki/Beta_Feedback_Survey If I recall correctly, every time they hit 80% retention then they would push the system out to a new community, add new features, or make the opt-in system more prominent - and respond to the new issues that subsequently arose. I thought that this was an excellent method of steadily increasing the pool of testers and building trust.
-Liam
wittylama.com Peace, love & metadata
On Mon, Jul 22, 2013 at 5:43 PM, Liam Wyatt liamwyatt@gmail.com wrote:
The concern is not about the validity of the Visual Editor project, or the quality of the work being done, but about the deployment process. Unfortunately, the rollout schedule for the visual editor was determined by the WMF senior management months and months ago. The "1 July defaut for en.wp" deadline was set in stone independently of the status/stability of the software, merely to meet a self-set and arbitrary reporting deadline.
That's an inaccurate characterization, Liam. The original deadline was negotiated with the team (although James only joined as PM in May), and the launch on July 1 by en.wp was also done on recommendation of the team (as were other controversial decisions, e.g. not to provide a disable switch). If the team had said "We need X amount more time to meet Y objectives", we would have moved the launch.
The deadline was not a simplistic "We will go live by X date no matter what", but driven both by the scope of functionality we needed to deliver (e.g. template editing, reference insertion), critical blockers (e.g. dirty diffs, performance), and the date we needed to deliver it by. Based on these three variables, we decided to go forward. Many urgent issues have been fixed quickly since the launch.
I am not saying this to pass the buck, but to simply state that we're in this together. If people on the team felt pressured to do something they think is wrong, they would not have trouble saying so. :-) Instead, what I've been hearing from the team is "It's great to finally have a product out in the world and see real usage and real feedback".
Since the launch, many many new issues have been reported and fixed. Many of the main concerns which are still lingering (e.g. "increased JS footprint") have been fully resolved (VE adds 2.6KB to JS footprint until used). Others (e.g. users accidentally typing wikitext into VE) have been partially addressed.
A lot of things that users report or experience as bugs are almost unavoidable aspects of the introduction of a new editing system. The occasional confusion between the two modes is an example of that. As are the following:
- Introducing a visual editor means that people will do, well, visual editing. That means they may be more likely to make a certain category of mistake (e.g. applying inappropriate formatting, or removing a footnote), and less likely to make another category of mistake (breaking markup completely). It may be frustrating to look at diffs where people do things that they'd never do in markup mode, but it's to some extent unavoidable.
- The uses to which templates are put are truly mindboggling. For example, a route-map template for the Circle Line of the London Underground looks like this:
https://en.wikipedia.org/w/index.php?title=Template:Circle_Line_RDT&acti...
The template for football infoboxes accepts parameters that dynamically render images of football shirts in specified colors:
https://en.wikipedia.org/wiki/Template:Infobox_football_club
Needless to say, these don't look particularly great when run through the new parser, and I'm not especially embarrassed about that.
The number of different citation templates and "standards" that co-exist in a single wiki is equally boggling. Sometimes <ref> tags exist inside a template, sometimes outside. Sometimes {{#tag:ref}} is used instead of <ref>. Etc.
The notion that any VisualEditor would, at launch or soon thereafter, be able to provide an intuitive editing experience for this entire base of content is insane. Nor is it sane to strive for making those types of templates and constructions all equally workable.
Rather, we need to collectively figure out what a discoverable, intuitive user experience should look like. Should subway maps really be constructed from templates like {{BS8-2}}? :-) If we were to use a modern, intuitive design approach for this problem, what would the solution look like? Probably we need to think in the direction of more flexible tools for creating and editing vector graphics.
We're not going to solve these challenges if we lock away VisualEditor into some kind of laboratory and work in waterfall mode for another year. We have to make improvements every day, and get them into production every week, in order to find solutions that make sense.
That's why it's the right decision to get VisualEditor out there now, and to continue to improve it, and that's why I would encourage everyone to not take the easy way out and hide it from their experience, but to keep hammering at it, keep reporting issues, and help us make it the best editing experience it can be.
VisualEditor is emphatically *not* intended to simply be a "nice way for newbies to edit articles". It's intended to become the best collaborative editor for the web, for new users and power users alike. We've still got a long way to go, but we're not turning back.
Erik -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation
Erik Moeller wrote:
We're not going to solve these challenges if we lock away VisualEditor into some kind of laboratory and work in waterfall mode for another year. We have to make improvements every day, and get them into production every week, in order to find solutions that make sense.
That's why it's the right decision to get VisualEditor out there now, and to continue to improve it, and that's why I would encourage everyone to not take the easy way out and hide it from their experience, but to keep hammering at it, keep reporting issues, and help us make it the best editing experience it can be.
VisualEditor is emphatically *not* intended to simply be a "nice way for newbies to edit articles". It's intended to become the best collaborative editor for the web, for new users and power users alike. We've still got a long way to go, but we're not turning back.
I wonder what it will take for you to stop digging in your heels. You can continue to unconditionally treat Wikimedia editors as lab rats, but you're doing serious harm to the Wikimedia Foundation's standing (and your own) with the Wikimedia community. I hope you've carefully weighed the costs and consequences of the choice that you and James F. are making here.
This particular ongoing saga (refusing to provide an opt-out mechanism for VisualEditor) seems to largely echo past issues with treating Wikimedia editors as customers instead of colleagues. It's a disgusting paternalistic attitude ("we know best, just suffer our new toys") that shows only disrespect for the hardworking volunteers who, on a daily basis, help make Wikimedia wikis great.
MZMcBride
On Mon, Jul 22, 2013 at 10:06 PM, MZMcBride z@mzmcbride.com wrote:
This particular ongoing saga (refusing to provide an opt-out mechanism for VisualEditor) seems to largely echo past issues with treating Wikimedia editors as customers instead of colleagues.
That's not the intent, and I'm sorry if that's how it comes across. The "Just make it go away if you don't like it" solution of saying "Tick this checkbox if you don't want to deal with VisualEditor ever again" seems to me to be more problematic in creating distance between WMF and its most active users. As this dialog hopefully demonstrates, distance is the last thing we want to create.
We want to actually make sure that the default user experience we can offer _works_ for power users, rather than just making it easy to freeze the experience in time and having us not worry about "those users" anymore. Like I said in my response to Adam, that was the approach taken to Monobook->Vector, and it's not one we want to repeat.
As I've noted in my response to wikitech-l just now, there's also the issue of what "opt-out" should mean as VE becomes increasingly more pervasive in the user experience.
But as I've noted in [1], I do not think a compromise on the preference question is necessarily out of reach. I've asked James and team to deliberate on some of the possibilities here, and offered the same suggestion I noted in [1].
Erik
[1] http://lists.wikimedia.org/pipermail/wikitech-l/2013-July/070643.html
On Tue, Jul 23, 2013 at 1:01 AM, Erik Moeller erik@wikimedia.org wrote:
On Mon, Jul 22, 2013 at 10:06 PM, MZMcBride z@mzmcbride.com wrote:
This particular ongoing saga (refusing to provide an opt-out mechanism
for
VisualEditor) seems to largely echo past issues with treating Wikimedia editors as customers instead of colleagues.
That's not the intent, and I'm sorry if that's how it comes across. The "Just make it go away if you don't like it" solution of saying "Tick this checkbox if you don't want to deal with VisualEditor ever again" seems to me to be more problematic in creating distance between WMF and its most active users. As this dialog hopefully demonstrates, distance is the last thing we want to create.
We want to actually make sure that the default user experience we can offer _works_ for power users, rather than just making it easy to freeze the experience in time and having us not worry about "those users" anymore. Like I said in my response to Adam, that was the approach taken to Monobook->Vector, and it's not one we want to repeat.
As I've noted in my response to wikitech-l just now, there's also the issue of what "opt-out" should mean as VE becomes increasingly more pervasive in the user experience.
But as I've noted in [1], I do not think a compromise on the preference question is necessarily out of reach. I've asked James and team to deliberate on some of the possibilities here, and offered the same suggestion I noted in [1].
Erik
[1] http://lists.wikimedia.org/pipermail/wikitech-l/2013-July/070643.html
Erik Möller VP of Engineering and Product Development, Wikimedia Foundation
Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Erik,
Unfortunately, that is the way it comes across.
Of course the WMF has the ability to override consensus of the community. WMF pays the server bill and the developers. There will even be times the WMF absolutely must use that authority, such as in cases where what the community wants would be likely to cause legal jeopardy.
But that absolute override should be used cautiously and as a last resort. When WMF uses it to say "We're not doing ACTRIAL", or "No more new message banner", or "You get VE whether you want it or not", that, right there, is what creates distance between WMF and its most active volunteers.
That's not to say the most active users will never embrace new features. I, myself, love the new notification system. It's a great idea. But it didn't have to be mutually exclusive with the big orange bar specifically for new user talk messages, and at the very least that could've been a configurable preference. Yet it is not.
The frustration a lot of us have is the distinct feeling that no one at WMF is actually listening. Sure, we get a response, but always very noncommittal, and there's a very distinct impression that nothing we say, no matter how many of us say it, matters in the end. A bugfix here, a minor tweak there, sure, but the big decisions that impact our whole project are being taken essentially out of our hands and dictated from the top down.
Attracting new users and making things as easy as possible for them is of course a good goal, and one most of the community shares. But continuing to work against us, rather than with us, ultimately does not serve that aim either. I can still remember over eight years ago when I decided I'd begin editing Wikipedia. I know now what worked and what didn't, and what I wish would have been done better. Every last editor in our community was, once, a fumbling new editor, not quite sure of what we were doing or how it should be done. Now, many of us have volunteered countless hours toward keeping Wikimedia projects running and making them better.
The best resource for those new editors are our seasoned veterans, just as they were for me years ago, and to attempt to attract new editors while repeatedly alienating those veterans and dismissing them as "power users" without a clue what a new editor would need is madness.
Todd Allen
We need to keep in mind that the people who are vocal on mailing lists, or who participate in on-wiki polls with 50 or 100 participants, represent only a tiny fraction of all Wikimedia users - even only a small fraction of those who are active and registered. Yet the constituency of the WMF must be all present users, as well as everyone who might become a user in the future.
The Foundation can't surrender to the inertia and change-resistance of long-term editors, because this serves the bulk of its constituency quite poorly. I understand why Todd thinks the WMF should only rarely override the community, and in some respects I agree. But MediaWiki and the user interface are the WMF's core product, and a small minority of vocal resistance should not be the deciding factor in rolling out new features.
That said, the statistics referred to in another thread by James Salsman and Robert Rohde are troubling and deserve serious attention by Erik and the product team. Those combined with the negative reaction of vocal long-term users should be a big red flag that the team needs to begin communicating much more clearly and being much more (visibly) attentive to potential problems. It boggles my mind, to be honest, that the WMF continues to run into these PR crises without having thought through deeply engaging communication plans and feedback loops.
~Nathan
Hi Erik,
On 23 July 2013 17:01, Erik Moeller erik@wikimedia.org wrote:
But as I've noted in [1], I do not think a compromise on the preference question is necessarily out of reach. I've asked James and team to deliberate on some of the possibilities here, and offered the same suggestion I noted in [1].
Erik
[1] http://lists.wikimedia.org/pipermail/wikitech-l/2013-July/070643.html
A warm and genuine thankyou for this.
I just want to basically endorse some of the other comments being made here, which I think are quite insightful. If the goal of this project was to get the Visual Editor deployed on time and on budget, then the goal has been achieved. But if the goal was to gain acceptance from the community, then I think that the polls on enwiki and nlwiki show that it has been quite a failure. And if the goal was to make it easier for newbies to edit, which I believe was the whole point of the VE in the first place, then the statistically significant decline in edits from new users discussed in the other thread would indicate that VE has failed to meet that goal. Ultimately in its current state it's a tool that very few people, whether newcomers or power users, seem to like very much.
As is usually the case, I'm not saying this to have a go at the developers or anyone else involved (who are obviously doing their best), but I think that some of the communication on this topic has been a bit clumsy and has caused a lot of unnecessary angst that could probably have been avoided if it had been planned for in advance. Does the Foundation have formal communication plans for things like this that focus on gaining community buy-in? If not, then you probably should. Obviously more testing and specifically more user acceptance testing would have been helpful in this case, although I understand the political pressures in getting the product shipped on time.
Cheers, Craig Franklin
On Tue, Jul 23, 2013 at 6:16 AM, Craig Franklin cfranklin@halonetwork.net wrote:
I just want to basically endorse some of the other comments being made here, which I think are quite insightful. If the goal of this project was to get the Visual Editor deployed on time and on budget, then the goal has been achieved. But if the goal was to gain acceptance from the community, then I think that the polls on enwiki and nlwiki show that it has been quite a failure.
At no point did we expect that VisualEditor would see significant adoption among experienced editors initially. It's very clear that initially, for a user experienced with markup, a completely new editing tool that sometimes introduces new types of errors (either inevitably because it's a different editing mode, or avoidably due to bugs or UX issues) will in most cases represent primarily a new cognitive burden and not increased ease. It's to the credit of our community that we nonetheless see strong support for developing a VisualEditor even from users who are unlikely to use it in the near future.
I'm hearing some of those users say "It's easier for me right now to do simple copyedits", and I've seen some examples of users who weren't active come back and say "I'm editing again now because I was never able to figure out markup". But for users who are very comfortable with the current mode of editing, it will take us a long time to both provide a consistently superior experience (which I do think is possible, but very hard) and to win them over. It will take users some time, as well, to discover features in VisualEditor that make their lives easier (keyboard shortcuts, templatedata, default parameters, etc.).
We did expect higher uptake among new users. It is higher (currently about 35-40% for post-July 1 account holders), but not as high as we'd like. That number will go up a fair bit as we add IE support, we're estimating to ~50%. As you interpret data, please keep in mind that it's hard to accurately establish whether a user is new based on registration date alone. For example, we don't know how many of these users have prior casual IP editing experience (prior survey results indicate that about 60% of active editors do), or experience editing on non-WMF wikis, or even as an account on en.wp (sock puppet, forgotten password, etc.).
We don't know at this point what the quantitative impact on new user productivity is. The initial A/B test we ran prior to release is still being analyzed, and there were many confounding variables (including the fact that some users who were assigned to VE shouldn't have been). Please wait for Aaron and Dario to complete this work before drawing conclusions from it.
That said, based on what I know, the single factor that likely has the most negative impact on new users is performance on long articles, which is still quite poor. If you've never encountered wiki markup before, it may still be a better experience, but it can be painful, and prohibitively so on older machines or the most extreme cases (e.g. 300K lists that consist entirely of templates). To be fair, document-level operations like full-article previews on those types of articles in wikitext aren't exactly lightning-fast, but there are features in the wikitext editor, like proper section editing, that alleviate that.
This is a genuinely hard challenge as some of our articles are comparatively huge and complex, and it's easy to bring any web-based editor (including the best-of-breed ones like Google Docs) to its knees at that level of document size and complexity. But we're exploring various optimization strategies that look very promising, and this is our highest priority right now.
Erik -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation
On 23 July 2013 at 17:03:07, Erik Moeller (erik@wikimedia.org) wrote: On Tue, Jul 23, 2013 at 6:16 AM, Craig Franklin cfranklin@halonetwork.net wrote:
I just want to basically endorse some of the other comments being made here, which I think are quite insightful. If the goal of this project was to get the Visual Editor deployed on time and on budget, then the goal has been achieved. But if the goal was to gain acceptance from the community, then I think that the polls on enwiki and nlwiki show that it has been quite a failure.
At no point did we expect that VisualEditor would see significant adoption among experienced editors initially. It's very clear that initially, for a user experienced with markup, a completely new editing tool that sometimes introduces new types of errors (either inevitably because it's a different editing mode, or avoidably due to bugs or UX issues) will in most cases represent primarily a new cognitive burden and not increased ease. It's to the credit of our community that we nonetheless see strong support for developing a VisualEditor even from users who are unlikely to use it in the near future.
I'm hearing some of those users say "It's easier for me right now to do simple copyedits", and I've seen some examples of users who weren't active come back and say "I'm editing again now because I was never able to figure out markup". But for users who are very comfortable with the current mode of editing, it will take us a long time to both provide a consistently superior experience (which I do think is possible, but very hard) and to win them over. It will take users some time, as well, to discover features in VisualEditor that make their lives easier (keyboard shortcuts, templatedata, default parameters, etc.).
Should that even be a concern? I mean, if lots of newbies and technophobes start using the Visual Editor and a bunch of us dorks who love writing markup don't, would that matter?
I'm very happy that the Visual Editor exists and glad that the Foundation have invested the time and resources building it, but have absolutely no intention of using it, and have disabled it on my account. Not because it is bad, but because it is Not For Me. That's because in my work life, I spend most of my day inside a text editor.
The same is true for OpenStreetMap: they recently rolled out the iD editor, an in-browser editor that makes it significantly easier for newbies to edit. It has a built-in tutorial mode and a much nicer UI for managing metadata. But the keyboard commands of JOSM, the desktop editing tool have been wired into my brain and are better suited for a power user. (One simple thing: there's keyboard commands to change from 'select' mode and 'draw' mode - the S and A keys. Which means drawing lots of small fiddly objects doesn't require me to move my mouse over to the tool panel.)
If lots of grizzled wiki-veterans try out the Visual Editor, realise it isn't for them and stick with editing markup, that's not a failure for the Visual Editor, that's a win for freedom of choice.
-- Tom Morris http://tommorris.org/
2013/7/23 Tom Morris tom@tommorris.org:
Should that even be a concern? I mean, if lots of newbies and technophobes start using the Visual Editor and a bunch of us dorks who love writing markup don't, would that matter?
I saw the following more than once on editing workshops and similar events: An experienced user is teaching newbies about editing and shows it with his own account... with Monobook. This is already a problem, because it's different from what the newbies will see. Then he tells the newbies to start editing, and starts walking around and helping them one-by-one and *he* is confused by their interface, which is obviously Vector. A *real* spoken quote from such an occurrence: "Huh? A 'Read' tab? What is it? When did They add it?"
Yes, it happened in 2013. (And I hope that my use of capitalization on "They" conveys the right message.)
It doesn't have to happen in a workshop - it can happen in technical village pumps, too; I still occasionally see techies advise people who ask for support to switch to Monobook.
And obviously, the gap between Monobook and Vector is negligible compared to the gap between WikiEditor and VisualEditor. This creates a Paradox: The people that are the most capable to teach the newbies how to edit are not able to help the newbies because they are using different interface. There is no other way to overcome this paradox than to dog-food.[1]
People who really don't want to dog-food will have "Edit source" for the foreseeable future. But encouraging others to use VE is very much desirable, and has good reasons.
[1] https://en.wikipedia.org/wiki/Eating_your_own_dog_food
-- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore
On Tue, Jul 23, 2013 at 9:25 AM, Tom Morris tom@tommorris.org wrote:
Should that even be a concern? I mean, if lots of newbies and technophobes start using the Visual Editor and a bunch of us dorks who love writing markup don't, would that matter?
That's a great question, Tom. :)
We're confident that in the long run, we'll be able to offer features and capabilities that will give experienced community members compelling reasons to use VisualEditor, so when people say things like "I will never use VisualEditor", I can only note that never is a very long time, and the bulk of our continued effort will go into making VisualEditor the best possible editing experience it can be.
This is not a feature we're launching and forgetting about. This isn't an effort that's scheduled to end. Enabling collaboration is part of our core mission; it's at the heart of what we do. We've got our work cut out for us for the next few months, and we also know what some of the longer term objectives are (integration with discussions, real-time collaboration). Beyond that - sky's the limit.
So, does it matter if people continue to use markup? Probably not - but if you're a human, we'll aim to give you a much better tool to get the job done. So even if you are, as you put it, a markup-loving dork, we hope you'll come visit us in VisualEditor-land every once in a while and mingle with us. We do have cookies, and tales of template madness.
Erik
On Jul 24, 2013 9:57 AM, "Erik Moeller" erik@wikimedia.org wrote:
On Tue, Jul 23, 2013 at 9:25 AM, Tom Morris tom@tommorris.org wrote:
Should that even be a concern? I mean, if lots of newbies and technophobes start using the Visual Editor and a bunch of us dorks who love writing markup don't, would that matter?
That's a great question, Tom. :)
We're confident that in the long run, we'll be able to offer features and capabilities that will give experienced community members compelling reasons to use VisualEditor, so when people say things like "I will never use VisualEditor", I can only note that never is a very long time, and the bulk of our continued effort will go into making VisualEditor the best possible editing experience it can be.
This is not a feature we're launching and forgetting about. This isn't an effort that's scheduled to end. Enabling collaboration is part of our core mission; it's at the heart of what we do. We've got our work cut out for us for the next few months, and we also know what some of the longer term objectives are (integration with discussions, real-time collaboration). Beyond that - sky's the limit.
So, does it matter if people continue to use markup? Probably not - but if you're a human, we'll aim to give you a much better tool to get the job done. So even if you are, as you put it, a markup-loving dork, we hope you'll come visit us in VisualEditor-land every once in a while and mingle with us. We do have cookies, and tales of template madness.
Erik
Erik Möller
Speaking of template madness, the current horrible brokenness that are templates seem to be on the long term roadmap to be fixed. Fixing them requires breaking a whole lot, far more than a visual editor preference. Is two way community dialog on how to handle that on the roadmap? It might still be years and years away, but boy will it hurt, and we better brace ourselves.
VP of Engineering and Product Development, Wikimedia Foundation
Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
2013/7/25 Martijn Hoekstra martijnhoekstra@gmail.com:
Speaking of template madness, the current horrible brokenness that are templates seem to be on the long term roadmap to be fixed. Fixing them requires breaking a whole lot, far more than a visual editor preference. Is two way community dialog on how to handle that on the roadmap? It might still be years and years away, but boy will it hurt, and we better brace ourselves.
It seems more possible to have a wiki software developed from scratch than this to happen.
If sometimes a small technological fart causes a pandemonium, what can we say about a real technological progress?
Maybe a new community (less conservative?) to build a good encyclopedia can come up if a new platformn be invented?
On Thu, Jul 25, 2013 at 7:12 PM, Everton Zanella Alvarenga everton.alvarenga@okfn.org wrote:
Speaking of template madness, the current horrible brokenness that are templates seem to be on the long term roadmap to be fixed. Fixing them requires breaking a whole lot, far more than a visual editor preference. Is two way community dialog on how to handle that on the roadmap? It might still be years and years away, but boy will it hurt, and we better brace ourselves.
It seems more possible to have a wiki software developed from scratch than this to happen.
If sometimes a small technological fart causes a pandemonium, what can we say about a real technological progress?
I believe in the resilience of our community and our projects. Big changes are messy, but we've still gone through them. In the last few months, we have partially or completely rolled out:
- a new editor ;-) - mobile editing - a new login/account creation experience - a new central login system - a new language selection experience - input methods for >150 languages - automatic font delivery - a new translation user experience - edit suggestions for new users - mobile web uploads - mobile app uploads for iOS/Android - notifications, including user mentions & thanks - Lua support for templates - Wikidata support for templates and countless Wikidata improvements (development by WMDE) - etc. etc.
Of course, all these changes are all still imperfect and all still in motion, in many cases including wider rollout. We have a lot of work to do to ensure we don't add too much technical debt in the process of making these changes, fix bugs, user experience and logic errors, add missing functionality, and reduce performance penalties wherever possible.
But 2-3 years ago the reputation of Wikipedia was that its platform was stagnant. That time has come to an end. We're now in the period of the most dramatic technological change in the history of our projects. It will take us a while to absorb the full scope and impact of these changes, but in partnership, we can get there.
On our end, we've not built a team of community liaisons just so we can respond on feedback pages when things break. As VisualEditor becomes more stable and performant, my hope is that we can engage more and more on the new opportunities, and on difficult questions. Opportunities such as ensuring consistent templatedata coverage for all templates, or up-to-date end-user documentation. Questions around what kinds of templates make sense and which ones don't.
I have faith, too, that the community will come up with amazing new ways to build on these technologies, as they already have. The ecosystem of Wikidata applications that have already been built is truly impressive. The adoption of Lua for templates was rapid. Templatedata _has_ been added to many of the most common templates already, and new gadgets using it have been written. Google Summer of Code students are working on plugins for math and syntax highlighting, and I'm sure we'll see many more. And so forth.
I believe in the resilience of our community and its ability to innovate and adapt. I believe in our ability to fight well with each other. And I believe that Wikimedia has never been a more exciting community to be part of than today. :-)
Erik
On 26 July 2013 03:12, Everton Zanella Alvarenga everton.alvarenga@okfn.org wrote:
Maybe a new community (less conservative?) to build a good encyclopedia can come up if a new platformn be invented?
Hence "power users" as a snarl word.
After the uprising of the 17th of June The Secretary of the Writers’ Union Had leaflets distributed in the Stalinallee Stating that the people Had forfeited the confidence of the government And could win it back only By redoubled efforts. Would it not be easier In that case for the government To dissolve the people And elect another?
- d.
I have tried and failed to use the Visual Editor several times in the past few weeks, and as with all new technologies, I consider myself a "follower" rather than a "leader", so I was very interested to look up the Dutch feedback that Romaine was reporting. One of the comments was that it was impossible to create a simple blue link with the VE, since the VE throws <nowiki> around any attempt to do this. Since that is one of the most basic parts of wikimarkup that anyone will use, I decided to investigate, since that was my problem too.
I am happy to report that I just discovered what the problem is. I had turned off the "Show edit toolbar" option in my preferences (probably over a year ago), so I wasn't seeing the top part of the VE edit toolbar, which includes the hyperlink icon, among other things. I was only seeing the other, second, line of the VE toolbar icons for including media, reference, references list, and transclusion.
I expect that many other experienced Wikipedians have the same problem. This should help solve a lot of the "ghost edits".
2013/7/26, David Gerard dgerard@gmail.com:
On 26 July 2013 03:12, Everton Zanella Alvarenga everton.alvarenga@okfn.org wrote:
Maybe a new community (less conservative?) to build a good encyclopedia can come up if a new platformn be invented?
Hence "power users" as a snarl word.
After the uprising of the 17th of June The Secretary of the Writers’ Union Had leaflets distributed in the Stalinallee Stating that the people Had forfeited the confidence of the government And could win it back only By redoubled efforts. Would it not be easier In that case for the government To dissolve the people And elect another?
- d.
Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Right -- and if not that specifically, I'd imagine most experienced users do have various hacks, scripts, gadgets etc installed that we've accumulated over the years. I know many people who have been editing for a long time have a custom skin as well.
I don't know how any of these might or might not affect VE performance, but one thing about the VE being enabled for IPs too (at least on a few wikipedias) is you can always log out and see if the same problem persists :)
-- phoebe
On Sat, Jul 27, 2013 at 12:45 AM, Jane Darnell jane023@gmail.com wrote:
I have tried and failed to use the Visual Editor several times in the past few weeks, and as with all new technologies, I consider myself a "follower" rather than a "leader", so I was very interested to look up the Dutch feedback that Romaine was reporting. One of the comments was that it was impossible to create a simple blue link with the VE, since the VE throws <nowiki> around any attempt to do this. Since that is one of the most basic parts of wikimarkup that anyone will use, I decided to investigate, since that was my problem too.
I am happy to report that I just discovered what the problem is. I had turned off the "Show edit toolbar" option in my preferences (probably over a year ago), so I wasn't seeing the top part of the VE edit toolbar, which includes the hyperlink icon, among other things. I was only seeing the other, second, line of the VE toolbar icons for including media, reference, references list, and transclusion.
I expect that many other experienced Wikipedians have the same problem. This should help solve a lot of the "ghost edits".
2013/7/26, David Gerard dgerard@gmail.com:
On 26 July 2013 03:12, Everton Zanella Alvarenga everton.alvarenga@okfn.org wrote:
Maybe a new community (less conservative?) to build a good encyclopedia can come up if a new platformn be invented?
Hence "power users" as a snarl word.
After the uprising of the 17th of June The Secretary of the Writers’ Union Had leaflets distributed in the Stalinallee Stating that the people Had forfeited the confidence of the government And could win it back only By redoubled efforts. Would it not be easier In that case for the government To dissolve the people And elect another?
- d.
Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On Sat, Jul 27, 2013 at 12:45 AM, Jane Darnell jane023@gmail.com wrote:
I am happy to report that I just discovered what the problem is. I had turned off the "Show edit toolbar" option in my preferences (probably over a year ago), so I wasn't seeing the top part of the VE edit toolbar, which includes the hyperlink icon, among other things. I was only seeing the other, second, line of the VE toolbar icons for including media, reference, references list, and transclusion.
That's interesting, Jane; thanks for the report. I'm not able to reproduce this - as far as I can tell, the preference is completely ignored by VE. If you or someone can get a repro on the exact circumstances under which this occurs, please drop me a note or directly add it to Bugzilla.
Thanks, Erik
I am using chrome and a pretty old computer. I am having trouble getting my editting toolbar to go away again - probably cache problems. I will try to reproduce this properly tomorrow, and otherwise, scratch it up to RTFM
2013/7/27, Erik Moeller erik@wikimedia.org:
On Sat, Jul 27, 2013 at 12:45 AM, Jane Darnell jane023@gmail.com wrote:
I am happy to report that I just discovered what the problem is. I had turned off the "Show edit toolbar" option in my preferences (probably over a year ago), so I wasn't seeing the top part of the VE edit toolbar, which includes the hyperlink icon, among other things. I was only seeing the other, second, line of the VE toolbar icons for including media, reference, references list, and transclusion.
That's interesting, Jane; thanks for the report. I'm not able to reproduce this - as far as I can tell, the preference is completely ignored by VE. If you or someone can get a repro on the exact circumstances under which this occurs, please drop me a note or directly add it to Bugzilla.
Thanks, Erik
Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
If I understand the minutes of the VE / Parsoid quarterly review [1] correctly, then significant changes for templates could be on the table for the first half of calendar year 2014. One of the largest technical challenges for the handling of templates in the VE / Parsoid context is that individual templates can have open-ended syntax where, for example, one template opens a table and an different template closes it (and even more ridiculous examples). Hence the individual templates are not necessarily closed units in themselves but may interact with content from other parts of the pages, which creates various problems for parsers.
In the minutes, the possibility of simply banning such open-ended templates is mentioned, though the reply in the minutes suggests that such an option was seen as probably too disruptive of existing content. Hence the developers mentioned a need to find better ways to enforce the nesting of templates while also supporting all (or at least most) existing content.
However, it does seem likely that devs are discussing changes to the way templates are handled that would move away from the current structure where templates are allowed to contain completely arbitrary blocks of wikitext that would only be interpreted once the whole page is assembled.
-Robert Rohde
[1] http://meta.wikimedia.org/wiki/Metrics_and_activities_meetings/Quarterly_rev...
On Thu, Jul 25, 2013 at 10:23 AM, Martijn Hoekstra martijnhoekstra@gmail.com wrote:
On Jul 24, 2013 9:57 AM, "Erik Moeller" erik@wikimedia.org wrote:
On Tue, Jul 23, 2013 at 9:25 AM, Tom Morris tom@tommorris.org wrote:
Should that even be a concern? I mean, if lots of newbies and technophobes start using the Visual Editor and a bunch of us dorks who love writing markup don't, would that matter?
That's a great question, Tom. :)
We're confident that in the long run, we'll be able to offer features and capabilities that will give experienced community members compelling reasons to use VisualEditor, so when people say things like "I will never use VisualEditor", I can only note that never is a very long time, and the bulk of our continued effort will go into making VisualEditor the best possible editing experience it can be.
This is not a feature we're launching and forgetting about. This isn't an effort that's scheduled to end. Enabling collaboration is part of our core mission; it's at the heart of what we do. We've got our work cut out for us for the next few months, and we also know what some of the longer term objectives are (integration with discussions, real-time collaboration). Beyond that - sky's the limit.
So, does it matter if people continue to use markup? Probably not - but if you're a human, we'll aim to give you a much better tool to get the job done. So even if you are, as you put it, a markup-loving dork, we hope you'll come visit us in VisualEditor-land every once in a while and mingle with us. We do have cookies, and tales of template madness.
Erik
Erik Möller
Speaking of template madness, the current horrible brokenness that are templates seem to be on the long term roadmap to be fixed. Fixing them requires breaking a whole lot, far more than a visual editor preference. Is two way community dialog on how to handle that on the roadmap? It might still be years and years away, but boy will it hurt, and we better brace ourselves.
VP of Engineering and Product Development, Wikimedia Foundation
Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe _______________________________________________ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On 23 July 2013 00:01, Erik Moeller erik@wikimedia.org wrote:
As I've noted in my response to wikitech-l just now, there's also the issue of what "opt-out" should mean as VE becomes increasingly more pervasive in the user experience.
But as I've noted in [1], I do not think a compromise on the preference question is necessarily out of reach. I've asked James and team to deliberate on some of the possibilities here, and offered the same suggestion I noted in [1].
[As just posted to wikitech-l]
Because I understand the level of concern that this matter is causing, I am changing my mind on this. For the duration of VisualEditor's "beta" period, there will be an opt-out user preference. This will be deployed tomorrow morning, San Francisco time. Once VisualEditor is out of 'beta', this preference will be removed.
As others have explained better than I, we think that users will be ill-served by this opt-out, and I hope that as few users as possible will choose this way to degrade their experience and deprive the community of their input. Instead of endlessly arguing the point about this, I'd rather my team and I spending our time working to make our sites better.
Yours,
James Forrester wrote:
Because I understand the level of concern that this matter is causing, I am changing my mind on this. For the duration of VisualEditor's "beta" period, there will be an opt-out user preference. This will be deployed tomorrow morning, San Francisco time.
Thank you very much for reconsidering this, James. I appreciate that it's a bloody compromise, but I believe that it will help us all move forward.
As much as many editors have complained about dirty diffs and other bugs in it, VisualEditor really is a remarkable achievement and it continues to show amazing promise for the future of Wikimedia (and the broader Web). As always, Wikimedians complain loudly and congratulate softly and this is something I hope we all (myself included, to be sure) collectively continue to work on and improve. :-)
Thanks again.
MZMcBride
Thanks, James, for the flexibility that you are showing here. I think the Visual Editor is already great and it will become even better after polishing it.I am committed to test it as much as I can and to send some proposals. That haters can disable it completely will leave more room for constructive feedback and peace of mind :)
Thanks, Micru
On Tue, Jul 23, 2013 at 9:56 PM, James Forrester jforrester@wikimedia.orgwrote:
On 23 July 2013 00:01, Erik Moeller erik@wikimedia.org wrote:
As I've noted in my response to wikitech-l just now, there's also the issue of what "opt-out" should mean as VE becomes increasingly more pervasive in the user experience.
But as I've noted in [1], I do not think a compromise on the preference question is necessarily out of reach. I've asked James and team to deliberate on some of the possibilities here, and offered the same suggestion I noted in [1].
[As just posted to wikitech-l]
Because I understand the level of concern that this matter is causing, I am changing my mind on this. For the duration of VisualEditor's "beta" period, there will be an opt-out user preference. This will be deployed tomorrow morning, San Francisco time. Once VisualEditor is out of 'beta', this preference will be removed.
As others have explained better than I, we think that users will be ill-served by this opt-out, and I hope that as few users as possible will choose this way to degrade their experience and deprive the community of their input. Instead of endlessly arguing the point about this, I'd rather my team and I spending our time working to make our sites better.
Yours,
James D. Forrester Product Manager, VisualEditor Wikimedia Foundation, Inc.
jforrester@wikimedia.org | @jdforrester _______________________________________________ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
At enwiki, we have similar results. [1] For example
"VisualEditor, as currently deployed, is a useful feature" ( 5 Support, 37 Oppose )
Even though most users believe VisualEditor is nonetheless a good idea
"VisualEditor is a good idea in theory" ( 54 Support, 5 Oppose, 5 Neutral )
Taken in context with the various comments in other forums (such as WP:VE/F), the fact that 1300 enwiki users have enabled a gadget to remove VE, and the early evidence that VE makes new users less likely to edit [2][3], and I think one would also see a majority of enwiki participants voting in favor of turning the thing off. Somehow I don't think the WMF would actually let enwiki go back to an opt-in mode, but I do believe that a majority of the editors likely to participate in such polls would support that at present.
Of course, this deployment is clearly being run in a top-down fashion without much effort to determine whether the various communities involved feel the software is ready.
-Robert Rohde
[1] http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/RFC [2] http://meta.wikimedia.org/wiki/Research:VisualEditor%27s_effect_on_newly_reg... [3] http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&am...
On Mon, Jul 22, 2013 at 1:17 PM, Lodewijk lodewijk@effeietsanders.org wrote:
Hi,
I found the vote to be a poll here: http://nl.wikipedia.org/wiki/Wikipedia:Opinielokaal#Tijdelijk_uitschakelen_v... (some 50 people voted in favor of hiding the visual editor from all editors). Romaine seems (I only scanned it quickly) to have summarized the gist of the atmosphere correctly. To be totally clear: the poll is to make the visual editor *invisible*, with an opt-in for testing purposes. I am assuming this was to be achieved through either not rolling it out on nlwiki, or through js/css.
I must say I find especially this email very unspecific with regards to what would exactly be the problems. The poll gives more specific examples (although I myself don't really agree this weighs against the advantages, clearly for many they are significant enough).
Best, Lodewijk
2013/7/22 Samuel Klein meta.sj@gmail.com
Hello Romaine,
Speaking only for myself, I appreciate detailed feedback like this. Could you link to the local votes and today's discussion?
SJ
Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
wikimedia-l@lists.wikimedia.org