Will HTML 5 replace Flash in the next 5 years?

Author’s Note: This is the first post in what we hope to make series: “Ask a Web Strategist”. These are intended to be relatively short, public answers to questions web technology and strategy we receive. Do you have a question? !

Question: I’m all bent out of shape about the Flash vs. HTML 5 debate. I’m interested to hear your opinion about it. Will Adobe Flash still have a place on the web in 5 years?

Answer: Generally, trying to predict where any technology in a field susceptible to rapid change will be in 5 years is a losing game. Flash will probably be around for many years to come, but we’d bet on a much smaller place.

Continue reading Will HTML 5 replace Flash in the next 5 years?

Typekit: the font solution we’ve been waiting for?

Ask any front end web developer to describe common challenges involved in converting (or “cutting”) a design. Ask a designer who’s savvy about front end web technology what the biggest creative limitation of the web “canvas” is. In both instances, you’d likely hear an earful about fonts.

For the front end web developer, it’s all about taking someone else’s creative – often designed on a highly controlled and extremely flexible canvas like Adobe Photoshop – and implementing it in the much less controlled and much less flexible world of HTML/CSS/JavaScript. Sometimes, a design that look great as a static image or storyboard just doesn’t translate well into web code, especially when not-so-design-sophisticated clients have to maintain the content and some of the imagery.

Fonts have long been a classic example. A storyboard designer can use any font they have installed on their own computer to make a beautiful design, but hacks aside, web browsers have only been able to render text with fonts installed on the visitors’ computers. Since there are only a handful of fonts that are more or less guaranteed to be on  all modern computers (think Arial and Times New Roman), websites have been limited to a handful of uninteresting choices.

Continue reading Typekit: the font solution we’ve been waiting for?

Google Chrome Frame: Why they did it and why it probably won’t work

On September 23, Google released , an add-on for Internet Explorer (IE) 6-8. Chrome Frame allows websites to request that IE visitors use the rendering engine behind Google’s speedy Chrome web browser instead of IE’s native engine. A TechCrunch synopsis and the provide further explanation. This article offers strategic insight into why Google is aggressively pushing their own browser technology, whether Chrome Frame will succeed, and how Chrome Frame should be seen by web development clients.

Chrome Frame

Ask any web developer what they think of Internet Explorer 6 and you’ll hear an earful. The 8 year old web browser still commands nearly 20% of the browser market and is woefully inadequate at supporting modern standards, incurring millions of dollars for legacy support every year. IE 7 and 8 were big improvements, but as we’ve opined on before, even IE8 fails to support forward looking techniques supported by the competition.

In the 6 month since IE8’s release, competitors Firefox, Chrome, Safari, and even Opera, have all seen major updates. All of them introduced performance upgrades, in particular to their JavaScript engines. JavaScript is increasingly the engine for dynamic content on websites, from animations to on the fly content loading without page reloads (via AJAX). Google’s browser, , positioned itself from day one as focused on performance, JavaScript performance in particular. At least in theoretical tests, it more than delivers on its promise.

Continue reading Google Chrome Frame: Why they did it and why it probably won’t work

3 simple examples: why Internet Explorer 8 disappoints web developers

UPDATE: Paul Thurrott, a Windows journalist, has featured some commentary on our post over at his Winsupersite. Check out his post, and the great discussion below it! Thanks for the input, Paul!

have me concerned that there’s a growing and false notion that IE8 is just great, and its rendering problems are the result of web developers writing non-standard code optimized for IE7.

To understand why IE8 is a legitimate disappointment, we need to start by providing background on how different browsers impact web development, both from a cost and design standpoint. If you think you already have a handle on this, you can skip ahead to our 3 straightforward examples of IE8 disappointments.

Continue reading 3 simple examples: why Internet Explorer 8 disappoints web developers