Archive for July, 2009

So, “The market for mobile applications, or apps, will become ‘as big as the internet’, peaking at 10 million apps in 2020″ says GetJar – see BBC – Apps ‘to be as big as internet’ and GetJar forecasts 100,000 mobile apps by end of 2009. With Juniper Research predicting 20 billion app downloads by 2014 this a great outlook for mobile apps. But we shouldn’t be thinking of apps as an alternative to the internet. We really need to be thinking of them as one.

The buzz at the moment is clearly on app stores with the iPhone app store clearly leading the pack. See BBC’s click online summary from last week – Mobile phone applications grow up – for a great picture of the status quo.

We naturally turn to the ongoing debate of apps vs browser – Apps or browser? GetJar vs. Google on the future of mobile services. We needn’t think about either approach being right or wrong, or whether one approach will beat the other, especially when you consider that the user experience and commercials demands can vary wildly in different sectors or demographics. Let’s instead think about how the boundaries between the downloadable app and the web app can become blurred – creating a seemless experience for the end user.

Personally I’m getting pretty excited about the emergence of HTML5 web app stores as the HTML5 browser support arrives. We’re already seeing a taster of this HTML5 support, with the iPhone geolocation support in iPhone 3.0. Many apps currently in the app store realm lend themselves well to a personalised microsite with offline capabilities (such that HTML5 will enable) – take any of the information driven ones as examples, such as Amazon Mobile or Things. Developing in HTML5 brings with it the benefits of delivering to a wider set of devices and reusing existing web dev skills to create the apps. With these benefits in mind, the Open Gardens blog covers brilliantly the challenges that have to be tackled to create an HTML5 viable ecosystem – most importantly, what is the incentive for all the participating players.

We see the likes of (1) Nokia with their WRT widgets having foundations in HTML, CSS and Javascript and (2) Palm using HTML5 for native application – both providing potential alignment with the HTML5 web app store approach.

Now it’s really Google who is going all out for this HTML5 web app approach. With a slew of hot Android devices coming onto the market we can see Google slowly taking a slice of the smartphone. With the Android, Palm WebOs and Safari (iPhone) browsers all based on Webkit and with Webkit promising great HTML5 support things do look bright for HTML web apps.

BTW – to make my bias known – I co-founded bemoko which specialising in the delivery of the web to mobile. We have created a platform that allows existing (normal) web developers to deliver excellent mobile web UX – along with this wave of HTML5 (and widget) dev that is coming.

Posted in: mobile No Comments

Over the last couple of months we’ve started to use Canoo Webtest to functionally test our mobile web sites. We now use it for both product deployment cycles (we spin up a full version of bemokoLive and test a sample site prior to packaging up the platform) and site development.

What has particular impressed us about Canoo is the way we can rapidly create clean and succinct tests that address all of the functional aspect of a mobile web site that we can need to automatically test. There is a rich set of functions in Canoo to click around a site, interact with a page and test functionality and content of a page. We write all our scripts in Groovy which provides a language that is light on scaffolding syntax (i.e. code just what you want to do), allows us to dig into misc Java libraries as we choose and provides a functional language that is human readable (well to us techies).

For example, take the following test script:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
package com.bemoko.webtest.live
 
import com.bemoko.commons.test.webtest.BemokoWebtest
import com.bemoko.commons.test.webtest.WebtestXmlParser
import com.bemoko.live.devices.data.conf.HeroDevices
import com.canoo.webtest.engine.StepFailedException
 
 /** 
  * Test that welcome pages are rendered correctly to the hero devices
  */  
class PagesTest extends BemokoWebtest {  
  void test() {
    def parser=new WebtestXmlParser()    
 
    // (1) Iterate over HeroDevices    
    new HeroDevices().all.each { deviceData ->
      webtest("PageTests : ${profile} : ${deviceData.id}") {
        config(liveConfig) { 
          deviceData.evidence.each() { 
            header(name:it.key, value:it.value) 
          } 
        }
 
        // (2) Invoke the welcome page and verify some of the content
        invoke "/welcome/i", 
         description: "Index page : ${profile} : ${deviceData.id}"  
        verifyTitle "bemokoLive - i"
        verifyLinkedContent 
          xpath:"/html/head/link[@rel='stylesheet']/@href", 
          accept:"text/css"
        verifyLinkedContent 
          xpath:"//img/@src | //input[@type='image']/@src", 
          accept:"image/gif;image/png;image/jpeg"
 
        // (3) Validate document using an XML parser
        groovy { 
          parser.parseText(step.context.currentResponse
            .webResponse.contentAsString) 
        }
      }
    }
  }
}

The bemokoLive test suite provides a collections of devices that allow you to easily simulate requests from particular devices. The HeroDevices class, in the script above, provides a collection of around 10 devices that provide a representative coverage of different types of devices. We (1) iterate over this collection and pass in the evidence for the device, i.e. the HTTP headers, into the webtest configuration. We then (2) invoke a particular page, test its title and verify that the linked content is good. Finally (3) we validate the document against the DTD in the document – great for making sure nothing bad has slipped into the page.

Reports get generated with a full break down on the tests and any step failures along with a quick summary, for example the following screen shot shows the summary of test run of 431 tests which we ran against one of our customer sites. I’ve deliberately included a report with failures to make the summary a little more interesting:

Canoo mobile web test summary
There’s much more you can do with canoo and the Groovy scripting approach – take a read of automated testing on our bemoko wiki for some more pointers.

With this approach we can build up a robust set of scripts that verify our deliver and provide great foundations for our real device testing – no more burning time on real device testing dealing with functional issues that could have been caught earlier in development. This is also good black box test, so whether you’re using bemokoLive or a.n.other approach it’s equally applicable. If you’ve got a mobile web site that you want us to test, or help you get started to run this testing yourself just get in touch.

Posted in: mobile No Comments

We’ve started using a quick ImageMagick script to add shadows and borders to images. Useful for making screen shots stand out a little clearer on our blog and wiki.

For example, in a unix shell, create the function below (either by cutting and pasting the code into your shell window or adding to you shell init scripts) :

1
2
3
4
5
6
7
8
9
10
11
image-shadow () {
  out=${1%.*}-shadow.${1#*.}
  in=$1
  echo "Converted file : $out"
  if [ ! -z $2 ] ; then 
    convert $in -frame $2 $out
    in=$out
  fi
  convert $in \( +clone -background black -shadow 60x5+10+10 \) \
    +swap -background white -layers merge +repage $out
}

and then run

image-shadow myimage.png

to add a shadow to the image … or run

image-shadow myimage.png 6x6

to add a shadow and 6 pixel border.

Very simple to get images like …

Mex 2009 mobile web site

More examples and details on our wiki @ http://bemoko.com/wiki/ImageMagick.

Posted in: mobile No Comments