Apps-android-commons: Thinking about a combined "share" GUI

[psh]

I spent some time in Sketch today thinking about what a user interface might look like if we combined the single-share and multi-share activities into a single workflow. The thought experiment was about sharing 4 images with the Commons app, noting that we've had requests for

• the ability to add title + description to all images in a set
• pinch + zoom to scale the image
• ability to review images and see them more clearly
• clearer presentation of the policy declaration that doesn't interfere with the image

(Issues #604, #1074, etc)

Both the top and bottom cards would be (independently) collapsable to allow full access to the image. Without the previous smoky transparent overlay the image is fully visible. The small images in the top card scroll horizontally and tapping one pulls it up as the full screen image for review.

Note: if you were uploading only a single image then the top card would be hidden, and this first step of the wizard would be skipped taking you directly to adding title and description.

The wizard would step forward through the images making each the background of the whole screen to let you pick the best title + description. We could name them the same as we do now - prefill the title - with the set name and a sequence number. It would make sense to auto-collapse the top card as the wizard is now in control of which image is "selected" in the preview list - its tied directly to the step of the wizard that we are on.

When we're done stepping through giving titles to them all, we add categories. As with the current upload these are common across all the group. Is there a need to tie them directly to each image?

Lastly we would select the license and show the _"By submitting this picture, I declare that this is my own work, that it does not contain copyrighted material or selfies, and otherwise adheres to Wikimedia Commons policies."_ at the point of tapping submit.

The number of steps is dynamic based on the number of images shared.

If I share a single image then we would show a 3 step wizard

• Step 1 of 3 - enter title + description
• Step 2 of 3 - select categories
• Step 3 of 3 - license and policy click-through to submit

[nicolas-raoul]

Thanks for these nice ideas!

One thing: I am very hesitant to reduce the space available for category search. Category search is the most important part of the app, I would say, as uncategorized images are not worth their bytes. Finding the right categories is hard enough with full-screen on a large smartphone (I scroll hundreds of category suggestions for each picture I upload: location-based suggestions, history-based suggestions, filename-based suggestions, then by trying various words/synonyms describing depicted things), I can not imagine what it would be with only 3 lines :-/

[misaochan]

I love these! I think it's a step in the right direction in general, especially the collapsible top and bottom cards.

A few concerns:

• Is there a need for "name this set" for multiple uploads? We do have that currently (when you select multiple images in gallery and tap 'share'), but it actually REPLACES the title/desc, it isn't additional to it. This is legacy code, which we are likely to ditch in favour of a uniform title/desc screen for all.
• I think the category selection card could be automatically uncollapsed, since by that stage it is more important to have the screen real-estate for categories, not the image. This might help alleviate the issue @nicolas-raoul raised
• Categories must be the last step (after license etc) if we want to maintain our current flow of initiating image upload before the user selects categories. We cannot submit a license after the image has already been uploaded, as AFAIK licenses are mandatory for all uploads.

I do, however, question if we want to keep that flow at all. We have had a lot of headache with bugs caused by the current category modifications, and things could be a lot simpler if we submitted everything at one go, instead of uploading the image and then submitting category modifications. Category selection takes only about 30 sec anyway, and since all uploads are automatically queued and function in the background, I don't think it would interrupt anyone's workflow at all if we postponed the upload til the user has finished the entire process, as nobody would actually be stuck waiting for the upload to finish before they could do anything.

• Re: tying category selection to specific images... I personally am actually in favour of only allowing multiple uploads for a single specific subject, for instance if the user took a few pictures of a Christmas parade or of a specific food item. Hence I would personally be in favour of only one title/desc screen for all, and only one category screen for all. I believe that this fits our use case better - the user would not be pulling hundreds of photos from his hard drive with the intention of stepping through each one; rather, he would often be uploading on the go, e.g. on his way back from the parade. However, this is different from how the Upload Wizard handles bulk uploads (the Upload Wizard, AFAIK, allows individual selection of everything), so it would need to be made explicit to the user.

[psh]

So, tweaking thoughts about the category search - is this more of what you were thinking?

allowing for the top card to (optionally) be collapsed / expanded to see more

[misaochan]

Yes, that looks great IMO! :)

[psh]

I lightly tweaked the final step of the wizard - added a white background and the state (expanded / collapsed) of the top card would carry over from step 6 - to save the "Step __ of __" jumping around as you tap "Next".

And to get a sense of the expected behavior when the keyboard is opened - space between the cards would collapse as far as possible, and then the screen would scroll depending on collapsed/expanded state of cards, screen size, etc.

It would be amazing if there was a server component to the upload process - the client sends a single multipart form submission containing both the image & it's categories. From the app perspective it's one seamless transaction that either works or it doesn't - nothing gets out of step - while on the server it can be processed in as many steps as needed.

So, outstanding questions

• Should we drop the "name this set" step at the start of the workflow given that it's legacy code?
• Is the change of underlying operations (dont start uploading until the user taps "Submit" on the whole process) a change we want to adopt?
• Is the new category selection going to meet your needs @nicolas-raoul ?

[sivaraam]

Just a little nitpick about the Licensing step. In case my assumption that, the text "Wikimedia Commons" is a link to the actual policy in Wikimedia Commons, is correct. Then I guess the link text should actually be "Wikimedia Commons policies".

[psh]

Thanks for the feedback @sivaraam - I've updated the design mockup to include your thoughts.

[ilgazer]

Is there any interest in working on this feature or having a newer shinier UI?

[misaochan]

@ilgazer Yes, I am thinking about including this as a task in our future PG application. :) Or are you interested in working on it? It will be quite a big task, though, as it would involve a substantial overhaul of the underlying mechanism as well, not just the UI. I think @psh has done part of it at #1503 , but the PR isn't functional yet at the moment.

If we implement this we also need to think about how to handle existing features in ShareActivity like the Zoom and Coordinates buttons, as well as information about licenses etc.

[ilgazer]

Unfortunately, I don't have enough free time to undertake such a
significant task, but I believe working towards overhauling the upload
process and finally fully decoupling it from the upload UI should be much
more achievable and could be one of the long-ish term goals of this
project. Unfortunately, I lack the experience in software architecture that
would be required to lead such a project, but I would definitely try to
contribute if you laid out the framework for what needs to be done.

On Thu, 2 Aug 2018 at 12:24, Josephine Lim [e-mail] wrote:

@ilgazer https://github.com/ilgazer Yes, I am thinking about including
this as a task in our future PG application. :) Or are you interested in
working on it? It will be quite a big task, though, as it would involve a
substantial overhaul of the underlying mechanism as well, not just the UI.
I think @psh https://github.com/psh has done part of it at #1503
https://github.com/commons-app/apps-android-commons/pull/1503 , but the
PR isn't functional yet at the moment.

If we implement this we also need to think about how to handle existing
features in ShareActivity like the Zoom and Coordinates buttons, as well as
information about licenses etc.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/commons-app/apps-android-commons/issues/1128#issuecomment-409864298,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHRLo0UnE72YQReKOC5PkW6bkrIrGIDdks5uMsVogaJpZM4R_ckt
.

[ilgazer]

I took a better look at psh's work in #1503 and it seems that he has done more of the work than I initially remembered. I think I have enough time before school starts to get it to a working state.

[misaochan]

@ilgazer That would be wonderful if possible! Please let us know how you get on. Even if you don't have time to do everything, just getting the PR into a functional state would be great. We can then polish it up and add the extra upload components. :)

[ilgazer]

I had lots of free time yesterday and today so I got the PR into a working state. The duplicate and darkness checking etc isn't here yet but uploading works and the category addition workflow is much better(The categories get uploaded along with the file) than the "upload and add later" workflow for ShareActivity. As I don't have permission to create new branches on commons-app, could you create an "upload-overhaul" branch so that I can submit a PR to it? IMO getting the initial PR accepted with minimal features would be ideal so that testing can start as soon as possible.

[misaochan]

@ilgazer Wonderful! Done, please submit your PR to https://github.com/commons-app/apps-android-commons/tree/upload-overhaul :)

[ilgazer]

By the way, should I do separate PR's for new features(darkness checking, some new screens for EXIF editing etc.) as per the "one PR per feature" or go on with this single PR which will end up resolving like 6 issues?

[misaochan]

I'm personally OK with either, since it is an "overhaul" PR that will be sent to a separate branch, and all of those changes are related to the overhaul. Thanks for the PR btw, we will test it ASAP. :)

[misaochan]

This is almost complete and we will have a brand new upload UI soon. :)

Thank you so much to everyone who contributed to lay down the foundation for @maskaravivek to work on it, especially @psh and @ilgazer . Hugely appreciated!

[domdomegg]

Fixed in #1968