jackbsteinberg/std-toast

Is "toast" the best name for this concept?

domenic opened this issue Β· 11 comments

In #26 and elsewhere folks have wondered whether "toast" is the best name to capture this concept. For example, @aardrian says

toast leans on a visual metaphor. It is meaningless to many users and for others implies or asserts a kind of interaction as necessary.

[...]

Suggest defining toast using the existing roles already specced in ARIA (see #25 ) and naming it based on a word that captures those roles. Which means before proposing a proper name, agreeing on the roles, which means defining the problem as a user need not a developer need.

The repository and element name was chosen based on the work of the study group, which surveys existing libraries and found:

  • 9 toast
  • 2 snackbar (both from Google Material design)
  • 1 alert (although honestly that looks more like a dialog box than a toast to me)

Although ultimately I think @aardrian is right that we need to do a bit more work on the accessibility roles before making any decisions, we should have a place to track this discussion in the meantime.

My take:

First, remember that basically every UI component name, including HTML element names, are a metaphor. A window is something you open and close to let air in, but it is also how we contain programs on desktop computers. A dialog is two people talking, but it also means a pop-up window with some buttons. A carousel is something for people to ride at amusement parks, but is also a way of displaying items sequentially. A menu is a list of food to buy at a restaurant, but also a revealable series of clickable options that execute actions. A toast is a piece of bread, but also an unobtrusive feedback notification.

Second, remember that names are web developer facing, not user facing. They are meant to communicate things to web developers choosing what control to use, and web developers later reading the code. Although not every web developer is familiar with toasts, instead it being mostly the province of UI developers or developers that use design systems, the ecosystem evidence enumerated in the OP indicates that for those that are familiar, "toast" is the name that they would recognize. Picking a new name would need to be done with caution not to cause a break with the existing ecosystem. (Material UI did this, by choosing "snackbar", and it seems to cause some confusion.)

With this in mind, one path we should consider is doing "user" (i.e. developer) research. We've already done that passively, by looking at popular libraries, with the results enumerated in the OP. We could also do it actively, e.g. with a survey that demonstrates the unnamed UI pattern in action, and asking developers what name describes it best.

I'd like to add a +1 for reconsidering the name of this element.

I sometimes worry that the web community has gotten too carried away with finding "clever" names for things -- e.g. every operation in "homebrew" being related to beer. That might just be my preference, but I think there's some validity to the notion that if you're introducing something that could exist in a spec for 20+ years, it should have a timeless name.

Your point about "windows" is well taken, but the form and function of a "window" in an OS or application is analogous to a real window: it is shaped the same (more or less) and provides a viewport of a single application or aspect of that application. It's not just a completely arbitrary name. I could make the same argument for a dialog box (a message between the user and application) and a carousel (the word carousel is also used for things like luggage carousels at the airport, not just an amusement park ride).

I like your last proposed approach (asking developers what name describes the UI pattern best) rather than passively looking at what other libraries are currently calling it. I suspect that a survey asking which name describes the UI pattern best would yield very different results from one that asks developers what they currently call it or whether they like the name "toast". The latter two approaches would almost certainly load the deck in favor of "toast".

<message>

It covers all the defined ARIA roles (see #25: alert, log, marquee, status, timer), does not anchor on the interaction.

I would suggest <notification>.

That's fundamentally what it is isn't it? A notification element?

@Dan503

That's fundamentally what it is isn't it? A notification element?

Meh? Not sure notification corresponds with the log and marquee roles.

Though I am mostly interested in avoiding toast given how few people who do not live in frameworks seemed to know what it was (anecdotal, based on Twitter reactions I saw).

I agree a better name should be considered.

I make my toast on a pan with butter so toast makes absolutely no sense to me, unless it emits smoke and progressively gets burnt.

Meh? Not sure notification corresponds with the log and marquee roles.

I'm not convinced that adhering to the 'marquee' role is something toast should worry about (I know that discussion is ongoing). It might be worth thinking about a toast as a single entry in a log though.

I am not opposed to excluding marquee, but this proposal has not been so thoroughly specc'd that I think it excludes marquee.

A little look at a thesaurus and a couple of English dictionaries and I'd like to propose <notice>. Shorter than <notification>, it also has the "sense" of being able to ignore it (which is what I tend to do with Google's Gmail toasts) but it also makes me realise (or notice) that the thing has happened (email is sent, I can undo).

The repository and element name was chosen based on the work of the study group, which surveys existing libraries and found:

  • 9 toast
  • 2 snackbar (both from Google Material design)
  • 1 alert (although honestly that looks more like a dialog box than a toast to me)

[...snip]

With this in mind, one path we should consider is doing "user" (i.e. developer) research. We've already done that passively, by looking at popular libraries, with the results enumerated in the OP.

I don't think that the study group is a good place to look for naming. Not because it's a bad study group per se, but because of the specific reference libraries chosen. Half of the reference libraries have "toast" in the name. Searching for things called "toast" and then noting that they mostly use the name "toast" looks to me like confirmation bias. (Although I was looking for confirmation bias to begin with, so there are extra layers of it now. πŸ˜‰)

An alternative source of research is public design systems from various companies. Yes, there are going to be examples of "we named it this way because some other company's design system did", but it still gives a different picture of what this UI pattern is called.

I've trawled through the many, many design systems currently listed at http://styleguides.io/examples and https://github.com/alexpate/awesome-design-systems

Most of them don't have a matching UI pattern, but these are the results of naming choices for those that do. Other than a couple of exceptions, they all use the terms "alert", "message", "notification", and "toast"β€”often in combinations.

There is a wide spectrum of behaviour and nomenclature, and (to my eyes) a definite blurring of the lines of what makes something a "toast" notification versus some other kind of notification. An especially interesting case here is Salesforce's Lightning Design System, which has both "toast" and "notification" components, but the "notification" looks and behaves more like this proposal than the "toast" does. Alibaba similarly has multiple components which could fit the definition of the pattern.

Ruby on Rails has an inbuilt mechanism for adding "flash messages" to a page. The styling/behaviour is up to the implementor, but they are intended to be transient messages that only appear once after an action. Therefore a generation of developers who started with RoR will know this pattern as "flash messages" or "flash notifications".

Additionally, a small number of pages linked above mention Growl. Growl was the standard way of showing a temporary notification on Macs, before OS X implemented their own standardised system. Although it was the name of a specific piece of software, the term "growl" became synonymous with this type of pattern. A quick search for "js growl" shows many more JS libraries implementing this pattern, without ever calling it a "toast".

And finally, macOS always calls these notifications, as they appear in the "Notification Center".

In summary, "toast" is most definitely not the universal term it's portrayed to be in this proposal.

I just want to thank @gilmoreorless for putting in the elbow grease to do that survey of design systems! Very cool. (I found it via this article.)