Wikimedia Diversity Conference 2013/Documentation/engaging new editors by reducing barriers

Session: Matthew Flaschen, Jared Zimmerman, Vibha Bamba, Pau Giner // Engaging new editors by reducing barriers edit

Abstract edit

Everyone learns and participates in different ways. This session focuses on how underrepresented groups of users face inordinate barriers to entry to becoming and remain editors. The current system favors a very small segments of users. Contributions from women and the global south are under-represented, leading to a lack of diversity in the user population and the content that users are exposed to. We'll look at some of the projects both underway and planned, to increase participation and reduce friction of ways to contribute.

Challenges edit

  • some things works well for some people, not for others
  • communication and social interaction can be slow and inefficient
  • language used when talking with users tends to be robotic, cold, revert notices, templates, etc.

Ideas edit

How to solve and address barriers? Building tools from the technical side to allow people work more productive

Tools:

  • Guided Tour
    • way to teach users how to do things
    • not everyone reads manual even if it exists in a perfect version
  • Getting Started
    • Help users find tasks to do (easy fixes)
    • Notify users that they can edit
  • Language Support
  • Article Translation

Questions / Next steps recommendations edit

Reasons why article is rejected (deleted or proposed article never gets moved to the main space):

  • lack of notability
  • lack of reliability, references
  • not educational topic
  • Commercial (promotional)

Technical tools: event logging: logs how a user moves through a process. Are people clicking on "find easy tasks" or "edit a page" more often? When doing a major UX change: when you first signed up, you got to an interstitial page, not where you were reading. New option was to go straight back to what you were reading, with a dialog explaining this. This was preferred.

Q: What are the main reasons why users stop editing? A: New editors: having stuff reverted, but not understanding why; making the initial edit without understanding what the community wants, getting bitten. Excessive choices can result in people becoming less active. e.g. after logging on for the first time, you would get three articles per three "tasks", but this was overwhelming, so now only show tasks. Barriers include not knowing where to start; negative impact if you start without knowing what to do - getting a bad result.

Q: "Soft landing" - what exactly does this mean? A: The system could rather tell you what can be improved rather than saying that it shouldn't be published, e.g. by moving into your own space first. Also, tell you what's wrong (e.g. needs refs, etc.). Status quo is that as a new user you can just create an article (not recommended), or use articles for creation process - a bit like proposing an article to a journal. This is needlessly kludgy: doesn't flow smoothly. Could be improved for author and reviewers. Most of these ideas have been tried by community, but needs to be understood by users.

Q: If I were an editor, how would I find these userspace articles so that I could for example find articles on women, which are still in userspace (note: categories not allowed in userspace) A: Not sure whether you can browse by topic, but currently can browse AFC. Not trying to work with specific users, but making it better for everyone. Natural extension is an interface to find the users whom you can help. This would be useful. Someone starts editing about a rock band, then a similar band, then a singer from that band, etc. So we need to make this more prominent so that people can navigate more easily.Katie: AFC isn't really easy to use, but the "chat" option was useful. Would maintain the live chat and make sure it's usable. Support different kinds of communication between users. Katie: hard to get to the stage where you can see the IRC type interface.


Comment: While you're typing your article, you don't get feedback Response: en-wiki is aware of the problems with AFC, so we're in sync.

Ravan Jaafar Altaie comments in her video that it's great when you can influence thousands of people, but that this happened by chance! We need to make the process more reliable.

Notifications: how not to get spammed? Turn off all except talk page notifications.

"Thank this user" feature has had overwhelming success.

Seeing that the article you created has been widely viewed is very motivating.

Tell users that there is something new to update on a topic they've worked on.

What is the best frequency of notifications? Maybe bundle similar types of notification? Add buttons for subscriptions?

Comment: Mode of notification?

Response: Active vs passive notification: do you have to respond?

Katie: Talk page notification [orange bar] doesn't take you to new messages any more! Missing more stuff now!

Response: Probably an open bug.

Language is also a barrier. Knowledge only works if it's in your language. So:

  • provide appropriate web-fonts. Can even apply for English (e.g. OpenDyslexic for people who have dyslexia)
  • Provide suitable input methods to support users who don't know how to do this themselves.

Q: OpenDyslexic - Dyslexic people in .se found it didn't work in their community after brief trial. A: For example in Malayalam, the people who know Malayalam, and who can help, are not representative, but they're supporting the developers. Response: relevance? We often provide support believing that it's useful, based on community feedback, but might not work for whole community.

Comment: OpenDyslexic font has continual feedback from users - might need some getting used to, but fonts are very subjective, and you might get loud minority opinions.

Comment: Have you tested?

Response: Continual UX testing.

Response: Opendyslexic isn't carved in stone, might find better options later.

Q: How to type on Latin keyboards. Google translate, cut and paste. Users keep asking for a soft keyboard.

A: Correct - now we provide jump to help on the keyboard, but will also provide visual keyboard, and help for cases where it's not a one-to-one mapping of keystroke to character.

RTL scripts:

Guided tour with full RTL support. Determines whether to flip based on tour code location, e.g. automatically flipped on he or ar.wikipedia - smart enough to know when you're writing in Hebrew [not sure of details].

Subtle points: readers of RTL languages might have different assumptions about "next" or "previous" arrows pointing in "wrong" direction.

WP isn't a fluent process for translators. How about having articles side-by-side with machine translation to start with? Users say "faster, yes, but better maybe not!" Maybe if users don't change much, flag it for attention. We can maybe have different providers for translation.

We'll see what people change that way. Maybe we'll be able to improve those services (whether Google or open-source), and also (based on knowledge) provide the best service for a particular language translation. We'd never have exclusivity, and we are now looking at the issue that OS tools are not as mature as the proprietary options.

New ideas / New ways to contribute:

  • Different interests, want to contribute in different ways
  • Different devices and expertise levels
  • The way we consider editorship should expand, even if it's not traditional article writing (e.g. marking problems - microcontributions)

"Things that I can do"

  • Maybe put ideas for contribution in your "contributions" page (it's empty for new users anyway!)
  • Give mobile devices an interface, for example, for pepole to provide sources in "citation needed" case, or request citations for uncited statements. Need to be device appropriate: on mobile it's easy to highlight and flag stuff. On mobile apps you can easily get pictures, geolocate the user, prompt based on location.
  • How about giving people disambiguation interface?
  • Look at "Special:nearby"

Do a better job of showing that articles are living entities. Maybe have a banner at the top that highlights the history and trends related to an article. For example, a banner to show that it's just been updated, or number of editors who have edited it. When did it undergo the points where it has undergone the most editing, how many people have made significant contributions.

Q: Showing people where the content comes from - info about which word has been edited by whom. Hard to construct from the database, but would be useful. Would yo ulike this? A: Wikiblame does something in this direction. Response: not very good, WikiTrust needs a new maintainer/ host. A: If I told you who did what, what would you do with that info? Response: Could cite only the authors of that text, and only the contributors of the current version.

Comment: Better tools would allow people with less tech skills to become amins and contribute well on oversight. Response: Jeff is working on a tool which would allow you to view change in article over time. That kind of tool would make it easier to see who did what on an article.

Comment: In context of diversity, fine-grained control of authorship allows people to feel comfortable to contribute in humanities.

Mobile profile (only on alpha so far): shows what you have recently contributed, when you've been thanked. A profile allows is a means to an end: namely collaboration. Gives a face to an editor. Allows for short collaborations towards work. This makes you want to come back more often as well: more "sticky". How to get people past the 5 edit count? Show people the power of the community. On LinkedIn or Twitter, it's mostly new users looking for influencers, but on WP [I missed this now]

To enable alpha, go into settings, switch on beta, reload, switch on alpha.

Jessie: How do you test this? Answer: Soon we'll have "turn on beta features" on desktop. Will soon have tests for visual editor on by default, math editor, typography tests. Solicit feedback, change things frequently. This only gets to very connected users: already on village pump etc.

Multimedia support: [missed all this discussion].

Guided tour is better than a video: you're actually doing it while you're being guided.

Video helps, for example when editing code and not getting it right.

How much bandwidth do you need for the guided tour? Answer: it's pretty lightweight. We do try to keep pepole with bandwidth limitations in mind.