Might be partly fixed by https://gerrit.wikimedia.org/r/#/c/36572/ please verify.

(In reply to comment #1)

Might be partly fixed by https://gerrit.wikimedia.org/r/#/c/36572/ please
verify.

Yeah, I noticed, too, that sometimes both source and author fields are flagged as errors, and sometimes only source. That is unrelated to the Gerrit change, though; I got that also without this change.

We also need to clear the "This field is required" message after they click the final "Next" button.

bakert wrote:

Error behavior of required fields in Release Rights section of UploadWizard

Attached:

bakert wrote:

Error behavior of required fields in Describe section of UploadWizard

Attached:

bakert wrote:

(See the two "Error behavior of required fields ..." screenshots attached.)

The "Release Rights" and "Describe" sections are now separate steps in the UploadWizard. It is still true, however, that required fields are marked as such in the "Describe" section but *not* in the "Release Rights" section.

Part of the motivation for this might be that no field (apart from a radio button which has a default selected) is required until you actually change the default selection from "This file is my own work" to "This file is not my own work". However, the required fields are not revealed until you make that change so I think it would make sense for them to be marked in the same was as the required fields in the next step.

Related URL: https://gerrit.wikimedia.org/r/68948 (Gerrit Change I6c0274f9d10bd83d5916a475458b0cc88ddc81c2)

bakert wrote:

View of new Release Rights section with key

Does it look weird to show "* = This field is required." when no required fields are visible?

Attached:

bakert wrote:

This field is hard to mark as required despite being an input as it has no label

Attached:

bakert wrote:

New version of Release Rights section in https://gerrit.wikimedia.org/r/68948

Attached:

bakert wrote:

I've created a patch to fix up the base issue described in this ticket. As noted in the commit message there are still some inconsistencies here and some required fields that are not visually marked as required until you try to "Continue" but this does move the forms closer to consistency.

Thanks for your effort with the screenshots and the patch!

I think merging your change might lead to confusion among the users. Instead I would prefer to make a unanimous decision for this and then get it out in one merge.

bakert wrote:

Thanks for taking a look Nischay.

I'm happy to work further on this now I have a local checkout, etc. if there's consensus on what needs to be done.

The scope of this bug looks very unclear after all these comments, removing "easy" keyword. Bakert, are you able to continue working on this (there are some unanswered comments to your patch) or is your patch abandoned?

bakert wrote:

There was a UX review of this bug done by Jared Zimmerman <jared.zimmerman@wikimedia.org>. He said:

"You have great timing, we're currently working on a project to clean up forms throughout mediawiki. While the designs are still in-progress I'll share with your our ideas thus far about required fields.

In many places where complex forms exist there are more required fields than optional ones, so the pattern that we're using is that the primary action button is in a disabled state until all required fields are filled, and optional fields have helper text displaying that they are optional.

Additionally for some forms we're using in-line validation to help users confirm that the text entered conforms to the formats or content needed.

We are not however using the form validation simply as a "you've completed this step" indicator, as it could get very noisy very quickly.

Zero state
https://www.dropbox.com/s/1xyw2nq38umm9qx/Screen%20Shot%202013-06-20%20at%209.25.57%20AM.png

Partially filled and validated
https://www.dropbox.com/s/p419filfq1zt7cq/Screen%20Shot%202013-06-20%20at%209.26.54%20AM.png

error state
https://www.dropbox.com/s/t2en4yliahmnpkg/Screen%20Shot%202013-06-20%20at%209.27.04%20AM.png

In most cases not allowing the user to attempt to submit forms with missing information will keep them from ever getting into the form error state from the bug your working on."

This was in June 2013. So it seems that this patch is unwanted as it shores up what is fundamentally undesirable behavior. I'm afraid I haven't done any work on a better version as described above.