Move Relationships above Contextual Filters in Views Advanced Settings

Hi,

Thank you for this patch.
This is OK for me. Code is simple and works as expected.

I tested it on a fresh install in "content" core view form.

Please see attached screenshots before and after.

Before

After

OK for me too !

Patch rerolled

Setting back to RTBC, above test fails are unrelated.

contextual filters may depend on relationships, so the latter ones should be listed first.

+1 to this small but useful change on a UX perspective.

Some thought/notes...

• Contextual Filter are more commonly used than Relationships
• Contextual Filters do not require Relationships
• For many fields 'Relationships' are added in the background

I am not sure this change is worth making.

Discussed today at UX meeting and I agree with @jrockowitz: I missed that Contextual Filters do not require Relationships. I was assuming one required the other.

And as Angie and Aaron suggested on the call, Contextual Filters is one of the most used features in the "Advanced" group and probably people with experience with this UI would get confused.

Yeah, one of our concerns was "muscle memory" since Contextual Filters is a 60-70% use case vs. Relationships more like 10-20%. Suddenly flipping them 10+ years into Views UI's lifetime could lead to frustration. I think not knowing that Views would "fill in the blanks" of missing relationships, this change would make a lot of sense. But since it seems to do that, this might be "won't fix" (sorry :\), at least unless the impact of not making the change can be demonstrated to override these other concerns.

It's a tricky problem because you're balancing "mental model" with "frequency of use" and both are valid ways to order listings of stuff. (As well as alphabetical, etc.)

Bumping back to needs review for more feedback.

So what's the final verdict? The patch does work and can see both sides for changing and not changing it.

Applied patch #13 on 9.5.x and it works fine.

Before patch:

After patch:

Thank you for testing but doesn’t answer the open question

I've updated the issue summary by adding steps how to reproduce the issue illustrated with the screenshots found in #22. I'll set the issue back to needs review so the requirements for a review in fridays usability meeting are met (either in #3308883: Drupal Usability Meeting 2022-09-16 or in one of the upcoming weeks). That issue is definitely a good fit for having a discussion there. The points brought up in #18 and #20 are definitely reasonable and valid but at the same time a case that options stay unnoticed by the user are reasonable and valid as well. so a solution to the problem should be discussed.

We've discussed the issue at #3308883: Drupal Usability Meeting 2022-09-16. It will have a link to the recording and transcript of the meeting. For the record the attendees at the meeting were @aaronmchale, @benjifisher, @blackbamboo, @simohell, @worldlinemine, and me.

The group had a general consensus that there is the functional reason to have the change as described in the issue summary as well as the steps to reproduce section. In contrast to the comments in #18, #19, and #20 the experience of the attendees in personal as well as customer projects was the opposite, that relationships are used more often than contextual filters. Therefore a comment from @aaronmchale in the run-up to todays meeting sums up the case pretty well

I'm less convinced by the muscle memory argument, the first time the change happens and people see it, yeah they might click the wrong things once or twice, but their "muscle memory" will re-learn, you could apply that same argument to almost every change we make which causes a UI to be changed: someone, somewhere will have their "muscle memory" impacted for a brief moment. I don't think that's a good justification for not making an improvement, particularly when it comes to usability. If the change we make has an overall positive impact, then we should make that change.

As @benjifisher put it at the end "if there is a functional reason then let's do it". Therefore our recommendation is to switch the position of relationships and contextual filters as described in the issue summary. I'll remove the Needs usability review tag again and set the issue back to Needs work since it would need a patch for Drupal 10.1.x-dev at this point.

#13 still appears to apply to 9.5.x and 10.1.x. Queued up for retesting

This issue does not need anymore screenshots.

So #13 passed 10.1.x but had, what appears to be a random, failure on 9.5x

Should this go to review then for 10.1?

The beta releases for Drupal 9.5.0 and 10.0.0 were released yesterday. I think that means that most issues, including this one, should now target 10.1.x, so I am updating the version field.

I expect that issues will be bulk-updated soon to make the same change, like #24-#29 on this issue.

So moving to NR since the patch passed 10.1

The change is very simple so I don’t mind marking RTBC.

Again no more screenshots

According to a chat in the ux channel in the drupal slack i've updated the issue summary and adjusted it to the issue summary template. I've only left out the original report section since that one doesn't apply for this issue. I've then also added the screenshots from #31 to the ui changes section and added a sentence to the proposed resolution section.

+1 to RTBC from my perspective, let's get this one done!

Credited as many people as possible for the discussion. Committing the patch as this change was agreed by the Drupal usability meeting.

Committed and pushed 7f52db6fb2 to 10.1.x and e7e1cab8f7 to 10.0.x and 6c67f2b5e3 to 9.5.x. Thanks!