Archive for June, 2009
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.
A lot of people come to us and say that they already have a web site and want a mobile version. Their web site is driven by a back office – perhaps a database, CMS and any other data or business logic. They’ve already invested in creating a web experience and they want to see a mobile version – and they don’t want to see a large up front integration effort.
We at bemoko believe that you need to design for mobile – but that does not necessarily mean a lot of effort. It means being aware of the functions that a mobile user benefits from, creating a UI that looks good on their choice of phone and a general rounded well delivered end-to-end user experience.
Both these desires – the desire for an efficient delivery, driven from their existing web site investment and the desire to create a focused, relevant and elegant mobile UX – can be met using the bemoko approach.
Take a read of a recent article on our bemoko wiki – Semantically Tuning a Web Site – to give you an idea of how we can use your existing web site today to deliver a “designed for mobile” user experience, without having to follow the generic transcoding approach or blindly squeezing your PC web site onto a mobile. Since this mobile site is driven by your web site, if you make updates to you web site the mobile web site will follow. We’ll shortly be releasing an article on how you can deploy bemokoLive to support this PC website transformation approach as well as a few case studies of some people who were pretty happy with what they saw. Give us a call if you want to know more and we’ll get a live demonstration up for you.
With the iPhone 3.0 firmware released today, I thought I’d show you how to access one of the features I’ve been most looking forward to – support for the geolocation API in Safari means I can now create location aware websites.
This will be just a quick demo to retrieve and display the current longitue and latitude of your phone, along with a googlemap so we can see if the results are right. The more interesting applications will come….
To do this we’ll use javascript and the newly added Navigator.Geolocation interface to call the getCurrentPosition() function to retrieve the current longitude and latitude of the phone, which we’ll display and pass to the googlemaps API.
The code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 | <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE html PUBLIC "-//WAPFORUM//DTD XHTML Mobile 1.0//EN" "http://www.wapforum.org/DTD/xhtml-mobile10.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <title>iPhone 3.0 geolocation demo</title> <meta content="width=device-width; initial-scale=1.0; maximum-scale=1.0; user-scalable=0;" name="viewport"/> <script> function handler(location) { var message = document.getElementById("message"); message.innerHTML ="<img src='http://maps.google.com/staticmap?center=" + location.coords.latitude + "," + location.coords.longitude + "&size=300x200&maptype=hybrid&zoom=16&key=YOURGOOGLEAPIKEY' />"; message.innerHTML+="<p>Longitude: " + location.coords.longitude + "</p>"; message.innerHTML+="<p>Latitude: " + location.coords.latitude + "</p>"; message.innerHTML+="<p>Accuracy: " + location.coords.accuracy + "</p>"; } navigator.geolocation.getCurrentPosition(handler); </script> </head> <body> <div id="message">Location unknown</div> </body> </html> |
The results:
- iPhone OS 2.2.1
- iPhone 3.0
- iPhone 3.0 – I am here!
Try it for yourself by pointing your Safari browser at http://bemoko.com/blog/iphonegeo.
Update 27/7/2009: I noticed the zoom level on the google static map API wasn’t being set so the map was zoomed all the way out. I’ve added a default zoom for the demo code above. Not sure if thats a new requirement from Google’s side?



