My client has reps in both Shanghai and Beijing, neither of who could see the website, so I knew it wasn’t a localized issue. My immediate suspicion was that the infamous “Great Firewall of China” was to blame. Thankfully I was able to take a few simple steps to diagnose the problem and get the site up and running.

What is the Great Firewall of China?

For anyone who doesn’t already know, the “Great Firewall of China” is the informal name given to the vast Internet censorship apparatus of the Chinese government. Sites considered injurous to the public good are blocked on a massive scale, so that they are innaccessible to Internet users within China.

How to test if your site is blocked

For foreign businesses and web designers who need to ensure their website reaches a Chinese audience, there are several tools which test a site’s availability from servers within China.

WebSitePulse

Website monitoring company WebSitePulse offer a free service to check if a website makes it past the Great Firewall of China. You can test your site using servers in Beijing, Shanghai and Hong Kong. WebSitePulse also do a side by side comparion with servers in the US, Germany or Australia, so you can compare the responses.

WatchMouse

WatchMouse offer a free service which pings your website from a number of servers worldwide, including one in Shanghai. If your website is being blocked, the Shanghai server will report 100% packet loss.

Why me?

One of the common methods of censoring a site is by IP blocking. Unfortunately, if the banned site is on a shared web host, all sites that share the same IP address are also blocked. This is what I believe happened in my case.

The fix

Luckily there is a simple workaround to sidestep issues with using a shared IP address: buy a static IP address. If your website has a unique IP address then it can’t be blocked simply because it shares a server with a banned site.

Within an hour of purchasing a static IP adress, my client’s website could be reached from within China. WebSitePulse and WatchMouse’s Chinese servers could see the site, and more importantly, my client’s reps in Shanghai and Beijing could too.

IETester is a web browser that can run the IE5.5, IE6, IE7, and IE8.1beta rendering engines in the same process. It has a tabbed interface which makes switching between different IE versions a snap, and although it is only an alpha release it seems to work fairly well.

Personally, I’m still a fan of running IE6 in VirtualPC, using the virtual machine provided by Microsoft specifically for this purpose. No quirks or bugs, just the real IE6 running within a real Windows XP installation. But if for some reason you can’t or won’t run VPC, IETester provides a workable approach to testing in IE6 & 7 side-by-side.

Version targeting in Flash

Version targeting in Flash works in much the same way as it will in Internet Explorer: each Flash movie contains embedded information telling the Flash Player which version of Flash it was created for, and the Flash Player itself contains multiple rendering engines to handle legacy content.

This approach to backwards compatibility has been a feature of the Flash Player since its earliest incarnations. The latest version, Flash Player 9, supports content produced for FLV (Flash video), SWF9, SWF8, SWF7, SWF6, SWF5, SWF4, SWF3, SWF2, and FutureSplash. That means that Flash content created in 1995 still renders perfectly in 2008. Flash developers can have a great deal of confidence that an application they create today will continue to work in the future without any need to revisit it*.

Why have Adobe worked so hard to ensure the Flash Player is compatible with legacy content? I think the answer lies in the commercial nature of Flash. Because Adobe relies for its livelihood on the continued patronage of website developers, they need to keep that customer base happy. Flash would never have gained traction if developers were forced to rework their legacy websites every time a new Flash Player version is released - I can’t imagine anyone paying $700 for software that generates code that breaks every eighteen months!

Does backwards compatibility hamper progress?

Let us consider my concerns about version targeting, and see if they have been borne out in Flash: Has backwards compatibility hampered progress in the Flash industry? Has it slowed adoption of the Flash Player? Has it stalled advances in Flash technology? I think the answer to these questions is “no”.

One metric we can use to gauge the rate at which advances in Flash are taking place is to look at Flash Player adoption rates. A fast adoption rate by end users is a sign that users are encountering Flash content targeting the latest Flash version, and are upgrading their player in response. Even before the introduction of an automatic update feature, adoption rates for the Flash Player were very high. From the time a new Player was released, it would achieve 55%-65% market penetration within 6 months. This is a good indication that Flash developers are quick to take advantage of new features in Flash.

Another measure of technical progress is the rate at which new features are added to the Flash Player (as opposed to the Flash authoring tool, where some changes will be merely cosmetic). During the past four releases there have been three complete overhauls of the Flash programming language, the introduction of powerful video functionality, bitmap effects (motion blur, dropshadows, etc) and filters, to name just a few new features. Because version targeting ensures there is no pressing need for Flash developers to upgrade, Adobe needs to continually improve Flash’s feature set to give its customers a compelling reason to purchase an upgrade license. Rather than stymieing progress, version targeting actually encourages technical advances in Flash.

A personal perspective

I worked as a full-time Flash developer for four years, and Flash development still accounts for about half the work I do. Until this week I hadn’t given much thought to the impact of version targeting in Flash, but on reflection I see that it has compelling benefits for end-users, seasoned developers, and Flash novices alike.

Flash has a very healthy development community keen to push the boundaries of their medium, and even though version targeting enables many developers to work at a lower level, I don’t see any evidence that this skill gap impedes advances in the field. I myself still publish content targeting Flash Player 8, and am familiarizing myself with the new ActionScript 3 programming language in the meantime. I certainly don’t feel that I am holding anyone back by learning at my own pace!

I also consider that version targeting goes a long way towards easing the Flash developer’s workload. If I build a site targeting Flash Player 8, I know without testing that it works in Flash Player 9 too, and vice versa. I know too that I will never need to “fix” that site to comply with a future Flash Player release. This forward compatibility is something that I take for granted when I develop a Flash site, and the idea of ‘fixing’ my legacy projects every couple of years seems totally absurd. Yet for some reason this “break and fix” cycle is considered perfectly normal for HTML websites.

What’s good for the goose

Of course, comparing Flash Player with a web browser is not like comparing apples with apples: Flash and Internet Explorer have very different business models; Flash has no serious competition whereas Internet Explorer is part of a busy browser ecosystem; Adobe is free to introduce new features to Flash as it sees fit whereas Microsoft is beholden to various working groups; the upgrade cycle of Flash is driven by web developers rather than software vendors. What works for Flash may not necessarily work for Internet Explorer.

Yet I believe there are enough similarities to draw a comparison. Flash shows us that under the right conditions version targeting can actually be beneficial for everyone involved in the development, delivery, and consumption of content for the web.

Footnotes

* There is only once exception I can think of: new ’sandbox security’ restrictions introduced in Flash Player 7 caused some older Flash applications to break.

The mechanism for triggering the new standards mode is a meta declaration specifying which rendering engine IE8 should use:

<meta http-equiv="X-UA-Compatible" content="IE=8" />

This X-UA-Compatible instruction tells IE8 to render the page using the new advanced mode. If the tag is omitted altogether, IE8 will render the page exactly the same as IE7 would.

During the past week I have read a number of articles and blog posts about the proposed version targeting changes in IE8, and while I am warming to the idea, I still have nagging doubts whether Microsoft’s implementation is the best approach to take.

The future of web standards in Internet Explorer

Microsoft’s stated reason for introducing version targeting is to avoid a repeat of the backwards compatibility issues experienced when IE7 was launched. Although IE7 was embraced by the web standards community as a bold step forwards, it was seen by many within Microsoft as somewhat of a failure. Sites that previously worked in IE6 unexpectedly “broke” in IE7, and Microsoft want to avoid making the same mistake when IE8 is released.

The mantra of the IE development team has always been “don’t break the web”, and version targeting is their way of making backwards compatibility a reality in IE8: the browser upgrade process will be painless for end users, there won’t be hordes of angry web developers hollering that their sites are “broken” in IE8, and inside Microsoft support for web standards will no longer be seen to occur at the expense of customer satisfaction. This last point is particularly significant for the future of web standards in Internet Explorer.

It seems fairly clear that those on Microsoft’s IE development team who advocate for web standards have had to fight every step of the way. I’m sure that there are loud voices within Microsoft who couldn’t give a damn about web standards, and whose greater concern is that when they release a new version of Internet Explorer existing websites continue to render as expected. As Jeffrey Zeldman points out, the inclusion of version targeting in IE8 will smooth the path for standards advocates within the IE team :

“Microsoft won’t be inundated with complaints which, in the hands of the wrong director of marketing, could lead to the firing of standards-oriented browser engineers on the IE team. The wholesale firing of standards-oriented developers would jerk IE off the web standards path just when it has achieved sure footing.”

But the proposed changes to Internet Explorer are not without their pitfalls, I suspect.

Frozen in time

One problem I see with the proposed version targeting mechanism is the potential harm it will do to the adoption of web standards. By the time IE8 is released, standards-aware developers will will be intimately familiar with the X-UA-Compatible instruction, and will be in a position to make an informed decision about which rendering mode they support. But what of the legion of web designers and developers who have a less sophisticated understanding of web standards?

However much confusion may have been caused when IE7 “broke” websites that had previously rendered as expected, at least it forced web developers to acknowledge that the times were changing and they needed to change their methods to keep up. By contrast, if IE8 defaults to using the outdated IE7 rendering engine it is reasonable to assume that many web authors will remain blithely unaware that their sites may not, in fact, be fully compatible with the new standards-compliant browser. There will be no motivation to hone their craft, since in the absence of an X-UA-Compatible directive flawed pages will render just fine.

What about IE9?

Another nagging doubt I have concerns future versions of Internet Explorer. We know that IE8 will use the IE7 rendering engine by default, but what of IE9? IE10? IE11? Will these new versions also default to IE7 rendering mode, which seems to only way for Microsoft to truly adhere to the “don’t break the web” rule? Or will IE9 instead default to IE8 rendering mode, IE10 to IE9 rendering mode, and so on? If that is the case, all that X-UA-Compatible will achieve is to break the web later, rather than sooner.

If we assume that from IE8 onwards all versions of Internet Explorer will use the IE7 rendering engine by default, the implication is that web authors need never improve their scripting skill set, a prospect I find quite alarming. The only motivation to upskill would come from browser vendors who don’t implement X-UA-Compatible (Mozilla and Apple for example), since their browsers will always render a page using the most current implementation of web standards, drawing attention to any scripting deficiencies.

Opting out

On balance I think that version targeting with X-UA-Compatible is a positive, maybe even necessary step for Microsoft to take. As a means of ensuring that future browser releases don’t “break” intranets and public-facing websites, the X-UA-Compatible instruction is perhaps the only viable solution. It also allows the IE team to continue to implement web standards in their browser without fear of angering the corporate customer base on which Microsoft depends.

But the fact that IE8’s new standards mode will be opt-in seems somewhat counter productive. The message it sends to web developers is that adhering to web standards is optional, rather than necessary. The implementation of web standards in browsers may be far from perfect, and it’s a pain when new browsers break existing websites, but this instability also provides a motivation for us to continually improve the way we build websites.

Might it not be possible to require authors to opt-out of the new rendering mode instead of opt-in? If this were the case, sites that break in IE8 could still be fixed extremely quickly using the X-UA-Compatible instruction:

<meta http-equiv="X-UA-Compatible" content="IE=7" />

There would be no need for developers to spend painful hours or days debugging sites that break in IE8. This single line of code would force IE out of its advanced rendering mode and into IE7 rendering mode, fixing any compatibility issues instantly and permanently.

Then again, perhaps like Eric Meyer I will come to fully appreciate Microsoft’s implementation of version targeting. God knows we’ve had enough browser sniffing, code forking and CSS hacks in our industry’s short history, and just maybe this could be a way to leave that mess behind for good.

One of my work related New Year’s resolutions was to plan projects more effectively. Last year I frequently found myself juggling half a dozen or more active projects and it was difficult to keep track of the bigger picture - project deadlines would frequently clash, and managing my workload and client relationships became a delicate balancing act. I desperately needed a better system for planning projects, and software to help me implement the system.

I started out by making a list of features the application needed to have:

• Web-based, so it can be accessed from any computer
• The ability to keep projects separate from one another
• A calendar to which meetings and project milestones can be added
• To-do lists for keeping track of upcoming tasks
• Gantt charts (or similar) to provide a visual overview of time allocated to each project

Why not Basecamp?

I have always had great success using Backpack’s to-do lists for day-to-day task organization, so the obvious place to start my project management hunt was with its big brother, Basecamp. Sadly, I found myself frustrated by Basecamp’s lack of features.

Most conspicuously, there is no standalone calendar in Basecamp, or any way to keep track of meetings and events that occur at a specific time of day. Nor is Basecamp able to display Gantt charts, even in their most basic form. The folk over at 37signals, the developers of Basecamp, have firm views about Gantt charts and it seems extremely unlikely this form of project visualization will ever find a place in their software. Since my goal is to gain an overview of all my projects by blocking out time for them in my schedule, some sort of simple project visualization is essential. It’s all very well to set milestones for each individual project, but I also need to know at a glance how the projects relate to one another.

I also got the feeling that Basecamp’s true strength lies in facilitating communication between team members, rather than project planning or task management. I have a contractor working with me one or two days a week, but essentially I am a one man show, so group collaboration is low on my list of priorities.

The rest of the bunch

After turning my back on Basecamp, I did the rounds of its competitors and clones, of which there are many.

The software that impressed me most was Zoho Projects, which actually met all of my technical requirements. The only problem was that the interface was too cluttered for my tastes, and more critically, it was buggy. After clicking a button within the application I would frequently find myself staring indefinitely at a spinning AJAX loader animation. A second click would achieve the desired result, but the experience gave me serious doubts about the usability of Zoho Projects.

GoPlan also looked promising, but reading their forums and blog it became clear that the application receives updates very infrequently, which made me hesitant to open my wallet. I am not prepared to pay an ongoing fee for software that is left to languish by its developers.

Back where I started

After several evenings spent test driving online project management apps, I was ready to throw in the towel. Despite what I considered to be fairly simple requirements, nothing seemed measure up. Then it occurred to me that perhaps Backpack might be flexible enough to do the trick.

Rediscovering Backpack

I have been using Backpack for basic task management for some time, keeping track of the jobs I need to tackle during the day with a simple to-do list. I always assumed this was the most I could expect from the software, but when I dug deeper into its feature set I realized Backpack can also fulfill a more complex project management role.

Organizing projects

When it comes to organizing projects, Backpack doesn’t have an equivalent to the project paradigm which defines most project management applications. Instead it has ‘pages’ which can include any combination of to-do lists, notes - and in the paid version - files and images. However, by dedicating a page to each project it is possible to give each a dedicated area within Backpack, and keep jobs separate from one another.

Using the calendar to plan projects

By upgrading from the free plan to the $5/month plan I gained a standalone Calendar within Backpack. It isn’t possible to add project specific milestones to the calendar, but standard calendar events provide an adequate substitute. And unlike Basecamp, Backpack allows me to specify the date and time of calendar events, which is useful for scheduling meetings.

Another powerful feature of the Backpack calendar is that events can span several days, making it perfect for emulating Gantt charts. For example, a typical website project might require four multi-day events: Pre-Design, Design, Development and Deployment. By creating a separate color coded calendar for each active job it is easy to get a visual overview of the time allocated across all projects, which should make project scheduling far simpler.

File management

Backpack’s paid plans also include the ability to upload files and images, which is handy for archiving mockups, sitemaps, and other project development files.

Group collaboration

When it comes to granting project permissions for clients and other team members, Backpack is fairly lightweight. This isn’t surprising, since it is intended as a task manager for individuals rather than businesses. Unlike Basecamp, it isn’t possible to grant clients or team members access to your Backpack account without requiring them to sign up for their own Backpack account first. This makes Backpack fairly impractical as a tool for client collaboration, however it is adequate for basic collaboration between team members. When you share a page with other Backpack users, they can edit content on that page with full permissions. If the page is part of your paid plan and allows file and image uploads, shared users have access to those features too.

It may not pack the punch of Basecamp or other more complex project management apps, but for a freelancer like myself Backpack is a perfectly viable alternative. If I ever take on permanent staff then I may need to look elsewhere for more sophisticated team collaboration features, but for now Backpack will do nicely.

Andy Clarke has called for the dissolution of the W3C CSS Working Group. Alex Russell has accused Jeffrey Zeldman of hurting web developers and called for a return to the browser wars of the 90s. Jeff Croft has stated that “compliance is f**king boring”. Even Wired has provided coverage of the furore.

This is an issue that has been simmering under the surface for a long time now, and Opera’s suit has seen the gloves come off. As Eric Meyer observes, the timing is bad, but I for one am pleased to see the web community’s frustrations out in the open.

For a long time I think web developers have been afraid of criticizing web standards, for fear of sparking a return to the bad old days when browser vendors tried to divide and conquer with competing proprietary technologies. The W3C and the web standards movement provided a way clear from the browser wars, but today the W3C’s progress has been stalled by internal politics, and innovations now seem to occur largely outside the context of web standards - AJAX and Flash spring to mind.

For my part, I think that talk of a return to the “browser wars” (as it they were a positive force) is unproductive. Like many others I am frustrated by the snails pace with which the W3C seems to function, and would love to see CSS3 widely implemented by browser vendors so that we can actually start to use it in our daily practice, but I don’t see that turning our backs on the standardization process will bring us closer to that goal. Let’s not lose sight of the gains we have made. Hopefully this fresh debate will put increased pressure on the W3C to fix the transparency and accountability issues that hamper their progress, and they can get the ball rolling again.

I’m about to head off on my Christmas holiday, and don’t have time to give a more in depth analysis, but here are a bunch of articles and blog entries to flesh out the discussion:

Bad Timing - Eric Meyer
CSS Unworking Group - Andy Clarke
CSS Working Group proposals - Andy Clarke
Re: CSS Unworking Group - Jeffrey Zeldman
The W3C Cannot Save Us - Alex Russell
Do we need a return to the browser wars? - Jeff Croft
Year Zero - Jeremy Keith
Reigniting the browser wars - Stuart Langridge
Slightly broken, but not beyond repair - David Storey

Let me explain what I mean.

Instead of naming a div based on where it appears within my layout, I try to name it based on the content it describes. For example, rather than markup a site’s header as:

<div id="header">

I mark it up as:

<div id="branding">

and instead of:

<div id="footer">

I choose:

<div id="siteinfo">

The idea is that in the absence of meaningful, semantic HTML elements with which to markup content I use the most descriptive CSS id name I can think of.

How ironic then, that the new HTML 5 header and footer elements describe content based on where it appears on the page, rather than what it means.

Update 08 Dec 2007: I thought it was worth mentioning that the branding/siteinfo naming structure isn’t one I came up with myself - it is suggested by Andy Clarke in his book Transcending CSS.

For most web designers, especially those who work solo, a custom built content management system is still a tall order. Fortunately there are numerous commercial and open source content management systems available, which offer a practical and affordable means of wrangling content. However, a “one size fits all” content management system that doesn’t address a site’s specific content requirements can introduce as many problems as it solves.

One page, one blob

The easier a content management system (CMS) is to configure and use, the more restrictive it is likely to be. HTML and CSS offer a rich toolset for describing and presenting all kinds of content, yet most CMSs cannot be configured to address the myriad types of content a content editor needs to display. Instead, the content editor is given the ability to modify just one “blob” of content per webpage. This format suits the majority of webpages, but assumes that the content editor is happy to have just one block of plain text per page, or that they are comfortable styling text with regular HTML tags, or a ’simplified’ variation such as markdown. For the novice, HTML is hardly child’s play, and trusting a client to write compliant markup is optimistic to say the least. That’s where WYSIWYG (What You See Is What You Get, pronounced “wizzywig”) editors come to the rescue, and that’s when problems start to creep in.

The WYSIWYG problem

The WYSIWYG editor is at the heart of most modern content management systems, if not by design, then because web designers install one themselves. They are used as a “cure all” by CMS developers and web designers alike, because they provide content editors with a powerful interface for styling content, using a toolset that replicates the desktop word processors with which they are already familiar. The two most popular WYSIWG editors are TinyMCE and FCKEditor. Both use Javascript to enhance a regular HTML textarea, and do so via a menu of buttons similar to that found in Microsoft Word. This probably sounds ideal - a website’s content editor can take total ownership of their content, styling it in any way they please. But content editors are precisely that: editors. They are not designers, and shouldn’t have to - or be allowed to - make decisions that affect the design of their content. Sadly, this is exactly the power that WYSIWYG editors put at their fingertips.

Tinymce in all its glory. Watch your client destroy your layout in mere seconds!

Let loose with a WYSIWYG editor a content editor can mix and match font size, face and color, and even add tables, images, background colors, and emoticons to a webpage. If you think they will have the self control to exercise restraint, think again. Even the ability to alter the appearance of text can have disastrous results. I have seen a content editor use a WYSIWG editor to set body copy in 16 point, 12 point, and 10 point at various places on the same page, and in three different typefaces. Another client inexplicably changed the color of list items to exactly the same blue used throughout the site to indicate hyperlinks. The impact such misguided decisions have on usability and design should be obvious.

Of course the blame doesn’t lie with the content editor. They don’t have training as a graphic designer, nor can we expect them to grasp the subtleties of interactive design. The problem is that WYSIWYG editors mix the description of content (headings, lists, blockquotes) with its design (typefaces, colors, and point sizes). Web designers have long understood the importance of separating content from presentation, but WYSIWYG editors snatch that separation away from us.

Dial it back

Fortunately, most WYSIWYG editors allow you to limit their functionality to suit your needs. This can either be done using a CMS’s administration interface, or by editing a configuration file. When faced with a WYSIWYG editor I dial its functionality right back, leaving only the core set of tools needed to effectively describe content. Does a content editor need to specify background colors for text? Of course not. The size of text? Nope. Paragraph alignment? Uh-uh. Tables? Lets not even go there. I don’t even let a content editor underline text. Why? Because underlined text looks like a link.

Headings (h1, h2 etc), bold, italic, ordered lists, unordered lists, blockquotes, and hyperlinks: these should provide sufficient scope to describe most types of content. Let your regular CSS stylesheets style the output, and you’ll ensure the rendered content fits seamlessly with your existing website layout.

The copy and paste problem

WYSIWYG editors present another problem I haven’t touched on yet. Usually a website’s copy isn’t typed directly into a content management system, it is composed in a word processor, then pasted into the CMS. When this happens the formatting of the source text is brought across too, warts and all. Despite your best efforts to limit your client’s ability to style content, with one keystroke they can inadvertently bypass your safeguards. There are two solutions to this problem. The first involves education. Both FCKEditor and TinyMCE include a ‘paste as plain text’ button, that gives users the option of stripping all formatting from text as it is pasted into the WYSIWYG editor. The only problem is that your client needs to remember to use the button. The second option is more pro-active. Both FCKEditor and TinyMCE have a configuration setting that forces content to be pasted as plain text.

What about web standards?

A criticism often leveled at WYSIWYG editors is that they produce spaghetti code. In part, this is true. The only way a WYSIWYG editor can define the color of text, for instance, is by applying an inline style to your markup. But if you limit the WYSIWYG to a few core capabilities, as I suggested above, there is far less that can go wrong. The developers of WSIWYG editors are mindful of the need for standards compliance, and I have found that in most cases it isn’t hard to get both TinyMCE and FCKEditor to generate tidy markup.

Other options

Building a CMS from scratch is a huge task. I ought to know - most of my websites are powered by a CMS I built myself. Unless you are a competent programmer and have a heap of time up your sleeve (or just enjoy a challenge!), building your own CMS isn’t an option I would recommend lightly, but the advantages of the DIY route certainly pay off in the long run.

Building your own CMS gives you absolute control over how the software functions, allowing you to customize it to your own needs with fine grained control. When something breaks, you know how to fix it. If you want to add a new feature to the CMS, you just go ahead and add it, rather than submitting a feature request to the software vendor and crossing your fingers.

Another option to consider is XStandard, a WYSIWYG editor that touts its standards compliance and accessibility features. The big drawback I can see with XStandard is that it requires the content editor to install the XStandard application on their local machine. By contrast, a javascript based WYSIWYG editor makes your website editable from any computer sporting a modern web browser.

Whichever approach you take to content management, so long as you give careful thought to both your client’s needs and the pitfalls of giving them free rein, it is possible to strike a balance that keeps everyone happy. Giving clients the ability to edit their website’s content, and creating beautiful, standards compliant websites needn’t be mutually exclusive goals.