[Notification/Message] Deciding on a name

[andrico1234]

Naming Notification/Message

Based on the chat at the last Telecon, the next step is to propose a name.

I've suggested a handful of names, and am opening this issue to field other suggestions too. If we can settle on 3-5 prospective names, we can perform some research to see how the greater web community receives them.

Prospective names

Toast

AwesomeRobot: I think the problem is that it’s nearly impossible to guess what it means unless you’ve previously used it in this narrow context within a web framework.

In my eyes, Toast also presumes the element's behavior in the browser. i.e. pop up from the bottom like a hot slice of bread as it ejects from the toaster.

This might be appropriate if we want to be more opinionated over this kind of behaviour, but the case could be made that this falls under appearance.

Message

Proposed by Brian Kardell (@bkardell ): https://www.w3.org/2021/08/26-openui-minutes.html

message could cover a number of aria roles that don't have native HTML counterparts.

e.g. examples of the log, as written in the wai-aria:

Examples include chat logs, messaging history, game log, or an error log.

A name like message may indicate a component whose use-case is broader than I initially expected. I'll need to create another issue to discuss breadth of use-cases.

Notification

This is a complete gut reaction on my part, but Notification feels less focused on the visual behaviour of the element (e.g. like popping up from the bottom of the viewport), and instead focuses more on a purpose:

a time-sensitive, but relatively passive notice for the user, to let the user know of a change in the application's state.

(I don't know where the above statement came from, but it encapsulates what I initially had in mind in terms of this control's behaviour.)

Notice could also work, and would form as a shorter alternative.

Note: The difficult thing about coming up with a name at this point is that an accurate name requires a broad definition of what the component is, and how it should behave. e.g. choosing a name like notification implies time sensitivity (or dismissibilty - defo not a real world), but that name wouldn't be sensible for an element that covers the log role.

Research

Based on this std-toast issue on naming, choosing a name based on existing implementations isn't sufficient.

Survey

We could send out a survey, where the results are less focused on quantitative data (e.g. Choose your favourite name), and more qualitative, (and heavily inspired by Una's workshop), e.g. "You have been tasked with creating an element named , could you create an example usage, and describe some of its core behaviour?".

We could offer the same questions for each proposed name

The benefit of this form of research is that we can see if any specific names have connotations that carry across communities. It can also inform the behaviour we'd want to include.

I'm also happy to try out other forms of research, so please share any ideas you have

Next Steps

• Decide on 3-5 names in this thread
• Add it to the Telecon agenda to confirm that we want to put out the survey with these names
• Send out the survey
• Review results
• Settle on a name

At some point in the next couple of weeks I'll put together a draft for the questionnaire (and even put it out to you folks in the discord channel!).

[gregwhitworth]

Thanks for filing this @andrico1234 - I sent out a tweet to elicit feedback.

When I look through the name matrix I see the following:

• Alert 42%
• Toast 24%
• Notification 18%
• Message 12%

[jonathantneal]

My preference is for message because it’s familiar to me in the context of web technology as well as the English language itself. Merriam-Webster defines message as "a communication in writing, in speech, or by signals". I appreciate that message maps well to my expectations of a toast component without directly signaling its appearance.

I appreciate that message can accurately describe a variety ways I might expect to use it in web development. I find "message" works appropriately in the following sentences:

An alert message may be "special item added" when a special item is added automatically to a user’s cart because they qualified for it at the time they added another particular item.

A status message may be "your cart has 5 items" when a user has added another item to their cart.

[busynest]

Drawer.

[yinonov]

Alert = what it does
Toast = imagery of its appearance
Notification = what it is
Message = what it does

I'd notification on the lead

[busynest]

Serious, it's a "drawer".

Notification drawer.
Alert drawer.
Menu drawer.

[andrico1234]

@yinonov , I totally agree about toast. Message and alert can both be used as a noun and a verb, i.e. I can message someone, or I can send someone a message. It would be interesting how people interpret these names during the research phase.

@busynest thanks for the suggestion, I haven't come across the use of drawer for this UI component before. Do you have an example of a library that uses this naming? if not, could you elaborate about why you'd use drawer over another name like message?

@jonathantneal I think message is a good prospective name, my only concern is whether it's too broad of a name. At this point, it's pure conjecture and I think the results from a survey would be the best way to validate/invalidate my assumption.

[gregwhitworth]

I haven't come across the use of drawer for this UI component before.

Yeah, I haven't seen drawer used for this context either and the 3 UI libs in our system that have a drawer component represent a fixed container that slides out over top of the content upon invocation of other UI such as Material's here.
https://material.io/components/navigation-drawer/web#using-navigation-drawers

So while there may be other libs that use that for showing notifications/messages I don't think we should go in that direction due to the confusion this would cause.

[yinonov]

I would also suggest note, as if thinking on the real life equivalent, it is purely a memo side note politely displayed on our workspace. Thing is, note is already identified as bordered placeholder within articles.

[gregwhitworth]

Ok, so I'm going to do a quick rundown on names that have currently been added because I'd like to add this to the agenda for next week and get a survey out asap. @andrico1234 let me know if I'm missing any:

• Alert
• Toast
• Notification
• Message
• Drawer
• Note

@andrico1234 if you're ok with that list if you can spin up a Google form with those names and "Other" and make sure to make it so there can only be 1 vote per person.

If you want I can either tweet it out from the Open UI twitter account or you can and I'll RT from that account. Just let me know.

[andrico1234]

Thanks for this Greg, looks good to me! I'll get a survey whipped up tomorrow.

I initially had an idea to run a survey to gather more qualitative data:

We could send out a survey, where the results are less focused on quantitative data (e.g. Choose your favourite name), and more qualitative, (and heavily inspired by Una's workshop), e.g. "You have been tasked with creating an element named xyz, could you create an example usage, and describe some of its core behaviour?".

Shall we hold off on this for now, and instead tally for the most popular name?

EDIT: or is that kind of research more appropriate for a stage later than 0?

[Westbrook]

My apologies if I’ve missed it, but what functionally separates this from a <dialog> element?

[chrisdholt]

My apologies if I’ve missed it, but what functionally separates this from a <dialog> element?

To double down on this, are we focusing on what this looks like, common naming among libraries, or are we focusing on what it is? Naming is hard and I’d be curious if it’s been discussed what ARIA role this might fall under and how, if at all that should influence us here. If this is a non-modal dialog, wouldn’t a ‘’ with that role be sufficient? It may not be a dialog, but I do wonder if we should perhaps consider how the name relates beyond what it looks like or is commonly called in design systems.

[andrico1234]

@Westbrook @chrisdholt, thanks folks for jumping on the discussion!

We've got an in-progress proposal here.

In short, we haven't confirmed what the breadth of the component's behaviour is, but it would implement some of the live region roles defined in the aria spec.

@Westbrook based on the aria specs alone, the notification would be a live region, and would signal changes in state but wouldn't interrupt workflow like a modal would. I'm working on a section in the proposal comparing the notification to other elements, but haven't gotten around to finishing it yet.

@chrisdholt as for naming, we discussed earlier in this thread to avoid choosing a name that focuses on the component's appearance, like toast. I'd like to do some research that helps us understand how people could take a name, like message, notification, alert, and map it to a hypothetical component. A survey where each participant could briefly describe the behaviour and interactions they'd expect from each name could provide a lot of insight. It could challenge a lot of assumptions (that I have at least). I'd also love to hear other ideas on how to field this kind of data?

p.s. It's 1am here, and so I'm hoping this makes sense and isn't some hypnogogic gibberish!

[chrisdholt]

In short, we haven't confirmed what the breadth of the component's behaviour is, but it would implement some of the live region roles defined in the aria spec.

I’m tracking @andrico1234 and thanks for responding so late!

I think my primary concern would be going down the component road without really understanding what we are talking about behaviorally. Part of me wonders if we’re a little cart before the horse here and we should hold on discussing a name until we have a clear understanding of what this is. Primarily, if this is in fact a non-modal dialog behaviorally, does it still constitute a component? I think understanding what this is role-wise and what it does behaviorally is key to having the naming conversation - especially if we aren’t in fact focusing on what it looks like (100% approve of this :)).

[yinonov]

I think understanding what this is role-wise and what it does behaviorally is key to having the naming conversation

The live roles this relates to the most are probably alert and status.
It is also what similar UI component often introduce under their hood

[andrico1234]

@chrisdholt It's definitely a chicken/egg situation. I think there's value from performing research at this point to better understand the expectations around each name. Doing so can help us understand which behaviours developers would expect from each element. If we determine which behaviours the spec should implement, we can be better informed around which name to pick (error: circular dependency encountered).

I think you're right in that settling on a name at this point is premature, given that there's still confusion around the what. e.g. is this component solely going to be a convenience wrapper for a subset of live roles, or will it standardise a common notification-style implementation (of which there are dozens).

@Westbrook - I've updated the research doc with a comparison of other components that may be mistaken with what we're proposing here. I've tried to finding resources to back up each statement, but please comment if anything's inaccurate.

[markcellus]

What's been loosely described as "toasts" have always seemed like alerts--just popped up from the bottom of the viewport with a customized appearance (rather than the normal OS appearance).

"Toasts" can also have confirmations, which seems to integrate well with confirms.

Seems like we've already got some precedence here with alerts made available on the window. Is there any chance we could piggy back off of that? Nvm, looks like confirm, alert, and prompts are being deprecated and we've already got a <dialog> component going mentioned in #397 (comment).

I realize the dialog component (in its existing state) interrupts the flow of the UI, but can't that be handled with providing the component different options? For instance, the inertness of the dialog can be made configurable and the dialog's open attribute can be manipulated after a certain amount of time to dismiss it.

[bkardell]

Just a quick note for clarification... the message one is attributed to me due to the minutes, but the minutes are somewhat lossy here. i think what i said was that there was a lot of discussion on the issue and alternatives and some surveying and discussion there, and that from what i could see there, on both points, @aardrian 's suggestion (not mine) of message seemed good to me. I'm pretty sure i also added that i can see arguments why notification is not bad either, but both seem better than toast.

[gregwhitworth]

I think my primary concern would be going down the component road without really understanding what we are talking about behaviorally.

I'm fine with this but there was a general desire to block landing even the research without changing the name from toast. It's always important to understand that we can change this in the future. IMO, based on what I've seen as it relates to what toast/alert/notification (whatever we call it) does not overlap with <dialog>. <dialog> overlaps with a modal IMO with no expectation of having numerous on the screen whereas a toast/notification (whatever) can be stacked up.

As it relates to ARIA, @chrisdholt if there are other names that you think align please raise them. I do think it's also important to note that you can recommend that we adjust <dialog> in some meaningful way to cover this usecase if you do feel it overlaps that much. I have opinions on that but we can discuss it.

[aardrian]

@bkardell

@aardrian 's suggestion (not mine) of message seemed good to me. I'm pretty sure i also added that i can see arguments why notification is not bad either, but both seem better than toast.

It's an honor to be nominated.

FWIW, message has two syllables and notification has five, and I am a fan of whatever is simpler, easier to spell, more likely to translate/localize.

[yinonov]

dialog is pretty far off in that it can contain a more complex content. toast would only display a single unintrosive message. even adding an action will reform it to, what is called, a snackbar, which is timed and interactive

[chrisdholt]

dialog is pretty far off in that it can contain a more complex content. toast would only display a single unintrosive message. even adding an action will reform it to what is called a snackbar, where is timed and interactive

Don’t have time for a longer response to @gregwhitworth right now, but this is key to my line of questioning. Above, it is noted as well that some may have dismiss functionality. If we decide to support interactive content, I believe that drops roles of alert, alert/message dialog which without looking at the spec, I do not believe support interactive content. I’d agree that Dialog is far off only if we agree that toasts do not include interactive content. If they do (as was mentioned somewhere above on dismiss functionality) we primarily are looking at a dialog with regard to supporting that content with the desired semantics and an accurate accessible role - unless we want to ask the ARIA working group to consider changes there.

My argument would be similar to yours in that toasts do not include interactive content - but I think we’ll see varying opinions based on what I’ve seen from design systems over time.

[WickyNilliams]

Having read through this thread and the research doc, it is not clear to me the scope of this element. Is it purely semantics (wrapping up aria-live and role into one element)? Or does it include behaviour/functionality (e.g. some way for user to dismiss) and/or styles (e.g. positioning at a higher z-index than anything else)?

In any case, it is nice to see research underway. Toast/notification is a very commonly requested UI pattern that is so hard to get "right" currently (not actually sure there is a way to get it right as it stands, just opportunities to make it less bad).

[andrico1234]

Thanks everyone for your input so far! I created a new issue focusing on the scope of behaviour. I think a number of us agree that having a definition, even a loose one, is a pre-requisite for picking a name.

[paulshryock]

I like message and notification for this.

[andrico1234]

Based on the resolution of (this issue)[https://github.com//issues/400] the component will be an implementation of the alert role, and it seems appropriate that the preliminary name for this component is alert. Which can change at a later since it's a Stage 0 proposal