As we mentioned earlier, there has been an explosion of devices for connecting to the Web. As wonderful as this phenomenon may be, it places a considerable burden on authors (like you). No longer can authors write documents with expectations on how the content will be displayed. This is because each of these devices is a very different medium than the computer – the physical characteristics of the devices are different, the relationship between the device and the user is different, and the cost of using the device is different.
There are a variety of factors that we need to consider when developing our content and authoring our style sheets. Some of these we talk about in the following sections.
The first set of factors deals with the differences between the target devices.
The physical size of the display surface, combined with the graphics resolution, significantly affects how much content can be displayed on the screen and how that content is presented.
|
|
Low Graphics Resolution |
High Graphics Resolution |
|
Small Screen Size |
Single Font Limited Text Icons |
Many Fonts Limited Text Simple Graphics |
|
Large Screen Size |
Few Fonts Constrained Text Simple Graphics |
Many Fonts Full Text Support Complex Graphics |
The table above is a generalization of how the physical size of the display surface and the graphics resolution may affect what content you present to your user and how that content is presented. An example of a device that fits the 'small screen-low resolution' space is the current generation of mobile phones. An example of a device that fits the 'large screen-low resolution' space is the current generation of Internet-enabled television products (like WebTV). An example of a device that fits the 'large screen-high resolution' space is the personal computer. There are no products (that we know of) that fit the small screen-high resolution' space, although future generations of handheld devices may fit this niche.
Looking at the entries in the table, we will see that there are three general issues at stake: font support, amount of text displayed in a single screen, and graphics support.
The graphics resolution affects how many fonts can realistically be supported. If we look at the difference between any two fonts, we will see that fonts differ in the way in which pixels are drawn. If we have very few pixels to work with, we have very few ways of differentiating between fonts.
The physical display size and the graphics resolution affect how much text can be displayed. If the screen is small and the resolution is low, there are simply few pixels that can be used to draw text. For a small display, if you increase the graphics resolution you could increase the amount of text displayed by making the text smaller, but this is generally not a good strategy since the text will become harder to read. As the display gets larger, you have more 'real estate' to work with and can generally display more text.
Likewise, the physical display size and the graphics resolution affect how graphics are displayed. If the graphics resolution is low and a small display size, you have few pixels to work and you are probably left to working with icons. As the graphics resolution increases, you have more pixels to work with and are only constrained by how large you can make the images (which is bounded by the size of the display).
Different device types are very likely to display fonts differently. There are three factors affecting fonts:
Default font
Font presentation
DPI
The most offensive case is where different devices specify different default fonts. For example, a small handheld device may choose to use a sans-serif font while personal computer-based browsers use a serif font. Even between personal computers there are differences. The Macintosh uses Times Roman for a default font but Windows-based computers use Times New Roman.
The presentation of any single font may be different on different devices. If the vertical extent (the height of a font character), the horizontal extent (the width of a font character), and the white space (the space between characters) are not exactly the same, characters may word-wrap differently.
Finally, the DPI (or dots per inch) of the screen may also be different. If the DPI is not the same between any two devices, a 12-point font on one device will appear larger or smaller on another device. The Macintosh display has a 72 DPI resolution and the Windows-based computer display has a 96 DPI. This means that 12-point text on a Macintosh will appear significantly larger on a Windows-based computer.
The display bit depth is how many colors can be shown on the device. If the device supports 24-bit color, 16.7 million colors can be shown. If the device supports 8-bit color, only 256 colors can be shown.
The display's bit depth is different than the bit depth of the image (see Chapter 5). The bit depth of the image is how many colors are in the image or the image's palette. If the image is a 24-bit graphic, that image may contain up to 16.7 million colors. Problems in display may arise if the image bit depth is larger than that of the display device.
Different target devices may use different technologies for their displays. While in this day and age, computer displays are generally comparable in terms of quality, there is quite a variance in legacy and leading-edge display technologies.
Looking backwards, most televisions are still based on NTSC or PAL standards. This means that the color space for these displays is not the same as the color space used on computers. In general, televisions tend to over-saturate pure reds, greens, blues, and cyans. This means you need to be very careful using large fields of these colors. Worse, color saturation varies significantly between television manufacturers. In fact, considerable consumer brand preference is actually based on the nature of the color (over) saturation. This also affects your ability to display images to consumers in which the color of the image is very relevant – such as in apparel advertising.
In addition, most televisions are still interlaced. This means that the odd 'scan' lines for images are draw first, then the even lines, and then the odd lines, and so on. This creates 'jitter' when you try and draw small straight lines: they appear to shake (or 'jitter') between one or more scan lines. This significantly affects your ability to display fonts that have any details (such as small fonts and serif fonts).
Looking forward, some televisions that support overlaying graphics on top of video do not have square pixels. On these systems, the height of a pixel is not the same as its width. This means that if you try and draw a square, it will look like a rectangle, and if you try and draw a circle, it will look like an oval.
In addition, some emerging display technologies are using fundamentally different chemistries and physics that result in different display qualities. Some displays appear brighter, some may have certain tints to certain color values, and others may have different persistency characteristics (some pixels stay illuminated for some time after they are supposed to change color).
The second set of factors deals with the user-agent applications (the web browsers) running on the target devices.
As you may well be aware, there is considerable difference between personal computer web browsers when it comes to element and property support. The differences increase when you move beyond the computer platform to set-top boxes and handheld devices. For example, the WebTV platform does not support the <applet> element and the Palm web clipping platform does not support the <frame> element.
Non-traditional web devices may only support a limited set of file formats or features within these file formats. For example, the Palm web clipping platform only supports JPEG and GIF files (not PNG or animated GIF files). The WebTV platform is also limited on its native support (what it can do on the set-top box), but there are special servers that automatically convert many graphic file formats (such as PNG) to these formats before the user sees the web page.
A great deal of the multimedia on the Web is realized through plug-in decoders like Flash and Quicktime. While these types of plug-ins are well supported by the major browsers, the lack of memory in many non-traditional web devices prohibits their support. For example, the WebTV Classic platform only supports Macromedia Flash Version 1 and the Palm web clipping platform does not support any plug-ins.
The third set of factors deals with the way in which users interact with the device.
You can feel pretty confident that anyone accessing your web page on a computer has a mouse, or something like a mouse, as an input device. A common feature of these types of input devices is that they control a cursor that can move from any pixel on the screen to any other pixel on the screen, moving over any pixel on the screen.
This type of input is not always available on some web devices. For example, on some set-top boxes, your users may only be able to use an up-down-left-right set of keys that moves the cursor in a grid pattern.
Likewise, you can feel pretty confident that anyone accessing your web page on a computer has a full-function keyboard. This means that they can enter any alphanumeric symbol with relative ease.
This may not be the case on some web devices. For example, WebTV does not normally ship with a keyboard. Therefore, many WebTV users must use their remote control for entering alphanumeric characters – quite cumbersome, indeed.
Another important factor is the distance between the display and the user. As the user gets further away from a device, it is more difficult (and stressful) for the user to move a cursor to a small region on the screen.
In addition, the mode of the user may change as well. When the web device moves from the office to the living room, the user will change from an active, lean-forward, posture, to a passive, lean-backward, posture.
The device may also go from a single owner device (like a handheld device), to a single user at a time device (like a personal computer), to multiple users at a time device (like a television set-top box).
So the big question is: how do you deal with all of these factors?
Well, the simple answer is that you do not need to deal with all of these factors all of the time. First and foremost, you need to identify:
What you're trying to do with your Web page (your goals)?
Who is your audience?
The answer to these two questions will help you identify which 'factors' you need to address.
Once you have identified which factors you need to address, you can determine which strategies or combination of strategies are appropriate to your needs.
There are three basic strategies for managing content that targets multiple devices (rather than just traditional web browsers that we looked at in the page and site design chapters earlier):
Content selection
Content generation
Content adaptation
Each of these is described in the following sections.
The content selection strategy means that you have multiple versions of your web page, each version tailored to one or more devices or web browsers.
This is the simplest approach from a technical perspective – all you have to do is determine which web browser is asking for your web page and deliver the web page for that browser. On the other hand, it will require that you author multiple versions of the same document. This can become a considerable maintenance headache if the number of files or the number of devices increases.
The content adaptation strategy means that you adapt an existing web page to meet the constraints of the target device.
This strategy is very common in the Web. AOL and WebTV both perform content adaptation using something called 'proxy servers'. Proxy servers intercept documents as they move between the servers originating the documents (often called origin servers) and the client devices. These proxy servers adapt and cache the documents before passing them onto the client devices.
Unfortunately, proxy servers are not always available and their autonomous processing may lead to less than desirable results.
Content adaptation can be as simple as converting image and audio formats into those understood by the target device (WebTV converts PNG images to the GIF file format, for example), or content adaptation can be as complex as changing the content of the document.
As an example of this, WebTV does not support frames in the set-top box, rather, the WebTV proxy servers convert frames into tables.
A similar approach is being taken by the Wireless Application Protocol (WAP) Forum, an industry group working with the World Wide Web Consortium to define a markup language and protocols for delivering web content to mobile terminals (like cell phones). The WAP architecture calls for 'proxy servers' that can convert between the HTML and XHTML languages into the WAP Markup Language (WML).
The content generation strategy means that you dynamically build a web page that meets the constraints of the target device.
Typically, you would have an XHTML template for each target device, and the content comes from a database. Today, each of these template-database systems uses a proprietary solution.
The World Wide Web Consortium has introduced a new technology aimed at solving this problem. This new technology, called XSL Transformation (XSLT), is a language for transforming one XML document into another XML document. This means that you will be able to use your 'sniffer' technology to determine which browser is being used, and then apply XSLT technology to generate the correct XHTML document.
While the tools are not quite there yet, you can get a taste of XSLT using Microsoft Internet Explorer.
In this exercise, you are going to get a taste of things to come. Specifically, you are going to use the World Wide Web's new XSL Transformation technology to convert an XML document into two different presentations.
1. Run your text editor and type in the following:
<?xml version="1.0"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/TR/WD-xsl">
<xsl:template match="/">
<html>
<head>
<title>Film Library:<xsl:value-of select="filmlibrary/name"/></title>
</head>
<body>
<table border="2">
<tr>
<td>Title</td>
<td>Director</td>
<td>Year</td>
<td>Genre</td>
</tr>
<xsl:for-each select="filmlibrary/movie">
<tr>
<td><xsl:value-of select="title"/></td>
<td><xsl:value-of select="credits/director"/></td>
<td><xsl:value-of select="year"/></td>
<td><xsl:value-of select="genre"/></td>
</tr>
</xsl:for-each>
</table>
</body>
</html>
</xsl:template>
</xsl:stylesheet>
Save the file as movie1.xsl.
Create a new document in your text editor and type in the following:
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="movie1.xsl"?>
<filmlibrary>
<name>Classic Films</name>
<movie>
<title>Beauty and the Beast</title>
<genre>Fantasy</genre>
<country>France</country>
<language>French</language>
<year>1946</year>
<length>90 Min.</length>
<filmtype>BW</filmtype>
<credits>
<director>Jean Cocteau</director>
<producer>Andre Paulve</producer>
<writer>Jean Cocteau</writer>
<story>Mme Leprince de Beaumont</story>
<cinematography>Henri Alekan</cinematography>
</credits>
<plot>Beauty lives in a cottage with her father and
her two wicked sisters. Once day her father comes
upon a strange mansion with an ugly sorcerer named
Beast.
</plot>
</movie>
<movie>
<title>The Bicycle Thief</title>
<genre>Social Drama</genre>
<country>Italy</country>
<language>Italian</language>
<year>1948</year>
<length>90 Min.</length>
<filmtype>BW</filmtype>
<credits>
<director>Vittorio de Sica</director>
<producer>Vittorio de Sica</producer>
<writer>Vittorio de Sica</writer>
<story>Gennarino Bartolini</story>
<cinematography>Carlo Montuori</cinematography>
</credits>
<plot>Told through the eyes of a young boy
named Bruno, <title>The Bicycle Thief</title> is the
story of his father"s struggle to provide for his family
in Rome following World War II.
</plot>
</movie>
</filmlibrary>
Save the file as movie1.xml. Run the file in Microsoft Internet Explorer. You should see something like this:
|
|
Run your text editor and type in the following:
<?xml version="1.0"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/TR/WD-xsl">
<xsl:template match="/">
<html>
<head>
<title>Film Library:<xsl:value-of select="filmlibrary/name"/></title>
</head>
<body>
<xsl:for-each select="filmlibrary/movie">
<h1 style="text-align: center">
<xsl:value-of select="title"/>
</h1>
<h2 style="text-align: center">
<xsl:value-of select="year"/>
<xsl:value-of select="credits/director"/>
</h2>
<p>
<xsl:value-of select="genre"/>.<xsl:value-of select="plot"/>
</p>
</xsl:for-each>
</body>
</html>
</xsl:template>
</xsl:stylesheet>
Save the file as movie2.xsl.
Load the movie1.xml file into your text editor and make href point to the second version of the XSL style sheet:
<?xml-stylesheet type="text/xsl" href="movie2.xsl"?>
Save the file as movie2.xml. Run the file in Microsoft Internet Explorer. You should see something like this:
|
|
How It Works
In Step 1, we specified an XSL style sheet. The first couple of lines are standard boilerplate:
<?xml version="1.0"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/TR/WD-xsl">
They specify the version of XML and the namespace for the XSL style sheet.
The next line is more important:
<xsl:template match="/">
This "/" string indicates that the following template should be applied to the root node of the XML document, i.e. to all of it.
The next dozen or so lines (beginning with <html> and ending with </html>) define the XHTML template. Within this template are some XSL instructions for extracting data from the XML document. Look at the <title> element:
<title>Film Library:<xsl:value-of select="filmlibrary/name"/></title>
The <xsl:value-of> element says that we want to use the element content for the element that matches the value of the select attribute. In this case, we are going to use the value of the <name> element that is a child of the <filmlibrary> element.
Thus:
<title>Film Library:<xsl:value-of select="filmlibrary/name"/></title>
gets transformed into:
<title>Film Library:Classic Films</title>
because 'Classic Films' is the content of then <name> tag contained within the <filmlibrary> tag in the XML file:
<filmlibrary>
<name>Classic Films</name>
That is, <xsl:value-of select="filmlibrary/name"/> is replaced with Classic Films because 'Classic Films' is the value of the "filmlibrary/name" selection used in the <xsl:value-of> element. (One may think of it almost as a programmed find-and-replace technique.)
The next occurrence of an XSL element is in the <table> element:
<xsl:for-each select="filmlibrary/movie">
The <xsl:for-each> element instructs the browser that we want to repeat the following template for each occurrence of the element which matches the value of the select attribute. In this case, we are going to repeat the template for each <movie> element that is a child of the <filmlibrary> element.
Within this for-each loop are a set of <xsl:value-of> elements which put the value of the <title>, <director>, <year>, and <genre> elements into the table:
<tr>
<td><xsl:value-of select="title"/></td>
<td><xsl:value-of select="credits/director"/></td>
<td><xsl:value-of select="year"/></td>
<td><xsl:value-of select="genre"/></td>
</tr>
So even though we have two <movie> elements within our XML file, we only need the one <xsl:for-each> block in our XSL file to perform the same operation on both the <movie> elements. Obviously, we could have as many <movie> elements as we wanted in our file and we would still need only one <xsl:for-each> element to process all of them.
In Step 2, we authored the XML document. Like the XML style sheet, the first line indicates the version of XML that we are using:
<?xml version="1.0"?>
The second line associates the style sheet with our XML document:
<?xml-stylesheet type="text/xsl" href="movie1.xsl"?>
The rest of the document contains the content that gets transformed by the XSL style sheet.
In Step 5, we create a second XSL style sheet. Looking at the first couple of lines in this style sheet:
<?xml version="1.0"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/TR/WD-xsl">
<xsl:template match="/">
we see the same XML version and XSL style sheet namespace identifiers, as well as the <xsl:template> element, as in the previous sheet.
Where this style sheet departs from the previous one is that rather than formatting the XML document as a table, we format it using headers and paragraphs.
Looking at the <body> element, we wrote:
<body>
<xsl:for-each select="filmlibrary/movie">
This means that the element content of the <body> element will be based on each occurrence of the <movie> element in our XML document.
The <h1> element is defined by the following lines of XML:
<h1 style="text-align: center">
<xsl:value-of select="title"/>
</h1>
The <xsl:value-of> element means that the <h1> element will contain the content of the <title> element. Similarly, the <h2> element will contain the content of the <year> and <director> elements:
<h2 style="text-align: center">
<xsl:value-of select="year"/> <xsl:value-of select="credits/director"/>
</h2>
and the <p> element will contain the content of the <genre> and <plot> elements:
<p>
<xsl:value-of select="genre"/>.<xsl:value-of select="plot"/>
</p>
In Step 7, we associate the style sheet with the XML document:
<?xml-stylesheet type='text/xsl' href='movie2.xsl'?>
When we load the XML document into Microsoft Internet Explorer, the document is then transformed using the associated style sheet.
In this chapter, we learned a little about media types:
Using media types to manage different types of web devices
Managing media types using the <style> element
Managing media types using the <link> element
Controlling how documents are printed using @media and @page rules
Forcing page breaks with page breaking properties
We also learned about three types of problems affecting our ability to target different devices:
Device constraints
User agent constraints
Human interface device constraints
Finally, we introduced some strategies for overcoming these constraints. We can author different versions of our content for different devices, use tools that adapt content to different devices, or generate content based on the type of device.
