On Mon, Jul 22, 2013 at 6:35 PM, James Forrester <jforres...@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
