Make disabled status more obvious in a View

I agree that it should be advertised more prominently on the Edit page, if a View is disabled. Currently, the only difference is no "Path /archive" (for example) for a disabled View with a page. Another minor difference, is the second right side drop down, where "View Page" has been removed, so instead "Duplicate Page" is shown.

Perhaps change the background color, and make it the same as for unpublished nodes, and show an alert text at the top?

Also, it would be nice to be able to disable and enable a View from the View edit page, and I created a follow up issue for that.

Thank you @ressa for working on this. But according to my view this should be handled from php instead of adding it via css. For an multilingual sites it is hard to handle the translations if the plain texts are added via css using content attributes.

Thanks for the fast review @Mithun S, I really appreciate it.

And yes, you're right -- it's best if it's translatable, and I have updated the MR.

Think usability may need to take a look. The red kinda reminds me of node preview when something is unsaved. So looks like the view is unsaved.

Thanks for the feedback @smustgrave, let's try with grey instead.

Limit the grey background to the view region.

Thanks again!!. The approach that is followed looks good to me. But I see there is a impact on the view edit form. The font size of the text Advanced got increased in the right sidebar and the PR has some impact on it. Could you please check ?
Note: Please donot change the font size of Advanced via css.

Changing the status to Needs work. Thank you!

Nice catch @Mithun S :)

I didn't actually change text size via CSS, it was an odd side effect of adding a H2 tag ... I have instead added an exclamation emoji to draw attention, as well as a line break which is allowed inside an <h1> tag:

[...] you can use the following convenient elements inside of a header tag in HTML5: a, em, strong, code, cite, span, br, img.

From https://stackoverflow.com/a/19779520.

Also, <h1 class="unit-title clearfix">⚠️ Note: This view is disabled.<br>Displays</h1> validates on https://validator.w3.org/nu/#textarea.

Fyi did mention in #ux https://drupal.slack.com/archives/C1AFW2ZPD/p1708440649188029 here and it seems will require it to be brought up.

@rkoller made some good points

i think it might make sense to discuss the issue in a group context. i see a few aspects worth having a discussion. for one, for sighted users the used visual pattern might be more prominent or even use a warning admin notice or an info admin notice. but cross checked the user interface standards but there is no remark about that case: https://www.drupal.org/docs/develop/user-interface-standards → but also from an accessibility perspective i wonder if the current proposed solution might go unnoticed for screenreader users? perhaps adding a detail in a visually hidden span to the page title might be an option? therefore i think it “might” make sense to discuss it in a group context.

this report doesn't seem to recongse 10.2/11 branch does have messaging for this.

IMO: Placing it on top of the entire view instance then make it seem like the entire view is disabled.
yes, the title could have more help to it stand out more. an icon is helpfull, but maybe more basic have it wrapped with a This dispaly is disabledMARK tag.

Thanks for sharing the comment from Slack @smustgrave.

@rkoller: I tried to add the warning visually-hidden as well, was it something like that you meant?

@SKAUGHT: Thank you for sharing the report from 2020. And yes, disabled displays now have an alert text "This display is disabled.", which is great. But the aim of this issue is to show a message when the entire view is disabled, not just a display.

I do see this now thanks.
-> user has to come from come from /admin/structure/views as this is the only place to disable an entire view.
-> Views UX: no place on 'edit' form for user to disable enter View, or more importantly now: re-enable!
this is where the individual display status shows.

it's a large oversight to not have control of the status in Views itself..this is why you're filling in the gab with notice text and bg coloring and leaving it to the main list page to enable/disable.

Yes, being able to enable and disable a view directly on the view edit page is missing, so I created follow up issue ✨ Enable/Disable View within View Edit page Needs review to solve that. I have now added it in the Issue Summary, which I forgot. Sorry about that.

In my opinion, making the disabled view status obvious is priority number 1, and probably easiest, and disabling/enabling in the edit form can be handled separately.

What do you think of the visually-hidden span text I added yesterday, as recommended by @rkoller?

- css colours could/should be css var, not direct colours.
- new text line ->has no space between words. This new H1 title is not a sentence/statement. needs work!

Yes @SKAUGHT, it would be nice with a disable/enable option on the edit page.

I removed the visually-hidden text, and updated the MR with your suggestions. I previously had a problem using h2, but now it seems to work ... Maybe P tag is too small, and h2 better?

accessibility/readability: as long as the font is above 12px that is 'good' (golden rule) -- of course, you can adjust that in the css (add a class) if you feel it still needs something.
use h2: no... we are giving information, not a title..

how about this!

    $form['displays'] = [
      '#prefix' => '<h1 class="unit-title clearfix">' . $this->t('Displays') . '</h1>',
      '#type' => 'container',
      '#attributes' => [
        'class' => [
          'views-displays',
        ],
      ],
    ];

    if ($view_status == 'disabled') {
      $views_overview_url = Url::fromRoute('entity.view.collection', [], ['absolute' => TRUE]);
      $views_overview = Link::fromTextAndUrl($this->t('Views Overview'), $views_overview_url)->toString();
      $form['displays']['view-disabled'] = [
        '#type' => 'container',
        '#attributes' => ['class' => ['view-changed', 'messages', 'messages--warning']],
        '#children' => $this->t('This view is disabled.  It can be re-enabled on the @link Page', ['@link'=>$views_overview]),
      ];
    }

thanks for all the work on this!

re #25 ✨ Make disabled status more obvious in a View Needs review in regards of the visually hidden text. no my suggestion was not about appending the same text snippet visually hidden right after the "this view disabled" note. that is redundant and the initial problem that a screenreader user might miss that note isnt fixed that way. and in case the person notices the note it is announced twice that way.
no my initial suggestion was to add the note that the view is disabled to the page title tag in the head. but i completely forgot that text wrapped inside a title tag has to be plain text therefore a visually hidden span aka html mark up is no option there. but on second thought probably a visually hidden span isnt necessary at all, instead you could simply append that information for example with something like Glossary (Content) disabled view | Drupal 11. That way the most important detail "Glossary (Content)" is front loaded then comes the information that this view is disabled and then the site name. So the order goes from the most important and most specific to the most general. So if there are too many tabs open for sighted users the most important information is shown all the time before concatentation sets in, while screen reader users get the whole context of the page aka they know that the page is about the glossary (content) view and that this view is disabled.

and i've added this issue to the shortlist for the ux meeting on friday: 📌 Drupal Usability Meeting 2024-02-23 Active . in case if anyone has time to join, the meeting starts at 14:00 UTC and the link to the meeting is posted in the #ux channel on the drupal slack 10 minutes before the meeting starts.

Thanks @SKAUGHT, much better with a link to the View list! I have updated the MR with that. And it sounds great @rkoller, thanks for giving this some attention in the UX meeting!

Appending "disabled" to the title is a great suggestion, and makes sense.

The Needs Review Queue Bot → tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Cheers.
I see bot message. I see we have an odd line on top. i'm going to look into combinine the 3 types of messages in a better way. i'll have an update shortly.

changed and locked have some interesting behaviour. we need to avoid those 2 items.
moved into display, work with direct display status (disabled) and ghosting with our bg color changes.

The Needs Review Queue Bot → tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

general points from UX review meeting this morning (thanks all!):
- add "enable view" to the drop button
- follow-up: use the same message to announce when a display is enabled, instead of the existing "ghosting"
- position of the message
- add disabled info to tag
- Add an enable link instead of a link to the overview page
- use the same pink as unpublished node
- info or warning?

Usability review

We discussed this issue at 📌 Drupal Usability Meeting 2024-02-23 Active . That issue will have a link to a recording of the meeting.

For the record, the attendees at the usability meeting were @AaronMcHale, @benjifisher, @ckrina, @rkoller, @simohell, @skaught, and @worldlinemine.

If you want more feedback from the usability team, a good way to reach out is in the #ux channel in Slack.

At first thanks again for all the work that went into this issue so far! In the following a summary of the points that were noted during the discussion:

1. There was a clear consensus to recommend adding an "Enable view" option to the view display extra actions drop button of a disabled view. Adding that option could either be moved to a follow-up issue or that change could already be done within this issue, that is up to the people working on the issue in here.
2. The technical constraints with the admin notice aside, @skaught explained that the You have unsaved changes admin message is in place all the time and unhidden on demand when there are unsaved changes, there was a clear consensus to move the admin message from it's current position within the field set up to the position where the unsaved changes admin message is placed. Even though it is not possible to combine the unsaved changes with the this view is disabled admin message it is an acceptable downside since the this view is disabled message is about all displays, placed within a display like it currently is, it might seem only the display is disabled while the label says the view is disabled. Hierarchically having the admin message placed on top is the cleaner, clearer and more unambiguous approach.
3. At the moment the admin message This view is disabled. It can be re-enabled on the Views Overview Page is labeled as a warning (yellow), but the consensus was to change it to an info (green). The view is still editable (in contrast to disabled displays) and no potential dataloss is possible. Therefore going with the info type as a "fyi" is more appropriate and was agreed on.
4. Talking of disabled displays, it was agreed to use the same admin message pattern to announce when a display is being disabled - the admin message should be shown in the position that currently states This display is disabled, plus remove the current "ghosting" for the disabled display which adds an opacity of .5 greying out the three columns. That step is clearly out of the scope for this issue and should be tackled in a follow up issue.
5. Instead of adding a link to the Views Overview page it was agreed on replacing it with a link that enables the View instead. That step is probably only relevant as long as "Enable view" option hasn't been added to the drop button.
6. For the sake of consistency there was a strong agreement instead of using a greyish background for a disabled View page to go with the same color of pink that is used for unpublished nodes.
7. In regards of adding an info that the Views page is disabled to the tag in there was no clear consensus. I will elaborate in a separate comment since i was the only person who strongly advocated on the issue already as well as in the discussion on the UX meeting.

about #45 ✨ Make disabled status more obvious in a View Needs review .7
I've quickly created two screen recordings to illustrate the point. The announcement is by VoiceOver in macOS Sonoma, with Safari as the browser.

page_title_without_info.mp4 starts with announcing the summary about the page containing the page title, number of links, buttons, headings, form controls, tables and landmarks (control-option-shift-i), i then tab through the page until i reach the admin message, i then activate the rotor (control-option-u) and then gothrough the available sections.
the problem is while tabbing i only notice the already visited Views Overview link, there is no indication about the full admin message and within the rotor it is the same there is no direct indication about the admin message there is only the link to the Views Overview page. In one of the previous iterations for this issue an h-tag was used instead of an admin message, that way the title of the h-tag was shown in the rotor and directly actionable. but in the context of admin messages there are no h-tags so that is not an option.

in page_title_without_info.mp4 i've simply added "disabled view" to the title tag in head. that way the overview provides an indication that the view this page is about is currently disabled.

If you take a look at WCAG 2.2. SC2.4.2 (https://www.w3.org/WAI/WCAG22/Understanding/page-titled.html) :

The intent of this Success Criterion is to help users find content and orient themselves within it by ensuring that each Web page has a descriptive title. Titles identify the current location without requiring users to read or interpret page content.

and the corresponding technique G88 (https://www.w3.org/WAI/WCAG22/Techniques/general/G88.html):

Descriptive titles help users find content, orient themselves within it, and navigate through it. A descriptive title allows a user to easily identify what Web page they are using and to tell when the Web page has changed. The title can be used to identify the Web page without requiring users to read or interpret page content.

In the example illustrated in page_title_without_info.mp4 the user is required to read and interpret the page content to figure out that the view the page is about is currently disabled. by providing that detail about "disabled view" the user has all the necessary information at hand: the reassurance that this page is a view, the name of the view, that the view is disabled and the overall context aka the site title is provided as well.

Therefore i would still vote for adding that information to the title tag.

since this morn now, I have found some path toward ✨ Enable/Disable View within View Edit page Needs review to add the links for Enabling (and Disabling) a view from the first level (displays) Dropbutton operations.

easy to change the message to 'messages--status' (green). to note the HTML Link does remain the same 'yellow' link color in the admin theme (Claro)

have watched the page_title_without_info.mp4 video. Indeed i think the the "Views Overview" link is too much.

@ressa @kruser (and all):
IMO: i'm in favour of just keeping this ticket toward adding the background (unpublished pink) and having the TITLE/H1 dynamically add in '(disabled)' with this ticket, and move into 3422333.

SKAUGHT → closed merge request !6773

Sorry for the PR confusion. i'm switching to gitlab from old-school patch workflow. getting used to targeting. cheers.

@ressa @kruser (and all):
after preparing the work for ✨ Enable/Disable View within View Edit page Needs review it became clear that the h1/title display helped in that ticket more directly.

For this tickets scope, Views UI already does give a class for both enabled/disabled -- before we did any work here. However, neither views_ui.admin.css does not even use the classes. we can simply add the bg color (and ensure claro theme has it's own touchup.
it's tested with other frontend themes and a class in views_ui.admin.css works well. Claro has something around it's variable use that's different.

SKAUGHT → changed the visibility of the branch 3422333-enabledisable-view-within to hidden.

changing to bug. Views ui does have a enabled/disabled class wrapped around it's form. Seems like it never got used by the module form itself, nor did stark/stark9 base have any use even though they uplift/alter core libraries..

the proposal to add the entire line, as noted by review is more noise to the with adding the link (generally then, the addtion of our header notice is 'too much')..
at this time ✨ Enable/Disable View within View Edit page Needs review will be adding in changes to the h1/TITLE to add 'disabled'.

SKAUGHT → changed the visibility of the branch 3184588-views-ui-status-visual-notificaiton to hidden.

am going to leave column background white when disabled. column border is faint as is and lots of item stripping and the disable display are already alot on page.

Thank for all the organizing and juggling of branches and issues! i've applied MR6816 successfully on a install of drupal 11.x-dev with the standard profile. One question and one concern:

Since you've moved some of the functionality in between issues. Is the "only" thing that this issue changes right now is adding the pink background to a view that is disabled, and the rest of the things we've discussed moved over to ✨ Enable/Disable View within View Edit page Needs review ? the info admin message that this view is disabled shouldn't be shown anymore? cuz i "think" if i remember correctly that admin message wasn't part of ✨ Enable/Disable View within View Edit page Needs review ?

aside that, in #55 ✨ Make disabled status more obvious in a View Needs review you've illustrated the ghosting when a display is disabled. the disabling of the view is clean, you are adding pink as the background color and the user is still able to alter and interact with the disabled view. that is perfect.
that is the same for the disabled displays. the user is still able to make changes and interact with the ui of the display. problem is that the disabled state there is achieved by adding an opacity of 0.5. that is completely breaking the color contrast requirement for WCAG SC 1.4.3 (it was broken before already). i think the cleaner approach would be instead of applying an opacity for disabled displays also change the white boxes to pink as a short term fix. but that is probably out of the scope for this issue.

but in the long run we should discuss how disabled interface components should be handled. Until i got reminded to disabled views, displays and so on i was an advocate for a two step approach: https://drupal.slack.com/archives/C2ANFUGGG/p1704455215012089?thread_ts=... but maybe a third step should be added. Am in the course of writing up an issue about that as a starting point of a discussion (hope to finish it on one of the next days).

I have checkout to the branch and applied the changes on my local and reviewed the changes and the changes looks good. Leaving the column background color as white is a good option according to me. Attaching the screenshots of the disabled view.
RTBC +1

#58
q:the info admin message that this view is disabled shouldn't be shown anymore? cuz i "think" if i remember correctly that admin message wasn't part
a: on 3422333 have added second bullet point "adds 'disabled' to suffix of View Title. h1.page-title and html Title tag shows status text if disabled.."

..in working with the ajax side of the edit form, it was easier for me to very the title change while adding in the link on that ticket. As this ticket first originally didn't have any message in the request.
also: i think 3422333 will probably 'get in first' as this color and ghosting UI -- i suspect may delay this ticket. (:

#59.
thank you! i'll move status and we'll see how the next steps go!

nod_ → closed merge request !6816

Not ideal as noted in #58 but it's incremental progress until the bigger issue lands.

Committed 87b34b9 and pushed to 11.x. Thanks!

Great work @SKAUGHT and @rkoller completing this task, thanks!

Automatically closed - issue fixed for 2 weeks with no activity.