Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[UX] Better content deletion confirm forms. #3162

Open
klonos opened this issue Jun 3, 2018 · 11 comments
Open

[UX] Better content deletion confirm forms. #3162

klonos opened this issue Jun 3, 2018 · 11 comments

Comments

@klonos
Copy link
Member

klonos commented Jun 3, 2018

Before:

screen shot 2018-06-04 at 9 26 05 am

After:

screen shot 2018-06-04 at 9 31 01 am


PR by @klonos: backdrop/backdrop#2221

@klonos klonos changed the title [UX] Better module deletion confirm form. [UX] Better content deletion confirm forms. Jun 3, 2018
@klonos
Copy link
Member Author

klonos commented Jun 4, 2018

...in the PR I have also fixed the content bulk deletion form.

Before:

screen shot 2018-06-04 at 10 59 34 am

After:

screen shot 2018-06-04 at 11 00 16 am

@olafgrabienski
Copy link

olafgrabienski commented Jun 4, 2018

@klonos In the sandbox site I saw that the sentence If you need to hide content from site visitors, you may consider unpublishing it instead. is displayed before I delete individual content but not before bulk deletion. Should we add the sentence also for bulk deletion?

@klonos
Copy link
Member Author

klonos commented Jun 4, 2018

Changes:

  • converted "Action cannot be undone" text to a warning (also changed the period to a !)
  • added the following description when deleting a single piece of content (it seemed too "empty" after moving the "Action cannot be undone" to a warning):

    If you need to hide content from site visitors, you may consider unpublishing it instead.

  • appended the content type after each content title in the list of files to be deleted when deleting multiple pieces of content in bulk.
  • unrelated, but while at it, I also fixed a UI bug that caused the success message to always refer to the content types as "posts" no matter if they were a mix of other types. Changed that to the more generic "item"/"items" instead.

@klonos
Copy link
Member Author

klonos commented Jun 4, 2018

@olafgrabienski, yeah, sorry, I had typed my previous comment in the morning, after filing the PR, but forgot to press "save" 😄 ...as I explain above, I added that text there because the page seemed too "blank" when deleting an individual piece of content (via the operations drop-button). When deleting via the bulk operations (even if a single pice of content has been selected), that space is filled with a list of pieces of content to be deleted, so that is not "a problem" in that case. I wanted to get some feedback before adding the same text in the bulk operations confirmation page too.

I am trying to make our UI more smart/intuitive, and to be suggesting things for newcomers where it makes sense. If this feels like out of scope, I can revert that change (and stop doing that in general). If people think that this makes a better product, then I can be adding these small snippets here and there as I am fixing things in the UI.

All feedback appreciated.

@opi
Copy link

opi commented Jun 4, 2018

In https://user-images.githubusercontent.com/2423362/40892440-87627038-67da-11e8-8be9-fc88e1290881.png, why is there a left padding before the "If you need..." sentence ?

@klonos
Copy link
Member Author

klonos commented Jun 4, 2018

@opi I have not touched the style of that at all. This must be the default padding that comes with the description. Don't have the time to look into it now, but promise to do so soon.

@herbdool
Copy link

herbdool commented Jun 5, 2018

An improvement. However, I'm not sure we can assume a "visitor" can't see unpublished content. It depends on permissions and whether they are logged in or not.

@klonos
Copy link
Member Author

klonos commented Jun 6, 2018

Valid point @herbdool 👍 ...adding a check on permissions so to conditionally show the message seems overkill for a help text (not that we are not doing that elsewhere), so I could just remove the text.

Waiting for some more feedback before I update the PR.

@quicksketch
Copy link
Member

I'm worried about using messages directly in the form definitions like this. I've seen this problem previously where the message can end up being displayed after the form is submitted. It also makes it so that the form can't be embedded anywhere else, because the message will be shown at the top of the entire page. Aesthetically I think this is an improvement. I'm not sure if my technical complaint is sufficient argument against a UX improvement.

@klonos
Copy link
Member Author

klonos commented Sep 3, 2019

I think we can get around the issue of having the warnings "bleed" into other pages either by using a blank backdrop_get_messages() in the functions called by the submit button (or the redirect of the "Cancel" link), or alternatively add the warning as #markup, with classes that style it as a warning. I think we've done the same elsewhere before. I'll have a look soon as I get a chance.

@klonos
Copy link
Member Author

klonos commented May 2, 2023

Perhaps #3329 can help here as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants