Page MenuHomePhabricator

Surface both search and upload in a better way (not tabs maybe)
Open, MediumPublic

Event Timeline

Prtksxna assigned this task to Nirzar.
Prtksxna raised the priority of this task from to Medium.
Prtksxna updated the task description. (Show Details)

One option we discussed was to integrate the entry point for uploading a file as part of the sequence of images shown when inserting a file. Before the first image, a placeholder to add a new one can be shown to invite users to upload.

That could also help to establish the idea that users are adding their file to a common repository as part of adding it to the article.

@Nirzar had some designs illustrating that idea that could be added here.

Here is a rough flow

When you open the window it will show the current commons interface but on the bottom there will be an explicit action to upload your own image. clicking on it will open the OS file selection menu.

step 1.png (1×2 px, 1 MB)

You select an image with OS file selection menu and then you see the image you have selected. and we ask a question like "is this your own work?"
Yes = agreed to the terms and conditions and we move forward to upload the image
If user says NO here then we show another screen with instructions to upload it on commons.

step2.png (1×2 px, 723 KB)

This Yes/NO model solves the "checkmark" to enable the upload button.

And here's an alternate interface for the screen 1 where we have bigger area for uploading your own image

alt.png (1×2 px, 160 KB)

the grey area is for commons search results

@Pginer-WMF @Prtksxna what you think?

@Pginer-WMF @Prtksxna what you think?

I think that many of the ideas proposed can work really well. Some comments:

  • The initial window where upload is presented as a continuation of searching the current images (1st mockup) makes a lot of sense to me. It also helps to understand that you'll be uploading your image to the repository of images in addition to using it for the article (which is something hard to communicate, and this helps to that).
    • I think this layout works better than the side by side version where options are presented more as exclusive choices.
    • The missing piece is communicating also that you can drop. I think that even with the first design we can surface the possibility to drop an image a bit.
  • I'm not completely convinced by the "yes/no" model. It provides a clear path forward which I see as an improvement to the current situation (a disabled button and the unchecked checkbox giving no cue on how to proceed). However, the choices given look like a trick question ("are you sure you didn't copied that image from someone else?"). We are not communicating that this tool is only for your own images in advance, and if you choose the wrong choice you are not allowed to upload here. I think we can do a bit more to communicate the purpose of the tool and the effects of the choices.
    • As I commented in T115860, one option could be to show the defaults (about user and license) where the user just has to confirm them. In this way we communicate the tool is for uploading images you authored. If the user is looking for something else, a separate option provides other ways to upload. I think that reflects more the real choice the users are making here: proceed with this tool which is for your own images or go somewhere else. A very basic wireframe showing the idea is shown below:

upload-process.png (577×1 px, 65 KB)

@Pginer-WMF @Prtksxna what you think?

I think adding the upload action in the Search tab is a good idea. We could even make the entire dialog a drop area. Then again, we already allow the user to drop in the entire editing area, we should probably educate the user about this feature here. Once they are trained to do that, they should stop opening the dialog altogether when they know that they don't need see the search results. @Esanders, what do you think?

This Yes/NO model solves the "checkmark" to enable the upload button.

There is a larger problem here. More discussion at T120867 and T115867.