36

Assume we have a website or mobile app, that has e.g. a list of messages. User can add/delete/edit a message. After making an operation user receives a toast that operation has succeeded.

What's the most appropriate toast message for this scenario?

  1. <entity> was <action>
  2. <entity> has been <action>
  3. <entity> <action>
  4. <action>
  5. Something else

For example, if the <entity> is a "message" and performed <action> was "adding to favorites", the toast could say "Message has been added to favorites". I wonder if there's the conventional way of saying this according to some UI guides. Or I am just being meticulous.

Improve this question
7
  • 43
    "<action>, was the <entity>" is clearly the best choice.
    – MonkeyZeus
    Commented Apr 16, 2018 at 17:33
  • 21
    @MonkeyZeus Sure, if you're designing an interface for Yoda.
    – Cave Johnson
    Commented Apr 16, 2018 at 17:48
  • 5
    @MonkeyZeus "There is no <entity>".
    – msanford
    Commented Apr 16, 2018 at 20:26
  • 5
    @MonkeyZeus Wouldn't that be <action>, the <entity> was?
    – Polygnome
    Commented Apr 17, 2018 at 20:32
  • 4
    @hobbs I usually use bread to make toast, but to each his own.
    – David Starkey
    Commented Apr 17, 2018 at 20:37

4 Answers 4

Reset to default
50

I lean strongly toward concision in communication. Which you choose depends on the rest of your UI.

Without further context, I would suggest option 3, which is the approach we take in our own style guide: simply "Message added to favourites". It provides adequate reinforcement that they completed the desired action on the expected entity.

Adding "was", "has been" does not serve to increase understanding and arguably only adds (albeit marginally in most people) to cognitive load in parsing extra words in the sentence. As someone with a language processing disability myself, I've always found that type of verbiage an unnecessary nuisance.

Improve this answer
6
  • 1
    Good point about the extra wording being a possible hindrance. I hadn't considered that aspect.
    – maxathousand
    Commented Apr 16, 2018 at 15:29
  • @maxathousand Thanks. I'm extra sensitive to it having an LD. Some people find it reinforcing, but I do not. It's why I share it as a personal experience rather than an absolute. It really needs to go in context of the rest of the UI and what the users expect: are they philosophers or software engineers?
    – msanford
    Commented Apr 16, 2018 at 15:33
  • 6
    And this brevity (provided it doesn't lead to ambiguity) seems especially important in a toast message where space is often limited.
    – TripeHound
    Commented Apr 17, 2018 at 10:33
  • If only messages can be added to favorites, I think just Added to favorites would be sufficient. Thoughts?
    – Traxo
    Commented May 3, 2018 at 8:25
  • 1
    @Traxo Definitely. But that's not the case here as OP specifically mentions they have a variable <entity>. If only one type of entity can be acted upon, then the entity name can be dropped. Unless there is value in reinforcing the entity (say, two work contexts look similar and you want to ensure the user understands that they have changed something specific).
    – msanford
    Commented May 3, 2018 at 12:29
15

I respectfully disagree with the other answers. Foo barred parses ambiguously in English: does it mean that the foo was barred or that the foo did the barring? How many possible meanings does settings user deleted have? At least some of the time, writing that tersely will lead to confusion, or crash blossoms, and once you rewrite one case to remove the ambiguity, all your other messages will now be inconsistent. And in a particularly misleading way: if you went out of your way to say that the foo was barred, wouldn’t you have done that to Baz meeped if you meant the baz was meeped, not doing the meeping?

Improve this answer
23
  • 1
    Shoot, you're right. Now I'm doubting my reversal of stance... I guess for this very reason is why I tend to favor slightly more verbose, but unambiguous wording.
    – maxathousand
    Commented Apr 16, 2018 at 18:00
  • 1
    @maxathousand: Sometimes you have to choose between brevity and precision. The correct choice depends on your audience. Communication should be optimized to your audience. When your target audience is "most people" the correct choice is brevity. (While Foo barred is ambiguous, the people most likely to find it ambigous are people who can handle ambiguity.)
    – Jesus is Lord
    Commented Apr 16, 2018 at 18:18
  • 4
    @maxathousand I click "Edit" to edit a user. I edit. I click "Save." A toast appears saying "User saved." Given the context of what just happened, it should be clear I was doing the saving, not the user.
    – Jesus is Lord
    Commented Apr 16, 2018 at 18:55
  • 1
    @maxathousand Case 1 - all toasts are the result of user actions: well the user perfomed the action, so it's clear they caused it. Case 2 - some toasts are not the result of user actions - well maybe always speak in active voice. So "You updated Equipment Control" and "Equipment Control updated X" could be the toasts. Also see my next comment.
    – Jesus is Lord
    Commented Apr 16, 2018 at 20:14
  • 19
    Respectfully, "foo barred" and "settings user deleted" are extremely contrived examples. The phrase OP would have to use is "User settings deleted" (with 'user settings' the entity and 'deleted' the action) in response to clicking the delete button on someone's user settings. That is not ambiguous. With your example, adding words doesn't help parsing: "settings user have been deleted" is no more intelligible, nor is "foo was barred".
    – msanford
    Commented Apr 16, 2018 at 20:14
13
  1. None.

Giving a toast every time an <action> has been successfully performed, is annoying and wasteful of the user's time.

Instead of a toast on success, if there is a failure to perform the <action>, present a useful error message and/or provide corrective steps such as reopening the <entity> for editing.

This is the least disruptive method to lead to the user correcting errors on their part, or let them know that there is a service issue.

The UI should be responsive enough, say, having a list of the <entity> to be changed, the <action> should be obvious to have been performed or not.

Improve this answer
6
  • 4
    A toast is not "an error" so I don't understand where you're going with that line of reasoning. As far as "responsiveness" goes, if the action causes something to vanish from the list, it may not be immediately obvious whether that's because it got deleted, or moved to a different list, or something else entirely. Worse, in a very long list, individual items appearing or disappearing may be hard to see.
    – Kevin
    Commented Apr 16, 2018 at 23:46
  • 4
    Indeed. When users expect application to work reliably, they don't need constant assurance that the application didn't fail. Conversely, if you constantly announce success, you may give impression that it can't be trusted and needs to be verified. Compare experience of plugging in a USB mouse into a Mac (complete silence) with connecting a Bluetooth one (there is a popup indicator). That's because USB one is expected to always work, and Bluetooth is famous for being flaky.
    – Kornel
    Commented Apr 17, 2018 at 1:09
  • 1
    I agree completely. If the user's intent was to cause the <entity> to undergo some <action> and the result was exactly that, then all they need is a big green tick. You can give more detailed feedback if other things have occurred. I've seen a toxic version of this where a modal alert was used thereby adding half a second to every operation for no reason.
    – speciesUnknown
    Commented Apr 17, 2018 at 6:47
  • I don't completely agree with this answer. While it's true that these messages shouldn't be abused, feedback is still extremely important. It may be possible to skip displaying a toast, if, say, a message is deleted, because with the aid of an animation, the effect is pretty obvious to the user. On the other hand, a send confirmation toast could be appropriate imo, although mail clients like Apple's will play a sound as feedback. In op's case, "added to favourites" could be shown with a heart or a similar glyph on the item. But in every case, there is some kind of feedback.
    – Baptiste Candellier
    Commented Apr 17, 2018 at 10:16
  • 1
    I would argue that toast notifications are only needed when it is non-obvious from looking at the UI that an action has succeeded. In the context of the basic CRUD actions referred to by the original question, it should be very obvious whether those actions have succeeded or not. Therefore I don't see the point of toast notifications in this scenario. I agree 100% with this answer.
    – Steven Rands
    Commented Apr 17, 2018 at 10:24
5

<preamble> One of the most important goals of your UI should be to allow the user to perform what they want with as little friction as possible. Effective feedback is a key aspect of this. The UI should be as transparent as possible, clearly showing the user how to perform tasks, what the user is about to do, and what the user has done. </preamble>

Taking these points into consideration, I'd posit that "<entity> has been <action>" or "<entity> was <action>" should be the template for your feedback. Informing the user which entity was acted upon as well as what was done will aid in processing your feedback without requiring the user to recall any information on their own. This is especially useful if your user is on a slow connection and actions may be completed after some time.

Deciding between these two tenses ("was" versus "has been") for your response would be a good question to search for or post over at English Language & Usage.

Improve this answer
3
  • And yet there are many programs out there that simply say potrzebie added to widget.
    – Jeff Zeitlin
    Commented Apr 16, 2018 at 15:26
  • 1
    @JeffZeitlin I'm sorry, I don't understand the point you're raising in this comment. Would you expand?
    – maxathousand
    Commented Apr 16, 2018 at 15:28
  • I don't necessarily disagree with your suggestion that has been or was is a good way of handling it; however, it seems not to be the default - virtually every program that I've seen out there that uses similar messages omits the 'to be' verb in favor of the short form <object> <verb-phrase-past-tense> - e.g., potrzebie added to widget.
    – Jeff Zeitlin
    Commented Apr 16, 2018 at 15:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.