5

I develop and maintain several web applications for internal use at my company. They are all PHP/MySQL-based with HTML/JavaScript front-ends utilizing jQuery and various plugins for UI elements, grid displays, AJAX, etc.

An issue that I'm constantly facing is that the users generally leave their browsers open for days at a time, with a tab for each application that they generally don't close unless they shut down their whole system. Consequently, every time I make a change to a JavaScript or PHP/HTML skeleton file, users do not get the updated scripts until they restart their browsers or press F5.

Every time I mention to a user that there will be an update going out overnight, I inevitably get a perplexed call the next morning asking why they're not seeing the changes. Every time, my answer is "try pressing F5," but it hasn't sunk in with any of the users. I don't expect users to know how web apps work in a technical sense - after all, that's MY job, not theirs. I can't expect them all to instinctively know to refresh the application before calling me, and to not expect any aspect of the front end to magically change unless they do so, although that would be nice.

I'm thinking of implementing a rudimentary solution where I will have the applications refresh themselves in the middle of the night at a certain time, probably shortly after the cron job that moves updated scripts from the "good to go" staging area to production. I'm sure this will work, but there has got to be a better way. Has anybody run into this problem and implemented a more clever solution than a simple scheduled refresh?

5

The easy way

If you're the one sending round the update notices each time, by far the simplest way to do it is to add a nice big 'Troubleshooting' section. The first thing you put in that goes:

Why haven't I got the update?
A: Try pressing F5 to refresh the page.

However, there's not a 100% guarantee that users look at that, so you may also want to implement the next part.

The clever way

You could also 'tell' your application when there's an update available. You could do that with a simple text or JSON file on the server (JSON is probably better as you can use jQuery's getJson method). Then, you set a long JS timer - if you only do updates overnight then you set it for a day (1000*60*60*24 milliseconds), and when the timer triggers you do a jQuery Ajax call to the server. This returns the contents of the JSON file, which you can check for the version number and refresh the page automatically if there's a new version.

Alternatively if you don't fancy editing the JSON file every time, define a global variable in your app's main JS file. You can check that with any JS on the page and refresh.

Which is better?

As usual, I'd say 'it depends'. If you can be sure everyone reads your update announcements, go for the first method. If not, and if people continue to ring you without refreshing, then use the second - it shouldn't be too hard to implement.

  • My update announcements are generally verbal unless it's a major overhaul, in which case I do generally include a brief suggestion to press F5 to get the update. At least internally, email use at my company is practically nil, which I actually don't take issue with. One thing I've noticed is that, because of the anti-email culture here, people tend to only skim over or read the first sentence of two of an email. It can be very frustrating so I try to avoid emailing when possible. – Matteo C Jul 31 '14 at 15:15
  • @MatteoC - fair enough then. You may want to use the second approach in that case, though I suggest that verbally telling your users to press F5 has probably saved you plenty of nuisance calls so keep on doing it. – ArtOfCode Jul 31 '14 at 16:05
  • Pretty much what I was thinking, but good point about having some way of indicating to the application that there is an update to be grabbed, rather than blindly refreshing at some arbitrary time. I'm not sure exactly how I'm going to go about it (I'd rather have something check the last modified date than have to manually edit a JSON file every time I intend to do a push) but that's a good idea, thanks! – Matteo C Jul 31 '14 at 18:22
  • @MatteoC - Or there's another way I just thought of - check the edit – ArtOfCode Jul 31 '14 at 18:48
2

If you are pushing a structural update to the end users that requires them to do a manual refresh then you need to adjust your code.

I see 2 basic scenarios:

  1. The content they see on screen is valid until they make a transition
  2. The content has to be updated for the user to be informed (think current stock price) to make the right decision(s)

If you are dealing with #2 where the users are needing to see the full update, or you need to push something to them then your code should trigger the applicable refresh/reload as needed.

e.g.

location.reload();//or whatever actual loading you need to do

If the issue is specifically with a change to the static content of your site (CSS/JavaScript/Images) that will already be cached in the user's browser then you need to use some sort of static-cache management that physically changes the name of the static resources when they change... However this is another question best suited for stackoverflow.com ;-)

There's a million ways to deal with pushing the update out to the user automatically but one of the easiest I've seen is to build a simple heartbeat call that runs at every interval (your choice... every 15min? hour? 4hours?) to see if there is anything "new". 99% of the time you'll return nothing, but when you have an update, it tells the client to reload.

  • What structural update doesn't require a refresh? – ArtOfCode Aug 1 '14 at 8:24
  • The OP could have AJAX calls that get new content that overwrites part of the "structure" of the size but still not require a reload. My main point is that an SPA shouldn't require that the user has to manually do a reload in the browser to overcome a design flaw in the site/app. – scunliffe Aug 1 '14 at 15:33
  • Point. I have to say though, ajax calls like that would require some fairly long code, even with jQuery. JS is easy to overwrite but overwriting CSS files is not so easy. – ArtOfCode Aug 1 '14 at 19:59
0

2019

This answer has nothing to do with UX but I am including it here for the purpose of completeness.

  1. Add laravel mix to your project.
  2. It has a feature called cache busting where it adds unique hashes to each of your script files when it sends them to the client.
  3. No need to mess with the UI of your web apps in any manner

    When the script changes in any way, the ids change and the browser is forced to redownload them.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.