Jump to content

Strategy/Wikimedia movement/2018-20/Transition/Discuss/Improve User Experience

Add links
From Meta, a Wikimedia project coordination wiki

Discussion of priorities: Increase the Sustainability of our Movement • Improve User Experience • Provide for Safety and Inclusion • Ensure Equity in Decision-making • Coordinate Across Stakeholders • Invest in Skills and Leadership Development • Manage Internal Knowledge • Identify Topics for Impact • Innovate in Free Knowledge • Evaluate, Iterate, and Adapt

This is an open discussion space dedicated to defining potential priorities for implementation from the Improve User Experience recommendation.

Methodology to improve the Wikimedia platform UX research, design, testing and community engagement

[edit]

Methodology to improve the Wikimedia platform UX research, design, testing and community engagement:

  • Involve representatives of designers, technical developers, communities, and user profiles in iterative user experience (UX) design, research and result dissemination processes to raise awareness and enable better decision-making.
  • Test and validate the usability of products with different user profiles (advanced editors, technical contributors, and newcomers reflecting the diversity we aim for).

Community engagement around product design and UX:

  • Inform communities about the state of UX, collaborate on needs, and support them in taking responsibility to be more inclusive by addressing barriers that prevent growth, diversification, and participation.

Adaptable UX to various devices:

  • Interfaces designed intentionally for a wide range of devices so users can consume and contribute in diverse contexts.
  • Comment Comment This ambition has promise. We must be either cautious, careful, or wary about trying to do everything all- or mostly-mobile. The mobile experience and desktop experience are very, very different from each other. I found one old review about MS Word Mobile vs Word 2013. Well, Word 2013 is an old program, but the review still reflects how mobile is good for "light use" but may not be suitable for working on more than one document simultaneously and completing a task. A review on Google Docs also considered mobile good for readership and quick editing but no substitute for desktop. I believe that the same experiences would apply to Wikimedia projects. George Ho (talk) 01:01, 7 December 2020 (UTC)[reply]
  • Comment Comment Note the absence of support here, on text that (in theory) should get overwhelming support. The Foundation's efforts in this area have been unsuccessful or actively detrimental, and the background on this item indicates an intent double down on the same failed ideology. This is only going to result in more conflict and failure, unless the Foundation is ready to acknowledge the data showing VisualEditor has been detrimental for new users. Alsee (talk) 01:23, 5 January 2021 (UTC)[reply]

Compatibility with Accessibility Guidelines

[edit]
  • Support compliance with the most advanced accessibility guidelines using free and open-source software (WCAG for web, W3C mobile web best practices, etc.).
  • ..

Resources for newcomers

[edit]

Easy-to-find and easy-to-understand resources for newcomers, including onboarding media and guiding interfaces helping them independently learn and navigate.

  • Comment Comment Helping newcomers is one thing, but we can't assume that all newcomers have good intentions and are willing to learn how to do well in a project, do we? George Ho (talk) 01:16, 23 November 2020 (UTC)[reply]
    Certainly not, but improving newcomer resources doesn't typically require any such assumption. The state of newcomer resources has a very long way to go (when I started delving into the area at en-WP, there was a ton of low-hanging fruit, and even now after a bunch of work I'm still often held back by editors that have difficulty putting themselves in beginners' shoes or prioritizing their needs). {{u|Sdkb}} talk 05:54, 23 November 2020 (UTC)[reply]
    If we want to highly prioritize this, shouldn't we tell newcomers to rather use a laptop or desktop for more complicated and/or lengthy, time-consuming edits, even on a Wiki? Smartphones and iPads without connecting a Bluetooth keyboard have become more convenient for general editors to do simple and shorter edits. However, desktop and laptop are much more preferable for Wikimedia work as much as educational and business work. Wouldn't you agree? George Ho (talk) 07:18, 23 November 2020 (UTC)[reply]
    Many newcomers are coming from parts of the world that are just starting to go online; they often don't have access to a computer. {{u|Sdkb}} talk 23:09, 23 November 2020 (UTC)[reply]
    If we're gonna serve those newcomers of those areas lacking sufficient access to computers, which newcomer groups of those areas? There must be more brainstorm than just implementing this initiative. For such areas, shall we serve schools, government agencies, and businesses first, or must we go broader than just those establishments? Trying to target mass appeal from those areas would be too risky for anyone, even an entrepreneur, to achieve, wouldn't it? Furthermore, distributing Wikipedia articles in print is less and less practical nowadays.

    If that's not risky to you, what about focusing more on tablet users? (Oh wait, the formal term is "tablet computer", isn't it?) Out of over one billion tablet users worldwide, how many of them live in those areas? In those areas, how many of them surf and/or edit Wikipedia? What about mobile web or desktop web? Honestly, editing on a smartphone will never be easy, even with a Bluetooth keyboard and/or mouse, no matter how much effort is made to attract smartphone users. Neither will overall smartphone user experience with Wikipedia. To put this another way, many (general?) smartphone users will have difficulties composing lengthier edits on Wikipedia, regardless. George Ho (talk) 02:34, 24 November 2020 (UTC)[reply]

See Wikimedia 2030/Initiative/Cross-project tool development and reuse#Dependency for everything. Tools for newcomers is a good thing to do, but a lot of things in each wiki are localized differently. It's not just a matter of language, but a matter of different templates and gadgets in each wiki. Communities implement their workflows using templates and gadgets, and as long as templates and gadgets are different in each wiki, there will be no scalable, efficient way to make tools for newcomers. This is addressed by initiative "14. Cross-project tool development and reuse". So beginning initiative "11. Resources for newcomers" without doing initiative 14 first would be a bad idea. --Amir E. Aharoni (talk) 19:57, 27 November 2020 (UTC)[reply]

I'm not really convinced that initiative #14 (which I have thought is too ambitious on its own) is necessary to make initiative #11 better. I commented on initiative #14 about the tool's reliability. I know that the initiative #11 looks baffling to you, and... well, I hadn't like this initiative as either too broad or too redundant. However, most other people have liked the initiative #11 without making the other necessary. Furthermore, #11 and #14 are too different from each other, and mixing them up would make the focus either too narrow or jumble up (or convolute) the focus. Focusing on initiative #11 alone isn't such a bad idea, is it? If initiatives #9 and #11 can be discussed in one room, then why need #14? Besides, I thought focusing more on #11 than #14 would help us stray away from #14 and concentrate more on #11. BTW, you have the WMF account, yet you're not using it at the moment. I guess what you said doesn't reflect stances of WMF, right? George Ho (talk) 21:40, 27 November 2020 (UTC); standing corrected, 18:21, 28 November 2020 (UTC)[reply]
I don't know why do you think that initiative #11 looks baffling to me. It doesn't. It's totally legitimate, and it makes sense that many people think it's important. What I'm saying is that implementing it without addressing #14 first will be inefficient. More people like #11 more than #14 probably because most people are focused on their home wiki and don't notice the problems that arise from the lack of cross-wiki tool reuse. But building resources for newcomers will have to take local onwiki tools into account, and without cross-wiki tool reuse this will be inefficient. --Amir E. Aharoni (talk) 14:17, 28 November 2020 (UTC)[reply]
Now I understand your point. Still, you and I have different approaches with this initiative. You find this initiative inefficient, while I have found it too broad or too general. I have made comments about it earlier. This can be discussed in December meetings. George Ho (talk) 18:47, 28 November 2020 (UTC)[reply]
Many recommendations and initiatives indeed sound too broad, not just this one. They have to be, because if they were more detailed, there would be 450 of them and not 45. --Amir E. Aharoni (talk) 08:27, 29 November 2020 (UTC)[reply]
I mean, global templates are something that we pretty badly need for all sorts of reasons. I'm not sure how much they apply with regard to beginner resources compared to other areas. {{u|Sdkb}} talk 02:26, 30 November 2020 (UTC)[reply]
Sdkb, you can't edit almost anything on any wiki without running into templates and gadgets in some way. For the last fifteen years, I've taught people to edit in all namespaces, in four languages, in many countries, over talk pages, over email, over instant messaging, over the telephone, over video conferencing, in real life, in Wikipedia, Wikisource, Wiktionary, and Wikidata, with Visual editor, with the wiki syntax editor (2006, 2010, and 2017 versions), with Visual editor, with the mobile web, iOS, and Android editors, and with Content Translation. Templates and gadgets always have to be mentioned after no more than 30 minutes or so.
I can imagine two families of resources for newcomers: Documentation (simple text or a more interactive app), and software tools (wizards, toolbars, etc.) that help people self-learn the editing (and reading) process or find other people who can help them. If this teaching or self-learning process for newcomers is to be improved with any kind of resource, it will have to take templates and gadgets into account from the outset. When this is done for each language separately, it is inefficient.
It's not theoretical. This is already happening. I've been involved in the research, design, and development of several tools of this kind, as part of WMF work, and also with chapters (mostly Wikimedia Israel) and with other volunteers. With all this experience, it is obvious to me that the most necessary improvement for developing such resources is to make the onwiki tools reusable across projects. The inability to efficiently reuse across wikis the resources for beginners that were developed by WMF and chapters has come up repeatedly as an issue, and almost every time it ended up along the lines of "... so we're only making it for the English Wikipedia / the German Wikipedia / the Hebrew Wiktionary / etc.". Sad to see so much wasted effort. --Amir E. Aharoni (talk) 14:08, 30 November 2020 (UTC)[reply]
  • @Amire80, George Ho, and Sdkb: Thank you all for the thorough and interesting comments about this initiative and its relation to the other changes proposed in this recommendation. Based on results from here and the Global Conversations, there's now a dedicated part of the space to discuss the highly-prioritized initiatives for global implementation in 2021-22. You're invited to continue the conversation there, if interested --Abbad (WMF) (talk) 15:41, 17 December 2020 (UTC).[reply]

Peer-to-peer spaces

[edit]

Spaces that allow finding peers with specific interests, roles, and objectives along with communication channels to interact, collaborate and mentor each other.

  • ..

Platform functionality and documentation standards

[edit]

Documentation and standards to capture platform functionalities for evaluation, learning, and improvement.

  • ..

Cross-project tool development and reuse

[edit]
Main article: Wikimedia 2030/Initiative/Cross-project tool development and reuse

Tools to connect cross-project and cross-language functionalities to provide an enhanced experience of the knowledge contained in the Wikimedia ecosystem for a particular interest, informational need, or inquiry.

  • Clear pathways for advancing new wiki proposals (including new language versions) and for reusing community-developed software features on them.
  • Developer tooling and high-quality documentation to allow technical contributors to create and maintain tools with usability and efficiency.

This initiative is a dependency for all the other initiatives in this cluster. For an explanation, see the subpage: Wikimedia 2030/Initiative/Cross-project tool development and reuse#Dependency for everything. --Amir E. Aharoni (talk) 12:49, 27 November 2020 (UTC)[reply]

If starting initiative #11 would be a bad idea without #14, why is initiative #14 not in most people's best interests? Honestly, IMHO the cross-project tool proposal appears to be a competitor to Google Translate (and Microsoft Translator[?]), isn't it? How would this cross-project/cross-language tool be more reliable than Google Translate or any other translator? Many people have concerns about any AI translator tools, like Google Translate. As I fear, they would say the same about the proposed tool. Don't you think? George Ho (talk) 21:22, 27 November 2020 (UTC); standing corrected, 18:32, 28 November 2020 (UTC)[reply]
Initiative 14 has absolutely nothing to do with AI or machine translation. It's not necessary related to translation either. It's about technical collaboration between any two wikis, and this may include English Wikipedia and English Wikisource. --Amir E. Aharoni (talk) 14:10, 28 November 2020 (UTC)[reply]
Oh, I see. But we already have local tools directing readers to other projects, e.g. links. Is core MediaWiki infrastructure needed for this cross-project tool? George Ho (talk) 18:51, 28 November 2020 (UTC)[reply]
Perhaps we are understanding it differently because of the ambiguous grammar of English language :)
I might be wrong, but I suspect that you read "Cross-project tool development and reuse" as "development and reuse of a cross-project tool", but that's not what it means.
It means "development and reuse of tools across projects". Currently, on-wiki tools are developed in each project separately, and this initiative is about building an infrastructure that will allow tools to be shared across projects, and will allow their developers to collaborate efficiently. --Amir E. Aharoni (talk) 08:41, 29 November 2020 (UTC)[reply]
Are you also proposing that enwiki and Wikidata share each other's tools or share tools together? Recently, I begin to find Wikidata more troublesome than what it's worth. George Ho (talk) 17:13, 2 December 2020 (UTC)[reply]
Wikidata, for this matter, is just one of the 900 or so wikis in the Wikimedia family.
There is a global repository of images: Commons. Images from Commons can be used in the English Wikipedia, Wikidata, Meta, Arabic Wikisource, etc. Wikis can also have local images if they don't want to use images from Commons for any reason. Just like there is a global repository of images, there should also be a global repository of modules, templates, and gadgets, from which English Wikipedia, Wikidata, and all other wikis will be able to pull tools they want. And they can also look keep their local tools. --Amir E. Aharoni (talk) 18:44, 2 December 2020 (UTC)[reply]
Now that you mentioned "Wikidata", which is all "structured data" yet less practical, I soon wonder whether this initiative is in the current Movement's best interests. I don't know which global repository modules, templates, and gadgets you had in mind. However, if Wikidata is involved in this, I figure this is why many people didn't vote for this. George Ho (talk) 21:50, 2 December 2020 (UTC)[reply]
I didn't mention Wikidata, you did.
(And I fixed my previous message: I meant to write "a global repository of modules, templates, and gadgets".) --Amir E. Aharoni (talk) 09:29, 3 December 2020 (UTC)[reply]
Well, I mentioned it first, and then you mentioned it. But ah well... George Ho (talk) 10:30, 3 December 2020 (UTC)[reply]
Abstract Wikipedia perhaps? Vexations (talk) 22:55, 2 December 2020 (UTC)[reply]
What about Abstract Wikipedia?
It is certainly a cross-wiki initiative, and its functions will become a new type of cross-wiki tool. However, Abstract Wikipedia alone doesn't address the issue of sharing the hundreds of thousands of current community-developed tools across wikis, at least not at the moment. And yes, there are actually hundreds of thousands of them, because templates are tools, and there are hundreds of thousands of templates. And this is a major problem that cannot be ignored. Abstract Wikipedia is not a magic thing that will fix it.
The current onwiki tools are written in wikitext (templates), Lua (modules), and JavaScript+CSS (gadgets). As of December 2020, we don't even know in which programming language will the Abstract Wikipedia functions be written; the developers say that it will be possible to use multiple languages, and my prediction is that in reality it will be just one, and that it will be a dialect of JavaScript, although I might be wrong. But mostly we just don't know. So this initiative requires separate attention, and it cannot be dismissed by saying "we're already developing Abstract Wikipedia". --Amir E. Aharoni (talk) 09:29, 3 December 2020 (UTC)[reply]
Do you think the programming language of Abstract Wikipedia will be either proprietary or open-source or derivative of a proprietary source? George Ho (talk) 10:33, 3 December 2020 (UTC)[reply]
It's going off-topic, but it's quite certain that it will be open source because all the software that we deploy is open source. --Amir E. Aharoni (talk) 18:28, 3 December 2020 (UTC)[reply]

Partnerships to develop Wikimedia API

[edit]
Main article: Okapi

Make the Wikimedia API suite more comprehensive, reliable, secure and fast, in partnership with large scale users where that aligns with our mission and principles, to improve the user experience of both our direct and indirect users, increase the reach and discoverability of our content and the potential for data returns, and improve awareness of and ease of attribution and verifiability for content reusers

  • ..
Retrieved from "https://meta.wikimedia.org/w/index.php?title=Strategy/Wikimedia_movement/2018-20/Transition/Discuss/Improve_User_Experience&oldid=23616138"