Web Programming

Going more mobile

Oliver Brown
— This upcoming video may not be available to view yet.

I announced limited support for mobile devices viewing the blog recently. That support basically only covered phones with Opera Mini.

Well now I have a WML theme installed so you should be able to view the site with any WAP device.

You can force WML output with any browser though (although most browsers do not understand WML).

Detecting Mobile Phones

You’re first instinct is probably to check the user agent. Although it’s true there are fairly consistent ways to detect a phone from the user-agent there is a better way.

One of the many under-utilised headers that browsers always send (well 99.99% of browsers you encounter will) is called Accept. This is just a list of MIME types that the browser can handle. Since all mobile phones (as well as PDAs can display WML pages, we’ll use this as the basis to detect mobile devices. The MIME type for WML pages always seemed rather odd to me: text/vnd.wap.wml.

if (strpos($_SERVER['HTTP_ACCEPT'], 'text/vnd.wap.wml') !== false) $mobile = true;

Now we need to find out if the phone can accept XHTML Basic (or XHTML Mobile Profile or whatever) in pretty much the same way:

if (strpos($_SERVER['HTTP_ACCEPT'], 'application/xhtml+xml') !== false) $xhtml = true;

Many “real” browsers are inconsistent with regards to the MIME type for XHTML. As far as I know since mobile phones do not have any sort of backwards compatibility issues they all use the proper application/xhtml+xml.

XHTML Compliant - Thrice!

Oliver Brown
— This upcoming video may not be available to view yet.

I tried validating the markup and my site and found a few errors (nobr tag not allowed, span tag not allowed inside a ul and few others) so I fixed them and I’m XHTML 1.1 compliant once again. That is the home page and a few random pages I tried are compliant. There are probably some posts with random stuff that isn’t…

The main reason I did it was for the sake of any mobile browsers that might complain really loudly about bad markup. So I started reading about XHTML Basic what exactly was and wasn’t allowed. Well I couldn’t find anything useful so I just tried validating as XHTML Basic 1.0. I had to remove script tags, style attributes, replace i with em and again, a few other minor things. The end result is that an XHTML Basic version of the site is available to mobile browsers. Since I don’t have a mobile browser to test it on I can’t guarantee I’m detecting them properly yet. If you want to see what it looks like though, just go to Oliver Brown - Basic.

Then I discovered that it’s mainly PDAs that use XHTML Basic and that mobile phones tend to want XHTML Mobile Profile (XHTML MP also called WAP 2.0). Just changing the doctype was enough to get XHTML Basic to validate as XHTML MP. You can check it out at Oliver Brown - Mobile (it looks the same as Basic).

Just to let you know, when browsing the other versions manually all the links bring you back to the normal site - you actually need a browser detected as being a mobile phone for it to work properly.

AJAX problems in IE

Oliver Brown
— This upcoming video may not be available to view yet.

One of the things I’m working on right now (at work interestingly enough) uses a fairly simple JavaScript function that takes a url and an element id and replaces the content of that element with whatever the url returns.

This worked well until I started getting an odd error from IE - Unknown runtime error. Firefox and Opera both handled this fine. After some fiddling I discovered the problem was the type of element I was replacing into - Internet Explorer doesn’t like you replacing the innerHTML of certain elements.

So far I’ve found TR and TBODY don’t work (and I’d guess THEAD and TFOOT too).

Looking good in every browser

Oliver Brown
— This upcoming video may not be available to view yet.

Okay, “every” is overstating it. The site has always looked how it should in Firefox (and Mozilla variants) and Opera as well as almost right in Internet Explorer. And although I didn’t look in depth it seemed fine on Safari when I used a friend’s Mac.

Well now it looks how it should in IE too. Although I did have to do a pretty nasty hack of sorts (but I remain XHTML compliant).

IE supports “conditional comments”. They’re HTML comments in a specific format which IE interprets as special. Overall this is quite a clever idea since the other browsers see them as normal tags and technically my site isn’t using any no standard markup.

The dodginess in IE (if you hadn’t noticed or don’t use IE) is that the graphic behind the Google links bar was 1px to the left. So all I did was put a style definition inside an IE conditional comment to nudge it to the right: <!--[if IE]><style> #linksbar { background-position: 1px 0 } </style><![endif]-->

Apparently you can do cleverer things with the comments like so conditionals on specific version of IE but that’s getting a little silly and if you want that much control it’s probably better to do it on the server so you don’t send every version of a page to every browser…

For more information, check out conditional comments on Quirks Mode.

Going mobile

Oliver Brown
— This upcoming video may not be available to view yet.

Screenshot of OliverBrown in Opera SSR

Screenshot of OliverBrown in Opera SSR

Following my recent discovery of Opera Mini I fiddled around with stylesheets trying to make the site presentable on mobile phones (well ones running Opera at least). And I seem to have success. The image on the left is how it the page appears in Opera’s small screen mode using the “handheld” stylesheet I defined. That’s about 240px wide but it displays okay at anything down to 176px (the screen width of the Nokia N70). Since the modifications are only to the stylesheet the page is still the same size as before (which is rather bloated) Of course if you use Opera Mini this isn’t a problem since it formats and compresses the page before it gets to your phone. For anyone wanting to do something similar, here are some of the things I did specifically:

  • Lower the font size. I’m not sure whether proportional fonts are ideal here - I just set body { font-size: 10px }.
  • Remove the adverts. Most of the adverts are fixed sizes that are too big for mobile phones. Large ad networks probably won’t pay for mobile visitors anyway. Remove them by giving them a display: none CSS attribute.
  • Set a maximum size for images. All the images have max-width: 95% to stop them needing to scroll.
  • Cut down the margin and padding for basically everything. Especially lists.
  • Hide redundant navigation. Most sites have multiple menus that aren’t necessary and a pain to scroll through. In my case I scrapped the calendar.
  • Resize form elements especially textareas. I’m not sure whether it’s practical to try and post from a mobile phone but I don’t want it to be impossible.
  • Use a sans-serif font - they’re more readable at small sizes. More subjective and only an issue really if you can’t read the serif font.

A final note (in case you didn’t guess): the page is using normal XHTML. Not XHTML Basic, cHTML or WML. Although I haven’t tested it on a real phone Opera claims it will display it fine (which could mean it only works in Opera Mini - but it’s free and apparently better than any other mobile browser out there). cellphones, mobile phones, mobile browsing, browsers

Language learning ideas - bringing it all together

Oliver Brown
— This upcoming video may not be available to view yet.

This post, like many of my others on the topic ramble a bit. You have been warned :P

Any regular readers I might have will know how much I like Pimsleur products for learning experience. I believe the basic idea can be greatly enhanced with computers. I did in fact try a short time ago but suffered from a lack of voice talent which is where speech synthesis could be useful.

Synthesised voices can be imported into the current system (which at the moment I wouldn’t be able to demonstrate since the voices need to be licensed if they are to be distributed) just by recording them to audio. This solution would allow maximum support since any browser with audio capabilities could use the system.

There is an advantage to using the IE plugin though (or any other system supporting SALT) - speech recognition. It should be entirely possible to actually have a browser based system that checks your pronunciation which would instantly make it better than any system out there.

Quite why none of the companies that create these synthetic voices have tried to develop a system like this I don’t know…

An introduction to SALT

Oliver Brown
— This upcoming video may not be available to view yet.

The speech engine that I was talking about in my last article about speech synthesis is an add-in for Internet Explorer. Follow these instructions to install it yourself (you can get Microsoft Speech Application Software Development Kit (SASDK) Version 1.1 now though).

To actually create speech enabled web pages, you need to use SALT. Speech Application Language Tags is now fairly standard and being supported by Microsoft means it is almost guaranteed to survive in some form. SALT is an XML markup so you would generally embed it straight into a HTML (or more usually an XHTML) page.

The first requirement is to add the SALT namespace to your XHTML document: <html xmlns:salt="http://www.saltforum.org/2002/SALT"> This probably isn’t a requirement but you should do it anyway. The next thing you need to do is to load the add-in and tell it what to handle. This is definitely vendor specific and only applies to the add-in for IE: <?import namespace="salt" implementation="#saltobject" /> All the code does is create an object and then tell it what namespace to look for SALT tags in (in this case the “salt” namespace). There is one potential sticking point. The standalone IE add-in is not the same as the one you get if you install the whole SDK so for debugging purposes so the classid will be different.

After that it’s just a matter of adding the SALT tags for handling the speech. In this article I’ll just deal with the simplest one, prompts. A prompt is just a piece of speech. Just write your speech inside a <salt:prompt> tag: <salt:prompt id="InstructionsPrompt"> Hello. Thank you for using this salt demo. </salt:prompt> The id can be anything you want as it is only used to uniquely identify the prompt.

We now have to get around the semantic separation of form and function: this simply defines a prompt and doesn’t actually do anything with it. To actually make it do something we have to use JavaScript. Prompt objects all have a Start() function accessible from JavaScript so to make it play, just call InstructionsPrompt.Start(). Although it’s not an ideal solution for testing purposes just attach it to the onload event of the body tag. You can see (and hear) the whole SALT demo.

A final note about voices. Windows XP comes with a good voice called Microsoft Mike, but this may not be the default. Some of the others sound really bad. To set Mike as the default: Start -> Control Panel -> Speech -> Text-to-speech Windows Vista will come with new voices (the ones made from sampled sounds I talked about before), one of which is called Anna.

Google and bad markup

Oliver Brown
— This upcoming video may not be available to view yet.

I had quick look at the source HTML on Google Analytics (specifically the first page: executive summary) and saw a piece of really bad markup: They had the whole page (HTML, HEAD, BODY, the lot) wrapped in a DIV tag… Naughty Google.

More stable server

Oliver Brown
— This upcoming video may not be available to view yet.

The server should now be up far more often.

I can’t work out why MySQL and/or Apache keep crashing so often so as an interim solution I’ve just written a PHP script that is run by the cron daemon that checks each if they are running as they should and restarts them if they’re not. Hopefully this means if the server is down it shouldn’t be for more than an hour.

Netscape for web developers

Oliver Brown
— This upcoming video may not be available to view yet.

There is an article on MSDN about how to get round the ActiveX activation issues that will be introduced into IE shortly. On that page it mentioned something I didn’t know - the latest version of Netscape Browser (version 8) can use Internet Explorer’s rendering engine (Trident) instead of the Mozilla rendering engine, Gecko.

If you develop web sites these days you need to make sure you can support at least IE and Firefox and preferably Safari. Testing Safari is often not possible if you primarily use Windows but testing in IE and Firefox can now be done from the same browser - you can actually change rendering engine at any time with CTRL-SHIFT-E. It also supports all the cool developer features of Firefox (like the DOM Inspector (although if you are using the IE rendering engine you can’t just click an element to select it).