Poor mans' TomTom Live Traffic on mobile phone

Last week, TomTom released the 1.3 version of their iPhone app, which now includes HD Traffic subscriptions. iPhone users have been expecting this update for quite some time, and time will tell if this will be a bit more succesful than TomTom's HDTraffic subscriptions for their own PNDs.


One thing that has not received a lot of attention, is the fact that some form of HD Traffic has been available to all users with a webbrowser, including iPhones; the TomTom online route planner has been online for quite some time. It seems TT is not planning on giving this platform a lot of attention; they could've easily started deploying an app that mimicks the Maps app, like Microsoft did with their Bing app. They haven't discontinued the tool yet, but obviously are not investing a lot of effort in it either. The UI looks horrible on an iPhone, and the form to enter origin and destination is hardly usable. (see image on the right/above)

I expected TomTom to launch some sort of HD Traffic Light app that would take advantage of the modern mobile phones location awareness and other features. But as the example shows, it seems they're not putting a lot of effort in free tools lately. So I decided to give them a hand and create my own app for it.

The use case to support is being able to check your route to some destination (e.g. home, work) quickly for any traffic severe enough to take a detour. You can do this today by going through the tedious work of entering origin and destination, and then bookmarking the result to your springboard. But this would only work as long as you remain on your origin. As soon as you leave, your new position (say you're halfway there) may be a reason why the suggested detour is no longer an option for you. What we need to do, is add the current position in the bookmark instead of your entered origin.

TomTom allows you to copy a link of a route you planned from the online route planner and reuse that later on (e.g. e-mail to friend or store on your computer). The link contains information about the origin and destination.
The URL basically looks something like this:
http://routes.tomtom.com/route/--ORIGIN--/--DESTINATION--/?leave=now&traffic=true

And here is the catch: it also support latitude and longitude in the URL! So conceptually, what we can do is take the GPS position of the phone, mix it with an entered destination and build a new URL to the online route planner.

Unfortunatly, it is not possible to change the bookmark on the iPhone on the fly. Another solution is to create a webpage that takes your current position, lets you enter a destination and then build the URL to the online route planner and direct you there. Here's some screenshots of what that would look like:

To make this app complete and support some bookmark like functionality, it would be great if it could remember your last entered destinations. So we store them in cookies. The next thing you would need to do is add a link to this page on your springboard, and you're all set. Whenever you're on the road and have doubts about the traffic and need a second opinion on the best route home, you simply start the app and tap your home address! and a Traffic Light app is there.

Want to give it a try? try it here: http://fambaas.nl/htl/. I'm not sure if this works on Android and other mobile phones with GPS. Let me know if it does!

-edit; Android does not support GPS location reading in the browser apparantly.

Acknowledgements: I've used javascript code from some sources across the web to join them into this Quick Traffic page (to read/write cookies, to read the GPS location etc), and used the IUI toolkit (although I also should acknowledge that the toolkit did not work without some struggle)

Re: Stop Masking Passwords

I was reading the article about masking passwords, from Jakob Nielsen, and it got me thinking about why we are masking passwords. I don't agree with his solution to just display passwords in open text inputs (there is so many side effects to that), but do agree that we could do better.

One of my colleagues was better at verbalizing a reason why not to stop masking: Even though it may make users feel less secure about the correctness of the password, it is just as likely that a feeling of security is introduced by the fact that passwords are masked. I think both statements should actually be verified. Both Nielsen and I are posing assumptions here.

Devices that have coped with the issue of making errors while typing passwords, are mobile phones. Using the web browser on an old Nokia to enter text in a password field - shows you an un-masked character for the last character you entered. This is a pure necessity: using a numpad to enter text (press "2" twice to get a "b") is painful by itself, let alone if you cant see what you type.

But this feature also made its way to smartphones. Android is using a similar approach; it displays only the last character, and masks it after a short period of time. Problably, because making errors on a small touch screen is also more common compared to a regular full-size keyboard.

But if we can do it on phones, then why not on normal computers? Here is a proof of concept using javascript to simulate the behavior. The "actual password" field would be hidden of course.

I actually think that this example should not be implemented on websites; it's really up to the browser manufacturers to fix the issue. We have the "password" type field, and it doesn't make sense to introduce new bugs and complexity to website this way, creating hundreds of new variants of password fields out on the open.

--Thank you, Douwe, for pointing out that a better solution to the problem with many passwords would be to start introducing OpenID and OAuth on more services. So if you want to do something for your users on your end, start with OpenID!