Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Replace OC.Notification with toastify js #15124

Merged
merged 3 commits into from
Jun 7, 2019
Merged

Replace OC.Notification with toastify js #15124

merged 3 commits into from
Jun 7, 2019

Conversation

juliushaertl
Copy link
Member

@juliushaertl juliushaertl commented Apr 16, 2019

This is a PoC pull request for #13423 to make error messages that are sent though OC.Notification more obvious and visually appealing.

image

Feedback is welcome @nextcloud/designers

Note that the current OC.Notification.show OC.Notification.showTemporary continue to work, but the toastify lib adds additional types (error,warning,success,info) to give a visual hint about the type of message.

ToDo as from #13423:

  • Every notification needs to be dismissable
  • Move the toast to the top right

@juliushaertl juliushaertl added design Design, UI, UX, etc. 3. to review Waiting for reviews labels Apr 16, 2019
@juliushaertl juliushaertl added 2. developing Work in progress and removed 3. to review Waiting for reviews labels Apr 16, 2019
@rullzer
Copy link
Member

rullzer commented Apr 16, 2019

So the design team has to decide of course. But I'm not 100% convinced having it on the bottom is the best. All our notifications etc are on the top so that is where people look. Maybe adding it just blow the header makes more sense?

@rullzer
Copy link
Member

rullzer commented Apr 16, 2019

Of course visually this looks a lot better than the 1990 style we had before.

@stefan-niedermann
Copy link
Member

I think it is hard to distinguish from the other content. Maybe use a contrast color (white on dark background on normal, and dark on white background on dark theme)?

@MorrisJobke
Copy link
Member

So the design team has to decide of course. But I'm not 100% convinced having it on the bottom is the best. All our notifications etc are on the top so that is where people look. Maybe adding it just blow the header makes more sense?

See the last open checkbox ;) It should be moved to the top right.

@juliushaertl
Copy link
Member Author

I think it is hard to distinguish from the other content. Maybe use a contrast color (white on dark background on normal, and dark on white background on dark theme)?

A full colored background is a bit to much I think, but I've increased the box shadow visibility a bit (see the updated screenshot in the first post)

So the design team has to decide of course. But I'm not 100% convinced having it on the bottom is the best. All our notifications etc are on the top so that is where people look. Maybe adding it just blow the header makes more sense?

Done 😉

@juliushaertl juliushaertl force-pushed the enhancement/toast branch 2 times, most recently from 8ca1804 to 348e589 Compare April 16, 2019 13:38
@jancborchardt
Copy link
Member

Top right is indeed much better, that’s where all the "meta / organizational" stuff is. :)

And it looks really really nice! Props @juliushaertl! The only thing I can find is that the x icon is not our .icon-close icon – any reason for that?

@juliushaertl
Copy link
Member Author

And it looks really really nice! Props @juliushaertl! The only thing I can find is that the x icon is not our .icon-close icon – any reason for that?

No reason, I can adjust that as well.

@juliushaertl
Copy link
Member Author

@jancborchardt Thanks for the hint, pushed with the proper close icon
image

@juliushaertl juliushaertl added 3. to review Waiting for reviews and removed 2. developing Work in progress labels Apr 16, 2019
Copy link
Member

@skjnldsv skjnldsv left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Having the mouse over the notification should prevent it from disappearing I think. If you're reading something long and it disappear, you're confused :)

@juliushaertl
Copy link
Member Author

Having the mouse over the notification should prevent it from disappearing I think. If you're reading something long and it disappear, you're confused :)

I'll see, but we probably need to fix that upstream.

@BrookeDot
Copy link
Member

Having the mouse over the notification should prevent it from disappearing I think. If you're reading something long and it disappear, you're confused :)

I agree, I struggle from a bit of dyslexia and often find myself highlighting text to help me read it and sometimes reading takes a bit longer than "average". Having a notification disappear while reading it can be quite frustrating. Especially if there's not an easy way to get it back.

I'll see, but we probably need to fix that upstream.

I have opened up apvarun/toastify-js#21 upstream so we'll see if this feature can get added. If not, perhaps I can recommend not setting the timeout at all.

@skjnldsv
Copy link
Member

@BrookeDot Thanks a lot for that! 🚀

@skjnldsv
Copy link
Member

I have opened up apvarun/toastify-js#21 upstream so we'll see if this feature can get added. If not, perhaps I can recommend not setting the timeout at all.

Opened PR: apvarun/toastify-js#22

@karlitschek
Copy link
Member

I like it. Looks more modern

@juliushaertl
Copy link
Member Author

Do we really need that this often?
In most cases it is called to avoid that an old notification is hiding the one that should be added.

I would also be happy with just ignoring the hide method and have a default timeout of 30s for notifications that were called without a timeout though the legacy API.
Anything that speaks against this @nextcloud/designers ?

@jancborchardt
Copy link
Member

I would also be happy with just ignoring the hide method and have a default timeout of 30s for notifications that were called without a timeout though the legacy API.
Anything that speaks against this @nextcloud/designers ?

Just to clarify: This issue does not happen when using this new notification API?

Cause a defaut timeout for notifications has a big issue in that people don’t necessarily check the screen or tab all the time, and they might miss a notification. Also, do these notifications have a close button so you can close them before the 30s?

@juliushaertl
Copy link
Member Author

Just to clarify: This issue does not happen when using this new notification API?

The new API has a default timeout as I would consider those notifications to be more temporary than permanent.

Cause a defaut timeout for notifications has a big issue in that people don’t necessarily check the screen or tab all the time, and they might miss a notification. Also, do these notifications have a close button so you can close them before the 30s?

I have now also rebuild the old OC.Notifiation.hide() method, so the behavior on the old API should be complete. The only thing that has changed is the fallback if no notification to hide was provided. In that case we do nothing now, as there was a warning logged for quite some time and just removing the first notification doesn't seem to be a good fallback to me.

Let's see if the tests are happy.

@juliushaertl juliushaertl added 3. to review Waiting for reviews and removed 2. developing Work in progress labels Jun 5, 2019
@juliushaertl
Copy link
Member Author

🎉 Tests are happy again. @skjnldsv @ChristophWurst Mind to have another look?

@skjnldsv
Copy link
Member

skjnldsv commented Jun 6, 2019

Looks all good to me :D
Rebase, sign and squash! 🚀

@skjnldsv skjnldsv added 4. to release Ready to be released and/or waiting for tests to finish and removed 3. to review Waiting for reviews labels Jun 6, 2019
Signed-off-by: Julius Härtl <jus@bitgrid.net>
Signed-off-by: Julius Härtl <jus@bitgrid.net>
Signed-off-by: Julius Härtl <jus@bitgrid.net>
@juliushaertl
Copy link
Member Author

Rebase, sign and squash!

Done 🚢

@danxuliu
Copy link
Member

@juliushaertl There is a mismatch in the options received by OC.Notification and OCP.Toast: OC.Notification uses isHTML, while OCP.Toast uses showHtml. Either OCP.Toast.message is adjusted to use isHTML too, or OC.Notification.showTemporary is adjusted to set options.showHtml based on options.isHTML (and also the unit tests to reflect that OC.Toast.message expects showHtml instead of isHTML).

@LinneyS
Copy link

LinneyS commented Sep 27, 2019

If you scroll down the page, the message is not visible under the header

@ChristophWurst
Copy link
Member

If you scroll down the page, the message is not visible under the header

Please open a new ticket.

@skjnldsv
Copy link
Member

skjnldsv commented Sep 27, 2019

Should be fixed already #17110
edit: we forgot to backport

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
4. to release Ready to be released and/or waiting for tests to finish design Design, UI, UX, etc. enhancement
Projects
None yet
Development

Successfully merging this pull request may close these issues.