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.

It didn’t quite take 2 years, at least. But very, very close. The last release of this script was May 25th, 2006 — - so I made it just under the wire. But this is also a bit more than just a script update. In fact, this is a complete overhaul. I’m not certain that there’s actually a single line in the poll script which is the same as the previous version.

This was necessary; because the previous version was, in a word, pretty lousy. It may have acted as a decent jumping off point for some beginning programmers to code their own; but, on the whole, it was not a sophisticated script, and it was nothing like developer-friendly.

This new version, leveraging the power of Google’s Chart API and some clever scripting by Christian Heilmann provides a better end result with fewer potential problems for the user.

I’ve vastly increased the flexibility of the script — - which once could only support a fixed 2 — 5 options in a single question — - to provide support for any number of questions with any number of options, customizable at the question level. I don’t anticipate that anybody will be authoring 100 question polls with this…but they could, in theory.

And, to cap it all off, I’ve added an administrative interface which allows users to perform most of their basic management needs without needing to crawl into the database. Hopefully, it won’t prove to be too buggy.

Are there likely to be bugs in this? Yes! So, if you download this and try it out, please let me know what you notice. I caught quite a few; but I think it’s safe to say that there are a few left in there.

And by “a few,” I mean “actually, there could be a lot of ‘em.”

Check it out or download the package now.

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.

I received an interesting comment from my contact form the other day. I don’t need to respond to it, as the sender left a clearly false email address as their response address, but I do feel that it poses an interesting question for me.

This is the message in its entirety:

Dude how come your example poll have this amazing format, cool graphics, and when I download and installed yours, looks like SHIT?

I mean, thanks for doing this and all that, but come on, you are showing a FALSE example on your web site.

The example poll referred to is this: an example installation of a free MySQL/PHP polling script available on my website. Now, I find it hard to believe that anybody actually thinks of that example as having “this amazing format, cool graphics,” but that’s not really the point: the question is what a “free script” should be expected to include.

This person obviously expected a fully-realized, designed installation. What I provided was nothing but raw HTML and PHP scripting. No “out of the box” styling at all. This is what I generally desire out of a script: if it has a few hooks for CSS and semantic code, that’s great!

I can certainly agree that if you want something you offer to really become a major player in the world of popular downloads, you’ll need to put in a fair amount of work in providing easy template styling, etc. But I hardly think that should be expected for a simple web site add-on.

It leaves me curious: when you download a script, what do you expect of it?

Without both, it’s very difficult to have a successful online business. Unusable web sites have an incredible ability to generate a lack of trust in the business — - as soon as one feature fails to work correctly, or doesn’t behave as you expect, there’s an immediate connection made:

“If they can’t get this right, what else might they have problems with?”

Will they lose your financial data? Will they ship you the right product? Will they bill you the right amount of shipping? What are they going to do with your private information?

It’s hard to fully trust a website which gets in your way when you’re trying to perform basic tasks. The above questions may come up as reactions to pretty severe site problems, such as incorrect product data or frightening error messages, such as this one:

“You cannot do that. This action is being recorded.”

Yikes! Not really an ideal situation. Now, having written error messages before, I can imagine what was meant, which might be better stated like this:

“You may not perform that action. We have logged the error and will work to take care of any problems!”

There are a couple of important differences between those statements.

First, there’s the tense of the statement: we are currently recording vs. we have recorded. The first leaves an ongoing implication that your actions are being monitored which may be a bit disturbing.

Second, we have the indication of what has been recorded. In the first case, it sounds like the system is recording your actions. The second message clearly states that the information recorded was the error which occurred, and assures you that the problem will be worked on.

Maintaining trust in your application depends on good data, clear and non-threatening error messages, and clear task pathways. If your task paths aren’t clear, you may lose users due to sheer confusion. If you aren’t checking your data and perfecting your error messages (and all other responses, of course!) you may lose the visitors trust that you’ve really got their needs in mind.

Working as a web developer, I find myself dealing with a lot of different domain registrars, hosting services, etc. It’s inevitable. It’s also not the slightest bit uncommon to run across one very specific usability inconvenience with how these services manage their services. (Not all of them — - but enough that it’s irritating.)

This specific problem is that when you’re managing domains, some of these services handle multiple-domain management in the following manner:

1. Select the action you wish to perform.
2. Select the domain you wish to change.
3. Rinse and repeat.

It should be readily apparent what the problem is: choosing the action prior to choosing the domain is an extremely ineffective way of making a large number of changes to a specific domain.

Now, the way I tend to work (and I don’t see any great likelihood that this will change) is to focus on a particular site and do everything I need to do on that site in one working session.

End result: if I need to make, say, five changes to a domain, I need to take 10 individual actions. If I selected the domain, and then performed a variety of actions on that domain, I could easily reduce this to only 6 actions.

Even if I needed to work a different way, such as making the same change to a large number of domains, this continues not to be an efficient way of making the same change on a large number of domains, which would be best handled by allowing selection of multiple domains for simultaneous changes.

At any rate, if you happen to be a large company which manages hosting and/or registration of domains, don’t set up your management interface like this. It’s annoying.

End rant.

An interesting thread at Cre8asiteforums, titled “When lots of your visitors go straight to search? discusses a member’s curiosity about navigation patterns after noticing that a significant percentage of his visitors — - 25% — - go directly to search after arriving at his site.

It’s an interesting element of site navigation to investigate, and the thread raises a pretty significant number of additional questions worth analyzing.

The navigation path of any given user will be fundamentally unique. However, when taken in aggregate, navigation paths begin to suggest a lot about your navigation structures. The percentage of visitors who immediately jump into a site search, however, suggests a very different thought process.

On sites which I visit frequently, for example, I generally have a very set system for finding information. If the site has a good search, then I may use the search. If they have a very clear navigation, I may use that, instead. If they have neither, it’s unlikely that I visit the site frequently…but if I do, I generally have separate bookmarks to the individual features which I actually use.

And that raises a separate question — - if a site has difficult navigation and inferior search, what would drive you to actually visit it frequently? For me, the site has to offer some specific information or functionality that I simply can’t get elsewhere. Otherwise, there’s simply no justification for the challenge of using the site.

You can learn a lot about the effectiveness of site navigation by following analytics data. Knowing that most users who use your search feature fail to find what they’re looking for, for example, should suggest that this is a feature of your site which needs work. Finding that users frequently enter several sections of your site before finding the right information can be significant as well — - it suggests that you need to rethink the way your site categories/sections are organized.

So…important question, then: HOW do you follow this? Where do you get this information?

You’re not going to get meaningful user information from standard statistics packages like AWStats or Webalizer. You need to use some tool which will provide a means to track the path of specific users. This can be parsed from your server logs. A high-end statistics package such as Clicktracks will give you user path data. There are a number of other services which can provide this information (and, if you know what you’re doing, you’ve already got the information).

I’m not really an expert on analytics packages, of course. If you want a lot of detailed information about web analytics and analytics packages, here are a few resources:

• Stone Temple Consulting: Analytics Report - Great resource. Extensive commentary and analysis of multiple packages.
• Occam’s Razor by Avinash Kaushik - Blog on web analytics from one of the top experts in the field.
• Web Analytics: An Hour a Day, by Avinash Kaushik - Same author, but you can read him in print.
• Ultimate Web Analytics Comparison - Manoj Jasra - lists numerous packages, providing immediate access to features lists and comparisons between different stats packages. Particularly good for comparing Google Analytics to other packages.