Artwork: Refreshing the artwork for the product

What is the artwork for a software product ? The artwork for a software product is all the visual imagery that is used in the product. This could be the application icon that you see in the top left corner, this could be the image that you see when the product is being loaded, this could be the icons on the various dialogs and screens of the application. If you ask an engineer on the product development team, he could not care less about the artwork (some are concerned, but most would be concerned about the impact of delivery of the artwork on the overall schedule and the screens on which they are currently working).
Why is the artwork important ? Well, you could also buy some simple stock images and icons (or get them designed from innumerable free or low cost options available on the internet), but the problem is, the artwork is part of the overall branding of the product and has a significant role to play overall. For those who monitor the overall branding of products, when companies make a change in their branding or in the icons, it is a big effort.
From time to time, there is a need to refresh the artwork used in the product, it makes the application feel fresh. It is not so easy to perceive, but users get a bit jaded when they see the same artwork, the same icons in the product across different versions. When the artwork is refreshed, it gives regular users of the application the feeling that they are seeing something new, even though reviews may not give too much importance to the change in artwork. Further, when there are changes to the look and feel of the operating system on which the application works, there is a need to make changes to ensure that there is a sync between the operating system and the application. For example, it could be that the new operating system has icons that have a certain amount of transparency, and applications that do not have the same kind of look and feel stand out (and that too in a negative way, not positively).
However, refreshing all the artwork, or even part of the artwork is not an easy task. It cannot be done without an expert - you have visual designers who talk to the product management, who talk to the product team and senior management, who talk to the customers (we actually had meetings with a group of customers to get their feedback on different sets of proposals for new artwork to see which seems to work, and which does not).
The artwork design and creation process has a separate schedule and is normally done outside the base product team and their schedule, so there are some complications that need to be overcome. The project / program manager needs to ensure that the schedule for this delivery has to be done before the dialogs overall delivery is complete, including some time for evaluation and review, and rework. And then the dialogs / screen would need to be shown to outside reviewers to get their overall feedback and impression, and corresponding changes would need to be done.
There is further impact. Since the artwork is changing, all the screenshots of the application in the Help documentation (in the base language and in the other languages in which the application is available) need to be changed, and this can be an intense effort that takes time and a lot of work (including testing that the change has happened in all the languages).

Supporting previous versions of the software (Part 6)

The previous post (Supporting previous versions of the software (Part 5)) talked about a team trying to make a decision about whether to drop support for a previous version of the software or not. If you are a user who is impacted by dropping support for the version of the software you are using, you would think that the team has taken such a decision without thinking about users. However, such decisions are not taken without a detailed discussion, and maybe after thinking about this decision at multiple levels before the final decision on dropping support is taken. However, it can be the exact reverse decision that could happen. With some serious defects having risen, the team has proposed that these cannot be fixed easily and also because these problems are for an older version; however, when a decision is finally taken, the decision is the exact opposite. The support for the previous version is not removed, and infact, the team is told that with these severe defects, there needs to be a fix provided to users.
With this decision, it can provide quite a challenge for the team to provide the dot release / patch for the release, but not impossible and hence they have to plan for it. There are a number of parameters that need to be considered, evaluated and a solution found for all of these. Some of these are (this is not an exhaustive list, if you see more parameters, please let me know through comments):
- Whether to release a dot or patch: What is the difference ? The terminology could vary, but typically consider 2 different kinds of releases ? One is where you have a simple small executable that just updates the few files required for the fix, while the other is a complete release that essentially replaces the application that they have on their machine. The reasons for deciding which method to use is also complex; it depends on the number of files to be updated, as well as the actual mechanics of issues such as upgrades, dependencies, etc. This decision is typically an engineering decision.
- Number of resources to be used for the release: In most cases, teams do not get additional resources for handling such updates unless they are doing this on a regular basis. So, some amount of work estimation needs to be done to determine the number of resources needed, as well as the schedule on which they will be needed.
- Support from external teams: For any product release, there is support needed from additional teams such as testing, installer and release, documentation, etc. Even if there is a small update to be provided, there is a need to ensure that these external teams are in place and committed to the effort, This can be a challenge sometimes.
- The timeframe for this effort needs to be decided: This can be a challenge sometimes. Typically a dot or a patch needs to be released pretty quickly, and there is a need to optimize to ensure that the existing engineering work for the current version is not impacted. This schedule can be a challenge, since the priority will remain the work for the existing release, and yet there needs to be an update.
- Update problems / engineering issues: Whenever an update / patch / dot release for a previous release needs to be released, it needs to be checked with the application installed on the user's machine. This includes ensuring that the application continues to work fine with the update, including the standard checks. This means that the team needs to install previous versions of the application and even replicate the operating system version that some of the customers might be having.
- Informing the users through support teams, forums and so on. There needs to be a campaign to inform users about the impending update release and ensure that feedback needs to be taken quickly when the update is released.

Supporting previous versions of the software (Part 5)

In previous posts in this series (Supporting previous versions of the software (Part 4)), we have talked about how an organization makes the decision to remove support for a (much older) previous version of the software. Removing support means that customers are encouraged to move to a higher version, defect fixes are not provided and the support team will not take any more calls on that version. This can get tricky, and sometimes the decision is not all that clear as to whether the support would be withdrawn.
For removing support for a previous version of the software, the groups that typically advocate removing this support are the development and testing teams; the number of previous versions of the software that remain supported in the market, the more effort they need to put in. For example, just as an example, there are a lot of compatibility issues that need to be developed and tested, and these increase as the number of previous versions are supported. Another example would be the support team, since they have to keep a track of issues, defects, notes, and other items for all the previously supported versions. However, when you look at product management and marketing, they have a lot more contact with customers, and they are able to better figure out whether it is possible to drop support or not.
I am going to try to layout some reasons where the team took the call regarding whether to drop support and decided that they cannot drop support as of now. Here are some of the reasons (and this cannot be a comprehensive list, more based on my experience in the industry).
- Too many users complaining about support being withdrawn: This happens when the team informs people through support forums and the helpdesk that they are planning to drop support. If there is significant push back (and discussions with some those protesting reveals that they are really going to be impacted), then the organization may decide to not drop support as of now.
- Previous deals commit support for an extended period of time: This happens typically in the case of OEM's or when there is a large deal. As part of the deal, support was required for 5 years after the launch of a version, and this grew tricky in the years to come. But we were bound by this condition, and the only learning was to be more careful of the implications of providing support for extended periods of time.
- The Product Management / Marketing looks at data, looks at support discussions, user forums and decides that the level of discussion is still fairly high enough that the support needs to remain for some more time.
- Data from metrics reveals that the understanding of the team was incorrect regarding the number of people still using the software and the data reveals more people that are using the software. In this case, it could still mean drop of support along with an offer for those people using the older software to get some concessions when they are upgrading to the latest version.

Read the next version of this series (Supporting previous versions of the software (Part 6))

Supporting previous versions of the software (Part 4)

This is a series of posts on the subject of when an organization decides to drop the support for a previous version of a software. Say, you are working on version 8 of a software and version 4 was released 4 years back, and the management team is trying to make a decision on retaining support for the software version. In a previous post (Supporting previous versions of the software (Part 3)), we had talked about a situation where there is no choice but to drop support, because of a dependency issue. The previous version used a software component that is not working properly and there is no way to fix this; in many such cases, the organization has to take action. It cannot pretend that the previous version is working fine except for a few glitches, and instead would need to declare that the version is no longer supported. When it says that a version is no longer supported, it actually means that there will be no support, no updates, no bug fixes and it is recommended that users upgrade to a newer version of the software.
What happens in the case where the organization has no data metrics about the number of users who are using the previous version of the software. Well, it does get kind of tricky, but these situations have happened in the past. The emphasis on being able to trap user interaction and mine this data for doing all sorts of analysis (including determining usage habits) is something that is of relatively recent vintage, not being emphasized even 4-5 years back. Now, every product tries to capture user interactions, which workflows use more often, and so on; but consider the case when this data was not being tracked and now the organization wants to drop support for a previous version of the software for which they do not have this kind of data.
Just because they do not have this data does not mean that the organization will continue to support previous versions for a long time. There is an increasing heavy cost associated with supporting long back previously released versions of software and at some point, the organization will decide to drop support. If there is no user data, the organization could check with support teams and with user support forums about the amount of queries that come in for these previous versions of the software, and if it seems that there are a large number of users that are active for those versions, then it makes sense to not drop support for some more time. On the other hand, if it turns out that there is hardly any interaction related to that specific version, then it might make sense to take the decision to drop support. Of course, there is some amount of subjectivity involved in this, since forums might not be a totally accurate mechanism to determine whether there are a lot of people using that version, but it is a hard choice. You have no other mechanism to determine the usage levels and you have to use some kind of proxy to help you make that decision.
One way is to make announcement about dropping support in another few months, and then see the reaction. If there are a large number of people who voice complaints and so on, then it might make sense to interact with some of them and determine whether they are really discomfited if support is dropped, how often do they really need some kind of support and so on. Even in such cases, after due discussions and interactions, it may still be possible to drop support (even if there some amount of opposition, as long as it is containable).

Supporting previous versions of the software (Part 3)

This is a line of posts that talk about the reason why software companies may drop support for a previous version of software that they have released. For example, Microsoft has released many previous version of the Operating Systems (out of which a number of them are no longer supported), many previous versions of its Internet Explore Browser (again, many previous versions of the browsers are no longer supported), Adobe has released many previous versions of popular software such as Photoshop or Acrobat (and periodically drops support of previous versions of the software), and so on. Does it mean that there are no problems when the organization drop support of these versions of the software ? No, but the number of users who are outraged by this dropping of support is low or there is an upgrade path for those users and hence it is possible for the company to do this.
In the previous post (Supporting previous version of the software - Part 2), we talked about having analytics and data information about the number and percentage of users who are using the version of software that is proposed to be dropped, and hence the organization can take an informed solution.
In this post, we will talk about a situation where the hand of the organization is forced. For those involved with designing software products, the question of component dependency is a double-edged sword. When you are making your own software (we'll consider the case of building a software product for the Windows environment), you do not build each and every functionality. There are many organizations that have built components that do specialist work much better than you would be able to do so. For example, for building a video application, it would make more sense to license the usage of a specialist video codec that does it much better than you could. With this advantage, there are some disadvantages as well. You have locked yourself to this component (and large modern software products may use tens or hundreds of such components). In most cases, even when the external component gets upgraded, the upgrade would happen in such a way that software products using such a component can still work. However, over a period of time, especially when a number of years have passed, there can be many problems that come up because of this component dependency. For example, the company that has built the component has gone out of business, or sold the business, or did something similar. This may still work, but it gets even more complicated when defects start cropping up in that component (and customers start reporting those defects). In such cases, when the version of the software is pretty old (more than a couple of versions old), the organization starts veering to the decision that it cannot fix the problem. Even if a fix of the component gets available in some way, it would just be possible to easily fix the problem, or the effort involved to fix, and test this problem would be deemed as not justified.
Consider another case where the software dependency is on some component for which support itself has been withdrawn. Consider the case where you would have integrated a previous version of the Internet Explorer browser support in your product, and Microsoft has withdrawn support for this version of the Internet Explorer. When you start running into multiple such problems, then taking a decision to drop support becomes easier.
Read the next post in this series (Part 4)

Supporting previous versions of the software (Part 2)

Well, actually, the topic of this post should be more like, When to drop support for the previous versions of the software. In the previous post (Supporting previous versions of the software - Part 1), we did a top level summary of the problem, and what are some of the approaches one should be following.
In this post, we will talk about the usage of data analytics to determine the number and percentages of users who are using previous versions of the software, and how to use these data analytics to work out whether to continue support or not. Say, if the data is able to determine that there are only 1% of users who are on a version that was released about 5 years back, then it would really help in the decision making. One of course needs to keep in mind that the data cannot be the only factor in determining the dropping of a support, but it is very useful to have such a data rather than trying to make a decision without this kind of data.
How does one get this kind of data ? Well, it is fairly easy to make the application to be phoning back whenever the user launches the application. The data phoning can be incorporated in various different ways - it can be incorporated to repeat the first time that the user launches the application, it can also track how many times each feature was launched in the application, for how much time, what were the workflows involved, and so on. This data coming into the applications data gathering mechanism can be tweaked to do whatever kind of analysis is required.
This data provides a great amount of input into the decision making process. For an application that has around 10,000 active users across versions, if there are only say 100 users working on an application version that was released 5 years back (and during the year of release of this version, there were around 900 users); it is possible to make a decision that support for this software version could be dropped. In many cases, the product team could try to entice these users on previous software versions by offering them a discounted upgrade path to the newest version.
However, using data analytics comes with its own challenges. There are many cases where there are challenges in data collection, or in data analysis. It needs to be very very sure that there are no errors during this process of data collection and analysis. And there are legal issues that need to be settled. This concept of sending data from the application needs to ensure that there is no violation of the privacy of the user (there can be heavy penalties in case it is found that privacy of the user has been violated). Hence, the functionality of this kind of data collection and data analysis would need to be cleared by somebody in the organization who has the authority to clear such kind of privacy potential issues (can be the legal advisor in the company).
Read the next post in this series here.

Supporting previous versions of the software (Part 1)

It is one of the biggest challenges of software development companies. Over a period of time (years), there are different versions of the product that get released. The discussion that happens gets interesting when the company has to decide which previous version of the product needs to remain supported. It is not an easy decision for the company to decide whether to drop support for previous versions of the product; after all, when the company does decide to stop support for a previous version of the software product, there may be a number of users of that software who raise objections. I have worked with a team which had to make that decision on an ongoing basis. The team would release a software every 15 months which had tens of thousands of paying users, and it had been ongoing for more than a decade. As a result, software was being supported that was released more than a decade back. A long time back, when the company had decided that software support would be stopped when the product was released more than 5 years ago, there was a firestorm released onto the support forums and other networks, and had the potential to be damaging PR. As a result, the company decided to reverse the process of dropping support without getting much more data. During the analysis of this decision and the reversal, it was clear that the data for this decision was not really analysed to the level it was expected to be. It was decided that the next time that this decision of dropping support was to be taken, it would need to be done only when there was adequate data for the same; or at least much more analysis of the decision.
What needed to be done ? Well, the basic data for taking such an decision would be to determine how many users of that particular product version were still there, and what percentage of the total users were still there on that particular version. It would be easier if the instrumentation for this was built into the various products; in which case, it is a matter of building the analysis that takes the data from the different software product versions out there in the market and determines the percentage of users who are still using the different software versions out there. What we finally decided was that once the percentage of users of a previous software version dropped to below 4% and it was the software version that was released the earliest, we would start notifying users, going to support forums and the various social networks to explain the reason for dropping support, providing the users with an upgrade path and the proper explanation for the reason for dropping support.
When this decision is communicated many weeks or months in advance of the timeline, it helps the users to come out in favor or against the decision and lets the team react to these and provide the explanation for the same. Once this kind of discussion happens, it lets many users understand the basis for the decision and maybe even accept it (a lot of users just want to understand why something like this has taken place).

Dropping support for a software version is complicated, we will need more posts to walk through the reasoning and the reasons for the same. Look forward to the next post in this series (Part 2)

Emphasizing the importance of status meetings

During the course of a software project, there are so many different ongoing issues and sub-projects. As a result, there are so many matters that the project managers and leads do not know about; with some of the issues only getting highlighted when they are major issues or when they are close to bursting out in flame. There are team members who need information from other team members or need some help from outside the team, and they are not sure how to highlight this information.
How to handle such issues ? How do team managers and leads figure out all these and work out an ongoing formula to get more information, to provide information back to the team and to the layers in the team, and so on ? The answer to this is a version of the status meeting. This may be one meeting, or this may be multiple meetings, this may be a meeting the project manager has with the team, or this may be individual meetings that the leads have with their respective teams; or it may be a combination of all of these.
So, meeting(s) may be setup in the team on a regularly periodic basis. In such a meeting, you would have team members / leads / managers interacting on a structured basis, with issues being brought up, upcoming schedule milestones being highlighted, and so on. However, in a project, there are almost issues that may be on fire, or there may be other items that may be going on, where team members or leads may feel that it is more important for them to be present rather than attending these status meeting (this may be highlighted even further if the person has not had much going on in the previous meetings).
However, once this kind of a feeling comes in on the team, it can cause huge problems for the project manager(s) and the leads, since this meeting is extremely important for the team. As a result, right from the start, it is important to emphasize to the team regarding the need and necessity for this meeting for everyone in the team; that it would take something real critical to prevent people from attending this meeting. Some teams I know even make sure that if somebody is not attending the meeting or has not attended the meeting, they need to talk to a lead or a manager and explain the need for doing so.
And yet, there are cases. Team members visualize that this meeting is important for the manager, not for the individual team member; and it would not matter too much if they do not attend; or that they may something on their plate that is so critical that they can skip this one meeting. That last part may be true, but depending on the team dynamics and the maturity of the team members, deciding whether a team member can skip or not may be a decision that may be with the team member or with the manager. 

Defect handling: Rolling over bugs for a hotfix

Getting critical defects fixed before a software product is released. Right ? Would make a lot of sense, that the release would be considered problematic if there are fairly severe defects open when the product is about to be released. So I was so surprised when I was speaking to the engineering manager of a team which works on the regular subscription product updates release program for a software company (consider the case where a customer has bought a subscription, and every few weeks, the software automatically updates itself with a new incremental version of the product).
In such a case, the showstopper definition has changed. Now, the showstopper is not a severe defect, but anything that imperils the periodic release of the update; since customers have come to expect that there will be a release and may have their teams somewhat geared to handle and implement this release. In such a scenario, even though it seemed so odd that me the colleague was ready to accept a defect in the released product, that earlier might have caused the product release date to be impacted because of the need to accept the defect, analyse the defect and finally incorporate the defect fix. It took some amount of discussion with the colleague before I was able to accept the way their product release was setup to get impacted by defects.
The concept was that the regular updates have a rolling list of defects along with the update, and the customers have accepted this as a standard procedure, to the extent that they study the defect list and identify the ones that could impact them and pass these back to the product team along with a list of priority. This is the case with the multiple large teams that are customers. However, this is not to say that showstopper defects will not be fixed before the product is released. If there are defects that do not allow specific workflows to happen, or cause data loss or something similar that is of a severe impact, these defects will still need to be fixed before the product update needs to be released. However, earlier definitions of what is a severe showstopper would have been released.
A defect that would have earlier caused a product release to be delayed is now considered and evaluated as to whether it really something that is critical enough that it needs to be fixed now and cannot be sent out as a part of the defect list sent out by the product team. This relaxation, just as long as customers continue to trust the product team and its criteria, ensure that the team is able to increase its chances of  releasing updates on schedule which in turn actually benefits the team as well as the customers since it increased predictability.