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 On 23 July 2013 02:35, Erik Moeller <[email protected]> wrote: > On Mon, Jul 22, 2013 at 6:35 PM, James Forrester > <[email protected]> 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 > > _______________________________________________ > Wikitech-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
