MobileFrontend/Photo upload/Upload Wizard mobile port

From mediawiki.org

Some considerations when porting Upload Wizard to a mobile UI.

General[edit]

  • UW is built to create uploads that are of sufficient quality to meet the standards on Wikimedia Commons. This means: 1) Correct and legally valid licensing, 2) Useful titles, 3) Descriptions are a must. Categories are optional but strongly encouraged for advanced users. The only reason they're not required is that the Commons category system, by definition, requires proficiency in English.
    • Translating the entire flow to mobile makes it a pretty cumbersome process with lots of typing involved, even if we reformat it nicely.
    • In theory, we have the infrastructure needed to just dump files and add metadata later (stash). However, we wouldn't want to put that obligation on the community, but on the uploader. So one possible flow would be "dump your files via mobile, then log in and complete your uploads on your desktop".
      • If user testing a mobile-formatted UW prototype shows it to be unworkable, we may want to go down this path.
      • There has been extensive discussion with two Commons admins about the metadata requirements on mobile and the current mock-up incorporates these ideas. In other words, we did settle on the bare minimum typing necessary, and also some limitations on licensing and reduced wording of the legal language describing the licenses, which was reviewed by legal. --Pchang (talk) 06:51, 18 April 2012 (UTC)[reply]
  • The UW front-end generating code is all over the place. A fork would be hard to maintain, but adding mobile codepaths to all DOM manipulation may not be much more fun.

Error cases[edit]

Uploads can encounter a number of tricky error cases which require user interaction or automatic resolution. Interactions that are reasonably straightforward on a large screen may pose major issues on a mobile device with limited screen real estate and inefficient text input. These issues stand out:

  1. Form validation issues. When you upload more than one file, and there are any errors in your submission (missing titles, descriptions, title blacklist matches, etc.), Upload Wizard will highlight all the errors and refuse to proceed. Even on the desktop users can get stuck here trying to find out where the problem is. Having a graceful error resolution UI would be a must for mobile.
  1. Title blacklist issues. All uploaded files are matched by name against commons:MediaWiki:Titleblacklist, and the API will refuse an upload if there is a match. (The file can be stored in the stash, but it can't be uploaded.) So, Upload Wizard currently asks the user to correct any titles which match the blacklist, e.g. filenames that are assigned by your camera like DSC23234.JPG.
  2. User input issues. Users will often try to use the same title multiple times, or accidentally upload the same file. This then requires showing a warning, which gets us back to the problems under (1), or silently rejecting content.
  • The warning is already there, and we should keep it. I believe the warning is specific enough to let the user fix the problem by modifying the title. There is some thinking around generating a title that will be automatically unique, for instance by appending the username. --Pchang (talk) 06:56, 18 April 2012 (UTC)[reply]
    • You probably don't want to do that as it would create significant workload for Commons admins to make the titles acceptable (such filenames would not be desirable under Commons conventions).--Eloquence (talk) 18:34, 18 April 2012 (UTC)[reply]

Device specific issues[edit]

  1. "Safari on iOS does not support file uploading, that is, <input type="file"> elements. If your webpage includes an input-file control, Safari on iOS disables it." [1] That means no iOS uploads except by app workaround.
  • Yes, our intent is to flag iOS browser users and direct them to an app, if one is available. A possible workaround is to install a plugin via an app that then allows file uploads from the browser, but this still requires an app.--Pchang (talk) 06:45, 18 April 2012 (UTC)[reply]

Current bugs that affect mobile[edit]

  1. The coordinate (location) extraction is pretty fragile and will extract values like "-1" for altitude which it then refuses to accept. Lots of mobile photos will embed location info, so this is likely to come up. This should be ripped out and re-done, ideally with a map UI to select coordinates.

Account creation[edit]

Currently there's no API method for creating accounts, and doing it through the web requires passing a captcha in our current configuration.

  • To create accounts as part of the app workflow, we would need to add an API method for account creation, including hook points for sending a captcha image and returning the value, and support that in the app.
  • Within the regular web interface, user account creation can, if you follow the steps correctly, send you back to the page you started from. But, the interface currently strongly encourages you to create your user page instead of going back to the page you started.
  • Within the current mobile web interface, Special:Userlogin shows a login form but shows no apparent ability to create an account.