What We Do

We are a new company focused upon HTML5 based mobile web development along with apps where they makes sense and traditional sites. We work on both the front and back end. This is not your grandfather’s mobile web, rather, as experts in the field we leverage the latest technologies and platforms to provide optimal function in a cost effective solution. We also update and maintain older sites to benefit from current technology.

Our philosophy is Mobile Minimalism, underpinned by KISS, techno and business savvy, psychology, art and an open mind – we love to learn and strive to constantly improve.

We intend this site as both a place to be found by clients new and established, and as a reference and information exchange for members of the mobile community – developers and users of exciting mobile web technology.

Posted in Corporate | Leave a comment

Illustrated History of the Mobile Phone

Remember the remarkable ground breaking mobile gadgets of way back when – well ten or fifteen years ago anyway. Watch the video and enjoy!

Posted in Mobile Hardware, Other, Trends | Tagged , , | Leave a comment

Near Field Communications (NFC) and Mobile Payments

First the Techno Mumbo Jumbo

Near Field Communications is receiving a fair amount of attention in the mobile space in the USA just recently. This is a relatively simple technology relying upon the well known physical principle that the signal strength of the magnetic component of an EM wave transmitted by an antenna starts very great but falls of very rapidly (approximately proportional to inverse cube of distance) within a radius that is termed the ‘near field.’ For practical approximation the maximum extent of significant near field effect is one wavelength though for the compact antenna of a smart phone it would be less – for benefit against eavesdropping and interference this is a beautiful thing! We are talking here essentially about an air core radio frequency transformer where the transmitter and receiver are coils tuned to resonate at the transmission frequency which is in the unlicensed ISM (Industrial, Scientific, and Medical) band at 13.56 MHz and with a band width of 14 KHz. At greater distances than approximately one wavelength the signal strength falls off according the inverse square of distance from the antenna. For practical purposes the signal to noise ratio of any detectable signal at this distance or greater is insufficient to enable communication at reasonable data rate using consumer grade electronics.

The Lo Down on Expected NFC Applications

Summarizing all the above, useful bandwidths of hundreds of kbits per second of secure data transmission are possible via NFC over distances of 20 cm or so. The near field limit where sophisticated instrumentation still has a shot at eavesdropping is of the order of meters. There will of course be protocols for coping with one or two way communication, encryption, and for collision avoidance.

Tip – Relevant standards include the draft standard ISO/IEC 14443 Identification cards — Contactless integrated circuit cards — Proximity cards”

So Whats The Big Deal With NFC?

So why all the fuss anyway? In a couple of words “mobile payments.” You know, wave your phone near part of a gas pump or ticket machine or beverage dispenser and “ka-ching.” Slightly more exotic applications will no doubt abound – how about buying a ticket to a concert by waving your phone near a billboard?

One unique smart phone characteristic from a marketing perspective is that it is much more likely to be intimately connected to one user (how often do you lend your mobile to some one else?) So, combining that fact with ever increasing efforts to track users habits and hardware and correlate them to personal profiles and I think we might soon start to see personalized or location specific or real time pricing to go with personalized advertising?

So, what happens if you leave your smart phone in the movie theater (yes, I’ve done that too)? Are you going to become the proud but remote owner of all kinds of “wave and dispense” merchandise or services over a very short period? At the very least a mobile device typically has a auto timed lock out requiring a PIN to unlock but I’m guessing that isn’t going to be enough. Of course there are myriad application details such as identification, security, commissions, even credit limit, to be addressed. Some of these will be addressed in future postings about mobile security, etc.

Some recent smart phones for the US market already have NFC built in. Expect this to become the norm very quickly.

Not So Revolutionary

Don’t get too excited. The USA is late to the mobile payments party. Many Asian and European mobile users have had some access to this technology available for quite a while. The essential problems in the USA are the normal suspects: lawyers, politics, corporate strategy. However, consumers by and large want this and the lure of increased profit channels has become sufficiently irresistible to all potentially involved and as recently as this November ATT, Verizon, and T-Mobile announced what amounts to the kick off the mobile phone payments story for the USA with the formation of the ISIS joint venture. It turns out that Barclays Bank along with Discover Financial Services are also involved. Roll out is expected in the first geographic markets within 18 months.

More information about ISIS can be found at their website.

Posted in Other | Tagged , , , , , | Leave a comment

Google Chrome Frame brings HTML5 to IE6, 7, 8

If you are frustrated by the inability of IE8 and below to deal with your beautiful HTML5 code then fret no more. Google has come to the rescue. Go over to code.google.com/chrome/chromeframe for the skinny on how to bring those IE browsers in line with Google Chrome’s WebKit based reality when it comes to HTML5 goodness. All you have to do is add a single line of code to the <head/> section of your file and you’re done, that is assuming visitors using IE8 and below have download and installed the Google Chrome Frame plug-in. You can add some simple boiler plate code to detect the absence of the plug-in and let those visitors decide if they would like to enjoy the enhanced browser experience.

Behind the scenes the plug-in renders pages using the WebKit layout engine and V8 JavaScript engine which reportedly run very much faster than the native IE code.

Posted in HTML5 Browsers | Tagged , , , | Leave a comment

Another OS: MeeGo

As you can see from the little graphic on the right, Meego which is a brand new Linux based OS as of mid 2010 from a partnership between Nokia and Intel, is aimed at supporting a wide variety of application platforms. According to MeeGo developers are very welcome (how many OSs can a developer commit to?)

They state that MeeGo brings together the best application and platform development tools available. At the heart of development is the MeeGo SDK, including Qt, which provides a full set of consistent, cross-platform APIs. Qt itself is a cross-browser application and UI framework supporting the concept of write once deploy elsewhere. Qt incorporates a browser based upon the open source WebKit standard used by many main stream browsers including Safari and Chrome.

To give an idea of what this is all about, here is what the MeeGo site has to say about the Handset application of their software platform..

Today’s users are demanding more powerful and feature-rich devices to take with them on the go. Next generation smartphones allow users to enjoy a rich and dynamic Internet experience, watch HD movies, and multitask like never before on a small form factor device. Travel lighter and longer with extended battery life. Wherever you go and whatever you do, it’s a mobile experience that not only does more, it does it better.

The MeeGo based platform is specifically designed to enable the application and services ecosystem for these mobile, rich internet and media-centric devices. The MeeGo handheld platform builds on the foundation laid by Maemo and Moblin.

The Nokia web site notes that MeeGo is not currently planned to replace the Symbian OS on their handsets, but it will be used on higher end handsets.

Posted in Mobile OSs, Mobile Software, Trends | Tagged , , , , , | Leave a comment


HTML5 is a Work in Progress

The HTML5 standard is not yet final as of this posting but is in working draft status. Major web browsers are playing catch up to the more stable aspects. I would expect to see HTML5 in major adoption by both user agent and browser providers, as well as developers and designers well within a couple of years. It is already having having an impact, and I would expect to see the adoption for mobile sites to take center stage and displace much of the app store momentum in its wake – after all, why maintain and download many apps when a single mobile web site works both online and offline just as well?

HTML 2.0 (1995) 3.0 amd 3.2 (1997) were quite hodge podge. The 1998 Web Standards Project added weight to the need to let W3C define standards and it pushed for browser developers to follow such standards to help alleviate proprietary tags, behavior, etc that has historically caused many web developer a lot of sleepless nights. HTML 4,0 (1999) has been the standard until even now in many regards. The first true XML based standard (as opposed to almost XML) was XHTML 1.0 (2000) together with its related DTD however most browsers anyway continue to internally render the strict XML markup as if it were still the sloppy HTML version, replete with proprietary behavior quirks (can anyone say Microsoft?). Meanwhile, the increasing expectations for gee-wizz browser functionality brought about by slick high bandwidth connected devices have already placed such serious demands upon developers and architecture that more standardization and functionality was obviously needed. Next up, XHTML2.0 was a work in progress at W3C from early 2000s until 2009 when it was abandoned without any major browser implementations. The point of XHTML 2.0 was to move browsers and developers to a completely XML structured framework however the project was abandoned largely to give way to the WHATWG group (Web Hypertext Application Technology Working Group) founded by experienced developers and designers and adopted into W3C as a formal project in 2007. This project was later renamed to HTML5 and garnered great support among power players in the industry such as Google and Apple. The goal of the HTML5 project is standards to allow designers and developers to more easily create much richer mobile and static web experiences that are compatible across platforms. All this while HTML5 compliance must include that browsers (user agents) remain backwards compatible with earlier non HTML5 markup. HTML5 is an evolution of HTML4, XHTML 1.0 and DOM Level 2.

But Wait a Minute is HTML5 and XML document?

Aha! No it isn’t, however lest you worry about the inherent sloppiness that may be encouraged let me introduce the strictly XML flavor called, you guessed it, XHTML5 which must be served with an XML MIME type. XHTML5 still requires the HTML5 doctype as well as XML’s strict, well-formed syntax.

What’s New in HTML5?

Included are standardized things that reflect what developers have been doing by much more tedious and non standard means in recent years. Things such as:

  • new semantic elements (tags) and attributes
    • some new content tags..
      • <figure> for visual content such as illustrations
      • <video> pretty self evident
      • <audio> pretty self evident
      • <embed> plug in content like Adobe Flash
      • <canvas> drawable backdrop
    • new form attributes help with things like form validation and auto fill that may be user agent dependent
      • <input type=”email”>
      • <input type=”url”>
      • <input type=”range”>
      • <input type=”number”>
      • <input type=”date”>
      • <input autofocus>
      • <input autocomplete>
      • <input placeholder=”placeholder text”>
      • <input required>
    • some new application related tags
      • <meter> scalar measurement within a know range
      • <progress> fractional completion
      • <time> time encoded data various formats
      • <details> disclosure widget such as accordion type container
      • <command> user invokable command with graphics
      • <menu> define menu structures within applications
  • APIs for common developer tasks
    • <audio>
    • <video>
    • inline editing
    • offline application
    • history – use browser history
    • web protocol
    • drag and drop page elements
    • geolocation
    • 2D canvas drawing
    • local data storage
    • web workers
    • web sockets
    • messaging
  • Support for simple means to include audio and video

CSS3 is Not Part of HTML5

Though frequently mentioned in the same sentence CSS3 is its own W3C project. CSS3 has theoretically been around since 2000 but development has been split into modules some of which are progressing slower than others. Most current browsers actually support CSS2.1 well. CSS3 deserves its own article. Vendor specific extensions are available to support various aspects of CSS3.

Tip: www.ecsstender.org offers a helper library for cross browser CSS3

Tip: www.css3generator.com tracks vendor specific CSS code

CSS3 will allow much more control of issues such as typography (using local or remote open source or licensed font libraries).

Tip: see www.paulirish.com/2009/bulletproof-font-face-implementation-syntax to learn about current cross browser techniques for font support

Tip: www.fontsquirrel.com lists license free fonts and font kits which include style sheet snippets to include them and license terms (read).

HTML5 Content Models

Tags can be grouped into the following content usage categories or contexts. Many tags belong to more than one usage context.

  • Metadata – tags that sets context of presentation or behavior of the document
  • Embedded – tags that import other content into the document
  • Interactive – tags that define content used for user interaction
  • Heading – tags that define header of a section
  • Phrasing – tags that define the text of the document (many elements in this category)
  • Flow – tags that define presentation flow of the document (this most elements are in this category)
  • Sectioning – tags that define the scope of headings and footers

Where is HTML5 at Now?

Implementation is increasing very rapidly eight now (late 2010).

Several other sites include up to date matrices of support. For example:

Tip: A particularly useful javascript library is found at www.modernizr.com. This library adds an object to your client which may be interrogated at run time to check for supported HTML5 features, and thus offer your code a way to deal effectively with cross browser variances via alternate code.

In a slightly odd twist Mr Softy is on top of HTML5 developments and promises to deliver upon them in IE9 while at the same time IE8 and lower offer little support for HTML5 when compared against most other browsers.

HTML5 Error Handling

Deprecated Tags and Elements

There are several , most notably <u> but most of the others were very rarely used except for many deprecated <table> attributes.


DOM is now part of HTML5 which implies that HTML5 scripts should work on any platform.

New methods include

  • getElementsByClassName()

HTML5 doctype

This is simply ‘<!DOCTYPE html>’

The presence of this with no prior white space as first line of a file triggers HTML5 standards mode for the browser.

HTML5 charset

This is simply ‘<meta charset=”utf-8″>’

Dealing with IE8 and Below

IE8 and below don’t even know what many new HTML5 tags are. One way to prevent these browsers from breaking is to conditionally include a script snippet hosted by Google which will dynamically retag the offending pages to keep these older browsers happy.

<!--[if lt IE 9]>
<script src="http://html5shiv.googlecode.com/svn/trunk/html5.js"></script>

Canvas and Canvas API

Dynamic drawing via javascript, etc with layers

Tip: since drawing is very fast it is a good idea to make sure external resources have loaded before using them as source for drawing functions. For example use ‘img.onload’ event to trigger call to drawing routines.

Drag and Drop API

Drag and drop has become a fundamental component of modern interfaces.

Unevenly implemented across browsers at present making actual usage difficult. Based off of Microsoft implementation (been present since IE5) but even IE only partially supports the API. Oh wonderful Microsft! Can drag links, images, etc. Event driven.

Tip: Supports dragging elements from external applications – potentially huge!

Offline Web Applications API

This is perhaps the major reason why ‘app-store’ apps may not have such a mainstream future as the current mania surroudning them might suggest.

Store a version of the application in user agent cache along with data. Offline local updates will be synced with cloud upon going back online.

Note: hosting servers must recognize the manifest mime type:

<html manifest="cache.manifest">

This API is already widely supported, except in IE8 and below (of course)

Tip: Offline applications currently require user to ‘opt-in’ for syncing externally

HTML5 Video

Current HTML5 spec does not define a standard CODEC and licensing, patent issues are playing out big time currently so that major browsers are targeting differing CODECs. Perhaps the open source and very good VP8 CODEC from Google and others will win out. You can read about this at the WebM Open Media Project Blog. Bottom line it is currently necessary to support at least several CODECs.

Tip:www.videojs.com, and www.html5video.com libraries offer help with this currently messy area.

Example code to public video with CODED fallback in HTML5:

<video width="240" height="236" controls preload="false">
<source src="video/myvideo.mp4" type=video/mp4"/>
<source src="video/myvideo.ogv" type=video/ogg"/>

Tip: Use fall back content to support multiple video formats in the order they should be tried. Note that the iPhone must see mp4 listed first or it will fail. Fall back to flash can also be supported.


Spec is currently at draft stage. It specifically allows each user agent to decide its own approach to finding location and defines standard methods to access and use that data. Device support is moderately good at present time. Location can be found on one shot basis or continuous tracking basis. Currently, the user agent must include methods to ensure the user has to opt in before enabling exposing their location to the application.

Tip: currently, a good cross browser solution is to use Geo.js library. This is hosted at Google.

Web Storage

Adds a this leg to persistence of data. Existing methods include cookies (limited storage), or database or file storage on server. The web storage API is no longer part of the HTML5 working group or spec but has been put in its own sub project: dev.w3.org/html5/webstorage

The web storage mechanism uses key-value pairs to store both ‘session data’ (single session in single window) and for ‘local storage’ (over multiple windows and persists longer than one session). Web storage allows much more data to typically be stored locally when compared to the cookie approach. A set of access methids and event listeners are defined for access and usage of web storage. Support is good cross browser but inconsistent between browsers.

Tip: currently, a good cross browser solution is to use the jStorage plugin (for Prototypejs, Mootools, jQuery etc libraries)  found at www.jstorage.info

Note: There are competing approaches to local storage. These include Google Gears and Web SQL Database (another sub project of HTML5)

Web Sockets

The web storage API has its own sub project: dev.w3.org/html5/websockets

Prior to AJAX the almost universal approach to client server communications was stateless connections. The client would establish a connection sufficient for a page to be downloaded, then the connection would be closed.

In all cases the client has been required to initiate a connection making it impossible to have the server push content asynchronously to the client without some form of polling by the client. These techniques are obviously wasteful and require complex control of firewalls and proxy servers.

“COMET” is a pre HTML5 Web Sockets work around approach increasingly adopted of late to overcome the lack of a “push” mode from server – such as would be afforded by a persistent connection. This type of functionality is very useful in applications such as monitoring, data logging, updates orchestrated by a cloud based server – the “smart grid” is a typical application where intermittent server initiated communication becomes useful.

The Web Socket is a persistent bi direction client server connection using either the Web Socket or Secure Web Socket communications protocol. As such it circumvents firewall and proxy server issues. It is easy to initiate by client side script and will allow applications such as streaming, push from client, etc.

Tip: This is a big deal, a game changer enabling many new areas of web applications.

Web sockets are not fully supported yet in most browsers.

Tip: check out www.jwebsocket.org

Interesting links






Posted in HTML5 Browsers, Standards, Trends | Tagged | Leave a comment

The Future of Native Apps vs Browser Apps

What do You Think?

My opinion is that HTML5 browser based applications are poised to steal the spotlight away from native apps (the app store type), perhaps leaving app stores as a mere shadow of their former self. After all, who wants to have to produce and maintain umpteen different applications each targeting a different phone operating system and version when a single well designed web site (application) will do the job just as well if not better?

A little background

Back when I started getting into mobile web back in 2006 there were no iPhone or Android smart phones. I developed a food and drink finder type of mobile website. Long story short I used user agent detection and had code on the server to issue forth either mobile or PC oriented pages. Even five years ago the task of adapting content to look pretty on a myriad of screen sizes present and anticipated was too daunting so I crafted the presentation aspects to automatically adapt to screen size. I learned that in 2006 only pretty limited and quirky mobile browsers existed. I established a minimal set of generally well supported XML and CSS and went forth. I did not use javascript as it was not adequately supported on any phones at that time. This approach appeared to work well and avoided many pitfalls of attempting to adapt to each platform through code which wasn’t and still isn’t really possible to do adequately well.

The arrival of the iPhone of course shook life into the mainstream mobile web market, at least in the USA where it pretty much didn’t exist until then. My site worked very well on even the early iPhone.

The introduction and explosive reception given to “app store” native mini apps pretty much put the kabosh on any business potential of my site. Native apps offered access to geo location, snazzy graphics, shake sensor, etc while browser support lingered in the dark ages i.e, pre HTML5.

Is HTML5 a Game Changer for Native Apps?

My experiences led me to throw in the towel on the business side of making any money from my browser based app – it could not compete against native apps (well that would be the iPhone kind in 2007). I came to suspect that the likes of Apple were purposefully dilly dallying on improving browser support in order to make hay from the interest in their app stores. Fast forward to 2010 and my view is that the game is changing quite drastically. Already, the latest iPhone and Android based phones do support a significant number of HTML5 features, for example javascript access to location information, enhanced graphics APIs, local data stores, that put the spotlight back on the browser based application as the natural choice for mobile web users. Of course, there will always be some applications where native apps make sense – those requiring very low level hardware interaction for example such as some high end games, or access to the connector port signals.

Posted in Trends | Leave a comment

Leave a comment