Mailing List Archive

[Wikimedia-l] Feedback for the Wikimedia Foundation
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




_______________________________________________
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>
Re: [Wikimedia-l] Feedback for the Wikimedia Foundation [ In reply to ]
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>
Re: [Wikimedia-l] Feedback for the Wikimedia Foundation [ In reply to ]
Hello Samuel,

At any time I am willing to give feedback. (Many times I translate new developments to the local community with explaining why, what is needed much, and I try to report feedback back.)

The voting can be found here:
https://nl.wikipedia.org/wiki/Wikipedia:Opinielokaal/Tijdelijk_uitschakelen_visuele_tekstverwerker

The community doesn't consider these bugs as minor.


The feedback page is:
https://nl.wikipedia.org/wiki/Wikipedia:Visuele_tekstverwerker/Feedback


Romaine



Samuel Klein meta.sj at gmail.com
Mon Jul 22 19:31:50 UTC 2013

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>
Re: [Wikimedia-l] Feedback for the Wikimedia Foundation [ In reply to ]
Hi,

I found the vote to be a poll here:
http://nl.wikipedia.org/wiki/Wikipedia:Opinielokaal#Tijdelijk_uitschakelen_visuele_tekstverwerker
(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>
Re: [Wikimedia-l] Feedback for the Wikimedia Foundation [ In reply to ]
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>
Re: [Wikimedia-l] Feedback for the Wikimedia Foundation [ In reply to ]
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_registered_editors/Results
[3] http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=565381622#Some_performance_notes

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_visuele_tekstverwerker
> (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 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>
Re: [Wikimedia-l] Feedback for the Wikimedia Foundation [ In reply to ]
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_Departments_to_Failure

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>
>



--
Etiamsi omnes, ego non
_______________________________________________
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>
Re: [Wikimedia-l] Feedback for the Wikimedia Foundation [ In reply to ]
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_Departments_to_Failure
>
> 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
_______________________________________________
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>
Re: [Wikimedia-l] Feedback for the Wikimedia Foundation [ In reply to ]
The problem is that the roll out schedule seems to be more important than the quality of the work itself. A deadline of roll out schedule is only a tool to plan things, but as usual with plans, is is called a plan and not actual situation so things can change due circumstances. If the work isn't ready, and you haver to choose between quality or the schedule, I really hope they will choose for the quality and not the schedule.

Quality is in communities considered as more important than some arbitrary schedule. The schedule was already a month ago considered unrealistic, but still they want to keep that schedule. For communities that is a nightmare.

If the press finds out that WMF is considering quality less important than some arbitrary planning, this will give WMF an image problem.

Local communities are the victim due they have to fix all problems the visual editor causes. Already I had to fix two articles by users who used the visual editor via opt-in (and I didn't check all VE edits), if every user or everyone gets the visual editor before this is fixed, then we can daily fix a lot of articles. Is that the purpose of new software? To force local communities to fix articles which because of the visual editor are broken?

In general the community trusts WMF in what they are doing, but this causes a crush between WMF and communities. I hope WMF remembers that communities daily do the actual work.

Romaine



Liam Wyatt liamwyatt at gmail.com
Tue Jul 23 00:43:19 UTC 2013

On 23 July 2013 07:10, David Cuenca <dacuetu at 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_Departments_to_Failure
>
> 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



_______________________________________________
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>
Re: [Wikimedia-l] Feedback for the Wikimedia Foundation [ In reply to ]
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&action=edit

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

_______________________________________________
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>
Re: [Wikimedia-l] Feedback for the Wikimedia Foundation [ In reply to ]
Hello Erik Möller,

> 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.

Nobody have said, so far I have seen, that the visual editor should be locked away for a year, the longest estimate of the time needed to get ready is some months. Mentioning an extreme time schedule seems to me a form of framing, exaggerating is not a good base as argumentation. Sorry, we don't fall for that.

I still see no good reason in you mail why "it's the right decision". You still miss the point: local communities expect that when a piece of software comes out of the beta it has a basic of good functioning. Now it has not, it still messes pages up on nl-wiki and this fact is been ignored for weeks now. The local community does not want to fix the problems the visual editor causes. The software should help us instead of giving us extra work.

I still don't see a reflection in your mail that you take the feedback from local communities seriously. You would encourage everyone to hide the visual editor, but 80% of the community on nl-wiki thinks it should stay in beta until the problems are solved and should be hidden. We are willing to help, please stop ignoring the feedback about problems and stop ignoring the communities.

Romaine






_______________________________________________
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>
Re: [Wikimedia-l] Feedback for the Wikimedia Foundation [ In reply to ]
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



_______________________________________________
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>
Re: [Wikimedia-l] Feedback for the Wikimedia Foundation [ In reply to ]
On Mon, Jul 22, 2013 at 9:42 PM, Romaine Wiki <romaine_wiki@yahoo.com> wrote:

> I still don't see a reflection in your mail that you take the feedback from local communities seriously.

Romaine, we're not ignoring feedback. I'm asking James to weigh in
with some details relative to the issues raised that are specific to
applying VisualEditor to the Dutch Wikipedia content and template
corpus, so we can make a final assessment on whether these issues are
severe enough to justify a delayed deployment there.

From what I'm seeing on the feedback page, these are (as is often the
case) typically related to specific template constructions. That's
generally what's going to be most likely to bite us during the
cross-language rollout: each Wikipedia uses a very different set of
templates, and some template constructions are inherently fragile.

For example, from the feedback page, it doesn't surprise me that a
construction like

[[File:Bla.jpg|{{largethumb}}|Some caption]]

where {{largethumb}} contains only the text "260px|thumb", may cause
problems in VE :-). It is somewhat reassuring to only see a single
interlanguage link to nds-nl on that template.

To be clear, as we go forward, we'll need to determine what kinds of
uses of templates we can and want to support. As noted earlier,
templates are used in some truly mindboggling ways, some of which
we'll simply never be able to support well.

Erik
--
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>
Re: [Wikimedia-l] Feedback for the Wikimedia Foundation [ In reply to ]
Erik Möller wrote:
>...
> we need to collectively figure out what a discoverable,
> intuitive user experience should look like.... We're not
> going to solve these challenges if we lock away VisualEditor...

Erik, I don't understand. Could you please explain how making the
visual editor opt-in only until the currently discovered batch of bugs
are addressed would prevent future improvements? I don't see how that
follows at all.

Feature enhancement brainstorming is not worth preventing millions of
productive edits, because you most certainly can do it without causing
them.

_______________________________________________
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>
Re: [Wikimedia-l] Feedback for the Wikimedia Foundation [ In reply to ]
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>
Re: [Wikimedia-l] Feedback for the Wikimedia Foundation [ In reply to ]
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
_______________________________________________
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>
Re: [Wikimedia-l] Feedback for the Wikimedia Foundation [ In reply to ]
You say you are not ignoring feedback. Then how did it happen that all the feedback we have been given on nl-wiki in the past month is still nothing done with, including some major bugs? Nothing is done with it, you can say you do not ignore feedback, but we would like to see the proof for that. The liaisons and developers make the visual editor already look nicer than it actually is, so we really like to see that it is no fairy tale.

But thanks for assessing the bugs of nl-wiki. Keep what that in mind that in general the community of nl-wiki likes the idea of a visual editor and still 80% voted for delaying launch due problems/bugs.

You say that we have typically template constructions. Let me say a few things about that, at first: it is wikisyntax and parser functions used for those things we got them for. Second, we try to keep our templates as KISS as possible. No gigantic constructions like en-wiki, but max 2 layers of templates.

Largethumb has as goal that all images under an infobox have the same width as the infobox itself, so that they are aligned at each other. The template contains very basic codes, like you describe here. It is one of the most simple templates on nl-wiki, and the visual editor can't cope with that. Sorry that only one interwiki is added, I haven't searched for it on other Wikipedias. The largethumb came into existance as we missed an image parameter for that. In the past we also had a template for borders around images, until the software got |border| as parameter for images.

If templates are going to bite, maybe it would have been a better idea to keep then green shaded, like the gallery currently is. It is better to have a good working visual editor which is not able to edit some aspects of articles (like templates) than having a visual editor which breaks templates.

And if project specific templates will bite, perhaps it is an better idea not to aim for many Wikipedias at the same time but to spread that in time, so that developers have the time to pay attention to project specific bugs.

Still it all sounds strange to me. Why?
* One of the most easiest templates appears to be the most difficult one for the visual editor.
* The MediaWiki own <gallery> still doesn't work in the visual editor.
* I heard from the Korean wiki that the visual editor couldn't handle some characters in the Korean alphabet.
* But also a lot of tables can't be handled, not the most difficult tables.

Basic things!
So no weak excuses please, the visual editor isn't ready, that is the onliest conclusion I can draw if very basic things still do not function well. On top of that are also enough more complex bugs.

Also our appendix template, to add manual or showing <ref> sources in articles, it is a very easy template but very difficult in the visual editor. And above all our very nice wrapper template. The wrapper is there because WMF still doesn't fix a bug of pushed down images.

Another problem the visual editor has is that it makes it too easy for users to change the size of images. The MediaWiki software has a thumbnail feature in it what enables users with bad eyes to make images larger in their preferences (second tab), or for users with very large or very small computer screens to resize the images to give them a better perspective in the screen. If you add a px to the thumb, that feature is broken. On the Dutch Wikipedia we like very much that basis feature in the software as we can serve more people in a better way with information, but the VE makes it too easy to change that and stimulates bad behaviour. I have seen also other examples of stimulating bad behaviour. The software certainly should not stimulate that.

I still think you aim too high for now, with all kinds of complex things. MediaWiki itself took years to get in the current stable version, the development of visual editor seems to try to match that level of development, which seems to me an utopia. It needs time than only a few months to get a fully ready editor.

The communities are in general willing to adopt the visual editor, but the way how WMF is acting with the launch is greating the gap. The way how it is going now enlarges the gap between the community and WMF. I know some developers have editing experience, but still I think it would be good to have a non-developer (or two) in the developing team, someone with much editing experiences and is able to oversee the consequences, so that creating gabs is prevented, as well as "déformation professionnelle". [1]


Romaine


[1] https://en.wikipedia.org/wiki/D%C3%A9formation_professionnelle


Erik Moeller erik at wikimedia.org
Tue Jul 23 06:05:50 UTC 2013

On Mon, Jul 22, 2013 at 9:42 PM, Romaine Wiki <romaine_wiki at yahoo.com> wrote:

> I still don't see a reflection in your mail that you take the feedback from local communities seriously.

Romaine, we're not ignoring feedback. I'm asking James to weigh in
with some details relative to the issues raised that are specific to
applying VisualEditor to the Dutch Wikipedia content and template
corpus, so we can make a final assessment on whether these issues are
severe enough to justify a delayed deployment there.

>From what I'm seeing on the feedback page, these are (as is often the
case) typically related to specific template constructions. That's
generally what's going to be most likely to bite us during the
cross-language rollout: each Wikipedia uses a very different set of
templates, and some template constructions are inherently fragile.

For example, from the feedback page, it doesn't surprise me that a
construction like

[[File:Bla.jpg|{{largethumb}}|Some caption]]

where {{largethumb}} contains only the text "260px|thumb", may cause
problems in VE :-). It is somewhat reassuring to only see a single
interlanguage link to nds-nl on that template.

To be clear, as we go forward, we'll need to determine what kinds of
uses of templates we can and want to support. As noted earlier,
templates are used in some truly mindboggling ways, some of which
we'll simply never be able to support well.

Erik
--
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>
Re: [Wikimedia-l] Feedback for the Wikimedia Foundation [ In reply to ]
In the most early stages WMF has told us via various way that the visual editor would have an opt-out. It appears that at the last moment before the the launch on the English Wikipedia this was removed.

A lot of people are annoyed for years that developers of various software inside and outside Wikimedia expect of end users that they accept and use new functions, while many of them do not have any need for those and do not want new functions. When there are complaints about that behaviour of developers it is very very irritating that those developers then say: "deal with it". It is very much arrogance that developers can decide for users what they must use, really, that is absolutely not the way how the users themselves think about that. Saying that users have to deal with it is roughly similar with saying "we don't car what the community is thinking about it".

Last week a power user of nl-wiki described another example: A long time ago he had learned to use Wordperfect. He learned everything about the software and knew exactly what it did. Wordperfect changed to Word. That was a big change, a lot of things were different, so called on an "intelligent" way. He then had to re-learn everything from beginning how this editor worked. And then, right at the moment that user knows the software completely, the software company changed the user interface completely. All familiar menus disappeared and a ribbon came in place of it. And what must the current software (Word) do? still the same as Wordperfect!

> "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.

The opposite is true. People use the MediaWiki software for many years now, sure there are users who consider the visual editor as handy but many users do not want to change. They are happy with the software as it is, they understand that the visual editor can be handy for other users, but absolutely do not want to be forced to use it themselves. Not be able to opt-out gives them the feeling not being taken seriously by the WMF. (Combine that with the broken promise, it gives double that feeling.)

> We want to actually make sure that the default user experience we can
> offer _works_ for power users

Power users need fast software, that works for everything, with customized tools. The visual editor is sooooo slowww, doesn't work for everything and the usual customized tools are useless in the visual editor. I am a power user, I see no reason at all to use the visual editor. Also I experience the visual editor as clumpsy, I really can't say that with the current visual editor you understand what power users do and how they work. (In combination with the previous mentioned things it gives triple the feeling not been taken serious.)


Romaine




Erik Moeller erik at wikimedia.org
Tue Jul 23 07:01:00 UTC 2013

On Mon, Jul 22, 2013 at 10:06 PM, MZMcBride <z at 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>
Re: [Wikimedia-l] Feedback for the Wikimedia Foundation [ In reply to ]
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

_______________________________________________
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>
Re: [Wikimedia-l] Feedback for the Wikimedia Foundation [ In reply to ]
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
_______________________________________________
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>
Re: [Wikimedia-l] Feedback for the Wikimedia Foundation [ In reply to ]
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

_______________________________________________
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>
Re: [Wikimedia-l] Feedback for the Wikimedia Foundation [ In reply to ]
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/

_______________________________________________
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>
Re: [Wikimedia-l] Feedback for the Wikimedia Foundation [ In reply to ]
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‬

_______________________________________________
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>
Re: [Wikimedia-l] Feedback for the Wikimedia Foundation [ In reply to ]
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>
Re: [Wikimedia-l] Feedback for the Wikimedia Foundation [ In reply to ]
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



_______________________________________________
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>

1 2  View All