Talk:Strategy/Wikimedia movement/2018-20/Transition/Discuss/Cluster B

Questions to discuss

Since there was a limited time for discussion at the Global Conversations, and not everyone who wanted to participate was present, the same discussion around this cluster can continue here on Meta (the focus would be, ideally, on the same questions that attendees tried to answer during the events - pasted below) --Abbad (WMF) (talk) 21:54, 18 December 2020 (UTC).

• Guiding question: What are the immediate steps we need to take to implement this initiative cluster?

Supporting questions:

• Who needs to be involved and what does their involvement look like?
• What do we want to achieve more specifically in 18 months?

Evangelism

Development of Wikimedia software products already tends to include standard UX practices - there is user research, usability testing, user feedback during development, beta flags and so on. I'm sure it can be improved but I don't think there are any low-hanging fruits there. The bottleneck today IMO is more on the community side - once-in-a-million edge cases affecting experienced users get elevated above major usability issues for new users because some editors (probably a small minority, but then we don't really have any lightweight means for determining whether a given opinion is held by a minority or the majority so no one knows for sure) demand them to be fixed. More generally, change aversion slows everything down. (Change aversion is, of course, a rational thing - even if the new behavior is better by all objective measures, it invalidates muscle memory and experienced users need to relearn things. That is a burden on volunteers, but that burden needs to be evaluated against the benefit to people who did relearn (or, in the case of new users, just learn) the new behavior and now have an easier time due to it. That rarely happens in community discussions.)

This is largely the consequence of lack of understanding and attention amongst experienced editors to the importance of retaining new editors. That is normal - people automatically perceive when some change affects them; it takes intent and effort to think about how it effects others, and much more so to try to see with the eye of someone who is unfamiliar with the wiki tools and policies. It often requires some research, too. The importance of editor retention is also something that needs to be translated into things that are immediately understandable to be problems, such as not having enough patrollers. In short, understanding the importance of editor retention, both in the abstract and for specific features, is real work, and it would be unfair to blame volunteer editors who feel it is not the work they want to do in their volunteer time.

So, in my opinion, the low-hanging fruit for UX is an organized effort to make accurate but catchy and easy to grasp explanations about how UX and social problems affect new editors and how low editor retention affects experienced editors. Evangelism, for lack of a better term. Setting up such a team (or comittee? these kind of things always benefit a lot from volunteer contribution, but then it's up to volunteers to decide whether they see it as a good use of their time) should be one of the immediate steps IMO.

(This is not some kind of big original insight, of course. It builds on the recommendation made by the Product & Technology Working Group, which I was a part of.) --Tgr (talk) 00:20, 21 December 2020 (UTC)

Why would you link to the Wikipedia article of "technology evangelist", which is tagged for possibly containing "original research"? Furthermore, why would you cast fault on "change aversion" (or whatever you call it), which I think is not as harmful as, say, radical changes without consultation with communities? "Change aversion" reflects Foundation's decisions that have provoked negative community reactions. "Change aversion" also reflects how big corporations and big companies and any other big influential may impact how projects should functions. "Change aversion" also reflects how any radical change may affect not just software itself but also stability of software, something that neither the cluster nor the recommendation has addressed... has it? If that's not the case, then why else would you be so negative about "change aversion"? I am not that negative about "change aversion", and I don't blame "change aversion" for slowdown.

The blame lies elsewhere, like external barriers. One of external barriers is lack of very, very talented and well-educated candidates who would have improved the Foundation and/or the projects. Another is poverty and insufficient resources, like bluetooth keyboards for mobile devices. Unfortunately, the attention on internal barriers (like "issues" with projects within) has been sought (especially by note-takers) and has distracted us from resolving external barriers. I really hope you reconsider your negativity on "change aversion". Can you do that? George Ho (talk) 01:03, 21 December 2020 (UTC)

Oh... let me put it this way: change aversion is good... isn't it? George Ho (talk) 01:08, 21 December 2020 (UTC)

Radical changes without consulting the stakeholders are certainly more harmful; fortunately, they basically never happen. Change aversion on the other hand is omnipresent; and while it is important to understand the burden change places on power users, it's also important to understand the innovator's dilemma. A stronger partnership between software developer organizations and wiki communities would be needed to strike a balance between those two, and some kind of systematic outreach and teaching (I don't love the term "evangelism", which is too often used as the synonym for marketing, but I don't have a better one) seems to me like the way to get there.

External barriers can of course be significant, but usually we can't do a lot about them (that's why they are called external).

(I don't understand you last question, probably because I haven't seen the movie.) Tgr (talk) 01:30, 21 December 2020 (UTC)

Somehow, I don't see a Wikipedia article about "change aversion". Then I checked the background of the author who wrote a blog article about "change aversion". Seems that the company likes to make newer innovations, doesn't it? Then I found some paper written by Google authors using the phrase "change aversion". Then I found out there's "loss aversion", which is economy-related. Still trying to find out origins of "change aversion" term. Weren't you borrowing the term from a Google paper, or did it come earlier than that?

I don't know which organizations (of software development) the Movement wants to choose, even when tempting. However, I know from common knowledge that software won't work well without a compatible hardware. Trying to insert a software incompatible with a hardware (old or new) and its drivers would be chaotic (or... how else do you call it?). Using a bootleg, buggier, unstable, or poorly developed software would be worse. Maybe I can say the same about risks of seeking computer/server hardware organizations, which have worked their butts off to develop whatever can carry internally. Or is seeking hardware establishments more costly than software ones? (BTW, I was making an American pop cultural reference. My apologies if you've not seen it; still, it's pretty good, from what I heard.) George Ho (talk) 02:32, 21 December 2020 (UTC)

Better support for mentors and patrollers

The experience of a user when they are new to Wikipedia is in many ways the most crucial; they are unfamiliar with the site, uncertain in what they are doing, vulnerable, and very easy to drive away. The UX of experienced users is mostly an efficiency problem; the experience of new users is mostly a retention problem. The Wikimedia Foundation did put a lot of effort in the last decade into improving the experience of new users, but in my opinion has mostly overestimated how much of that experience comes from software features, and underestimated how much of it is social experience - good or bad interactions with other users, especially other users who specifically focus on user-to-user interaction, ie. mentors and patrollers. New users not get enough human support, and having too many negative interactions with patrollers, is a major factor in our retention problems. Those negative interactions are largely a result of high load (jut reverting is much less effort than reverting, thanking the user for their contribution and explaining them what went wrong; when you need to review hundreds or thousands of edits a day, those time differences add up), and high load is a result of poor tooling.

Power user tooling is something the WMF gave low priority to (although the creation of the Community Tech team improved the situation somewhat), based on a false dichotomy between the needs of new and experienced users. But better tooling for power users workflows that involve interacting with newcomers is very much to the benefit of those newcomers. It's not rocket science either - just being able to deploy friendly canned messages with no extra effort when reverting or nominating something for deletion would go a long way. So finding an owner for those feature areas, and meaningfully improving them in the next 18 months, would be a good implementation step.

(Full disclosure: when I have my staff hat on, I work for the Foundation's Growth team, which develops some tools for mentors.) --Tgr (talk) 00:53, 21 December 2020 (UTC)

The UX of experienced users is mostly an efficiency problem - yes, for them; but it's also a false positive problem. Wrong blocking of newbies and wrong deletion of articles they created happens more than they should.

The UX of the experienced has a couple of other often-forgotten properties:

• It's heavily customized, per site and per user, with user scripts, CSS, gadgets, etc.
• It's dramatically different from the new users' experience:

Experienced editors	Readers and new editors
Logged in	Often logged out (which may mean very reduced permissions and different experience)
See banners and site notices for logged-in users, don't see banners for logged-out users	If logged out, only see banners for logged-out users
Mostly desktop (sometimes even on mobile devices!)	Often mobile
Wikitext editing	Visual editing
Have lots of permissions (autoconfirmed, extended confirmed, sysop, file mover, etc.)	Have only basic permissions
Rarely see abuse filters in action	Often blocked by abuse filters
Unlikely to ever see CAPTCHA (at least on the home wiki)	Likely to see CAPTCHA for some actions
Sometimes use non-default skin (Monobook, legacy Vector)	Use the default skin
Changed preferences	Haven't changed preferences (yet)
Enable lots of custom gadgets	Don't enable any non-default gadgets, and don't see any gadgets on mobile interfaces
Have many edits on shared sites (Commons, Wikidata), and the permissions that go along with them	Have no edits on the shared sites, and no permissions
Familiar with lots of template names	Not familiar with template names
Familiar with terminology around talk pages, manual of style, abbreviations, etc.	Not familiar with any jargon

And the trouble is that because of this gap of experience, which keeps growing, the veteran users hardly ever think about what the new users perceive. --Amir E. Aharoni (talk) 11:51, 21 January 2021 (UTC)

Wiki-specific user experience

The Wikimedia Foundation and Wikimedia Germany have, in the past, put some considerable effort into improving the user experience of various things that are part of the software in the more conventional sense of the word - things like VisualEditor or ContentTranslare that are written and maintained by developers and run on the Wikimedia servers. That's important and useful, but a big part of the user experience stems from (for the lack of a better word) wiki-specific things that are maintained by the editors: some combination of help pages, templates, bots placing those templates, and gadgets. Editors are entirely on their own for maintaining these, and the tooling they have for it is abysmal. Almost everything has to be redone for every single wiki, our template language is stuck in the early 2000's, our module language is one if the most obscure choices possible, there are no guidelines or campaigns for writing good help pages, working on gadgets is a time travel three decades into the past when people were still writing web pages in Notepad, and so on. I think providing better tooling and better support (in coordination and skill building) for editors working on these things is a major impact area for improving user experience.

Figuring out how to centralize most template and module maintenance to a single central wiki, and building a cross-wiki contributor community around it, would be a major part of this. Using a popular modern language, probably Javascript, for Scribunto modules, would be another one. A third would be a sane developer environment for gadgets (possibly by integrating standard developer workflows based on Gitlab & the like with on-wiki gadgets); a fourth support for reviewing, updating and organizing help materials, with more in-context help and possibly some kind of centralization. Those are all fairly large and complex projects I imagine they can't all be realistically done in the initial stage of implementation, but I'd suggest picking at least some of them as early steps.

(Much of this is based on the relevant Product & Technology Working Group recommendation.) --Tgr (talk) 01:17, 21 December 2020 (UTC)

What are your pros and cons of centralizing tools, using popular computer language, environment for gadgets, and improving help materials with in-context help and centralization?

Centralizing tools: I don't know why you favor centralizing tools, which would lead to many more Phabricator tasks than we have now. Furthermore, centralization of tools would slow down or hinder further software development, wouldn't it? Also, centralization would undermine local autonomy/authority and its powers and influence.

Modern language: Are open-source computer languages more popular than proprietary ones? I've not seen many big companies release their popular software or language as open-source. Which language do you suggest using?

Environment for gadgets: Um... examples? BTW, that's still a lot of work that would take years and years to complete, and the suggested project may not be completed by 2030 as promised. Maybe 2099 or... 29832948 (I just randomly typed the numbers)?

"reviewing, updating and organizing help materials": Still a lot of program writing, and I would say the same as I said about "environment for gadgets".

Also, what do you have against template language [that] is stuck in the early 2000s? The "early-2000s" language is to this date more stable and robust than any other language AFAIK. Too bad certain young (or very old?) newcomers overlook the benefits and may be intimidated by the language that they don't understand. Their ways of executing the language without further improvements and learning didn't help matters. However, those things about newcomers don't affect how I perceive the "2000s" language as better and more suitable than any other language available. George Ho (talk) 05:21, 21 December 2020 (UTC)

About Centralizing tools: Why would it hinder software development, and undermine local autonomy? Quite the contrary. Easier collaboration will make software development much faster, and no one is proposing taking away local autonomy. The Global templates proposal says specifically that it will be preserved.

About the template language being very old: Yes, they are old, but it's important to separate the language from the way in which people use it. Indeed, the template and module languages, despite their problems, have been used for many to create some amazing features, which are used on many millions of pages. This cannot just be ignored.

That's why a project to allow shared storage of templates and modules must be completely separate from a project to change the languages in which they are written. In the Global templates proposal I wrote as specifically and explicitly as I could that that project doesn't recommend changing the syntax of the templates, but to only add a new way in which they will be stored and loaded (note: add a new way, not completely replace the existing way). It's not that I think that these languages are perfect; they aren't. But changing them is a separate thing.

--Amir E. Aharoni (talk) 12:01, 21 January 2021 (UTC)

The Improve User Experience event on 22 January

This is a kind notification that, as has been mentioned on the page, the follow-up event for this cluster will take place on next Friday, 22 January (here is the meeting link on Zoom). I'm also pinging those who previously signed up to "express interest" in implementation, in case they would like to join: @Amire80: @Aron Manning: @Anupamdutta73: @Bhuvana Meenakshi: @Camelia.boban: @Dolphyb: @Anna Torres (WMAR): @Agustín Peña (WMMX): --Abbad (WMF) (talk) 11:28, 21 January 2021 (UTC).