One of the most important features of our products is the ability for us to actually update them. The Mac team has been talking a lot about this lately, specifically: how best to keep users up to date without impacting them in any way?
Our updating process actually has quite a few steps:
1 – we launch a process that manages the updating (LiveUpdate)
2 – LiveUpdate checks the LiveUpdate servers (most of the time a Symantec server, but sometimes enterprise customers have a local LiveUpdate server that lives behind the enterprise firewall) and checks to see what updates are actually up there
3 – It checks to see if the available updates apply to any of the installed Norton applications and various update components (like the antivirus definitions or signatures for vulnerability protection
4 – if there is stuff to download, we download it
5 – then we install it
6 – then we do some cleaning up (and we check, again, just in case to see if we have anything else to download that may have required the stuff we already downloaded to be present before we could install the newer stuff).
And this is just the steps that I know about. I’ll bet my developers will be more than happy to expand on this list (product managers tend to over simplify, I admit).
So, like a ton of stuff happens and, well, I just bet the vast majority of our customers could care less. They want to use their computer and they don’t want some product they spent fifty bucks on to slow it down.
A lot of this is perception, of course. When we do these basic updates, we do it all behind the scenes, you don’t see LiveUpdate launching on the dock like you used to, nor does the old LiveUpdate download progress windows show up. And if you are using your Mac, our processes will take a bit of a backseat and give you more CPU time, otherwise, if you aren’t doing anything, we’ll use more CPU power and get our work done as quickly as possible.
It’s a good start, but as my QA Lead is often reminding me, we can do more. So, we’re rethinking the whole process. The details are still being hammered out, but again, the goal is the same–keep people up to date without interfering with their work.
So, that’s good for content updates–do it behind the scenes, don’t make a big deal out of it. But when it comes to product updates, I found that I needed to think a bit differently. Given how we run at a lower level than, say, a graphic design application, oftentimes our product and engine updates will require the user to restart, or at least log out for the changes to take effect, not unlike the base Apple updates. So, that’s cool, we don’t update our products all that often, but I am thinking that we should at least inform the user:
1 – hey, we would like to update a product
2 – but you know what, it’s gonna require a restart
And ask them whether or not they want to deal with it now or postpone it for later. Not exactly rocket science, I realize; plenty of apps do this, the trick is being gently persistent–this is security software, after all, and we’re not going to update the product or engine unless it’s going to fix a problem or improve security. So, we’re thinking a lot about that.
And, finally, we have to acknowledge and support the customers out there who just love to update and make schedules to check more often than our defaults. Hey, I get it: you are running a file server or something that people rely on, you want it to be as protected as possible. We’ll help you make that happen, too.
Regardless, whatever we do, we’ll make sure that the protection is as current as it should be and we’ll make whatever changes we need to to make that happen.
Source and Copyright: Norton blogs.