Posts in the ‘mobile’ Category
iPhone Apps – the current sensation in marketing circles. Every brand wants a piece of the iPhone action. Are brands jumping on this bandwagon as part of an overall mobile strategy or is it just the current trendy thing to do? Are brands becoming pre-occupied with mobile apps?
Many people forget that an iPhone app can only be used by people who have an iPhone. Whilst the iPhone is undoubtedly popular, it only has at most 5% of the market, so brands are effectively ignoring a majority of their consumers. Can this really be part of a considered mobile strategy?
There are a number of solutions to this problem:
1) Ignore it.
2) Create apps for other devices. This is expensive as it means a seperate development for each class of device, in a different programming language
3) Get the best of both worlds with a combined app and mobile web strategy. This can reach more consumers for a lower .
Save money, get a bigger audience
If you could have a solution that delivered the coveted iPhone app and also addressed consumers on all other devices you would have maximum coverage for your brand. And if it cost less than developing the native iPhone App, what’s not to like?
Using the latest release of the bemoko multi-channel web development framework, web developers can create a mobile website which works on all devices. The framework very easily allows the site to be tweaked for the iPhone, allowing it to be styled as an app with all the sliding page transitions and fancy effects associated with an app. So now you have a website that looks like an app, the icing on the cake comes with our integration of the PhoneGap framework to wrap the website in native code so it can be placed in the app store as a normal app and downloaded by consumers.
Now you have the iPhone App for the iPhone users and also a website that can be used by all your consumers whatever device they are on. And, because developing a website is much cheaper than developing a specialised app, you’ve only paid a fraction of the price of a native iPhone app with a limited audience.
Finally, a mobile strategy to keep everyone happy!
I’m really pleased to announce that v1.2.5 of bemokoLive is now released. This version takes a step forward in the management of mobile campaigns with the provision of sub-sites and content rules. We’ve also put together a great getting started tutorial you can download from our wiki.
Do you regularly send email newsletters to your customers? You might do this once a week, once a month or you might even manage email campaigns for many people. Now these campaigns most of the time may follow the the same format – perhaps it’s announcing latest books available or sharing information on your latest promotions – but you may also find that often you want to add something special to each newsletter, breaking out of the mold of the same old template. You might also be finding that perhaps 20% of people who receive your emails are accessing from a mobile phone.
bemokoLive, as always, makes it easy to take your message to mobile phone and engage with this growing number of people accessing from their phone, but with the release of v1.2.5 we’ve made it even easier to take 100% control of your email campaigns. With bemokoLive you can create a single site which defines your look and feel, as well as common functions such as getting content from your CMS. This site allows you to rapidly put together each months newsletter. sub-sites in v1.2.5 take this to next level by allowing you to customise each newsletter – by making as few or as many changes you need. Perhaps you simply want to include a different seasonal logo or even deliver the message with a whole new look & feel.
Context Rules is a great new feature that helps users of your site as well as site developers. Site users can now readily access either the PC version of the site or an optimised mobile version as they desire so that they can get the experience they want. Site developers can also use context rules to quickly test what the site looks like on different devices.
There’s the usual handful of other useful updates with this release – see the release notes for more details. And if you’re new to bemoko, please get in touch and we’ll help take you web sites to mobile (and other digital channels).
… or in other words we can readily synchronise local browser storage with back-send server persistent storage. This is one of the fundamentals of compelling off line web applications.
So a little background. You may know that you can store data in your local browser database with javascript like …
1 2 3 4 5 6 7 8 9 10 11 12 13 | function store() { if (window.localStorage) { var count=window.localStorage.getItem("count"); if (!count) { count=0; } count++ window.localStorage.setItem("count",count); } } window.onload = function() { store(); } |
and you can even see it in action here, if you got a decent browser such as the latest iPhone 3, Firefox 3.5, Safari 4.
But this ain’t much good if you can’t get this data back to the server to do something useful with it, e.g. share with friends, share with your other devices, keep a backup, send a message … I could go on.
So what we really need is a way to easily listen out to storage events and deal with it in one place. Yep, we could create our own Javascript framework to do this and handle getters and setters, but that sounds nasty to me.
Instead we can know use the onstorage attribute on the HTML body tag to hook into a function that will handle all of these call backs based on local stored data.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | function store() { if (window.localStorage) { var count=window.localStorage.getItem("count"); if (!count) { count=0; } count++ window.localStorage.setItem("count",count); } } function handleOnStorage() { myFunctionToSendDataToServer(event.key, event.newValue, event.oldValue); } window.onload = function() { document.body.setAttribute("onstorage", "handleOnStorage();"); store(); } |
Take a look at it in action here in the bemoko mobile test suite. It works on iPhone 3 and Safari 4. You can even see the complete code here.
Imagine if radio came along after television.
… would the first radio shows simply have been recordings off the TV?
Before the days of video recorders I used to sit and record the television with the new shiny mic onto cheap D90s I’d bought from the market. The novelty soon wore off and none of my friends seemed that interested in my recordings.
We’ve grown accustomed to see TV and radio as two very different media channels. In particular we don’t consider the radio as a lesser medium even though from a simple point of view it’s just a constrained TV. I love the radio – in fact I spend more time listening to the radio than I do watching the TV. Why? Not because I think there’s better content on the radio, and not because I think it’s physically better than the TV – more because it fits comfortably into my way of life and my context.
I work quite a bit – and I learnt pretty early on that I can’t work whilst watching the TV. Took me a while to realise that and I still experiment with it, but basically if I’m front of a TV I don’t get any work done. However the radio fits my mood – I can put on some back ground music, or even talk programs, to give me inspiration. It doesn’t tear my attention away and in some respects can enhance my work environment.
I do quite a bit of DIY, housework – my old paint splattered radio follows me around. I’m often amazed at how long a couple of AA batteries power the damn thing, even though I leave it on too much. It falls off tables, sit’s in damp rooms … it’s so simple and portable and it goes on broadcasting for me.
I can safely say I’ve never tried to watch a TV and drive. Don’t think I’ll ever give that a go, but I obviously do listen to the radio in the car. When good programs are on I don’t even mind sitting in traffic as it gives me a little time to think and relax … as long as it’s not too much traffic.
Radio production has learnt from the strengths of the audio only medium. You can in fact do things you can’t do on a TV, perhaps because of the limited budgets but perhaps because you can create an experience not possible when you’re distracted by the images. It reminds me of the classic line in Educating Rita when, in response to “Suggest how you would resolve the staging difficulties inherent in a production of Ibsen’s Peer Gynt” , … she simply replied … “Do it on the radio. ”
So where does this sit with mobile …
As we start to explore the opportunities with mobile, we’ll start to exploit the true value in an always on, context aware, portable communication channel. We’re starting to see it already. Rummble provide an excellent location based personalised recommendation service. facebook is being accessed regularly from mobile devices by over a quarter of it’s users to keep in touch with their community.
I see the next few years as pretty exciting, as we grab this mobile medium and let it power people’s lives. It’s why I’m spending a good bit of time at bemoko refining the way that we take everything we’ve learnt and created in the web world to power the mobile enabled web; taking the unique benefits of mobile to create experiences we only dreamed of before.
Today marks an Android first: the launch of the T-Mobile Pulse – the first PAYG Android device on the market.
Priced at under £180 this could be exactly what’s needed for Android to move beyond the luxury smartphone market into more mainstream adoption. Infact, this price puts it cheaper than the popular Nokia 5800 XpressMusic on T-Mobile’s current pay-as-you-go price list.
T-Mobile Pulse (image from techcrunch.com)
Using the same processor as the HTC Hero (a Qualcomm MSM7200A for those that like detail) it’s not obvious that many corners have been cut; although the case design isn’t up there with the Hero, and certainly reminds me a little of an old HTC Touch Winmo handset.
Screenwise, the resolution is standard Android at 320×480, although physically its reported to be a little larger that the Hero at 3.5″, making it about the same as the iPhone. See here on why having a physically larger screen could be a good thing for Android usability.
This is great news for mobile consumers, and great news for us at bemoko – we’re huge fans of internet-centric devices with capable browsers. And the more people that use devices like this, the more opportunities this gives us as mobile web designers.
This is the week that we saw Google Voice pulled from Apple’s app store concerning the industry sufficiently for the FCC to investigate.
Google Voice scares AT&T (and probably other operators) as it provides an alternative way for users to make calls as well as making it easy for user to switch between operators whilst keeping the same number (think roaming – pop in a local PAYG SIM).
I look back at my twitter stream from the week and I see a pattern of activity. We wait with baited breath to see if Apple will approve Spotify – an alternative to getting music from iTunes. We also see a pattern of rejections from Apple for PhoneGap apps. PhoneGap is an innovative service that makes it easy for web developers – with HTML, Javascript skills – to create iPhone apps … and Android apps … and Blackberry apps … and soon support for Palm WebOS, Nokia Symbian and Windows Mobile apps.
What is made clearly apparent is that an app store owner has control over what they choose to let there users install. Control is good – we don’t want apps to introduce vulnerability and stability risks to our phones and we probably want to avoid some of the shady sides of the industry – but who is to decide where to draw this line? When phone owners only have one place that they can go to get apps we are subject to problems of monopolisation control.
Apple cannot maintain strict control of application delivery to iPhones without seeing a backlash of people looking at alternative platforms with their alternative app stores. Apple have the user experience advantage at the moment – no where else is it so easy for user to get their hands on a rich set of applications – but as alternatives rise which have decent user experience and provide killer functionality missing from the iPhones, iPhone lovers may start to look elsewhere.
Michael Arrington (Techcrunch) quits the iPhone and Steven Frank (Co-founder, Panic) is “Not buying any future iPhone OS based devices” until the situation improves.
Apple, the iPhone and their app store have lifted the mobile industry in the past couple of years. I pray that Apple relax a few of their constraints, as I want Nokia, Palm and the Google Clan to have beat Apple by improving their user experience – not because Apple gives away the customers.
Update:
- Frustrating transcript of a call between Riverturn (provider of Voice Central one of the apps that Apple pulled) and apple highlighting some the challenges that app developers face
- Who refunds all those people who can’t now get support for the app they’ve downloaded and previously paid for
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.
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:
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.
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 …
More examples and details on our wiki @ http://bemoko.com/wiki/ImageMagick.
Form input modes are an important design pattern when it comes to requesting information from a mobile user. If you want to collect numeric data, you can constrain the input mode of the users’ device so that only numbers can be entered – this both simplifies data entry for the user and reduces the validation issues.
One of the challenging things on mobile is that the input mode is implemented in a variety of ways – see input mode. Just tonight I created an example of how we can make it easy for a site developer to use this input mode feature across a wide variety of devices. I thought I’d share it with you as a great example of how powerful bemoko tweakers are.
As with all bemoko site development, we create sites in standard XHTML markup. There’s an attribute – called “inputmode” – that was added to XHTML Basic v1.1, but still has limited supported. Much more likely is that a device will support the WCSS style “-wap-input-format:'*N'” or the OpenWave “format” attribute. As a site developer you shouldn’t have to care – and bemoko can take the pain away.
A site developer can specify the input mode in an input element using the XHTML Basic v1.1 notation in a standard way, e.g.
<input name="digits" value="" type="text" inputmode="digits"/>
bemoko can (behind the scenes) apply the following tweaker to optimise the markup for the given device and generate the correct input mode controls in the markup:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | class ImputModeTweaker extends AbstractTweakerPlugin { void tweakMarkup(Node node) { node.'**'.findAll { it.@inputmode == 'digits' }.each { tag -> switch (platform.activeUser.device.inputModeSupport) { case "useWCSS": tag.@class=(tag.@class ? tag.@class + " " : "") + "digits" break case "useFormatAttribute": tag.@format="NNNNN" break } } } } |
Note that this example uses the inputModeSupport DDR vocabulary to get the preferred input mode support. This particular piece of DDR vocabulary will be available in the next bemokoLive release.
Although a site developer shouldn’t have to care about this behind the scenes tweaking, the unique approach to mobile rendering that bemoko have taken, means that a site developer can care if they want. In particular they can take full control of the situation. This has huge advantages – you can build on the solid foundations on the maturing set of plugins and best practices that bemoko provides as well as being able to react and deliver quickly.