3. Embedding Images and Media
Few websites are solely
textual, and most both decorate the theme of the site with graphical
elements and embed images and media into the body of the content. As you
might imagine, the watchword for doing this for the mobile variant of
your site is efficiency: Graphics can represent a significant part of
the overall download size of a page, and because each requires a
separate request to be fetched from the server, graphics can exacerbate
the effect of latency in the mobile network.
It's advisable to keep the
number of images in your overall page template to a minimum: perhaps a
logo, a gradient fill, and a few icons. Graphical elements that appear
on each and every page should ideally be cached, so make sure the web
server is specifying a liberal expiry time for such images.
For images within the content of
the site (such as illustrations accompanying articles, images in blog
posts, and the like), common sense should also prevail to give your
users a good experience. Don't use excessively high resolutions for your
images: Although desktop browsers (and some mobile browsers) easily
resize a large image if its dimensions exceed the boundary, you can
waste valuable bandwidth in getting redundant extra pixels to the mobile
device. You may also want to provide highly compressed versions of
photos — using JPEG format, in particular — that mobile devices can
download quickly, even if the quality is slightly degraded. As for
placement within the text, the usage of floating or inline images is
somewhat riskier than simply having full-width images between
paragraphs. Device support for CSS {float:}
rules is erratic, and you probably want to use the full width of the
screen to make the image as discernable as possible anyway.
With images in mobile
sites, you typically need to understand the characteristics of the
target device. Whether it is a logo across the header of the site or an
inline image inside the body of a page, it is important to know what the
width of the screen is, in particular.
Screen dimensions are a vital
part of a good mobile device characteristics database, and you should be
able to key their values off the user-agent header that arrives in the
HTTP request (or the mobile plug-in will do it automatically for you).
Some mobile browsers also provide their screen dimensions explicitly in
the headers: Microsoft Windows Mobile devices use the UA-pixels header
(although its values are sometime wildly inaccurate).
Knowing the physical dimension
of the screen hardware of a device is only a start though. If you are
placing an image in an article, for example, you probably want to
provide a margin around it that matches that given to the adjacent text.
Figure 5
shows an embedded image perfectly sized for the physical screen of an
Apple iPhone (320 pixels wide), but which, with the page's default
padding of 8 pixels, runs off the right side of the screen. First, this
looks bad as it is, but the device now renders a page wider than its
screen. On the iPhone, the browser responds to this by introducing a
horizontal scroll bar (as shown in Figure 6). This is likely to be disconcerting when the user is scrolling down the article and it "plays" from side to side.
An image that takes the
padding and margins of the containing layout into account looks much
nicer and eliminates any horizontal scroll issues the browser might
introduce. In Figure 7, the same image has been reduced to 304 pixels in width (which is the physical screen minus 8 pixels on each side).
But on a rotatable touch-screen device, of course, you immediately have a new problem. When viewed in landscape mode, as in Figure 8, it is the other dimension of the device that becomes the constraint or target.
When faced with these
various dimension-related challenges, you must decide how much work you
want your web server to do to address them and how much you expect of
the device. Will your web server be emitting images perfectly scaled to
the dimensions you need for each type of device and each possible
rotation? Are these scaled on the fly (and presumably cached)? Do you
have vast directories of preprocessed images? If your images are hosted
on another service, such as Flickr, how do you rescale them?
Or should you simply send a
standard resolution of the image to the device, hoping that the browser
can rescale it appropriately? Or explicitly set image scaling in the
embedding markup, using <img> width and height attributes or CSS {width:} and {height:} rules — and hope that the fidelity of the image does not suffer too much?
All of these techniques may
have a role to play. Relying on the device to rescale images is
certainly an option if the target devices are known to be capable smart
phones with fast connections and good graphics acceleration: You can
send overly high-resolution images that the device can scale down and
decide that the increased download time and client-side rescaling
overhead are tolerable. And using conditional CSS is one of the easiest
ways to rescale images for dealing with screen rotation.
But on the whole,
experience would suggest that server-side manipulation of images is
ultimately unavoidable. Some older devices will struggle badly with the
memory overhead of receiving a large image, let alone then having to
scale it — and the responsiveness of the scaling and page rendering
suffers badly as a result.
3.1. Other Media
You can assume that all
mobile devices can support most image formats on a page. You can also
assume that support for any other sort of embedded media is highly
variable.
Embedded video is feasible on
some devices, but the exact nature of its delivery is itself a
challenge. Apple devices don't support Flash, for example, so trying to
embed a classic YouTube video player into a page targeting that device
(and indeed many mid- and low-end devices) is fruitless. If delivery of
video is critical for your website, it's probably advisable to use image
thumbnails that, when clicked, download a video file or start a stream,
rather than trying to embed them in-line to the page. It is still
important to know which video formats, frame rates, codecs, and so on
are supported by each of your target devices, and this is important
information that you can gather from mobile device capabilities
databases.
Flash — or at least on mobile,
Flash Lite — is installed on a large number of devices worldwide and is
available as a plug-in for mobile browsers. However, it is very rare to
see mobile websites using Flash extensively and deliberately, perhaps
because of the well-publicized lack of support for it in Apple's iconic
iPhone device.
The Scalable Vector Graphics
(SVG) standard is supported on many device operating systems and is a
viable option for embedding and displaying line art (such as diagrams or
maps) in a mobile page. However, native support in desktop browsers has
been slow in coming, so few desktop websites use SVG extensively.
Mobile developers may be wary of relying on SVG for their mobile medium
alone.
Support for code-based
elements in pages, such as Java applets or Microsoft ActiveX objects,
should be considered non-existent on mobile devices — although,
fortunately, these are little used on contemporary websites anyway.
