MobileFrontend/Photo upload/Feedback

Here is early feedback from two Commons admins:

Derrick
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. also leave out the sharing on Android information thing. More distraction. 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. favor of just clicking on the picture. If they click something accidentally they can always go back. 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. not, but it cannot be hidden in order to be legally valid. 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). 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. 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. 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". 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. 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. location seems silly. (whether or stages other than current stage are shown) and this seems needless. flow, I would show e.g. the monument ID field by default rather than bury it. so that others on PC can see it? one screen. You will need Next page/Prev page. 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.
 * There should be Back and Cancel buttons available throughout, in a
 * I agree that leaving multiple selection out of v1 is justified. I'd
 * Rather than a text field with a browse button like on a PC, I think
 * If there's no multiple selection, you can lose the upload button in
 * The warning/consent screen should display the selected image. The
 * I'm not clear if the licensing statement is hidden by default or
 * I'm personally very disturbed that CC-BY/CC0 are not license options
 * I can't see what's under Other options. I would be hesitant to put
 * There is no warning regarding derivative works. I have no idea how
 * Yes title will need to be validated to be unique and not too short.
 * For general use, rather than have an "Add other info" button, I
 * Rather than e-mailing them info on how to use it, you could offer to
 * Advanced flow: Making the contest name bigger than the name of the
 * The strip at the top behaves differently in Basic and Advanced flow
 * If you know what contest they're participating in in the advanced
 * I'm all for stats and ratings but where will this info be published
 * Rating screen: there are going to be way too many photos to fit on
 * The info on how to use the file on the tracking screen seems

Now my comments on John's comments:

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?"). 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. 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 that if you can determine whether or not they took the photo
 * Most phones with GPS automatically tag images with GPS EXIF data,
 * In the absence of a reliable connection (i.e. upload fails), some

-

> 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.

John
> 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.