The pulse of Alexander Interactive

PSFK has published a report (disconcerting, damning or riotous, depending on your station) showing that many top luxury brand websites don’t function on the iPad. (That image above is the Prada home page.) Given that Apple buyers are often luxury product consumers, this is a glaring omission for some of the world’s strongest brands.

The iPad is a reminder that the web is now rapidly moving away from the “build a website, let it run” strategy. A growing diversity of web-enabled devices is going to force companies to build websites that make usability the prime directive. The direct problem is the use of Flash, but the real issue is the lack of universal accessibility.

The growth in broadband mobile networks has led to rapid adoption of web access by consumers. Smartphones are nearing 20% of the American cellular marketplace and are expected to reach 30% soon. Ai clients saw growth in mobile traffic as high as 600% over 2009 alone.

The iPad is the latest and most profound bellwether in this usage shift. Contemplating how to service users with 1.5″ BlackBerry screens was one thing; dealing with iPad users, with their 1024×768 screens and just-like-a-laptop-only-better expectations, is entirely another. And while the iPad may be just a first step in an evolution, a million unit sales in a month suggests someone found the keys to the steamroller.

Computers are not going away; manufacturers shipped 68 million of them in 2008 alone. More important is the fragmentation of the marketplace, which, years after homogenizing almost entirely in Internet Explorer for Windows, is now an open landscape. Four different browsers have substantial (greater than 3%) market share. And dozens of devices are now displaying web pages in displays ranging from 320 to 1920 pixels in width, both with and without Flash.

The requirement for 2010, then, is to adapt to the fragments. Good websites need to actively identify visitors’ platforms and deliver user-centric results–not just the Amazons and Facebooks of the web, but the many small- and medium-size sites that encourage exploration and engagement. As platforms continue to diversify, creating flexible, accessible sites is a must.

A new element introduced in HTML 5 is the <canvas> tag which can be used to draw graphics by means of a scripting language such as JavaScript. In the markup, it acts very similar to the HTML <img> tag, but there is no need for src or alt attributes – only width and height can be used, but both are optional. With no values given, the area will default to 300px wide and 150px high. Below is a simple example of what the markup would look:

<canvas id=”draw” width=”500″ height=”300″>
<p>Your browser does not support the canvas element.</p>
</canvas>

While <canvas> does not require a closing tag in Safari, it is required in Firefox and is best practice to always use one so the element will render properly in all supportive browsers. The <p> is used for alternative content when a user’s browser does not support <canvas> – an <img> can be used here as well. Alternative content could not be utilized if a closing tag is not used. An id attribute is used in the code sample in order to identify the element in the JavaScript.

Like all other HTML elements, <canvas> can be styled with CSS (margin, border, etc.) but those styles will not be applied to the actual content within the <canvas>. In the example below, a dotted border is used to display the actual <canvas> element:

Your browser does not support the canvas element.

When viewed in a supportive browser, two rectangles should be seen above – One green, one opaque blue. This example is quite simple and just a mere demonstration of the ability to draw with JavaScript.

One of the nice features of the <canvas> element is text replacement, generally tackled by sIFR (Flash-based text replacement). Cufón is a text replacement method which utilizes the <canvas> as a means to display copy with the specific font of choice. One major drawback to the Cufón method is the amount of HTML code generated, making a simple heading element bloated enough to make a developer cringe. While it is better than sIFR, with the need for a third-party (Flash) plugin to be installed, it is still not a perfect means for text replacement.

Accessibility with the <canvas> element is a concern for many developers. There are no current native methods to generate markup from the content produced within the <canvas>. Using alternative content can be helpful but it must be manually input by the developer, and it will not be true to what the element’s actual content is displaying.

The methods used to create <canvas> content is rather pain-staking, considering the end result. Drawing with JavaScript creates many lines of code, and the end result does not seem worth it. Some great examples of what people are cooking up with this new element are located at www.canvasdemos.com. There are definitely some cool effects that can be used to make a website more lively, but in terms of practical use I don’t foresee a heavy use of this new element. It seems to be more application-driven for a specific purpose (see: Tiny Doodle), which most websites will have little to no use for. Once <canvas> becomes more widely-used and supported it is likely that scripting libraries, similar to MooTools, will be built. This would enable developers to create <canvas> content with much more ease.