Carsonified » Coding

How to build mobile widgets

Ryan Carson — Fri, 10 Apr 2009 21:46:21 +0000

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:

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.
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.
Images. These are contained in a single images folder.
JavaScript files. These are contained in a single script folder.
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:




  
    Twiggy

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.

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

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

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

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 , insert the following divs:



  
    What is your name?

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:




  My Awesome Application
  It asks you your name, and says hi!
  
  240
  320
  
    John Q. Developer
  
  
    My Awesome Application
    2009-04-08

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:

While you’re there, change your label to:


What are you looking for?

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.

Coding for the mobile web

Chris Mills — Wed, 05 Mar 2008 12:59:29 +0000

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:

Do nothing except follow web standards.
Create a completely seperate mobile site
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