The Visual Editor is a huge failure

[Vigilant]

This story looks hopelessly naive now.

http://tech2.in.com/news/web-services/w ... oon/875654

So I start digging around for articles on the VisualEditor...
Naturally, I find lots of puff pieces and PR sells.

This one makes me shake my head
http://opensourcebridge.org/sessions/877

Just looking at the kids they have in charge renders my shock at this debacle of a project into an "I should have known" stage.

Digging further
http://www.trevorparscal.com/resume/
leads to a bunch of dead projects in the "open source but who cares?" arena.

I don't get how you hire these guys with little to no relevant experience, let them write mission critical software and then have them give content free talks on how things are looking up...

Makes zero sense.


Edit:
Then I find this
http://opensourcebridge.org/sessions/954

*shakes head and goes to have a beer*

[Malleus]

This story looks hopelessly naive now.

http://tech2.in.com/news/web-services/w ... oon/875654

Your point about Agile development is an interesting one. My understanding of Agile development is that it's a way to handle uncertain customer requirements, not carte blanche to hack away as you discover what you ought to have known already had you taken the trouble to ask.

[Vigilant]

This story looks hopelessly naive now.

http://tech2.in.com/news/web-services/w ... oon/875654

Your point about Agile development is an interesting one. My understanding of Agile development is that it's a way to handle uncertain customer requirements, not carte blanche to hack away as you discover what you ought to have known already had you taken the trouble to ask.

The Agile stuff comes out of the previous crazy, rapid prototyping.

It comes in response to what Agile consultants called "analysis paralysis" wherein teams spend tons and tons of time trying to write up massive documents that are targeted towards a product that might not be what the customer wants.

Agile and Scrum try to avoid long cycles ala the waterfall cycle of development. Get *something* working that the customer can see. Fix things quickly and make fast, incremental progress towards a final product. Get the whole team together often to do "constant integration" so you don't end up writing modules that don't fit together (API mismatch) at some distant integration point.Less work in the wrong direction. There's also a nod to pair programming where two devs take turns watching over each other's shoulders for rapid mistake fixing.

This tends not to work in practice as many devs are poorly socialized and need some solitude to go face in on the problem.
You need someone to convert the team to this ideology, get complete buy in and then ride their asses to follow the methodology.

This is orthogonal to good test and regression methodology.
Having built FPGA->ASIC, I understand what it takes to write code that you know cannot be modified once the device is built.

"No Spins" was our motto. We even had silly buttons made.
Typically, it took 4 man months of verification for each man month of design before we'd have reduced the defect rate far enough to ship. 3x if the design was a knock off design.

Software doesn't have to be that rigid, but these guys have no fucking clue what they're doing.
If a clue fell out of the sky and wriggled on their collective faces, they still would not be able to make the identification.

As a long time engineer, I am appalled at their lack of professionalism.

[Vigilant]

http://www.engadget.com/2013/07/02/wiki ... ualeditor/

Making simple edits to a post on Wikipedia hasn't traditionally been an impossible undertaking, but Wiki markup (the syntax used to add and adjust formatting) wasn't nearly as intuitive as it could have been. And editors dropped like flies as a result of confusing tags and a generally frustrating workflow. Now, in an attempt to simplify the editing process dramatically, the site's management team is adding a brand new What You See is What You Get (WYSIWYG) tool called VisualEditor. Making corrections is now as simple as hitting "Edit" and typing in your changes -- intuitive buttons for text formatting, list creation and adding headings enable you to make pages look nice and consistent without a lot of work. Assuming you're using a recent version of Chrome, Safari or Firefox, manual page overhauls should take minutes, rather than hours.

Well, that sure didn't turn out to be the case.

Written by a typical PR hack outlet. Check the other articles.
http://www.engadget.com/about/editors/zach-honig/

and
http://www.shellypalmer.com/2013/06/wikipedia-wysiwyg/

It’s been a long time coming, but the Wikimedia Foundation is finally on the cusp of rolling out its visual ‘WYSIWYG‘ editor for all Wikipedia users. Back in December, Wikimedia explained why, after all these years, Wikipedia still relies on Wikitext, a markup code that precludes many people from actively contributing to the world’s biggest online encyclopedia. However, the organization has been working on a WYSIWYG editor for several years, and it said it has been the “most challenging software project the Wikimedia Foundation has ever worked on.” If you’ve ever used WordPress, you’ll note there’s a ‘visual’ and ‘text’ editing mode – the former essentially means you don’t ever have to touch HTML, so anyone with basic computing skills can blog and self-publish. Thus, a visual editor will revolutionize Wikipedia.

You're an irrelevant hack, Shelly.
http://www.shellypalmer.com/shellys-blog/

And assorted others, all equally puerile.

http://www.dailydot.com/business/wikipe ... r-wysiwyg/
http://thewikipedian.net/2013/07/02/adv ... l-editing/
http://techifreak.com/2013/07/02/wikipe ... al-editor/

None of these guys has actually attempted to use this new monstrosity for any appreciable length.

Hopefully, August 1 will have some followup stories that hasten Sue to the door.

[Malleus]

I used to teach that stuff, and constant integration is the key. And those donkeys who break the daily build need to be punished. One company I worked for had a Dunce's hat, to be placed on the workstation of any "engineer" whose code had broken the build.

I come back to my basic point though, which is that use cases are only of use if you actually get end users to help write them. I think we all know that if you asked the WMF developers for a formally specified use case they'd panic and go into obfuscation mode. Or maybe you'd get some kind of childish gang sign.

[Hex]

One company I worked for had a Dunce's hat, to be placed on the workstation of any "engineer" whose code had broken the build.

At the place I was at it was a large "trophy" made of a cardboard tube with a rubber chicken stapled to the top, all spray-painted silver, big enough to see over the top of their monitor from any direction. Also their name would appear highlighted at the top of the build monitoring report. Good times.

[The Joy]

If the subject is related to a WP:BLP (T-H-L), I think "no consensus" defaults to "Delete."

Only if the subject has expressed a wish for deletion.

I find Wikipedians like to "bend" the rules if it suits them. If the details of a policy work for them, they'll argue for the details. If the details do not favor their position, they'll argue about the "spirit" and "big picture" of the policy.

[thekohser]

Looking at the 500 most recent changes on the English Wikipedia, I see that 39 of the edits were tagged as having been completed with VisualEditor. That's 7.8% of edits. And this thing is switched "on" for all Wikipedia pages, right?

I also note that most of the editors using VisualEditor are either IP addresses, or red-linked new Users, adding or subtracting very tiny amounts of content (e.g., changing "draft" to "drafted").

Among the 39 edits, it was also easy to spot a brand new COI editor.

Another discovery among the VisualEditors is someone improving the heck out of this article, which has been the subject of years-long vandalism.

Congratulations, Wikipedia, on engaging so many new editors in profoundly useful ways!

[Malleus]

If the subject is related to a WP:BLP (T-H-L), I think "no consensus" defaults to "Delete."

Only if the subject has expressed a wish for deletion.

I find Wikipedians like to "bend" the rules if it suits them. If the details of a policy work for them, they'll argue for the details. If the details do not favor their position, they'll argue about the "spirit" and "big picture" of the policy.

That sounds about right. I've always found the Ignore All Rules policy to be interesting, as I've never seen it actually applied.

[Malleus]

Looking at the 500 most recent changes on the English Wikipedia, I see that 39 of the edits were tagged as having been completed with VisualEditor. That's 7.8% of edits. And this thing is switched "on" for all Wikipedia pages, right?

I also note that most of the editors using VisualEditor are either IP addresses, or red-linked new Users, adding or subtracting very tiny amounts of content (e.g., changing "draft" to "drafted").

Among the 39 edits, it was also easy to spot a brand new COI editor.

Congratulations, Wikipedia, on engaging so many new editors in profoundly useful ways!

... and finding more and more inventive ways to alienate existing editors.

[Vigilant]

Great - I hope to use the visual editor extensively in the coming days, and also talk to people at the Foundation. At least preliminarily, I plan to speak about it at Wikimania... but I'm not sure yet that I'll have enough of interest to say!--Jimbo Wales (talk) 13:19, 22 July 2013 (UTC)

Have fun, monkeyboy.
Luckily, you've got a troop of lesser hominids to follow along behind you and cleanup.

[Vigilant]

The rate of now issues is slowing at the Feedback page.

Which is more true:

* The obvious bugs are all found and fixed?

* Those users capable of exercising the editor and finding a bug have all turned of the editor?

[Malleus]

The rate of now issues is slowing at the Feedback page.

Which is more true:

* The obvious bugs are all found and fixed?

* Those users capable of exercising the editor and finding a bug have all turned of the editor?

"True" is a binary concept; something is either true or it isn't. As to your question, I very much suspect that there are rather few editors actually using this piece of shit, so obviously the number of bug reports will be reducing. And when when nobody at all uses it the number of bug reports will reduce to zero, at which point I guess the WMF will declare victory in their war against the editors.

[Randy from Boise]

The rate of now issues is slowing at the Feedback page.

Which is more true:

* The obvious bugs are all found and fixed?

* Those users capable of exercising the editor and finding a bug have all turned of the editor?

"True" is a binary concept; something is either true or it isn't. As to your question, I very much suspect that there are rather few editors actually using this piece of shit, so obviously the number of bug reports will be reducing. And when when nobody at all uses it the number of bug reports will reduce to zero, at which point I guess the WMF will declare victory in their war against the editors.

............and expound upon their triumphant introduction of new software in their 2014 fundraising appeal.

R

[Vigilant]

The rate of now issues is slowing at the Feedback page.

Which is more true:

* The obvious bugs are all found and fixed?

* Those users capable of exercising the editor and finding a bug have all turned of the editor?

"True" is a binary concept; something is either true or it isn't. As to your question, I very much suspect that there are rather few editors actually using this piece of shit, so obviously the number of bug reports will be reducing. And when when nobody at all uses it the number of bug reports will reduce to zero, at which point I guess the WMF will declare victory in their war against the editors.

Don't they have to deploy it to the rest of the languages first?

[Malleus]

The rate of now issues is slowing at the Feedback page.

Which is more true:

* The obvious bugs are all found and fixed?

* Those users capable of exercising the editor and finding a bug have all turned of the editor?

"True" is a binary concept; something is either true or it isn't. As to your question, I very much suspect that there are rather few editors actually using this piece of shit, so obviously the number of bug reports will be reducing. And when when nobody at all uses it the number of bug reports will reduce to zero, at which point I guess the WMF will declare victory in their war against the editors.

Don't they have to deploy it to the rest of the languages first?

The truth I think is, with only a very few exceptions, the rest of the languages don't matter, and it obviously won't work any better for them than it does for English. Almost certainly worse in fact.

[Vigilant]

The rate of now issues is slowing at the Feedback page.

Which is more true:

* The obvious bugs are all found and fixed?

* Those users capable of exercising the editor and finding a bug have all turned of the editor?

"True" is a binary concept; something is either true or it isn't. As to your question, I very much suspect that there are rather few editors actually using this piece of shit, so obviously the number of bug reports will be reducing. And when when nobody at all uses it the number of bug reports will reduce to zero, at which point I guess the WMF will declare victory in their war against the editors.

Don't they have to deploy it to the rest of the languages first?

The truth I think is, with only a very few exceptions, the rest of the languages don't matter, and it obviously won't work any better for them than it does for English. Almost certainly worse in fact.

I happen to agree with Jimmy that "bringing back the fun" is paramount.
I fully expect the deployment of the VisualEnema to "bring back the fun" for me while I watch the failure cascade on the feedback page.



in 100 languages!

[The Joy]

Devs should start seeing this on the Chinese Wikipedia:

"这VisualEditor是一块废话!"

(It's supposed to be "This VisualEditor is a piece of crap!" in Simplified Chinese. The Google translation, however, says "This VisualEditor is a nonsense!" Meh, close enough.)

[Zoloft]

Devs should start seeing this on the Chinese Wikipedia:

"这VisualEditor是一块废话!"

(It's supposed to be "This VisualEditor is a piece of crap!" in Simplified Chinese. The Google translation, however, says "This VisualEditor is a nonsense!" Meh, close enough.)

The 这 is silent?

[Vigilant]

Devs should start seeing this on the Chinese Wikipedia:

"这VisualEditor是一块废话!"

(It's supposed to be "This VisualEditor is a piece of crap!" in Simplified Chinese. The Google translation, however, says "This VisualEditor is a nonsense!" Meh, close enough.)

The 这 is silent?

Like Django.

Incidentally, when I was in China for business, ran a fairly large engineering group for an ASIC company, I took a Chinese name since the locals all took English names.

My team gave me my Chinese name.
It was Fèi huà (废话) which more accurately translates to "bullshit" than "nonsense".

[Hex]

You know it's a clusterfuck when fighting spills out across multiple venues.

Edit: Worth reading MZMcBride's post in the latter.

[Vigilant]

You know it's a clusterfuck when fighting spills out across multiple venues.

The weirdest thing on that first page is that the bug is assigned to Tomasz W. Kozlowski aka odder of commons porn fame...

Is there nobody too low for them to hire?


Edit: As most of you know, I'm not a huge fan of Risker, but she hits the nail squarely on the head in this email.
http://lists.wikimedia.org/pipermail/wi ... 70596.html

When Vector skin became the default, users continued to have preferences
for other skins. That went extremely well, and did not negatively impact
editing. (I'll note that there were comparatively few bugs reported when
Vector became default, and none of them prevented people from doing
*necessary* tasks, like referencing.) This was the first major all-sites
deployment of new software in many years, and it was very successful.
There are those who say it wasn't successful because so many people chose
not to switch; however, there's been no research I'm aware of to figure out
why people chose not to do so. (Myself, I still use monobook on enwiki
because it opens large pages much faster, but I use Vector elsewhere.)

The logic that people are only avoiding VE because they hate change is
faulty. They're not using it because it isn't fully functional yet.

They're not using it because it can't handle edits that experienced users
make dozens of times a day yet. And yes, some of them aren't using it
because they hate change. But most of them have very good reasons not to
want to debug software that was far too buggy to have been deployed as
default. No explanation has ever been forthcoming of how we went from an
alpha release that was so feature-deficient nobody was testing it to a
default beta deployment with major features (i.e., referencing and
templates) that were almost completely untested by those who were expected
to use it. The result was not "many eyes find all bugs"....it was "most
eyes stopped looking, and those that stayed have found a whole pile of
bugs, some of which should have been caught before the software became
default". This felt a lot like the kinds of releases the WMF did back in
the 2000s when there were no resources at all. It's not really what people
expect from an Engineering department with over 100 employees and a budget
of $17 million.

People have already written hacks to prevent the tabs from showing up. The
majority of edits by people registered after July 1 are now being done
using "edit source", as are IP editors; over 90% of edits by experienced
editors are using source editing, and there are questions about even the
10% being done on VE because so many are testing it right now. I'm not
going to go so far as to say we should go back to source editing as
default; that decision is being made indirectly by every group that is
editing. Please pay attention to these red flags. I think some goodwill
can be done by reinstating the opt-out preference. It's happening anyway.

A note about the bugzilla: there's a reason why people are commenting
there. They're being ignored in every other venue, and WP:CONEXCEPT
(exceptions to project consensus)[1] has been invoked in regard to this.
Therefore the correct place to appeal the decision is with the community
of Wikimedia developers and (maybe) WMF staff, and one of the most
effective ways of getting the eyes of both groups is to launch and comment
on Bugzillas.

Risker

Absolutely superb analysis from a dedicated, long term insider.
Kudos from a very infrequent admirer.

[Hex]

Just looking at the kids they have in charge renders my shock at this debacle of a project into an "I should have known" stage.

Roan Kattouw (Catrope (T-C-L)) is 22.

His user page at MediaWiki has this interesting list of VisualEditor code commits.

[Vigilant]

Wow.
Ho-ly shit.
http://lists.wikimedia.org/pipermail/wi ... 70600.html

I am getting real sick of the WMF developers shoving shity products down
the throat of their users and saying FUCK YOU. That is the pattern that I
have seen over the recent months starting primarily with Notifcations and
now moving to VE. It really pisses me off that more and more sites are
shoving crap into javascript that just plain sucks, is poorly written and
extremely bloated. Since the devs implemented resource loader it has become
harder and harder to block the poorly developed bloat that has crept into
mediawiki. I used to be able to isolate the JavaScript file causing the
issues (I remember BITS geolocation being a major hog) and just block it.
Now thats not possible any longer. Users WANT a method for turning off an
extremely bloated "Feature" keep in mind that the WMF Staff is dependent
not only on donations by users, but also by what content they produce.
Instead of fucking up stuff why dont the devs spend time going back and
fixing bugs and issues that the community wants fixed. There are major
features and bugs that have been open for over 5 years that need addressed.
Lets stop trying to become facebook and remember what our goal here is.

VE needs a method for disabling the loading of the associated JavaScript,
If users what to test VE again they can, but lets put this piece of shit to
rest until its not a piece of shit

John

That's a pissed off guy.
Go get 'em, John.

[Hex]

Interesting comment from Risker (previous post) as well.

A note about the bugzilla: there's a reason why people are commenting there. They're being ignored in every other venue, and WP:CONEXCEPT (T-H-L) (exceptions to project consensus) has been invoked in regard to this. Therefore the correct place to appeal the decision is with the community of Wikimedia developers and (maybe) WMF staff, and one of the most effective ways of getting the eyes of both groups is to launch and comment on Bugzillas.

[Vigilant]

Interesting comment from Risker (previous post) as well.

A note about the bugzilla: there's a reason why people are commenting there. They're being ignored in every other venue, and WP:CONEXCEPT (T-H-L) (exceptions to project consensus) has been invoked in regard to this. Therefore the correct place to appeal the decision is with the community of Wikimedia developers and (maybe) WMF staff, and one of the most effective ways of getting the eyes of both groups is to launch and comment on Bugzillas.

Pssst: I bolded that part in my post.

[Vigilant]

Jimmy's talk page is on fire...

Ouch.

In the past when I've made major public mistakes, the best strategy was a sincere, heartfelt apology. Keeping it short tends to make it more credible. Since WMF doesn't seem inclined to apologize for the current condition of VE, perhaps you could do it for them.—Kww(talk) 19:13, 22 July 2013 (UTC)

The most important thing that happened while you were away is that the Visual Editor was released to the broad community in spite of having an astonishing number of critical bugs and being almost unusable for some basic functions, such as adding references. See WP:VE/F for results. (For the record, I'm hugely in favor of VE, but another month of debugging would have paid great dividends. The release came with no feature freeze -- major functionality was being added right up to the last moment, with predictable results.) Looie496 (talk) 15:16, 22 July 2013 (UTC)

The saddest thing about this is the WMF ignored its own research. Of course, it had precedent: it ignored its own research with Echo as well.

VE reduces the likelihood of a newbie making his first edit by 43%
Echo increases the chance of a new editor being blocked by 20%

In both cases, WMF attempted to portray objections by English Wikipedia as being simply a result of conservatism, despite the fact that their own research demonstrates that the objections are well founded.—Kww(talk) 17:12, 22 July 2013 (UTC)

Agree with the above. This is serious, and WMF should listen and change attitude accordingly. The attitude of WMF developers, asking for "zen acceptance" of critical decisions never discussed with the community ([1]), is worrying. -- cyclopiaspeak! 17:19, 22 July 2013 (UTC)

Having worked as a developer myself, I don't quite agree with those points. There is no way to introduce major new functionality without major disruption: the bad thing here is that the developers, probably as a result of being understaffed and overpressured, have not followed standard practices in the software industry. Looie496 (talk) 17:46, 22 July 2013 (UTC)

I have worked as a developer, manager, director, and CTO. I will agree that this is not really the developers' fault: the blame lies with their management that has refused to withdraw the product until the errors are corrected. There's certainly a future that includes VE, but when a piece of software explodes this badly, you don't continue to roll it out.—Kww(talk) 17:53, 22 July 2013 (UTC)

Welcome back Jimbo, as a question related to the software rollouts, do you personally believe that the WMF has continued in the heart of what you meant when you wrote at User:Jimbo Wales/Statement of principles- "Any changes to the software must be gradual and reversible. We need to make sure that any changes contribute positively to the community, as ultimately determined by the Wikimedia Foundation, in full consultation with the community consensus." (bolding from original)? As Kwww states above, the Community does seem to get a response from the WMF of (in Kww's words) "objections by English Wikipedia as being simply a result of conservatism", that kind of response, in my opinion, does seem to stall any "consultation with the community consensus", but I am taking Kww's word for it that their response is that truly that overtly "Daddy knows best", I would like your opinion as you are close to the WMF and still close to the Community at large.Camelbinky (talk) 19:55, 22 July 2013 (UTC)

That's a beating right there.

[Vigilant]

No place for new editors/IP's to test VE?

I just gave an IP a uw-test1 warning which directs them to the sandbox. It occurred to me to check if VE works with the sandbox - it doesn't. So how can we direct these editors to a place where they can play with VE? --NeilN talk to me 20:53, 22 July 2013 (UTC)

LMAO!

Confirming and enshrining for all time the fact that the WMF devs don't edit wikipedia nor do they help new users try to.

Edit: Followup

Well registered users can use their own sandbox but that doesn't work for IPs as they cannot create pages. User:Sandbox is a redirect to Wikipedia:Sandbox at present as it was apparently causing a lot of confusion with a user sandbox and the page it was redirect to. Perhaps the VE team could register user:VEsandbox or something for this purpose? Thryduulf (talk) 21:08, 22 July 2013 (UTC)

I strongly encourage the VE team to look into this as right now new editors (who are supposedly the target audience for VE) have no place to test or are being directed to a page where the editing UI is completely different. --NeilN talk to me 21:13, 22 July 2013 (UTC)

This problem was brought to their attention before the roll out to IP, but as you can see in many discussions about VE, rolling out seems to be more important than anything else. --NicoV (Talk on frwiki) 21:25, 22 July 2013 (UTC)

I almost feel sorry for the dev team.
They must have all been very bad in former lives to deserve to work for Mo:eller.

[Vigilant]

From the mailing list:
http://lists.wikimedia.org/pipermail/wi ... 70610.html

On Mon, Jul 22, 2013 at 9:51 AM, Eran Rosenthal <eranroz89 at gmail.com> wrote:
> Hi,
> When the ResourceLoader was deployed (or even before it) to production,
> there were migration development guides for gadget/extension developers:
>
> -
> http://www.mediawiki.org/wiki/ResourceL ... developers
> -
> http://www.mediawiki.org/wiki/ResourceL ... urceLoader
>
> Such guides allowed easier adoption of ResourceLoader. We need something
> similar for the visual editor:
>
Yes we do . More generally, VE needs plugin infrastructure. Most of
it is already there, and I'm working on the last bits of it.

> - Migration - What are the recommended steps to make gadget/extension
> VE adapted? [with answers to questions such as: how to get the underlying
> model - instead of $('#wpTextbox1').val() and what is this model [and what
> modifications to the underlying model are supported/to be avoided by
> gadgets/user scripts ] ]
> - Development with the VE: guides with explanation for common editor UI
> customization, and what is recommended API for it (for example: add custom
> toolbar buttons).
>
These are excellent suggestions for documentation we should write once
the plugin infrastructure work is done. I intend to do this in the
next few weeks.

Roan

Nice to see that they planned this out well.
1) Release the VisualEnema.
2) Work on APIs for existing stuff to work with VE
3) Write documentation after coding

Fucking amateurs.


Another interesting email
http://lists.wikimedia.org/pipermail/wi ... 70549.html

[Vigilant]

I don't know what to think about this email...
Palace coup?
http://lists.wikimedia.org/pipermail/wi ... 70620.html

On 23/07/13 04:36, Erik Moeller wrote:
> On Mon, Jul 22, 2013 at 9:51 AM, Tyler Romeo <tylerromeo at gmail.com> wrote:
>> Seriously, though, I understand why the VE team might want to force
>> everybody to use VE
>
> That's a misrepresentation of the facts. We're not talking about
> "forcing people to use VE". We're talking about whether there should
> be a preference to hide all aspects of VE from the user interface.

No, we're talking about whether the preference to hide all aspects of
VE should be in the "gadgets" tab or the "editing" tab.

We're also talking about whether that preference should be technically
consistent across all wikis, or whether it should be done in a
wiki-specific manner.

If the preference was consistent across all wikis, then we could
easily do statistics on its use. If, in a year or so, we feel that the
users who disabled VE should reconsider it, we could send them a
message or display a popup. It's also possible to do this with gadget
preferences, just more difficult.

Now that the gadget is in place and widely used, I can't really
believe that this is about encouraging the use of VE. To me, it looks
like a token gesture by WMF demonstrating support for VE, but without
any perceivable impact aside from angering VE's detractors. It's a
foot in the ground; a position taken. It's a message to the old guard
that their opinions will be ignored. As such, it's not surprising that
the old guard are upset.

If it was up to me, I would try to win them over with awesome
features, rather than prod them with a stick.

-- Tim Starling

[Hex]

Pssst: I bolded that part in my post.

Oops, so you did. I blame any lapses on my attention on it being over 90°F, which is about as hot as it gets around here.

[EricBarbour]

I blame any lapses on my attention on it being over 90°F, which is about as hot as it gets around here.

Oh, you poor little Brits. A little hot weather and you just melt.
Have a look at my thermometer.

Now that the gadget is in place and widely used, I can't really
believe that this is about encouraging the use of VE. To me, it looks
like a token gesture by WMF demonstrating support for VE, but without
any perceivable impact aside from angering VE's detractors. It's a
foot in the ground; a position taken. It's a message to the old guard
that their opinions will be ignored. As such, it's not surprising that
the old guard are upset.

If it was up to me, I would try to win them over with awesome
features, rather than prod them with a stick.

-- Tim Starling

Too little too late, Mr. Starling.

[Vigilant]

What the fuck is Forrester high on?
http://lists.wikimedia.org/pipermail/wi ... 70621.html

Adding a preference to disable VisualEditor in normal user preferences
(rather than making it as easy as possible for gadgets to disable if people
so chose) would be a lie.

It would imply that this is a preference​ that Wikimedia thinks is
appropriate. This would be a lie. For a similar example, see the removal of
the "disable JavaScript" option from Firefox 23.

It would imply that this is a preference that Wikimedia will support.
This would be a lie. We have always intended for VisualEditor to be a
wiki-level preference, and for this user-level preference to disappear once
the need for an opt-in (i.e., the beta roll-out to production wikis) is
over.

It would imply that Wikimedia thinks preference bloat is an appropriate way
forward for users. This would be a lie. Each added preference adds to the
complexity of our interface, increasing even further the choice paralysis
and laughable usability of our existing preference system.

It would imply that Wikimedia thinks preference bloat is an appropriate way
forward for expenditure of donor funds. This would be a lie. Each added
preference adds to the complexity of our software - so increasing the cost
and slowness of development and testing, and the difficulty of user support.

It would imply that Wikimedia can get rid of under-used preferences. This
would be a lie. We do not have a successful track record of getting rid of
preferences, even when used by a handful of our users, even when set away
from default mostly by inactive accounts; accepting this form of product
debt now on the spurious claim that we'll pay it off later is untrue.

It would imply that getting rid of preference later rather than now would
in any way reduce the outcry. This would be a lie. The very few times we
have done this, the arguments from those campaigning for retention are
generally emotive and not based on the above points - that "it's just a
little preference, not harming anyone", that Wikimedia "has enough money
for just this one item", or that the preference is the only thing keeping
the user from leaving - an argument that almost always is visibly proven
untrue after the preference is removed.

​Creating such a preference is a lie, and a lie I cannot endorse.

​J.
--
James D. Forrester
Product Manager, VisualEditor
Wikimedia Foundation, Inc.

A better example of the dangers of inbreeding I could not come up with.

[Mason]

What the fuck is Forrester high on?
http://lists.wikimedia.org/pipermail/wi ... 70621.html

A better example of the dangers of inbreeding I could not come up with.

Wow, what an asshole.

It's like he wants to be Steve Jobs, but he's doing it by emulating the "Steve Jobs acts like a colossal dick to people" bit while completely forgetting the "Steve Jobs made products people want" bit.

[Vigilant]

This really looks bad for Forrester.
Tim Starling, a WMF developer, directly refuting his points in a public mailing list and rightly so.
http://lists.wikimedia.org/pipermail/wi ... 70633.html

On 23/07/13 11:35, James Forrester wrote:
> It would imply that this is a preference that Wikimedia will support.
> This would be a lie. We have always intended for VisualEditor to be a
> wiki-level preference, and for this user-level preference to disappear once
> the need for an opt-in (i.e., the beta roll-out to production wikis) is
> over.

The feedback from established users [1] and the results from Aaron
Halfaker's study [2] suggest that opt-in would be the most appropriate
policy given VE's current level of maturity. That is, disable it by
default and re-enable the preference.

A proponent of source editing would claim that the steep learning
curve is justified by the end results. A visual editor is easier for
new users, but perhaps less convenient for power users. So Aaron
Halfaker's study took its measurements at the point in the learning
curve where you would expect the benefit of VE to be most clear: the
first edit. Despite the question being as favourable to VE as
possible, the result strongly favoured the use of source editing:

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

On the Wikipedia RFC question "Wikimedia should disable this software
by default?", there were 30 support votes and 17 opposed. But many of
those 17 oppose votes assumed that VE is beneficial to new users. Now
that we know that that isn't the case, the amount of support for
enabling VE by default would surely be very small indeed. If it's not
beneficial for either established or new users, why have it?

It's not like the VE team are sitting around with no testing to do, no
features to add, and no bugs to work on. So the argument that you need
people looking at VE in order to provide feedback seems shallow. (Ed note: 500+ of them)

Round-trip bugs, and bugs which cause a given wikitext input to give
different HTML in Parsoid compared to MW, should have been detected
during automated testing, prior to beta deployment. I don't know why
we need users to report them. (Ed note: My favorite part)

Perhaps the main problem is performance. Perhaps new users are
especially likely to quit on the first edit because they don't want to
wait 25-30 seconds for the interface to load (the time reported in
[3]). Performance is a very common complaint for established users also.


[1] <https://en.wikipedia.org/wiki/Wikipedia ... Editor/RFC>

[2]
<https://meta.wikimedia.org/wiki/Researc ... rs/Results>

[3] <https://office.wikimedia.org/wiki/Visua ... user_tests>

MzMcBride bringing it home with a sledge hammer.
http://lists.wikimedia.org/pipermail/wi ... 70635.html

James Forrester wrote:
>​Creating such a preference is a lie, and a lie I cannot endorse.

Oh, for Christ's sake, James. The last thing this thread needs is very bad
pseudo-poetry. And that's not a lie.

What we need is for you and Erik to recognize that you're wrong and to
make this right. Is there anyone besides you and Erik who agree with the
position you're taking here?

You may not respect my opinion or the opinion of the many editors who have
expressed the same opinion on-wiki, but I would think you could show a
little professionalism and a little deference to your colleagues and
peers, _all_ of whom have tried, as diplomatically as possible, to tell
you that you're wrong without completely undermining your role as the
Product Manager of VisualEditor.

You're very quickly exhausting good will both inside and outside the
Wikimedia Foundation. You're eroding public support for VisualEditor and
_every future project_ you'd like to work on/lead at the Wikimedia
Foundation. And for what? Please be reasonable and do the right thing.

MZMcBride

Calling him out for bad poetry, too. Harsh, man.

[EricBarbour]

All he needs is a lollipop.

[Vigilant]

I was thinking more along these lines

[Vigilant]

Fuckin A. Staggering arrogance.
http://lists.wikimedia.org/pipermail/wi ... 70643.html

On Mon, Jul 22, 2013 at 6:35 PM, James Forrester
<jforrester at wikimedia.org> wrote:
> It would imply that Wikimedia thinks preference bloat is an appropriate way
> forward for expenditure of donor funds. This would be a lie. Each added
> preference adds to the complexity of our software - so increasing the cost
> and slowness of development and testing, and the difficulty of user support.

I want to elaborate on this point a bit, because some of the
complexity cost may have gotten lost in the discussion so far.

It is true that providing a mechanism to hide all evidence of
VisualEditor, as it currently exists, from the user interface entirely
is utterly trivial, from a technical standpoint.

However, it is important to note that VisualEditor is not purely a
means of editing pages, but will also provide, in future,

- a mechanism for quickly performing simple metadata manipulation
(e.g. categories);
- a subset of rich-text editing functionality for edit summaries, log
entries, etc.;
- a default interface for posting or replying to comments (in Flow);
- etc.

On the first point, right now, we're approaching categories and
similar page metadata from the point of view of the editing surface as
an entrypoint. This makes sense if you simply try to map all aspects
of markup (which is inherently positional, even where it carries no
positional value like categories) into an editing interface. VE is at
least providing a "Page Settings" dialog that gets rid of the
positional context for categories, etc.

However, from a user's standpoint, it still doesn't make a ton of
sense to do it that way. If I just want to add a category, I shouldn't
have to invoke an editing surface at all. Similarly, if I want to turn
a page into a redirect, I shouldn't have to edit the page at all. As
most of you know, some gadgets like HotCat already operate on a
similar principle.

The VisualEditor team is going to revisit some of these types of edit
operations from the standpoint of "what's the fastest and most
intuitive way to perform this operation" rather than "how do we
integrate this with the editing interface".

So, when a user has "disabled VisualEditor", should those affordances
then also disappear, if they happen to be provided through the
VisualEditor MediaWiki extension? Should VE be hidden from view in
contexts where it could be safely and speedily initialized, on new
content without the complexity of existing pages?

As VisualEditor becomes more pervasive in the user experience, the
complexity of maintaining a preference in a consistent and
non-confusing manner will go up, and the cost of having users who
could otherwise successfully use VE not see it will increase as well.
Users who hate VE for editing articles with templates might not hate
it for writing comments, but if they have that preference set, they
might never see it for the latter use case.

This is one other reason why we think it's preferable to focus on
ensuring that the user experience _with VE present_ is minimally
disruptive, rather than creating a preference that completely hides VE
from view, and could in future be potentially misleading and/or
harmful to the user experience.

In other words, as we add VE in other contexts, we'll also want to
make sure that source mode is easily accessible in all those contexts,
and that there is always a default fallback on browsers where VE can't
be used.

I'm not saying that we can't find a compromise here - just that
there's more long term complexity than one might see immediately. One
compromise I could imagine is to offer a preference for the preferred
_default_ editor, and honor it consistently (in the labeling of the
tabs, in whatever mode gets primary presence in contexts where we
can't offer a choice, etc.).

Erik

--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

You just don't understand how great we are and how much you will grow to love this cowpat project.

[Vigilant]

http://lists.wikimedia.org/pipermail/wi ... 70645.html

Erik, please stop and listen. Almost without exception, people from all
areas of the Wikimedia community are calling on a re-evaluation here. It's
lovely to have this vision of the Mediawiki future. But until you get
VisualEditor right, you need to get your feet back on the ground. People
were asking for a VE-like editing interface for years, and you're getting
close but you aren't there. However, people haven't asked for different
ways to do categories (and in fact, different projects use categories in
different ways). People weren't clamoring for many of the features in
notifications (and it took months to get it functioning at the level of the
features it replaced), and they've not asked for most of the features that
are being highlighted with Flow.

And none of it matters if you cannot provide a good enough VE platform to
make it attractive to experienced editors. Pull back on the investment in
these other projects until you have this one right. For all the
disagreements there may be, I don't think anyone really wants to believe
that you'd rather 90% of experienced editors leave than have to change your
vision.

Risker

Don't do it, Erik, It's a trap!
She's trying to deflect you from your well deserved moment of glory.
Soldier on and ignore these foolish mortals.

[The Adversary]

What the fuck is Forrester high on?
http://lists.wikimedia.org/pipermail/wi ... 70621.html

A better example of the dangers of inbreeding I could not come up with.

Wow, what an asshole.

It's like he wants to be Steve Jobs, but he's doing it by emulating the "Steve Jobs acts like a colossal dick to people" bit while completely forgetting the "Steve Jobs made products people want" bit.

Bingo.
And obviously Erik M. is the same.

[The Adversary]

Don't do it, Erik, It's a trap!
She's trying to deflect you from your well deserved moment of glory.
Soldier on and ignore these foolish mortals.

(Yes; everyone who ever wanted to edit wikipedia actually had a secret wish...to become a software debugger!
And only you, Erik, understood that ....)

[Hex]

Oh, you poor little Brits. A little hot weather and you just melt.

We're a lot further north than you guys, y'know! And this is the southern part of the country. My other half is from way up in the north, and they really struggle.

Have a look at my thermometer.

Nice. Dry or humid? I've been in temperatures like that plenty of times in other countries - but with air conditioning. Domestic aircon is not something the UK has ever gotten to grips with. (When I said 90°F, I meant inside.)

[Hex]

preference bloat

Fuck me. Is he being deliberately dishonest or is he just blind? (WHYNOTBOTH.GIF) Have you seen the amount of irrelevant crap in Special:Preferences that 99% of users will never, ever need?

[dogbiscuit]

preference bloat

Fuck me. Is he being deliberately dishonest or is he just blind? (WHYNOTBOTH.GIF) Have you seen the amount of irrelevant crap in Special:Preferences that 99% of users will never, ever need?

If they applied the creativity that they have applied to defending the indefensible to the original design they wouldn't be in this mess.

Their whole defence is predicated on VisualEditor being essentially fit for purpose, and their thinking is based on this lie. Until the development team managers stop lying to themselves (presumably in the misguided belief that these are not really big problems but something that will go away in a few weeks and they can claim this was a fuss over nothing) they cannot hope to manage the situation effectively.

[thekohser]

preference bloat

Fuck me. Is he being deliberately dishonest or is he just blind? (WHYNOTBOTH.GIF) Have you seen the amount of irrelevant crap in Special:Preferences that 99% of users will never, ever need?

James Forrester really shouldn't use the word "bloat", ever.

[Anroth]

Is it possible to mention people without resorting to fat jokes?

[Hex]

Is it possible to mention people without resorting to fat jokes?

+1

That shouldn't be happening.

[DanMurphy]

Wales asks for:

...a concrete example of current functionality that you are afraid of losing under Flow? As a side note, Flow is a long way off so while it's good to be having conversations about it early, I'm this week mainly focussed on understanding the state of the world with respect to the visual editor.--Jimbo Wales (talk) 10:06, 23 July 2013 (UTC)

A fellow provides a long (and what strikes me as cogent, though not my area of expertise) response:

For the VE, surely the major concerns right now are with respect to templates; the VE design seems to have been centered around formatting, with little foresight on how creation of complex content would be used (it seems clear that they didn't create a single paper prototype for the templates dialog, or they would have found basic mistakes like the dialog obscuring the text in the article that one must read to populate the template).

With respect to both the VE and Flow I'm primarily concerned about how the community creates new backlog review processes (like the User:Snotbot/AfD's requiring attention, User:Wcquidditch/wikideletiontoday or the Wikipedia:Article Rescue Squadron/Rescue list) without the need to request developers' support. Those community tools heavily depend on the wiki support for semantic knowledge creation (tags, templates, categories, transclusion)... and there's nothing like that planned in the roadmap for the new tools.

This focus in the flexibility of the current existing platform seems to be completely lost in all WMF analysis, even though it's one of the project's main assets. That's why all editors are so rabidly focused on asking for guaranteed support of all current wikitext. I see Wikipedia as the major example of a semantic platform in the world (stronger and wealthier even than Google's Freebase), and the only successful deployment of a user-friendly semantic network in a massive scale. Forcing the community to rely on "Office"-level tools (simple word-processor editing and simple mailing support) is a disservice to what Wikipedians have built as an ecosystem for collaborative content creation.

The focus on specialized tools, fine-tuned for particular use cases, can't compete against the flexibility of the current semantic wiki tools. There seem to be some grand visions to support some workflow creation module in Flow, but frankly the prospect of depending on a yet-to-specify tool of uncertain possibilities and built from scratch is less appealing than using the existing, well tested mediawiki platform. Which is a shame, because at least the VisualEditor has potential to become the largest and user-friendliest semantic content creation tool in the world, if only its developers could see it that way instead of as a simple pretty printer for raw text. Diego (talk) 11:01, 23 July 2013 (UTC)

Wales' response to all that?

"It seems clear that they didn't create a single paper prototype" - seriously, the editorializing is insulting, demeaning, and unhelpful. Let's just focus on the facts and stop insulting good people who have worked hard to develop something new. It's just not helpful. If you believe it to be true that blame must be assigned, that's fine. Keep it to yourself, I don't want to hear it. NPOV.--Jimbo Wales (talk) 11:41, 23 July 2013 (UTC)

This is the fashion that you might use to bully a child. Surely it doesn't work on adults? And has he so internalized Wikipedia's culture that he actually thinks the assertion that "so-and-so's work is subpar" is "insulting and demeaning?" Does he actually have the childish belief that "worked hard" (I have no idea if that's true) is a defense against failure? I honestly don't know.

[dogbiscuit]

Does he actually have the childish belief that "worked hard" (I have no idea if that's true) is a defense against failure? I honestly don't know.

I'd rather have lazy people who succeeded than hard working failures. (Time to bring out the Hammerstein-Equord quote)

[rhindle]

Wales asks for:



Wales' response to all that?

"It seems clear that they didn't create a single paper prototype" - seriously, the editorializing is insulting, demeaning, and unhelpful. Let's just focus on the facts and stop insulting good people who have worked hard to develop something new. It's just not helpful. If you believe it to be true that blame must be assigned, that's fine. Keep it to yourself, I don't want to hear it. NPOV.--Jimbo Wales (talk) 11:41, 23 July 2013 (UTC)

This is the fashion that you might use to bully a child. Surely it doesn't work on adults? And has he so internalized Wikipedia's culture that he actually thinks the assertion that "so-and-so's work is subpar" is "insulting and demeaning?" Does he actually have the childish belief that "worked hard" (I have no idea if that's true) is a defense against failure? I honestly don't know.

Yes, everyone gets a trophy! How about tell them put on on their Big Boy pants, admit there's something wrong and get it fixed?