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
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
Robert Rohde wrote:
>...
> early evidence that VE makes new users less likely to edit [2][3]
>...
> [2] http://meta.wikimedia.org/wiki/Research:VisualEditor%27s_effect_on_newly_re…
> [3] http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&o…
>...
[2] states: "Newcomers with the VisualEditor were ~43% less likely to
save a single edit than editors with the wikitext editor (x^2=279.4,
p<0.001), meaning that Visual Editor presented nearly a 2:1 increase
in editing difficulty."
[3] states:
> Change in total (daily) article edits since before VE became default on 1 July (comparison: 18-30 June): -4.5%
> Change in registered user article edits since before VE became default: -2.2%
> Change in anon article edits since before VE became default: -8.6%
Both of those statistics are terrible and would strongly support
shutting the visual editor off except for opt-ins until all open bugs
including browser and mobile device coverage are addressed before
trying again.
But why are those statistics so different?
Oliver Keyes wrote:
>
> "active editors" == "editors with > [5/10/depending on standard] edits a
> month". It's pretty impossible, at our end, for us to identify one person
> between multiple IPs or one person between multiple IPs.
Why can't you use behavioral and expertise characteristics to measure
the proportion of anonymous IP editors who edit with the same
distinguishing attributed and skill as active long term editors, as
below, in order to estimate their active proportion? The assertion
that you can't is like saying you can't count black swans unless you
can get their feathers in a centrifuge to check the pigment chemically
simply because it's dark at nighttime.
I hope that this question will not go unanswered, but my experience
(being told that explaining multivariate analysis during Office Hours
is inappropriate because executives can't possibly be expected to
understand it) is not encouraging.
> Nathan wrote:
>>...
>> Because they are measuring different things? The first refers
>> to newly registered editors, which the second (judging by
>> your summary) does not.
>
> You are absolutely right. This gives us a silver lining insight that about
> 80% of anonymous IP editors have the editing experience of
> non-new registered editors. Therefore most of them should be added to the
> number of long term active editors, and even by a conservative estimate
> that means that the Foundation has finally reached the elusive long term
> strategic goal in growth of active editors. Congratulations!
>
> Always look on the bright side!
>
> Robert Rohde wrote:
>>...
>> early evidence that VE makes new users less likely to edit [2][3]
>>...
>> [2] http://meta.wikimedia.org/wiki/Research:VisualEditor%27s_effect_on_newly_re…
>> [3] http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&o…
>>...
>
> [2] states: "Newcomers with the VisualEditor were ~43% less likely to
> save a single edit than editors with the wikitext editor (x^2=279.4,
> p<0.001), meaning that Visual Editor presented nearly a 2:1 increase
> in editing difficulty."
>
> [3] states:
>
>> Change in total (daily) article edits since before VE became default on
>> 1 July (comparison: 18-30 June): -4.5%
>> Change in registered user article edits since before VE became default: -2.2%
>> Change in anon article edits since before VE became default: -8.6%
>
> Both of those statistics are terrible and would strongly support
> shutting the visual editor off except for opt-ins until all open bugs
> including browser and mobile device coverage are addressed before
> trying again.
>
> But why are those statistics so different?
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.
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
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…
>
> 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
Dear all,
Wikimedia UK has for the last few months been engaged in an open strategic
planning process. We've had a number of workshops and drafts as part of
this process, and at our recent Board meeting discussed the long-term goals
that will underpin the strategy. This is on our wiki here:
http://uk.wikimedia.org/wiki/Towards_a_five_year_plan_2013-18/Draft_Goals_v…
Comments are very welcome - from the UK or the rest of the Wikimedia
movement. Once the goals are defined, these will be fleshed out with
strategies and targets to reach them along with metrics for success.
Many thanks,
Chris Keating
Chair, Wikimedia UK
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…
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