Planet Mobile Web

The Web OS is already here… it’s just not what you thought it would be. Web technologies are currently powering content and interactions across multiple devices effectively turning the most popular native applications into Web browsers. The end result is a widely distributed and used Web-based operating system. Just not the one you imagined. — Luke Wroblewski

The latest UC Browser version 8.4 for Symbian S60 3rd. Edition  and S60 5th Edition is now available for download at wap.ucweb.com (mobile) and www.ucweb.com (PC) The 5th Edition version also works on Symbian Anna and Belle.

New features in this release incude:

1. UDisk - Cloud storage, integrated with the browser. Each file has an expiration date, from 7 days to infinity. Storaghe limits are relatively low; 70MB for long-time storage and 2GB for files stored up to 7 days storage. UC promises additional storage space will be available in the near future.

2. App Gallery - This is a new tab on the browser start page for quick access to UC's built in "Apps" which are UDisk and The Quick Reads RSS reader introduced in version 8.2. According to the release notes a third app, Bookmark Sync is also part of the app center, however on my N8 and N95 it's not there but is available from the bookmarks menu. According to UC more apps will be availbale soon.

3. Stable Release - Adopting a convention used by the Linux kernal, starting with UC Browser 8.4, even numbered versions like 8.4, 8.6, etc. are designated as stable versions while odd numbered versions like 8.5 or 8.7 will be experimental new feature releases.

4. Spanish Support - Hola! Qué tal todo el mundo? Starting with verssion 8.4 for Symbian and the yet to be released 8.4 for Java, the UC Browser will be available with a Spanish language UI. Support for additional languages is in the works as well.

5. New default theme - Version 8.4 introduces an arttractive new light blue and grey theme. A night mode theme is also preinstalled and over a dozen additional themes are available for download.

I installed UC 8.4 on two Symbian devices, a Nokia N8 and a Nokia N95-3. Installation over the previous 8.2 version went through without a hitch on both phones and retained my bookmarks and settings from the earlier version.

I'd experienced problems syncing bookmarks with UC version 8.2 on both phones. I'm pleased to report that with the N8,  this version seems to have fixed the issue where bookmark sync would not recognize my password. On the N95-3, the browser would silently crash whenever I tried to sync my bookmarks in 8.2. Sadly, 8.4 doesn't seem to have helped, the browser still shuts down with no error message when I try to sync bookmarks.

Other than the bookmark sync issue with the N95-3, the browser worked well. All the sites I tried loaded without error except for Twitter. As has happened with previous versions of the UC browser, I got a 403 Forbidden (Rate Limited Exceeded) error trying to load mobile.twitter.com. This is obviously a Twitter issue, the same error used to appear with Opera Mini, but Opera worked with Twitter to quickly get it resolved. The third party Twitter client dabr.co.uk, which I prefer over the official Twitter web app, works flawlessly with UC Web.

UDisk worked well. I had no problems uploading files as large as 1.2 MB. Cloud storage is a useful feature and having it version built into the browser is handy. However UCDisk is misssing two of the most useful features of other cloud storage services like Dropbox, sharing and access from any browser. There doesn't seem to be any way to share a UDisk file with other users or to access UDisk with any browser except the UC Browser, making it impossible to use UDisk to transfer files between PC and phone. Hopefully sharing and general web access for UDisk are in the works.

UC 8.4 for Symbian is a recommended upgrade for all Symbian users. UDisk seems handy if limited, and the bookmark sync issue is fixed, at least on some devices.

Related Post: New UC Browser 8.2 Adds RSS Reader and Bookmark Backup and Restore

I am speaking at the LTE world series in Barcelona ‏@LTEWorldSeries  #ltews LTE world series Zone 2 – 14:20 – Exploring the Deployment Feasibility for different M2M Markets - only there for a day but still meeting a few people. If you are there – happy to meet – email me at ajit.jaokar at futuretext.com

My wife and I just returned to New York after a much-needed holiday in Amsterdam and Spain. Our excuse for crossing the pond was for Mobilism in Amsterdam, which was an absolutely amazing mobile web conference put on by PPK and company.

I presented For a Future-Friendly Web, which covered how we as web creators can think and act in a more future-friendly way. Here are the slides, video and notes from my talk:

• The web is now a lot bigger than what we’ve been used to. There’s more web-enabled devices than ever: from smartphones, dumbphones, e-readers, tablets, netbooks, notebooks, desktops, smart TVs, game consoles and a whole lot more.
• All of these devices are just the beginning. There’s a whole host of connected devices right around the corner. Disruptions like Google’s Project Glass will continue to redefine our connected world.
• Because change is so rapid, it would be foolish to say that we can create anything that’s really “future proof”. But just because we can’t predict the future doesn’t mean that there aren’t things we can do to be better-prepared for whatever comes down the pipes.
• The power of the web is its ubiquity. No native platform or proprietary solution can claim the same level of reach as the web. This ubiquity is becoming increasingly important as more and more devices emerge. The web’s intrinsic inclusiveness is something that should be preserved and embraced.
• First and foremost we need to create relavent, purposeful content. There’s more stuff than ever demanding our attention, and we as humans only have the capacity to handle so much.
• People’s capacity for bullshit is rapidly diminishing. If you don’t focus your products and services, your users will do it for you. Tools like Instapaper, Readability, Safari Reader, Ad Block Plus, DVR, Bittorrent, and more allow users to get to the content without the crap that typically goes with it.
• As Josh Clark eloquently put it, we need to think of our content like water, and get our content ready to go anywhere because it’s going to go everywhere. It’s bigger than the web, native, Facebook, etc. We need to put our content and functionality in front of users wherever they may be.
• Rethink context. Historically we’ve created assumptions that users are comfortably seated in front of a desktop or laptop with a strong connection, large screen and fast processor. Mobile has shattered those assumptions and now context is a lot more fuzzy. We need to think about the quantitative (screen size, processing power, input methods, etc) and qualitative (user goals, environment, capabilities, etc) aspects of context when designing experiences
• Invest in content infrastructure. Too often redesigns are like slapping a new coat of paint on an otherwise-condemned building. Content is the foundation with which everything else stands. That means creating context-agnostic APIs and more robust, flexible content management systems that lend themselves to adaptation.
• Think more responsively. Responsive web design isn’t about creating squishy websites, it’s to create a more optimal experience across an increasing number of contexts. Unfortunately, many people, both proponents and opponents, miss the point.
• Users don’t care if your site is responsive, a separate mobile site, or even a plain old desktop site. They do care if they can’t accomplish their goals, if the experience takes 30 seconds to load, or if interactions are buggy and broken.
• Mobile is more than just a small screen. We should take mobile’s constraints and opportunities in mind when designing experiences.
• Progressive enhancement is becoming increasingly important. Lay a solid semantic foundation, writing mobile-first styles and using feature detection are good techniques to support more web-enabled devices while still optimizing for the best.
• Entirely separate experiences aren’t scalable in the long run, but building a separate mobile site might be reality. This can be a great opportunity to lay a future-friendly foundation. Don’t wait for the “perfect opportunity” to start taking steps in the right direction.
• This is going to be difficult, but it’s absolutely necessary. It will require all of us working together like never before, so let’s set aside petty differences and realize that we’re all on the same team trying to figure all this out. Let’s keep learning from each other.

I’m truly honored to have been part of such an amazing conference. I saw a lot of old friends and met a lot of new ones too. I’m already excited for next year’s Mobilism!

Some people do a lot of research before they travel. They read guidebooks. They like to know what they are going to do before they get there.

Others want to experience the new place and let the serendipity happen. In their minds, planning ahead would take all of the fun out of the trip.

Either approach works fine. But anyone who has travelled in a group knows what happens when the person who plans ahead is forced to contend with the care free attitude of someone who wants to wait until the last minute to decide what to do.

And that is essentially the conflict we have between the browser’s lookahead pre-parser and responsive images.

What does the lookahead pre-parser do?

In recent years, browser makers have put an emphasis on making pages load as quickly as possible. The lookahead pre-parser is part of their efforts.

The Internet Explorer team describes the lookahead pre-parser as follows:

To reduce the delay inherent in downloading script, stylesheets, images, and other resources referenced in an HTML page, Internet Explorer needs to request the download of those resources as early as possible in the loading of the page.… Internet Explorer runs a second instance of a parser whose job is to hunt for resources to download while the main parser is paused. This mode is called the lookahead pre-parser because it looks ahead of the main parser for resources referenced in later markup.

The lookahead pre-parser is much simpler than the full parser used to determine how the page will be rendered. Because the scripts and css have yet to be processed, the lookahead pre-parser is taking some guesses about what assets will be downloaded:

The download requests triggered by the lookahead are called “speculative” because it is possible (not likely, but possible) that the script run by the main parser will change the meaning of the subsequent markup (for instance, it might adjust the BASE against which relative URLs are combined) and result in the speculative request being wasted.

How lookahead pre-parsers work isn’t that important. What does matter is that the browser wants to start downloading assets before full page layout has been determined. To be successful, the pre-parser needs to know what the page is likely to do ahead of time.

Responsive images travel without a guidebook

If the lookahead pre-parser is the tourist with a detailed itinerary of places to visit, responsive images are the go-with-flow tourist waiting to see what things look like before choosing what to do.

In a responsive web design, the layout and images are all fluid. The size of any given image cannot be determined until the page layout is calculated by the rendering engine.

All of the solutions suffer from this conflict

No matter if you favor <picture>, @srcset, or some other solution, the fundamental conflict between the lookahead pre-parser and responsive images persists. Let me demonstrate with some of the more popular options.

@srcset min-width only

One of the biggest points of confusion for the srcset proposal was understanding what the width and height attributes in the new syntax were supposed to represent.

<img src="face-600-200@1.jpeg" alt=""
     srcset="face-600-200@1.jpeg 600w 200h 1x,
             face-600-200@2.jpeg 600w 200h 2x,
             face-icon.png       200w 200h">

Originally, I thought the 600w 200h in the example syntax represented the image size. But instead, they list the minimum viewport resolution that should be used for a particular image. Think CSS min-width being used in a media query.

Once I understood what the width was meant to represent, I began to see the shortcomings of this approach. Whatever values where listed in srcset would need to match the breakpoints specified in the design’s media queries.

Jeremy Keith pointed out that by only supporting “min-width”, srcset will have difficulty matching breakpoints defined using max-width in CSS. He writes:

One of the advantages of media queries is that, because they support both min- and max- width, they can be used in either use-case: “Mobile First” or “Desktop First”.

Because the srcset syntax will support either min- or max- width (but not both), it will therefore favour one case at the expense of the either.

Both use-cases are valid. Personally, I happen to use the “Mobile First” approach, but that doesn’t mean that other developers shouldn’t be able to take a “Desktop First” approach if they want. By the same logic, I don’t much like the idea of srcset forcing me to take a “Desktop First” approach.

The inability of srcset to match breakpoints defined in media queries is just the beginning of the challenges.

@srcset px only

The @srcset attribute currently only supports px and not other units like ems which we’ve advocated using in responsive designs. Why this limitation? Odin Hørthe Omdal explained why:

You can use em and % freely in your stylesheets/CSS. The values from srcset is used to fetch the right resource during early prefetch, checked against the width and height of the viewport (and only that viewport).

Having ems or % would make no sense whatsoever there, because you don’t know what they mean…If you make a solution that will support em/% in a meaningful way, you would have to wait for layout in order to know what size that means. So you will have slower-loading images, and ignore the “we want pictures fast” requirement.

Sound familiar? It’s the conflict between the lookahead pre-parser and responsive images again.

Without support for ems, it will be very difficult to match srcset attributes to responsive design breakpoints that use ems.

@srcset and <picture> maintenance nightmare

As the challenges of matching media queries to @srcset values became clearer to me, it also became apparent what a mess updating this code would be when a redesign occurred. This is a problem for both @srcset and <picture> as D. Pritchard pointed out on the WhatWG list:

I dread the day when I have to dig through, possibly hundreds of pages, with multiple images per, to update the breakpoints and resolutions. Surely there’s a better way to manage breakpoints on a global level rather than burying the specifics within the elements or attributes themselves.

Unfortunately, no one has suggested a better way yet likely because most of the global rules for a site exist in CSS which is parsed much later by the browser.

A progressive image format

Surely all these problems point out that we shouldn’t be messing around with breakpoints in HTML anyways. What we really need is a new progressive image format (or perhaps an old format used in a new way).

Le Roux Bodenstein describes well the appeal of this solution:

Use a progressive image format and HTTP range requests. Ideally the image metadata at the start of the file would include some hints about how many bytes to download to get an exact image size. The browser can then download the smallest size equal to or greater than the dimensions it needs based on the layout’s width as specified in CSS.

Unfortunately, this description also demonstrates why this approach will also battle the lookahead pre-parser. How will the browser know when to stop downloading the image? It will know based on the size of the image in the layout.

And so on and so on

I could list other proposed solutions. Each has their own merits and problems, but they all suffer from the same conflict due to the fact that the proper size of a responsive image isn’t known until the layout is complete which is too late for the lookahead pre-parser.

No intrinsic cut off points for images

What if we’re complicating this too much. Perhaps we shouldn’t try to replicate the breakpoints in HTML. Instead, we should simply supply different sizes of the image and let the browser decide on the best version.

There are two problems with this idea.

1. How does the browser know when to download each image? At the time of the lookahead pre-parser, it doesn’t know what size the image will be. So it will need you to tell it when to use each size image.
2. If you’re not tying the selection of images to the breakpoints in your design, how do you decide when you should switch images? Should you create three versions of each image? Five? Ten? Should you switch them at 480 because that is the iPhone width in landscape and then lament your decision if rumors of a taller iPhone screen come to pass?

The problem is there is nothing intrinsic to the image that would guide you in deciding where you should switch from one size of the image to another. Whatever we select will be entirely arbitrary unless we base it on our design breakpoints.

What matters more: lookahead pre-parser or responsive images?

Since coming to the realization that the real conflict is between the lookahead pre-parser and responsive images, I’ve been wondering which we should prioritize.

The lookahead pre-parser has been essential to providing a better experience for users given the way that web pages have been traditionally coded. Doing anything that prevents the pre-parser from working seems like a step backward.

At the same time, while it may seem responsive images is an author issue, the biggest impact is felt by users. Downloading images that are too large for the size that they are displayed at makes pages load more slowly. It is possible that the performance gains from the pre-parser could be lost again due to unnecessarily large image downloads.

For existing web content, the lookahead pre-parser is undoubtably the fastest way to render the page. But if web development moves towards responsive images as standard practice, then delaying the download of images until the proper size of the image in the layout can be determined may actually be faster than using the lookahead pre-parser. The difference in size between a retina image for iPad and an image used on a low resolution mobile phone is significant.

It seems like this tradeoff ought to be measurable in some way so we can quantify what the impact would be. I’m not skilled enough to construct that test, but hopefully others can help evaluate it so we can make an informed decision.

Two years later and I finally understand the problem

It has been two years since I first started looking at images in responsive designs. It seemed simple. The <img> tag had one src and we needed multiple sources.

Until the WhatWG got fully engaged in this question, I thought I understood the problem. Now I realize it was much bigger and more difficult than I originally thought.

We have an existential problem here. A chicken and egg conundrum.

How do we reconcile a pre-parser that wants to know what size image to download ahead of time with an image technique that wants to respond to its environment once the page layout has been calculated?

I don’t know what the answer is, but I’m very curious to see what we decide.

1. It is worth noting that the original srcset proposal by Ted didn’t suffer from the conflict described in this post because it didn’t attempt to address responsive images. It focused solely on image density and thus didn’t contain any viewport width declarations.

Great interview of me by Kim Chandler McDonald - who is interviewing innovators worldwide in her Capital I series whose aim is to ‘consistently strove to find people who broke the mold, led the pack, moved their own particular mountains’

This series has included in the past former US Secretary of State, Madeleine Albright; former President of South Africa, FW de
Klerk; film director, Terry Gilliam; theoretical physicist, Brian Greene; and authors John Irving, Amy Tan and Tom Wolfe. (list is HERE)

Very pleased to be in this company. Also the interview itself is long and detailed and I love the depth of Kim’s thinking!

The interview link is - Computer Mediated to Computer Meditated: Innovation Interview with Ajit Jaokar, author of ‘Meditation in the Age of Facebook and Twitter – From Shamanism to Transhumanism’

Seeking Alpha is a big US based stock market analysis and financial site. I recently discovered that it has a mobile formatted layout which it seems to only serve to Android and iOS devices. In Safari, the Android default browser and Android Chrome, the mobile layout is attractive and seems user friendly, although scrolling in both Android browsers feels a bit laggy.

On other mobile platforms like bada, Symbian, S40 and WebOS, Seeking Alpha delivers its desktop layout, which is a bit sluggish and unwieldy, but usable on mobile devices.

But woe to anyone who tries to use the Seeking Alpha site with Firefox Mobile, Opera Mobile or Opera Mini on Android. The mobile formatted version loads in these browsers. It even looks OK with all the page elements laid out in their proper places. But most of the links don't work and pages can't be scrolled.  In other words the page is completely and totally broken! And there's no way to switch to the desktop view either. I didn't try the site in Opera Mini on an iPhone but suspect it breaks the same way there.

The site's designers apparently know or suspect (because they probably didn't bother to test in any other browsers) that their mobile view doesn't work with anything but iOS Safari and the Android browser so they don't serve it to other mobile platforms.  But their browser detection algorithm detects platforms rather than browsers and they end up serving markup intended for the Android browser to Opera and Firefox just because they are running on the Android platform. This is confirmed by the fact that the Opera browsers on Symbian get the desktop version.

The way Seeking Alpha breaks only on non-Google browsers on Android is weird, but one of the perils of building and testing to a specific browser or browsers rather than using a standards based approach and testing with multiple browsers and platforms.

This tendency for web designers to only test against iOS and Android, the so called "Webkit Monoculture", is putting other browser vendors and their users in a real bind. It's pushing Opera and Mozilla toward giving their browsers -webkit- CSS prefix support, and in the case of Mozilla, changing user agent strings to impersonate Safari.  Many in the web design community design community whom I respect think this will do more harm than good. As a user I'm don't know who's right, I just want sites to work no matter which platform and browser I'm using.

Update 3-May-2012: The Seeking Alpha site now works properly in Firefox Mobile but is still broken in Opera Mobile and Opera Mini.

I did a post a while ago explaining how to modify Opera Mini's jad file to hide the unneeded touch keypad that displays at the bottom of the screen on some touchscreen phones. The post included a link to the modified Opera Mini. I received a request asking for a copy of the latest signed Java version of UC Browser modified to hide the keypad.

The process for modifying the UC Browser or any other Java app is exactly the same as what was described in the original post:

1.Download the app's jad file to a PC. You can get UC Browser jad files (signed or unsigned ) at www.ucweb.com/English/UCbrowser/platform.html?platform=java

2. Open the downloaded mini.jad with a text editor or Windows Wordpad

3. Scroll to the bottom of the file and paste in the following lines:

MIDlet-Touch-Support: True
UseNativeTextButtons: hide
ReverseSoftkeys: hide
UseNativeCommands: hide
Navi-Key-Hidden: true
Nokia-MIDlet-On-Screen-Keypad: no

4. Upload the file to Dropbox.com or another file sharing service that is easy to use in your phone browser. Click here to get a free 2GB Dropbox account (by using this referral link I get an extra 250 MB of storage in my Dropbox which I thank you for).

5. Visit Dropbox with your phone browser and click the modified mini.jad link to download it to your phone.

I've posted the modified UC Browser 8.0 jad at:
dl.dropbox.com/u/4637247/UCBrowser_V8.0.3.107_Java_pf70(Build11112416).jad
Short link: is.gd/uc8touch. To install it, go to is.gd/uc8touch with your phone browser.

Update: 21-Mar-2012 UC Browser 8.2 Alpha has been released. It features many enhancements and bug fixes see my review for details. This is the latest patch release that adds swipe navigation and fixes a bug that made entering URLs on bada phones impossible:

dl.dropbox.com/u/4637247/UCBrowser_V8.2.0.132_Java_pf70_(Build12032111).jad
Short link: is.gd/uc82touch. To install it, go to is.gd/uc82touch with your phone browser.

Update: 20-Apr-2012 The Production (non-Beta) version of UC Browser 8.2.1 has been released. New features include a built in RSS reader and bookmark backup and restore. See my review for more details.

dl.dropbox.com/u/4637247/UCBrowser_V8.2.1.144_Java_pf70_(Build12041210).jad
Short link: db.tt/ajY88aHm. To install it, go to db.tt/ajY88aHm with your phone browser.

We are pleased to announce that registration is open for a new edition of the W3C online training course “Mobile Web 2: Programming Web Applications”.

Developed by the W3C/MobiWebApp team and taught by Marcos Caceres, this course covers all techniques you need to know for programming successful mobile Web applications, including:

• Progressive enhancement and feature detection
• HTML5 for mobile
• Javascript APIs for geolocation, device orientation, handling touch events, using local storage, accessing the camera
• Taking applications offline

The 6-week course begins 11 June. An early bird rate of 195 Euros is available until 25 May; after that date the full price is 225 Euros so register no!!

The course is for you if:

• you understand the basics of Web development and would like to understand the specifics of the mobile context;
• you know how to create mobile Web sites and would like to move on to more advanced applications;
• you wish to update your knowledge of Web technology with more recent additions from the HTML5 and Javascript world;
• you want to learn how to package your Web applications so that they can work offline or as native applications.

Read the full course description and looking forward to welcome you on board!

The topic at Mobile Monday Silicon Valley was “Make Money with Mobile Ad Mediation”. Great topic, there’s a lot of activity around mobile advertising right now. Overall my take on mobile advertising high level remains what it was a few months ago: that we have a long way to go before we’re really delivering on the promise of what mobile could be. I’ve started chipping away at a few of those issues with a new project, and in the process dug into the details of the current mobile ads business a lot more deeply than I have in a while. There’s been a lot of attention paid to the supply side of mobile, so it was good to get a nice summary dump all at once. I normally take a pretty geeky take on things, and there were a few points that the discussion glossed over I just wanted to pull back out.

The mobile advertising world has matured pretty quickly. It was really simple to start out with, but it’s since evolved in the same direction as online advertising. So if you’re looking to understand what’s going on with mobile ads currently it wouldn’t hurt to familiarize yourself with how ad serving works online. Picking up on how realtime bidding works is a good idea too, cause RTB is one of the hot button items in mobile. Everyone is spinning up an exchange.

Mediation is a supply side technology. Generally speaking the folks who use mediation in the online world are at the upper end of media sophistication. They have particular constraints, such as having an in-house sales team that sometimes commits to high value campaigns. For them the mediation layer takes care of swapping inventory between what they sold themselves and what they want to put out on the general market.

Users of mediation in mobile range all over the place though, not just the upper end. The particular technical requirements in mobile, and mobile applications in particular, have a lot to do with that. One of the initial reasons for developers putting mediation in their apps was so that they could experiment with different ad networks without having to wait for an app approval cycle. In the online world if I want to try out a different ad network it’s a relatively easy thing for me to put the new ad network code up on my web servers and the swap is almost immediate. However in mobile if I want to try out a new ad network in my iOS app I might have to wait a week or longer for the app to go through Apple approval. And even then, if users don’t update they still see the old advertising setup. Some users update their apps very infrequently, some users not at all. In the mobile world the mediation layer is playing a bunch of additional roles it doesn’t necessarily have to fill in the online world.

Even though a lot of the discussion around mediation is around maximizing fill rate and increasing your effective payout, keep in mind the base tech requirements if you’re looking at doing a mobile service and considering how to setup advertising. This is the point that the Google mediation services for AdMob seem to really drive at. That you can start out with AdMob, and then turn on mediation down the line. Which doesn’t really seem like a huge deal, but keep in mind that approvals time and upgrade cycle for consumer apps and it sounds more appealing. You can do the same effectively with some of the other services. Just pay attention to the need to install the SDKs for other networks along with the mediation tool – if you have to that’s a signal that you might not be getting as much flexibility as you would like.

The really important point to underscore is that if you abstract the decision of how to serve ads and offload it to a server right off the bat instead of baking it into your binary you’re potentially saving yourself a headache.

MobiWebApp is collaborating with the Mosquito European project on a series of events three weeks from now, from May 29th to 31st in Paris.

The event combines a workshop on challenges around mobile Web with a set of presentations from a variety of perspectives on May 29, followed by an interoperability event on May 30th and 31st, where more than 40 mobile devices will be made availabe to participating developers to test their Web applications, and report the main interoperability difficulties they enounter.

Learn more about this and related efforts on the W3C site.

Arriving back in London from a business trip to New York last week, I was expecting a moderate wait in the immigration queue, after all it was 7:45am on a Saturday and this was Terminal 3 not Terminal 5.

Seeing 10 – 12 rows of people in the queue (I estimated there were well over 500 people in the queue ahead of me) I knew I was in for a long wait. It took well over an hour to get through immigration.

This doesn’t have to be the case though.

Until February this year, I would sail through immigration, even though I am an Australian citizen resident in the UK,  I was able to use the “IRIS” retinal scan system as a registered traveller.

I would submit my eyes to a quick scan (I got used to standing in the exact position for a perfect scan) and in 15 seconds I would be through immigration!

When I tried to renew my registration in February I was told that “IRIS is being phased out” and no new registrations were being taken.

Apparently this was being done in favour of the ePassport scanning stations that are only available for EU or UK passport holders.

In my multiple trips over the last few years through Heathrow, I have never actually seen ANYONE using the 3 dedicated ePassport machines at most checkpoints.

This was the case also on Saturday – no-one using the ePassport stations, and no-one using the IRIS machines (I can’t anymore)

Why the IRIS system was so good was that anyone resident in the UK (and that includes those expats like me that travel internationally a lot) could sign up and it took much of the frequent traveller traffic off the normal immigration desks.

I have no idea why the ePassport system has not taken off for EU and UK nationals, perhaps brits just really do like queuing!

The UK Border Agency CAN solve immigration queues with technology.

While I can concede that the IRIS system may have had its day (with 2 machines at each UK border, invariably over the last 5 years when I have used the system one or both would be out of order for no reason), I see no reason why the ePassport system could not be extended to those expats like me that have an ePassport.

In the US, which arguably has even tighter immigration checks at the border, their global entry program is available to all permanent US residents, and also includeds a background check and interview, as per the IRIS program.

Heathrow, with the closure of IRIS has excluded non UK/EU residents from using technology to clear immigration by restricting the ePassport gates to UK/EU passport holders only.

This would be a quick win for the UK Border Agency – divert the frequent travellers with rights to stay in the UK to the ePassport machines and check the biometrics on their passport and speed them on their way – freeing up the non-EU desks with less traffic.

Will Heathrow cope with the Olympic arrival traffic?

Having lived through an Olympics in Sydney, my observation is that London is just not prepared.

In Sydney for the 2000 Olympics SOCOG (the Sydney equivalent of LOCOG) tested EVERYTHING!

They even staged a mock avalanche of incoming travellers at the Airport – signing up volunteers with luggage to come to Sydney International airport months before the games, load testing with Olympic sized arrivals and seeing what systems and processes could be optimised.

Sydney has only one international terminal, and all arrival gates lead to just one arrivals hall that has only about 20 immigration desks.

Sydney coped with this influx – because they had tested the procedures and optimised.

The main stadium at Olympic Park was not only finished 12 months before the games, they held huge test events there (such as the National Rugby League Grand Final in 1999 that I attended) to see what they could improve.

As a result, Sydney will always be seen by the IOC (unofficially of course) as the “benchmark games” where everything went to plan.

I’ve seem a decided lack of test events and “load testing” by LOCOG and we’re under 100 days from the opening ceremony.

If the chaos at Heathrow did not serve as a real “load test”, then nothing will.

The solution for reducing immigration queues at Heathrow?

I believe that only by getting smart and using technology such as IRIS (extending existing registrations NOW to ease traffic on existing non-EU queues) AND implementing ePassport access for non-EU travellers will Heathrow be able to cope with Olympic sized traveller influxes in July.

Have you used IRIS in the past at Heathrow and like me are angry that they have scrapped the system – have your say in the comments below.

Related posts

• London 2012 Olympics O2 sponsor deal is no different from previous games
• London 2012 – do you have a plan of action?
• I survived opening day of Heathrow Terminal 5 – March 27 2008
• Visions for the Future–Telstra webcast August 8 2000
• Mobile social networking meets crowd powered media