If we are going to discuss Minimal Viable Product, then we might want to take note of the line in the Wikipedia article that says:
"The product is typically deployed to a subset of possible customers, such as early adopters that are thought to be more forgiving, more likely to give feedback, and able to grasp a product vision from an early prototype or marketing information." More than any specific deficiency in VE, I think the aggressive roll out did the most to cause user dissatisfaction. If you want to claim that VE is a minimal product, then it stands to reason that it wouldn't be ready for all users. There are plenty of ways to stage a deployment and gather feedback that are intermediate between the early opt-in and turning it on for all users everywhere. The WMF took nearly the most aggressive deployment path possible while the quality of the software really didn't warrant that. -Robert Rohde On Thu, Aug 1, 2013 at 12:00 AM, Erik Moeller <e...@wikimedia.org> wrote: > Hey Kevin, > > contrary to your belief (and in spite of your desire to blame me ;-), > I actually have a ton of respect for the opinions you've expressed > throughout the process, and for the level of detail and time you've > committed to it, including helping in a hands-on manner. I don't agree > with you on quite a few issues, obviously, but I've really enjoyed > reading your comments, which are always well-reasoned and on point. > :-) I hope you don't lose your patience with us, as you really are the > kind of person we enjoy working with due to your diligence and the > quality of your reports. > > So, if you've personally felt that it's been disruptive for you and > caused you annoyance and frustration, I'm sorry, because I do respect > your opinion and your work as an editor. > > On the subject of an appropriate MVP: > >> If you had followed that, and understood that the Minimum Viable Product >> included cut-and-paste, table editing, and maybe the ability to successfully >> and completely edit the hundred or so most edited articles out of all the >> millions, you wouldn't have hit the level of pushback you've encountered. > > Couple of diffs from a few minutes ago of table edits: > https://en.wikipedia.org/w/index.php?title=Major_League_Soccer&curid=71802&diff=566676293&oldid=566669395 > https://en.wikipedia.org/w/index.php?title=List_of_True_Blood_characters&curid=23290782&diff=566675268&oldid=565993704 > > That's not just plain vanilla tables, but tables with inline CSS > specified by hand, templates inside cells, etc. No roundtripping > issues or other problems as far as I can tell. > > The kind of table you want us to make work well is this type: > > <onlyinclude>{| class="wikitable" style="margin: auto; width: 100%" > |- > ! colspan="2" rowspan="2" style="width:3%;"|Season > ! rowspan="2" style="width:5%;"|Episodes > ! colspan=2|Originally aired > ! colspan=2|DVD release > |- > (...) > | style="background:green; color:#134; text-align:center;"| > | style="text-align:center;" colspan="2"| '''[[List of Big Time Rush > episodes#Film|Film]]''' > | style="text-align:center;" colspan="2"| {{Start date|2012|3|10}} > | style="text-align: center; top" {{N/a}} > | style="text-align: center; top" {{N/a}} > > which injects this kind of template: > https://en.wikipedia.org/w/index.php?title=Template:N/a&action=edit > > In other words, a table partially constructed out of table cell templates. > > Now, I understand that you've dealt with dirty diffs resulting from > people editing pages using those templates, and I know that sucks, so > sorry about that - but it's a hard problem, and I don't think it's > reasonable to frame it as an MVP-level one. The reasonable expectation > is to fix roundtripping issues on those hairy tables as soon as > possible, and ideally avoid any kind of accidental leakage of CSS into > the UI. But as you know, some of these templates don't even map > against HTML elements, so it's not a trivial issue. > > We could spend literally months trying to make > tables-constructed-out-of-templates work nicely, and it would still be > a shitty experience, and those would be months not spent on actual MVP > features. Before we sink countless person hours into > tables-constructed-out-of-templates, I think we need to step back and > see what our options are for solving that particular problem well in > the long run. Perhaps there's a type of table-template we can support > well, and gradually migrate all tables to it, but it won't be easy. > > I appreciate that you created the "Disable VE" template which makes it > possible to shield pages that are vulnerable to dirty diffs from VE. > That was a great hack (we should have included _that_ one with the > MVP, it would have saved users a lot of pain), and should help in > cases where an immediate fix isn't feasible. > > As for copy-and-paste, yes, it's pretty wonky still, and I'm sure > causes a fair bit of frustration for first-time VE users who have no > experience with wikitext. However, it is there within a VE session, > and we see very few diffs where users are causing problems due to > broken copy-and-paste. Does that not match your experience? I've just > inspected another round of 100 diffs and didn't see a single > copy-and-paste related issue. Contrary to Andreas' claim, copying > references isn't completely broken, but the bug is pretty nasty when > it hits, so we'll get it fixed soon. > > As for performance, it already was a high priority before release, and > we made huge gains in server-side performance thanks to the deployment > of a completely new caching infrastructure for VisualEditor and lots > of optimizations on Parsoid (still more to come). Where we could have > done better prior to release was client-side performance -- we didn't > do sufficient profiling there, and pushed it off to later; but we've > made pretty significant improvements in the last month already to the > point that even Adam Cuerden remarked on it. :-) > > I don't agree that focusing more on the pain points you name would > have reduced the level of pushback significantly. You don't mention > nowiki issues, but guess what, across the communities, aside from > performance, that's the single biggest pain point we've heard and > focused a lot of attention on already. And it's exactly the kind of > issue you only really see fully in real world deployment. Or what > about users who encountered a bug or crash when they used VE and > concluded immediately that it could not possibly be ready? Or what > about the users who want us to process wikitext inside VisualEditor? > They'll continue to point to that as evidence of brokenness. Or the > users who say that VisualEditor is a horrible idea, and we should just > all be using markup? "It's a big giant waste of money, obviously! Kill > it!" All of those opinions exist in fair measure. > > But I don't want to argue with you - I'm just saying things are a bit > more complex and nuanced. In any case, we're also not arguing for not > giving an inch, so your complaint about "You're not listening still!" > is really not fair. (Would I be spending an hour before midnight > engaging in this discussion with you if that was true?) I think James' > proposal on the talk page is a reasonable middle ground. Users get a > separate VisualEditor tab, clearly labeled beta, with a clear one-time > notice informing them what that means. If they want to hide it, that's > a click away, and the ones who already have hidden VE won't see it > again. Why don't we try that for size and see if it helps us get to a > reasonable pattern of working together? > > 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-requ...@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-requ...@lists.wikimedia.org?subject=unsubscribe>