As of late, I’ve been working on developing a widget that runs on both PCs and mobile phones, for Opera’s X-Widgets Challenge.
The widgets for the challenge must work on a QVGA (320×240) screen, and that presents certain challenges. For example, as the size of the widget is so constrained, you need to think what is absolutely necessary – does the user have to see this piece of information on this screen, could it be shown elsewhere, or is it actually relevant at all?
Yesterday I finished the development of my widget. Let’s look at some things I had to consider to make it work on a small screen, and what could’ve been done even better.
The widget idea
The basic idea for my widget was pretty simple: Allow its users to easily find bus routes in Oulu. Of course, it also should show useful information, such as when a bus leaves, and which stops you need to walk to/from to get to your destination. A map would be nice too.
The bus company which drives the local traffic in Oulu has a website, which I could scrape for all of the needed information, so it was a pretty typical widget: One which gives you a better interface to an existing service, and which works by doing Ajax queries to the actual website.
So how to make this work nicely on a small screen?
You might easily go on PC terms at first, unless you’ve actually used a mobile phone browser extensively. Even if you have, it’s still easy to forget that even though Opera Mobile 9.5 is very close to an actual desktop browser, phones have certain limitations.
The lack of a proper keyboard
One key thing is the lack of a proper keyboard in most models. Anyone who has used a phone to type SMS messages knows it isn’t as fast as typing on a qwerty keyboard.
My widget would require the user to type two addresses, the start and the destionation, and also select the date and time they want to travel. Many users would most likely have a bunch of specific locations they need to type: their home address, their work or school address, and maybe some others.
So, to reduce the typing required, I added the ability to mark locations as favorites by clicking a star shaped button next to the text field. The same button could also be used to un-favorite the typed in location. The favorite locations themselves would be displayed in a list when one of the location textboxes was activated, using the Web Forms 2.0 datalist element, which is supported by both Opera and Opera Mobile.
In addition, the favorite locations can be synchronized using the Opera XML Store, so you could save your favorites on your PC, and just sync them on your phone.
Web Forms 2.0 also provides nice solutions to inputting dates out-of-the-box: it adds a new input element type, which is imaginatively called “date”. This shows an easy to use calendar-style date selector, similar to what some JavaScript based ones do, but being browser-native, it’s faster and works better.
As a final touch, I made the date and time boxes default to the current time. If you need to find a route on the go, chances are you are planning on hopping on the first bus which goes your way, as soon as you reach the bus stop.
The lack of space
As mentioned earlier, one big thing to consider is how to place information, so that the users get the information they need easily.
The widget is divided into several screens: Search, results, map and sync.
The search is shown first, and displays the boxes you need to fill to find routes. It’s relatively simple, and everything was easy to fit here.
After searching, the widget displays all the available routes, and basic information such as when the bus leaves, and when you would arrive if you chose this route. This allows you to easily get a quick look at the available routes and the most important details. On a big screen, you could easily display all the available bus routes and their details such as the bus number and station names, but on a small screen, the information needs to be filtered to only show what’s important at this point.
Then, you can select the route you want, which expands it to show more information. The expanded route shows the steps in the route – which stop to walk to, what bus to take and which stop to get off at. Finally, it allows you to see a map of the route.
The map view is pretty simple. It works a bit similar to Google Maps, and allows you to pan and zoom around to see the route better.
Finally, the sync view simply displays a My.Opera login form, and the sync status after logging in.
Other things
There’s also some other things to note.
- There is no “cursor” – your app can’t depend on hovering the mouse over something.
- Performance – Heavy JavaScript usage is slow even on modern PCs. Now imagine you have a computer from the turn of the century.
One final concern is the “operation” of the device – does it have a touch screen, and does it support a stylus, or just fingers (ála iPhone)?
If the device only supports finger-based operation, you need to take into account the fact that you can’t hit very small buttons or checkboxes very easily. This is less of a problem with a stylus, but it should still be considered.
This is the only thing I wanted to improve in the widget, but it would take much more time and effort than it would benefit. On a QVGA screen, if it’s large enough, the widget is probably usable with a finger. However, on my HTC Touch Diamond with its 480×640 screen, the widget is a bit on the small side, and only usable with a stylus. But all is not lost, as Opera Mobile can zoom widgets, and at 200% zoom, it actually is a bit better.
Still, I would’ve liked to make the widget automatically take up the whole screen, show nice big buttons and textfields and such. In theory, this would’ve been possible by using a separate stylesheet, but when first testing the widget on the phone, I realized that it used the screen profile, and not the handheld profile. This meant I didn’t really have a good way to tell if the widget was running on a phone or not, and I wouldn’t like to make it fullscreen on a PC with a big monitor!
In closing
While this was mostly observations from developing widgets, they can still be applied if you’re developing a website and want to make it behave better on a phone.
Just don’t forget that iPhone isn’t the only phone which can render HTML, as so many people seem to do, at least based on the “how to make your site work on the iPhone” articles which blatantly ignore other browsers. ;)