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 erik@wikimedia.org wrote:
On Mon, Jul 22, 2013 at 6:35 PM, James Forrester jforrester@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
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l