Recently I set out to find a more robust way of synchronizing my Google Calendars to my iPhone, thankfully I found one.

To date I have been using the Google Calendar to iCal sync tool “Calaboration“. In terms of functionality it’s great. My Google Calendars sync seamlessly with my local iCal program and once I plug in my iPhone in the calendars update. Perfect – right?

Notice: iPhone development will be one of the many topics covered at The Future of Web Apps London 1-2 October 2009.

The main problem is that I rarely plug my phone in to my Mac Book and as a consequence have a very out of date iPhone calendar. I also use the iPhone to set reminders, without sync’ing these back to iCal they never make it back to Google Calendar – all in all an unsatisfactory solution.

What’s the Ideal?

In a perfect world I would be able to enter a new event on my iPhone and have it appear relatively instantly in Google Calendar (or vise versa), no plugging in and over the air.

The Solution: NuevaSync

After a quick search I came across NeuvaSync. It’s an online service which allows you to:

Sync your calendar, contacts and e-mail over-the-air to your smart phone. NuevaSync works with Google Calendar, Contacts and GMail. Use the iPhone, Windows Mobile and other smart phones. It needs no app. Your phone’s built-in sync client and inbox is used. Just configure and sync. NuevaSync Web Site

Simple Setup

The basic service is free and setting up an account is straightforward. Once you have registered it allows you to login to Google and select the account(s) you would like to synchronize . Next the simple admin interface asks you to choose which services you would like to sync i.e. calendar, e-mail or contacts (or a combination of the three). Be careful here as on first use all data will be erased (more info on why that happens on the NeuvaSync Wiki).

Next it’s just a case of setting up a new mail account on your iPhone. This is as simple as creating a new Exchnage account in your iPhone’s Mail settings. A detailed seven step graphical how to is available on the wiki.

In Practice

I have been using the service for a few days now and I am impressed. Adding and deleting events in either Google Calendar or on the iPhone are replicated quickly and it means that I no longer have to plug in my iPhone to keep up to date. NuevaSync also offer a premium service for $25 a year which includes “Push” e-mail.

There are other solutions out there, if you have experience of alternatives that have worked for you please put a link in the comments.

If you’re a web developer or designer, there’s a really exciting development happening right now called ‘mobile widgets’. Carsonified is working with Betavine to spread the word about mobile widgets, so we recently spent four days building one in order to see how hard or easy they are to build. The result was Twiggy, a Twitter search widget, and today we’re going to talk about how we built it.

So what is a mobile widget?

A mobile widget is a simple web app that’s built with open web technology like HTML, CSS and JavaScript (we used jQuery). You don’t have to write a line of Java or any proprietary code and you don’t have to understand anything about ‘mobile development’. The files are packaged up into a zip file and downloaded to the phone. The device installs the widget locally, and then it can talk to the web. Widgets can currently run on Nokia S60 phones (currently 1M+ and growing).

Widgets have access to a permanent storage facility for settings and downloaded data. This mechanism is similar to cookies, but the storage capacity is larger and does not automatically expire after a given time.

Why are they a good idea?

We think mobile widgets are a really good idea because they allow you to reach a huge non-iPhone audience. Don’t get me wrong, everyone at Carsonified has iPhones and we love The Steve, but we’re not ‘normal’ and as web designers and developers, we have to consider there are a heck of a lot of people out there who would really benefit from useful widgets that ran on their phones. (They also run on Opera.)

Also, you can easily port mobile widgets to iPhone with a few simple tweaks. Here’s the version of Twiggy that works on an iPhone.

Here’s a quick video to show widgets in action, on a Nokia N96:

Cold hard cash

To encourage people to try building mobile widgets, Betavine are running a competition with a prize of £20,000. There’s no obligation to Betavine, you keep the IP to the code and they promote the widget to Vodafone customers, so it’s a pretty nifty deal.

What’s in a widget?

As I mentioned above, a widget is built with HTML, CSS and JavaScript and packaged as a regular zip file, renamed to use the extension .wgt.

Here’s what’s in the zip:

1. A widget configuration file. This is an XML file in the root of the widget structure that holds information about your widget including its size, name, author, and security information.
2. An index document. Like on a web page, this document contains the basic skeleton/content of the widget. Widgets content can be created using any markup that browsers handle natively, for example HTML, SVG, or XML files. This file also lives in the root of the widget structure.
3. Images. These are contained in a single images folder.
4. JavaScript files. These are contained in a single script folder.
5. Stylesheets. These are contained in a single style folder.

I’m going to hand it over to Elliott Kember, who built Twiggy, to go into detail about how Twiggy was built, and what hurdles we had to overcome. Over to you bud …

Mobile widget tutorial

Thanks, Ryan!

Hey everyone, I’m Elliott and I built Twiggy. I’m going to take you through a brief walk-through of how to build a widget.

First, you’ll need a directory. In that directory, make an “index.html” file, a “style.css” file, a “scripts” directory, and an “images” directory. You can structure your files any way you feel most comfortable with. If you want to split your CSS files up by contents later on, that’s fine.

Now, in your HTML file, put some content. For our widget, we’re using this:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
  "http://www.w3.org/TR/html4/strict.dtd">
<html>
  <head>
    <title>Twiggy</title>
    <!-- This is for the Opera Widget Emulator. -->
    <script type="text/javascript">if(window.parent&&
    parent.emulator)parent.emulator.begin(window)</script>
    <link rel="stylesheet" href="style.css">
   </head>
   <body>
  </body>
</html>

You can open it in a browser, and see what it looks like (it should be blank). Now, get a copy of jQuery and put it in your “scripts” directory, and add a line like this to your to include it.

<script type="text/javascript" src="scripts/jquery-1.3.2.min.js"></script>

Write all your application’s javascript in an “actions.js” file, which goes in your /scripts folder. Add it like this:

<script type="text/javascript" src="scripts/actions.js"></script>

If you want to use any other jQuery plugins, drop them in the /scripts folder and include them as normal:

<script type="text/javascript" src="scripts/plugin.jquery.js"></script>

Now, add these lines to your <head>, just in case you ever want to look at the page on your iPhone:

<meta name="viewport" content="initial-scale=1,
maximum-scale=1,minimum-scale=1 user-scalable=no,width = 320" />
<meta name="viewport" content="width=device-width;
initial-scale=1.2; maximum-scale=1.2; user-scalable=0;" />
<meta name="apple-mobile-web-app-capable" content="yes" />
<meta names="apple-mobile-web-app-status-bar-style"
content="black-translucent" />

They tell the iPhone how to render the page, what level of zoom to use, and basically tell it to treat the page like a web-app.

In your <body>, insert the following divs:

<div id="home" class="panel">
  <form id="main-search" class="panel" action="#">
    <label for="search">What is your name?</label>
    <input id="search" />
    <input type="submit" id="bigsubmit" value="Go!"/>
  </form>
</div>
<div id="results" class="panel">
  <!-- result goes in here -->
</div>

Inside the body, we’ve put two divs with class “panel”. These are different pages of our application, and only one will show at a time. When we submit the form on the “home” panel, we want the home panel to hide, and the “results” panel to show.

The JavaScript

Now for some actions.js Javascript code:

var search = function(text){
  text = "Hello, "+text+"!";
  $('#home').hide();
  $('#results').text(text);
  $('.panel#results').fadeIn('fast');
  return false;
};

$('document').ready(function(){
  $('#search').focus();
  $('#results').hide();
  $('#main-search').submit(function(){
    value = $('#search').val();
    search(value);
  });
});

Rad! We’ve got ourselves a widget.

Making it look pretty

Now let’s add some style:

*{outline: none !important;}
input::-moz-focus-inner { border: 0 !important; }

html, body {
  padding: 0;
  margin: 0;
}

body {
  display: block;
  width: 100%;
  font-family: verdana;
  background: #007FC0;
  text-align: center;
  color: white;
}

#home.panel {
  padding: 20px 0;
  display: block;
}

#results.panel {
  background: #ff00ff;
}

#search {
  margin-top: 10px;
  padding: 4px;
  border: 1px solid #ff00ff;
  font-size: 13px;
}

And we’ve got the beginnings of a widget.

The configuration

Now, all you have to do is add a config.xml file, which looks like this:

<?xml version='1.0' encoding='UTF-8'?>
<widget dockable="yes">
  <widgetname>My Awesome Application</widgetname>
  <description>It asks you your name, and says hi!</description>
  <icon src="icon_64.png" />
  <width>240</width>
  <height>320</height>
  <author>
    <name>John Q. Developer</name>
  </author>
  <id>
    <name>My Awesome Application</name>
    <revised>2009-04-08</revised>
  </id>
</widget>

And you’ve got it. Feel free to open that in Opera just to test it out.

Searching Twitter

Now, if you want to search Twitter, include the plugin from tweet.seaofclouds.com after your jquery javascript file:

<script type="text/javascript" src="scripts/jquery.tweet.js"></script>

While you’re there, change your label to:

<label for="search">What are you looking for?</label>

Change your actions.js file to:

var search = function(text){
  $('#home').hide();
  $('#results').fadeIn('fast');
  $("#results").tweet({
              query: text,
              join_text: "auto",
              avatar_size: 32,
              count: 10,
              loading_text: "loading tweets...",
              auto_join_text_reply: '', auto_join_text_default:
              "", auto_join_text_ed: "",
              auto_join_text_ing: "", auto_join_text_reply:
              "", auto_join_text_url: "",
  });
  return false;
};

$('document').ready(function(){
  $('#search').focus();
  $('#results').hide();
  $('#main-search').submit(function(){
    value = $('#search').val();
    search(value);
    return false;
  });
});

And add this to your CSS:

#results { float: left; display: block; width: 100%; }
ul { margin: 0; padding :0; }

li {
  list-style-type: none;
  text-align: left;
  background: white;
  color: #333;
  line-height: 1.5;
  border-top: 1px solid #007FC0;
  float: left;
  display: block;
  padding: 5px 0;
  font-size: 12px;
  width: 100%;
}

li img {
  float: left;
  display: block;
  margin: 5px 8px 5px 5px ;
}

And you’re done! Zip everything in that folder up into a file called “search.wgt” (zip -r search.wgt *) and put it on your phone via USB cable. When you run it, it’ll run as a widget.

Testing with an emulator

Go get the widget emulator and try it. It should look like this:

The good, the bad and the ugly

This is a cool experiment, because you now have a site that will work in just about anything. The iPhone will handle it, it’ll work as a dashboard slice, browsers like it, and it can be run as a widget. We’ve tried to port it to a PhoneGap app for the iPhone, but no success yet.

There’s really not too much to watch out for. You do, however, have to be careful with your 100% width layouts so that the application doesn’t scroll horizontally.

Here are some other gotchas:

• Auto-focus input fields wherever logical. Nobody likes using that !$?*! joystick mouse.
• Hover effects are important. Make buttons obvious, because getting to them is a nightmare.
• Make sure the phone has your typeface, and renders it nicely. I got caught out with italics.
• Don’t resize images with HTML – although this is pretty good advice anyway. The phone does it wrong, and it looks horrible.
• Even if you think you’re only bundling this on the phones, use CSS sprites – because once you’re done, you have a web app waiting to happen, and waiting for your button images to load on hover is lame.
• There’s no keypress-type event handling, which is a damn shame if you’re making a game. Poll instead.
• Remember, the phone is fast, but not as fast as your computer is. Neither is the network connection, so be thrifty.

Data storage for widgets

Storing stuff on the phone is done through some Javascript API calls. You don’t have access to anything juicy yet, but you can store and retrieve strings, using the widget.getPreferenceForKey() and widget.setPreference() methods. To be clever, include the jQuery Cookie plugin and do this:

var get_key = function(key){
  if (typeof(widget) != 'undefined'){ // A phone!
    return widget.preferenceForKey(key);
  }else{ // It's a browser!
    return $.cookie(key);
  }
}

var set_key = function(value, key){
  if (typeof(widget) != 'undefined'){
    return widget.setPreferenceForKey(value, key)
  }else{
    return($.cookie(key, value));
  }
}

This way, you can set and get keys without worrying about whether you’re saving to a cookie, or to the phone. Happy hunting!

Elliott is a freelance developer who lives in Bath, and used to work for Carsonified. He writes CSS, uses Rails and is generally available. He also likes long walks on the beach and candle-lit dinners. You can find him at @elliottkember or elliottkember.com.

At 280 North we’ve been working on a framework called Cappuccino for creating what we like to call desktop class applications. These are not your average web sites, but instead a new breed of web application that aims to replace many of the programs that currently run on your desktop. When we launched 280 Slides, the first application built on this framework, many people were surprised to see just what was possible in the browser. Since then, Cappuccino has been steadily progressing with over 40,000 downloads and code contributions from twenty-one individuals.

The goal of Cappuccino has always been to make it as simple as possible to build high quality applications in the browser, and up until now we’ve worked on providing built-in behavior for enabling such tasks as autosaving, undo/redo, and copy/paste. But recently we’ve been focusing on an entirely new product: Atlas. Atlas is a new IDE and visual layout editor that leverages the power of Cappuccino, but drastically reduces the amount of work required for creating a truly rich application experience on the web.

WYSIWYG

With Atlas you can build and style your entire interface using drag and drop. By default we provide you with a large library of built in widgets along with the new Aristo open source theme, meaning your application will look fantastic with no additional work. However, you can also skin these applications entirely from the editor and extend the library of widgets with Atlas’ plugin architecture. And unlike a lot of existing layout editor availabe today, Atlas is not a code generator. On the contrary, Atlas lets you edit the live JavaScript objects in memory and then takes a “snapshot” of them in place. When your application runs, it ‘thaws’ these objects out, making sure that you see exactly how your application will look before you run it.

Layout that Makes Sense

Atlas provides a new take on web layout that make it easy to define precisely the behavior you want, while simultaneously doing away with existing browser inconsistencies. Instead of having to learn the variety of different ways to position and resize elements in the browser, Atlas introduces the simple concept of ‘anchors and springs’. Anchoring an interface element to one of the edges around it ensures that it will stay “stuck” there when it’s container resizes. Activating the internal ‘springs’ causes it to resize with its container.

While simple to learn, these two tools enable you to create incredibly complex and fluid layouts. More importantly, they’re guaranteed to behave the same way regardless of the browser you’re running your web app in. Atlas also provides a large selection of collection views to handle common layout tasks such as split views, table views, and scroll views.

Connections Reduce Glue Code

A common problem that has plagued layout editors in the past is the need for additional glue code to “talk” to the generated interface. In Atlas, much of this work can be done with a technology called ‘connections’. Connections allow you to visually define the interactions between interface elements and other objects. For example, you can define what action a slider should take when it is dragged:

Similarly, you can ‘bind’ the contents of an array to a table, so that when it changes the table automatically updates as well, all without having to ever touch the keyboard:

Model View Controller Built-In

Cappuccino is a Model-View-Controller framework, and Atlas takes this idea to the next level by allowing you to not only create visual elements, but abstract models and controllers as well. By allowing you to interact directly with the objects in your program visually, you can focus on building unique interactions instead of learning a myriad of APIs.

Atlas has gone a step further and provided a number of pre-built controllers to existing web services that you can simply drop in to their applications. You can then simply use connections to grab information from services like RSS and Twitter. Once again, Atlas’ plugin architecture allows you to create controllers for your own web services as well, which you can then share with others.

Multi-Platform Support

Cappuccino was built from the ground up in preparation for a world of multiple platforms. It is becoming increasingly important for applications to run in several different environments: browsers, social networks, handheld devices, and much more. In general, very little application logic or backend code has to change from platform to platform, but the interface usually needs to be recreated from scratch.

With Atlas, it is drop dead simple to create a unique and custom interface for different platforms like the web browser and the iPhone. Cappuccino will then intelligently load the correct interface for your application depending on the environment it is being run on, allowing you to reduce the amount of code you need to rewrite and as well as using just one language and API for all the platforms you deploy on. We call this idea ‘Write once, layout everywhere’, and we feel it is the right way to gaurantee a high quality experience everywhere you ship your application.

View full size

View full size

Atlas will be shipping this summer and you can sign up for email updates at 280atlas.com.

[Photo credit: flickr.com/photos/atelier_tee]

With this years Future of Mobile conference coming up in a months time I have been looking at the key areas of change in the mobile ecosystem since last years event.
Last year the Future of Mobile discussed the question “Will content be King”. Since then the focus from both Operators and handset manufacturers seems to have been on improving the music capabilities of the phone itself and offering enhanced services to buy music. SonyEricsson have expanded their range of handsets with a shake to shuffle capability. Nokia are launching their Comes with Music service this week.

We have seen many mobile music services come and go over the last few years. This begs the question, what is the key differentiator between success and failure? Nokia have big pockets and are continuing with their Windows only DRM embedded music. T Mobile and Google have sensibly partnered with Amazon to deliver DRM free music from a vast catalogue to the G1 phone. Apple are holding a middle ground with iTunes content for the iPhone but do make it a deliberately obtuse process to move any content into other media players and devices.

The increase in the onboard memory of mobile handsets seen in the last year is typically eight fold, meaning that many users now see their phone as replacing their mp3 player. As with all aspects of mobile the user experience is the key to success. Will users really take to a service that can fill the phone up with music, but locks it in there so they can’t knock up a virtual mix tape and pass it on to a friend? I doubt it, since the launch of the cassette tape people have taken great pleasure from sharing music with each other.

New services such as Didiom in the USA really understand what users want from their music collection and the collection of devices they have in their lives. This interoperability is the key to a successful service. The insightful J P Rangaswami perfectly summed up why DRM is always destined to fail on his Confused of Calcutta blog this week. Companies that really get it are going from strength to strength like the UK’s Indy Mobile who build lasting relationships between the record labels and mobile consumers.

At Future of Web Apps in London last week I had the pleasure of discussing the mobile future with Stefan Fountain, founder of Soocial, who is one of the most astute mobile theorists there is. He says…

“The future of mobile is not about a device, it’s about the service, maybe not even that. It’s about what you want to do”.

This quote is taken directly from his FOWA presentation which is available to watch, embed, and share right here.

(Photo credit: Chuckumentary)

It is said that you are more likely to leave your wallet behind than your cellphone when leaving the house. Most people are within 15 feet of their phone at any time, even when they are sleeping. One person in seven has been dumped by phone and the incidence of firing by phone is growing.

The phone is so omnipresent it is becoming set to take over as the task-oriented access point for the Web, while the PC, the TV, and other large screen access points will continue to be the choice for video streaming, browsing, and other activities involving heavy graphics or complicated interfaces. It is unlikely that the phone will take over as the online word processor any time soon.

Moving functionality onto the phone: spending

If you are more likely to have your phone with you than your purse, it starts to make sense for the phone to take over some of the functions that you need all the time. It is no surprise that payment is moving on to the phone.

Take your credit card, for example. What is a credit card, really, but a bunch of information held in a form that is awkward to replicate? In effect, it’s an account number combined with an ID. Any modern cellphone has more storage capacity than a hundred credit cards require, so why not move it onto the phone and have it with you the whole time?

However, managing your finances on your phone with a full-scale accounting application might not be convenient; you would really need a bigger screen than is really comfortable to carry around with you. So we have our first driver towards convergence right here. Moving a credit card to the phone and administrating your finances across a variety of web channels not only makes sense, but there are a lot of other advantages to it which we will discuss later.

Traveling

First let’s look at how another card with a magnetic strip has evolved. The humble tube ticket used to be the standard way of getting about in London; now 80% or more of eligible journeys are made using contactless Oyster cards. Contactless cards are quicker and more convenient than putting a card into a slot. So if we are going to move the credit card onto the phone then let it be as a contactless card. And if we have a contactless card, it might as well be our Oyster card as well. That way the Oyster can be “topped up” from the account attached to the credit card and save us a bit more bother. In the world of developing technology, convenience should be king. It is no surprise to find that the Oyster card is administrated over a web interface, so perhaps we should integrate that with our accounting package so that we can see our debits coming out of the bank account, and then drill down into the journeys.

Just making the phone into a ticket is limiting its usefulness, though. If you are connected to the network, the phone could know where you are and alert you just before you reached your stop. This would be handy for those people who tend to fall asleep and go straight past their stop. Also, it could spot if you are going the wrong way (oops, wrong platform and wrong train!). Clearly this could also work if we spread the ticket to cover “over-ground” rail and bus. It could do these tasks already, but it needs to know where you are going. If our application were tied to your calendar, then it would already know where you are going. If you had not put the trip into the calendar, then the phone could check while buying your ticket. It could even set an “out of office” autoreply on your email, add a calendar entry in to let people know where you are, and add the trip to your expenses claim form. Directing you to the right platform, the right train and then letting you know in time to gather your things together before you got there would be easy, too. Even more useful, for those unfamiliar with the tube system, would be help to find your way around the labyrinthine tunnels.

Identification

While we are at it, are there any other contactless cards we could add to our phone? Well, here at dunnhumby there is our security pass. Now, a phone can’t replace all the functionality of my pass because having a photo visible is clearly an important security element. The phone could do the door-opening part of its work, though. I’m less likely to be left behind than the standard pass, so let’s look at how it could work if I remembered my phone but forgot my standard pass.

If I left my pass behind I could swipe my phone at a kiosk at reception. The kiosk could then print out a photo of me, from my badge record, to hang around my neck. Clearly I need to show that I really am me, so I would be asked for a password and a few other details before being given the temporary pass. Now the kiosk could ask for those details, but so could the phone. The phone is, after all, a computer.

We could also look at putting a biometric check on the phone. These are available on laptops, so why not phones? It isn’t 100% secure, but it is better than we have now. Now the phone has an advantage over the kiosk as a place to check my biometric data, because it is somewhere I am more comfortable with the verification information being stored. It also prevents data redundancy, as I only need to have my personal details in one place rather than several. If we are doing security checks with the phone then we want to ensure that loss of the phone does not let it out into the world. What we really need to do is to make this another joint application, with the phone accessing a secure hybrid online interface and backup system on the Web. Clearly this will need the best security we can find, but if it has that then we can start tying the security aspects up with that credit card we were talking about earlier.

Security

So now we have a phone/web application that knows how to identify you and can be used in a quick and easy way to give you access to money, travel and work. This is clearly of value, so what happens if you lose it? Well first, it is a phone so you may be able to locate it: you could call it, or get it to use GPS to tell you where it is. But what if it was stolen? You can can easily cancel it through the phone network. But not only that, your new replacement phone can make itself into a clone of your old one as soon as you have verified your identity. So your new phone/card wallet is safer than the old credit cards you used before, immune to shoulder surfing, and tied into the way you run your accounts. With a credit card someone can clone it and access your account, but a phone can change the code it uses with each transaction so even a thief could intercept the code they couldn’t use it.

Given that our phone knows who we are it could also act as a key. Not just at work, but for our homes, too. You could control access to your house remotely to let people in; your house is connected to the phone network after all. If you were organising a party you could make access to your house part of the invitation email as you pick people out of your contacts on your home PC. They would be able to access their email from their phones, effectively making their own phones into “keys” to get in. You could set up visitor phones to have access once for a limited slot (that party invite perhaps), or regularly on certain days (the cleaner) or on a permanent basis (the boyfriend). You could then remove the permission straight away (during an argument in a restaurant, say) and not worry that they will come busting in later (I Will Survive might never have been written if it had been that easy to change your lock!)

Shopping

Mixing phone access with web applications can help enable spending, traveling, working and security; perhaps it can do more than that. It is already tied into the way you budget, so why not set it up so purchases over $20 require a fingerprint? As we put verification on the phone instead of the kiosk it is easy, and it won’t slow things down as you are holding the phone to wave it near the checkout anyway. If it’s a big purchase, say $100, you could set it up to ask for a PIN number too. It’s your phone so you can set the limits to amounts you are comfortable with. All of this adds security, but could also help you stick to a budget.

Let’s go further than that. Why not decide what weight we are happy to carry in a single shopping trip, and say that if you purchase anything over 10kg you will be willing to pay $5 for delivery. Pickers gather a basket for you at your local store, so if it is heavy why not put the basket we have gathered into the same process? Your phone can exchange contact details and pay at the same time. That is all very well if you are buying everything in one store, and we could do it even with an ordinary credit card and epos (electronic point of sale) access to preferences. What happens if you build up to 10kg across a few shops? If your phone keeps track of your purchases it could ask, when you go over the weight limit in one trip, whether you want the latest purchase delivered. Perhaps, as a slightly more costly service, the picker in store could take the basket you picked from all the different shops and get them all delivered? This could combine with your online mapping application to remind you to get delivery when you are in the stores that do delivery, even if that means popping into a nearby store. It would also tie up to your overall shopping trip and maybe your packing list too. Going on holiday? Make the application remind you when you are near any items you need to buy before you go.

If we are putting cards into our application then including contactless loyalty cards clearly makes sense. What are the advantages? Well, the first is that if your loyalty card and your payment mechanism are on the same phone then you can begin to get credit for all those small purchases that were not worth getting your card out for before. Pulling out your phone to pay is even less work than getting your money out of your wallet, particularly if you don’t have to count the money, just wave the phone. Again convenience is king, and adding convenience is actually providing customers with value.

In order to get at the other advantages of the loyalty card being on the phone we should, perhaps, touch briefly on what a loyalty card is:

• A way for a retailer to say “Thank you for shopping here, do come again”
• A way for you to tell the retailer which offers will interest you so as to keep the offers you are sent relevant
• A way for the retailer to understand shopping habits so that they can become the type of shop that you, their customer, wants

In any interaction between a retailer and a customer, both parties must benefit. If this is not the case then the interaction will not happen. When you buy a loaf of bread the retailer gets your money and you get to eat; both sides benefit. The same is true for a loyalty card. By becoming the place you want to shop the retailer becomes more profitable and both parties benefit. In the way I have described the phone developing I have been talking about the benefits to the phone’s owner. Some of them are overwhelming, and will mean that market forces make them happen, but that will not necessarily make them as convenient as I have described. The bank that puts their credit card onto our phones first has an advantage and people will start to switch to them. This, in turn, will pressure all banks to move their credit cards onto our phones.

This won’t work if there is just convenience to the customer without a clear commercial beneficiary. I mentioned the possibility of your phone keeping track of what you bought and arranging for the shopping to be delivered, if necessary. If a shopping trip stays within a single shop then that shop benefits, but if a trip takes the shopper through multiple shops only the customer benefits from the phone doing this work. Equally, where is the advantage to the product manufacturer in making the weights of its products available to millions of phones? Likewise, if credit cards are being added to the phone, who is going to provide the platform that lets you add them in and remove them when it becomes necessary to, for example, change your credit card provider?

So, who’s going to do all of this work?

Perhaps it would make sense to create a deal similar to that for loyalty cards: customers provide some information about themselves in exchange for having the platform to add and subtract cards and to set limits, alarms, and alerts. Given that loyalty cards are doing some of this kind of work already, it might make sense to extend an on-phone card to include the platform itself. This would allow much closer integration between phone and online applications without the causing the phone to be costing too much in bandwidth. One possible benefit to the loyalty scheme might be the advantage of having control over the branding as settings are changed and alerts read. Given that the platform will require maintenance, and will run within a possession we have already shown is integral to everyday life, there is a need for it to be of the level of quality that only comes at a considerable cost. As customers, we could offer a willingness to receive non-intrusive targeted offers and advertising within the platform interface and additional information about ourselves for targeting those offers in return for the loyalty card company providing the platform. Neither one of these seems too high a cost for the value such a platform would provide for us.

This sort of deal with a loyalty card could have a significant advantage over phone manufacturers producing a home-grown solution: consistency. If convenience is king, then usability is the throne it sits upon. If something is not usable it is not really convenient. Usability comes from things working the way you expect them to without having to think. Given the rate at which we change from one phone to another, following fashions, we do not want to have to learn a new interface every time. We particularly do not want to risk having the way our credit card is protected changing continually. If your favourite loyalty card were the platform it could come with you. It will be a brand to rely upon to back up your phone and not accidentally delete your settings, your identification and half of your life.

Conclusion

Nearly all of the functions to be integrated that I mention here are either in use on phones in other countries or are already in development. For example, contactless capability, referred to as NFC (Near Field Communication) looks like it will be standard for most new UK phones in about 18 months or so; in Japan it is already how everyone uses their phones. This kind of convergence and integration has not really happened yet, but is clearly on the horizon.

So what is the future of web apps? They will tell us who we are, where we are, what we can spend and what we can spend it on. In effect, they can become the ultimate view nannies, always remembering the fact that the user will have set up the guidelines themselves.

The only question is not how far can the future development of web applications take us, but how far do we want it to go?

Introduction

Good evening — in this article I will aim to demystify the world of mobile web development, or in other words, developing web sites so that they will provide an acceptable user experience on mobile devices. I’ll run through how “the mobile web” differs from the normal web, the basics of techniques you can employ to make your sites work sucessfully on both mobile and desktop browsers, some general DOs and DON’Ts for mobile web design, and numerous resources where you can go to find out more information.

How does the mobile web differ from the normal web?

This is a good question — first maybe we should start by answering the question what is the mobile web? after all, there isn’t a separate mobile web that users of mobile devices plug into, leaving the desktop web for when they get home in front of their home computer. When I say mobile web, I mean the Web as viewed through mobile devices.

At Opera, we passionately dedicate ourselves to creating browsers that allow you to view the whole web, regardless of (dis)ability or browsing device. There is one and only one web, and you can make this one web work for everyone on every device as long as you treat it with a bit of care and respect and follow web standards when creating your sites. There are exceptions to this rule however — in some cases separate mobile sites DO make sense, as you’ll see below.

The playing field is not level on mobile

In the desktop domain, things are getting pretty easy for us web developers these days — most modern browsers support web standards pretty well, be they Opera, Firefox (and other Gecko-based browsers) or Safari (and other WebKit-based browsers). Even IE is causing us less pain than it used to, although IE 6 is still used by an alarming number of web users, due to factors such as corporate lock in. The story is quite different on mobile devices however:

• You’ve got web browsers that offer support for the full web, like Opera Mobile and Safari on the iPhone. Opera Mobile uses the same rendering engine as the equivalent desktop version, so the standards support is about the same.
• You’ve got constrained browsers, ie, browsers with a limited support for web standards. A few of these still only support WAP (such as WinWAP,) some support other standards like cHTML or HTML MP (for example the Japanese NTT DoCoMo iMode browsers,) and some support a limited subset of the web standards (such as Netfront, Pocket IE, and Blazer.)
• Lastly, you’ve got Opera Mini, and other browsers that work via a proxy system. It mainly just acts as a client interface between the user and a big server farm. When the user submits a URL, the client asks the servers to look up the page. They then convert it into a lightweight binary markup language, format it for viewing on a mobile device, and send it back to the client for viewing. The major advantage of doing it this way is that the pages are reduced in size by up to 90%, saving the user lots of money on bandwidth. language Say what web standards do and don’t work well on mobile devices. Because of the way the service is set up, Opera Mini doesn’t handle some aspects of Ajax/JavaScript very well — this is explained in detail here.

Note: don’t expect your ultra-interactive Ajax and DOM scripting animated sites to work well on mobile devices. JavaScript support on mobile devices varies a lot. Provide fallbacks at all times. An example of this approach is called Hijax.

So as you can see, you’ve got quite a bit more to think about in terms of cross browser support on mobile devices. But never fear — my advice below will send you in the right direction, and as time goes on standards support will improve across mobile browsers, to the point where mobile web development isn’t really that much of a worry anymore. When will that happen? Who knows!

What are the other constraints of mobile browsers?

Of course, there are more considerations when developing web sites that work on mobile devices, besides just mobile browser standards support. You also have to consider the constraints of the device itself, such as:

• Limited controls — don’t just assume your user can control everything with a mouse, provide a keyboard alternative. Some mobile phone users may not have a mouse pointer equivalent, so constructs like :hover and onClick are useless to them (this is important for accessibility as well — some users may have disabilities that affect their ability to use their hands.) Also important is providing aids for inputting data — most of you will already know how annoying it is having to fill in a long web form using a mobile phone. To get around this, try to make as many things as possible selectable from a drop-down list, rather than expecting the user to type it in. Prefilling form fields with the most likely option is also a good idea.
• Limited screen size — think about how usable your beautiful intricate 1024 x 768 design will look like on a 240 x 320 screen, or smaller than that…there are some ways to plan for this — you can deliberately make your design very simple and fluid, or you can serve appropriate pages to a mobile device using capability detection or media queries and media types (more on this later.) Some phones will help you out in this regard, with mechanisms such as “zoom modes”, but you can’t guarantee it.
• Limited memory and bandwidth — mobile devices will obviously have less memory available than desktop computers, therefore you need to think carefully about those image heavy galleries, and interactive streaming video applications you we planning on putting on your home page! Again, some mobile browsers have the option of turning images off, but again you can’t be sure.
• Limited typography — wow, you thought you had it bad with typography on desktop computers? You ’aint seen nothing yet! There are exceptions to this rule, but a lot of mobile devices have very limited font choices, like 1 or 2. This is partly down to the system, and partly down to the browser.
• Limited colour palette — some mobile devices also have a very limited palette. Think about how much your page’s experience reiles on colour, and make sure that colour contrasts still work ok on mobile devices.

It is constraints like these that really make the mobile web experience different from the desktop web experience. Never try to kid yourself that the user experience on your site will be EXACTLY THE SAME on mobile devices as it is on desktop devices — this isn’t going to happen. You do however need to make sure that the experience is still a good one, regardless of browsing device.

The only way to be really sure that your site provides a good mobile experience is to test, test, and test again, on multiple devices. Some web designers have been known to have half a dozen mobile devices at hand to test on, in addition to their normal phone, desktop computers, and game console browsers.

Different approaches to the problem

It is generally recognized that there are three ways to approach the mobile development problem (this is corroborated by Cameron Moll — check his book out for more.) I’d recommend trying to follow way number three if possible — as stated earlier, at Opera we believe that there should only be one web — but as I’ve also said earlier, there are some case where this is difficult to achieve, and/or unnecessary. the three methods are as follows:

1. Do nothing except follow web standards.
2. Create a completely seperate mobile site
3. Create one site, but add code to optimize it depending on the device and browser looking at it.

Let’s now go through each of these in turn.

Do nothing except follow web standards and best practices

The foundation of every good web site is a good HTML structure, with CSS for style and JavaScript for behaviour. If you follow the standards carefully, there is a pretty good chance that most mobile browsers will be able to at least interpret your sites and render them in a manner that is basically usable. For example:

• A site with good logical source order structure and without decorative images in the markup will display logically in a mobile browser’s single column/mobile mode.
• If your form elements have label elements then the browser will make more sense of form fields
• If you also use good graceful degredation/progressive enhancement techniques for your CSS and JavaScript so that functionality not supported in browsers is either simplified, or ignored and an alternative provided, the chance of the site providing an acceptable user experience is increased greatly.

This is not a bad way to go, but there is more that can be done to improve the mobile user experience if you have the time and the knowhow to spend on it. If your target audience includes a great deal of users using either non-HTML browsers (eg Japanese browsers that support WAP or cHTML, then you may be forced to detect for the device and serve up appropriate content.

Provide a completely separate mobile site

As mentioned before, I think this way should be avoided if at all possible. You can do device detection and redirect automatically so that it doesn’t inconvenience the user base, but it does mean having to maintain two web sites. The main way to do this is to detect the browser via user agent sniffing or capability detection on the server-side, and then serve up the appropriate site. There are a number of good articles at dev.opera.com about how to do this — see the resources section at the end.

But there are exceptions, where a separate mobile site may mke sense — you’ve got to consider the user experience at all times. Some types of browsing device won’t be likely to make use of certain web sites, or certain features of certain web sites. For example, take a site such as a university campus that has search functionality for looking up department phone numbers, but also contains pages and pages of university history. You are likely to want to use the former on a mobile device, say if you are meeting someone but can’t find their department, but you are unlikely to want to sit and read reams of text on a mobile device while out and about.

In this situation, you could use some of the techniques described below to create a site that only serves a certain subset of it’s functionality to mobile devices, or it might just be easier to create a seperate site entirely for mobile devices. You could just detect what kind of device your users have and serve them the appropriate site automatically, making the process completely transparent to the user, but this is seen as bad by many — many people don’t like to be restricted like this, so if you are going to do it, provide a link to the full site so the user can try using it on their mobile browser if they wish.

One word of warning — device detection is very open to abuse. You often see a full desktop version of a site in all it’s glory, and then a really rubbish basic mobile site experience alongside it, because the developer is just dumbing the mobile site down to the lowest common denominator. It’s easier on him or her, but not fair on the target audience, as many mobile browsers can handle the full capabilities of the Web these days! You should instead be serving devices with as much capability as they can handle, and taking advantage of mobile specific benefits, such as location based services (LBS), and the tel: protocol, which can cause a mobile phone to dial a phone number when a link is clicked on.

Provide one site…

This is where it starts to get interesting. You can again rely on server-side capability detection, but optimize a single site for the mobile device, rather than redirect to a seperate site. There are databases of mobile phone capabilities availble, such as WURFL. This comes in the form of an XML file that you can query to find out the capabilities of a device, before sending it optimized content. You can also query the UA strings of a mobile device to find out details such as whether the device has a camera, what the screen dimensions are, and what languages it would prefer content to be delivered in.

On the client side, you’ve got a couple of options for optimizing content for mobile devices — media types and media queries.

media types

As you’ll no doubt already know, you can specify different CSS to be used for different purposes, for example:

the handheld media type allows you to target a mobile device with a stylesheet optimized for viewing on mobile devices (eg simplified layout, simplified typography etc.) It is a well-supported mechanism, and fairly simple to implement, but it does have it’s drawbacks. Again, it is often abused by developers to serve a site a crappy lowest common denominator layout. So much so in fact, that Opera Mini recently changed it’s default behavior from using the handheld stylesheet to using the screen stylesheet. Opera Mini can handle most full web sites, so it doesn’t really need to use the handheld stylesheet. You can set Opera Mini to use it instead if you wish by switching to mobile view in the browser preferences.

Media queries

Media queries are a CSS 3 construct that act in a similar way to conditional comments — you can enclose a block of CSS rules inside a media query, and then have them applied to your markup (or not) depending on a condition, such as “is the screen size less than 480 pixels”? Put into code, this would look something like the following:

img {
  margin: 0 0 10px 10px;
  float: right;
}

@media all and (max-width: 480px) {
  img {
    margin: 10px auto;
    float: none;
    display: block;
  }
}

You could even use a couple of media queries together, as follows:

body {
  max-width:800px;
  font-family:georgia, serif;
}

img {
  margin:0 0 10px 10px;
  float:right;
}

.info {
  position:absolute;
  left:8000px;
}

@media all and (max-width: 480px) {
  img {
    margin:10px auto;
    float:none;
    display:block;
  }
}

@media all and (max-width: 240px) {
  img {
    display:none;
  }
  .info {
    position:static;
  }
}

So in this example (source code available here,) images in browsers with a screen width larger than 480 pixels are displayed floated to the right, with the text flowing round them at a conmfortable distance provided by the margins. (There is an alternative message hidden in p elements with a class of info — check the HTML source out.) The text flow might start to look a bit crappy on smaller screens, where there isn’t enough room to have the images and an appreciable amount of text on the same line, so as soon as the viewport gets smaller than 480 pixels, the images are changed so that they no longer flow the text around them, but are instead displayed on separate lines using display:block. But wait — there’s more! If the screen gets far too small for the images to be displayed usefully, then they disappear, and the alternative messages are displayed in their places, to give textual descriptions of those pictures — this provides an alternative mechanism of getting that information across to the reader, and also provides a textual alternative for blind users using screenreaders to view the site. Figure 1 shows the three different display settings when the example is viewed in a browser that supports media queries, such as Opera 9.5.

Figure 1: The three different viewing modes of my example.

This sounds great, but what’s the downside? Well, browser support is currently very patchy for media queries. Opera browsers support them, so does Safari 3 (and other modern Webkit-based browsers), but Firefox <3 doesn’t, and neither does IE or other web browsers. One way to tackle this is to use a combination of media types and media queries. This kind of approach is explained in my article here. It is a workaround of sorts, but certainly not ideal. This should improve in the future.

Summary

That’s it for now. I hope my journey into the world of mobile development has been helpful. I’ve only scratched the surface here, so be sure to dig into some of the resources below to learn more.

Resources

• Mobile web design book, by Cameron Moll
• Designing and developing mobile web sites in the real world — a case study by Brian Suda
• Server-side capability detection for mobile devices by Brian Suda (includes more on WURFL, UA strings…)
• Ajax/JavaScript support in Opera Mini 4, by me
• Kristian von Streng Hæhre’s Opera Mini request header reference
• How to serve the right content to mobile browsers, again by my good self — includes media queries and media types
• Creating safe media queries that work cross browser
• Web design with Opera Mobile in mind, again by me
• The WURFL homepage
• The Opera Mobile homepage
• The Opera Mini homepage

The number of mobile devices loose in the world greatly exceeds the number of desktop (or laptop) computers filling up desk and table space in offices and homes. The number of people who might view your site while clutching a screen measuring anywhere from 100 pixels to 640 pixels in width increases daily. Creating mobile-friendly content is quickly becoming less of an occasional add-on and more of a standard practice.

This article will take a look at how you can create mobile-friendly content, how you can test your work, and offer a few tips for writing CSS for the media type handheld. If you are a Dreamweaver or Flash user, we’ll also take a look at something new from Adobe that will help you test your pages for handheld devices.

Start with the basics

If you begin with standards-based HTML that is formatted with logical, semantic markup, you’re ahead of the game already. A well structured document with clear organization and semantic markup will display cleanly, be usable, and be accessible on any device – mobiles included. Using CSS to separate content from presentation means your content will be accessible, even on the least capable mobile device. Pay attention to other basics as well. For example, good alternative text is an essential for any non-text element in your pages. Make sure that form fields are properly labeled.

Clean, semantic markup is crucial when you consider the variety found in mobile devices. Some phones may only understand WAP. More capable phones may understand WAP2, which opens them up to rendering websites with XHTML and CSS. Some devices may display only monochromatic screen colors, while others may have full color. Some devices support CSS, some do not. Some only understand HTML 3.2, while others understand XHTML. Some devices undertand tables, floats, frames, JavaScript, and dynamic menus, but many do not. Most devices don’t support cookies. Devices at the high end of the mobile market such as BlackBerry, Palm, or the upcoming iPhone are highly capable and support nearly as much as a standard computer.

All those possibilities are enough to make you long for the days when the browser wars meant coding for Internet Explorer 4 or Netscape Navigator 4! But we have two things now that we didn’t have in the bad old days: a large body of knowledge about how to write standards-based HTML and XHTML using semantic markup and about how to separate content from presentation with CSS. If you stick to best practices in those two areas, the need to worry about every single rendering possibility from mobile devices diminishes and you can develop with confidence.

Testing your site

None of the free or fee-based testing options can equal the testing results you get with an actual device. I recommend testing with real mobile devices much as possible, but I know it isn’t feasible to run out and buy every single mobile device. There are some fairly reliable ways to test your site without going to that extreme. Some of the testing techniques are free, some are not. First, let’s look at the free options.

Opera provides two good testing tools. Using the standard Opera browser, select View > Small Screen to see your page rendered in an approximation of what a mobile screen might display. The Opera web developer bar has a button called Display that allows you to toggle CSS on or off when viewing a page using small screen view. Here you see two Opera small screen views of my blog, Web Teacher, first with CSS, then without.

As you can see, Opera renders the images in small screen view. (We’ll talk more about images later.) Note that the small screen view renders the content in source order, that is, the order in which the elements appear in the HTML. Elements are clearly distinguishable from a semantic viewpoint: headings, links, paragraphs, blockquotes. The organizational and semantic underpinnings hold up so that the content is readable and useable. This is especially easy to see in the second screen shot, with the CSS toggled off. Keep in mind that neither of the displays in the previous two screen captures are influenced by a handheld CSS media type stylesheet. When a heldheld CSS stylesheet is present, Opera’s small screen view will take it into account. More about this in a bit.

Opera provides a free browser that can be downloaded and installed on handheld devices. It’s called Opera Mini. (You can purchase Opera Mobile for even more capability.) Both are available at opera.com. Since Opera is in the business of providing browsers for mobiles, the company made a helpful online mobile simulator at operamini.com/demo. Here, you can load a page into the Mini Demo and operate it with mouse or keyboard as if it were a real mobile phone. The screen capture shows that the Mini Demo renders images and CSS. Again, there is no handheld CSS media type stylesheet affecting this rendering.

Another free way to test your site for clear structure, organization, and proper semantics is with Firefox’s Web Developer extension. Use this tool to disable images, JavaScript, and CSS and you’ll have a good idea about whether your content is going to make sense and be navigable in one of older and less capable mobile phones.

Here’s a Firefox screen capture. For this, the Web Developer Toolbar was used to disable all CSS, all JavaScript, and all images.

Viewing the page without images and with no functioning JavaScipt is very useful in terms of testing for older mobile devices. Keep in mind that some of the less capable mobile devices don’t render tables. None of them understand frames. Seeing your site this way really drives home the importance of standards-driven, semantic markup.

Using specific emulators

Some of the phone and PDA manufacturers have emulators on their sites that you can download and use for testing. Depending on your target audience, testing on a specific emulator might be helpful. If you are interested in specific device or manufacturer, check their site for developer resources. (For example, Sony Ericsson’s Developer World, Nokia has a developer forum with an XHTML section,

Testing CSS Handheld media stylesheets

An important tool in the Firefox Web Developer Toolbar is CSS > View CSS by Media Type > Handheld. If you look at Web Teacher in a standard monitor, you see that it is a simple two column layout using a left float for the content div and a large margin-left to create the sidebar as a second column. I’ll add a stylesheet for handheld media to the testing mix. It contains only two rules — to reset the sizes of the content div and sidebar div and to remove the float. Here’s the entire stylesheet:

#content {
	float: none;
	width: 95%;
}
#sidebar {
	width: 90%;
	margin-left: 5%;
}

The link to this stylesheet was added to the document head after the all media stylesheet, so as to be last in the cascade. I’ll use a link element for this. For those mobiles that do understand CSS, using link is more reliable than using @import for bringing in styles, although some of the more capable devices understand @import. Here’s the link element:

Media types are mutually exclusive. A user agent can only support one media type when rendering a document. If I want to retain any of my existing styles in a handheld display, I need to take one more step, and that is to list all the media types I want my existing styles to apply to in a comma separated list. I change the link element for my existing stylesheet, which is called 2col.css to include this media attribute: media="handheld,all". The two link elements are now:

The styles and the color scheme I have in 2col.css should also apply to handheld renderings, but the two column layout will be removed by the mobile.css rules.

Testing with the Firefox Web Developer Toolbar menu CSS > View CSS by Media Type > Handheld should now show handheld media results, and it does.

The first screen capture shows the two column layout, as it normally displays with the all media stylesheet. The second shows Firefox using the handheld media view.

From the second screen capture, you can see that Firefox has expanded the content div to 95%, according to the mobile.css rules. If you scrolled down the page past the content div, you would find the sidebar div now displays at 90% width after the content div. Note in the second screen capture, that styles from 2col.css such as the presentation of the list under the title image and the background gradient behind the headings are retained because of the handheld media designation in that stylesheet.

You may not want to retain any of your all media styles in the handheld CSS rules, as in this example. Keeping the background images, for example, results in longer page load times. Since many wireless mobile devices load very slowly, you want to really simplify things for handhelds. In that case, simply leave the handheld media attribute out of your main stylesheet. I’ll give you more tips for simplifying things for handheld media shortly.

Testing with subscription services or with software

The testing tools I just mentioned are all free. There are other options that are not free, but you might find them helpful and worth the expense. Browser Cam, where you can test your sites in all sorts of browsers, has added a testing area called Device Cam. Here you can test a page in a smattering of Windows Mobile-based PDAs and several BlackBerry versions. Here’s a screen capture of the test page in a Device Cam rendering of a BlackBerry. Note the strong resemblance to what you saw previously in Opera’s small screen view when the CSS was toggled off.

A brand new option for owners of Adobe’s latest CS3 software is Adobe’s Device Central. Device Central uses skins for dozens of mobile devices to display your content in various ways. Here’s a rendering of the test page in a Nokia 7390 skin.

Device Central can load a live URL or a file from many of the Adobe CS3 applications. It responds to the presence of a stylesheet of the handheld media type when the page is rendered using Opera’s small screen view. Using the Opera small screen view is an option with each of the skins in Device Central. Deselecting the option to view the rendering with Opera’s small screen view in Device Central rendered this page as two columns, in spite of the presence of the handheld stylesheet rules meant to eliminate that.

Tips for handheld CSS

Handheld media stylesheets can be more extensive than the two rule example I showed you previously. A few more rules would certainly benefit Web Teacher, but keep in mind that handheld stylesheets should be as small and compact as possible because of download time.

What can you do to simplify your site and make it more usable in mobiles? First, eliminate some of these problematic items from mobile display.

• Eliminate floats and frames
• Eliminate columns – one column with the content first is the best option
• Eliminate scripted effects such as popups or pop out menus in favor of plain old HTML and simple text menus
• Eliminate decorative images that slow down the loading process. Use display:none to remove anything that isn’t absolutely necessary, such as links to external resources. Remember, however, that devices that don’t understand CSS won’t do anything with display: none. Any essential images need to be reworked for the small screen and the width and height attributes need to be included in the HTML.
• Eliminate nested tables and layout tables. If you have tabular data, consider finding a way to present it in a linearized alternate display.

Once you’ve simplified through elimination, start building the rules you need to add. Consider these ideas.

• If you’re not already using relative measures, switch to ems or percentages rather than pixels
• Reduce margins, paddings and borders to suit the small screen
• Use smaller font sizes for headings and paragraph text
• If you have a long navigation list at the start of the page, add a skip to main content link, or move the links to the end of document flow. Keep the number of clicks required to get to content as minimal as humanly possible. Without a mouse or keyboard, most mobile users have to click laboriously through any top navigation.
• Make sure your color combinations provide good contrast between foreground and background colors, particularly for devices with fewer color options.

Tips for bloggers

Some blogging software provides the opportunity to format a single blog posting with several different templates, one of which can be meant for mobile users. This specially formatted and simplified material is posted to a unique URL on your site, perhaps something like mobile.mysite.com. If you’re a blogger, check your software to see if you have this capability with your blog. One important consideration for the mobile users of your blog is to keep the number of blog postings per page to a minimum for faster downloads.

In summary, making your site mobile friendly can be boiled down to a few concepts. Use validated, standards-based HTML or XHTML, ensure meaningful semantic markup with presentation removed to a stylesheet, and add handheld media rules as needed.