Designing websites for mobile users

Similarly, we can drop in the text-based navigation in the same way.

For some of the pages we use the brokenMobileBrowser function to tell people they can’t use a page from their phone.

That is because in the form we use hidden fields to pass some information back, including a form element that Dreamweaver added for us, which some mobile browsers reject. We could work around it by recoding bits of the page.

Where we’re going
The screenshot in the top left-hand corner of this page shows what one of the site users has suggested as a more iPhone-friendly look for the timer setting screen; thanks to Gavin Law, who created the mock-up with Joe Hewitt’s iUI tool.

There’s no doubt that this is a cleaner implementation of the form than the original web page, but it does look a little, well, iPhoney. So, while it would be possible to just give the form a makeover in this style, it wouldn’t fit with the rest of the site. So, how do you make an iPhone version? The answer is that you wouldn’t start from here.

It’s easy to create a new test in the moblib file based on the HTTP_USER_AGENT, which contains ‘iPod’ for both iPod Touch and iPhone. But then what? Joe Hewitt’s iUI provides useful stylesheets and scripts so, for instance, on/off options on web pages can have iPhone-like sliders to set them.

But if your code is anything like mine you’ll have to work that script into your existing code with a large set of PHP if statements. And, since many of the pag es were created originally by Dreamweaver, there’s a lot of database code at the top of each one, plus a little in the middle.

The simplest option is to design new pages that are optimised for the iPhone ­ and then, perhaps, to give users a preferences setting so they can choose if they want to view those by default, or the ‘real’ pages instead.

But what about all that code? Create another set of pages and you have double the number of queries and recordsets to worry about if you make any database changes.

One option is to take out the database code at the top of each file and turn it into a PHP include ­ you can do this fairly easily by copying and pasting and then simply adding a require statement, along the lines of

with a similar function in each page for its own database code. Then you can have iPhone or other specific versions of the page, but just one set of common database code to maintain. One problem doing this, however, is that you’ll probably break Dreamweaver’s drag and drop functionality for adding fields to the page ­ so don’t do it until you’ve got everything in place.

An alternative might be to strip out the guts of the page itself; leave the database code in place, and include a specific version of elements such as forms, optimised for the type of device on which they’re being displayed.