Redesigning the platforms for more diversity of people and content experiences

Q1. What is your Recommendation?

By 2030 we envision the Wikimedia movement to be based on technological platforms that are being used by a wider base of profiles with all sorts of technical and non-technical expertise in order to include all sorts of learning experiences (either with text, audio, video, interactive, etc.).

In order to encourage such change, we propose different requirements or principles that the software should follow in order to support any kind of present and future learning experience within the Wikimedia platforms.

Previous related recommendations:

Q2. What assumptions are you making about the future that lead you to make this Recommendation?

In this recommendation we want to highlight four problematics during the technological development that should be taken into account.

The ideation of tools created in the current community tends to assume the current editor is the target user. This limits design optimizations to current tasks instead of new tasks or new diverse users. This happens in all parts of the current technological platforms and becomes a barrier to innovation and newcomers. In this sense, the implications are that the software is not as usable as it could be for other types of users and the prioritization of certain tasks.
The software development process in our decentralized environment implies there is no single center of control. Content is at the center of the website and this leads to more complexity as new tools and platforms are built around it. This complexity can only grow, and with it some negative implications for the experiences of both old and new users, who may have some difficulties in finding anything they know it exists (e.g. a specific tool they need) but cannot remember where, and also in discovering something new that just came out (e.g. another tool that upgraded an old one or any new news).
The implementation stage of new software tools or an interface redesign relies on the acceptance by the current community. Any possible disagreement may stop an implementation and hinder the benefits that it could have for a newcomer or other users. Consensus-based decision-making requires everyone to be aware of the needs and implications for each part of the software, which makes it more challenging than centralized environments.
The web content is still mainly a textual place, other types of content are usual (video and audio) and other types of content (to be superposed in augmented reality) may appear. Providing ways to store and to experience such forms of content are not just a way of ensuring the future of Wikimedia platforms, but also of allowing many people who are currently left out because of barriers in accessibility, literacy, and knowledge tradition, among others.
The creation of content in new languages must be as easy and streamlined as possible. Starting and continuing to add and modify content in any valid natural living human language must be as easy as it is in any other language in which there is some content already.

These are some relevant aspects related to the way software is conceptualized, developed, implemented in Wikimedia and the kind of content it enables. The proposal of the future Wikimedia software design is to aim at fulfilling these requirements or stick to these principles:

1) The bias that exists in having a community thinking only about their needs in order to create new software can be tackled in two different ways. On the one hand, in order to obtain new ideas that apply to other types of users, it is necessary to conduct user research. On the other hand, in order to have software that more diverse types of users can use, it is necessary to set higher usability and accessibility requirements for the software, and later test it with various profiles. The need for testing with more diverse types of users is evident - we should test with the users we would like in the future community.

2) The increasing complexity our system is reaching in terms of number of platforms and tools should not distress new or experienced editors. At the same time, it should not be difficult to find any available tool, event or activity. We need to compensate for this architecture with satellization of platforms, tools and information in general by providing some strategies to increase findability - either by creating or improving search engines or having some syndication services or personalized channels to receive news. The first strategy may be preferred, as the second one (if it leads to another platform outside the place of contributing) may also increase complexity.

3) The fact that implementation depends on consensus can lead to stopping software that may benefit many different types of users. One possible solution to this is having more modularity in the software design in order to allow more developers to create different “clients” to perform the same tasks. This would lead to a greater personalization and freedom for the user, which could have a communication stream and interface more tailored to their current knowledge and needs - hiding all that is not necessary for that particular moment. This also means that there has to be more modularity in the content, as currently a considerable part of the Wikimedia sites’ functionality, such as infoboxes, citations, and many other components, is implemented in wikitext and templates, which are mixed with the content.

4) With digital applications taking over our daily lives, it is expected that there will be more and more ways to access and use content (and therefore, to learn about the world) than just reading. This implies that Wikimedia platforms should support and encourage the inclusion of different content types via new platforms or extensions for the main one. In addition, while storage of content is important, the interrelation and ability to facilitate how it is experienced is also crucial. Looking at it from the user perspective, even though there may be multiple platforms, there is just one single experience.

5) There must be better ways for different projects and languages to collaborate horizontally and reuse each other’s content and community-developed software features (such as templates - see Appendix: Global templates and modules). Product developers and content writers on all levels must be encouraged to write content and software in a way that is easily reusable, portable, and translatable, and the development tools must support this. Communication streams must better facilitate awareness of developments to support such collaborations.

6) In the future, more people will get connected to the web and see that Wikipedia, Wikisource, and other projects, exist online, but not in their own language. Because creating a new wiki site is so difficult, they will likely assume that there is no place for their language among Wikimedia projects at all. Making this procedure discoverable and easy to carry out will increase the language diversity of the information that is available in our projects. For further context on this point, please read the Appendix: Simplify the creation of wikis in new languages.

Q3a. What will change because of the Recommendation?

The impact of sticking to these principles or aiming at these requirements can bring improvement to the platforms’ user experience and bring some positive outcomes.

We can detail them for each change:

More usability/accessibility will impact in...

Wikimedia platforms will be more welcoming to all types of users (some of which will be new) and this will increase the current number of contributors.

More findability will impact in...

New and current editors will be able to find anything related to the Wikimedia universe and this will benefit their overall user experience.

More modularity will impact in...

More developers will be able to create interface solutions to the same problems but with different design approaches which will benefit the diversity of users. It will be easier to develop software for Wikimedia projects in a way that works well in all languages and on all platforms and form factors. Content writers and re-users will be able to add and translate more diverse content easily; in particular, it will be easier for people to focus on contributing in the areas where human contribution is most needed (writing encyclopedic “prose”, well-edited translation of words and texts, manual verification of data and references, transcription of sources), and it will be easier for software to produce content that can be reliably produced automatically from available structured data.

More content types will impact in...

More users will be able to contribute and enjoy a learning experience in the Wikimedia platforms.

Q3b. How does Recommendation relate to the current structural reality?

Each of the principles and requirements require that the current software developers (as individuals and as groups and organizations) to be more strict or start taking users into account.

In regards to usability and accessibility more diversity in the users for testing requires updating the protocols for usability testing. Accessibility is regulated by W3C guidelines (Web Content Accessibility Guidelines 2.0/2.1). Thus it would be necessary to comply with as many guidelines as possible, and to at least level AA. The Wikimedia Foundation has been already moving forward with a lot of changes on the interfaces in order to comply with WCAG 2.0/2.1, but it is required to have a proper accessibility statement and create an organization-wide accessibility product policy. We believe this is something the Product and Technology recommendations should address in more depth. More detail on this can be found in Appendix: Testing Any Tool User Interface and Policy With All User Profiles.

In regards to modularity it requires to either think of different ways to make MediaWiki more modular or create a new software architecture that separates best the different layers (content and interfaces to experience them). This is a sensitive issue with no single solution.

In regards to new types of content, it implies creating new extensions or platforms in order to support them. Likewise, it requires finding ways to relate the content types so that it is possible to navigate (i.e. thinking about listening to a song in a particular place as part of an augmented reality experience).

In regards to findability, it is essential that every tool, research project or results, user or activity is tagged with metadata so that a search engine can find it more easily.

Q4a. Could this Recommendation have a negative impact/change?

We cannot see any negative impact in following these principles or fulfilling these requirements other than the general, usual discomfort that change brings to some users.

Q4b. What could be done to mitigate this risk?

Raising awareness of the need for diversity and modularity in the current communities and thoroughly involving them in product development are essential in order to facilitate change. Improving communication systems so that situations do not escalate or cause distrust among the various actors is also crucial.

Q5. Why this Recommendation? What assumptions are you making?

The development of technology for Wikipedia started in 2001, when the technology ecosystem was significantly different from 2019. By 2030 it will most likely be even further removed from the realities of 2001.

Many of the decisions made about technology before 2006 still influence our current technological landscape profoundly:

The early contributors were English speakers, most of whom were well-versed with computers and Internet technologies, markup languages, and concepts of system administration.
The only common web browser was Internet Explorer 5, which had no support for WYSIWYG editing, and using a custom markup language was perceived as reasonable and even easy.
Templates were initially created to address repeated parts of pages, and there was no foresight about the central role that they would end up playing in the site’s design. Their advantage is that they are easy to create, modify, and deploy for experienced people, but are quite cryptic even for otherwise experienced wiki editors, and too hard to comprehend for new editors. They also ended up mixing up content, logic, and design, in a way that is quite hard to untangle.
The Wikimedia Incubator, started in 2006, was built on the assumption that people who are creating new wikis are experienced with editing wikis in other languages. This assumption may have been correct back then, but is no longer correct in 2019.
In 2001, systems for discussions on the web were not common. The “talk page” was a relatively novel idea. Usenet already existed, but wasn’t perceived as a model for Wikipedia’s talk pages. Web forums were less common then, and technologies that made them standardized, such as phpbb, were only emerging. Social networks such as MySpace, Facebook, and Twitter, which made easy online discussion ubiquitous hadn’t started. New people trying to use talk pages on Wikimedia sites usually have difficulties with using them, because they are still stuck conceptually in 2002. Two projects that attempted to modernize them (LiquidThreads and Flow) were not successful.

All of these issues influence the current state of Wikimedia’s product and its underlying technology, and many of them are derived from the low diversity of early contributors: they mostly spoke English (low diversity of language and national background), they were mostly experienced with markup languages and assumed everyone else could easily learn them (low diversity of technical background), and they were mostly from cultures with existing published encyclopedias, dictionaries, and textbooks and well-functioning public education systems in their native languages (low diversity of educational and cultural background).

Q6. How is this Recommendation connected to other WGs?

It is connected to Technology and Resource Allocation, but because technology is essential to the functioning of the Wikimedia movement, it impacts all WG.

Q7. Does this Recommendation connect or depend on another of your Recommendations?

It is directly connected to Introducing people-centered principles within the Wikimedia movement and Reaching a self-aware and dynamic structure aimed at community diversity and health, but also relates to other recommendations, i.e. community planning, policy, partnerships, resources.

Q8a. What is the timeframe of this Recommendation in terms of when it should be implemented?

Since technology is essential to the functioning of Wikimedia, this recommendation should be implemented as soon as it is feasible to do so. The accessibility component of this recommendation is long overdue and something we must need to comply with as soon as possible, with situations that have been pending to be resolved for many years without avail.

Q8b. Who needs to make a decision on this Recommendation?

The Wikimedia Foundation leads a big part of the Product and Technology developments for the projects, for which is in WMF, its leadership, and Board of Trustees, to move this forward within the Product and Technology departments.

v t e Movement Strategy Working Group recommendations (September 2019) Now merged into the final 10 recommendations
Advocacy	1. Transparency 2. Diversity 3. Global conversation 4. Knowledge management 5. Advocacy Hub 6. Common positioning 7. Partnerships 8. Empowerment of advocates 9. Self-Determination 10. Protection of Advocates
Capacity Building	1. Building Capacity for Capacity Building 2. Matching human assets and online knowledge resources with capacity building needs 3. Capacity Building Should Occur in Context 4. Provide Capacity Building for Organizational Development 5. Resources for Capacity Building 6. Evaluating Capacity Building 7. Online Training 8. Mentoring and leadership development 9. Recognizing Individuals 10. Independently governed Capacity Building ‘Unit’
Community Health	1. A joint set of rules we all agree to live by (a.k.a. Code of Conduct) 2. Redefining power structures to better serve the communities 3. Building the leadership of the future 4. Structure for handling conflicts- before, during and after 5. Investing in building an inclusive global community 6. Newcomers are a key indicator to the success of the movement 7. “Democratizing” participation (making Wikipedia/Wikimedia everyone’s responsibility) and reducing barriers for participation 8. Privacy and security for everyone 9. Opening the circle: All terrain readiness 10. Network to continually support community health 11. Aligning resource allocation with community health goals 12. Investing in equity-centered technologies
Diversity	1. Introducing people-centered principles within the Wikimedia movement 2. Reaching a self-aware and dynamic structure aimed at community diversity and health 3. Redesigning the platforms for more diversity of people and content experiences 4. Planned community diversification 5. Reflective policies for participation and governance 6. Establishing partnerships in order to represent and protect worlds’ cultural diversity 7. Decentralized administrative structure for resource allocation 8. Bridging different local contexts and Wikimedia projects' notability and verifiability policies
Partnerships	1. Provide the knowledge needed for understanding and solving global issues 2. Wikimedia as steward of the Free Knowledge Ecosystem 3. Shared ecosystem of services and tools for content partnerships 4. Data partnerships approach to fulfill the vision of knowledge as a service for our partners 5. Focus on knowledge equity when determining priorities for Partnerships 6. Partnerships as part of a Distributed Vision 7. Partnerships as a shared and equitable resource and activity 8. Prioritise documentation 9. Invest in sharing knowledge about partnerships across the movement 10. Support the skills development of people working on partnerships 11. Invest in the leadership potential of community members 12. Establish recognition principles for new partners for attribution and content donation 13. Additional research for areas where we have identified issues but haven’t made recommendations
Product & Technology	1. Evaluate and Decentralize Technology Components 2. Support Community Decision-making 3. Open Product Proposal Process 4. Deployment Council 5. Disseminate Product Knowledge 6A. Improve Technical Contributor Engagement 6B. Modernize Technical Contributor Tooling 7. Realize the Potential of the Third-Party Ecosystem 8. Movement Technology Ethics Review Process 9. Monitoring Product Trust and Availability 10. Developing an Evolving Technology Vision and Strategy
Resource Allocation	A. Set Common Framework of Principles for Resource Allocation B. Design participatory decision making for Resource Allocation C. Recognize privileges / Design for equity D. Distribute existing structures E. Build Thematic hubs – to provide services to the free knowledge movement long term F. Ensure flexible approach to resource allocation in a complex, fast moving and changeable space G. Allocate resources for capacity and sustainability H. Allocate resources to new types of partners/organisations (essential infrastructure of the free knowledge ecosystem) I. Include knowledge consumers
Revenue Streams	1. Turn the Wikimedia API into a revenue source 2. Provide Paid Wiki-related Services 3. Monetize merchandise 4. Expand global fundraising 5. Develop non-fundraising revenue streams for affiliates 6. Set a goal of financial sustainability for all movement actors 7. Diversification of revenue channels
Roles & Responsibilities	0. Scenario 1. All of this exists to support our primary purpose: free knowledge and its distribution (Original) 2&3. Decentralisation and self-management 4&5. Establish a Movement Charter 6. Wikimedia movement organisations will be governed by inclusive, diverse, and accountable boards 7. Capacity building