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

Ensuring coordination with respect to 3rd party icons such as from Facebook / Youtube .. (contd)

I wrote a post about this topic in a previous post (using icons from external services such as Facebook or Twitter). One of the unsaid conclusions from the previous post was that it is essential that such planning be done well in advance, so that one does not run into issues near the end of the schedule - tracking of such items where multiple parties are involved can be time consuming and frustrating when getting into the ending stage of a schedule. So what are some of the points to keep involved when dealing with using icons from 3rd party services such as Youtube, Facebook and Twitter:
- If you have used the icons in a previous version of the software, ensure that when you get into a new version of the software, you verify about whether there is a requirement to update the icon. If not, then it would be easiest to just ensure that you continue with the old icon.
- When you are doing some re-design on your end, and need to get a different icon, many of these have multiple icons available with different sizes also available for use. However, if none of these icons really fit into the UI of your application, things can get tricky. The terms and conditions of most of these services do not allow you to use an icon other than the ones that they have supplied, so modify your UI accordingly.
- If there are multiple products within the organization that use these services, then it would make sense to ensure that these products collaborate with each other to understand their use of these services. We had a classic case where one team had a relationship with the product manager of one of these services (through one of the team-members, and this contact helped in refining the use of some icons).
- Make sure that the legal team is well conversant with the usage of these icons (and also overall with the incorporation of connectivity with these services). Even though these services seem present everywhere, they do come with their terms and conditions, which need to be met by the products that are interacting with these services.
- Most of these services have an active development community. It is important to ensure that atleast one of the development team members is on this community since these communities are the first places to be notified when there are any change in policies of the external service provider. This is pretty important. We were connecting with one of these services, and then it turned out that there was a notification about a change in the API that was being used, and we did not know about this; when did we get to know ? When our connectivity to the service was lost.

Ensuring coordination with respect to 3rd party icons such as from Facebook / Youtube ..

The process of software product development is a complex one, with a number of different items to manage. In addition to the many internal complexities that need to be managed (requirements / development and testing schedules, etc), there are a whole load of external dependencies that need to be managed, and the amount of complications involved in these external dependencies are greater than than those of the internal kind. One of the complications that need to be handled has increased with the usage of more and more 3rd party services. With the increasing use of social networks by people all over the world, they being Twitter, Facebook, Flickr, Google+, and numerous other social and sharing sites, life is more complicated now.
One cannot build applications without the connection with such sharing sites, but the actual logistics of getting this done can be complex. One of these areas revolve around all the icons and others used in the application. Now, for the most part, most applications with a large number of user interfaces use their own customs icons and graphics, these having been made to seem to fit with the application (in terms of the image that the application seeks to present, the customer profile that it tries to fit, as well as the functionality that is being done in the application - an application that is dealing with money or finances would have more icons that have some sort of representation of money or cash, while applications dealing with images would show more of cameras or images, etc). Another use of these custom icons is that they present the same set even if the application is installed on Windows or on the Mac (while the application system icons on these different OS's are very different).
However, when interfacing with these 3rd party icons, there needs to be careful coordination with the team that is developing the custom icons. As part of the public API's available for most of these networks, they also have a list of icons that client applications need to use, and in some cases, the icon may drastically vary from the icons used in the application. It is typically not possible to get variations in the icons provided by these 3rd party services, although some of them will provide multiple icon sets at different sizes to ensure that one of them is suitable, but that may not be the case. Further, the team designing the custom icons may not be aware that there is a legal requirement to use only the service icons, and they should be kept informed so that they do not try to develop customs icons for these networks when only the service provided icons can be used.
In addition, if the icons provided by the services are striking on their own and different from those in the application, it would help if the designer team already knows this in advance, and hence can ensure that the icon set that they are designing for the application is made in a way that the service provided icons fit with the service. But, from time to time, these 3rd party services also go in for a rebranding, and require all clients using their services to also change the icons that they are using, which means that somebody needs to keep track of communication from the external services regarding their branding and icons.

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