[UX][A11Y] Visually indicate a View Display is disabled

[laryn]

The main content of the view display gets greyed out if it is disabled, but the main link to the display does not. I think it makes sense to carry that through to the display links at the top like this:

---

PR: backdrop/backdrop#3049
Alt PR: backdrop/backdrop#3058

[indigoxela]

Good catch and it's a minimal change.

[ghost]

My only concern is that people may not realise they can click on the disabled view display to re-enable it...

[jenlampton]

We also need to check that contrast for accessibility. We might want to do a ghost button instead.

[jenlampton]

Yeah, there's not enough contrast between the button background and the text color:

[jenlampton]

Well, it looks the contrast on the rest of the disabled UI is not readable either... Should we fix both in this issue, or create another?

[klonos]

How about indicating disabled displays by making the "This display is disabled" text a warning at the top of the page, instead of using opacity? That way, we don't have to worry about readability. Then we could be appending (disabled) in the display link as well.

Something like this for example?:

...and I think that we should also be indicating disabled displays in the main views listing page:

PR: backdrop/backdrop#3058

[olafgrabienski]

How about indicating disabled displays by making the "This display is disabled" text a warning at the top of the page, instead of using opacity?

Not sure but an Interesting idea! If we choose this approach, I'd prefer a blue info message instead of a warning to not confuse it with the "All changes are stored temporarily" warning which appears as soon as you start to configure a view. In any case, for a disabled display it should be sufficient to just inform about the state.

[klonos]

Yup, it indeed feels better with the message being of type info instead of warning. Great suggestion @olafgrabienski 👍 (I've updated the PR)

[olafgrabienski]

Thanks for updating the PR, @klonos. As we have two PRs now, I've added the needs - more feedback label to the issue. I'm still not sure which approach to prefer. However, if we choose your PR, I'd suggest to display the name of a disabled display as 'line-through' (see screenshot mockup at bottom).

I've also tested @klonos' PR in the sandbox site. It works fine but when I saved a view, the info message was rendered twice. Speaking of the info message, I'd prefer to not show the info at the top but below the warning message, so that the info is placed directly above the Displays heading when there are other messages.

Screenshot mockup: strike-through for name of disabled display

[klonos]

I'd suggest to display the name of a disabled display as 'line-through'

I'm neither hot nor cold re this; let's wait for some more feedback before I update the PR.

when I saved a view, the info message was rendered twice.

Ah yes, this does happen sometimes. Usually the solution is to add a "blank" backdrop_get_messages() before the actual backdrop_set_message(t('bla bla bla')). I'll test locally and update the PR if that indeed fixes the issue.

I'd prefer to not show the info at the top but below the warning message

Hmm 🤔 I don't think that you can control the order of messages thrown by backdrop_set_message() (although that'd be nice), but I have an idea re this issue: we can use the same approach as in #3330 (but we should really at some point implement #3329 in the Form API level). ...I've updated the PR to implement it that way. Here's current behavior:

...and here's a screenshot from the updated PR (with the "dirty form" message):

[ghost]

Is the duplicated messages related to #4247? Maybe it's a broader issue...

[klonos]

Yes @BWPanda, it is. I've missed that issue, so thanks for pointing it out 👍

[laryn]

I like this (and agree we might as well fix the grey-out accessibility issue right in this issue). The info message is great, and adding "(disabled)" to the display name works for me. I don't have a strong opinion on whether to also add a lineout to the name.

[indigoxela]

Seems like this issue has stalled back in early 2020. Changes have been requested, but never got addressed. Additionally, this PR contains loads of completely unrelated changes. Time to remove the milestone.