The Cabinet of Curiosities

Watch this space: JQuery Mobile

2011-05-19T10:29:00.009+01:00

JQuery Mobile is a web-based framework that can be used to create web-apps for all kinds of mobile devices. It provides an optimised experience for touch-based smart-phones and tablets, whilst still allowing older devices to access the content. It is supported by the JQuery community.

I've been tinkering with using the JQuery Mobile framework for a few months now. It is currently in an alpha phase but is already very feature rich and follows nice principles of progressive enhancement, and graceful degradation. In addition, I like how the framework uses WAI-ARIA attributes to attach styling and javascript to the DOM elements. This is one way to encourage developers to bake in accessibility from the minute they start writing their first line of HTML.

Other reasons why I like JQuery Mobile:

It's relatively quick and cheap to create a site that works on multiple mobile devices regardless of whether they have a particular OS (Android, iOS, Symbian, etc.), or a particular screen size (tablet, or small-large smart phone screen)...they just need a browser.
It helps create a great experience for smart-phone users with newer browsers, but degrades reasonably well for older phones and other devices with less feature-rich browsers (such as the Amazon Kindle browser).
It supports page transitions, touch gestures such as swipe-left, and various navigation aids out of the box, and allows you to customise these easily.
It is easy to learn and use because it uses well established web-technologies (HTML, CSS, JavaScript) that you already know or can learn easily from millions of books, blogs, and your peers.

Some considerations:

You can take a JQuery experience native using a framework like PhoneGap, but:

It is hard / impossible to get the exact native look and feel...you run the risk of falling into the 'uncanny-valley' of an experience that confuses the user by appearing to be native but not behaving quite as expected.
The above point, and the fact that Apple has deliberately tried to sabotage cross-platform development in the past means that you are more at risk from Apple's approval process than if you were writing in Objective-C.
JQuery Mobile is probably more suited to allowing a better experience for mobile browsing of content than it is to creating specific apps that use a lot of native features...some of these features can be accessed through PhoneGap, and some can't.
Similar to the point above, JQuery Mobile allows us to use the web as a platform rather than writing for each platform individually...you wouldn't create a desktop app for your website, but you might create a desktop app for a drawing program. So there are still going to be lots of situations where you need write a native app.
Remember your team, and support team's skillsets - perhaps they can support an Android device written in Java better than client-side technologies (then again, the opposite may true especially with Objective-C).

Accessibility Tools

2010-06-17T13:35:00.002+01:00

There are hundreds of accessibility tools available on the web. They can help with checks for:
- Required reading age for a piece of text (and suggestions for sentences to revise).
- How your site looks to users with color-blindness.
- Areas where contrast is too low for good readability.
- Indicating areas of the site that need manually checking for issues - such as only conveying information in pictoral form.
- Etc.

Here's a link to whet your appetite: 8 Tools to Analyze Your Website’s Level of Accessibility

UK mobile phone market share

2010-06-04T12:29:00.003+01:00

In mid May 2010, the UK mobile phone market is dominated by IPhones and Blackberries:

1) IPhones = 50%
2) Blackberries = 28% (RIM operating system)
3) Nokias (and some Samsungs) = 8% (Symbian operating system)

» Statcounter - UK mobile market

Source: StatCounter Global Stats - Mobile OS Market Share

2010 Browser Stats and Trends

2010-06-01T15:01:00.016+01:00

This article will cover:
1) Global browser statistics (Feb/May 2010 depending on source)
- Overview
- Changes in market share
2) How these statistics are collected (and who isn’t tracked)
3) What this means for your website development project, now, and in the future. Plus: should your project support IE6?

1) Current global browser statistics

Overview:

According to StatCounter:
Top browsers in May 2010:IE total = 53%
of which:
- IE8 = 27%
- IE7 = 16%
- IE6 = 10%
Firefox = 32%
Chrome = 8%
Safari = 4%
Opera = 2%

According to w3counter:
Top browsers in April 2010:
IE total = 49%
of which:
- IE8 = 25%
- IE7 = 13%
- IE6 = 8%
Firefox = 32%
Chrome = 7%
Safari = 6%
Opera = 2%

According to NetMarketShare:
Top browsers in April 2010:

Changes in market share:

IE losing out to Chrome’s meteoric rise:

From April 09 – May 2010 IE has lost a 10% market share 62% down to 52%. It looks like Chrome has been the main winner from this pocketing 6% extra market share over the same period. Firefox and Safari have eaten most of the remainder collectively increasing their market share by 3%.

IE users are upgrading:

The hidden chaos:

On the surface this makes browser support seem fairly simple. However, there is a lot more complexity when we start drilling down further into browser versions. Notice in the graph below how users take some time to upgrade their browser version when a new version is released:

Want to know more detail? Want to see different regions...e.g. United Kingdom stats? How about resolution sizes? What mobile phone browsers do people use, and on which operating systems? All that is available using the dropdowns below the graph at StatCounter:

2) How these statistics are collected (and who isn’t tracked)

Using StatCounter as an example, there are two parts to the way users are tracked:
1) Javascript tracking (sets up some global variables which are sent as part of an Ajax post to statcounter.com).
2) Image tracking (for users without javascript) – by loading a 1x1 pixel image from the StatCounter website using the id that you set up with them. StatCounter records these image requests server side and collates them. The user agent is known from the html header.

This means that users who have javascript and images turned off (e.g. text-only browsers) don’t get tracked. This is probably a very small proportion, but its still good to be aware of it.

Here's the StatCounter code

3) What this means for your website development project, now, and in the future.

First of all a warning: Don't use global stats to inform your site design if possible. It is far better to use *statistics specific to your site*. If you don’t have these, you can try looking at your target audience. For example, is your website primarily focused on the UK market? Then use statistics specific to users in the UK:

Or if it’s for the market in china then make sure it displays really well in IE6 (59% in May 2010. IE browsers account for 89% of the market share in China):

Currently:

On current client projects, I actively support, test on, and bug fix for the following browsers:

The modern browsers: Firefox, Safari, Chrome, IE8. These take minimal development effort and tend to cause less bugs.

Outdated browsers: IE6 and IE7. IE6 in particular can sap significant development effort and results in most of the visual bugs on a project. However IE7 can also take a fair amount of time to support as well. Some projects may have a business case for dropping support for IE6. And this will become more and more common as IE6 browser usage continues to dwindle (in the UK IE6 holds less than 4% market share).

Future projects:

A lot of future web projects will not need to support IE6 at all. Google and YouTube are dropping support for IE6 and it is becoming increasingly easy to make the business case for your website to do the same. IE9 will help encourage users to upgrade from IE7, so once IE6 support is phased out IE7 will be the next browser on developers’ hit list. IE7 is going to be around for some time yet though. Chrome will probably continue to gain market share globally. Its going to be a while before CSS3 is fully supported (for example IE8 doesn’t support border-radius – for rounded corners), and even longer until HTML5 is commonplace. However, internally facing websites may be able to take advantage of these new features by for example, only supporting browsers that have fully implemented certain useful CSS3 and HTML5 features in order to reduce development time.