Page MenuHomePhabricator

Make app Wikidata description editable
Closed, ResolvedPublic

Description

It would be nice if the lead image Wikidata description overlay were tappable/editable.

There are definitely UX considerations which will need to be addressed, but I'd like to take a stab at a quick proof of concept to kick off discussion.

My goal would be to work on this during the Lyon hackathon.

Please see the mobile apps page for the hackathon for more details in general.


Video of fully functional proof of concept on iOS:
https://www.youtube.com/watch?v=6VblyGhf_c8
Patch:
https://gerrit.wikimedia.org/r/#/c/215074/ (massively in need of re-base and cleanup as of Feb 11, 2016)

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Krenair added a subscriber: Krenair.

Since you'd be editing wikidata rather than the local wiki, could there be policy concerns here?

hoo added a subscriber: hoo.Mar 4 2015, 4:27 PM

Since you'd be editing wikidata rather than the local wiki, could there be policy concerns here?

The privacy policy is the same, but obviously you need a CC0 license warning and the anon edit notice (for logged out users).

Lydia_Pintscher moved this task from incoming to monitoring on the Wikidata board.Mar 5 2015, 1:42 PM
Deskana renamed this task from Make iOS app Wikidata description editable to Make app Wikidata description editable.Mar 9 2015, 7:20 PM
Qgil added a comment.Mar 9 2015, 9:05 PM

I wonder whether a bot is / scanning all Wikipedias adding the first sentence to the article as the description of the corresponding Wikidata item. Doing that work manually is no fun and very time consuming.

dr0ptp4kt updated the task description. (Show Details)May 7 2015, 5:26 PM
Qgil added a comment.May 18 2015, 11:12 AM

It is time to promote Wikimedia-Hackathon-2015 activities in the program (training sessions and meetings) and main wiki page (hacking projects and other ongoing activities). Follow the instructions, please. If you have questions, about this message, ask here.

Mhurd claimed this task.May 23 2015, 3:57 AM
Mhurd renamed this task from Make app Wikidata description editable to Hacking: Make app Wikidata description editable.May 23 2015, 4:01 AM
Mhurd added a comment.May 25 2015, 2:13 PM

an edit pencil now appears to the right of the article title

when tapped, an interface now appears for editing article description

enter a description, then tap save

now the article has a description, and if you were logged in the edit is properly attributed!

search can now use the new description too

jeblad added a subscriber: jeblad.May 25 2015, 5:33 PM
Qgil added a comment.Jun 1 2015, 5:59 AM

This feature was developed as a prototype but it is still not implemented in production, correct?

Mhurd added a comment.Jun 2 2015, 12:11 AM

@Qgil - not in production yet - going through code review and some design / UX refinements atm.

Mhurd added a comment.EditedJun 2 2015, 12:15 AM

@Vibhabamba - if you have time, lets chat about some of the UX stuff we mentioned during the showcase meeting. i.e. making it easier to see first paragraph when editing descrips - turns out it's actually really tricky as the keyboard comes up leaving you with very little room... also can be confusing if you see too much clutter - i.e. the editing interface + keyboard + sample descrip + first paragraph... hmm...

@Mhurd agree about too much going on if we display it all at the same time.

Notes for Design Iteration:
Call to action/Icon needs iteration

Product Deliberations:
List wikidata and other abuse/vandalism filters employed (Even though Wikidata has this, its important for the team to know what filters we are running )
Using a more universal example that applies to a larger category (Place/person/event) might be bit more useful to users
@jkatz to add productizing/research comments

Communications:
This is a low barrier to entry edit funnel. We *could* socializing the feature if we don't see vandalism after a test period.

Some friendly suggestions:

  • Consider adding a specialised tag for edits to the Wikidata description. That way, edits to descriptions via the app could be easily tracked and curated on Wikidata.
  • It's possible that the existing tag is enough: https://www.wikidata.org/w/index.php?title=Special:RecentChanges&tagfilter=mobile+app+edit
  • When this is being rolled out or tested, this should be socialised to the Wikidata community so they're aware of it.
  • You can use this tag to perform quantitative analysis of how many of the description additions were reverted. This hard numerical evidence can be used to evaluate the success of the feature.
aude added a comment.Jun 2 2015, 6:32 PM

somewhere / somehow, it should be mentioned that their contributions to Wikidata (via the app) are CC-0 license.

Mhurd added a comment.Jun 2 2015, 8:24 PM

Note that there is a functional work-in-progess patch here: https://gerrit.wikimedia.org/r/#/c/215074/

Fjalapeno reassigned this task from Mhurd to Vibhabamba.Jun 2 2015, 9:26 PM
Fjalapeno moved this task from Tracking to Needs Design on the Wikipedia-iOS-App-Backlog board.
Fjalapeno added a subscriber: Fjalapeno.

Assigning this to vibha to discus with jon and get the new mockups made.

Qgil added a comment.EditedJun 4 2015, 10:43 AM

We are trying to help all open tasks listed under "Work continues after Lyon" at the Wikimedia Hackathon 2015 workboard finding their best way forward.

  • If you are participating in Wikimania, consider adding the #Wikimania-Hackathon-2015 project to get this task in that loop, which is about to start.
  • If you think this project could welcome help from a dedicated Google Summer of Code or Outreachy intern, or from an Individual Engagement Grant, add the Possible-Tech-Projects project.
  • If you would like to receive some other type of support (organizing a Tech Talk, establishing contacts with existing developer teams in Wikimedia or elsewhere, travel sponsorship for a related activity... you name it), please create a subtask explaining your request and associate it with Developer-Advocacy (or you can start by commenting here if you prefer).
  • Keeping the description, priority and assigned fields up to date always helps. :)

For some context about this message, see T101151: Evaluate which projects showcased at the Wikimedia Hackathon should be supported further. It is the last communication related to Wikimedia-Hackathon-2015 that we will post here.

@Vibhabamba @Mhurd

@Deskana stole my thunder on specialized edit tags (essential for tracking quality) and community engagement. I guess it was his thunder to begin with...

Other essentials:

  • what about protected articles? They are not necessarily protected on wikidata--I would hate to see Barack's page get vandalized and have nobody fix it because our most active community only looks on desktop.
  • small % rollout + kill switch
  • more relatable example
  • abuse filter documentation
  • do we have validation criteria? Might need character limit and cut-off rules.

Not a blocker

  • It would be great if we could somehow pull an example from something in the same 'category'. By this I mean with the same wikidata 'instance of' property value. If instance of = human, then we might even pull 'occupation'. That way looking up a painter would show you an example from another painter. If there isn't anything with a description, then we could rely on a default. I don't see this as a blocker for a % rollout with a kill-switch.

What not to worry about:

  • I don't think we should worry about specific instructions and criteria at this stage. This belongs to the community to decide and currently the variety is one of the coolest things about descriptions.
  • I don't think we need to be concerned with edit wars yet--casual users wont notice if it gets reverted, experienced users will know what to do. Let's see how it plays out...

@JKatzWMF:

  • The boiled down usage example and text @Mhurd, @Deskana and I came up with at the hackathon reflect the Wikidata community's instructions. Use that and you should be good to go.
  • protected articles: We need to figure out what's worse - not being able to edit a vandalized description or being able to vandalize one. From the feedback I got the former is much worse for people.
  • Edit wars: @kaldari is talking about edit wars between Wikipedia and Wikidata editors over what is shown on the Wikipedia article vs what's useful for Wikidata. This is already happening and causing grief. See my comment at https://phabricator.wikimedia.org/T97566#1337875 please.
Mhurd added a comment.Jun 11 2015, 3:13 PM

Screenshot of the abuse filter message received when trying to enter an expletive for a description:

Vibhabamba added a comment.EditedJun 11 2015, 3:31 PM

Need information on the hard limit that exists within wikidata for submitting a description.
Lydia_Pintscher said she would provide details here.


This is what appears in the edit history of the page.

Deskana removed a subscriber: Deskana.Jun 11 2015, 3:44 PM

The 'Write Description' interface needs to be mention the license under which the reader is submitting the contribution.

Mhurd added a comment.Jun 11 2015, 6:00 PM

@Lydia_Pintscher

Upon further reflection I actually think we actually can't do description editing if Wikidata overloads the "description" field with a delimiter to accommodate the "internal usage notes" :(

Here's why:

We know the field has some size limit, for the sake of argument say 256 characters.

If "description" is overloaded to also contain internal usage notes following some delimiter, we now not only have to strip these notes out in every single place the description needs to be displayed (already half a dozen places in the apps alone), but we also then have to strip the internal usage notes and delimiter out when a user edits the actual description, and we'd have to re-add the internal usage note and delimiter *back* in when we saves the description - otherwise editing would destroy the internal usage note.

Presuming all of that, say a pre-existing note of, oh, 200 characters already exists - this means when we present the editing interface, we actually only have 56 characters which the user can use for a description. Say the internal usage note is 256 chars - this means we cannot have a description *at all*.

Does this make sense?

Ainali added a subscriber: Ainali.Jun 12 2015, 5:12 AM

@Mhurd @Lydia_Pintscher thanks for the heads up--this is a great example of why we do not overload fields in a database and why wikidata should strongly reconsider adding a separate field for instructions if they feel it is necessary.

aude added a comment.Jun 15 2015, 5:31 PM

how common are these "instructions" in wikidata? I realize the items for "male" and "female" have them, but then they have no site links (https://www.wikidata.org/wiki/Q6581097) so think would never appear in the wikipedia app.

aude added a comment.Jun 15 2015, 5:32 PM

also, I notice (at least in android), we don't show descriptions if they are too long (more than two lines). Not sure how we would handle them with editing (maybe show, but truncate with "..."). If editing / adding is possible then I think it's important to show something (the fact that there is a description)

how common are these "instructions" in wikidata? I realize the items for "male" and "female" have them, but then they have no site links (https://www.wikidata.org/wiki/Q6581097) so think would never appear in the wikipedia app.

My guess would be at least a couple dozen with sitelinks. People have been using descriptions to prevent mistaken uses of the instance-of property. For example, "person" (Q215627) has a note pointing editors to Q5 for instance-of uses.

If "description" is overloaded to also contain internal usage notes following some delimiter, we now not only have to strip these notes out in every single place the description needs to be displayed (already half a dozen places in the apps alone), but we also then have to strip the internal usage notes and delimiter out when a user edits the actual description, and we'd have to re-add the internal usage note and delimiter *back* in when we saves the description - otherwise editing would destroy the internal usage note.
Presuming all of that, say a pre-existing note of, oh, 200 characters already exists - this means when we present the editing interface, we actually only have 56 characters which the user can use for a description. Say the internal usage note is 256 chars - this means we cannot have a description *at all*.

I don't follow. Why not just set the character limit to 256 minus the number of characters used by the usage note? I think it's reasonable to assume that that will be enough space.

@Jkatz and I chatted about the case where users paste the first two sentences as a description.
We should think about handling this case.
In the case where the user reads all these 3, there is a fair bit of repetition.

Rationale:

  1. First the use reads the search results
  2. Then he scans the description
  3. Then he reads the lead section.

This way the same content gets repeated 3 times instead of twice.


Vibhabamba added a subscriber: Mholloway.EditedJul 15 2015, 8:41 PM

@Mholloway - is there any way to identify the category of the article?
We can provide better help for the user who is editing the description if we know the category. (Description styles vary based on category)

This may not be required for MVP, but it might help in the future if we find users struggling with descriptions. Wikidata provides specific guidance based on category. For instance style for describing an article about a person (BLP's) is Country > Career.

Aklapper removed Vibhabamba as the assignee of this task.Sep 25 2015, 9:21 AM
Mhurd updated the task description. (Show Details)Feb 12 2016, 2:49 AM
Mhurd updated the task description. (Show Details)
Mhurd updated the task description. (Show Details)Feb 12 2016, 2:53 AM
Mhurd updated the task description. (Show Details)
Mhurd updated the task description. (Show Details)
Qgil removed a subscriber: Qgil.Feb 12 2016, 8:30 AM
JMinor added a subscriber: JMinor.Aug 16 2016, 4:04 AM

Recently requested in OTRS Ticket#2016081410007397

Mhurd added a comment.Oct 26 2016, 8:25 PM

Related: Android Wikidata description editing ticket:
https://phabricator.wikimedia.org/T146641

@Nirzar @cmadeo @RHo

This is the wikidata descrip editing ticket from my Lyon hackathon project - lots of screenshots and discussions... even a youtube video link at the top.

Dbrant added a subscriber: Dbrant.

Untagging Android, since our work on this is tracked in T145813

JMinor renamed this task from Hacking: Make app Wikidata description editable to Make app Wikidata description editable.May 24 2017, 9:33 PM
JMinor raised the priority of this task from Low to Medium.

Resurrecting this ticket as a placeholder for iOS work following on T145813. This should happen this summer, pending community acceptance of the Android roll-out.

Restricted Application added a subscriber: PokestarFan. · View Herald TranscriptAug 10 2017, 2:24 AM
revi added a subscriber: revi.Dec 26 2017, 7:52 AM
LGoto closed this task as Resolved.Mar 26 2019, 9:13 PM
LGoto claimed this task.