MobileFrontend/Photo upload/Feedback

Here is early feedback from two Commons admins:

Admin 1

There should be Back and Cancel buttons available throughout, in a

consistent screen location, that either go back one screen or cancel the upload operation. This would solve a number of navigation problems and replace many of the existing buttons in the interface. In the last screen Cancel would become Done or Close.

I agree that leaving multiple selection out of v1 is justified. I'd

also leave out the sharing on Android information thing. More distraction.

Rather than a text field with a browse button like on a PC, I think

a "Select an existing image" or something button without a text field makes a lot more sense. To most people, filepaths on their phones are quite meaningless and unhelpful.

If there's no multiple selection, you can lose the upload button in

favor of just clicking on the picture. If they click something accidentally they can always go back.

The warning/consent screen should display the selected image. The

two speculative options at the bottom should be removed for now. The Change and Cancel buttons are unnecessary if there are already "Back" and "Cancel" buttons available in a consistent location throughout.

I'm not clear if the licensing statement is hidden by default or

not, but it cannot be hidden in order to be legally valid.

I'm personally very disturbed that CC-BY/CC0 are not license options

for own work, although on reflection this probably isn't worth the UI complexity to make everyone select a license. I would at least want a configuration option for advanced users to change the default license (I would not use this app if it always applied CC-BY-SA).

I can't see what's under Other options. I would be hesitant to put

too many options here, and might leave this out entirely. People aren't likely at all to have PD images sitting around on their phones! They may have images taken by others.

There is no warning regarding derivative works. I have no idea how

to do this concisely and effectively, but we don't want people uploading snapshots of posters, signs, or covers. There are also serious issues with people uploading photos taken with their phone by other people that will have to be addressed somehow.

Yes title will need to be validated to be unique and not too short.

I worry that mobile users may use overly vague titles anyway, but I don't see an easy solution for that, other than an exhortation to "be specific".

For general use, rather than have an "Add other info" button, I

think it would be a lot more flexible (and likely to be used) to have a freeform text "Other info" field which is appended to the description.

Rather than e-mailing them info on how to use it, you could offer to

post it to their Commons and/or Wikipedia user talk page. If you prefer to e-mail them, note that some user accounts already have e-mail addresses associated, and you can e-mail them through Special:EmailUser automatically.

Advanced flow: Making the contest name bigger than the name of the

location seems silly.

The strip at the top behaves differently in Basic and Advanced flow

(whether or stages other than current stage are shown) and this seems needless.

If you know what contest they're participating in in the advanced

flow, I would show e.g. the monument ID field by default rather than bury it.

I'm all for stats and ratings but where will this info be published

so that others on PC can see it?

Rating screen: there are going to be way too many photos to fit on

one screen. You will need Next page/Prev page.

The info on how to use the file on the tracking screen seems

useless. They need to be on PC to use it, and if they're on PC anyway they can check their user talk page/e-mail.

Now my comments on John's comments:

I agree that if you can determine whether or not they took the photo

with their phone that would be really great info to include automatically, for purposes of copyright status determination. It is possible for them to put photos they own rights to on their phone however, so I would not disallow it if this is not the case, although a warning box may be called for ("Are you sure you took this photo yourself?").

Most phones with GPS automatically tag images with GPS EXIF data,

which in turn is automatically used for geotagging on Commons. Therefore no further action is needed here, and I would avoid adding to the UI for this purpose.

In the absence of a reliable connection (i.e. upload fails), some

kind of "upload this later" would be pretty handy. However this makes verifying things like unique title impossible, so I'd be hesitant to "queue up" upload information.

> I agree with almost everything you said, with the one exception of selecting > an image. I thought it would be helpful to have a click to open an image > full-screen. Also, a button makes very explicitly what the expected action > is.

Ah if selecting the image displays it fullscreen then that's fine.

> Are CC-BY/CC0 and CC-BY-SA the only important options?

Yes those three are the only important options. However, I am hesitant to give newbies a choice here if they don't understand what it means. Perhaps a "?" button could be next to the dropdown which, when pressed, pops up a full screen help box explaining briefly the difference between the three. "Your license choice determines how can people can use your work. CC-BY requires that people give you credit when using your work. CC0 does not require this. CC-BY-SA requires that works that are based on yours are released under CC-BY-SA too." Something like that. I realise I should be suggesting this for the Upload Wizard too.

> And I guess we should add a warning about derivative works. However, this is > not present in the current Wizard. Do you think this is something that > should have been added there? I am aware of the legal issues, I think.

The Upload Wizard has the big visual diagram at the beginning which explains about derivative works and many more things, which is why it can afford to omit it later. Perhaps you could take a similar strategy of having a warning screen at the beginning, which very briefly warns: "Do not upload pictures of copyrighted posters, signs, or covers." Sculptures and buildings are immensely complicated, depending on the country and whether the work is on permanent display to the public, so these are better to sort out later after upload.

> Finally, do you think the freeform text field should be visible along with > the title field, or just make it something that can be selectively exposed?

Since there's plenty of room I think it's okay to have a second freeform text field. People are bound to have "other stuff" they want to add but not necessarily in the title. Even if it's left blank 90% of the time it'd still help a lot.

> Also, do you think a categories field should be available? We plan to add > some hidden categories by default.

No, I really think categories should be added later, and probably not by the uploader unless they really want to.

> While we're at it, here is a bigger question about categories: > > We want to assign categories automatically to all photos coming in from this > method, but they would be hidden. For example, there could be a top-level > category like [mobile photo upload] and a sub-level category like [Android > 2.3.6 Safari browser]. > > We don't want to expose the complexity of adding real categories in the > first version. But since these are hidden categories, that could trigger > notifications from a bot that would tell users they haven't assigned > categories to their photos.

That all sounds most appropriate to me. Not unlike how Upload Wizard works. I'm all for users neglecting categories and making Commoners do it, where necessary, although it is good to encourage users to do it if they're willing, since they know the context better. I would also encourage them to visit the file description page on their PC and add more details to the description now that they have a real keyboard.

-)

> I should say that for version 1, there will be a tendency to leave out > features that would suit only a minority of users. The freeform text field > is an example.

Sorry, I wasn't very clear. The idea was it to have it serve effectively as a description field (just basic text, no markup). Although the title is already be used as a description, this text could be appended to the description. Anyone can come along later and reformat things based on the description. The point of this field is to allow them to enter any info they think is important that they don't wanna put in the title (in plain old English).

> The screen that enables an email to be sent would definitely encourage > follow-up on the PC. Do you think some users would want an update on their > talk page only? Should we do both?

Hard for me to predict what people would prefer there. I think some would like talk page only and some would like e-mail only and some neither.

> - Deletions are often based on the lack of metadata such as licensing and > categories. Given that this workflow will "force" some of those things to be > included, I wonder if measuring deletions of mobile uploads will not be > comparable to normal deletions. So one question that arises is: what are the > main criteria for deletion, and another is: what is the percentage of > images, roughly, that are deleted due to lack of licensing, categories, or > other metadata?

I don't have this data. Note that deletions due to missing categories do not ever occur. However, the mobile app has an inherent advantage in that most uploads will be self-taken photos, whereas on the PC many uploads are grabbed off the web. The phone just does not naturally afford that kind of web copyvio. If you implement the suggested feature indicating explicitly when a photo was taken with the current phone, that would make our jobs really easy, since the number of exceptions would be small and easy to review by hand.

> - It would be helpful to know the general status of curating content that > comes into Commons. Is that matching the inflow of content? I had heard that > there is a large backlog of images that have not been curated. So this would > imply that a relatively small percentage of deletions occurs normally.

This is very much true. Curation is ad hoc and occurs as people find stuff, usually while exploring categories, or noticing images in articles, etc. Commons does not have the staff to keep up with the upload rate - even now our deletion requests backlogs run into multiple months. Sometimes I've reviewed recent uploads, and it's fruitful, but we can't keep up with that all the time.

> - Is there any automation being used to curate images, and if so what are > those tools?

No, except for Flickr review and Picasa review, which (for images from Flickr/Picasa Web Albums) verify that the source website license matches and uploads the highest available resolution. I've been talking forever about a machine learning system for detecting possible copyvios, but haven't implemented it yet.

> And finally, can you think of any other metric that could be used to measure > effectiveness? Another one that comes to mind is the number of times an > image is used in articles.

I think use is a far better measure of impact. Images not used in articles are also more likely to be overlooked for deletion, for lack of exposure, even if they have problems. Deletion is not a big concern unless they start to dominate deletion requests, which I don't think is too likely. Keep in mind individual users may be blocked if they persistently upload copyright violations, and the app should report if they are blocked and advise them to visit their user talk page to find out why.

> One last thing on the freeform text field - would it be better to expose the description field? Our current intention was to hide any field that was not absolutely necessary, just because most people will not have the patience on phones. It sounds like the purpose of the freeform text field is in fact very similar to the description field.

> So for example, we could show the title field and underneath have a Description link, which will reveal that field and say something like: "Add a description or the title will be copied into this field automatically." But if you think the freeform field is better or more flexible, just say so.

Exposing the description field would be about the same thing and might be slightly better, I'm indifferent there. I'm calling it "other info" instead of "description" because I want to avoid implying that we actually expect them to type all the information they can find on their phones, since that's awkward - rather it's a place to type "notes" about the picture that they might not remember later when they edit it on the PC. Although I still expect this field to be often ignored, it would greatly benefit curation when the user chooses to supply it.

> Would identifying the photo as being taken from that phone help with the case of a photo depicting something like a poster? I guess that's why you want to have that warning.

> My feeling is that the warning is probably the most effective measure we can take, as it is very likely the photo will have been taken on that phone.

> The hidden categories will make it easier to identify the photos from phones, but maybe that argues the hidden categories should not be hidden?

The phone identification is intended mainly to serve as evidence and can help either to keep or delete a work. For example, if an identical photo was later published on the web by someone who might be the same person, the phone ID provides evidence that it's legit. Conversely, like you said, it helps identify derivative works. Source categories should be hidden - hidden cats are still visible in small text for people who are looking for them.

Admin 2

For added coolness, check the phone ID vs. the photo metadata and ask, 'I took this photo using this phone" or something like that. The assumption is that the person uploading used this camera to take the photo. If not, they can't upload anyway - they don't own it, and we would need OTRS approval from whoever does. That's not going to be done via a phone interface.

I think you need cancel on the same screen area as continue. If they are uploading a photo other than their own, chances are that they are going to need to hit cancel, so don't bury that button.

Can the app determine the user's native language? Will the "description" metadata be input in their native language?

There should be a checkbox to allow the upload to include the geocoordinates. The main benefit of uploading via phone is that the phone has camera + geocoords.

It would also be useful to batch up the uploads for transmission later with geocoords recorded in the saved batch. Often in Australia it is possible to have enough coverage to have accurate geocoords, but not good enough to upload high res photos.

For an intuitive interface, I think the assumption that the user took the photo should be made.

Regarding the complexity of copyright, I think the app design needs to presume that the uploader doesn't know what they are doing, and no amount of UI is going to solve this. The only barometers for an uploaders knowledge of copyright is how many uploads and when was their account created. And their block log, but I'd advise against an app trying to derive intelligence from a block log - it would be wiki-politically incorrect to even make basic deductions from a persons block log.

The community will want the app to support all of the free licenses that Commons accepts. IMO this should be a preference setting rather than a part of the per-photo workflow. Photographers generally have one license they want to use all the time. Commons uploaders generally only use a few other licenses.

Store it as raw text so that the photographer can alter it to be anything that they want, include attribution parameters. The only validation should be that it starts with '{{' and ends with the only '}}' in the string.

In order to also support batches of public domain uploads, or uploading someone elses work, the license options should be in a raw text file that the photographer can easily edit (using a different app). e.g.

-- >8 -- own work:{{CC-BY-SA|my attribution string}} PD-Australia:{{PD-Australia}} Jo Bloggs photos:{{permissionOTRS|1234567890}} -- >8 --

A WMF app needs to tackle the geocoords issue. The WMF does not want to find itself being held accountable for creating an app that publishes peoples private information without their explicit permission- it wouldn't violate the WMF policy, but it would be seen as a major oversight. The app needs to strip out the geocoord metadata before uploading, or the mediawiki software needs an option to strip it before publishing it. I think the latter would be better - as you've guessed this is a growing problem that affects all uploads and not just phone app uploads.

For WLM, in order to ensure that this emerging brand is not tarnished, I think the app should add a category to uploads that allows triage of copyright problems. e.g.

'[[Category:WLM uploads in the United States of America to be copyright checked]]'

We then add an abuse filter rule on Commons to track whenever this category is removed from a file, so people can add a second layer of review to the process of copyright clearance.

Maggie

Not being sure where this language comes from, I suspect that some in the community may have an issue with it: "Please provide copyright information for this work so that others can legally re-use it."

There are two issues I see here. First, from the perspective of uploaders, they may not want others to reuse it or understand that permitting reuse is required. Second, the issue is less urgently that the copyright information is required so that others can legally re-use it and more that if valid copyright information isn't provided, the file will be deleted. I think probably it needs to be made more clear that the license is a requirement for upload. This *may* be necessary for our legal protection as well, since there's nothing in the language on that screen right now that suggests that we do not host content that violates copyright.

Understanding that space is at a premium and simplicity is key, I wonder if it would help to say instead something like, "Files must be legally licensed for modification and re-use. Please provide license information for this work." I do not know if legal would require that you incorporate a link or a reference to Terms of Use, but I wouldn't be surprised if they did. And they might not be 100% (or even remotely) happy with the language I've come up with. I'm trying to keep it short but still cover the grounds, but I might miss the mark.

I like the text under "Own work."

The Commons community is of two-minds about having an option checked by default. On the one hand, they worry that it will encourage people to upload images mindlessly without concern for actual copyright status. On the other hand, they find that it makes it a little easier to single out images uploaded by people who don't know what they're doing, because they all do it under that one license tag. :) Whether you choose to an option checked by default or not, some people may complain.

It seems to me that if the community is on board with the idea, they could easily have the notice bots exclude content marked with your hidden category. Humans might leave notices, but bots then would not. Of course, we can't guarantee that the community will be on board with it. They might think it's a fine idea, or they might balk at being asked to do the categorization themselves. It's always hard to predict.