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.
- 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.
No comments:
Post a Comment