This new book from Packt Publishing & Nirav Mehta is a quick and effective introduction to developing websites specifically targeted at mobile device users. I say “users” for a reason — - one of the strongest advantages to the book is a strong focus on considering your user and their needs as a key element of mobile web development.
My overall reaction to this book was positive. It covers a wide variety of key issues for mobile web programming in an easily understood manner. The book is targeted primarily at developers who already have some experience at web development and design, so it doesn’t delve into any serious detail when it comes to server-side programming or HTML coding, but instead makes a point of emphasizing places where the mobile web is different from internet interaction on a desktop device.
Mehta goes out of his way on many occasions to emphasize the serious importance of considering who (and what!) will be using your mobile web application.
“Any website accessed from a mobile device is mobile web — - whether it’s been tailored to work on a mobile or not!” Mobile Web Development, Nirav Mehta, page 10
The book covers a wide range of issues — - from developing for mobile devices using a “lowest common denominator” plan to implementing highly dynamic mobile applications which adapt automatically to the device currently in use. The text is easy to understand and follows a logical progression, starting with the mobile web development practices which are most similar to the development of standard web applications before moving into the areas which are very specifically targeted towards mobile devices.
This isn’t to say that the book doesn’t have a few flaws. I identified three areas where I really would have liked to seen better work.
Editing
In general, the copy editing on this text was pretty poor. The editing improved as I got further into the book (or I became more oblivious to it), but the introductory chapters had a lot of problems. There weren’t a lot of typos — - but the grammar was noticeably lacking. The book is rife with sentences like this:
“We will need a recharge of patience if we wanted to watch a movie preview on low speed mobile networks.”
I’m not a member of the grammar police, but I’m certainly sympathetic. Professionally published books simply shouldn’t contain the kinds of errors found in this book.
Code Examples
The author talks about following web standards as a critical element of mobile web development. That’s great. It is, however, a serious pet peeve of mine to see code examples which don’t reflect the text of the book. The very first code example in the book is this:
<link rel="stylesheet" type="text/css" media="handheld" href="mobile.css">
The text preceding it states “Here’s how you can add an alternative stylesheet link in your XHTML page.” I see a problem here. Yes, the author does explain at a later point in the book that all XHTML elements must be closed: but it’s a simple fact of life that most people referencing this book will be far more likely to simply reference the code as is. This is simply a mistake; but it’s not one that should have made it through a review of the book.
I’ll admit that I haven’t gone through and checked the validation of every code example. Most of them seemed solid and accurate. There are definitely examples which wouldn’t be valid under the XHTML DocType, but I’m not adept enough with XHTML-MP to know off-hand if the same is true within the mobile profile DocType.
Appendices
Simply put, there aren’t any. There were numerous points in the book where I thought to myself that an appendix would be great. A list of resources cited by topic, a section summarizing the syntax of VXML, tables showing the differences between XHTML and XHTML-MP or between CSS and WCSS. These kinds of resources would have been tremendous benefits to the overall reference value of the text.
Overall
This is a worthwhile book. Even though I wouldn’t recommend trusting the code examples, the truth is that you should never simply take code examples as written — - you learn best by taking an example and re-purposing it for your own needs. Mobile Web Development will introduce you to the key issues for mobile web programming and design in a manner which can give you a quick start on mobile web application development.
Here’s the first clue: it’s not creating a pixel-perfect replication of your ideal version of a site in all browsers.
In fact, cross-browser compatibility ultimately has very little to do with what a web site looks like, and a lot more to do with how it functions. It also has relatively little to do with browsers, and perhaps could better be explained as multiple user-agent compatibility.
“Compatibility” (in this context) is not a term which means “looks and behaves identically” — - instead, it may be better described as “performs equivalently under alternative conditions.” But developers and designers tend to most immediately seize upon appearance as the guiding line for cross-browser compatibility.
Of course, let’s be honest: there are a lot of very good reasons for this. Completely disregarding what we may know about the behavior of a site, clients tend to be very visually oriented. They POP their new site open at home one day during development and notice a whole variety of differences which they’re suddenly concerned about. If you’re lucky, they’re opening up Internet Explorer 6 after you’ve gone through the painstaking process of correct its inability to cope with standards-compliant code, rather than before you’ve gotten around to it. That can be awkward…
Another good reason is that despite what I’ve stated above, making the design behave more-or-less identically between different browsers is actually quite desirable. From a usability perspective, a seamless change in interactivity between different user-agents is very desirable. If you’ve ever tried to guide somebody through using a website which delivers a different experience to their browser than to yours, you are intimately familiar with one reason it’s a very bad idea.
But the absolute key to cross-browser compatibility is simply functionality. A lack of cross-browser compatibility doesn’t mean that something looks different; it means that it doesn’t work.
And a good thing, too. Otherwise, compatibility would be pretty well impossible between desktop browsers and mobile browsers. 
With web design, it’s occasionally entirely possible to make two browsers render a design exactly the same…if you assume certain factors will remain constant, such as the user settings described in my last post. If any of those have been changed, everything pretty well goes out the window. As desirable as it is to make your designs look as similar as possible between the various desktop browsers, it always has to be acknowledged that there are limits.
There’s nothing at all that you can do to actually guarantee the same view for everybody; instead, you need to guarantee an equivalent view for everybody. Equivalent in that they will be able to get the same information and use the functions of the site to perform the same actions.
It wasn’t long ago that I wrote an article on authoring an effective text-resizing widget. In that article, I made a point not to espouse the use of text-resizing tools, since it’s generally more effective to allow people to use their browser’s built-in text-resizing functionality.
In fact, browser’s allow you a great deal more control than simply size. Modern browsers can give you extensive control over website text, including dictating background colors, text color, base text size, minimum text size, and link attributes. This post is intended to provide a quick overview of the specific controls for most modern browsers.
Most browsers have fundamentally the same options, although the interface and location in menus is quite variable. Some are more intuitive than others, and some interfaces simply don’t quite work right…
Read more: Refining Text Presentation with your Web Browser: Windows
(Or, more accurately, why the DOCTYPE is no more broken than any other potential switching mechanism.)
In a recent article, “Beyond DOCTYPE: Web Standards, Forward Compatibility, and IE8”, Aaron Gustafson states that “the DOCTYPE [is] unsustainable as a switch for standards mode.”
His argument is based on the problem that many developers and authoring tools now make use of correct DOCTYPEs despite the fact that they are not in fact using standards-based, valid code. Therefore, you can not actually assume that a valid DOCTYPE actually indicates the presence of the type of HTML code it claims.
Yes. This is true.
However, he then continues to state that a reasonable solution for this issue is to create yet another standards-based rendering switch. How is this logical?
Let’s review: the reason the current DOCTYPE switching mechanism is broken is because developers and authoring tools don’t use it correctly. The solution? Create a new switch which…can also be misused very easily.
…we’re really only left with one option for guaranteeing a site we build today will look as good and work as well in five years as it does today: define a list of browser versions that the site was built and tested on, and then require that browser makers implement a way to use legacy rendering and scripting engines to display the site as it was intended—well into the future. Aaron Gustafson
That’s a great idea, except for the minor flaw that there’s absolutely nothing stopping developers from misusing it in exactly the same way they have misused the DOCTYPE. Authoring tools may add an auto-generated list of default browsers, developers may cut and paste from other sites without understanding what they are using (much like some currently do) or (undoubtedly) new browsers will be developed which either ignore these switches or mis-interpret them.
I think that there’s a certain amount of sense in stating the exact state of browsers when your site was launched. I can see distinct value to being able to state that your site was developed and tested on Firefox 3, Internet Explorer 8 and Opera 9.732. I can certainly understand that this can help future browsers understand how to interpret your older code: when Firefox 14 is released, it will (hypothetically) simply incorporate the rendering rules from version 3, apply them, and there you are: a perfectly rendering web site. Complete with all the limitations it had when it was built, and incapable of taking advantage of any superior changes in rendering that a well-authored and standards compliant site perhaps could have benefited from.
I do feel that it is a serious mistake to consider this to be any kind of long-term solution, however. In reality, it’s just another requirement which can be mis-used exactly like any other.
The solution (which is not, of course, a popular one) is actually attentive developers who are prepared to make changes to their sites when new browsers are released. Developing to standards is a great way to ensure minimum requirements for redevelopment: why should we add yet another feature to pander to developers who refuse to observe basic minimum standards of coding?
As announced on the IEBlog today, web standards guru Molly Holzschlag will be working as a contractor to try and get at IE’s standards and interoperability issues. This is pretty exciting news for web standards: Molly is a very highly qualified advocate of web standards, and with any luck she’ll be able to pound her message through the bureaucratic net at Microsoft.
I’m not one of those people who believes that Microsoft actually doesn’t care about web standards, or that Microsoft is willfully ignorant — or even that Microsoft intentionally perverts web standards in their products in order to increase market control. I think that Microsoft’s main problem has to do with scope: the fact that they’ve intertwined Internet Explorer so deeply into the operating system makes for a lot of extra problems in making the major changes required to get any significant change accomplished. Molly is a very dedicated and knowledgeable web standards guru, and I have high hopes that she can accomplish something substantial.
I’m looking forward to seeing what will happen!
IE, the Next Generation. I know – version 7 has only been available for a month and here we standards guys are, whining about it’s flaws. Let’s face it, though: IE 7, though better than it’s predecessor, is ultimately just a clumsy patch job.
Roger Johansson has written up his big wishes, asking for some pretty wishful thinking options such as “Rewrite or replace the layout engine.” That’s a huge demand, and personally, I won’t be holding my breath. Nonetheless, the fundamental principle is right on: Trident is buggy. Other engines are less buggy.
Read more: What we want in IE “Next”
Kelly Ford, from the IE Accessibility Team, posted today in the IEBlog about IE7’s expected behavior with a variety of commercial screen readers and screen magnifiers.
The general sound of things is that IE7 will be compatible (or mostly compatible) with the most recent versions of most assistive technology software.
Although the number of products detailed on the IEblog is quite small, it does cover the better known products in assistive technology, all of which either are currently compatible with IE7 or will be patched for compatibility within the next month.
The information in the post is brief and provides little information about any kind of advanced functionality: however, if you want to verify whether your assistive technology will be compatible with IE7 it’s probably best that you check this out — before you install IE7!
Return to Top
