One Website, Many Designs | Part 2: The Platforms and Devices

In the first installment of this article (One Site, Many Designs: The Change in Mindset) we stated that designers need to think about websites, first and foremost, as a tool for organizing and presenting information. That organization is best represented by a site map, which describes how the information is presented in topical categories and identifies key navigational prompts.
As a general rule of thumb a user should be able to find the information they want within three clicks, however, some details may, appropriately, be more deeply embedded. It is important to remember that the average user’s attention span is short; most will make a decision and click the next navigational link within four to eight seconds, and few will spend more than thirty seconds drilling down into a site if it’s not resulting in substantial progress. If they can’t find what they want quickly, most users will abandon a site and move on to another.

That said, let’s assume you have a solid site map. The information is well organized and the navigation is clear and concise. Now you’re ready to design and code. What are the constraints for your design and what considerations should you keep in mind as you proceed?

One major factor that will affect both your design and coding practices are the devices you need to support. Should your site be made to support only new computers or should it support old computers? Do you need to support cell phones, Blackberries, and iPhones? How do you decide what to support?

In part, the devices to which the site must be accessible depends on the user-base. Your users and their choices affect the devices they may be using to access your site. Younger users are, for example, more likely to be accessing your website with an increasingly high number of handheld devices like cell phones. The same is true of business users, however business users are more prone to use Blackberries while younger users may have a higher usage of iPhones.

Let’s take a look at the some potential types of visitors and examine some of the devices they may be using:

• The younger user—Uses computers and, at the highest rate of any group, uses handheld devices. The handheld devices may be any generation of cellular device with a higher frequency of iPhone usage than any other group.
• The business user—Highly likely to use computers, primarily with Windows and Internet Explorer (IE). Increasingly likely to use handheld devices with the greatest number being Blackberries or Palm devices. Use of the iPhone, however, is on rise in this group.
• The elderly user—Most likely to use a desktop computer. More likely to have an older browser and lower screen resolution. Possibly has special concerns related to ease of reading (font-size, larger icons, etc.). Least likely to use handheld devices, but the use of handheld devices is also on the rise in this group.
• The less affluent user—May use computers or handheld devices. If using a computer, it’s more likely to have a lower screen resolution. If using a handheld device, it’s more likely to be a cellular device and less likely to be a Blackberry or iPhone.
• The more affluent user—May use computer or handheld devices. If using a computer, it’s more likely to have a higher screen resolution. If using a handheld device, it’s more likely to be a Blackberry or iPhone.
• All users—Likely to print pages from your site, although pages containing text copy or reference material are more likely be sent to print than graphical or multimedia pages.

These days, there’s a whole host of devices that can browse the web and access your site. Many are under the control of your users and you must always examine your user base to determine what devices are more or less important to support on your site. The devices you do choose to support can significantly affect the design and coding practices you use.

Let’s take a look at the various devices and agents you may need consider and examine their impact on site design.

Desktops and Laptops

Computers are, and probably will for some time remain, the most important device accessing your website. All computers use a web browser to access your site. Currently there are several flavors of web browser, and they all behave a bit differently. These include:

• Firefox—Firefox is the predominate browser in use today, used on 47.7% of all computers. Firefox is compliant with most modern coding standards and should be the primary browser in which your site is tested. Your site should always work in Firefox.
• Internet Explorer (IE)—IE is also major tool browser used on 41% of computers, although at three different release levels, each with different behaviors. Currently IE 6 is in use on 14.5% of computers. IE 7 is used on 21.3% of computers, and IE 8 is used on 5.2% of computers. IE 6 does not support a full set of modern CSS (cascading style sheets) capabilities. IE 7 does support most current coding standards, and IE 8 has become much more strict on compliance with modern coding standards, favoring more modern code and CSS. In the case of IE you need to ensure your site is coded to support IE 7 and IE 8. Note that the use of IE 8 is expected to increase over time. You should also ensure you provide a graceful degrade path for IE 6 users, although the importance of IE 6 is rapidly decreasing over time.
• Google Chrome—While a recent addition, Google’s new Chrome Browser is now in use on 5.5% of computers. One fortunate thing is that the Chrome browser complies closely to the same standard as Firefox, so sites tested in Firefox will generally work as expected in Chrome. You may still want to test in Chrome, however, because every now and then there is that unexpected anomaly. It is not yet certain how the number of Chrome users will change over time, but having used it myself I’d expect to see the numbers increase as it has some desirable characteristics.
• Safari—Used on only 3% of machines, most of which are Macs. This browser has a fairly minimal impact and has been laden with technical problems. It’s troublesome with Java Script. Fully supporting this browser can often be more effort than it’s worth, and most Mac users have since learned to install and use Firefox as a more viable alternative. One note, however: Safari cannot be completely ruled out. It’s the only browser that works on the iPhone.
• Opera—In use on only 2.2% of machines, this browser somehow manages to stay alive. Personally I think the bulk of Opera users today are web developers testing their sites in Opera, but that can’t be verified with certainly. It’s only my opinion. Considering the return, I would not suggest using too many resources to support this browser.

The use of browsers is changing all the time. For more up-to-date information on browser usage, check the W3C Browser Statistics. (W3C: The World Wide Web Consortium is a developer-driven consortium to establish clear standards for internet development.)

Primarily, the browsers affect how you code your website, but they may also have an impact on design. There are some things that are very nice and desirable which, unfortunately, won’t work in all the browsers you may choose to support. Often when you’re using new options and features you’ll need to insert extra code so your site has a graceful degrade path in less powerful browsers. That can sometimes impact the design, but it will always increase the cost.

In addition to browsers there is another variant in computers and laptops that may affect your design. That is screen resolution, most importantly, screen width. I say width because it’s perfectly fine for a website to scroll up and down. It’s not so desirable for a site to scroll left and right, so you need to ensure the site fits on most screens from left to right.

The general trend is for screen resolution (in computers and laptops) to increase over time. Currently the statistics for screen resolution are:

• Higher than 1024 X 768 pixels: 57%
• 1024 X 768 pixels: 36%
• 800 X 600 pixels: 4%
• 640 X 480 pixels: less than 1%

When it comes to design, it’s always preferable to use as much of the available real-estate as you can. This gives you more room for content and navigational elements and allows better use of white space. Unfortunately, the rule of lowest common denominator applies here. Most developers today are developing to a maximum width of 1024 pixels. When you consider the area taken up by the browser’s chrome (not to be confused the Google browser named Chrome—chrome is the area of a browser that’s taken up by borders, scroll bars, etc.), that leaves you a maximum width of 999 pixels in which you can safely work.

Screen resolutions are changing all the time and it may soon be possible to develop to a greater width, but that time is not quite here. For more up-to-date information on screen resolution, check the W3C Display Statistics.

Handheld Devices

More and more frequently, websites are being accessed with cell phones, iPhones, Blackberries, Palms, and other PDAs. The screen for these devices is about 3 inches wide and is commonly referred to in the industry as the 3-inch screen. The good news is, most of these screens have a high resolution and can often display your website as coded for a browser, and with the zoom utility, most of your site can be made legible to the human eye while in zoom mode.

The bad news is there is still a war going on for standardization, and one of the major contenders, the iPhone, refuses to play nice. Most of these devices allow coders to use a special CSS command (@media handheld) to design alternate display specifications so a site can be made compatible with a 3-inch screen.

The iPhone, on the other hand, is a different animal altogether. The iPhone refuses to acknowledge the @media handheld command and insists on displaying the site as though it were a computer. Additionally, the iPhone uses a minimized version of the Safari browser and allows no alternative browsers to be loaded, so you must support Safari to properly support an iPhone. Lastly, the iPhone will not render flash. And since flash is a very commonly used web element, iPhone users are getting accustomed to seeing a “puzzle piece” (missing iPhone component), in place of what is often one of the favorite elements of a site.

I do find some irony in the fact that after years of complaints about Microsoft creating browsers and software that’s too proprietary, the iPhone, produced by Apple, may yet turn out to be the single most proprietary device to browse the web to date.

All that said, you do need to consider the impact of handheld devices on your web design. If you choose to support these devices there may be some special design and coding involved. For most devices you can use the @media command to provide alternate styling and navigational queues for display on the 3-inch screen. For specific information on how to use the @media option, see W3 Schools Media Types.

If you choose to fully support the iPhone you may find that developing an alternate site for just iPhone users is the best solution. If you do this, don’t use flash. It doesn’t work at all. Also, don’t expect your java script to work. These two restrictions alone will kill most, if not all, of your special effects. In addition, you’ll find the abbreviated version of Safari that’s used on the iPhone also doesn’t support some very common HTML tags, like IFRAMES. If you decide it’s really important to fully support an iPhone, be prepared for some disappointments and a lot of debugging.

Printers

Frequently, your visitors will want to print pages from the site. If you haven’t considered this, the results can be unpredictable, and undesirable. Here’s a few common things you’ll see on sites where the printer has not been considered:

1. Important graphical elements, like the company logo, print as a hallowed out sketch. This occurs when a site uses transparent GIF files and does not provide an alternative print file.
2. The site is too wide. The edges are outside the margins of the printed page and get clipped off. This occurs when the site is designed for display only and alternative margins and rules for printing have not been defined.
3. The text is not legible. This may occur when a light text color was used on a dark background, and the background color does not print. You get the light text on a white piece of paper.

Print devices allow coders to use a CSS command (@media print) to design alternate specifications for print. We always recommend you use this to include a print a line that identifies the site the page was printed from. It’s amazing how many times I’ve printed a page then can’t remember what site it came from and have no references identifying the site on the print-out. For specific information on how to use the @media option, see W3 Schools Media Types.

As always, the additional coding and design can drive up the cost of the site, so you need to decide when and where you choose to provide special support for print devices. This can be done on a site-wide basis, or it can be done selectively on those pages which are likely to be printed for later reference.

Alternate Accessibility

It should be noted that not everyone who uses the web, and possibly not all of your visitors, can easily use standard screen displays. Many people are visually impaired, and if much of your audience is so impaired, this can be a significant factor in site design. If your user base has a high number of elderly visitors this may be an important concern.

In addition to using larger fonts, icons and navigational prompts, there are some other practices you should consider:

1. All web browsers offer the user the ability to change font-size. That ability can be overridden in the code. Some designers choose to do this to enforce the integrity of their design, but in the case where your audience may be concerned with impaired vision accessibility, you should leave this feature available. This can be done by expressing font sizes as percentages, rather than absolute values (pixels or points). This makes your layout less predictable, but more fluid and easier for the end user to adjust it to their liking.
2. Always complete ALT tags and HREF tag titles. In the case of ALT tags, this provides a text alternative to someone trying to interpret the meaning of a picture. It’s spelled out in text. HREF title tags provide a text alternative to links and other navigational elements.
3. Keep in mind that there are also alternative devices for browsing the web. There are text-readers that parse the text portions of your site and read out audible speech. Without ALT tags pictures are meaningless; without HREF titles navigation may be impossible.

Not everyone chooses to develop sites that support test-readers, but most should as a standard practice, at the least follow the guidelines for completing ALT and HREF titles. There’s generally not a huge cost in this simple practice.

Search Engines

Search engines are not a device, but they are an agent which accesses your site and reads the content. If you care about whether or not your site shows up in a search results, you need to code the site to be easily parsed by search engines.

While the science of SEO (search engine optimization) could fill a book, there are several simple practices that can help ensure your site is search engine friendly:

1. Organize the site content into topical categories. Search engines like content that relates to a topic it can interpret by reading the links and text. Search engines look for similar terms used frequently on a page or section of your site and rate recurring terms as being of higher importance. This practice also makes it easier for users to navigate your site.
2. Use simple, clean coding practices with CSS driven layouts. This removes a lot of the code related to layout from the page source and lets the search engine parse the core content, without the need to interpret large blocks of computer code. This practice is also desirable in more modern browsers, such as IE 8 and Firefox.
3. Complete ALT tags and HREF titles. This helps the search engines interpret the meaning of images and graphical elements used as navigational queues. This practice is also desirable for accessibility.
4. Create sites with navigation that degrades gracefully. Search engines cannot always follow links that are driven by java script. Whenever possible you should also provide standard HREF links as an alternate form of navigation. This is also a good practice to ensure your sites can be easily navigated by older browsers.
5. Complete the meta name description tag. This tags contains the description that shows up when a search engine lists a page form your site. It tells the user what they will see when they click on the link, and should be unique for each page in your site.

Conclusion

As you have seen, there are many devices that may access your site. Some of the most important depend on who comprises your user base. Others do not. Regardless, only you can decide which devices are most important for you to support. That’s a choice you should make with a good understanding of the practices and concerns of your user base and the purpose of your site.

In theory it’s nice to say you’d like to support everything at all times, but in the real world that’s not always practical. The more devices you choose to support, the more code you’ll need put into your site and the more testing you’ll need to do. And this will always increase the time it takes to deploy your site and drive up the cost. Thus, this decision needs to be made with respect to other real world concerns: deadlines and budgets.

Organize your site well, follow some simple practices and make reasonable choices with an understanding of who your site serves, and you’ll be fine.