Slashdot Mirror
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.
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!
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.