This is a series of posts on the handling of items other than code during the development of different versions of a software application. In the first post of this series (Keeping tack of images and other content during software development - Part 1), I took the case of the icons, images and other graphics that are used in a software product and which may be used as the same across different versions or updated when a new version of the product is used. For example, the application icon would be updated everytime a new version is released, so that it can also be differentiated from previous versions and also seek to graphically display the theme of that specific release. I will be adding more details in this post, focusing on the graphics and images.
The theme of this series is about how we do a lot of effort to ensure tracking of different versions of the code of a product (given that the code is seen as the most important valuable of the release in terms of being its Intellectual Property - and the IP of products such as Photoshop, MS Office, and others is very valued by the organizations that build these products) in a code repository, and with the use of processes such as labeling and branching, easily able to track which version of code was contained in which release.
However, my experience in multiple versions of a major software application led me to believe that this same sort of focus is not put on the non-code items that also form part of the application. I have already talked about the graphics and images that are used in an application and how my experience led to believe that organizations can very disregard the need for having a good process regarding these items. Let me continue on the same example that I was using earlier.
We had a team that would provide us the graphics and we would go through several rounds of discussions, sharing these graphics with the core team and the team that would create the installers that were an integral part of the application. However, the process was so haphazard in terms of their sending us the original set and later versions by email (as .zip attachments), and the process of reviewing them (even though we tried various options such as using Excel, Wiki, or even filing for changes as defects) did not provide a high level of confidence that the process would be error-free. And so it turned out, in the sense that invariably we would find out that some graphic was missing, and so on and so forth. Further, there was an additional element of complexity in this discussions, since the size required of the graphics was different.
The application dialogs, the installer dialogs and other such dialogs had different requirements in terms of size of such graphics, and so there was a need to ensure that we were communicating these different size requirements, and then receive the different sizes. Since they were producing such graphics in a large size, it eventually turned out better for them to send us multiple sizes of each graphic and we could pick and choose the one we liked. We did try using a more process oriented tool for this purpose, but getting a creative team to follow tight processes and the like were very problematic and caused additional stress for the program manager of the team once the process was put in place and the creative team did not follow the defined processes. As a further example, once they provided us these sizes, there was no effective place other than a folder on a server to save these, and if you needed a different size in the next version of the product, it could be real hard to work these.
More in the next version of this post (Keeping track of stuff such as graphics and others across software versions - Part 3 - TBD).
The theme of this series is about how we do a lot of effort to ensure tracking of different versions of the code of a product (given that the code is seen as the most important valuable of the release in terms of being its Intellectual Property - and the IP of products such as Photoshop, MS Office, and others is very valued by the organizations that build these products) in a code repository, and with the use of processes such as labeling and branching, easily able to track which version of code was contained in which release.
However, my experience in multiple versions of a major software application led me to believe that this same sort of focus is not put on the non-code items that also form part of the application. I have already talked about the graphics and images that are used in an application and how my experience led to believe that organizations can very disregard the need for having a good process regarding these items. Let me continue on the same example that I was using earlier.
We had a team that would provide us the graphics and we would go through several rounds of discussions, sharing these graphics with the core team and the team that would create the installers that were an integral part of the application. However, the process was so haphazard in terms of their sending us the original set and later versions by email (as .zip attachments), and the process of reviewing them (even though we tried various options such as using Excel, Wiki, or even filing for changes as defects) did not provide a high level of confidence that the process would be error-free. And so it turned out, in the sense that invariably we would find out that some graphic was missing, and so on and so forth. Further, there was an additional element of complexity in this discussions, since the size required of the graphics was different.
The application dialogs, the installer dialogs and other such dialogs had different requirements in terms of size of such graphics, and so there was a need to ensure that we were communicating these different size requirements, and then receive the different sizes. Since they were producing such graphics in a large size, it eventually turned out better for them to send us multiple sizes of each graphic and we could pick and choose the one we liked. We did try using a more process oriented tool for this purpose, but getting a creative team to follow tight processes and the like were very problematic and caused additional stress for the program manager of the team once the process was put in place and the creative team did not follow the defined processes. As a further example, once they provided us these sizes, there was no effective place other than a folder on a server to save these, and if you needed a different size in the next version of the product, it could be real hard to work these.
More in the next version of this post (Keeping track of stuff such as graphics and others across software versions - Part 3 - TBD).
