MiniApps Blog

Multi touch gestures using Webkit

Wed, 10 Mar 2010 19:53:16 +0000

I thought it might be useful if I posted a working example that demonstrates how to use touch and gesture events on the iPhone/iPad using Safari and Webkit.

I won't go into depth covering the basics of how touch events work, you can read about that in this article. What I will go into, is the basics of how my template works, so that you can easily adapt it for your own applications.

First, feel free to view the live demo, and read the documented code.

The HTML template file consists of a single square block that can be touched, dragged, resized and rotated using touch events. The JavaScript file provides a basis for handling six different types of touch event. The first three, touchstart, touchmove and touchend are all used to handle single finger touch events. In the example, the square block can be touched and dragged around the screen using a single finger. You can easily see when a touchstart event is triggered, as the square will turn blue in colour. If you drag your finger when the square is blue, a touchmove event is then triggered, and the square will follow your finger. When you release your finger, a touchend event is triggered, and the square will turn back to its original colour and remain where you left it on the screen.

The next three touch events, gesturestart, gesturemove and gestureend, are all used to handle multi touch events. These class as any touch event that uses more than one finger. In the example, a gesturestart event is indicated by the square block turning red in colour. A gesturechange event is triggered by performing a typical two finger pinch/zoom/rotate gesture, which has the effect of scaling and rotating the square. When your fingers are released, a gestureend event is triggered, and the square turns back to its original colour. It will also remain at the scale and angle of rotation that you left it at.

Take some time to read through the documented code and understand the way events are triggered. Any questions, please feel free to get in touch.

Serving iOS retina startup images for the new iPad

Wed, 28 Mar 2012 21:52:51 +0100

In the past we have touched on how to serve iOS startup images for full screen web apps using both CSS media queries and JavaScript techniques. Now that the latest iPad sports a retina calibre display, we must again look at the best way to serve startup images in our web apps.

Given the potential bandwidth cost incurred by downloading such large images (2048 x 1496 landscape, 1536 x 2006 portrait), the most advisable technique is to use JavaScript to serve only the assets a device requires (rather than downloading every asset, which would happen if we used media queries). This can be done using the following code snippet in the of your page.

You can test this code out using the example here.

It would be nice if Apple would provide a better way to do this rather than having to rely on JavaScript. Perhaps in the future we will be able to have the option to use vector formats, such as SVG for startup images?

iOS startup images using CSS media queries

Mon, 24 Oct 2011 20:47:09 +0100

Ever since the arrival of the iPad and iPhone 4, serving correctly sized apple-touch-startup-images for iOS web apps has been somewhat problematic, especially if you wish to cater for every type of iOS device.

A common solution has been to use JavaScript to detect what device the user is on, and then to write the correct image into the of your HTML file.


(function () {
	var filename;
	if (navigator.platform === 'iPad') {
		filename = window.orientation === 90 || window.orientation === -90 ? 'splash-1024x748.png' : 'splash-768x1004.png';
	} else {
		filename = window.devicePixelRatio === 2 ? 'splash-640x920.png' : 'splash-320x460.png';
	}
	document.write('' );
})();

To make things more complicated, you also need to serve a high-res startup image for the iPhone 4's retina display. The iPad requires two different splash screen images for each orientation as well. Things quickly start to get a bit messy…

As of iOS5, you can now use CSS Media Queries to serve each type of startup image required, so no need for JavaScript anymore!

Just use any of the following media queries in the of your HTML file.

If you are on iOS5 you can check out an online demo here. Add the web page to your home screen and then launch from the icon.

Caveat

The only drawback to this CSS only method is that every image seems to be downloaded, regardless of which one is used on the device. If your application is supporting both iPhone and iPad, it may be worth using the JavaScript solution still. But the choice is yours to make, depending on the number of files and their respective sizes. Hopefully Apple will eventually support another solution to serving the correct file, such as using the sizes attribute.

Adaptive CSS layouts using Media Queries

Wed, 23 Jun 2010 22:03:06 +0100

(Update 10/10/11) This an old blog post, and is no longer true to the way this site is built. If you would like to read about more current techniques, check out the article on mobile first, responsive design.

Over the past few weeks I have been refining the CSS3 Media Queries on this site in order to try and create an adaptive layout that can scale and resize to any window or screen size, whether it be on desktop, tablet or mobile device. I think (hope) that I've got things flowing pretty smoothly now, so I thought I would post the queries here so that others can adapt them:

I could have included all three media queries inside a single CSS file using the @media rule, but I quite like to keep things separate for simplicity. For now, I have chosen to use three individual stylesheets. The main site stylesheet (styles.css) is used as a master, and then the separate mobile.css and tablet.css stylesheets override certain CSS rules in the main stylesheet, to provide an optimised view that is dependant on the media query being used. I have also used queries based on both min/max-width and min/max-device-width, so that both desktop browsers and intermediate size devices can also make use of the adaptive stylesheets. Have a go at resizing your browser window to see the results.

Targeting iPhone 4 using CSS Media Queries

Sat, 26 Jun 2010 16:12:09 +0100

With the release of iPhone 4 and it's 326ppi display, there has been a fair bit of speculation as to what impact this would have on mobile web apps and websites that are optimised for mobile screen sizes. How would web developers target both older iPhones with a 480x320 display, as well as the iPhone 4's 960x640 display? Would we need separate CSS stylesheets for each device? How would images need to be optimised for the new screens?

It turns out that CSS media queries targeting 320px screens still work on iPhone 4. It's all down to Mobile Safari utilising a 'device to pixel ratio' density of 2. There is actually a distinct difference between a device (screen) pixel and a pixel that we typically define in CSS. For example, when the iPhone 4 browser viewport is equal to the device width, 1 CSS pixel actually translates to 2x2 device pixels. For those interested, there is a quite old (but very relevant) Webkit article about high dpi websites. It makes for an interesting read.

This is largely good news for mobile web developers, as very little needs to be done to our mobile CSS stylesheets for iPhone 4. Device pixels are translated to CSS pixels automatically. But what about images? Well, this is where some work needs to be done. In order for images to look crisp on the new iPhone 4 display, we now need to serve images that have a higher ppi than the standard web traditionally uses. To do this, the iPhone 4 (and any other high ppi device) can be targeted using the following CSS media query (Notice I have included rules both with and without the -webkit venor prefix).

Update (07/10/11) - the code below has now been updated to include additional vendor prefix properties, that did not exist at the original time of publishing this article.

/* High PPI Devices ----------- */
@media only screen and (-webkit-min-device-pixel-ratio: 1.5),
only screen and (min--moz-device-pixel-ratio: 1.5),
only screen and (-o-device-pixel-ratio: 3/2), 
only screen and (min-device-pixel-ratio: 1.5) {

	//high resolution images go here

}

I won't go into great detail on how to best serve images, but it basically involves creating images that are double the pixel size that you would traditionally need (e.g. a 100x50 pixel image translates to 200x100 pixels). You can then set the background size in CSS so the large images still take up the same number of CSS pixels as they would on a normal display. Walt Dickinson has already written a nice article that has some more info on how to do this.

Finally, one last tip – you can also test for the same value using using JavaScript:

if (window.devicePixelRatio == 2) {

//Targeted code goes here

}

Pixel perfect icons for iOS devices using CSS Media Queries

Fri, 02 Jul 2010 14:26:31 +0100

Jesse Dodds has written an excellent article on how to serve pixel perfect web clip icons for Apple iOS devices using CSS3 Media Queries. Well worth a look.

WKTouch - Multi-touch JavaScript plugin for Apple iOS

Mon, 19 Jul 2010 19:53:02 +0100

I've just released a little JavaScript plugin called WKTouch up on github. It's a tiny plugin for Apple's iOS Safari browser, enabling multi–touch drag, scale and rotate on HTML elements.

Using the plugin is pretty simple. Firstly, include the main JavaScript file in the header of your HTML document:

Next, add the following CSS to your stylesheet. Please note, your HTML element must use absolute positioning:

.touch {
    -webkit-user-select: none;
    -webkit-tap-highlight-color: rgba(0,0,0,0);
    -webkit-text-size-adjust: none;
    -webkit-touch-callout: none; 
}

#element1 {
    position: absolute;
    left: 10px;
    top: 10px;
    height:120px; 
    width:120px;
    background-color: blue;
}

Now add the class name and id to your HTML element:

Finally, in the head of your HTML file, include the following JavaScript to create a new instance of the plugin, making sure to pass it the id of your HTML element:

That's it! You can view a fully working online demo here using multiple instances of the plugin on one page. You can also download or checkout the source over on github.

iOS 4.2.1 brings some major new features to Mobile Safari

Tue, 23 Nov 2010 11:21:11 +0000

Apple has just released iOS 4.2.1 which offers some really interesting new features and improvements to Apple's Safari mobile browser. New features include access to the Accelerometer via the DeviceMotion event class, Gyroscope event data via the DeviceOrientationEvent class, an implementation of HTML5 WebSockets API and a StyleMedia class for querying CSS features via JavaScript. There is also improved support for web fonts amongst other useful enhancements.

There is a nice blog post detailing many of the new features over on Mobile Web Programming.

I'd still like to see access to things such as the iPhone camera, photo library and contacts — but this is a great looking update for iOS users and mobile web developers.

WKShake - 'Shake to Undo' JavaScript plugin for iOS Mobile Safari/Webkit

Thu, 25 Nov 2010 09:51:29 +0000

I've created a little JavaScript plugin that emulates the familiar 'shake to undo' gesture found in many iOS apps, so you can now use it in your web applications on iOS 4.2.1 onward.

Check out the online demo, or alternatively grab the source direct from GitHub.

Note: WKShake has since been renamed to shake.js.

WKTouch and WKSlider now hardware accelerated in Mobile Webkit / Safari

Thu, 10 Feb 2011 11:38:43 +0000

I've recently pushed a few updates to WKTouch and WKSlider on GitHub that enable full hardware acceleration in Mobile Webkit / Safari. iOS users now get a considerable performance boost when dragging and manipulating objects and UI elements. This is achieved by using CSS 3D transformations where available, as iOS devices offload these processes to the device GPU. For Webkit devices that do not yet support CSS 3D transforms (such as Android), the plugins provide a fallback using regular 2D transformations.

Another small improvement to WKTouch is the ability to drag an object at the same time as performing a two finger scale / rotate gesture.

Head over to the code section to try out demos of each plugin, or check out the source over on GitHub.

New sizes attribute in iOS 4.2.1 for web clip icons

Tue, 30 Nov 2010 09:31:06 +0000

A small but relatively undiscovered new feature in iOS 4.2.1 is the new 'sizes' attribute for defining different sized web clip icons. Instead of using previous methods, Apple now have a custom attribute you can use to target different device resolutions on iOS. Here's an example:

Now what we really need is for this new attribute to also work on apple-touch-startup-image, so we can finally define different resolution startup images.

Using HTML5 localStorage as a fallback for offline form submission

Sat, 18 Dec 2010 20:39:50 +0000

I recently put together a working demo for a client showing how you might use HTML5 localStorage as a fallback for form data submission when a mobile device is offline without signal. I've uploaded a working demo for anyone interested and the full source code is over on GitHub.

The demo uses window.navigator.onLine to listen for a boolean value of true or false, determining whether the device is online or offline. When online, the app makes a regular XmlHttpRequest and sends data to a server. If the device loses signal and goes offline, the app queues up and saves submitted data to localStorage as a JSON string. When online connection is next restored, the app then re-sends the queued data to the server automatically. Once the data has been sent successfully, the item is then removed from localStorage.

I won't go through all the code line by line as it's reasonably straight forward, but feel free to take a closer look on GitHub. Many Webkit based smart phones now support window.navigator.onLine, as does desktop Safari or Firefox. To test, try enabling flight mode on your phone, or disable wifi on your laptop once the app is open.

WKSlider - A touch slider UI JavaScript plugin for Mobile Webkit

Thu, 23 Dec 2010 09:33:24 +0000

I've just released another JavaScript plugin for Mobile Webkit, this time a simple to use touch–based slider UI plugin. So far I've tested it successfully on iOS, Android and Opera Mobile 10.1.

Check out the online demo, or alternatively grab the source direct from GitHub.

Tap.js - A lightweight 'tap' event JavaScript plugin

Mon, 12 Mar 2012 20:49:45 +0000

While the W3C touch events API is quite flexible in its low-level implementation for dealing with multi-touch interaction, it means that the higher level gestures we use daily in our web apps can take quite a lot of work for developers to implement themselves, even down to the basic 'tap' event. Many mobile web frameworks already offer support for such gestures, but if your app does not use or require such a framework, something as simple as a 'tap' plugin can become a necessity on nearly every mobile project.

Tap.js is a simple, lightweight plugin for a common 'tap' gesture. It has no dependencies and can be used just like any regular JavaScript event, along with standard event listener syntax. It also falls back to using regular mouse events when touch is not supported, so you don't need to manually feature detect or provide two different event types in your code.

Setup

First, include the main JavaScript file in the of your HTML document:

Next create a new Tap instance, passing the element you want to use:

var el = document.getElementById('my-id'),
    myTap = new Tap(el);

You can then start listening for 'tap' events using the regular JavaScript event listener syntax:

el.addEventListener('tap', tapDidOccur, false); 
function tapDidOccur (e) {
    //your code
}

You can stop listening for tap events like so:

el.removeEventListener('tap', tapDidOccur, false);

Tap.js is open source and available on GitHub.

Tested browsers

iOS Safari (5.1)
Android default browser (2.3.5)
Opera Mobile 11.50 (Android)
BlackBerry Playbook (1.0.8.6067)
HP webOS 2.1.0 (click fallback)
All modern desktop browsers (click fallback)

Enable CSS active pseudo styles in Mobile Safari

Mon, 17 Oct 2011 10:05:08 +0100

By default Mobile Safari disables CSS active pseudo styles on web pages, instead opting for a generic tap–highlight colour on clickable elements. A little known trick is that you can easily re-enable your active pseudo styles by declaring a touchstart event on the page. You don't even need to actually use the event, simply declaring an empty function will suffice.

Just add the following single line of JavaScript to your web page and all your active CSS styles will spring to life.

document.addEventListener("touchstart", function() {},false);

Note: if you do this trick it is also worth removing the default tap–highlight colour Mobile Safari applies using the following CSS rule.

html {
	-webkit-tap-highlight-color: rgba(0,0,0,0);
	tap-highlight-color: rgba(0,0,0,0);
}

You can view an online demo here.

On a related note, there are also some other useful mobile Webkit oddities that can activated by using empty event declarations, like making form labels clickable.

Making web content more accessible with iOS VoiceOver

Mon, 06 Jun 2011 10:34:49 +0100

If you're a web developer and own an iOS device, you may have noticed it comes with a whole range of accessibility features. One such feature is a built-in screen reader for visually impaired users, called VoiceOver. For a touch screen device, VoiceOver is a wonderfully capable piece of assistive technology, and a very useful tool that you can use to help test the accessibility of your web content.

This article gives an introduction to using VoiceOver on iOS, followed by some basic tips to help improve the accessibility of your web content. While covering iOS specifically for example's sake, many of these tips are also applicable to improving accessibility for screen reader users in general.

Navigating a web page using VoiceOver on iOS

You can enable VoiceOver on iOS by going to: Settings -> General -> Accessibility -> VoiceOver.

Using VoiceOver at its most basic level involves selecting an item by touching it, activating a selected item by double-tap, and scrolling by flicking three fingers. You can also swipe left/right to navigate through content elements in the natural order of your page’s markup. For quick page navigation, you can swipe up/down to jump through predefined sections of web content, such as headings, links, words, lines and even landmark roles. These pre-defined options are selected via a feature known as Rotator. A user can cycle through Rotator settings using a two finger rotation gesture anywhere on screen. The selected option is then read aloud as you rotate your fingers.

Aside from regular click events which operate using double-tap, touch events operate a little differently with iOS VoiceOver, since they rely on dragging the finger and not just tapping. If a web page features an element that has a touch event associated with it, the user must double-tap & hold on the element until an audible sound effect of three small tones is heard. Once the tones have played, VoiceOver then allows a touch gesture to be performed and ignores all other actions until the finger is next released. At this point VoiceOver returns back to it's normal state.

This may sound like a lot to remember at first, but VoiceOver is actually very simple to use and feels very intuitive after just a few sessions. Give it a go before reading on and try to familiarize yourself with the gestures.

There is a nice introduction to VoiceOver on the iPhone over on Apple's website for some more in-depth examples and other features not covered here.

Using WAI-ARIA landmark roles

As you will have discovered after trying VoiceOver, one of the fastest ways to navigate through a large web page is to use the Rotator feature. If your web pages use well structured headings and markup, then your pages should already be relatively easy to navigate. A nice additional feature you can take advantage of however, is the use of WAI-ARIA landmark roles. These role attributes enable screen reader users to quickly jump to predefined sections of a web page, and these can be accessed by VoiceOver using the Rotator 'landmark' option.

Here's some basic HTML5 markup for a common web page complete with landmark roles:


     Page heading



     
          Sub heading 1
     
     
          Sub heading 2
     



     Footer title

Note: as of iOS 4.3 the 'landmark' option is not included as a default rotator setting, and must be selected first in the general accessibility options. iOS does not currently read out the landmark types either, it just simply describes each as 'landmark start' and 'landmark end'.

Hiding and showing content

Because many client-based web applications are often just single page controllers that hide and show content when switching between views, it is important to make sure that only visible content is accessible to screen readers. If you can't visually see something on screen, then (usually) it should be hidden from assistive technologies as well. Some mobile web applications simply slide elements in and out of the viewport when transitioning between screens. This can be problematic since elements that are not visible can still be read out and accessed by VoiceOver.

You can hide an HTML element from screen readers by setting the aria-hidden attribute to true. Likewise, setting the value to false will un-hide the element again.

document.querySelector('#panel').setAttribute('aria-hidden', 'true'); //not visible
document.querySelector('#panel').setAttribute('aria-hidden', 'false'); //visible

If you wish to visually hide the content as well, you can also take advantage of this attribute to set the element's display property in CSS like so.

#panel[aria-hidden="true"] { display: none; }
#panel[aria-hidden="false"] { display: block; }

Note here we are only changing the display property for the element #panel and not simply for every element that might have aria-hidden applied. There are situations where you might want content hidden from screen readers, but still visible on screen. Take for example, if your website creates a floating dialog box that is displayed on top of the existing page. In this case the content is still visible behind the dialog box, but should not be accessible until the user responds and the dialog box is closed. Here you might want to apply aria-hidden to the page behind, but not actually change the display property.

Making faux-buttons behave like buttons

While it is advisable to use a native HTML

Different ways to trigger touchcancel in mobile browsers

Fri, 23 Dec 2011 09:30:54 +0000

The touchcancel event is often neglected when building touch–interfaces using JavaScript. Historically, browsers vendors have never really published documentation detailing the circumstances as to when this event gets fired, and hence it has always been associated with a level of obscurity by many developers. The aim of this post is to try and shed some light on the matter.

Apple originally created touch events for iOS Safari, which have since been adopted as a basis for the W3C Touch Events Specification. The original Safari DOM Additions Reference documentation provides very little information on touchcancel:

Sent when the system cancels tracking for the touch.

Thankfully, the W3C Touch Events specification gives us a bit more detail, including some situations where the event should occur:

A user agent must dispatch this event type to indicate when a touch point has been disrupted in an implementation-specific manner, such as a synchronous event or action originating from the UA canceling the touch, or the touch point leaving the document window into a non-document area which is capable of handling user interactions. (e.g. The UA's native user interface, plug-ins) A user agent may also dispatch this event type when the user places more touch points on the touch surface than the device or implementation is configured to store, in which case the earliest Touch object in the TouchList should be removed.

From this description we can begin to understand touchcancel with regard to browser behaviour a little better. It not only helps the browser keep accurate references to active Touch objects in the TouchList, but it can also be used by developers to carry out UI specific tasks, such as reseting any variables used during touchstart or touchmove. In the event that the system cancels tracking and the touchend event does not fire, touchcancel saves the day.

But when do browsers actually trigger this event? To start investigating, it was necessary to build a simple event logger to track all touch events. This test features a touch-area and logs the last touch event fired, making it easier to see exactly what kind of interactions result in a touchcancel. Try it out in your browser and see how many ways you can manage to trigger the event.

What follows is a list of findings for various mobile web browsers. It is interesting to note that touchcancel is not very predictable, especially on Android (2.3.5). But even on iOS5 you cannot always correctly guess what will trigger a touchcancel.

iOS Safari 5.0.1 (iPhone 4 & iPad 1)

Actions that do trigger touchcancel during a touchstart or touchmove event:

User presses the home button.
User presses the action button in Safari's bottom toolbar.
User presses/smears the palm of their hand on the screen, creating no discernible single touch points (iPhone only?).
User presses the lock button.
User initiates a gesture using four or more simultaneous touch points on iPad and Multitasking Gestures are enabled in system preferences.

Actions that do not trigger touchcancel during a touchstart or touchmove event:

User presses the bookmark button in Safari's bottom toolbar.
User presses the back or forward history buttons in Safari's bottom toolbar.
User taps to focus on the Safari search bar.
User rotate's the device orientation.
Popup notification such as WiFi locator or Clock timer alert appears on screen.
New iOS5 style notification appears at top of the screen.
User opens a new tab (iPad).
User refreshes the page.
User presses the volume buttons.
User switches the device onto silent/vibrate.
User receives a phone call.

In some of these circumstances the browser will simply fire a touchend instead of touchcancel. In others situations (such as the old–style popup notifications), touchstart or touchmove will remain active (even while the content is hidden underneath the notification), until the user releases their finger, at which point touchend is fired.

Notable iOS5 system functions that will not activate during a touchstart or touchmove event:

User cannot focus on the Safari address bar.
User cannot open a new page (iPhone).
User cannot double–tap the home button to open the app tray.
User cannot swipe down from the top of screen to open notification centre.
User cannot tap on a new iOS5 style notification when it appears at the top of the screen.

Android 2.3.5 (Samsung Galaxy Y GT-S5363) stock browser

Actions that do trigger touchcancel during a touchstart or touchmove event:

User presses the lock button.
Appears to fire randomly for no immediately obvious reason. This is especially noticeable when performing repeated quick taps and swipes.

Actions that do not trigger touchcancel during a touchstart or touchmove event:

User presses the home button.
User rotate's the device orientation.
User presses the volume buttons.

Notable Android 2.3.5 system functions that will not activate during a touchstart or touchmove event:

User cannot press the menu or back buttons.
User cannot open notifications menu.
User cannot focus on the browser address bar.
User cannot tap the bookmarks button.

Opera Mobile 11.50 for Android was also tested. While the browser appears to have support for touchcancel, it does not actually seem to fire the event. In the case of pressing the home button for example, Opera Mobile appears to immediately fire touchend instead.

BlackBerry Playbook (1.0.8.6067)

Even though the browser reportedly supports the touchcancel event, it does not appear to get fired at all. Even when pressing the power button to put the device on standby, touchcancel is not fired. The same goes for pressing browser tool bar buttons, or focusing on the address bar. It is also worth noting that when performing a touchstart or touchmove, the Playbook does not respond to any bevel swipe gestures.

Conclusion

It is appears from the tests that touchcancel is still a bit unpredictable. While it is easy enough to identify situations where it gets fired, there are often near identical situations where it does not. While the usefulness of this event is by no means in question, it seems like developers cannot yet rely on this event getting fired in all expected circumstances.

What is clear though, is that you cannot rely on touchend getting fired on every device. You need to write code that deals with touchcancel. This is especially true on the iPad for example, say if you're building a multi–touch app or multi–player HTML5 game. Since there is no way of telling if the user has enabled Multitasking Gestures, your app needs to handle touchcancel gracefully. The unpredictable nature of Android browser also demonstrates the importance of dealing with this event, as failure to do so will likely cause bugs in your UI.

So, next time you're writing your own touch events, don't forget about touchcancel. Despite the varying levels of browser support, it still comes in very handy when dealing with certain unexpected user interactions.

Event delegation for touch events in JavaScript

Tue, 16 Aug 2011 21:02:51 +0100

Anyone who has experience developing web applications on mobile devices will have no doubt encountered the 300ms delay when firing click events in web browsers such as Mobile Safari. There are some useful standalone libraries and informative articles to help combat this delay, but this post aims to show a super–quick example of how to do simulated 'tap' events on dynamic content using JavaScript event delegation.

A common technique when dealing with click events in dynamic content is to use event delegation to capture events bubbling up through the DOM. This same technique can be applied to touch events, although it is a little more difficult since there are at least four different events to capture; touchstart, touchmove, touchend and touchcancel.

Here's a Gist containing a very basic example of how to capture a simulated 'tap' event:

var tapArea, moved, startX, startY;

tapArea = document.querySelector('#list'); //element to delegate
moved = false; //flags if the finger has moved
startX = 0; //starting x coordinate
startY = 0; //starting y coordinate

//touchstart			
tapArea.ontouchstart = function(e) {

	moved = false;
	startX = e.touches[0].clientX;
  	startY = e.touches[0].clientY;
};

//touchmove	
tapArea.ontouchmove = function(e) {

        //if finger moves more than 10px flag to cancel
        //code.google.com/mobile/articles/fast_buttons.html
	if (Math.abs(e.touches[0].clientX - startX) > 10 ||
      	Math.abs(e.touches[0].clientY - startY) > 10) {
    		moved = true;
  	}
};

//touchend
tapArea.ontouchend = function(e) {

	e.preventDefault();

        //get element from touch point
	var element = e.changedTouches[0].target;

        //if the element is a text node, get its parent.
	if (element.nodeType === 3) {	
		element = element.parentNode;
	}

	if (!moved) {
                //check for the element type you want to capture
		if (element.tagName.toLowerCase() === 'label') {
                        alert('tap');
                }
	}
};

//don't forget about touchcancel!
tapArea.ontouchcancel = function(e) {

        //reset variables
	moved = false;
	startX = 0;
  	startY = 0;
};

Notice here it is useful to make use of touchmove to detect any finger dragging gestures that might occur after a touchstart has fired. This way it is easy to cancel the 'tap' on touchend if desired.

Update: Originally this article was using the function document.elementFromPoint(x,y) to get the element target in ontouchend. A few people have kindly pointed out that you can actually just use e.changedTouches[0].target or even e.target to get the same result for a simple 'tap'. It should be noted however, that the target attribute in this case always refers to the originating element, so if you do need to reference the element a finger might have moved on/off during touchmove or touchend, you would still need to use:

document.elementFromPoint(e.changedTouches[0].clientX, e.changedTouches[0].clientY).

Any questions, comments or suggestions feel free to leave one on the Gist. Life would be so much easier if we had a native 'tap' event in mobile browsers!

Site redesign, a mobile first approach

Thu, 22 Sep 2011 11:30:17 +0100

Anyone who has visited this site over the last few weeks will no doubt have noticed a few changes. MiniApps has now had a complete design overhaul, which is probably long overdue given the current rise in interest of principals such as responsive web design and mobile first. What follows is a run down of basic changes to the site, in what hopefully makes for a much improved reading experience, in our rapidly changing, device-agnostic world.

Establishing a useful baseline

Rather than using a traditional CSS reset, MiniApps now uses normalize.css to establish a consistent baseline for cross-browser CSS rendering. Normalize.css makes web browsers render elements more consistently and in line with modern standards. It also preserves useful defaults and corrects common browser inconsistencies, unlike many CSS resets.

Mobile First

For a site where 62.46% of visitors in August to September 2011 were on mobile devices, this is real a no-brainer. Whilst the majority of mobile visitors to MiniApps are on more capable smart phone platforms such as iOS and Android (where a simple set of CSS Media Queries could suffice), given the continual rise in the number of people using mobile devices to access the world wide web, it still makes sense to design using a mobile first approach.

The MiniApps site now serves styling for browsers in the following order:

A default CSS style sheet suited to small–screen devices
CSS Media Queries then optimize content for larger screen sizes such as tablets, e–readers and desktop web browsers.
Note: since Internet Explorer 8 (and below) does not support CSS Media Queries, it is served a static set of CSS styles optimized for desktop, via a single conditional comment.
Update: IE Mobile is now set as version 7 in the conditional comment. This is because the new Mango update uses mobile IE 9 (thanks Paul Irish!).

/* Default CSS for mobile here -- */

/* Tablets (portrait) ----------- */
@media (min-width : 570px) and (max-width : 768px) {
	
}

/* Tablets landscape, and desktop */
@media (min-width : 769px) {

}

Responsive design

Whilst the new MiniApps design is quite minimal, using a single column design centered on readability and clear presentation of content - there are still some interesting pieces of responsiveness worth noting (other than the typical resizing of content to fit the browser window).

Content first, navigation second

Despite MiniApps already using a mobile first approach for CSS, more capable small–screen web browsers can benefit from a further layer of progressive enhancement, with the adoption of a content first, navigation second design pattern. Using the CSS3 Flexbox module, visitors on capable mobile web browsers will see the page header and main content first, followed by the navigation further down the page, but before the footer.

Here is a basic template for the site's structural HTML markup:

Nested inside an appropriate CSS Media Query, small–screen browsers are then be served a different ordering of page content, using the box-ordinal-group property.

/* Smartphones (portrait and landscape) ----------- */
@media (max-width : 569px) {

body {
        display: -webkit-box;
        display: -moz-box;
        display: box;
        -webkit-box-orient: vertical;
        -moz-box-orient: vertical;
        box-orient: vertical;
}
	
nav[role=navigation] {
        -webkit-box-ordinal-group: 4;
        -moz-box-ordinal-group: 4;
        box-ordinal-group: 4;
}

header[role=banner] {
        -webkit-box-ordinal-group: 1;
        -moz-box-ordinal-group: 1;
        box-ordinal-group: 1;
}

section[role=main] {
        -webkit-box-ordinal-group: 2;
        -moz-box-ordinal-group: 2;
        box-ordinal-group: 2;
}
	
aside[role=complementary] {
        -webkit-box-ordinal-group: 3;
        -moz-box-ordinal-group: 3;
        box-ordinal-group: 3;
}
	
footer[role=contentinfo] {
        -webkit-box-ordinal-group: 5;
        -moz-box-ordinal-group: 5;
        box-ordinal-group: 5;
}

}

This gets the user straight to the content they want to see, making much better use of valuable screen real–estate. Each page also features skip links, allowing for quick access to navigation and main content irrespective of the content order.

Note: for the subset of mobile browsers that support CSS Media Queries but do not yet support Flexbox (e.g. Opera Mobile/Mini), featured detection comes to the rescue courtesy of Modernizr. A few alternate CSS styling rules are all that is needed for the navigation and footer sections. Modernizr also provides the site's HTML5 shim that enables Internet Explorer to correctly style new sectioning elements.

QRCodes

Since this site often features web applications optimized for small–screen devices - desktop and tablet visitors are now served QRCodes, linking directly to mobile–specific content. These scannable barcodes act as super–fast links for any desktop visitor wishing to view content on a mobile device. Just looking at the stats from the last few weeks of use, people really do seem to be using them (110 scans between August 26 2011 - 22 September 2011). So they are now here to stay - no need to type in tricky URL's on small screens with even smaller keys.

Building a PlayBook WebWorks app

Mon, 03 Oct 2011 16:37:35 +0100

MiniApps was recently hired to develop the front–end HTML, CSS and JavaScript for a BlackBerry PlayBook application, packaged using RIM's WebWorks SDK. The main purpose of the app was to assist the user in consuming a large volume of digital content (in the form of text, images and video) via a streamlined, touch–friendly interface. Despite a reasonably small development window, the PlayBook browser and development tools proved to be very capable in getting the job done.

What follows is a run down of the key HTML5 features used in the application, and how well they performed on the device. Please note the code shown in this article is simplified in places for the sake of clarity, and is by no means complete.

Local database support

While an internet connection would be required to view online images and stream video via YouTube, one of the main technical requirements was that the app should still function and be navigable when offline. Incremental data returned via a remote server should be permanently stored on the device and always accessible. The maximum payload of data this app required was around 15 to 20MB, so the natural development choice was to use an HTML5 WebSQL Database, since the Playbook browser does not yet support IndexedDB, and the 5MB limit for localStorage was too small for the size of data required.

Implementation was quite straight forward, with the application creating a simple WebSQL database on first launch, together with a single table called 'appdata' to act as a main store.

var storage = {},
    myData = null,
    dbName = 'mydatabase',
    dbVersion = '1.0',
    dbDescription = 'app data store',
    dbSize = 20 * 1024 * 1024;

function handleDbError (e) {
	
	console.log(e.message);
	console.log(e.code);
}

function initDatabase () {
	
	try {
		var data = '';
						
		storage.db = openDatabase(dbName, dbVersion, dbDescription, dbSize);
		storage.db.transaction(function (tx) {
					
  			tx.executeSql("CREATE TABLE IF NOT EXISTS appdata (id unique, text)");
  						
		}, handleDbError);
  					
  		storage.db.transaction(function (tx) {
  					
  			tx.executeSql("INSERT OR IGNORE INTO appdata (id, text) VALUES(?,?)", [dbName, data]);
  					
  		}, handleDbError);
  									
    	} catch(e) {
    		handleDbError(e);
	}
}

initDatabase();

The application then makes a remote server call, and the JSON string returned as a response is then parsed and used immediately. At the same time, the data is saved asynchronously to the local database (in a single table row entry).

function getData () {
			
	var myRequest = new XMLHttpRequest();

	myRequest.onreadystatechange = function () {	

		if (myRequest.readyState === 4 && myRequest.status === 200) {
			myData = JSON.parse(myRequest.responseText);
			updateDatabase();
			startApp();			
		}
	};

	myRequest.open('GET', 'http://', true);
	myRequest.send();
}

function updateDatabase () {
	
	try {	
		var data = JSON.stringify(myData);
						
		storage.db = openDatabase(dbName, dbVersion, dbDescription, dbSize);		
  		storage.db.transaction(function (tx) {
  					
  			tx.executeSql("UPDATE appdata SET text=? WHERE id=?", [data, dbName]);
  					
  		}, handleDbError);
  									
    	} catch(e) {    			
    		handleDbError(e);
	}
}

If the app is later launched while offline, local data is then read back from the database and parsed back to an object, so the app only ever requires a single database read operation.

function throwReadError (e) {
	
	console.log(e.message);
	console.log(e.code);
			
	if(!myData) {
		showAlert("This app requires an internet connection for first launch");
	}
}
		
function readFromDatabase () {
				
	storage.db = openDatabase(dbName, dbVersion, dbDescription, dbSize);
	storage.db.transaction(function (tx) {
  				
		tx.executeSql('SELECT * FROM appdata', [], function (tx, results) {
  				
			myData = JSON.parse(results.rows.item(0).text);
			startApp();
		});

	}, throwReadError);		
}

The PlayBook coped with this size of data store very well. We never hit any bugs or performance issues. Updating the client data on subsequent app launches was also pretty trivial due to the very basic data store model. The PlayBook does not appear to ask the user for storage permission at any size of data we tested, although 50MB is likely the limit if other browsers are anything to go by.

Offline detection

For offline detection the app initially used navigator.Online, which at first appears to be supported by the PlayBook Browser.

var isOnline = window.navigator.onLine;

initDatabase();
				
if (isOnline) {
	getData();
				
} else {
	readFromDatabase();
}

However, once the first WebWorks build was made it became clear something was not right, since navigator.Online was always returning true on launch. This turns out to be an existing bug, but one that can be easily fixed using a WebWorks API call for offline detection:

var isOnline = 'blackberry' in window ? blackberry.system.hasDataCoverage() : window.navigator.onLine;

Notice here we use a simple feature detect using the blackberry window object, so we can carry on using navigator.Online in the browser (for development purposes).

CSS animation

While the PlayBook has very good support for CSS 2D and 3D Transforms and animations, it seems to struggle providing hardware acceleration. While RIM claims 3d transforms are hardware accelerated on the PlayBook, in real–world development we found that only the simplest examples managed anywhere near the smooth performance you come to expect on the iPad.

When building an app with a sizable DOM, the PlayBook seems to struggle when it comes to animating content. For example, if you display an element that has a CSS animation associated with it, the PlayBook seems to choke if it needs to render the element and then immediately animate it. Searching on the WebWorks support forums, there are many other developers experiencing similar issues. More odd quirks also exist, like hardware acceleration failing if the element uses CSS gradients.

For this reason, performing full–screen animations and transitions we're simply too much for the Playbook to pull off reliably. Only after lots of testing, setTimeout wrangling, tweaking and refining, we're we able to achieve some decent results.

Hopefully RIM can provide a future update that fixes current hardware acceleration issues, but as it stands this is currently the Playbook's only major weak point for WebWorks development.

Touch events

The app featured multiple sections where scrollable, dynamic touch–based carousels were needed. For this task iScroll4 came to the rescue, and proved to be very reliable on the PlayBook browser. Even zoom-able sections that needed multi–touch proved to be no problem for the device.

The only notable exception is that the PlayBook seems to support multi-touch in a slightly different way to how it works on iOS. For example, while you can perform a two–touch gesture on a single element on the PlayBook, you do not seem to be able to drag around two separate elements independently of each other. The Playbook appears to be limited in the number of simultaneous, independent touch–points it can support.

Native hooks

API wise, the app used 95% browser–based API's. The remaining areas where WebWorks had to step in were for small things, like opening external links in the PlayBook browser and providing native alert boxes.

function showAlert (message) {
	try {
		blackberry.ui.dialog.standardAskAsync(message, blackberry.ui.dialog.D_OK, {
			title : "Alert", 
			size: blackberry.ui.dialog.SIZE_MEDIUM, 
			position : blackberry.ui.dialog.CENTER
		});
	} catch (e) {
		alert(message);
		console.log(e);
	}
}

function launchBrowser (url) {
	var args = new blackberry.invoke.BrowserArguments(url);
	blackberry.invoke.invoke(blackberry.invoke.APP_BROWSER, args);
}

Remote debugging

This is the area really where the Playbook shines in the eyes of a web developer, as you can quickly and very easily remote debug on an actual device, over your local network. This saved many hours development time and bug fixing, especially when testing device related JavaScript events, such as orientation changes.

Hopefully one day we will have this kind of support on the other major mobile web browsers, and not need rely on third party solutions. RIM are really one step ahead of the competition here.

Conclusion

For web developers, building native applications using the WebWorks SDK is overall a very good experience. There is still room for improvement in key areas such as hardware acceleration performance, but otherwise the Playbook browser is a close second to iOS Safari in terms of browser features and support.

If only it was as easy for RIM to instill the same level of enthusiasm and confidence in tablet–buying consumers!

Make sure to use correct meta viewport syntax

Wed, 23 Nov 2011 09:46:21 +0000

When browsing the web it's not uncommon to come across two slight variations on the syntax for declaring meta viewport content values. It's a bit unclear how the two variations originated, but it should be noted that only one is correct, and using an incorrect syntax can actually create problems on certain web browsers.

This is the correct syntax:

This is the incorrect syntax:

Notice the correct syntax uses comma separated values. The incorrect way is to use a semi-colon separator. There is also no real need for the separator on the last value, user-scalable.

So, why does all of this really matter? “It doesn't seem to make a difference on my iPad?” Well, maybe not — but it can and does make a difference on other devices. The recent CSS Device Adaptation specification defines it, so real world implementations are now built toward the comma syntax style.

A real world example is the BlackBerry Playbook. It has a good web browser, but it's not very forgiving with error handling when parsing the meta viewport. If you use semi-colons instead of comma's, width can in some circumstances not get set to device-width. There is currently a bug in the PlayBook's viewport implementation that means width gets set to an arbitrary value if initial-scale is not also set to 1.0. If an error is thrown due to incorrect viewport syntax, initial-scale can be ignored and the whole page will appear enlarged, with over-sized text and blurry images. Not really what you intended, huh?

Safari and Chrome are currently the only web browsers that display a series of errors/warnings for an incorrect meta viewport declaration:

Viewport argument value "device-width;" for key "width" not recognized. Content ignored.
Viewport argument value "1.0;" for key "initial-scale" was truncated to its numeric prefix.
Viewport argument value "1.0;" for key "maximum-scale" was truncated to its numeric prefix.
Viewport argument value "0;" for key "user-scalable" was truncated to its numeric prefix.

It would be nice if more browsers did this. Maybe once @viewport becomes more widely adopted, we could then begin to phase out the messy meta viewport altogether?

So, the next time you are using meta viewport in a site — make sure you define it properly. Don't just cut and paste it from a old/bad example you found somewhere!

Please note, you should not necessarily be including all the different properties seen above in your declaration. This article is simply concentrating on how to define things correctly.

Update - for anyone wishing to use width=device-width without also setting initial-scale=1.0, the PlayBook can be tamed by inserting the legacy BlackBerry HandheldFriendly meta property before the viewport declaration:

MiniApps Blog

Multi touch gestures using Webkit

Serving iOS retina startup images for the new iPad

iOS startup images using CSS media queries

Caveat

Adaptive CSS layouts using Media Queries

Targeting iPhone 4 using CSS Media Queries

Pixel perfect icons for iOS devices using CSS Media Queries

WKTouch - Multi-touch JavaScript plugin for Apple iOS

iOS 4.2.1 brings some major new features to Mobile Safari

WKShake - 'Shake to Undo' JavaScript plugin for iOS Mobile Safari/Webkit

WKTouch and WKSlider now hardware accelerated in Mobile Webkit / Safari

New sizes attribute in iOS 4.2.1 for web clip icons

Using HTML5 localStorage as a fallback for offline form submission

WKSlider - A touch slider UI JavaScript plugin for Mobile Webkit

Tap.js - A lightweight 'tap' event JavaScript plugin

Setup

Tested browsers

Enable CSS active pseudo styles in Mobile Safari

Making web content more accessible with iOS VoiceOver

Navigating a web page using VoiceOver on iOS

Using WAI-ARIA landmark roles

Sub heading 1

Sub heading 2

Hiding and showing content

Making faux-buttons behave like buttons

Providing textual descriptions for icons

Final Note

Different ways to trigger touchcancel in mobile browsers

iOS Safari 5.0.1 (iPhone 4 & iPad 1)

Android 2.3.5 (Samsung Galaxy Y GT-S5363) stock browser

BlackBerry Playbook (1.0.8.6067)

Conclusion

Event delegation for touch events in JavaScript

Site redesign, a mobile first approach

Establishing a useful baseline

Mobile First

Responsive design

Content first, navigation second

QRCodes

Building a PlayBook WebWorks app

Local database support

Offline detection

CSS animation

Touch events

Native hooks

Remote debugging

Conclusion

Make sure to use correct meta viewport syntax