I’ve just noticed something I haven’t seen before after enabling the Drupal core contextual_links module. On an individual taxonomy term page there is now an “Edit” button in the secondary menu at the top of the page. Clicking on this toggles the contextual links dropdown within the taxonomy term content area (this dropdown also appears when hovering over the term content). Within the contextual links dropdown there are links to edit and delete the taxonomy term:
I have seen contextual links before but this “Edit” menu item is new. I’m not sure if this was added with Gin, Admin Toolbar or maybe Drupal core but however it happened, it’s there! IMO having this “Edit” in the secondary menu at the top of the page is a bit weird for farmOS - this would make more sense when editing content (like a blog post) on a more traditional Drupal site.
The menu link aside - I’m curious about replicating this behavior for all farmOS entity types (asset, log, plans) and removing the edit/revision/delete task links entirely (screenshot of current land asset for context):
Right now there is an inconsistency where term pages have a “Delete” task link but the farmOS entity types can only be deleted from the bottom of the “Edit” page. This can be improved by having the “Delete” link easily accessible in the contextual links dropdown.
As we add more task links to entity pages (all assets have a “Logs” link, location assets have an “Assets” link, etc) the meaning of these tasks links becomes confusing. Some are for modifying the current entity, others are more “informational” for viewing relationships & additional information about the entity. Removing edit/revision/delete links would increase continuity and reserve more space for future & custom “informational” links.
Additional links can be added to the contextual links dropdown - this would be a nice place to link to the entity in JSON:API or perhaps hook into 3rd party applications eg: “View asset in field kit”.
I imagine there are some improvements we could make to the contextual links button itself, too. Maybe we would want it to always be displayed instead of only on hover or when toggled with the “Edit” button? Make the button bigger? Maybe move to a different part of the page? I think it might overlap with the map if rendered at the top of the content in these entity pages. Need to think about mobile, too!
An alternative to contextual links could be adding edit/revision/delete as second-level task links under “View”. This would keep these links more visible than contextual links but also take up more vertical space. Overall I think if we can improve the usability of contextual links they could be very effective & simplify the UI, but since they are hidden by default, this is a particularly hard thing to “teach” the user.
I’m open to exploring farmOS using the contextual_links module - thanks for the initial exploration and ideas @paul121!
Sounds like there are some things to think through… Might be worth just diving in with a simple draft PR to play around with in a Tugboat sandbox.
As you know, I tend to prefer sticking to “default” Drupal behavior as much as possible. Mainly because I’ve had to fix my own hacks too many times. The more we can lean on upstream the better, is my only concrete thought on this.
I’m a bit wary of trying to mess with the View/Edit/Revisions tabs… but I agree the UX isn’t great mixing those with other tabs. I wonder if we could also think about it from the other direction: should we leave the View/Edit/Revisions tabs alone and find a better place for the Logs/Assets/Children/Locations, etc?
I could almost see those being child tabs of View… but that won’t work because many of those tabs have children of their own.
I definitely see why you’re thinking of moving the View/Edit/Revisions tabs instead…
If we’re able to implement something with minimal “hacks” to core behavior, and good test coverage, then I’m open to exploring this…
I copied and modified that class slightly to set the parent_id instead of base_route for the “Edit” and “Revisions” tabs to put them in sub-tabs.
I also changed the top-level “View” tab to read the asset bundle eg: “Plant”. This is just hard-coded for an example, it might be a bit complicated to dynamically add the bundle here. But “View” just doesn’t seem entirely appropriate if “Edit” is one of it’s sub-tabs? We could leave this as “Asset” but then it becomes confusing to have “Logs” and “Assets” as the neighboring tabs… So tldr there might be a better option for the name of this top-level tab, I just thought the bundle “Plant” seems like a decent choice
Wow I really like that @paul121! Could you share the code that you created? Or push it to a branch so we can take a look. It sounds very simple, which I like.
I’d want to just give this some thorough thought and testing to make sure it doesn’t have any other potential ramifications we aren’t thinking of. But in general I’m in favor of the change!
I also changed the top-level “View” tab to read the asset bundle eg: “Plant”. This is just hard-coded for an example, it might be a bit complicated to dynamically add the bundle here. But “View” just doesn’t seem entirely appropriate if “Edit” is one of it’s sub-tabs? We could leave this as “Asset” but then it becomes confusing to have “Logs” and “Assets” as the neighboring tabs… So tldr there might be a better option for the name of this top-level tab, I just thought the bundle “Plant” seems like a decent choice
I do really like the bundle label being used. It provides another quick-glance indication of what kind of record we’re looking at, which can be helpful. (Of course there are other indications of that in the breadcrumb and on the view tab itself, but still nice IMO.)
If we aren’t able to do that easily, then we’ll have to decide what else to set this too…
