If journalists enable NoScript, they don't get warning when deleting source codename

[trevortimm]

Journalists who have scripts turned off do not get an 'are you sure?' warning when they go to delete a source code name.

The means that journalists engaged in best security practices are ironically more at risk at slipping up and deleting a communications line with a legitimate source.

[diracdeltas]

I've noticed this too.

We could redirect them to a "Are you sure you want to delete these codenames?" page and then force them to click through it before deleting.

[garrettr]

@diracdeltas That would work, but I'd actually encourage taking a different approach (would require some backend work). I really hate the UX of these confirmations, because 99% if I click "delete x", I meant it. But then there's the 1% of times when it was a (potentially catastrophic) accident, and I want to undo it.

So - let's add an "undo" feature instead. Banish confirmations, and instead show what was deleted in the response and give a button to "undo" the change. Github is a great example of a site that uses this pattern (try deleting a comment).

To implement this on the backend, we'll want to use a work queue. This should be straightforward. If you guys agree with this UX change, comment affirmatively and I can start working on implementing that.

@trevortimm Note that other features of the journalist UX (for example, the "select all" and "select none" buttons) won't work if JS is disabled.

[garrettr]

Ack, my example was bad! Deleting a comment uses a JS confirmation and then deletes it with no option to undo. I've seen the suggested pattern elsewhere on Github though, just can't remember where.

[diracdeltas]

This sounds like a good UX improvement. How long would you wait before permanently deleting?

[garrettr]

In my mind, the key use case is the "oops, I hit the wrong button" moment of terror, so the delay doesn't have to be long. 5-10 minutes seems reasonable to me.

[dolanjs]

I think that the 5-10 min queue would suffice and this approach is better
than the warning message.
On Jan 28, 2014 8:04 PM, "Garrett Robinson" [email protected]
wrote:

In my mind, the key use case is the "oops, I hit the wrong button" moment
of terror, so the delay doesn't have to be long. 5-10 minutes seems
reasonable to me.

Reply to this email directly or view it on GitHubhttps://github.com//issues/295#issuecomment-33546510
.

[rosatolen]

Picking this up. https://trello.com/c/IposmE55

[psivesely]

Note this is the same for deleting journalists/ admins.

[heartsucker]

@redshiftzero Hackathon candidate again?

[redshiftzero]

Good call - added!

[daonb]

This seems the oldest issue for the Hackathon, so I'll have a go. Here's what I figured:

Good security dictates disabling JS. When that happens, the system requires no confirmation for destructive actions, like deletion. The proposed solution is to add all critical actions to a work queue with an activation timer of 10 minutes and give the user 7 minutes to click an Oops button and revert the change.

On the UX side, we need to list all the critical activities. On the front we'll need a simple, template based notification system to display a one line with the last critical activity and an Oops link. On the back we need a work queue (not sure if we have one) and a task runner to handle all critical activities.

[heartsucker]

I think that's actually more complicated. What we could do is have JS buttons start with a default form action pointing to some HTML page that asks for a confirm. Then the JS erases that and replaces it with the confirm popup before going ahead with the action.

I think that's more inline with how some of the other behavior is and more intuitive. I think people assume most actions on websites don't have an "oops" option.

[daonb]

After talking with the guys at lunch, we want to suggest to keep things simple and resolve this granddaddy of an issue. We've got about 3 hours to go in the TLV Hackathon...

Let's replace the js based approval system with a new HTML confirmation page. What @heartsucker suggested is clearly better, but we don't have the time.I suggest we solve this the simplest way and open an fresh issue for the Oops button.