Bring back contextual links for admin views

+1

If contextual links is out of the question as @Bojhan said:

Ugh, the contextual link really sucks...

...then we should at the very least provide a "Configure this display" link somewhere at the bottom right of the list/table that would take people straight to the respective view in edit mode.

As @ParisLiakos perfectly explained this would save clicks and time.

The main reason, IMO, that we're not using contextual links is that Seven doesn't have a good place to display then when they're on the page level.

We did have a discussion about this back in #1851086: Replace admin/people with a View, I don't mind either way but the UX guys also wanted the contextual links removed for these pages...

Yeah, the links were removed specifically at @Bojhan's request. See #1851086-64: Replace admin/people with a View through #78.

The original point of bojhan was the following:

Ugh, the contextual link really sucks. I always hated that in admin generated screens - 99% of the time it will be irrelevant, we should figure out if we can make that nicer. Perhaps we can have a way to hide them, a setting?

Why will it be irrelevant ... Just one example usecase: You add any kind of field and you want to filter your content by that field. This happens on a lot of sites ...

I agree with paris, although in drupal7 it was anoyign to have lots of contextuals in one place we should be able to show it somewhere. As I'm not a theming/contextual link expert Im not going to fight for this as I'm not going to work on it :).

Writing a patch is a novice task.

Changed this for admin/content and admin/people, however I think there is a UX change that should be made too. The pencil is in the upper right hand corner of the page, but I would suggest that it appear somewhere more obvious. I'm not sure if this is a Seven theme issue globally or simply related to views that are pages. Images attached of current and proposed.

In support of #10 & #11: Also note that the contextual links on Views will only appear if the current user indeed has permission to edit the view. Other users won't be bothered by it.

#13: you might need to adjust Views' work-around that it uses to get contextual links to show up on the right element. Because, indeed, here it doesn't appear in the appropriate location.

With this location I really don't think there is a reason anymore to not have the contextual edit links.

There has been a fix proposed for Drupal 7: #1493210: Contextual links added to page element if 'page' view is displayed
I hope this can be adapted to Drupal 8 really easy.

remove something that people can read different than meant

13: vdc-bring-back-contextual-link-admin-views-2020265-13.patch queued for re-testing.

I really like the improvement in #13. The current placement can affect the shortcut link in the new content header design. #2022695: Content header style update

13: vdc-bring-back-contextual-link-admin-views-2020265-13.patch queued for re-testing.

ReRoll Note Also to be consistent with YML coding standard all '1' values have been converted to true.

We should get Bojhan to weigh in here.

Reviewing this tomorrow

I don't think this is a good idea, let me elaborate though. For us going back and forth between the views UI and administration UI is only natural, just to add a few more filters. However lets keep in mind the next two principles:

1) How often do you adjust the administration UI?
- Probably most often in the initial building of the site. In reality a large part of our audience, probably won't bother doing this at all (there is a nielsen report on this).

2) How usable is it?
- For experts exposing this functionality it is very usable, for beginners exposing this functionality it is very dangerous and unusable. Because after all you can wreck your administration page with changing one option, and there is no way to get back. http://limi.net/checkboxes-that-kill/ is a very well written piece on this subject.

This UI is very useful, but its not something a beginner or probably even intermediate user desperately needs close at hand. The people that need it, will probably have stumbled upon it in the views UI by the time this use case opens up. If not, its more likely that they will take the effort to find it, its not like its very hidden its in a key interface. Keeping it out of the administration UI by default, will make it more safe and usable for our beginner/intermediate audience.

This is the kind of clutter, I am trying desperately to keep out of our UI. Its easy to let those small details slip into the UI, in the end you will have a cockpit with small buttons everywhere because of our modular nature.

Just to play devil's advocate for a moment...

The only people who will see these contextual links are people with "administer views" permissions, correct? In other words, the site builders, the "experts" for whom the very feature exists. By contrast, content authors, forum moderators, and other "beginner/intermediate" roles that actually use these pages day-to-day will not see these links, and therefore will not be confused/overwhelmed by them. At least in theory. (This needs verifying via manual testing.)

This is why in the block conversion issues I've been pushing so hard to make sure that content author-affecting settings (# of records, title, etc.) do not require "administer views" permissions to change, and instead only normal "administer blocks" permissions. So that we can keep this separation between roles, and in theory allow "power user" niceties like this to exist.

Changing status.

Yes, and no. I think we shouldn't classify beginners/intermediates as people who don't have administer views permissions. As developer when you start of with Drupal you are also a beginner and often quickly intermediate. Our content authors, forum moderators will indeed not be affected by this change. I don't worry about them too much, I think we are more and more making Drupal harder to use for the developers/site builders starting out with Drupal.

I fear that people who start out with Drupal, will be introduced to Views through the most destructive method. Potentially rendering their admin UI unusable when they tinker with it. I think for most people who know what they are doing, the step to the Views UI to see that you can edit these pages is rather small - and that from my understanding that will be the primary audience for this.

Therefor don't it's wise to introduce Views to beginners, through contextual links in the admin UI.

Yeah, I can see that perspective (esp. the "oops I just completely broke my admin interface" argument). The only counter-argument I'd say is that without these contextual links, it's not really discoverable at all to beginner/intermediate site builders that these pages even are views and can be modified in the Views UI (this has never historically been the case, and it's definitely not the case in most other CMSes). And after you install a fairly trivial number of modules, the list of views at admin/structure/views becomes totally unwieldy, and so I'm honestly not sure how else to expose this awesome feature to beginner site builders apart from contextual links.

I'd also posit that if they're *super* beginner site builders, they will probably take one look at the Views UI and then scream in terror and close the window. ;)

I'd also posit that if they're *super* beginner site builders, they will probably take one look at the Views UI and then scream in terror and close the window. ;)

If we add a tour for the first time someone visits the views UI this part could be skipped..

The only people who will see these contextual links are people with "administer views" permissions, correct? In other words, the site builders, the "experts" for whom the very feature exists. By contrast, content authors, forum moderators, and other "beginner/intermediate" roles that actually use these pages day-to-day will not see these links, and therefore will not be confused/overwhelmed by them. At least in theory. (This needs verifying via manual testing.)

I think this is a good point. Existing site builders kind of expect that these listings can be changed, as they are a view. For other people it is probably a good experience to know that these are changeables.

@Paris
Let's tackle it from the other site and remove contextual links module :)

@webchick Yeah, it is less discoverable but in no way undiscoverable. It is pretty prominently shown when people are exploring Drupal, if you have installed a few modules - you probably also at least seen the listing of Views. I think for the people, who actually want to customize a page - finding it should not be too hard.

Although I understand we want to expose the "awesomeness" of this part, I am just not sure if that justifies the potential bad experience a beginner would get. Also its important to keep in mind the 80%. Contextual links are quite a distraction (showing/hiding of a contextual links is a motion, which draws attention). I think its save to say that atleast 80% of the time that you spend in /admin, you won't actually need this. -Customizing a admin page is something you only do once in a while. It is not something you use on a daily basis.

Contextual links on admin serve a much smaller use case than on the front-end, where it is quite often the 80% usecase for navigating between the admin and your end-result on the front-end.

We are making some movement in reducing the scream of terror, tour is one, some of the UX issues we are working on resolves some of it (e.g. making the listing of views more scannable). But it will be long before, we can actually consider it a good experience.

I stand by my point, that introducing it would introduce 1) clutter, the functionality exposed isn't used often enough to justify its exposure on every page, everywhere 2) bad experience for beginners, because of the destructive force. I know we should market this functionality, but I dont think its a good idea to do that at the expense of UX.

@Paris I don't think it is respectable to other community members or productive to take this to reductio ad absurdum. This is a very real concern, and as UX maintainer my role is to express that concern.

Note: this is a highly opinionated comment, though well, it is really want I want to express.

Here are the list of people supporting to show them:

• Paris
• klonos
• tim.plunkett
• aspilicous
• wim leers
• LewisNyman
• martin107

Neutral:

• webchick
• damiankloip

Hide them:

• bojhan

@Paris I don't think it is respectable to other community members or productive to take this to reductio ad absurdum. This is a very real concern, and as UX maintainer my role is to express that concern.

This is your good right, though it does not mean that other community members should be ignored or overruled.
People have a 180% degree opposite opinion to you.

Drupal should never be a crippled tool, it is a tool to empower and not babysit people and by people I talk about all the people especially site builders.

. I think its save to say that atleast 80% of the time that you spend in /admin, you won't actually need this. -Customizing a admin page is something you only do once in a while. It is not something you use on a daily basis.

Here is a point which just claims exactly the opposite:
What do site builders usually do: They add new content types, and add some new fields on them. Create some views (pages and blocks) and finally place them.
Once this is done you start to care about the admin site of things. You realize that more actions on the admin listings would be helpful as well as exposing also the new fields on them. Additional the actual output is often way clearer defined than the rest, so the potential of changing the rest is higher.

Instead of would rather suggest to remove the functionality to hide contextual links again, because hiding them is really not the 80% usecase. If your drupal distribution wants to

Regarding the potential for "wrecking" the admin - can't you then revert the changes to the default view? Also, including Views in core is one of the single greatest achievements of D8, I have a strong suspicion that a lot of time will be spend in D8 training materials (books, videos, etc) will be focused around customizing views, so I don't think we should be saving the admin from themselves.

+1 for providing the contextual links, in my experience there's no more real danger in exposing them for admin pages than in exposing them for non-admin pages.

@dawehner I think its up to the committers to decide. I don't think this is a voting game, I think I have expressed valid concerns - I am not ignoring or overruling anyone, I am merely expressing my concern. Keep in mind, my voice is often quite alone in these discussions - thats probably because my perspective as a UX designer is quite different. If Drupal would have been a voting game, my voice would probably never made any impact on the project, luckily it isn't and we allow for argumentation decide the best road forward.

I understand that there is a usecase, where people want to do this. I just don't think its a very common one, sadly we are both making this case with no data behind us other than from personal experience with the people around us.

I think its up to the committers to decide.

Great, then we'll leave it where they can find it.
And where it was before you knocked it back.

@tim.plunkett Thanks.

Given that the Views contextual links are much more out of the way in D8 than then views clone/edit links in D7, I'd be in favor of having them on by default.

Yeah, I mean, if they prove to be much trouble we can simply add a "disable this menu" link as the very last item in the context menu. This would allow people that are annoyed/confused by the context menus to disable them with ease right there without having to pogo stick around the admin UI (follow-up?).

So when we're at an impasse like this on a UX issue, it usually helps to try and collect some data. Fortunately, these views are essentially a copy of the Administration Views module in contrib, so we can look there for inspiration.

A search for "contextual" in that issue queue reveals only a couple of bugs and then #1778058: Remove contextual links from admin views, which was two developers (Damian and Sun) discussing amongst themselves briefly whether or not to do this, though neither felt super strongly one direction or the other. In the end the patch was committed, back in December 2012. The usage stats for the module at that point was about 5K people.

Since then (not claiming this is because of this change by any means :D) the module has ballooned to about 25K installs, which puts it in the top ~150 modules on Drupal.org. And despite a 400% increase in users, it doesn't look like anyone has complained about these contextual links not being on by default, ever. Now, granted, one thing we don't know from this data is whether or not people swore and fussed over this and adjusted it locally, silently muttering to themselves. But still. You'd think if it were a hugely annoying problem, and people were tweaking this on every single site build, there'd be some mention of it in the issue queue. And just to be on the safe side, I also grepped all distros looking for code that overrode these views and came up with nada.

So given that Administration Views already does what HEAD is doing, and has 25K happy users as a result, I find it a bit hard to get excited about this patch, despite the fact that I lean slightly in favour of committing it. And in any case, it's certainly not cause for the kind of disappointing snark that's happening here. :( https://drupal.org/dcoc

There is a claim to be made though that since Administrative Views is a separate contrib module you needed to go and get, chances are high you knew these pages were views (it's in the module name, after all, duh) and knew to make whatever adjustments were needed in the Views UI. This sort of clue will not be available in 8.x core, and in fact the default assumption will be that these pages are hard-coded since they were in previous Drupal versions and they are in every single other CMS that I can name.

As a result, rather than "won't fix," I lean towards "postponed" until a few beta releases in/just before RC1. By then, we will hopefully see more non-core developers using Drupal 8, and even have done some initial outside UX testing. If we see support requests coming in, or UX testing that shows that people have no idea how to customize these pages, we could make the decision then to flip the switch. (Really, we could introduce this in any minor release of D8, too.) But for me, anyway, the data doesn't bear out that this is a "no-brainer" change to make.

... You'd think if it were a hugely annoying problem, and people were tweaking this on every single site build, there'd be some mention of it in the issue queue. ...

And just to be fair: #1778058: Remove contextual links from admin views has only 4 followers (of which one is an irrelevant user/comment made a couple of weeks ago - so actually only 3 followers). So using the same rationale one could claim that it's not like there was a heap of complaints about the feature in the first place so to be decided to be removed. It was merely a decision of two people as you say. I see no UX studies preceding it or whatever.

... If we see support requests coming in, or UX testing that shows that people have no idea how to customize these pages, we could make the decision then to flip the switch. ...

Just as we could commit and watch for support requests or bugs instead or have UX testing actually prove that they get in the way of people and end up confusing them.

...just playing the devils advocate here (plus I find contextual links really convenient to be honest).

Well, let's just not fight here anymore. Afaik this was done as the UI was kinda broken with that, but sure there are
more important issues than explain people how things work.

I put this code in the Global PHP header supplied by Views PHP for a homemade admin contextual link. Works great and is a no brainer. You may need to adapt it to your own role names.

<?php
global $user;

if (in_array('administrator', $user->roles)) {
  echo "<a style='font-size:200%;float:right;' href='/admin/structure/views/view/" . $view->name . "/edit/" . $view->current_display . "'>&#x270D;</a>";
}
?>