Not sure whether the title of the post made sense, so am going to add more details right here. Let us take the case of Lisa, the user of the software. The software does greeting cards and allows users to take their own photos and add texts and the like. Now, some years back, the software had a facility that allowed users to take their final creations and save them to Yahoo Photos (which existed many years back, but does not exist now, especially after Yahoo had bought Flickr). In later versions of the software, the makers of the software would have removed this link to Yahoo Photos and modified the usage to point to some other site where photos could be hosted under a free account.
However, like most other users, Lisa does not upgrade her software application every time a new version of the application is created. So, even though the software in later versions is upgraded, every time Lisa uses the features in her software which connects to Yahoo Photos, some problems may occur. It could be that the error is something which makes sense, or it could be an error that makes no sense to Lisa, or it could be that the API call failing is something that is not handled well within the software and could even cause the software to crash whenever Lisa tries uploading photos to Yahoo Photos, which would not be a very good experience. In fact, in most of these cases, the experience that Lisa faces is not something that is a good user experience, and can cause dissonance and dis-satisfaction at the hands of Lisa.
For makers of commercial software, such a situation is very harmful, and yet you will find a number of software makers who are not ready to handle such a situation. And when you are trying to get your customers to upgrade their software, such problems are going to make it more unlikely that customers would appreciate the experience and want to upgrade. So, what do you do in such a case ?
Well, it is pretty important that the design of the application is done in such a way that features can be turned off later. So, the way to do this is to by making each such dependent feature call into a specific web site and ask for a specific parameter. If the parameter is a go, then the feature will launch and the user will get that specific feature. At the same time, if the parameter is a no-go, there would need to be some error handling that will inform the user about the problem, and also alert them about a web page where they would need to go for more instructions on what to do, and they can also be provided an explanation. Such a technique ensures that users do not feel that they are running into errors that cannot be handled. The beauty of this type of handling is that even if this problems comes in a product version that was released many years back, you can still go ahead and ensure that the users do not face major errors; and in fact, if the functionality is important to your users, you can inform them about the problem and that it has been handled in the latest version and show them an upgrade path.
However, like most other users, Lisa does not upgrade her software application every time a new version of the application is created. So, even though the software in later versions is upgraded, every time Lisa uses the features in her software which connects to Yahoo Photos, some problems may occur. It could be that the error is something which makes sense, or it could be an error that makes no sense to Lisa, or it could be that the API call failing is something that is not handled well within the software and could even cause the software to crash whenever Lisa tries uploading photos to Yahoo Photos, which would not be a very good experience. In fact, in most of these cases, the experience that Lisa faces is not something that is a good user experience, and can cause dissonance and dis-satisfaction at the hands of Lisa.
For makers of commercial software, such a situation is very harmful, and yet you will find a number of software makers who are not ready to handle such a situation. And when you are trying to get your customers to upgrade their software, such problems are going to make it more unlikely that customers would appreciate the experience and want to upgrade. So, what do you do in such a case ?
Well, it is pretty important that the design of the application is done in such a way that features can be turned off later. So, the way to do this is to by making each such dependent feature call into a specific web site and ask for a specific parameter. If the parameter is a go, then the feature will launch and the user will get that specific feature. At the same time, if the parameter is a no-go, there would need to be some error handling that will inform the user about the problem, and also alert them about a web page where they would need to go for more instructions on what to do, and they can also be provided an explanation. Such a technique ensures that users do not feel that they are running into errors that cannot be handled. The beauty of this type of handling is that even if this problems comes in a product version that was released many years back, you can still go ahead and ensure that the users do not face major errors; and in fact, if the functionality is important to your users, you can inform them about the problem and that it has been handled in the latest version and show them an upgrade path.
No comments:
Post a Comment