After moving a grain to trash, should navigate to /grain#trash not /grain

[paulproteus]

Steps to reproduce:

• On e.g. asheeshdev.sandcats.io , visit an old etherpad grain of mine, i.e. my browser has navigated to http://asheeshdev.sandcats.io/grain/zcvEKdzwa9mNsfzg2Xkcny
• Decide that it doesn't matter to me anymore and click the "trash" icon
• Click OK or I agree or Yes (I forgot what, precisely) when asked if I mean it
• Mentally change my mind, and decide I want it back

Expected behavior:

• The grain is in front of me somehow, so I can make that decision

Actual behavior:

• The browser has navigated to http://asheeshdev.sandcats.io/grain and I cannot see the grain (so I also don't really get a chance to learn how long things will stay in trash, or the fact that trash is auto-deleted)

[paulproteus]

Hi @dwrensha curious if you think this is worth addressing soon, so it goes into the same release as the trash UI.

[zarvox]

I believe that the current behavior is correct, and "deleting" a grain should not send you to /grains#trash. Deleting an email does not take you to your trash folder. Deleting a file in your file browser does not take you to the recycle bin.

I believe a more desirable behavior that might address your concerns might include having a flashed message acknowledging that the thing was moved to the trash, possibly linking to the trash, or providing an undo button.

[neynah]

@zarvox I agree that the user should stay on the current view but there should be some sort of indication a grain has been moved to trash. I'll quickly mock something up.

[paulproteus]

It seems the reason my browser navigates to /grain is that the sidebar tab closes. I didn't understand that at first and thought that the navigate-to-/grain behavior was an intentional new feature of the trash code.

I discovered that through another surprise behavior, which I'll call "Delete one grain, see another one, become confused"

Steps to reproduce:

• Create two new etherpad grains, call them pad1 and pad2, and have them both open in the same Sandstorm window (i.e. both pad1 and pad2 appear in the sidebar), and they both look very very similar given that they are both new documents.
• Click on pad2 in the sidebar to make sure that one is active
• Click the trash icon
• Click OK to say yes I want to move the grain to trash

Expected behavior:

• See something indicating success that I moved pad2 to trash

Actual behavior:

• See a new, fresh, contains-demo-text etherpad document and wonder if pad2 was ever actually deleted
• Slowly realize the grain title is pad1 and that yes, pad2 was deleted
• Note that if both grains were called "Untitled Etherpad Document" I would assume that moving the grain to trash had done nothing.

[paulproteus]

I don't have a strong opinion yet on the @neynah and @zarvox proposals, fwiw. I'm glad people are thinking about solutions and looking forward to seeing mockups/etc.

[paulproteus]

I think I would enjoy it if the grain tab did not go away, but instead the grain tab were reactively replaced by the message that already appears in the grain tab, indicating that the grain is no longer viewable due to being in the trash. That seems very clear to me.

I would also appreciate a link to the trash, and an indication that the grain will eventually be auto-deleted. For context I mean this UI here:

[dwrensha]

Sounds like removing the button from the topbar would also address Asheesh's concerns.

[paulproteus]

I agree with @dwrensha that removing the trash icon from the top bar would address my concerns. I didn't think about that when I filed this issue, but I guess I agree with that statement.

[zarvox]

I feel like I need to push back on some of these ideas.

---

I believe there exist users that will not take the time to learn how to use multiselect. These users should still be able to delete grains, by opening them one-by-one and doing nothing but clicking single buttons. I think it is reasonable that users will expect that they can navigate to a thing and then indicate an action that they wish to take on it, as they probably do with most emails/photos/etc, and as we have supported in the past up until now.

Additionally, dropping the button in the top bar immediately would be a rather jarring change, forcing all users to immediately adjust to the new workflow. Given that the trash button no longer bears the existential risk it used to, and given the above arguments for why it should continue existing, I certainly don't think we need to remove it now. If we think that the upsides of removing it outweigh the downsides, lets do it after we've given users some time to relearn how to delete grains.

I think the trash icon in the menu bar should stay, at least for now, and possibly long-term.

---

I think it is very surprising and undesirable for a user to still be staring at a grain in the trash after they have just placed it there. The intent expressed by the action of deleting is that they do not want to interact with that thing any more and want it to go away. I do not believe anyone benefits from adding additional clicks to that workflow.

I think the behavior of clicking the trash button should involve closing the current view of that thing, so the user can get on to whatever they actually wanted to do. I do agree that there should be something that explains that the grain was moved to trash, and maybe a way to quickly undo that action, but I don't think the answer is "make workflows require more interaction".

[ocdtrekkie]

I agree with Drew FWIW that you still need to be able to delete a grain while in that grain. Though it should be less high level than a top button. I look forward to less used top bar options moving to a dropdown someday soon.

[neynah]

Rough proposal:

• user clicks trash
• sees this confirmation (grain title still visible in the top bar) with some text and 2 buttons: "Move to trash" and "Cancel".
• once they move to trash we can show a success message on this view before we redirect them

Open to other ideas & happy to mock up other suggestions.

[zarvox]

Let's try to be consistent with buttons in forms - default action button is usually the right-most one. Alternate action buttons queue up to the left. Ideally, their tab order is right-to-left, so the default action button is the first one you encounter. If you use:

form.my-form {
  @extend %standard-form
}

<form class="my-form">
  <div class="button-row">
    <button type="submit">Move to trash</button>
    <button type="button">Cancel</button>
  </div>
</form>

...you should get the described behavior.

That said, do we actually still need a modal prompt for a single grain, if we give people an undo button? I'd lean toward not confirming at all, if undo is easy to make work. I might still like confirming aggregate actions on multiple grains, and definitely for things like emptying the trash. There's also an argument that we should use the red danger button for potentially-destructive actions (e.g. usage in the disabling a login provider dialog).

I'd rather the success message not be something that blocks you from making progress at your other tasks while it's visible. If we keep it only in the popup, how long do we leave that success message there before letting them get back to work? If you're a slow reader, how long do you have to hit that Undo button? We're incentivized to make the timeout short so that you can make progress, but we don't want it to be so short that users can't make use of it. A different design would avoid this conflict.

Perhaps we should immediately move on to the next view when the user confirms deletion, whatever that next view is, and for that view to have this (perhaps dismissable?) box floating over it (fixed position?). Then we can pick what we think is an appropriate timeout, and hide the dialog thereafter, and if the user doesn't want to interact with it at all, they can notice that the action was confirmed and get on with using their other grains.