A question about desired behavior.

The goal of this change, as I understand it, is that the "publish changes" button should be disabled if clicking it would cause nothing to change. The most basic scenario would be this one:

• When the user is adding a new caption in a given language, the button should be disabled until some text has been entered

What about this scenario:

• When the user is editing an existing caption in a given language, and they clear the existing input text, should the publish changes button be enabled or not?

Would replacing an existing caption with an empty string delete that entry entirely, or replace it with a value of ''?
Should we only allow the user to delete captions by clicking the red trash can icon?

I think that enforcing the latter would be the simplest solution – a way to delete existing captions is already provided; disabling the "publish" button when the user attempts to replace an existing caption with an empty text field seems like a sensible course of action, and it would allow a more straightforward implementation. But maybe there are other reasons I'm not considering to not do this.

Once the desired behavior has been defined, enforcing it with a qunit test seems like a good follow-up step.

I agree that we should allow the user to delete captions with the trash can icon only. Clearing an existing text input shouldn't be save-able.

@PDrouin-WMF I agree that the trash can should be the way that users delete captions, rather than submitting empty values.

After thinking about this a little more, I realize that I was only considering the single-caption scenario. We have one "publish changes" button but there could be an arbitrary number of different captions fields in various languages. So here is another scenario to consider:

• when the user is editing in a panel with multiple captions in different languages, and they add a new empty caption in an additional language without making changes to the existing captions, should the publish button be enabled or not?
• when the user is editing in a panel with multiple captions in different languages and they clear the text for one or more existing caption text fields, should the publish button be enabled? Should the emptied captions be deleted in that case?
• what if the user simultaneously adds a new caption in a new language and clears out the text of an existing caption in a different language?

I think those added scenarios help clarify the issue, thanks for thinking through things. I am now in agreement with you and @Ramsey-WMF about it.

Guys, this is an awful lot of thinking and, potentially, a lot of code, just to decide whether a button should be enabled or not.

If the 'publish' button is enabled, but there are no save-able changes, then the code already handles that and instantly switches the form to 'read' mode without sending anything to the API. IMHO that's probably good enough.

Are we sure the effort required to implement (and maintain) this ticket is worth it?

@Cparle at this point I agree with you, not worth the effort developing/maintaining this code for something that is already handled.

Alright so, there's a short answer and a long answer to this.

Short answer: let's put this off for now, and possibly revisit it once more major concerns have been taken care of. However, we should still plan on doing it via the method agreed upon yesterday (the complicated way) at some point.

Long answer: From a product perspective, this is of minimal concern. From a project perspective, it's currently not worth developer time if it is indeed going to be a hassle as our Senior Engineer says it will be :). However, given the current push for "polish" and "doing it the right way" on this project, regardless of technical constraints, I don't think we can completely ignore it. For now, let's focus on the work related to our immediate, higher priority concerns, then we can possibly revisit this in a "polish pass" at a later date.

I think that if we are going to take a deeper look at polish and user experience, it might be worth looking at UX differences between the Captions and Depicts panels to see if we can make them more consistent.

For example, in the Depicts panel, the user can click the input box to add items without explicitly shifting the panel into "Edit" mode – the shift happens automatically once they click in the empty field and start typing. But in the captions panel, the user must click that button before they can do anything. Should users be able to click the empty placeholder text that says Add a one-line explanation of what this file represents and automatically enter edit mode as well?

@Ramsey-WMF maybe we should create a new workboard that is attached to a tag (probably not a Milestone exactly) for UX polish? Then we could remove this ticket and others like it from the short-term deadlines without totally losing the thread.

This is another one of those complicated answers :)

We have talked about this internally before, and certainly everything is up for revisiting as we learn more about how people actually use the thing.

But a key thing to keep in mind is that in the very near future, captions and all other statements won't live in the same place on File Page (they already don't on UploadWizard), and we're treating captions in general as just an extension of "regular" content in terms of UX. So I think it's fine if they don't share UX patterns as long as said UX patterns are consistent with the context we're presenting these things in (with captions we're really trying to encourage all types of users to add content, while with other statements it's more heavily skewed towards certain types of editors). @PDrouin-WMF has thoughts, I'm sure :)

As for how we handle it on boards, we already have an SDC-Design board where we could stick tickets like this, potentially in a new column. Again, I'd look to Pam for input on that.

In T216454#4976757, @egardner wrote:

I think that if we are going to take a deeper look at polish and user experience, it might be worth looking at UX differences between the Captions and Depicts panels to see if we can make them more consistent.

For example, in the Depicts panel, the user can click the input box to add items without explicitly shifting the panel into "Edit" mode – the shift happens automatically once they click in the empty field and start typing. But in the captions panel, the user must click that button before they can do anything. Should users be able to click the empty placeholder text that says Add a one-line explanation of what this file represents and automatically enter edit mode as well?

@Ramsey-WMF maybe we should create a new workboard that is attached to a tag (probably not a Milestone exactly) for UX polish? Then we could remove this ticket and others like it from the short-term deadlines without totally losing the thread.

@egardner polishing Captions/Statements is something I'm currently working on, now that we have consolidated feedback from internal stakeholders. Currently, I have a bunch of stub tickets on the Design workboard, and I'm meeting with Ramsey today to review prioritization before fleshing out individual tickets. Workboard is here if you're curious: https://phabricator.wikimedia.org/tag/sdc_design/

Change 492976 had a related patch set uploaded (by Matthias Mullie; owner: Matthias Mullie):
[mediawiki/extensions/WikibaseMediaInfo@master] Only enable submit button when there have been changes

https://gerrit.wikimedia.org/r/492976

I've submitted a patch to address to submit button states, replicating the logic of what it actually submits.
Basically: whenever you have any input that has *changed*, the button will become active & you'll be able to submit it.
Incomplete input (e.g. added a row, selected a language, but no content) is just ignored: if that's the only change, submit button will still be disabled - if there's another change, submit will be enabled, but the incomplete row won't be submitted.

Change 492976 merged by jenkins-bot:
[mediawiki/extensions/WikibaseMediaInfo@master] Only enable submit button when there have been changes

https://gerrit.wikimedia.org/r/492976