Why leave read notifications in an inbox?

Question

I am making a website with the primary purpose of creating content (specifically, arguments consisting of interlinked statements), very similar in approach to Stack Exchange. Currently, I am implementing a notification system to notify users of content they contributed to or are interested in.

At first, I thought to copy the design of Stack Exchange: the amount of unread notifications show up in an overlay on the inbox icon, and opening the inbox marks all notifications as read, yet they remain in the inbox indefinitely. However, I expect a great deal more flux in edits made to arguments: statements will be edited regularly, commented on, and moved around. The primary reason to notify users is to keep them up to date with how the argument is evolving (since they have expressed an interest in it). But, essentially, notifications might rapidly become outdated.

For unread notifications the choice is easy: at any time, remove notifications which are no longer relevant. E.g., a comment which was added and subsequently removed.

However, what to do with read notifications ('read' being similar to Stack Exchange, meaning the notification list has been opened)?

• What use cases are there to visit the history of notifications?
• Does Stack Exchange remove notification history to content which is no longer available (e.g., comments, questions, or answers)?

Given that notifications on my site could essentially be considered 'to-do' items, I am inclined to remove them when they become irrelevant, even when they have been read. Similarly, I am considering a 'dismiss' or 'remove' option which removes notifications from the list entirely. Obviously, this can easily be expanded with 'dismiss all' or 'dismiss all' for a particular argument.

• Does it make sense to encourage users to keep their inbox empty?
• Do you know of any websites/systems with a similar design/intent I could draw inspiration from?
• Any specific mechanisms how I can convey this 'optimal' (if it is) use of the inbox? As in, teach them to dismiss notifications they have 'handled'.

Answer 1

I think there is more to what you describe here than just notifications and it really depends on what is the interaction you are designing for, imo:

To start first from notifications you proposed: * stackoverflow's nature of interaction is not the same to what you are modelling. The notifications here are important but mostly when someone answers my question and/or comments on my question / answer. That is 'important' interaction. * Use case for notifications in your system I see being important only to draw my attention that there has been an activity on the arguments I contributed to. Notification them selves are ephemeral it's the activity behind it that I need to pay attention too.

I mean the real question is what is user expected to do once he is notified. This is driven by the nature of change that she is being notified of, and what is follow up action. This is where this interaction becomes two directional (as opposed to question-answer style of stackoverflow).

In a lot of cases I need notification as interaction behind it requires me to respond:

• Do I need to respond to the argument (comment)?
• Has someone proposed a change to my original argument that I need to approve?
• ...

All these are to-do items (Collaboration on Google Docs first comes to mind, even though these are not 'grouped' as to-do items they need to be marked 'Done'). If I'm done with a task I don't need a notification lingering anywhere, and maybe not even that to-do that I've done. I might need to be able to see the history of changes, i.e. activity log.

Some notifications might be less important to me: - Has some used my argument and linked to it? This might not be notification worthy at all. Unless it is changing my User 'carma' where this can be a temporary badge over my avatar next time I log in.

Not sure it this helps at all...

Answer 2

As I see it, the primary reason to have a history of notifications/inbox/whatever is: Oops, I marked this as read too soon.

If mark as read is implicit like it is on Stack Exchange (you close the popup) then just misclicking is sufficient to have this problem. Another possibility is that someone in fact clicked through and read the thing the notification is about, and moved on, and — immediately or hours later — thought "er, wait…".

I would suggest that the notifications which have been read should stick around as originally presented. The user may remember the shape of the list and when trying to recall think in terms of "it was the one just before the one about dogs", say, so it's important that the sequence of items does not change. (But things like the title of a page that is linked in the notification could reasonably be shown as their current state instead.)

You might or might not remove old read notifications at some time, but they should stick around for at least a day and probably much more, to allow users to come back at a more convenient time.