Don't refresh without user interaction
Section 6.7. of the W3C's Web Content Accessibility Guidelines 1.0 (published 5-May-1999 already, mind you) states:
Ensure user control of time-sensitive content changes.
Ensure that moving, blinking, scrolling, or auto-updating objects or pages may be paused or stopped.
Back in the day, that mostly meant not using meta-tags to auto-refresh the page. The reasoning behind this is obvious: You can't know what a user is doing at any one time, so refreshing the page (or any part of it) at an arbitrary point in time is disruptive and disorienting.
Another aspect regarding usability that is equally valid since those days is that unorthodox approaches to refreshing potentially break the browser's history and back button functionality. Implementing any kind of refresh, you need to make sure that you handle history events in an appropriate manner (which you can do via html5 history implementations and respective polyfills).
Load partial views if possible
From a user experience point of view, loading bits of a page seems to be prefered by users, as the slightly lower delay in load times is perceived to have less negative impact. (There's a blog posting on the google research blog with interesting points, and data, see the pdf linked in the article.)
Given these two considerations really the best method seems to be a refresh after user interaction, or "Notification update", as you put it. Furthermore, the position of where items are loaded to (prepending existing items or appending after existing items) depends on the general sorting direction of your content.
Some points to keep in mind with this approach:
- make it easy for the user to keep track of where new items get inserted and how the current visible content gets rearranged (for example the page scroll position on twitter sometimes "jumps" on loading in new items, which disrupts the reading experience)
- show what or how many items were loaded (include a count or new items, or visually highlight what was loaded, at least temporarily - for example until next load; this article about infinite scroll has some good considerations)
- in my view, using the browser back button should reinstate the view before updating, so that if someone accidentally "updates" and gets confused, they can always retreat to hitting back - there are, however, situation where this might not be advisible and you might not want to flood the history with meaningless "update" events - it depends on your data and update frequency, I would say