Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
IT Technology

Refresh Is Sacred (tbray.org) 193

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.
This discussion has been archived. No new comments can be posted.

Refresh Is Sacred

Comments Filter:
  • by Anonymous Coward

    In India cows are also sacred. You sacred cows! Moo! Moo! Refreshed moo!

  • by DontBeAMoran ( 4843879 ) on Thursday September 28, 2017 @09:47AM (#55269329)

    Some applications have started using a "scroll past the top to refresh" crap and if you don't know the application can do that, then you don't know it has the feature in the first place.

    • by TWX ( 665546 ) on Thursday September 28, 2017 @09:51AM (#55269369)

      On a full-featured PC I would agree, but on something with a small screen where every function takes up an inordinate amount of that screen (ie a smartphone that has a UI large enough that a human finger can use) it makes sense to use a model that lacks a dedicated button for the function.

      Like everything it's a compromise. Google's gmail application on Android uses this kind of refresh and it wasn't exactly difficult to accidentally trigger the first time and then subsequently continue using when it became apparent.

      • by Luthair ( 847766 ) on Thursday September 28, 2017 @09:57AM (#55269401)
        This was why we had a menu button, until some UX circle-jerk decided that was too complicated.
        • by houstonbofh ( 602064 ) on Thursday September 28, 2017 @10:14AM (#55269545)
          They keep turning high powered multi-monitor computers into phones. I hate that my tablet keeps redirecting to the mobile site... On a 10 inch screen!
          • What serious sites still have a "mobile version" these days with responsive design?

            Slashdot you'll tell me? I said "serious sites" fella...
            • by JohnFen ( 1641097 ) on Thursday September 28, 2017 @10:45AM (#55269819)

              What serious sites still have a "mobile version" these days with responsive design?

              Not enough, unfortunately. "Mobile versions" of sites aren't great, but responsive design is far, far more irritating to me.

              I really wish that sites would do one of two things: stop basing the "responsiveness" on the window dimensions, or give some sort of "lock" control to freeze the current layout.

              • by AmiMoJo ( 196126 )

                Slashdot is one of the worst. Terrible mobile site, and the desktop site gets squashed because of the stupid ad.

                • Slashdot is one of the worst. Terrible mobile site, and the desktop site gets squashed because of the stupid ad.

                  +1. Kill Sticky is probably the main reason I'm still using Firefox. Do other browsers have similar extensions available for them?

              • by d0rp ( 888607 )

                I really wish that sites would do one of two things: stop basing the "responsiveness" on the window dimensions

                What would you base the responsiveness on if not the size available to the website? The whole point is to make it adjust the interface to take advantage on the available space (or lack thereof) across any range of devices using not just the pixel dimensions, but the physical size of the screen (i.e. is it a high-resolution screen on a smartphone which need to have buttons big enough to be used by fingers)

                or give some sort of "lock" control to freeze the current layout.

                This is an interesting idea, but I'm not sure exactly what you mean, can you elaborate with an example?

                • What would you base the responsiveness on if not the size available to the website?

                  I don't know, as this is a technical problem that I'm not interested in solving. All I know is that the way responsive sites work right now are a constant problem for me, because they rearrange (or even worse, remove) page elements when I resize the window on a desktop. It is often the case that I intentionally resize windows to just show a specific part of a page, and responsiveness really interferes with that.

                  I'm not sure exactly what you mean, can you elaborate with an example?

                  I'm not sure how I can explain it any more clearly, but here goes: if the page is "locked", then

                • by SQLGuru ( 980662 )

                  The biggest problem isn't that things resize or move around. It's when things are hidden on smaller screens. It's usually not clear how to get that functionality back in the smaller footprint.

                  For instance in Bootstrap, hidden-xs on an info box with a short-cut, but that short-cut doesn't appear on a menu. The only way to get to it might be three clicks through "Item" screens to get to the same stuff. The designers do ok with the VISUAL aspects of responsive design, but they do a poor job of the FUNCTION

                  • The biggest problem isn't that things resize or move around. It's when things are hidden on smaller screens.

                    I agree, although on the desktop (where we're talking about a window rather than a screen), things moving around is an equally large problem.

            • Depends on your definition of serious. Cardhaus.com comes to mind. I think of it as a serious site since the only site I've spent more money on is Amazon.com.

          • I hate that too.
            The browser on iOS is actually quite good.
            I insist to get the desktop site.

        • by bondsbw ( 888959 )

          I'm not sure why you think tapping a menu button and then moving to the Refresh menu option is easier to use.

          More discoverable, sure. But only because people have figured out to tap on some specific word or icon...

    • I would also add that you never really know if the update took place in most apps. There should be some kind of notification that says "update successful" upon return code 200
    • This particular case, if you read the blog, sounds like a deliberate oversight intended to fool users into thinking the app is more popular than it is. A refresh function would probably make the service look worse, not better.

      It's very common to see apparent UX "bugs" and glaring shortcomings that have a legitimate business case behind them. I think Netflix owns the patent on this brand of bullshit.

  • by msauve ( 701917 ) on Thursday September 28, 2017 @09:48AM (#55269343)
    and Don Norman, who has something to say on the matter. [jnd.org]
    • Re: (Score:2, Insightful)

      by Anonymous Coward

      Tog's a great guy and all but the single worst thing he did to the web was to convince everyone to kill the ComboBox, leaving everyone to reimplement it in javascript, shittily.

  • Staleness (Score:4, Interesting)

    by Clueless Nick ( 883532 ) on Thursday September 28, 2017 @09:49AM (#55269351) Journal

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

    • Comment removed based on user account deletion
      • The problem with the expires header (or any HTTP header) is that it needs to be requested from the client side.

        Right now your browser will not display this comment exactly when it appears unless:
        a) You refresh right as I post
        b) Slashdot implements an autorefresh that refreshes right as I post (which it only does on the front page)
        c) A metric fukton of non-standard javascript and open connections in the background handles push updates.

    • Re:Staleness (Score:5, Interesting)

      by hord ( 5016115 ) <jhord@carbon.cc> on Thursday September 28, 2017 @10:35AM (#55269717)

      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.

    • I'm not sure what problem that would solve. For a busy site like this one, push notifications would be somewhat pointless because it changes so frequently that you'll see updates for every refresh. For sites that aren't busy, the occasional refresh isn't a big deal if they have a reasonable cache setup.

  • Kill-and-Restart is the new refresh.

    • Yes, that's what I also do when I want to get the latest content in an app. But how annoying is it! A refresh button in a menu and an indication that the refresh was successful should be the way to go.
  • by houstonbofh ( 602064 ) on Thursday September 28, 2017 @09:55AM (#55269383)
    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!
    • Please tell me when Gnome3 will die. Even Microsoft fairly quickly backpedaled with Metro, while Gnome junk is still being switched to rather than from.

      • Please tell me when Gnome3 will die. Even Microsoft fairly quickly backpedaled with Metro, while Gnome junk is still being switched to rather than from.

        You mean like Gnome Panel/Flashback? https://en.wikipedia.org/wiki/... [wikipedia.org] If more people use this over Cinnamon / Mate, the Gnome Project will see it and respond. Or at least better support it, which is all I care about. As long as my shit works, I am OK.

        • There's far more wrong with Gnome than just the panel.

          • I use Gnome Flashback with Metacity, and it is quite good. Almost the same as Gnome 2. (Just a few regressions, and many taskbar applets are gone) However, the Gnome project is a dumpster fire far too often... But the other DEs are worse for my workflow.
    • The worst part about single-page websites is the damn "multiple backgrounds but you only see a slice of it while scrolling" crap. That kind of shit is so heavy of my old computer and slow internet connection that it negates the fact that it's a single page by about one thousand to one.

    • But it was trendy and cool.

      Trendy, yes -- but "trendy" rarely means "good". And it was never cool.

      • But it was trendy and cool.

        Trendy, yes -- but "trendy" rarely means "good". And it was never cool.

        It was cool to some... Yes, they were hipster art students in web design, but still... :)

        And I am glad it is going away! Slowly...

    • > Eventually, we will get to where we were 5 years ago!

      I'd like to go further back, honestly. You don't need all the crap that goes into most web pages today.

      There's nothing wrong with a title bar, a side menu bar, and buttons that look like buttons. I'm even somewhat nostalgic for frames, but I'm sure there are technical reasons why it's better to handle that functionality in other ways.

      I think at some point we collectively decided the average MySpace page was on the right track, and we took that turd

    • by DogDude ( 805747 )
      How the fuck does "flat design" effect productivity? Does it hurt your delicate eyeballs and then make you too sad to get shit done, or something like that?
      • by fisted ( 2295862 )

        The issue are controls that aren't immediately recognizable as controls.

        I don't think it has anything to do with hurting delicate eyeballs.

        Oh and you may want to learn how to spell "affect".

      • How the fuck does "flat design" effect productivity?

        Flat design makes it difficult to spot the things on the screen that I need to spot.

  • by Anonymous Coward on Thursday September 28, 2017 @09:55AM (#55269393)

    I don't even bother using Firefox's refresh button, it doesn't actually request the page a second time. CTRL-F5 is now the default refresh.

  • As time progresses these systems trend toward getting more reliable. I am sure a lot of you don't remember the good old days, where we needed the PC power button to be directly tied to the system power supply, early systems which had the power going threw the mother board to request a clean shutdown, often had problems where the OS was so locked up that such button was useless, and you had to unplug the system to get it to work. A standard windows setup was expected to crash at least once a week. (And a

    • As time progresses these systems trend toward getting more reliable. I am sure a lot of you don't remember the good old days, where we needed the PC power button to be directly tied to the system power supply, early systems which had the power going threw the mother board to request a clean shutdown, often had problems where the OS was so locked up that such button was useless, and you had to unplug the system to get it to work.

      I still miss the days when the power switch was a fucking SWITCH! There are times when press and hold still does not work!

    • Automatic updates don't remove the need to inform the user of the current application state.

      The user needs to know when was the last time that the content was updated; if the page becomes stalled (i.e. the time since last update is longer than expected), this might be because no new content has been created, but also because somewhere in the system there has been a hiccup that prevented an automatic refresh. No matter how reliable you make the system, there will always be delays, and some users will get the

      • Unless the data automatically refreshes when the data gets updated. It takes more work but it can be done with current browser technology.

  • Nobody? (Score:4, Interesting)

    by Gravis Zero ( 934156 ) on Thursday September 28, 2017 @10:07AM (#55269457)

    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.

    • by Bozzio ( 183974 )

      Also, if you aren't using a language that compiles to a natively executable binary then you have failed before even beginning.

      You're either showing your age, your dogmatism, or your ignorance.

      Or, prove me wrong and explain what you mean.

      • You don't build on sand because it has a tendency to shift.

        • by Bozzio ( 183974 )

          Again, please explain. What, exactly, is the problem with languages that don't compile to native binaries?

          What about languages that typically use runtimes but have options to build to a native binary anyway?

    • Do people even want cloud synchronization? It's the first thing I turn off.

  • by mysidia ( 191772 ) on Thursday September 28, 2017 @10:08AM (#55269471)

    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.

    • you don't see a REFRESH button on any major IRC client, and in fact, the operation would be a major waste of resources.

      A well-implemented refresh in that context shouldn't re-request the whole view if no new content has been published. It shouldn't be heavier than a Ping which returned the last time the content was updated, confirming that the client is up-to-date.

    • by AuMatar ( 183847 )

      Everything is web based these days. The number of apps that keep a persistent TCP socket to the server are extremely limited. And web based more or less means stateless by default. So there's plenty of opportunity for an app to get stale data, miss data, etc.

    • by sl3xd ( 111641 )

      More than anything, the article reeks of a guy who is complaining about a shitty software package, and then thinks that the thing he wants will actually fix the problem.

      It's like having a parent who's child needs surgery to remove his appendix, but goes to the doctor demanding opioids, because he knows opioids will make the pain go away.

  • If you like heavily-used server applications that occasionally lose state and don't have a refresh option, then you'll love heavily-used server applications where a significant portion of the userbase is spamming the refresh button every damned second.
    • Which is why you implement a sane delay period between refreshes. See any MMO with a broker/auction house/market place. Regard how the Search/Find button works. Now look at add-ons for some of them and the delays that are still implemented for massive refreshes. This isn't a new problem, it's already functioning on a massive scale, and edge cases have long since been identified.
      • ...if we're talking sane implementations, there are plenty of ways to do an effective automatic refresh app, as well. You can provide a small message indicating that the data is stale and the app is attempting to resolve the issue. Heck, you can even design an auto-refreshing app that unobtrusively provides the user with a refresh/retry button when it detects that something's gone wrong with the automated refresh. There are applications and audiences for minimal user interfaces, just as there are applicati
  • by Gregory Eschbacher ( 2878609 ) on Thursday September 28, 2017 @10:08AM (#55269481)

    You check in, you add your flight details to the portfolio screen, but then you can't navigate back to the barcode without activating some sort of action to invoke the refresh.

    Every UI should have a specific button that allows you to do a manual refresh. "Hidden" UIs or weird actions (such as dragging down on Android, which sometimes refreshes certain apps) are no good, especially for non-technical users. Especially where it's non-trivial to even REALLY exit and application and start it up again.

    For United, I have to use Android's task switcher to kill the app, then start it up again. Now it'll refresh successfully.

    Stop with the fancy UIs and allow people to use technology to work!

    • by dfm3 ( 830843 )
      I just screenshot the barcode ahead of time, then pull up the photo of the barcode at security and when boarding. Nobody's ever looked twice.
  • by ScentCone ( 795499 ) on Thursday September 28, 2017 @10:08AM (#55269483)
    Bandwidth, processing, and batteries are not in endless supply. Some sacred things (like absolutely live-synced all the time globally aware perfect client apps that are up to the nanosecond with back end data) are absurd perfect-is-the-enemy-of-the-good goals in the real, actual, finite world.
  • by JohnFen ( 1641097 ) on Thursday September 28, 2017 @10:14AM (#55269541)

    Steve Jobs taught us that fewer controls are better

    ...and real-world experience teaches me that Steve Jobs was wrong.

    Eliminating the means by which users can control what applications do is not a good thing. Sure, have some sort of "auto" mode for people who don't care, but leave the ability to control the operations of an application for those that do, or for those times when the "don't care" folks really need a manual override.

    This is particularly true with things like refreshing. In addition to being able to trigger a refresh on demand, it's also important to be able to stop automatic refreshing for those times when you really, really don't want the current data to change.

    • by Tablizer ( 95088 )

      Jobs viewed software more like appliances: minimal intuitive switches and a get-it-done-and-move-on philosophy. He wouldn't market a toaster to tinkerers and hobbyist. You probably want a toaster that runs Linux, right? ;-)

      • Yes, I'm very familiar with Jobs' philosophy -- and it can make sense if what you're building is a single-purpose machine that isn't doing anything incredibly complex.

        You probably want a toaster that runs Linux, right? ;-)

        Only if my toaster was intended to perform complex functions.

      • by fisted ( 2295862 )

        a toaster that runs Linux

        I'm afraid you'll need NetBSD for that.

    • Eliminating the means by which users can control what applications do is not a good thing.

      That is entirely dependent on the use case.

      • Well, yes, that's true for everything. And I'm not opposed to having things be automatic, I'm just opposed to that being the only option (for most use cases).

  • Because most internet systems were designed as stateless connections....
    https://en.wikipedia.org/wiki/... [wikipedia.org]
  • put a simple facade on a system rather than simplify it. Leaving the user no recourse in unexpected situation (other than to manipulate often undocumented registry settings) is practically a Microsoft signature.

  • ... But make it certain is there

    In the times of yore, the Nokia NMS2000 had a button to refresh from the network elements. It was in a right click, per NE and you had to be a admin to use it. But it was there*... very hard to press, otherwise, the guys in the night shift would play to see who can saturate the digital X.25 links to the BSCs faster ;-)... but it was there.

    There are reasons to hide the button, some are aestethic, as the poster said, othersare to avoid an inadverted DDoS by your own users by ca

  • And there it is... (Score:5, Insightful)

    by DriveDog ( 822962 ) on Thursday September 28, 2017 @10:47AM (#55269833)
    "'Steve Jobs taught us that fewer controls are better...'" Strict adherence to principles without exceptions is (almost, :P ) always a recipe for mediocrity at best, disaster at worst. Jobs was good at insisting on good design when it apparently conflicted with cost cutting. He was never a systems usability expert himself, otherwise some long-time Apple features and lack of features would not have stayed around so long. Automatic synchronization might be workable if it included an elaborate and well-designed "preferences" setup (I'd argue that most applications' Preferences are very poorly designed). No two persons have exactly the same needs, so one-size-fits-all is doomed to fail. Add the button by default, with an option to get rid of it after checking off some preferences to how automatic synchronization/updating should work. Not having room on a phone's screen to have a button for it isn't an excuse to not have it, it's a reason for redesigning the phones' interfaces.
  • by sgage ( 109086 ) on Thursday September 28, 2017 @11:03AM (#55269959)

    This kind of thing really pisses me off. 5 minutes ago from when? How often is it updating? Has updating gotten stuck?

    I think a lot of dissatisfaction with alleged autorefresh is that nagging feeling that something has stopped updating. For a long time there has been a trend on various blogs and forums to stamp items "updated 5 minutes ago" or whatnot, but no true time/date stamps. How about "updated at 11:59 am (5 minutes ago)". Just lately I've been seeing some forums go back to real time/date stamps.

    It's the uncertainty that is often the irritant, at least to me.

  • by Sloppy ( 14984 ) on Thursday September 28, 2017 @11:07AM (#55270001) Homepage Journal

    One hard problem is naming things. Anyone remember what the other one is?

    • by sgage ( 109086 )

      Yes, and when you get older, your memory is the first thing to go. I can't remember the second thing...

      • by Sloppy ( 14984 )

        If we can't quickly remember it, I suppose we could expensively derive whatever it was. But I'd rather remember it.

    • by rastos1 ( 601318 )
      There are 2 hard problems in programming: naming, caching and off-by-one errors.
  • I'm glad sites do a better job at supporting mobile browsers with minimal controls and single-page structure, but they need to also work with desktop browsers properly. While the browser Back and Forward buttons have always been problematic with form POSTS, their behavior is increasingly inconsistent and unpredictable.

    Case in point, American Express recently did a site update where, when you looked at transactions, it didn't go to a new page, it brought up a full-page dialog. The dialog had an "X" to clos

  • Steve Jobs taught us that [...] we should just take care of making sure we're in sync with the cloud.

    Yeah...no. While Jobs was definitely at the forefront of pushing for a cloud-based future even before we were calling it "the cloud" (e.g. I recall him talking in a mid-'90s interview about wanting to bring server-based user directories to consumers, since he had personally been using them at NeXT for years and thought they could change the way we used computers), there's no doubt that Apple's cloud products were one disaster after another for the entire time he was at the helm.

    First there was iTools in the

  • Look, the far majority of people are not tech workers. They don't need to know what an IP address is, let alone a MAC - a url is sufficient. For those people, a refresh button is not helpful (except psychologically)

    But not everyone is like that. Some people actually know a bit about software and hardware. They want and need controls, and refresh is the main one they want

"You'll pay to know what you really think." -- J.R. "Bob" Dobbs

Working...