Page MenuHomePhabricator

Lack of attribution in mobile image viewer
Closed, ResolvedPublic

Description

Author: bidgee-wiki

Description:
Unlike the desktop browser version of MultimediaViewer, the mobile browser version of MV doesn't any attribution to the creator of the work (which is a violation of the CC-BY/SA) licensing, one shouldn't have to click on "details" to view who created it.

Mobile MV example
https://www.dropbox.com/s/behpcp3lae2x84d/Screenshot_2014-08-12-11-06-55.png


Version: unspecified
Severity: normal
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=42660

Details

Reference
bz69656

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 3:37 AM
bzimport set Reference to bz69656.
bzimport added a subscriber: Unknown Object (MLST).

FWIW the desktop viewer has a similar situation when it cannot find the author name as computer-readable metadata on the file page, and that was not identified by WMF legal as a CC violation, so this should not be one either.

bingle-admin wrote:

Prioritization and scheduling of this bug is tracked on Trello card https://trello.com/c/BB3WPnyo

bidgee-wiki wrote:

(In reply to Tisza Gergő from comment #1)

FWIW the desktop viewer has a similar situation when it cannot find the
author name as computer-readable metadata on the file page, and that was not
identified by WMF legal as a CC violation, so this should not be one either.

It is a CC violation, it fails to attribute the author with the licence.

(In reply to Robert Myers from comment #3)

It is a CC violation, it fails to attribute the author with the licence.

You need to click on the "details" link to see the attribution. This is not particularly different from a thumbnail in an article where you need to click on the thumbnail to see the attribution. The relevant clause of the CC license is very vague (attribution must be present in a form that's "reasonable to the medium"). If you know of any expert opinion according to which a "details" link is substantially different from other forms of clickthrough attribution, please share it - otherwise, [citation needed].

@Tisza, the better question is not if it is strictly legal or not, but wether or not we have the moral obligation to attribute someone.

As I have said before, we need to stimulate the communities to cleanup their licensing and attribution information, so that we can make views like this. It is the only way all of these views are ever going to work.

(In reply to Derk-Jan Hartman from comment #5)

@Tisza, the better question is not if it is strictly legal or not, but
wether or not we have the moral obligation to attribute someone.

The author *is* attributed - you just need to click on the "details" button to read the attribution. IMO the better question is whether placing the attribution an extra click away degrades either user or author experience.

Which is a *question* - pretending it is an answer is unhelpful. Talking about license violations instead is extra unhelpful.

As I have said before, we need to stimulate the communities to cleanup their
licensing and attribution information, so that we can make views like this.

The information is available in this case (cf. https://en.wikipedia.org/wiki/Busabout_Wagga_Wagga#mediaviewer/File:Busabout_-_Bustech_VST_bodied_Mercedes-Benz_O500LE_6086MO.jpg ). I am not familiar with the design decisions of the mobile viewer; maybe the information is omitted because of the very limited amount of space.

bidgee-wiki wrote:

(In reply to Tisza Gergő from comment #4)

(In reply to Robert Myers from comment #3)

It is a CC violation, it fails to attribute the author with the licence.

You need to click on the "details" link to see the attribution. This is not
particularly different from a thumbnail in an article where you need to
click on the thumbnail to see the attribution. The relevant clause of the CC
license is very vague (attribution must be present in a form that's
"reasonable to the medium"). If you know of any expert opinion according to
which a "details" link is substantially different from other forms of
clickthrough attribution, please share it - otherwise, [citation needed].

Sorry but that isn't good enough, a person clicks on a thumbnail on a mobile device but then needs to click/tap on details (isn't going against what the whole point of MV was about, less clicks/taps to information) to view who created it? We (creators can deal with and have accepted that there is no attribution with thumbnails in articles, pages, galleries and categories) but if the desktop MV can have the attribution of the author, why not the mobile version of MV, there is room for it next to the license?

Please have a read of http://creativecommons.org.au/learn/fact-sheets/attribution/

(In reply to Robert Myers from comment #7)

Please have a read of
http://creativecommons.org.au/learn/fact-sheets/attribution/

Please quote those specific parts that you refer to for your argumentation.

bidgee-wiki wrote:

"All Creative Commons licences require that users of the work attribute the creator." "This means you always have to acknowledge the creator of the CC work you are using, as well as provide any relevant copyright information."

"When attributing a work under a CC licence you should:

Credit the creator;

Indicate the type of licence it is available under and provide a link to the licence (so others can find out the licence terms);"

They also give an example on how it can be done.
http://i2.wp.com/creativecommons.org.au/content/Flamingos-Partying-Pedro-Szekely-flickrstorm-attribution-web.png?resize=300%2C150

Source: http://creativecommons.org.au/learn/fact-sheets/attribution/ Creative Commons Australia CC-BY-4.0

daniel wrote:

Robert Myers' "After" screen shot looks like a pretty sensible solution to me. In its current state it is not obvious to me that clicking on the license name takes you to a "details" page.

I understand that especially on mobile devices screen real estate is precious, but it is also precious to our contributors to have a prominent attribution.

Gergő argues, that this view "is not particularly different from a thumbnail in an article". However the net effect of this is that, coming from the article, you just have added yet another layer of clicking and removed the attribution one step further away. It does not surprise me, that this irks some contributors.

The problem of determining the correct attribution seems to be pretty much solved on desktop. At this point it is a choice whether to implement this properly on mobile. I'm arguing for displaying the uploader next to the license.

I'm confused. I think 2 things are getting mixed up here. If there was no media viewer in mobile, clicking the image would take you to the File page where there is attribution. We don't attribute in photo captions... So I'm baffled to the idea that we are not fulfilling our legal obligations in the current setup (I can add Luis from legal to verify this if you need me to if necessary)

That said I do think this is a great opportunity to showcase the user who took the photo and we should take it. On mobile we have a last modifier bar for articles to give prominence to editors so I think it would make sense to do this for photos too! I say yes we should be doing that.

Whatever happens though we should be careful to do this consistently on both desktop and mobile and we should think carefully about such a solution as we are not in a rush as we are not violating the license.

The desktop viewer uses the extmetadata API to get the author:

https://en.wikipedia.org/w/api.php?format=jsonfm&action=query&prop=imageinfo&iiprop=extmetadata&titles=File:Busabout_-_Bustech_VST_bodied_Mercedes-Benz_O500LE_6086MO.jpg&iiextmetadatafilter=Artist&iiextmetadatalanguage=en

and then strips all tags other than <a>. I assume the mobile viewer already uses the extmetadata API already to get the license name, in which case getting the author should be easy.

Would be good if that API returned the username rather than a link. Is there a bug open for that?

bingle-admin wrote:

Prioritization and scheduling of this bug is tracked on Trello card https://trello.com/c/2OmzBt3E

Damn, my fault: iilimit is 10, so the "only string" is an old revision.

(In reply to Jon from comment #14)

Would be good if that API returned the username rather than a link. Is there
a bug open for that?

Bug 57308. The extmetadata API shows the author, though, not the uploader; that's freeform wikitext parsed from the {{Information}} template - in this case an internal link, but could be more complex, e.g. [[commons:File:RhB_Ge_4-4_II_Wiesener_Viadukt.jpg]] or [[commons:File:Fomalhaut_planet.jpg]].

bidgee-wiki wrote:

When will this be addressed? I've raised this four days ago and the last response was three days ago.

I shall cease any further uploads to WMF's projects until this has been addressed.

(In reply to Robert Myers from comment #19)

When will this be addressed?

See comment 15 for scheduling.

bidgee-wiki wrote:

It states nothing other then "Needs analysis" and "Archived", it has nothing regarding scheduling (ie: fix scheduled/planned to be complete on 1 Sept).

Yes, nothing scheduled yet, and for non-high-priority issues like this one I don't expect scheduling to happen within four days. Hence patience is required.

It will be implemented within the next week. Just waiting on some feedback from Moiz currently (the designer).

Can somebody on the team evaluate why this issue continues to arise repeatedly? I first reported the same basic issue in December 2012, and devoted a good deal of time to helping the team find an adequate solution. Why did this not "stick"? https://bugzilla.wikimedia.org/show_bug.cgi?id=42660

@Pete F: But that are two totally different bugs, am i right?

(In reply to Florian from comment #25)

@Pete F: But that are two totally different bugs, am i right?

Yes, you are right. Sorry if I wasn't clear. My point is that the underlying issue is the same, and that once an issue like this has been pointed out by volunteers to a product team, ideally the WMF should develop the ability to avoid similar mistakes (serious mistakes!) afterwards.

(sorry for the title change, I'm tired of getting pinged on this bug :))

bingle-admin wrote:

Prioritization and scheduling of this bug is tracked on Trello card https://trello.com/c/QohbVoc2

Sorry Pete F, i still don't understand :/

to avoid similar mistakes

This issue, if i read and remember correctly, isn't a real legal issue, it relies on how to interpret the CC correct. And if i read correct, in this bug report Jon pointed out, that it would be great, if the name of the image uploader is visible in mobile MMV :)

(In reply to Florian from comment #29)

This issue, if i read and remember correctly, isn't a real legal issue, it
relies on how to interpret the CC correct.

I don't understand what you're saying -- if the way to interpret a legally binding contract correctly isn't a "real legal issue," then what is?

And if i read correct, in this
bug report Jon pointed out, that it would be great, if the name of the image
uploader is visible in mobile MMV :)

I think it is a legal requirement -- and even if I'm wrong, it's certainly a core Wikimedia value -- to clearly communicate who the copyright holder (often not the uploader) is. The current version simply puts a bunch of confusing, jargony gibberish below the photo, like:

CC-BY-SA-2.0 [Details]

What is a reader supposed to make of that? What do they learn from it? Has ANYTHING meaningful been communicated?

I don't understand what you're saying -- if the way to interpret a legally
binding contract correctly isn't a "real legal issue," then what is?

maybe you read comment 4 and comment 6 again :)

(In reply to Tisza Gergő from comment #4)

(In reply to Robert Myers from comment #3)

It is a CC violation, it fails to attribute the author with the licence.

You need to click on the "details" link to see the attribution. This is not
particularly different from a thumbnail in an article where you need to
click on the thumbnail to see the attribution. The relevant clause of the CC
license is very vague (attribution must be present in a form that's
"reasonable to the medium"). If you know of any expert opinion according to
which a "details" link is substantially different from other forms of
clickthrough attribution, please share it - otherwise, [citation needed].

It's an additional click.

(1) you're looking at the Wikipedia article, which contains a thumbnail, but no attribution.
(2) you click the photo, which contains no attribution.
(3) you click a second time, and finally get to a page which, we all agree, has always made it difficult to find proper attribution, even once you arrive there.

So the introduction of this feature takes an already iffy situation, and makes it *more difficult* for a reader to find the attribution.

Change 155792 had a related patch set uploaded by Kaldari:
Adding attribution information to mobile media viewer

https://gerrit.wikimedia.org/r/155792

Pete: I'd be happy to discuss process issues, but not inside this bug. FWIW, I don't think there was any overlap between the people involved in bug 42660 (Kenan, Jon, MaxSem) and the people involved in the development of the mobile media viewer (Maryana, Juliusz, and now me). The product manager, designers, and developers have all changed since then.

Change 155792 merged by jenkins-bot:
Adding attribution information to mobile media viewer

https://gerrit.wikimedia.org/r/155792

We should strive to bring the attribution logic of the desktop and mobile version in alignment. There's a lot of complexity here, and it'll only grow as we expand into the remaining edge cases.

Right now, MMV (desktop) displays author _and_ source by default. That's a safe bet that'll make most people happy as it also satisfies use cases where authors specifically want the source to be named (such as a photographer's website). I would recommend adopting this for mobile as well, at least until bug 65445 can be resolved (which requires some template cleanup and possibly changes to the CommonsMetadata extension) so that cases where attribution beyond the author name is required can be satisfied, while the attribution can be kept minimal where it is not.

Stripping out all links from the attribution as the mobile version does right now) is problematic, as an author's name often only becomes uniquely identifying by linking it to a userpage or website. What's the reasoning behind this? A more conservative sanitization approach should suffice.

(In reply to Erik Moeller from comment #36)

Stripping out all links from the attribution as the mobile version does
right now) is problematic, as an author's name often only becomes uniquely
identifying by linking it to a userpage or website. What's the reasoning
behind this? A more conservative sanitization approach should suffice.

The reasoning is that on a mobile screen, we have a lot less space to work with, and it's a lot harder to provide a bunch of text, tappable links, AND still show the file :) The license text link is already pushing it as far as reasonable tappable area is concerned; if we were to add another tiny link right next to it, chances would be high that many users would fat-finger and end up somewhere really confusing (e.g., a user page not formatted for mobile when they were looking for license information, or vice versa). If we were to make those links bigger and more spread out so as to be more easily tappable, we'd lose screen real estate for the actual image. If we were to make that page bigger and scrollable, we'd basically be rebuilding the file page for no discernible reason, since it already exists. You just can't have your cake and eat it, too :)

Our current solution is to assume that 90% of users tapping on a thumbnail on a Wikipedia or sister project on a mobile device just want a bigger view of the image; we want to educate those users about the author and license, but not in a way that disrupts what they came there to do on that page in the first place. From this view, they can tap again to get to the file page, where all the salient licensing and author links are contained on a larger scrollable page, in a much more tap-friendly way. I think this is the best solution for the mobile form factor; I'm not sold on the "desktop experience must match mobile experience" argument in this case.

If you disagree and/or would like to continue this discussion, I suggest you start a thread on the mobile mailing list.

I agree with most of what Maryana said. Duplicating the desktop UI on mobile would be a big mess and would not be very usable on a small touch device. This is why we provide a very prominent button linking to the file page (more prominent than what is used on desktop). I support keeping the UI here as minimal as possible.

OK. Most licenses do give us some leeway in terms of "reasonableness" of how attribution requirements are met in practice. There's been lots of discussion about this especially recently with regard to desktop MMV to make sure we're in compliance and follow best practices as well.

I'll do a concise write-up of what we've learned about attribution requirements on dektop MMV for the WikimediaMobile list (with CC to Luis) so the team can make a call on any changes/improvements based on specific constraints of mobile, legal requirements and community input.