Refresh Is Sacred (tbray.org)

Several Slashdot readers share a blog post: There are two kinds of client applications: The first kind has a "refresh" or "reload" button to make sure your app's in sync with its server's view of the world. The second kind is broken. Of late, I have to deal regularly with several apps, notably including an emailer and car-sharing service, that lack such a button. I can imagine why -- a customer focused product manager said "Steve Jobs taught us that fewer controls are better and we should just take care of making sure we're in sync with the cloud. So lose the button. Except, it doesn't work. Apparently nobody in the world is smart enough to arrange flawlessly reliable hands-off client/cloud synchronization. There are times when you just know that what you're seeing on the screen is wrong and if the stupid app would just assume everything it knows is wrong and ask for a brain transplant from its server, things would be OK.

Comments

Staleness

[Clueless Nick]

What the internet needs, perhaps, is a Staleness indicator.

Re:Staleness

[hord]

It's far more complicated. You have a mobile device that can hop networks which means that connections have to be restarted. Meanwhile there is a drive to optimize network efficiency especially on slow, metered wireless networks. To avoid the overhead of connection hand-shaking apps try to use durable socket connections and aggressive client-side caches. When a networked device disconnects from the network, an error isn't always detected in the application leading to keep-alive protocols increasing bandwidth usage. Cache is an entire realm of disaster with no perfect solution due to the fact that you are wanting to atomically change data across multiple systems with no time delay. Simply not even possible.

All that being said we have techniques for getting around all of this. Many applications simply punt and either use an incomplete wrapper library or write their own incomplete connection/cache handling. I can't even tell you how many Java "Enterprise" applications make you configure connection pools for resources like databases that never restart making applications useless until a service restart. Firewall kills idle connections after an hour? Databases are gone and you can't get them back until a 30-minute Tomcat instance ritual is performed. Does the connection pool have an option for socket keep-alives in the pool config? No. Luckily you can cast a magic spell into some file somewhere where the Oracle can see it. Just my experience, anyway.

Minimal and flat design suck

[houstonbofh]

Studies have shown that minimal design and flat design are worse for productivity and ease of use. But it was trendy and cool. Thank God "Trendy" does not last long. I am starting to see flat design and single page websites fade away... Minimal design will not be far behind. Eventually, we will get to where we were 5 years ago!

Nobody?

[Gravis Zero]

Apparently nobody in the world is smart enough to arrange flawlessly reliable hands-off client/cloud synchronization.

Actually, there a plenty of people smart enough to ensure perfect synchronization. The problem is that not that many are interested in wasting their time on building an "app" that will likely be discarded in a few years for shitty pay. Also, if you aren't using a language that compiles to a natively executable binary then you have failed before even beginning.

What kind of app are we talking about here?

[mysidia]

If it's a web-based application, MAYBE.

If it's a server-to-server or client-to-server app, then a well-designed one will NOT require a refresh button.

Either because clients and servers are well-written AND state changes occur using a well-defined protocol that ensures synchronization
OR because the client automatically refreshes on its own according to some policy.

For example: IRC Clients do not require a refresh button to keep your view of a Chat room and its On-screen userlist accurate after the
initial /NAMES request, because (Non-buggy) IRC servers always send the proper MODE, JOIN, PART, KICK, and QUIT messages
to servers and clients over the TCP channel to keep both sides of the conversation updated with the current information as changes occur.

Also, while the protocol is versatile enough a client could technically re-request information and force a self-Refresh of its view:
you don't see a REFRESH button on any major IRC client, and in fact, the operation would be a major waste of resources.