Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Explanation needed what's going on here #47

Closed
jkpubsrc opened this issue May 13, 2021 · 8 comments
Closed

Explanation needed what's going on here #47

jkpubsrc opened this issue May 13, 2021 · 8 comments

Comments

@jkpubsrc
Copy link

The upload is performed as soon as you drop a file. This is quite irritating and breaks with common behavior people expect.

There are two options:

a) Describe this in the special page, or better
b) implement this as a two step process: First drop all files, then click a button, then the upload is performed the way it is performed now.

Additionally I noticed that some uploads failed though I have seen no error message in response to an upload.

@s7eph4n
Copy link
Contributor

s7eph4n commented May 21, 2021

This is the first time this comes up, so I think users' expectations regarding the behavior vary. But it is a fair point.
I would not like to see the two step process, though. The incentive to develop this extension was to allow for the upload of a batch of files every few days in as few mouse clicks as possible. So a two step process would be a step in the wrong direction.

@jkpubsrc
Copy link
Author

I would not like to see the two step process, though.

Well, any kind of upload typically is a two-step process: You perform the selections you intend to, provide the data you intend to, then click some kind of "submit" button. This conforms to regular dialog behavior in applications: You are presented with options, then select either "cancel" or "okay" to either drop your changes or make them persistent. The regular MediaWiki upload is no different.

The incentive to develop this extension was to allow for the upload of a batch of files every few days in as few mouse clicks as possible.

Yes, I considered that. That's why I'd expect to read some kind of text that describes the process in a few words. Users using this extensions will have no mind reading abilities: They like to learn about what's going on before some action is taken. This is even more important as all changes made are immediate: A file dropped is uploaded immediately. As this behavior does not meet the standard behavior one would expect, reading some kind of description on the upload page would be a very good thing.

However please note that some uploads failed without notice. I learned it the hard way: The images uploaded did not show on the page. After investigation I understood that some images have not been uploaded though indicated otherwise.

And additionally - not mentioned above - to accept drag and drop did take a very long time for a larger amount of files.

However, thank you very much for this extension. Don't get me wrong: I like it ;-)

@designnerd
Copy link

designnerd commented Jun 24, 2022

This is an awesome little extension, though I had the same expectation as OP (submit button on form, rather than automatic, unexplained behaviour). If there's no intention to change it to match user expectation, please label the behaviour clearly. Something like: Selecting images auto-submits the form (fill the above field first if needed).

The cost of not doing such, is a significant number of uncategorized images, which can be an ongoing headache to fix (if there's enough users, quite significant). For usability, this would be flagged for not matching standard behaviour (mental model for user expectation from wide/popular convention), for incomplete labelling, and for resulting in error which would rank the usability problem not as cosmetic but as a high (or even critical) priority for a fix in heuristics evaluation scoring.

Failing without notice as @jkpubsrc mentions would push it to a severe/catastrophic eval score (the scoring is relevant to the task at hand, which is uploading images; failing without warning/feedback is high/severe failure of intent). Yes, after making the mistake users will learn what not to do (though if not using for a while repeats are likely to happen) but the principle in UI design is to prevent error before it occurs.

This page, the summary of it, might help to explain why this is important:
https://www.nngroup.com/articles/ten-usability-heuristics/

Here's an eval scale (use case: this may "create significant delay and frustration" say if 15 images are uploaded (edit: which were intended to go into the SAME category) without the warning that summary needs to have the category (used for ALL) added first, (edit: the extension’s order is backward to the standard upload form habit ppl developed, it uploads the images without warning with no category if user thinks they can fill the top field after selecting images). Now the user must edit 15 image pages individually to add this (edit: the SAME category for all images, that they would have put in the first field if they had known the images would auto-uplkoad without warning and submit that field blank)… needlessly, when a warning or a submit button could have prevented.

image

Source: https://measuringu.com/rating-severity/ (combines the varying usability ratings from several known usability metrics authors).

@designnerd
Copy link

How about giving the user a mediawiki setting to toggle a button, or no button, if you are wanting as few clicks as possible? Click-spend does not override error and failure in UI usability priority.

@s7eph4n
Copy link
Contributor

s7eph4n commented Jun 25, 2022

As a wiki owner, why would you use this extension if what it produces does not match your expectation? If you need images classified individually, then surly you would not make this extension available to your users.
In any case, changing the documentation should be easy enough. Go right ahead.

@designnerd
Copy link

designnerd commented Jun 25, 2022

You’ve misunderstood what I wrote. I’ll try again and add changes to clarify:

  • User has 15 images to upload, into same category.
  • Because MediaWiki standard upload selects images first, users are used to selecting images first (years of muscle memory) before adding a category on the SAME upload form, and then submitting.
  • No warning this can’t be done in normal order on extension form (select images, add category for all images in summary/description box, because clearly this is how the thing works, the purpose of using it, how multi upload would need to function)
  • So, user does that, selects images first, intending to fill in the summary box on same form right after, prior to submit.
  • On image selection, images are uploaded instantly without warning, and without the intended category.
  • Result: user has to go edit each file page to add the missed (same for all) category, since form didn’t warn of mandatory input order and auto-upload/submit of both fields at the same time, one unintentionally empty due to order user intended to fill form out. Tedious, preventable.

I’ve had 4 users try without any intro, prep, or background, they’ve reached the same conclusion “why the heck does it upload the images without warning, now I have to go add categories manually because I thought the form would let me add category (to the form’s second field) after selecting the images” (then submit the upload). They’ve been trained by years of mediawiki use to a fill in summary field second order, on upload form, not in first.

Non programmers use mediawiki and have GitHub accounts to submit bug reports and help other user figure things out. I can’t be adding that myself. There are very few multi-upload extensions that allow users to upload images into the same category/categories, without having to jump though multiple extra hoops. Yours seemed like a candidate feedback doesn’t seem welcome. I thought it might be if presented with solid information as to why something is important.

@s7eph4n
Copy link
Contributor

s7eph4n commented Jun 25, 2022

Ok, I understand your use case. But that's not the use case this extension addresses.

@s7eph4n s7eph4n closed this as not planned Won't fix, can't repro, duplicate, stale Jun 25, 2022
@designnerd
Copy link

designnerd commented Jun 25, 2022

Well, thanks for trying to understand. For anyone looking for the described behaviour, here’s a link to a JS found just now that seems to do it (for now until there are MW changes):

https://dev.miraheze.org/w/index.php?title=MediaWiki:MultiUpload.js
It can be accessed at: Special:MultiUpload

But only after adding the following to MediaWiki:Common.js :

mw.loader.load( '/w/index.php?title=MediaWiki:MultiUpload.js&action=raw&ctype=text/javascript' );

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants