35

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.

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

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.

  • 1
    Good point about the extra wording being a possible hindrance. I hadn't considered that aspect. – maxathousand Apr 16 '18 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 Apr 16 '18 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 Apr 17 '18 at 10:33
  • If only messages can be added to favorites, I think just Added to favorites would be sufficient. Thoughts? – Traxo May 3 '18 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 May 3 '18 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?

  • 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 Apr 16 '18 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.) – Words Like Jared Apr 16 '18 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. – Words Like Jared Apr 16 '18 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. – Words Like Jared Apr 16 '18 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 Apr 16 '18 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.

  • 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 Apr 16 '18 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 Apr 17 '18 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. – gburton Apr 17 '18 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 Apr 17 '18 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 Apr 17 '18 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.

  • And yet there are many programs out there that simply say potrzebie added to widget. – Jeff Zeitlin Apr 16 '18 at 15:26
  • 1
    @JeffZeitlin I'm sorry, I don't understand the point you're raising in this comment. Would you expand? – maxathousand Apr 16 '18 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 Apr 16 '18 at 15:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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