Auto-Refreshing lists is a basic expectation in 2011(teamblog.supportbee.com)
teamblog.supportbee.com
Auto-Refreshing lists is a basic expectation in 2011
http://teamblog.supportbee.com/2011/09/14/auto-refreshing-lists-is-a-basic-expectation-in-2011/
21 comments
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".
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:
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);
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.
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.
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.
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.
Like everything else it should be a cost/benefit decision.
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.
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.
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.
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.
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.
The idea that a page should not be refreshed manually to get the latest information should have been a defacto "Web 2.0" idea.
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.
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.
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.
Does this apply to a Gmail or EC2 console kinda usecase? Going back to a previous version is essentially pointless because the state of your inbox/instances has already changed and that page is stale.
Automatic full page refreshes without much work: <META HTTP-EQUIV="REFRESH" CONTENT="5">
Please don't do this! It loses state, it borks the page when the network connection is lost (laptop closed and opened somewhere else), it interrupts whatever I was doing on the page, ...
That's the 1997 way.
What's wrong with it?