

Auto-Refreshing lists is a basic expectation in 2011 - prateekdayal
http://teamblog.supportbee.com/2011/09/14/auto-refreshing-lists-is-a-basic-expectation-in-2011/

======
unwind
I agree. Unfortunately, I think the "basic expectation" aspect means that
users really will _not_ "love it and thank you for it". They'll just go "meh".

------
igorgue
I think that frameworks like Rails or Django are not built to solve this
problem out-of-the-box. Thus if you're not careful enough you'll end up with
some messy ass JavaScript code (and I have seen it everywhere).

Lately though, I've started to build apps using Backbone (I guess you can use
Knockout or Batman too) and Django (or Rails) just to build the API, and it's
very simple to do this.

All you have to do is:

    
    
        // Poll every 10 seconds to keep the channel model up-to-date.
        setInterval(function() {
          channel.fetch();
        }, 10000);
    

At least in Backbone <http://documentcloud.github.com/backbone/#Model-fetch>

~~~
prateekdayal
That's a great approach. I think one issue that can crop up if you do a fetch
and reload the entire listing, some state like checked rows in the table etc
can be lost.

So you have to add some more logic to preserve it. I think that's why it's a
good idea to start thinking about this right at the start of your app/page.

~~~
igorgue
I think you can just bind the "add" event on the collection (I might be wrong)
and fetch wont re-render (since you wont bind the "render all" function) the
whole collection.

------
guelo
Yea that's nice and all but every new feature requires time, adds
complication, needs to be maintained forever, and is a potential source of
bugs.

Like everything else it should be a cost/benefit decision.

~~~
irrelative
I completely agree. What if while implementing this feature, you break the
ability to view the list at all? I bet your users won't thank you for that.

~~~
prateekdayal
I think you are talking about graceful degradation. Not being able to
gracefully degrade cannot be a reason for breaking this expectation. If you
have other well thought out reasons for not doing it, then it is fine.

Gmail is a good example of having this feature and also having a fallback for
people who cannot use js etc. It certainly can be done easily with the
technology (and open source code) available today.

~~~
deno
It can be done somewhat easily for a read-only presentation, assuming certain
degree of discipline on the part of the frontend developer. However, should
you require any complex logic without js and it’s practically inevitable, that
you’ll end up essentially writing not one, but _two_ , separate frontends —
one client-side and one server-side.

To have transparent support for client-side and server-side applications
otherwise, is a rather complex task. The only way to do it _and_ handle any
kind of complexity is to use server-side continuations to _emulate_ client-
side widgets. This means either using an intermediate layer instead of DOM, or
coding to DOM and running against DOM server-side. Using continuations of
course has its own set of issues — the state for each client has to be tracked
and kept server-side (and one client may have several states), and it means
that practically nothing can be cached (everything becomes dynamic). And with
all of that trouble and added complexity, what are the benefits? Do we really
need to support non-js clients to _that_ degree? Not to mention, that there is
practically no web-framework, in mainstream use, that gets it right.

And indeed, the alternative version that Gmail provides is much more
simplistic, and by the way, it does not make any use of graceful
degradation/progressive enhancement — it loads an entirely different Gmail
frontend. I’m willing to bet, that it does not share a single line of code
with the client-side version.

All that progressive enhancement gives you is search-engines visibility. It
_cannot_ be used to provide anything more than that.

------
ericHosick
The idea that a page should not be refreshed manually to get the latest
information should have been a defacto "Web 2.0" idea.

~~~
silon
Along with browser page history. I really get annoyed if I reload while
site/network has a problem and can't go back to previous version.

~~~
wladimir
Oh yes, indeed. Please implement it well or of not don't implement it at all.
Nothing is as annoying as reading an article and having it snap back to the
beginning, or suddenly staring at an error page.

Sure, for console-like applications like EC2 you cannot do without auto-
update. However, on content sites that require longer attention to one piece
of information, it is not necessary.

------
Joakal
Automatic full page refreshes without much work: <META HTTP-EQUIV="REFRESH"
CONTENT="5">

~~~
0x12
That's the 1997 way.

~~~
Joakal
What's wrong with it?

~~~
danielh
It reloads the whole page.

~~~
Joakal
That's what I said. Isn't it relevant for tasks that take a long time to
complete?

~~~
nekgrim
Forcing a reload is never relevant. If it's a very long operation, use a modal
popup, or hide the refreshing part of the page, but you should never force a
reload.

