Software Updates=Bad User Experience
A few days ago I had the following experience.
1. Open Windows XP SP3 based laptop.
2. Machine failed to sleep when I closed the lid, so it promptly sleeps when I'm trying to use it.
3. I wait for the machine to wake up again.
4. Upon waking, Outlook crashes.
5. Outlook will not die, even with end process tree. It is following the philosophy of "Never give up, Never surrender."
6. I force the machine to restart anyhow.
7. Five minutes later, the Windows restarts.
8. Upon restart, Office would like to update, wants to know if I'd like to report it crashing, and needs to do a full inbox scan.
9. While awaiting Office, all of my other software, including BOTH of my beloved Creative Suites and Windows itself would like to update.
10. Firefox and IE would like to update.
In short, it took me well over 35 minutes before I could get my work email even though I declined all other updates.
My computer using friends, we have a major problem. My software creating friends? We have SHOT ourselves in the foot. No WONDER people aren't updating and taking our security patches. We have done a TERRIBLE job of creating a decent experience! It's shameful. Really. One of the most annoying things about software.
Here are my suggestions:
1. Update on start or launch is a TERRIBLE idea. Let's explore the alternatives. This could be an ok option for some people, but is a horrid default. Think about the user. They are trying to do something with the software and we are interrupting them and delaying them. I realize this is the default because it is easy and there is a WRONG assumption out there that a user wants to know "as soon as possible" about every update that exists for every little thing. No, they do not.
2. Outlook needs to improve immediately at it's utter fear of death. When I say DIE, I mean DIE NOW and give me my resources back. I have no patience for Dumpprep when it's the same issue over and over. Dump THIS. End means end. It means give up right now. Internet applications and Windows are both guilty of this "never say die" attitude. Stop being selfish and greedy. The problem with the design is that it's so arrogant. "My application is the only thing that matters." That is the attitude that went into the over inflated sense of importance of refusing to die. If someone is ending task, it must be in error. They must WANT to tell us about it, because our software is more important than what the user is doing. This sort of thinking needs to be discouraged in companies. Your software is NOT more important than the user. They get priority, not you. Server/Client relations of many kinds fail at usability in this department. I think this issue is more technically difficult to solve, but we need to be more responsive to the user desire to be done.
3. Contradicting point 2, I'd like to suggest an option to update on program exit as a good default. This way you aren't waiting. This default should be to "Update and auto exit", not to update and make the user exit again.
4. Why? Why does it take so long to quit applications? Why is there no goal for us to speed this up and give the user their resources back? This is also a performance issue. I know many of us test for startup time, time to complete processing a certain task. Quit time matters too. So does time to cancel. I'm tired of the nonworking cancel button. Cancel means cut it out now. I feel unheard by my software often when I want to quit. As a person it makes me feel disrespected (seriously) and angry. These usability problems can really impact the overall experience someone has.
5. If we really care about security, we need to increase the likely hood of users taking an update. I wish someone would do a study of reduction in costs of security bugs and support costs by making the update experience better. So, I know how important it is and I STILL am not up to date on my home computer. I think that says a great deal. It doesn't make me a bad user, it makes me a mad user.
1. Open Windows XP SP3 based laptop.
2. Machine failed to sleep when I closed the lid, so it promptly sleeps when I'm trying to use it.
3. I wait for the machine to wake up again.
4. Upon waking, Outlook crashes.
5. Outlook will not die, even with end process tree. It is following the philosophy of "Never give up, Never surrender."
6. I force the machine to restart anyhow.
7. Five minutes later, the Windows restarts.
8. Upon restart, Office would like to update, wants to know if I'd like to report it crashing, and needs to do a full inbox scan.
9. While awaiting Office, all of my other software, including BOTH of my beloved Creative Suites and Windows itself would like to update.
10. Firefox and IE would like to update.
In short, it took me well over 35 minutes before I could get my work email even though I declined all other updates.
My computer using friends, we have a major problem. My software creating friends? We have SHOT ourselves in the foot. No WONDER people aren't updating and taking our security patches. We have done a TERRIBLE job of creating a decent experience! It's shameful. Really. One of the most annoying things about software.
Here are my suggestions:
1. Update on start or launch is a TERRIBLE idea. Let's explore the alternatives. This could be an ok option for some people, but is a horrid default. Think about the user. They are trying to do something with the software and we are interrupting them and delaying them. I realize this is the default because it is easy and there is a WRONG assumption out there that a user wants to know "as soon as possible" about every update that exists for every little thing. No, they do not.
2. Outlook needs to improve immediately at it's utter fear of death. When I say DIE, I mean DIE NOW and give me my resources back. I have no patience for Dumpprep when it's the same issue over and over. Dump THIS. End means end. It means give up right now. Internet applications and Windows are both guilty of this "never say die" attitude. Stop being selfish and greedy. The problem with the design is that it's so arrogant. "My application is the only thing that matters." That is the attitude that went into the over inflated sense of importance of refusing to die. If someone is ending task, it must be in error. They must WANT to tell us about it, because our software is more important than what the user is doing. This sort of thinking needs to be discouraged in companies. Your software is NOT more important than the user. They get priority, not you. Server/Client relations of many kinds fail at usability in this department. I think this issue is more technically difficult to solve, but we need to be more responsive to the user desire to be done.
3. Contradicting point 2, I'd like to suggest an option to update on program exit as a good default. This way you aren't waiting. This default should be to "Update and auto exit", not to update and make the user exit again.
4. Why? Why does it take so long to quit applications? Why is there no goal for us to speed this up and give the user their resources back? This is also a performance issue. I know many of us test for startup time, time to complete processing a certain task. Quit time matters too. So does time to cancel. I'm tired of the nonworking cancel button. Cancel means cut it out now. I feel unheard by my software often when I want to quit. As a person it makes me feel disrespected (seriously) and angry. These usability problems can really impact the overall experience someone has.
5. If we really care about security, we need to increase the likely hood of users taking an update. I wish someone would do a study of reduction in costs of security bugs and support costs by making the update experience better. So, I know how important it is and I STILL am not up to date on my home computer. I think that says a great deal. It doesn't make me a bad user, it makes me a mad user.


All of these problems can be summed up by two issues:
1) Only UI / Usability programmers should have anything to do with interfaces. Only one UI / Usability team should have control of the whole interface; everyone else should keep their grubby mitts off - and this should be enforced. It shouldn't be possible for any code other than an approved UI to do anything directly UI related; you're either UI or data, never both.
2) Updating code and data should be built into the lowest level of the OS. The OS sould be tracking the update source for each insalled piece, monitoring the traffic level on the network bottleneck point between the machine and each source where possible, and polling and updating its cached code and data in bits in the background when there's more than say 20% processor and traffic space free.
Reply to this
Oh, and Outlook has so many sieze-up and response problems, pretty much all of which can be traced directly back to not separating the UI from the data.
Reply to this