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

Notifications are annoying #133

Closed
dstillman opened this issue Mar 20, 2018 · 9 comments
Closed

Notifications are annoying #133

dstillman opened this issue Mar 20, 2018 · 9 comments
Assignees
Labels

Comments

@dstillman
Copy link
Member

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:

notification

And then having them auto-dismiss on the next state change (or click, even, if things like opening the editor don't change state).

@flachware
Copy link
Contributor

@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.

@dstillman
Copy link
Member Author

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 static/fixed (but that one works less well with auto-dismissal, because you don't want UI elements shifting while trying to click on them).

tnajdek added a commit that referenced this issue Mar 20, 2018
* Add unique identifier for each message so that react can correctly
  identifiy them
flachware added a commit that referenced this issue Mar 20, 2018
@flachware
Copy link
Contributor

@dstillman have a look now – I think I found a very elegant solution.

@dstillman
Copy link
Member Author

dstillman commented Mar 23, 2018

Ah, yeah, sticky is nice. We still have to close notifications when opening a modal, though:

notifcation-modal

@flachware
Copy link
Contributor

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.

@dstillman
Copy link
Member Author

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.

@flachware
Copy link
Contributor

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.

@tnajdek
Copy link
Member

tnajdek commented Mar 26, 2018

Let's track the sticky polyfill as a separate issue: #154

@dstillman @flachware Can we close this one?

@flachware
Copy link
Contributor

@tnajdek fine with me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

3 participants