Tips for Clearing the Browser Cache: IE, Chrome and Firefox

When doing web development, especially JavaScript/HTML, it’s sometimes hard to tell if your changes loaded when you refreshed the web page, in fact sometimes your changes aren’t reflected. The best thing to do is delete the cache and then reload the page. So, this post will tell you how to that for the three most used browsers – Firefox, IE and Chrome.

Before I tell you how to do it, it’s good to know what the cache does and why. It’s basically a file directory where your browser stores temporary files such as web pages (e.g html files), images (e.g. png’s) and other web-related items including sound files ( e.g. mp3’s). The idea behind storing these files is the user’s experience: it’s faster to retrieve a local file than it is to retrieve it from some remote web site and the page appears to load faster to the user. Another reason is reduces server load for high usage sites because many of the files are loaded locally for repeat visitors. But, even though you may care about this your end users certainly don’t.

Chrome 16.x (Windows)

Go to the top right of the browser and click on the wrench symbol, then Tools > Clear Browsing data. Chrome will then load the Options page and let you choose by timeframe how far back to go when deleting data. When you are doing frequent web development the “past hour” option is awesome. That way you can delete your most recent work and all your other cookies and data will stay in the cache.

 

Firefox 10.x (Windows)

Go to the top left of the browser and click the pull down menu, then History > Clear Recent History. Firefox then loads a popup window that also lets you choose how far back in time to delete data. Firefox was the first browser to offer the “last hour” option. Again, it’s a really nice thing to have when you are doing frequent builds and constantly reloading the browser.

 

Internet Explorer 9 (Windows, of course)

For IE, go to Tools > Internet Options > Delete. Unlike Firefox and Chrome, IE deletes everything and I don’t know of a way to tailor the tool to not do that. This is something to be aware of it IE is your primary browser and you need to blow away the cache. All password cookies and anything else you have stored will be deleted. IE does, however, have a nice feature that I use a lot which is the Delete Browser History on Exit option. Again, if you are doing lots of builds (code then reload page to see changes) then consider checking this option and save yourself a bunch of time clicking through menus every time you reload a page.

 

 

So you want to build a mobile app? Not all mobile apps are created equally

Most smartphones users I know ditch apps pretty quickly if they don’t work or end up being clunky. So, if your company is considering offering mobile apps to your customers you should be aware of a few things.

Buy a Smartphone. If you don’t already have a smartphone then you should go out and buy one. Then download a number of apps that interest you and try them out and see what you like and what you don’t like. For example, if you do the shopping for your family you might consider trying out a bar code scanner app that lets you compare pricing. Some scanner apps may work faster than others. If you don’t own a smartphone then you won’t be able to understand what a good app is.

Likes and Dislikes. Pay close attention to what you like and don’t like about a particular app. Here are a few questions to take note of:

  • Was it easy to use?
  • Did it hang and/or crash?
  • Did it perform its tasks gracefully?
  • Did it do what you expected?
  • Was it visually appealing?

Become Tech Savvy. Become a bit more tech savvy about things that the phone is doing behind the scene. There are apps that do this for both Android and iPhone that help you monitor what’s going one. Things to look out for:

  • Apps that keep running even after you think you shut them off. These will run the battery down faster.
  • Apps that consume more and more memory over time. Using more memory equals more battery usage and shorter time between charges.
  • Apps that seem to slow your phone down when they run. These apps may be using more CPU than necessary resulting in greater battery usage.
  • Apps that connect to the internet frequently costing you extra data charges. There are apps that let you monitor how much data your phone uses and some apps can help pinpoint which apps use the most data.

Which Phones to Support? Understand what devices to support. If you are building an application for internal use, then you have an easier decision since you hopefully have some control over which devices are being used and how often their software gets updated. If you work in retail, your users may have Androids, Blackberries, iPhones, iPads, Kindle’s, Nook’s and possibly other tablets that get updated whenever and however the customer dictates. My advice is do some research and pick one that is used the most and work on that first.

Release Early and Iterate Often. Technology changes so quickly these days that if your app takes more than 3 – 6 months to build, then the technology will change underneath you. In other words, you might be releasing an application that doesn’t work perfectly with the latest phone operating systems or browsers that your customers are using. When that happens, it will cost you even more time and money to fix the problem and the problem will repeat itself. Be sure to take into account the speed at which technology will change once you begin your software development process.

Go Native, Go Web Browser, or Both? Last, it’s important to understand that there are two common types of mobile applications. Native apps are downloaded from an app store and installed directly on the phone, the other is a web app that runs in the phones web browser. My advice is to research and understand your target market. What do your competitors use? What do your customers prefer? What are the trends in your industry?

If you go with native apps, you’ll need to understand which phones to support and how often you will be updating the app. If you choose web apps you’ll need to know which browsers to support. Also take into consideration which skill sets your development team has and understand if they can tackle the project or if you need outside help.

Update, Update, Update. No matter what you decide, you can’t just deploy an app and think you’re done. If you want to keep your customers happy, you’re going to have to keep updating the app until the product line is discontinued or replaced. And, you have to update it often enough to stay on top of the latest technologies. New smartphone models are being released all the time and they all may have different screen sizes and screen resolutions. An app that looks good at one screen size may look horrible on a tablet or iPad. These things have to be accounted for. And, the smartphones operating system software may be updated three or more times per year offering new functionality and fixing bugs. If your customers download a broken app, or if they see the app that hasn’t been updated in a while and something stops working they may not be your customers for much longer. This is especially true for retail apps where customers make split second decisions whether to stay or walk away and try something else.

Conclusion. I hope you find this list useful and at least give you some ideas to think about before you dive head first into bringing a new mobile application into the world. It can be fun, be there is a lot of hard work involved. But, if you plan it right you’ll be successful and learn alot in the process!