-
Notifications
You must be signed in to change notification settings - Fork 19
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
Notifications are annoying #133
Comments
@tnajdek I think this is a regression, the undo messages should auto-dismiss after 5s. @dstillman please reevaluate if the messages are still annoying once they auto-dismiss. If the undo text will be Item Deleted [ Undo ] we could specifically optimize the layout of undo messages, but trying to not overlap the logo won’t work for all messages in general (mobiles), as we have a generic layout for messages with changeable texts. |
The most common use of this will likely be errors while trying to add items (offline, network failure, translation server error), and when a one-line notification appears while scrolled to top on desktop it results in the "by Zotero" peeking out from the bottom of the notification, which looks bad. That's the main thing I'd like to address, and it wouldn't be fixed by auto-dismissal. As nice as the messaging system is, I don't think being able to show more than one message is really a requirement, and I think automatically closing an open notification when another one appears would generally be better anyway. So if we get rid of that, we only need a solution that avoids the problem when scrolled to top with a single notification, whether that's moving the logo up, shrinking the notifications, or doing something more dynamic with |
* Add unique identifier for each message so that react can correctly identifiy them
@dstillman have a look now – I think I found a very elegant solution. |
I’m in love with sticky. @tnajdek I think we need something like https://github.com/wilddeer/stickyfill to make the sticky positioning work in older browsers. @dstillman we put the notifications on top of the modals on purpose, because we assumed that we need to be able to show error messages caused by actions in the modal. If we dislike the look or feel like it is a usability issue (it can cover the modal header, at least temporarily), we could have messages in the modal. It is a nice thing though to only have one approach for messages. |
I'm just saying we should close existing notifications when we open a modal, not that we shouldn't show new notifications if a modal is open. It's just weird for a modal to pop up under an existing notification. |
Ok, I misunderstood that – makes sense to me, I guess once the user opens the editor modal it’s alright to discard the welcome message. |
Let's track the sticky polyfill as a separate issue: #154 @dstillman @flachware Can we close this one? |
@tnajdek fine with me. |
Follow-up to #115
I think we need a better solution for notifications. They cover the logo in a pretty unpleasant fashion whenever they appear, and as far as I can tell they also require manual dismissal. You shouldn't have to manually dismiss the notification every time you delete an entry.
An easy fix would be something like this:
And then having them auto-dismiss on the next state change (or click, even, if things like opening the editor don't change state).
The text was updated successfully, but these errors were encountered: