backdrop-issues
backdrop-issues copied to clipboard
backdrop
[UX] Add a cancel link in the views UI
When I edit a view, then decide not to make any changes, I always scroll around for a while looking for a cancel link or button. But then realize there is not one, and click "Back" in my browser. I think we could improve the user experience in Backdrop by adding this missing Cancel link.
When I edit a view in 1.6 I get a CANCEL button right next to the SAVE button at the top of the page.
@Dinornis the save and cancel buttons show up in the view edit form only once you make a change. What @jenlampton means is that we should have the cancel button available no matter if there was something edited or not.
PR upcoming...
@klonos With your PR applied (or in the sandbox site), making a change won't un-hide the submit button, so it makes it so that you cannot save the View at all! There's probably a line of JavaScript that also needs to be updated somewhere to show that button after a change is made.
Took a while of searching, but finally found the solution to the issue that @quicksketch mentioned. PR attached.
Looking good, but do you guys think that perhaps the button label should be something like "Back", instead of "Cancel"? "Cancel" without a "Save" paired to it feels kinda weird (unless in a dialog).
...also, it makes sense for this cancel button to be redirecting to the views listing page when the user started by editing a view from /admin/structure/views, but not if they were in another part of the admin UI and have used the Admin Bar (🍻 😆) to get to the view edit page. In the later, we should be redirecting them back to where they originally started from.
I like Cancel because it's consistent with the rest of the UI. I think another word might be confusing.
@klonos or @jenlampton - I think the redirect thing makes sense, assuming it's not too difficult to do - and I'm assuming it's not. I might have someone to work on this, can anyone provide a quick pointer on how to add the "redirect" thing?
Unless @BWPanda has the time and inclination to update the current PR.
I'm good with the PR as it is, but the redirect does make sense.
I tried doing the redirect, but couldn't work it out...
The 'Cancel' button is currently a form button (as opposed to a link). As such, when I try to get the HTTP_REFERER path to redirect to after pressing 'Cancel', it redirects back to the view form itself, since that's where you were when you clicked 'Cancel'.
This doesn't happen with other form (like nodes), I think because their 'Cancel' buttons are actually links, and they work differently. I tried making the views 'Cancel' button a link instead, but then you just give it a URL to go to, it can't run the function that clears any unsaved changes from the view.
So not sure this is going to be possible... Someone else is welcome to take a stab though.
@BWPanda forms like node_form() do this by preparing the redirect destination in the form, not after clicking the link/button. Would that not work here?
The current PR looks good as-is to solve the missing Cancel button. Maybe we make a follow-up? Besides the redirect location, I'm also inclined to add a status message along the lines of "Changes to the view %name have been discarded." So you get some kind of confirmation. Like @BWPanda says this is a button rather than a link, because Views have persistent storage while you're editing. Clicking the Cancel button actually does something in Views, not just leaving the page.
I like the idea of making the redirect a follow-up. I've updated the current PR to display an info message re. the changes being discarded ('info' because neither 'status' nor 'warning' seemed appropriate).
There's some problem with the Tugboat sandbox - it's expired, still seems to exist, but the password doesn't work anymore.
Also: the PR branch is quite behind, maybe a rebase makes sense, anyway.
I rebased the PR from @BWPanda and created a new one with his work to see if we can move this forward.
@quicksketch, @jenlampton, @indigoxela, @klonos, @Dinornis, @docwilmot
@stpaultim I tested your PR. I'm finding the same problem as this comment from 2017. When I make changes to an existing View, the Save button never appears in the View, and therefore it can't be saved.
Actually, after clearing caches, the Save button is now appearing. The modified JS script hadn't loaded after applying the patch, because of the js cache.
Thanks for the changes, @stpaultim. This WFM. There is a phpcs error (whitespace). Otherwise LGTM
We have moved to using links instead of buttons for "Cancel". So the cancel action we are introducing here should also be '#type' => 'link' instead of '#type' => 'submit'.
...I'm actually not sure about the value of the JS that shows/hides the submit elements in that form. We aren't doing that anywhere else AFAIk.
We have moved to using links instead of buttons for "Cancel". So the cancel action we are introducing here should also be
'#type' => 'link'instead of'#type' => 'submit'.
@klonos, this was already discussed above. We need to use a submit element because Views needs to do something before leaving the page. It gets a lot of info about the view via POST. A regular link only does a GET
See https://github.com/backdrop/backdrop-issues/issues/2516#issuecomment-1088013852
@klonos, this was already discussed above. ...
Right. Sorry, I missed that. Thanks for pointing it out. We actually have the same thing going on in the "Manage blocks" form. I'm not sure if I want to file a separate issue to have those submit buttons styled as links for consistency or not 🤔 ...perhaps I'll let it go for now, and if it ever comes up in the future, then we can sort it out.
What do you guys think about getting rid of the JS that shows/hides the submit button? Less complexity and code to maintain, and it'll bring things in par with the "Manage blocks" form and other forms too.
@klonos I simply rebased the previous PR with this JS. I haven't really thought about or know what the alternative would be.
Right, so here's my thinking... the issue description says this:
When I edit a view, then decide not to make any changes, I always scroll around for a while looking for a cancel link or button. But then realize there is not one, and click "Back" in my browser. I think we could improve the user experience in Backdrop by adding this missing Cancel link.
That ^^ is happening because JS is hiding the buttons. The UX bug with the current implementation of this JS is that it is hiding both the "Save" and the "Cancel" buttons (until there is any edit performed, in which case it reveals the "dirty form" message + both buttons). Our solution to that problem is to adjust that JS to only be hiding the Save button, and to leave the "Cancel" button alone (always shown). My proposal is to simply rip all that JS hiding code out, and show both buttons all the time, like we are doing in the "Manage blocks" form. That would solve the initially reported problem + reduce code/complexity.
...so basically:
- remove the
$('div.views-edit-view div.form-actions input#edit-actions-save').removeClass('js-hide');line fromcore/modules/views/js/ajax.js - remove the code in the
if (empty($view->changed)) {conditional that adds thejs-hideCSS class, along with the conditional itself. - leave the info message we've added, cause that's a nice UX+
On other pages, the submission buttons are never hidden, even in the case there have not been changes in the shown data. I think it would make sense to avoid hiding Save and Cancel on the view edit page too.
My proposal is to simply rip all that JS hiding code out, and show both buttons all the time, like we are doing in the "Manage blocks" form.
Makes sense to me.
@stpaultim it seems that we have some consensus here. Are you going to be able to work on this so we can knock it out of the way?(please see instructions in my previous comment - should be straight-forward).
@klonos I think I got it. Made changes to simply leave both buttons visible all the time.
I don't have strong opinions about this, so if this blows up, I was just following orders. ;-)
Look forward to hearing from others. Mostly, did I do enough ripping out of code. I ripped out the related code that was visible in this PR. Is there anything I'm missing?
Sorry, Tugboat sandboxes don't seem to be working for me right now. Anyone have any ideas about that?