Wikimedia Mobile engineering/Brainstorm/Archive

Assigning tasks to mobile users
Here is an idea that came up during the recent brown bag hosted by Howie and Dario. Senior editors, or leaders in the framework above, sometimes keep task lists to show to new editors. So this idea helps both active editors and new editors, and possibly could even help build broader participation.

Let's say we introduce a wikitext markup called "mf" or mobile friendly. When the active editor uses this on some items, those items are flagged as useful tasks for mobile users. We could run an ongoing filter to pick up those tasks and deliver them in a concise form to mobile users.

Assuming the worklist is already assigned to a category, readers browsing an article in that category will get a small but noticeable push notification to check out a suitable task.

Quick interactions on Wikipedia
Our mission is to discover new ways to engage the readers. We're looking for quick interactions that add value to the encyclopedia, make the reader happy and fit within their available time.

If our reader only has a minute or two, how can she best contribute? Are there simple tasks that she could do in that time frame, besides giving feedback? Check a source? Find a photo? Add a link? Categorize a link? Make a 'mini-edit'?

On Truthsquad.com, we show readers a single sentence, then ask them if it's true or false. And we get about 10x more participation than when we ask them to review entire articles on NewsTrust.net. It's a focused, bite-size, content-rich, almost game-like experience that draws you in and makes you want to click.

Once we get further along, I'd love to try testing a couple ideas like that, to see if any of them stick. It would be great to have a simple tool to quickly create a variety of calls to action like these. This could get really interesting.

New Pages Feed microtasks
Similar to the idea of calls to action, there could be a simple mechanism for enabling some tasks in New Page Triage as calls to action on mobile devices. A simple example is marking pages for propose deletion that are clearly examples of vandalism. Some of the structural design of this feature area could be incorporated, such as triage stacks. We could experiment with this in isolated Android apps.

Also started brainstorming other micro tasks, such as creating redline articles or article stubs, and possibly a collection of the most common "casual" editing impulses people have when reading Wikipedia. These could appear within a widget, similar in form to article feedback.

Casual communication

 * the widest mouth of the funnel

Recent experience with WikiLove has shown that simplifying communication can be desirable to readers. This could be achieved with a discussion forum or commenting support outside of the "normal" wiki Discussion page context. Wikimedia blogs currently allow threaded commenting and LiquidThreads has been deployed in limited fashion in some wiki areas.

The current structure for user-to-user communication makes use of User Talk pages, which are the Discussion pages associated with users' description pages. One use of WikiLove involved users commenting easily on user Talk pages. However, the Talk mechanism is incomplete for back-and-forth communication, simply because there is no automatic notification for replies (the user who owns the User Talk page will be notified when additions are made, but not anyone else, by default).

Here are a couple of "mild" suggestions:

1) Add notification of other participants on a User Talk page - this would require account creation/login and surfacing some form of opt-in

2) Use mobile devices to perform and track casual conversations, in the style of SMS, and perhaps using SMS

Both 1) and 2) could be combined. So for example, additions to a User Talk page could generate SMS or email notifications, and users could reply directly using SMS or email. There is a probable issue with generating SMS's automatically - cost.

Alternatively, a new threaded discussion system could be deployed in relatively small pieces, and be handled outside of the article or user discussion pages. Another thought is to combine this effort with annotation, described next.

Article annotation
Users can leave short messages on the talk page of the articles that point our errors or make suggestions either about a specific part of the article or about a subset. They might even be able to to create these annotations offline and then have them posted at a later time.

Within-article annotation
- adding notes to specific parts of articles, possibly part of "new editor conversion"

This concept leverages the nature of the reading experience on mobile while creating an entry point into the main editing processes.

The idea goes something like this:


 * Mobile reading can dramatically expand breadth of readership in terms of both numbers of readers and numbers of articles - however, such reading will tend to be situational and less in-depth


 * Mobile readers may encounter proofreading errors, factual errors, or incomplete information that they wish to make note of, either to perform some minimal editing on the spot, or to remind themselves of edits to make later


 * This would require readers logging in so as to enable private use of annotation - otherwise, the annotation would have to be public, and possibly the reader can be given a choice of public or private after he/she logs in


 * This could be developed as part of article Discussion, with the notable caveat that mobile writing and annotation in general tends to be abbreviated and imperfect


 * Two likely use cases, which are related and overlap to some degree, are: 1) casual readers who notice something and want to make a casual note, and 2) experts who want to provide some expertise but who are not currently editors (and possibly don't want to be)

Aaron Halfaker has created an annotation Gadget called Wikignome: Wikignome

Social features
- specific ways to help readers or members to become editors

(not just mobile, but maybe easier to get started on mobile)

Here is actual user commentary culled by Sue Gardner in her blog. Nine reasons why women don't edit Wikipedia

Both quotes are from Metafilter:

Not everyone feels self-doubting, though: ”It’s not that it intimidates me. It’s more that, well, if I spend three hours carefully composing a concise article on something, complete with blasted citations and attention to formatting consistency, the chances of it being poof!gone the next day are still high, and on top of all my work I don’t get anything back apart from the ineffable sensation of contributing to humanity’s knowledge base. I want friends who will excitedly inform me how pleased they were by my penultimate paragraph, dammit. I want a way to team up with someone who knows the markup and can help iron out problems before stuff gets published. I want a social backbone to keep me contributing and caring, one that doesn’t depend on the frequency of my contributions. Contests for “best article about birds in November”. Basically, give me a LJ-flavored wikipedia editors fan community.” [6]

[6] Source: From a discussion at Metafilter titled Wikipedia, Snips & Snails, Sugar & Spice?

The few times I’ve touched wikipedia, I’ve been struck by how isolating it can feel. It’s a very fend for yourself kind of place for me. Anywhere else online, my first impulse is to put out feelers. I make friends, ask for links to FAQs and guides, and inevitably someone takes me under their wing and shows me the ropes of whatever niche culture I’m obsessed with that month. It’s very collaborative, and prioritizes friendships and enjoyment of pre-existing work over results. Wikipedia isn’t like that, as far as I’ve experienced. There’s no reciprocal culture; to just plunge oneself into the thick of things and start adding information can be highly intimidating, and there’s no structure set up to find like-minded people to assist one’s first attempts. Instead I just find lots and lots of links to lots of information-dense pages.” [27]

[27] Source: From a discussion at Metafilter titled Wikipedia, Snips & Snails, Sugar & Spice?

Please consider these general comments that could just as easily apply to anyone new to editing Wikipedia, as to women in particular.

While these are general issues, some aspects could be addressed in a natural way with mobile functionality.

For example, could there be a way to browse a discussion forum on mobile and start chatting with participants who may be in particular discussions?


 * This is desperately needed on the web interface already, and isn't really mobile-specific. But... a good mobile interface for chat, discussion, review, and notifications could make it a lot easier for people to be active participants at more times. Like the 4-Square checkers-inners, some folks end up fielding a lot of requests just for fun. :) --brion 20:49, 7 October 2011 (UTC)

Could we surface users who are online and near the inquiring user, or users who have edited topics related to a search?


 * Location has serious privacy issues, but being able to opt in to 'local community' stuff could be helpful at times; could also be a way to encourage local meetups and connect traveling 'medians with their local brethren... --brion 20:50, 7 October 2011 (UTC)

Social network leveraging

 * Use profiles on LinkedIn to determine relevancy and expertise for editing (obviously not mobile-specific)

Mobile fundraising
Not within the four categories framework above, so won't take this too far off topic. The right ecosystem for this idea doesn't yet exist, but is definitely something to keep an eye on. The experience around mobile payments is improving rapidly, and pretty soon some one will get it integrated right. This experience can probably be envisioned as a "tap to donate" function in which a user is only 1-click away from seamlessly transferring a dollar or other flat amount.

Yes, and there are different ways to transact a payment. Recently on a mailing list, there was the idea of paying for an app as a donation. In fact, multiple versions of the app could "cost" different amounts to provide convenient choices of donation amount. If the app is on Android Market, then we could approach Google to donate their 30% cut.

Donations on the Apple App Store are likely to be even more successful, just because it is proven that it is easier to buy things on the App Store. The iPhone app upgrade will follow shortly after the Android app, and this is a great way to suggest this as a new feature, which I will now add on the Feature Corral page.

Personally, I think this idea fits in the first and possibly second categories. Readers making a donation are taking a small step toward participation.