Wikidata:Requests for comment/Editing descriptions from Wikipedia Android app

From Wikidata
Jump to navigation Jump to search


THIS RFC IS CLOSED. Please do NOT vote nor add comments.

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Sufficient feedback received DBrant (WMF) (talk) 15:09, 5 December 2016 (UTC)[reply]

The official Wikipedia apps for Android and iOS make significant use of Wikidata descriptions, in a number of useful circumstances:

  • In a list of search results, a short description can provide some quick context of what each article is about.
  • The same is true for a list of reading suggestions (e.g. a list of trending articles)
  • If a list of titles contains two or more identical (or nearly identical) results, the description can serve as a disambiguation between each title.
  • When navigating to the article itself, the short description can provide a high-level overview, before the user starts reading the article.

This style of displaying a "title + description" combination has been a very successful pattern in the native apps, and is now also done in search results on mobile web. We therefore want to give users a simple way to edit these descriptions.

Motivation

[edit]

We'd like to create more ways of engaging with our readers, especially ways in which casual readers can be encouraged to make contributions. Giving them the ability to edit these descriptions is a viable starting point to experiment with whether our readers can be converted to meaningful contributors. In addition, since the description is intended to be very short and limited to plain text, it can translate very nicely into a native mobile editing interface.

In addition, we're interested in reinforcing the idea in our readers' minds that Wikipedia is an encyclopedia that anyone can edit. Part of the workflow of editing these descriptions will be an encouragement to edit additional portions of the article itself.

Please see this mockup for a rough idea of the editing workflow. We would love to hear your general feedback and suggestions on the workflow.

Questions about filtering and/or protecting against vandalism

[edit]

We understand that presenting this feature to all of our readers will expose the descriptions to possible vandalism, and we want to do all we can to minimize nonconstructive edits. Here are some possible ways this can be done:

  • For some of the worst forms of vandalism, the edits will be caught by the AbuseFilter extension.
  • Should we limit the number of edits a user can make (e.g. 5?) without creating an account?
  • Should we hide descriptions entirely for certain types of articles, such as lists?
  • Would it be possible to integrate with ORES and preemptively obtain a "score" for the proposed edit, and approve/reject it before submitting it?
  • Would it be possible to take the Wikidata properties of the item in question, and see if the user mentions any of the properties in the description? (i.e. the more properties are mentioned in the description, the higher the score of the edit)

What other methods (client- or server-side) exist for preventing vandalism?

At best users of the mobile application would have a simple way to create accounts with Google OpenID and Facebook Login and all edits people make would come from an real account. In the absence of a real account I would like a hash of "phone ID + 'Wikidata'" instead of seeing an IP address of the user. ChristianKl (talk) 20:09, 3 November 2016 (UTC)[reply]

Feedback for the user

[edit]

Although the app itself currently does not support any moderation or administration features, the editing experience for the user will not be totally "blind", meaning that the user will receive some form of notification if their edit is reverted. For an MVP, this can be in the form of a native system notification that informs the user of the revert, and gives them the option to navigate to the Wikidata page in question (via mobile web), or to the talk page of the user who did the revert (also via mobile web).

However, this kind of notification is only possible for a logged-in user (it's not possible for anonymous IP edits). Therefore, we're considering the following options:

  • Require logging in when editing descriptions.
  • Limit the number of anonymous edits from the current device to a certain number (5?) before requiring the user to log in.

One other possibility for feedback to an anonymous user might look like this:

  • The user makes an edit to a description.
  • The app remembers the article and the description that was made.
  • The app starts a background service that periodically checks the description of that article. If it detects that the description is no longer the same as what the user edited, it shows a notification for the user.
  • This service would need to have a lifetime (e.g. 1 day?) after which it will stop polling for changes, to conserve data usage.

Are there other ideas for user feedback during/after the editing workflow?

Comments

[edit]
  • just my 2cents: I really like the general idea. More detailed comments:
    • I don't think we should spend any time on tracking reverted changes for not-logged-in users. Users should be told that there are plenty of advantages if they log in, such as the tracking, but setting up the infrastructure and code to do it for them not-logged in - no
    • Before I add the option of easy editing of descriptions, it would be great to be able to efficiently monitor descriptions on the fly too! If I am logged in, I would be really interested in seeing and patrolling all changes to descriptions in topics I am interested in my language. If I could do patrolling on the fly, I would be much less worried about vandalism on the fly. But only improving the tools for one side to the detriment of the other side feels wrong.
    • Basically we have three options: allow anonymous edits, allow 5 edits before requiring login, require login. I can't tell the tradeoff between these three - i.e. how much vandalism occurs in each of them - and I would suggest to tackle this experimentally.
    • I really like the idea of being notified when a revert happens, but really that should be something the app does in general! :D - but yes, here and in particular, too.
    • I love the idea of using Wikidata descriptions as the "gateway drug" to Wikipedia editing

--Denny (talk) 18:30, 31 October 2016 (UTC)[reply]

  • An important point imho: it would be nice to add a screen with a shortened version Help:Description in order to let user knows what is expected (only a few words, do not start with a capitalisation in English...). This screen should be linked from the onboarding popup and the editing interface. I think it would really improve the quality of the descriptions submitted by good faith users and will reduce the patrolling work of Wikidata users/bots (less normalization required afterward). Hopefully it will decrease the number of cases like "I thought that descriptions should start with a capital letter so I have edited X descriptions to add a capital letter and I got reverted". Also it would be nice that, in the implementations, the examples follow carefully Help:Description recommendations. Tpt (talk) 07:19, 3 November 2016 (UTC)[reply]
  •  Support I just want to second this comment - there are some rules we try to follow in writing descriptions in wikidata, and I think it's important that a wider editorship should have the same guidelines (as appropriately abbreviated). Also it looks like the author here may not be fully familiar with those rules given the examples in the demo presentation. ArthurPSmith (talk) 16:46, 8 November 2016 (UTC)[reply]
Thanks for pointing this out! We've updated the mockup with more correct samples, as well as more detailed guidelines when tapping the "help" (question mark) icon. DBrant (WMF) (talk) 14:58, 9 November 2016 (UTC)[reply]
  • Currently Wikidata description of Mona Lisa is "painting by Leonardo da Vinci". You give as an example for a good description "A painting by Leonardo da Vinci" which differs. Is there thinking behind your decision? ChristianKl (talk) 20:18, 3 November 2016 (UTC)[reply]
Thanks for pointing this out! We've updated the mockup with more correct samples, as well as more detailed guidelines when tapping the "help" (question mark) icon. DBrant (WMF) (talk) 14:58, 9 November 2016 (UTC)[reply]
  • Not sure if it's worth while. Descriptions are generally a combination of the label of the P31 and a few other elements. I'm not sure if it's really helpful if people try to type something lengthy in their phone just to find it shortened later.
    --- Jura 10:18, 4 November 2016 (UTC)[reply]
  • First thing I noticed reading through this idea: In the editing example, Wikidata isn't mentioned. I think it would be very confusing for a user to be shown the Wikidata page if their edit was reverted. Especially if it's a first time edit. It might be desirable for them to understand what they are editing (a Wikidata item) but can't think of a good way to introduce of Wikipedia and Wikidata and editing both at once. Frimelle (talk) 22:59, 5 November 2016 (UTC)[reply]
    • I agree with this. At some point, not only in the help section, should the user be confronted with where they're editing. This could either happen in the introduction/tutorial slides or only when they're actually redirected to Wikidata. Before the item view opens there could be a light box or anything informing the user where they are or where that edit was actually made and why they're here now. Charlie Kritschmar (WMDE) (talk) 17:10, 9 November 2016 (UTC)[reply]
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Requests_for_comment/Editing_descriptions_from_Wikipedia_Android_app&oldid=604386819"