Is it only me having trouble with setting the properties of displays? Doesn't seem so: #1188124: Any change to a display (block, feed, etc) overrides master

I try to explain, what happens very often and really upsets me:

When dealing with views with several displays, it is a common task to select one of them - lets say a page - and modify its properties. So, when I selected a page (and I'm that way in the logical context of the page), I click a property and modify it. I click save and just in that moment I realize, although I was in the settings for that specific display, I accidently modified the master value.

This is, because the property settings page defaults to "for all displays" and not "for this page (override)", regardless of what view the user switched to before.

One might say: well, just select "for this page (override)" if you want that. But when setting up a new view, I currently have to select "for this page (override)" a hundret times or so. And that's unnecessary.

My feature request is:
- enable the "master" display by default and perhaps name it "default" in the UI
- have "override" be the default selection for all other displays

This would come far closer to what the user expects and IMHO even optimize the learning curve of Views.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Anonymous’s picture

Issue summary: View changes

fixed nomenclature for better understanding

testtest23112’s picture

I also want this feature so much! Is there anything that can be done right now to "override" by default?

dawehner’s picture

I think you could write some custom module, that changes the behavior of views, though i see both no need and no chance to chance this for views, i think many people would get very confused and too be honest people setup the master display and change things for the sub-displays.

Anonymous’s picture

i think many people would get very confused and too be honest people setup the master display and change things for the sub-displays.

So what's the difference? This happens to maybe a thousand people each day right now, accidently. That's what my request is about.

A UI not picking up a user where he is, is frankly broken. In this very case, users select a display for editing. And what they get are lots of settings affecting all displays by default, requiring him to select the same display again and again.

Please don't think I just want to nag. The Views 3 UI is the mighties interface on the web I can imagine! But this is such a big flaw in usability. Or perhaps I just don't know the good reasons for it.

dawehner’s picture

So what's the difference? This happens to maybe a thousand people each day right now, accidently. That's what my request is about.

Well you know people get used to that, changing anything now will confuse SOOOO many people. I know there would be at least 10 issues per week just about this topic, and you know people which want this feature will not help in the issue queue.
There are probably already books about the new ui etc, sorry but that's from my perspective not something that can or should be changed.

Please try out the views interface in drupal6. The concept existed there as well, the UX is definitive better now.

Hehe funny enough the views ui actually got some good UX tests from google.

Anonymous’s picture

Title: override properties by default, instead of setting the master property » add option to "Override properties of current display by default"

I forgot how hard it is to get rid of bad habit... and thus my original request perhaps went too far. How about giving everybody the option to decide for himself:

We already have an option to "Always show the master display". No need to change this!

Why not add an option to "Override properties of current display by default" right below the master display option?

This way we wouldn't confuse old users and allow customization on demand.

Anonymous’s picture

Yet another victim, watch the video and move to timecode 09:10
http://www.youtube.com/watch?v=AxeskzN8BAc

Pete is very smart, but he had no chance agains the bad Views 3 display override behavior.

What would I have to do to get heard by responsible developers? Perhaps requires something like a collective online petition... ;)

Anonymous’s picture

Issue tags: +GoogleUX2012

Hehe funny enough the views ui actually got some good UX tests from google.

Please don't just answer to distinguish yourself. Actually Google found out: Users are confused about the meaning of "All displays" and "This page (override).". Details about the tests can be found here.

They also provide videos of how the testers worked. They look at each field and try to understand it. The test however doesn't tell us how site builders use the interface. When setting up a hundret displays, no body attemps to understand a single field. One just overlooks the field, because the display was already selected and it is unusual to repeat the selection for each property.

Anonymous’s picture

Issue summary: View changes

added another issue as reference

er.pushpinderrana’s picture

Assigned: Unassigned » er.pushpinderrana
Issue summary: View changes
Status: Active » Patch (to be ported)

I am working on this issue and soon will port patch for this.

er.pushpinderrana’s picture

Status: Patch (to be ported) » Needs review
FileSize
2.47 KB

I have attached the patch that will enable following feature with this module.

Feature:
Set "override" be the default selection for all other displays.

er.pushpinderrana’s picture

Assigned: er.pushpinderrana » Unassigned

Status: Needs review » Needs work

The last submitted patch, 9: views-override-current-display-9-1453020.patch, failed testing.

er.pushpinderrana’s picture

Status: Needs work » Needs review
FileSize
3.65 KB

I need some suggestion from views Maintainers here. It would be so useful for me if they help me to sort out this issue. I have tested this patch for all possible scenario manually and then run test cases against this. One test case fail after applying this patch because this new feature is completely opposite to that test case i.e testWizardMixedDefaultOverriddenDisplays().

Let me explain you what exactly I got understood from this test case. This test case ensure that page and feed have identical title and block having a different title. But we are creating this feature request where 'override' be the default option that will conflict with this test case. So in this patch I also make some changes in this test case and still working on that to ensure this patch should work fine for every scenario. Can someone look into these changes manually once to correct me if I am wrong.

I am attaching this patch again including changes in test case.

RaulMuroc’s picture

Status: Needs review » Reviewed & tested by the community

It works cool with latest -dev version (7.x-3.x-dev) as well as with latest stable version (7.x-3.7).

More positive opinions for this patch: Views Module: having trouble with settings the properties of displays?

This is really nice (and even necessary to avoid mistakes) to integrate in Views core.

Thank you @er.pushpinderrana.

er.pushpinderrana’s picture

Thankyou Raul for your valuable feedback.

colan’s picture

We've recently switched our testing from the old qa.drupal.org to DrupalCI. Because of a bug in the new system, #2623840: Views (D7) patches not being tested, older patches must be re-uploaded. On re-uploading the patch, please set the status to "Needs Review" so that the test bot will add it to its queue.

If all tests pass, change the Status back to "Reviewed & tested by the community". We'll most likely commit the patch immediately without having to go through another round of peer review.

We apologize for the trouble, and appreciate your patience.

colan’s picture

Status: Reviewed & tested by the community » Needs work
joelpittet’s picture

Status: Needs work » Reviewed & tested by the community
FileSize
3.65 KB

Reuploading previously RTBC'd #12

er.pushpinderrana’s picture

Thanks @joelpittet!

colan’s picture

Status: Reviewed & tested by the community » Needs work

Looks good, but some minor issues:

+++ b/views.module
@@ -2529,3 +2529,38 @@ if (!function_exists('user_views_api')) {
+ * Implements hook_form_alter

Missing parentheses and punctuation.

+++ b/views.module
@@ -2529,3 +2529,38 @@ if (!function_exists('user_views_api')) {
+      // Set option selected to "Override properties of current display by default"

Missing punctuation.

+++ b/views.module
@@ -2529,3 +2529,38 @@ if (!function_exists('user_views_api')) {
+

Let's remove this blank line.

er.pushpinderrana’s picture

Status: Needs work » Needs review
FileSize
3.69 KB
1.31 KB

Thanks @colan.

I have incorporated all your suggestions except the last one - regarding removal of blank line.

I think this blank line is needed before starting new function i.e. views_form_alter(). Please take a look to attached patch with interdiff.

AjitS’s picture

Status: Needs review » Reviewed & tested by the community

@er.pushpinderrana I think you have attached the reverse interdiff. The looks right to me, and issues from #19 seems to be resolved. Setting this back to RTBC.

dagmar’s picture

Status: Reviewed & tested by the community » Needs work
+++ b/includes/admin.inc
@@ -2592,7 +2592,12 @@ function views_ui_standard_override_values($form, $form_state) {
+    if(isset($form['override']['override_flag']))  {

This doesn't follow the drupal coding standards.