As reported in the Pavingways Blog, YouTube has re-launched their mobile service at m.youtube.com. The site does a really good job of taking a really high-glitz, complex and dynamic site like YouTube and shrinking it down to a highly usable and simple UI that works well on the typical mobile browser.

Unfortunately, the site fails most of the Mobile Web Best Practices guidelines tests and theefore can't be declared "MobileOK." Paging down the list of errors I get from the w3c validator, it looks like most of the errors are down to simply having invalid markup. This is kind of "bush league" stuff and it's disappointing that a first-rate Web property like YouTube is not giving valid markup and adherence to the mobile web best practices more attention, especially considering that Google (YouTube's parent company) has been a key participant in developing the best practices and the MobileOK specification.

As a side-note, if you're going to be in Barcelona next week for the Mobile World Congress, stop by the W3C booth (#7D56 in Hall 7) to find out more about MobileOK and about how to get involved in our next phase of work in the Mobile Web Best Practices working group which will focus on Mobile Web Applications and use of Ajax. I'll be there all morning on Monday talking to anyone who will listen to me and trying to encourage more web sites to get MobileOK!

In June 2005, I wrote about an issue I knew we were going to have to grapple with in the Mobile Web Best Practices group that we were then kicking off. What is the intersection of mobility and accessibility when it comes to Web content? In fact, the initial approach and early work of the group that set the foundations for the Mobile Web Best Practices and for MobileOK was based on the work of the W3C's Web Accessibility Initiative, and specifically the Web Content Accessibility Guidelines document.

This week, we have followed up the release of MobileOK with a new document that details exactly that: describe the relationship between Mobile Web Best Practices and Web Content Accessibility Guidelines. Why should you care? If you're trying to provide a service on the Web, you need to care about both accessibility and mobility. Both of these topics require some investment in skills, tools, and development time, so understanding where the overlaps are should greatly help to reduce development costs and time to market. At the end of the day, it's also about maximizing the potential audience for your service, regardless of a user's disability or the device used to access that service.

In the world of "Web 2.0 Social Network" sites, the current 500 pound gorilla is Facebook. From their roots as a sort of university campus social calendar, they have grown up into an online information and application exchange.

As any Facebook user knows, the service is addictive. The more you use it, the more you want to use it. And if you're an active user, then the longer you're disconnected from it, the more you get the creeping feeling that you're missing out on something.

I had a Facebook moment recently when I logged in after a week or so absence from the site only to find that a number of people had left me messages, some that called for urgent response. It is precisely this addictive nature which makes Facebook such a prime target for mobile use.

Enter m.facebook.com.

The site is very slick and makes good use of available screen real-estate. The key for a good mobile offering is distilling a service down to the information you want to see when you're mobile. Facebook have done a good job at this, putting inbox items and friend updates at the top of the page.

The site's simple layout mirrors Facebook's minimalist web aesthetic. However, the site looks identical across a number of browser/device combinations. On devices with a wider screen, the Blackberry for example, this means the tiny logo is squished incongruously into the upper left, whereas on the N70 browser it fills almost half the horizontal screen real-estate. There could be a bit more content selection going on here, I think (different logos for different screen sizes, maybe)?

As far as the Mobile Web Best Practice guidelines go, it's a mixed bag. The content is encoded in UTF-8 so high marks there. But the markup is not valid XHTML-MP as it declares itself to be according to the ready.mobi checker. This could make a big difference on lower-spec devices with WAP-only browsers. What they should be doing is using the newly minted XHTML Basic 1.1 standard from the W3C which provides compatibility to XHTML-MP renderers.

What's missing from m.facebook.com? For one, any notion of application. By and large, these applications are written for the desktop web site, to fit content into a pre-determined "well" on the page. It's also clear that many of these applications simply wouldn't work very well on the mobile -- many of them are written in Flash, for example. But to truly embrace the mobile platform, Facebook has to make some level of application integration possible. Secondly, the bare bones nature of the site is great for bare bones browsers, but not so great for higher-end mobile browsers such as the Series-60 Web browser. Funny how not 2 months after the iPhone was released there is already an iPhone-optimized (see iphone.facebook.com application but somehow this advanced mobile UI hasn't made it into the m.facebook.com site where it could be made accessible to the millions of users of Nokia Series-60 browser or Opera Mobile. (The iPhone site doesn't work on the Series 60, by the way.) I'd like to see some device/browser detection put in place here that detects the presence of an advanced mobile browser and makes use of these capabilities if they exist to provide a great iPhone-like user experience.

Clearly, a rich, usable mobile Facebook site is a necessity and has already drawn in quite a number of users. When we recently had some trouble with the launch of our adapting proxy solution in the Vodafone UK network, one senior marketing manager remarked to me off-record "what am I going to do on the train now if I can't access Facebook?" So, m.facebook.com fills a need, but it could be a lot more and it could especially do a better job at addressing high-end mobile browsers. Finally, they could be doing smarter browser detection and re-direction (as FlickR, for example, have done) to ensure that users get the interface best suited to their device/browser combination. Furthermore, there seem to be some technical issues with the generated code that need to be resolved.

So, even though the site is great and is one of the few mobile web sites that I find myself regularly using, I have to give it only 6 out of 10.

Finish start-up Jaiku is aiming to take some of the wind out of Twitter's sails by offering a converged mobile-desktop one-to-many short messaging service. Jaiku's founder, Jyri Engeström, calls his service "microblogging" and figures that his and services like them are positioned to "disrupt" blogging. Which leads to the inevitable question of "what could disrupt micro-blogging?" One-word blogging?

Possibly.

More relevant to this blog, however, Jaiku have just launched a fantastic Mobile Web version of their service at m.jaiku.com. The mobile service works very well on advanced and lower-spec browsers. It reportedly works well on the iPhone as well but I wouldn't know (sniff!). It's written in pretty bare-bones xhtml-MP but that works because Jaiku's PC Web site is pretty stripped down to begin with. The mobile site provides you access to most of the functionality you get on the PC site, including the ability to read and write comments on others' Jaiku messages. It also allows you to quickly update your contacts and provides a link to download their Series-60 client.

The client provides a richer user experience, but strangely isn't as full featured as the Web or the Mobile Web site. You can update your presence but you won't see if anyone posts a comment on any of your Jaiku messages. It can scan the Bluetooth area around you but in practice this, combined with the "always on" Internet connection it requires, turns out to be a battery killer. The great thing about the client is the way it replaces your normal Series-60 address book with an instant view into your Jaiku buddies' latest presence information. It also advertises your phone's current status (e.g. "meeting") and your nearest calendar entry (if you allow it to). The other down-side of the client, though, is that's it's Series-60 only.

For the rest of us, the mobile Web version provides you access to the basic Jaiku functions very competently. With a little mobile Ajax though, I think they could have built a slicker UI in the browser. For instance, I'd like to be able to see all my friends' status in some way like I can in the PC client by mousing over their head shot images. The mobile version (and for that matter the PC version) should allow me to toggle "auto refresh" on and off. On the plus side, they are making good use of access keys and they are using UTF-8 character encoding correctly (which aids in internationalization).

Great first effort for what is becoming one of the premier "Mobile Web 2.0" brands out there.

7/10

"Eating your own dogfood" is a rather graphic software industry term that roughly means "practicing what you preach." If you produce a product and you expect users to be using it, but you don't use it yourself, then something's wrong. dev.mobi is a great example of this principle at work. The folks at dotMobi have developed a suite of developer tools and resources for mobile Web developers (irrespective of whether these developers are using a dotMobi domain for their site), including blogs, a great testing tool (ready.mobi) and other articles and resources. The content on the site is fantastic and I highly recommend it to any Web developer trying to do work in the mobile space. More importantly, though, the site and tools themselves are available across a range of devices. The thematic consistency principle is applied here. For example, the URI for a blog post yields a mobile look and feel on the mobile browser and a desktop look and feel on the desktop. And the dotMobi folks have done a great job of taking advantage of browser features. For example, a great CSS based design evidences on the Nokia Series-60 open source browser while a simpler look and feel shows up on the Blackberry built in browser. Scripting could be more effectively used on the advanced browsers, but that's a minor quibble.

dotMobi is really leading by example by delivering this fantasitc site. Keep up the good work.

8 out of 10.