In the Views UI, the interaction pattern of “All displays”/ “Override this display” is confusing

As a fairly experienced site builder, I would very much be in favour of simply changing the default from All Displays to Override. I tend to use a lot of displays within one View, and I'm constantly forgetting to change the setting. As you say, the builder is focused on the task at hand, not on the default/override option.

Maybe this is from my experience with Views 2, still thinking of it in more of a Master/Slave type of paradigm. But I do think that when we're customizing blocks, attachments, etc. we're wanting to affect only that Display far more than we want to affect all of them. Maybe that's just me, but that would be my vote.

I agree with michaelschutz, and I never used Views 2, but got started with Views 3.

I am continually making the mistake of changing all my displays in a View when I only intend to change one display. I always thought it would be helpful to have the master View visible all the time (visually distinct from the other views in some way) and have changes made to any individual display only apply to that display (i.e. make Override be the default setting).

Then if you wanted to make a change that applied to all displays, you could do it on the master view. To me, it feels weird that editing any single display could have an effect on any other display.

I agree, that the default should be Override and not all displays.

Also when you try and rearrange fields for example, and remove them, only only then change override (this display) and click apply/save sometimes they tend to affect all displays.

It should be very clear what aspects of the display are inherited from the master and what aspects are overridden.

Idan

valsgalore, that "Master" paradigm was more of the Views 2 concept. I like the move away from that in Views 3, since it becomes more flexible. But I think the default behaviour is still echoing that Views 2 concept - the default being what it is, the assumption is being made that you want to affect all displays (or, in other words, make a Master-level change), every time you open the dialog box.

At its core, I think this could be a simple change: set the default to "Override". But I recognize that not everyone thinks like me (which is the very reason this issue exists; for some use cases, the All Displays setting may be a better default). So maybe the ideal solution is to have the ability to set the as a configuration option. (Though, I know that might add an undesirable layer of complexity in setup & config.)

Can I ask, conceptually, how people approach setting up their Views? I tend to think in terms of content categories: I want to have a page with a list of nodes of a certain content type, with blocks of other nodes connected, maybe by type or by taxonomy, and then maybe some different displays for different fields within that content type (image gallery or what-have-you). With the ability to clone displays, that becomes quick to customize things (except for remembering to change the "All Displays/Override" box :) ). But you can also clone whole Views, so it can certainly be done that way too.

Maybe that question is more tangential to the issue, but it may be relevant in that how one works in Views depends on how one thinks conceptually. There might be more in the study results too - I'll have to go back and give it another read through at some point.

This issue is based on the findings of the Views usability test, so we may assume that the current states does not map to users expectations. This: "Users are focussed on the task at hand" is basically why this is a confusing default right now.

I actually remember discussing this with merlinofchaos when designing Views 2 UI and at that time I think I was argueing for defaulting to override as well, but the choice was made to opt for manipulating the master by default. Long time ago :)

I think we should just make this change and see how it performs in a next usability test.

Who's up for a patch?

valsgalore, that "Master" paradigm was more of the Views 2 concept. I like the move away from that in Views 3, since it becomes more flexible. But I think the default behaviour is still echoing that Views 2 concept - the default being what it is, the assumption is being made that you want to affect all displays (or, in other words, make a Master-level change), every time you open the dialog box.

Well technically nothing changed beside the UI.

At its core, I think this could be a simple change: set the default to "Override". But I recognize that not everyone thinks like me (which is the very reason this issue exists; for some use cases, the All Displays setting may be a better default). So maybe the ideal solution is to have the ability to set the as a configuration option. (Though, I know that might add an undesirable layer of complexity in setup & config.)

Some changes in d8 makes it way more easy to actually allow this to be configurable. In general we should hide this behavior
for really simple views.

Can I ask, conceptually, how people approach setting up their Views? I tend to think in terms of content categories: I want to have a page with a list of nodes of a certain content type, with blocks of other nodes connected, maybe by type or by taxonomy, and then maybe some different displays for different fields within that content type (image gallery or what-have-you). With the ability to clone displays, that becomes quick to customize things (except for remembering to change the "All Displays/Override" box :) ). But you can also clone whole Views, so it can certainly be done that way too.

I fear that there is no single way to do it. Some people misuse a view and put just several total unrelated displays into it to group
it by "sections/features" on the site. There are people which try to save configuration by abstract things into the master display, but
the views itself aren't really similar, and there are normal users creating simple page/block combinations.

Correct, there's is no one true way. What the test has shown is that the current default throws people off and thus makes the wrong trade-off between flexibility and getting the task at hand done.

I'm somewhat tempted to bump this to major; this is my #1 all time pain point with Views. The functionality is useful, but the UX for it is very trying.

Additional information added

In #1832872-4: Fix broken Views UI search box/filtering, @yoroy suggests changing the select/button combo to a dropbutton. I think that makes a lot of sense, and then we can bikeshed over which one makes the most sense as a default operation :)

I don't have enough energy to work on that more right now, but if someone does, the relevant bits of code are in

ViewUI::getOverrideValues()
views_ui_standard_display_dropdown()
Drupal.behaviors.viewsUiOverrideSelect.attach()

Like this:

No need to bikeshed too much, the default should be to apply only to the current display :) The test results have shown that clearly enough.

We should decouple the change of the default value from the change to a dropbutton.

Reasons:

• Changing the default is way more difficult then people expect it to be (as the full system relies on defaults)
• It's not clear whether the default is actually the way to go, see comment #1412008-1: Set default editing option to "This [View_type] (override)"
  That's a really good point for me, most of the time you start with one display and then you will get confused if you have to start
  again when you add another one.

Some questions which are not covered by the current design:

• What happens with the progress indicator (to see that add two fields at the same time) (1 of 2 for example)
• What happens with the submit text when you add multiple fields (Apply vs. Apply and continue)

I am going to have a stab at this. But from my initial phase of research this usage of 'default' and 'defaults' are confusing me. I was able to change the default to overridden state but on clicking save the previous behaviour would prevail.

I will shortly post something more so that some of you can guide me in the right direction.

Here is my current progress on converting the select element to a button, but NOT to change the default.

ok so are we going to do this now or not(changing default)?

I have made following progresses.

in admin.inc of views_ui module line 440 onwards:

$form['selected_display'] = $display_id;
$display_dropdown[$display_id] = t('This @display_type (override)', array('@display_type' => $current_display->getPluginId()));
$display_dropdown['all'] = ($section_overrides ? t('All displays (except overridden)') : t('All displays'));

if ($current_display->isDefaulted($section)) {
    $form['override']['dropdown']['#default_value'] = 'defaults';
  }
  else {
    $form['override']['dropdown']['#default_value'] = 'all';
  }

in ViewsUI.php line 327:

$was_defaulted = ($form['override']['dropdown']['#default_value'] === 'defaults');
$is_defaulted = ($form_state['values']['override']['dropdown'] === $form['selected_display']);

Now the is_default,was_default, reverted logic works fine.
I need some idea regarding where in the code the actual swapping of values takes place.

@dawehner

I will look into the patch and work on it accordingly. But it would be great to know if we have reached any consensus regarding default overriding option issue.

But it would be great to know if we have reached any consensus regarding default overriding option issue.

As i said before, i don't see whether there is consensus yet regarding the default and hey the complexity of the changes is really a deep change in views, see DisplayPluginBase::defineOptions() and unpackOptions, or in short words, you don't want to look at that :)

The places in that these values are applied can be found via getOverrideValues()
which then calls $display->optionsOverride();

Hi,

I actually don't see how these two issues are relevant:

1. the progress indicator is at the top of the dialog, and doesn't change according to the choice of applying to all or current display.
2. same for the apply vs apply and continue, this is earlier, when you add the fields.

I do think we also need the same logic behind the apply to the remove button.

Idan

I will work on getting just the different UI in, but not the default.

dawehner: The dropbutton, however, is cool. My recommendation for the default would be this: If there is only one display, then the default should be 'all displays'. If there is more than one display, either 1) default to 'this display in all cases' or 2) more complex and would require some user testing, but default to 'this display' for all displays except the 'first' non-master display, which defaults to 'all displays'.

Might it be possible to add an option to the Views Settings page that lets the user choose the default? I understand the arguments both for and against using "Apply (all displays)" as the default, but some users (like myself) almost never want the All Displays version.

I think that we need to consider that "apply to all" could have very negative results if you add a filter or remove fields from a bunch of displays by mistake, where the only downside of apply to current display only would to redo the work, and have to add the fields to multiple displays, in that case it if you figure out you wanted the change to be applied to all displays you'd simply go back, redo the change and this time you'd remember to change the setting to "apply to all".

Idan

Just posting some progress, but be warned: There are known issues everywhere.

So I realized that the dropbutton is not working, because it's missing some ID's, will do reasearch this evening. Let's just run the testbot to see where this buttons are used. From the visual perspective it's looking great already and it works good, once you remove the '#dropbutton' property.

Note that #20 is quoting me, and I feel pretty strongly that we have to preserve the existing behavior when you have only one non-master display; otherwise you're going to really really mess up the usability for some people. When you have 2 or more non-master displays, I agree that it would be nice if you could always edit only the current display.

I would note: I feel that many people having this problem might be over-using displays. If you have a lot of displays on a single view that are very different from each other, you may not be using Views efficiently. Remember that when you have a view with multiple displays, when you load that view all of the displays have to be instantiated. Even though they aren't run, they cost you memory. So please consider your usage of this feature; if the displays are very different from each other, then you should have multiple views instead.

We probably need some fixes of the dropbutton code, to allow normal buttons to work fine without hacks (like prefix with ul-li).

Setting to needs review to see all fails.

I hope I'm not coming in too late for this, but here it is:

If we actually care about the "All displays"/"This display" splitbuttons behaving "smartly" for (almost) everyone, then we could have them remember the last used state. This way, we choose one default to start with, but -given enough time- the button will "learn" what each user usually uses (pun). We can even go a step further and make this a per-view or per-display counter. This could also apply to the "Save and publish"/"Save unpublished"/[add other contrib workflow states here] splitbutton with per-user, per-node-type, per-node granularity.

I myself do not really care that much about the splitbuttons behaving (almost) out-of-the-box how I'd use them most of the times. Perhaps because I don't belong to either category of users accustomed to either mostly requiring to edit all displays or only the one being edited. I don't even belong to the category of users that are accustomed to the "All displays" because it is the default they are used to from Views. That's because I belong to a third category of people that always checks every single setting and control in a form before hitting "Save" instead of "speed-clicking" around forms.

Now, because I am such a "freak", what I'd like to see instead would be the addition of a "Select displays..." that would pop-up a modal with a series of checkboxes and a "Apply to selected"/"Cancel" set of buttons.

On another subject, the "All displays" does hide a potential danger to "destroy stuff". I personally am struck by the UX paradox that although I find it weird to act on things I don't see by using the the "All displays", still I'm used to it as a de-facto of how things work.

So perhaps a confirmation modal dialog (with a "don't show this again" checkbox to allow "annoyed" people to opt-out of future warnings) would be The Best™ solution. This of course if we choose to go with the "All displays" as the default option for the splitbutton (and no "smart" behavior).

If we choose to "hide" the "All displays" as the/a secondary option on the splitbutton and the user still choses that option (intentionally or by mistake), well tough luck I guess because they already had two clicks to avoid this (one first click on the down arrow and a second on the actual "All displays" choice).

@klonos I dont really follow all your suggestions, could you visualize them?

This more or less brings back to behavior of views 6.x with a nice button.
It would be great if you could play around with it and see whether it works as you expect it to work.

Maybe also with a patch.

I LOVE where this is headed. Couple notes:

Also, the submit behavior of the button seems to be bugged in a few ways. I'm going to investigate more once I'm sure HEAD isn't broken.

Missing tag. :)

And why "Apply to all" and not "Apply to all displays" instead (for consistency with "Apply to this display")?

Thanks for the screenshot!

Yeah I left the dropbutton in for testing, so just removing that for now.

#37: drupal-1836392-37.patch queued for re-testing.

My preference, for what it's worth, is to not make any more primary buttons on forms into drop buttons. Personally, I find the node form behavior to be extremely confusing. This change actually makes much more sense than the node form, because putting the drop button directly on the primary action practically requires that the user repeatedly investigate what that option does. I strongly prefer a dedicated form element (with a label) that describes what's being changed. When used as the primary action on a form, end-users have no idea what's inside of those buttons unless they click on them to investigate.

@quicksketch I don't understand the "repeatedly" investigate - its not like the options exposed are variable. Its always the same. It is correct the first time they would need to figure out, that does not mean each time they use it, they need to figure it out. Personally you might find it confusing, but I am not sure if that translates to all users. I wouldn't discourage people from using a newly introduced pattern, if you disagree with the pattern you should open an issue about and we should discuss it.

I realize that the drop-button on the node form was based on a round of usability testing, but was the drop-button solution in this situation ever tested for comparison? With some background on how that happened in the first place that provided justification, I wouldn't mind seeing this pattern further applied. Thus far my perception is that we created drop-buttons on the node form's primary button without testing at all. We know drop buttons are good in general (i.e. in operations columns and in several locations throughout the Views UI), but the application to the primary button seems to have been a case of "A" solution is good, we have "B" problem, therefor apply solution "A" to problem "B", without considering that the original solution was not meant for this particular problem.

@quicksketch You are right, we did not test it for this situation (or a-like) - this is mainly because its quite a new pattern. We do not generally validate on such a detail level, instead we tend to test broad new features or changes - often touching on small interactions along the way. Although spark studies, touched on this interaction after its introduction - I haven't seen any results on this specifically. I have asked dharmesh to provide more data if he has them.

I am not sure what you are asking for though, comparative data on this proposed design vs. something else? I dont see how we could have done that, nor how we can - this is a small change, that shouldn't be subject to such research rigour considering our available resources. This is a different context, that is right - but could you elaborate on what you think is actually wrong with it?

From my point of view, users are always applying settings against "one or all". This becomes extremely relevant near submission, as people tend to jump to the first relevant options ignoring all other forms/text, putting it where it is now has been rather troublesome and confusing (does it effect the settings below? not really). Given that its one of those settings that is easily ignored, and is really relevant upon submitting. Placing it near that, visually distinct from the actual options - makes a lot of sense from my point of view. And in this case we happen to have a UI pattern for grouping "radio option" a like settings near the submit button.

Is it the best pattern - we dont really know, but it is a pattern and its not variable, so its unlikely people will have to relearn each time. It is very likely a pattern people will have been exposed to before, and it simplifies the form because there is one less "override this or that" select list. I understand the context is different, but I still feel like its an appropriate pattern. If this is not the right pattern, what else do you propose?

Why don't we just make it simple and still much less confusing than it is now.
Here is a screenshot how simple I mean.

I'd prefer to use the dropbutton submit pattern like on the node form. We have a pattern; let's be consistent with it.

#37: drupal-1836392-37.patch queued for re-testing.

That's a pretty nitpicky reject file:

--- core/modules/views_ui/lib/Drupal/views_ui/ViewUI.php
+++ core/modules/views_ui/lib/Drupal/views_ui/ViewUI.php
@@ -1151,4 +1168,5 @@
   public function onChange($property_name) {
     $this->storage->onChange($property_name);
   }
+
 }

We need to figure how much space we need in order to let the button not look totally silly:

#50: vdc-1836392-50.patch queued for re-testing.

Shouldn't the button go outside the overlay? E.g. be on top?

This does look awesome though :), lets remove the For: All displays.

Rerolled which was broken since the new dialog api. Note: this just works outside of the dialog, so in the nojs variant.

I have no clue why the dialog itself looks just broken.

Lots of fancy stuff happening with views UI modals.

It doesn't work with modal since we're creating jquery UI dialog buttons on the fly based on the form's own buttons. I'm afraid it'll take some pretty involved JS to fix this.

Made issue link a fancy issue link.

Could you provide an idae for this?

Can I get a reroll please? doesn't work properly when I try it :p

OT: maybe the string should be better: Apply to this display only ... @derhasi gave a feedback that it is potentially more complex
to read.

Looks like crap but meh.

Looks like crap but meh.

The code changes looks nice from my perspective, no idea what you mean.

As far as the defaulting, yet another Views UI setting so advanced users can customize the UI seems like a good fallback, but not ideal.

I've always wondered why the override mechanism is pull-based anyway. It seems to me that the moment a Views builder cares about the globalness of a handler is when looking at that handler, not when looking at the things that override it.

I haven't followed this thought to a UI design of any kind, but what of options such as "make this global" as a one-time copy, or "share this setting" in the sense of a master display.

Interesting, you can't retest a which which was never on "needs review"

Let's expect a lot of failures.

Last patch (#1836392-71: In the Views UI, the interaction pattern of “All displays”/ “Override this display” is confusing ) still applies, removing the needs reroll tag to avoid future confussions

Sorry to resurrect a zombie issue but this seems to be a bit more of a bug now rather than just being confusing/annoying.

A common scenario:
* You create a view with many displays, each added at various times and of varying types.
* Much later you need to add a new filter to all displays.

Unless you have never changed one display to be different (eg, never chosen 'This Display' when setting up each display), the addition of the filter with the option 'All Displays' will cause some displays to have *other* filters to be removed or altered rather than just adding the one filter.

This can be replicated in other ways, but this is my most common cause of 'views rage'. This I believe was introduced in D8? I honestly don't remember views behaving like this in D7.

#2857590: Users did not expect applying changes to all displays would remove the overridden settings was filed today and reminded me of this issue. I've lost work plenty of times because of the display override feature, which is generally considered a major bug. I've left both issues open for now since (as @dkre points out) this one is kind of a zombie, but #2857590: Users did not expect applying changes to all displays would remove the overridden settings is the recently filed one.

BTW @dkre, the behavior was not introduced in D8; I managed to screw up plenty of Views with it in the past myself. :P

Alright, lets atleast follow the direction set here.

My colleague just lost a bunch of work to this bug and suggested that we make a feature request to have it changed. I assured him that this was a known issue and not likely to change anytime soon. I hope I'm wrong. I seldom make this mistake anymore, but I lost plenty of work in the past before I got to this point.

I am teaching Drupal in a university. All of my students lost some work by this feature – and it frustrated them really heavy. In my opinion it is a major pain point, which leaves a bad second impression of Drupal.

And I am using Views for years – and I ruine my work on regular bases with it.

So can we please fix this?
I need some help in resurecting the patch.

OMG this shit is so frustrating, I still cannot believe all those kind of stuff I discover on Drupal.
No wonder this is a dying CMS,
this really lacks some UX designer

It is one of the WTFs of Drupal, yes.

I am also surprised seeing this still unresolved after so many years.
The issue is that we got used to this while newcomers find it really confusing and (according to the comments above) are losing a lot of work/time with it.
Instead of criticising we need push this forward together.
It's a free and open-source project after all.