search

tldraw / tldraw

SDK for creating whiteboards and canvas experiences on the web.
https://tldraw.dev
Other
33.4k stars 1.99k forks source link

ui: make toasts look more toasty #2988

Closed mimecuvalo closed 2 months ago

mimecuvalo commented 3 months ago
Screenshot 2024-03-11 at 14 03 44

Change Type

Release Notes

vercel[bot] commented 3 months ago

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Updated (UTC)
examples ✅ Ready (Inspect) Visit Preview Mar 26, 2024 3:33pm
1 Ignored Deployment | Name | Status | Preview | Updated (UTC) | | :--- | :----- | :------ | :------ | | **tldraw-docs** | ⬜️ Ignored ([Inspect](https://vercel.com/tldraw/tldraw-docs/EAdUVgMbENrv6m7VSUcdMySJh9Mf)) | [Visit Preview](https://tldraw-docs-git-mime-toasts-tldraw.vercel.app) | Mar 26, 2024 3:33pm |
ds300 commented 3 months ago
mimecuvalo commented 3 months ago

love the icons, though i wonder whether we need them for the success/info ones.

yeah, these are MUI icons, they work well! i would disagree that sometimes they're present and sometimes they're not. to keep the visual language consistent across toasts, it should "rhyme" and have the same layout so that people can discern toast severities from each other.

the background colors seem unnecessary to me. The icons and their colors already convey severity well. How do you feel about keeping the bgs white?

i would agree to disagree :) i think it's helpful and they're subtle enough. again, i think it's about conveying result of an action. the subtle application of color here can help signal to the user what happened (maybe without having to actually read the toast hehe)

ds300 commented 3 months ago

i would disagree that sometimes they're present and sometimes they're not. to keep the visual language consistent across toasts, it should "rhyme" and have the same layout so that people can discern toast severities from each other.

I don't think 'rhyming' is as important as distraction in this context.

Most users will look at the icon before the title. In the case of neutral 'info' toasts this is bad because the icon doesn't help them understand what's happened, it actually gets in the way of that by a few milliseconds. I strongly doubt anybody will notice, either consciously or subconsciously, that there was no icon in comparison to the warning/error toasts (which, hopefully, they see extremely rarely if ever).

Of course this assumes there's no separate 'success' toast, which I think is an anti-pattern and certainly to be avoided if possible.

i think it's helpful and they're subtle enough

agree to disagree indeed :D

mimecuvalo commented 3 months ago

I don't think 'rhyming' is as important as distraction in this context.

I hear that — I'll offer a different perspective regarding distraction: toasts/alerts are inherently distracting. Without a visual cue via color, the user is then forced to actually read the text regarding the latest operation taken. However, with a visual cue/iconography the user can 'skip' reading the toast's message because they can assume the operation went well (or not, if the color is warning/error signaling they should investigate what the toast is communicating in more detail)

Most users will look at the icon before the title. In the case of neutral 'info' toasts this is bad because the icon doesn't help them understand what's happened, it actually gets in the way of that by a few milliseconds. I strongly doubt anybody will notice, either consciously or subconsciously, that there was no icon in comparison to the warning/error toasts (which, hopefully, they see extremely rarely if ever).

To be fair, info toasts are pretty rare. It's a convention that exists in perhaps our logging, so I would maybe put aside the info case as it can be not relevant to the general discussion.

I do disagree with the assertion that warning/error toasts are of extreme rarity. One needs only to have a flaky connection to experience a misfired upload of an asset — I'd say it's somewhat common to have errors be presented to the user (thru new fault of our own hopefully!)

Furthermore, to go back to the visual cues of things: hopefully, a user does not see many toasts with errors and such — but the first time that they do encounter such an error in our product, the visual cue serves to call upon a pattern that is familiar to the user, especially when something has gone amiss. So when I say the word "rhyming" I also mean that it rhymes with other UX patterns established in general — these pattern serve to provide stability and confidence to the user.

Of course this assumes there's no separate 'success' toast, which I think is an anti-pattern and certainly to be avoided if possible.

I agreed that we shouldn't have a success toast in our case, it wouldn't make sense. But just to be explicity, I'll say there's a nuance that a success toast would be presented in the case of more dashboard-y type UI (say, in the defunct pro-world, it would have probably made sense in some places). So, I'll just say that having a success toast is not an anti-pattern in general but it is certainly distracting/not useful in our canvas context.

Does this need further discussion offline to move this forward? Happy to keep debating our points either way. As a recap, your requests were:

ds300 commented 3 months ago

I'd be happy for this to proceed if we do the following:

Your point about icons aiding ignore-ability won me over so I don't mind keeping the success/info ones separate as long as 'no icon' remains an option for consumers.

steveruizok commented 3 months ago

Hey, not exactly sure what this PR is addressing. Are our toasts not communicating enough?

Regarding colors: one of the key design constraints for tldraw is to not clash with external branding, hence the limited-but-consistent color palette. I would not want to add color here.

Regarding icons: I'd be fine with using icons to mark severity, though we should stick to the same set that we're using (radix-ui and variants of their icons) for consistency.

Aside from colors, a user achieve could this using the primitives we already provide, right? In general I'd prefer giving little pieces that could be composed to create whatever meaning is needed. An abstraction around severity could be helpful if we allowed users more freedom to style the toasts (e.g. a TldrawUiToast component that would receive this as props).

Looking at where they're used, toasts are pretty rare part of our UI.

We currently show toasts:

When an error occurs:

And when something sudden happens:

mimecuvalo commented 2 months ago

Hey, not exactly sure what this PR is addressing. Are our toasts not communicating enough?

heya @steveruizok , the context was this PR: https://github.com/tldraw/tldraw/pull/2959 and that that gif at the top of @ds300's PR made me sad. 😢

It said "Upload failed" but nothing about the toast communicated anything about an error having happened. It was completely neutral in its visual language and thus reduced the efficacy of the message.

Regarding colors: one of the key design constraints for tldraw is to not clash with external branding, hence the limited-but-consistent color palette. I would not want to add color here.

Makes sense, yes, a fair point. I think we should tease apart whether you mean any color vs. color on iconography or the background color. I think a judicious use of color on the icons, as discussed with David above is helpful.

Regarding icons: I'd be fine with using icons to mark severity, though we should stick to the same set that we're using (radix-ui and variants of their icons) for consistency.

I'd love to stick to radix-ui - I did check before looking elsewhere; however, radix-ui does not have the icons we need.

Aside from colors, a user achieve could this using the primitives we already provide, right? In general I'd prefer giving little pieces that could be composed to create whatever meaning is needed. An abstraction around severity could be helpful if we allowed users more freedom to style the toasts (e.g. a TldrawUiToast component that would receive this as props).

I don't disagree - the way MUI splits this up is two components which we could also do:

and then you compose the two.

Looking at where they're used, toasts are pretty rare part of our UI.

Rare, but needed and useful to get right. It's a paper cut right now and we can be better than how it's currently implemented!

We currently show toasts:

When an error occurs:

when sharing fails because an upload fails (severe?) when sharing fails because a project is too big (severe?) when we can't open a document (severe?) when we can't open a file (severe?) when we can't load a URL preview (severe?) when a copy fails (severe?) when you reach the maximum number of shapes in a project (severe?) when an export fails (severe?)

Just to make sure we're consistent on language here - by severe I think you mean "error", not "severe"

And when something sudden happens: when you move content to a different page (neutral?)

Yeah, that would be an info or I would argue a success one.

We're also missing toasts in a couple places as noted in these bugs:

and those would also be success or info

I'll put time on both your calenders to have a design review since that's the new process we're formulating!

steveruizok commented 2 months ago

Notes from discussion:

Introduce severity property (it's optional) Severity property sets the color of the icon and default icon User provided icon takes precedence (ie other icon or null) No severity = no icon / color

From radix icons, use:

check-circle info-circle triangle-exclamation

mimecuvalo commented 2 months ago

@steveruizok when you get the chance to ✅ this PR

steveruizok commented 2 months ago

Will review, but on a quick check there's a minor alignment issue:

image

image

It may be a case of "when no description is present, add some extra padding", etc.

mimecuvalo commented 2 months ago

Will review, but on a quick check there's a minor alignment issue:

Ahh, this is very interesting actually - David had brought this up above and I didn't know what he was talking about - now I see an underlying issue on why you two were seeing different things than I was.

I usually run yarn dev locally which is the examples app and there we set font-size: 12px on :root. However, when running yarn dev-app to run the dotcom site there is no font-size set on :root. In my tweak of this PR I used 1.2rem for the title to make the alignment work (I had also noticed a misalignment that was a problem before this PR) But my fix only helped fix the examples app and not the dotcom app.

So, two things: