Earlier this week I met up with a couple of agency colleagues over lunch to discuss their challenges with a client’s global content strategy. The client, which has offices across the globe, recently decided to redesign their website. As part of the redesign, they also invested in an enterprise content management system (CMS) platform with the goal of globally rolling out the newly designed websites on the same technology platform.
The client had already completed their initial discovery/strategy, worked out a new website taxonomy and was pretty far along in approving the website creative. Everything was coming together until the US marketing team shared their plans, taxonomy and designs the Asia Pacific marketing team. On the worldwide marketing teams call, the Asia Pacific team raised a red flag: initial feedback for the creative indicated that the new designs did not resonate with users in the Japan market. Specifically, those users wanted the designs to have “more imagery and less text.” Furthermore, the Asia Pacific marketing team was concerned that the proposed site taxonomy did not align with the products/services that were offered in that region. This meant that their plan to globally clone the sites using the US website (aka, the Master site) in each locale (aka, country and language) was not viable. So what was the US marketing to do? How could they develop a new website yet make the site templates flexible enough to support the Asia Pacific region?
My solution to this challenge was to switch from a global cloning approach to a regional cloning approach. The client could proceed developing the US website and leverage that for other countries in the Americas region. And, the Asia Pacific team would develop a custom website (aka an alternate Master site) which could then be leveraged for countries within their region. To take advantage of the global CMS platform, a shared assets folder would be created so that each region can re-use common functionality on their sites. This way, the Asia Pacific region could leverage as many, or as few, assets from the Master site as they wished (see image below).
Why use this approach? Because the Asia Pacific websites require a unique taxonomy to support their products/services. If the regions agreed to the same taxonomy, then the initial plan to globally clone the Master site and then personalize the websites (aka, update messaging and imagery) based on the region would have sufficed. Again, these paradigms of world-wide cloning and regional cloning are not uncommon among global websites. For example, Atlanta-based PGI (telecom industry) uses a unique look and feel for the US website yet the PGI Japan website uses an alternate look and feel.
Conversely, EMC (Data Storage Devices industry) uses similar taxonomy across the globe (see the US vs. Japan).
What are some other solutions to this global website strategy problem?
It seems that every day that goes by, another one of the user interface developers that I work with talks about how Internet Explorer 6 must die. Granted, they have plenty of justification for why this browser should go away. For example, Internet Explorer (aka, IE6) is “ancient” — it was released in late 2001 (source). It has serious security flaws (source) and Microsoft has moved on to release IE7 and IE8. But there’s a problem that non-developers seem to be ignoring.
While IE6 usage dropped significantly in early 2008/2009, the downward pressure has softened quite a bit this year. And a recent survey revealed that IE6 is used primarily at work and the majority of people unfortunately can’t upgrade/replace IE6 because they have insufficient privileges on their machines/their company won’t let them upgrade (source). So without significant force now, it may take another two years before IE drops to a level where enough developers stop coding UI tweaks for IE6. Since coding for IE6 takes significantly more time, marketers are unnecessarily spending money on outdated technology (like paying for a telephone land line or dial-up internet service).
Last week, six solid punches in one swing were taken at IE6. I am speaking about the announcement that Google is planning to phase out support for IE6 (source). The announcement indicated that key functionality in Google Docs and [international] Google Sites will be disrupted starting on March 1, 2010. Since no other popular web destination is stepping up to the plate, we’ve got to applaud Google which owns 6 of the top 20 destination on the web (source) for their efforts. So what we really need to do is convince several US-based companies, such as Microsoft (thank you @cubanx!), Yahoo! and Amazon, and Chinese companies, including Baidu, QQ.com and Sina.com.cn, to jumped on board. While it may feel like we’ve made progress, the short list below demonstrates that we still have a long road ahead of us.
Top 20 Companies that don’t support the IE must die movement:
- Google (starting 1-Mar-2010)
- Facebook (as of 24-Jul-2008)
- YouTube (starting 1-Mar-2010)
- Windows Live
- Blogger.com (starting 1-Mar-2010)
- Yahoo! Japan
- Google India (starting 1-Mar-2010)
- Google China (starting 1-Mar-2010)
- Google Germany (starting 1-Mar-2010)
The Iron Triangle allows for only two factors in determining the success of a web project. But the impact of the client’s perspective on the triangle seems to reduce the two factors into a single option.
Early on in my development career, I leaned how the Iron Triangle impacts projects. The iron triangle (aka the Project Triangle) is a software development concept that says that the quality of a project is determined by three factors:
- Timeline. How long you have to complete a project?
- Budget. How much is the client is willing to pay for the work?
- Features. What functionality can be built?
The point of the Iron Triangle is that you can pick or constrain only two of these three factors. So if the project timeline and features are constrained, then the budget must grow. If all three factors have to be met, then the quality of the web project will be sacrificed. While this concept seems to give developers some breathing room, the Iron Triangle seems to be further constrained when the client’s perspective is taken into account. Let me explain.
A client typically approaches web projects with two constraining factors. When a client requests a solution, they normally constrain the project by asking that the solution be delivered by a certain deadline. The deadline is normally set because the client needs to meet a pre-determined objective, such as seasonal promotion, customer acquisition campaign, etc. Additionally, when a client requests a solution, they further constrain the project with their budget. Since money doesn’t grow on trees, the client will dictate how much they can spend for development on a project to be completed.
So when the client’s constraints on a project are taken into account, the Iron Triangle is actually reduced to a single option: project features. This means that developers have to look at how many features they can implement for the time and money that they are given. The good news is that the feature list can be functionaly robust or weak. That means that there’s some play in what the client will or will not get for the time and money that they’re dedicating to the project.