All That I Know (About Technology)

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:

1. Google (starting 1-Mar-2010)
   
2. Facebook (as of 24-Jul-2008)
   
3. YouTube (starting 1-Mar-2010)
4. Yahoo!
5. Windows Live
6. Wikipedia
7. Blogger.com (starting 1-Mar-2010)
8. Baidu.com
9. MSN.com
10. QQ.com
11. Yahoo! Japan
12. Twitter
13. Google India (starting 1-Mar-2010)
14. Google China (starting 1-Mar-2010)
15. Sina.com.cn
16. MySpace
17. Google Germany (starting 1-Mar-2010)
18. WordPress.com
19. Microsoft
20. Amazon.com

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.

Understanding the purpose of a legacy microsite can help you determine whether you should fold it into your newly designed website or dump it. These tips will help guide you in the decision making process.

In my tenure as a web manager, I’ve worked on countless projects where the client wanted to redesign their website. The first step in a site redesign process is to complete a site mapping exercise, where various pages and content are identified. As part of the process, we frequently uncovered microsites, which is somewhat like finding a skeleton in the closest. The newly found microsites raise the question of whether they should be collapsed into the site or permanently removed.

While answer may seem elusive, I’ve found that the decision can be driven through thinking about the common characteristics of a microsite. These characteristics include:

• Temporary
• Unique branding
• Special content
• Custom navigation/URL
• Nonstandard content management

To clarify, a microsite is typically launched to support a new marketing initiative or promotion. The site may break the branding guidelines or rely on new print collateral so that the marketers can fully test their initiative. A microsite frequently has new content that doesn’t follow the normal content structure of the website. Additionally, the microsite may play a part in an SEO campaign or and SEM campaign so it may not link to the corporate site or require custom navigation so that visitors don’t have to think. Lastly, the content on the microsite may require more involvement than the corporate IT department can dedicate to this initiative.

So how do these characteristics help determine whether to migrate the microsite?

To answer this question, one must simply evaluate whether the characteristics of the site when it was built have stood the test of time. Some questions to ask yourself include:

• Has the marketing initiative or promotion become a permanent part of your marketing offerings?
• Can the design shift back to the corporate branding guidelines?
• Can the content fit within the corporate website through the use of an existing content template?
• Will the microsite continue to meet its goals if the navigation matches the corporate site?
• Can the content on the microsite be managed through a Content Management System or CMS?

By answering more of the questions above with a yes, the clearer the direction is to fold the microsite in with your website.