Software development - Keeping track of stuff such as images across versions - Part 2

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).

Software development - Keeping track of stuff such as images across versions - Part 1

When you are working on a software, it is not just code that you need to be worried about. A typical large software will contain a large amount of stuff besides the code that your software engineers write. When you look at the menus of the software, there might be cute icons to depict certain functions, or even if you look at the typical Undo option that sits in the Edit menu of a large number of options, there would be a button that you could hit for doing the Undo. If you look at Microsoft office recent versions, there would be a ribbon kind of menu at the top that will have a lot of options, and all of these are complemented by the visual appearance of icons. Typically, software makers try to ensure that their software has easy to remember buttons / icons that users remember and which makes the software apparently more usable by consumers.
However, for code, you would use some sort of code repository; but the same is not truly the same for non-code items such as buttons and other graphic options. Well, actually you can store such icons / visual items in the source safe but you will not be able to do operations such as comparisons between different versions of these items, and in fact, only when you actually export the history of such graphics from the source safe, will you be able to visualize what a previous version of the graphic items looks like.
One of the big challenges that software makers have when using such graphics in their application is about maintaining them. Consider the fact about the application icon (this is typically the graphic that is seen on the desktop, or in numerous other places where the name of the software is referenced). But, as you move from one version to another, you will need to have an application icon that is different from the icon used with the previous version. This helps you to mark that specific version of the software with a specific icon. So what do you do with the icon that you were using for the previous version ? You still need to save it somewhere since it was used in the previous version, and from time to time, people want to reference these icons and other imagery used within the product (once, we had a case where we were in version 7 of the product, and the management team wanted us to present the main graphics (including the application icon) that were being used in the previous 5 versions of the software; the idea was that there was a review team that was looking at a co-relation between the icon and the main focus of that previous release and whether these graphics were effective. It was hard to find the correct imagery, and the specialized team that had been preparing the graphics for us had suffered a lot of attrition over the years; they were unable to provide us the data that we needed. Finally, we had to do a lot of installation of previous versions, compare these with the versions stored in the source safe and then finally come up with the list.).
The idea of the previous story was about how it is much more difficult to maintain items that are different from code; since with code, the source safe will do a quick text comparison and make out the changes in code over a period of time. And mature large applications can have huge number of graphics embedded all over the software, and it is hard to find somebody in the team who will have the knowledge of which graphic was added at what period of time, and more important, the reason for why a specific graphic was added. And there are more complications that come into the picture. Consider that you are using a graphic in your software that was contributed by a team member and it was included in the software, and this happened over 4 years back. The graphic is still being used, and suddenly there is a legal challenge hit for the company over the rights of the graphic. At this time, you better have a good system of maintaining records to ensure that you can solve such a problem.

The next post will be a continuation of this series (Keeping track of stuff such as graphics in the software - Part 2).