WordPress.org

Make WordPress Core

Opened 7 years ago

Closed 15 months ago

#4735 closed enhancement (invalid)

OK/Cancel dialogs should have choices specific to the situation

Reported by: novasource Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Administration Keywords:
Focuses: Cc:

Description

The confirmation dialogs are not intuitive as their fixed OK/Cancel buttons require a layer of interpretation.

For example, to delete a draft, you get a dialog where you must read the explanation to understand if you should hit OK or Cancel. This is unintuitive and could invite errors.

The buttons' names should directly correspond to the choice I am about to make.

If this is not possible to change dialog button names, you shouldn't use a dialog at all, instead modifying the form to show two additional buttons right below the delete draft button that have appropriate text.

The dialog that appears when you navigate away from a draft without saving is just as bad, although I am not sure how possible a workaround is there.

Change History (21)

comment:1 novasource7 years ago

  • Component changed from Administration to General

Correcting the Component selection for this request.

comment:2 JeremyVisser7 years ago

  • Component changed from General to Administration
  • Milestone changed from 2.3 (trunk) to 2.4 (future)
  • Priority changed from normal to low
  • Severity changed from normal to minor

This is not possible to do, at least with JavaScript's confirm() function.

Possibly we could use a faux popup like what is done with the widget options?

comment:3 novasource7 years ago

  • Priority changed from low to normal
  • Severity changed from minor to normal

Thanks. I'd like to propose normal priority and severity since this design issue invites errors which could cause data loss.

As for how this is implemented, I'll bow out of that discussion. I have thoughts, but I am not an expert on Wordpress's organizational development methods.

comment:4 Nazgul7 years ago

This seems related to #2560, #4089 and #4529.

comment:5 follow-up: novasource7 years ago

2560: not well related. I want to can the OK/Cancel wording entirely. The buttons should indicate what you want to do without requiring a layer of interpretation. Cancel does not mean "keep my data" without context analysis.

4089: a possible solution, but I would go further and have the button labels read exactly what you want to do. In his example, I would have the first button read "Permanently delete" and the second one read "Keep content"--or something like that.

4529: not related. That is about undoing actions, and it can be implemented regardless of dialog used.

comment:6 in reply to: ↑ 5 ; follow-up: foolswisdom7 years ago

  • Summary changed from Make confirmation dialogs more intuitive to OK/Cancel dialogs should have chooses specific to the situation

Are their web services that do this well already?

Replying to novasource:

4529: not related. That is about undoing actions, and it can be implemented regardless of dialog used.

I think you are mistaken. Undo functionality would eliminate all/most of the AYS dialogs.

comment:7 novasource7 years ago

  • Summary changed from OK/Cancel dialogs should have chooses specific to the situation to OK/Cancel dialogs should have choices specific to the situation

typo correct the summary field

foolswisdom: I see what you mean. That's OK with me.

comment:8 in reply to: ↑ 6 ; follow-up: westi7 years ago

Replying to foolswisdom:

Are their web services that do this well already?

Replying to novasource:

4529: not related. That is about undoing actions, and it can be implemented regardless of dialog used.

I think you are mistaken. Undo functionality would eliminate all/most of the AYS dialogs.

I would be wary or replacing the nonce checks and AYS with a straight undo functionality.

We need to ensure that a GET request from a foreign page cannot cause a delete (or any other action) without the user being prompted.

If we dropped the nonce protection (and hence the AYS when nonces are not present) then a remote IMG tag with the src pointing at the blog admin would be able to delete comments for permenently logged in users - which is bad.

Seeing as we have good messages for each of the core AYS functions we should be able to add good labels as well.

Merging the AYS for delete/spam/moderate would be a real bonus.

comment:9 JeremyVisser7 years ago

Hey -- that undo is a good idea. We could, say, use WP-Cron to purge posts/drafts that have been 'deleted' for over 6 hours, with the opportunity to cancel the deletion.

comment:10 in reply to: ↑ 8 foolswisdom7 years ago

Replying to westi:

I would be wary or replacing the nonce checks and AYS with a straight undo functionality.

Seems your comment is also (maybe most relevant in) #4529. AYS are a bad experience, but as you describe there are many security considerations for a undo implementation.

comment:11 follow-up: markjaquith7 years ago

Westi, you're confusing two different things. This ticket is talking about modal JS "OK/Cancel" dialogs, not the "Yes/No" HTML dialog you get when you omit a nonce where one is required.

JS AYS is not a security measure. Nonces are the security measure, and those remain regardless of JS AYS. JS AYS only serves as an errant click prevention device. "Undo" functionality can completely replace JS AYS dialogs.

comment:12 in reply to: ↑ 11 westi7 years ago

Replying to markjaquith:

Westi, you're confusing two different things. This ticket is talking about modal JS "OK/Cancel" dialogs, not the "Yes/No" HTML dialog you get when you omit a nonce where one is required.

JS AYS is not a security measure. Nonces are the security measure, and those remain regardless of JS AYS. JS AYS only serves as an errant click prevention device. "Undo" functionality can completely replace JS AYS dialogs.

OK.

I guess lack of sleep at the time of my comment got me a little confused :->

comment:13 ffemtcj6 years ago

  • Milestone changed from 2.5 to 2.6

comment:14 Denis-de-Bernardy5 years ago

  • Component changed from Administration to JavaScript
  • Milestone changed from 2.9 to 2.8
  • Owner changed from anonymous to azaozz

comment:15 janeforshort5 years ago

  • Milestone changed from 2.8 to Future Release

Punting due to impending release. Will reconsider in upcoming release cycle.

comment:16 Denis-de-Bernardy5 years ago

  • Component changed from JavaScript to UI
  • Owner azaozz deleted

comment:17 caesarsgrunt4 years ago

The most common JS confirm(...) dialogs have been replaced by the Trash/Undo functionality. However, there are still both confrim(...) dialogs and HTML confirmation pages, and there is some inconsistency about which system used in some places.


To the best of my knowledge, the situation is currently as follows.

Trash/Undo has replaced confirmation dialogs in the following places:

  • Deleting Posts
  • Deleting Pages
  • Deleting Media
  • Deleting Comments

JS confirm(...) still exists in the following places:

  • Deleting Tags
  • Deleting Categories
  • Deleting Links
  • Deleting Link Categories
  • Deleting Themes
  • Cancelling the Editing of Media

HTML pages are used to confirm the following actions:

  • Deleting Plugins
  • Deleting Users

And there is no confirmation of the following:

  • Removing Widgets from the sidebar

The biggest inconsistency here is between deleting Plugins and deleting Themes. Whilst Plugins get an HTML AYS page with a list of files which will be deleted, Themes have a JS confirm(...) dialog. I think Themes should also get an HTML page.
An alternative would be to add a form of Trash/Undo to Plugins and Themes too, but personally I don't think it's needed and I would be against the idea.

Regarding Links, Tags, and Categories - these could also have the Trash/Undo.
However, when implementing Undo I decided not to do it for these for various reasons. The main reason for not doing it for Tags and Categories is that there is the problem of removing the Tag/Category from all posts and then adding it again in the event of restoring it from the trash.
Additionally, I decided that Links are a very minor thing to have to re-add in the event of an accidental deletion, compared to Posts, Pages, or Comments.
Trash could be added to all these in the future, though personally I would be against it.

For cancelling the editing of images, the JS confirm(...) could be replaced by an inline prompt fairly easily since there is a lot of jQuery used for that feature already. I dont know if a prompt is even needed there, though.

For removing widgets from the sidebar, I do think there should be a prompt - either JS confirm(...) or an inline prompt like we used to have for deleting media.


For what it's worth, I personally don't really think a few JS confirm(...) dialogs are a problem, now that we've got rid of the major ones.

comment:18 solarissmoke3 years ago

  • Keywords close added

Is there still traction for this? Ticket's been idle for ages?

comment:19 RyanMurphy3 years ago

If a committer/Jane says a patch will at least be talked about, I can go through and make one.

comment:20 nacin3 years ago

Given the status in 17, this is low priority. The most common tasks no longer have JS confirmations.

Deleting themes should have a page like plugins. Perhaps Jane has something specific as a replacement for JS confirmations for term deletions.

comment:21 helen15 months ago

  • Component changed from UI to Administration
  • Keywords close removed
  • Milestone Future Release deleted
  • Resolution set to invalid
  • Status changed from new to closed

Closing, as you can't change the button text on a plain JS confirm dialog. New and specific tickets should be opened for changing how a given AYS instance is handled, since they may/probably require different treatments based on the situation.

Note: See TracTickets for help on using tickets.