The Setup

If you’ve read my earlier posts you’d know I’m working on the design for an iOS app, a companion for the website surftourist.com.

The website uses a font called Crete Rounded via Typekit, it’s become part of the Surftourist brand. Naturally I wanted to use the font in the app, and I purchased the Open Type version for €35, using it liberally.

You got a licence for that?

It occurred to me that the license I got with my purchase might not cover me for app use, so I tracked down the foundry, TypeTogether, and it turned out I was right.

On 11 Oct 2011 at 17:45, Veronika wrote:

Dear Craig,

thank you for your email.

The license you would need is a Limited Commercial Basic License, meaning that the fonts are embedded as static gifs (or similar). They are not used interactively, i.e. the user can’t type with the font within the app.

The license fee for this use is €900 per font and per application, valid for the life-time of the product.

Wait, what?

1. Using the font on a website via Typekit, 25,000 page views a month, free
2. Print, unlimited distribution, €35
3. iOS app, no interactive use, €900

How could you justify that? Apps sell at extremely tight margins. If I sold my app for a dollar, I would have to sell it about 1200 times just to break even on a font? I wrote another email, which subtly pointed out the pricing anomaly, noting that for €35 I could distribute it in its printed form to as big an audience as I pleased:

On 12 Oct 2011, at 08:46, Craig wrote:

Hi Veronika,

Just to clarify, if I don’t currently have a ‘Limited Commercial Basic License’, does the license I purchased with Crete for €35 allow me to use it in commercial print projects, or on slides in a public event presentation?

On 12 Oct 2011, at 17:19, Veronika wrote:

Hi Craig,

the Limited Commercial Basic License applies only to mobile, online apps. It refers to the actual font software being embedded within the product. You can use the print fonts to create any printed materials, embed in pdfs, use in a presentation and more. For more details please read our EULA: http://www.type-together.com/resources/eula/TT-EULA.pdf

Enter Mobile FontFonts

Coincidentally this happened just as Fontshop released Mobile FontFonts in October 2011. Fontshop’s communication was a little misleading – they seemed to be taking credit for making custom fonts available in iOS when it had been possible since iOS3 – but what’s great about these fonts is their price. For around $170 each, a team of up to 5 developers can use the font to their hearts content in as many apps as they want.

These two vast differences in pricing got me worked up, so I wrote another email.

On 11 Oct 2011, at 23:52, Craig wrote:

Hi Veronika,

Thanks for your quote of €900 per font per application.

FontShop International now offer 14 fonts which they claim are specifically designed for iOS. They’re priced at about $170 each.  http://www.mobilefontfonts.com/font/2346/usecases

I would prefer to use Crete, but due to this project’s budget it looks like I’ll be using Tisa instead.

I don’t want to sound flippant, I just want to alert you to the immense price difference. Licensing fonts for apps is still new territory for everyone.

On 13 Oct 2011, at 5:28, Veronika wrote:

Dear Craig,

we have priced our fonts in tune with market standards so far. I am sorry, but for now i can offer you only a 15% discount on the license fee.

Even with a 15% discount (€765) this font would have to be freaking amazing for me not to resort to a $170 alternative.

Mobile FontFonts have hopefully set the margin for font pricing. Unfortunately at the moment we’re only given 14 fonts to play with. All we can do is hope it’s a roaring success and other font foundries take note. Currently the app marketplace runs on low margin/high volume. While foundries continue to price high margin/low volume, the system won’t work.

Mobile FontFonts
http://www.fontshop.com/fontlist/applications/mobile_fonts

TypeTogether and Crete
http://www.type-together.com/crete 

Using custom fonts in iOS4
http://stackoverflow.com/questions/360751/can-i-embed-a-custom-font-in-an-iphone-application/3198821#3198821
http://blog.beefyapps.com/2010/06/custom-fonts-in-ios-4/

I’m missing my images

Images not loading in an email is sucky, especially when it’s an email you’ve designed. Top of mind is the one pictured below (not one of mine) which arrived in my inbox recently.

We have to assume that no matter what we do we’re going to have to live with the occasional missing image, which is why we should always avoid splitting images up into separate parts. This stops photographs of products being cut in half, and rasterized text becoming unreadable.

How big?

I decided to ask @campaignmonitor what their opinion was on acceptable file size was:

@craigrozynski Generally, we say keep the email as light as possible – image-heavy emails are slow-loading and can burden mobile users ^RH

Nothing we didn’t already know right? Is it possible that no one has done conclusive testing? How can we be this far down the evolutionary path of email design and still be this vague?

I don’t think I’ve ever built an email larger than 200kB, but what if I’ve been needlessly paranoid, compressing product shots down all this time?

It’s all well and good to say “Dude your email should be like, 20kB tops. Draw it with CSS or something”, but when you’re selling products based on their aesthetic value, a heavily compressed jpg is dumb.

What I want to know is – how big a file size can I get away with?

How many times?

But wait, there’s another factor that may play a part here. Do email clients have an aversion to how many http requests I make? Obviously a single 100kB image will load better than 100 1kB images, but I want to know – what are the margins I should be working within? If my EDM has over 20 images in it should I be worried that some won’t load?

To the laboratory!

Okay I don’t have a laboratory. In fact I kinda hoped that by raising the issue with Campaign Monitor they might carry the torch, but alas:

@craigrozynski I’ll let you know if anything comes across my desk, def one to think about here ^RH

They are certainly better equipped to produce meaningful results, but they’re all very busy people. So, what’s the best I can do to get the ball rolling?

The criteria

1. What is a safe file size limit for an email design?
2. Does the number of http requests have an impact on loading images?
3. How do they compare on different connections?

1. Image size test file

1.1 100kB image
1.2 200kB image
1.3 500kB image
1.4 1000kB image

2. Http requests test file

2.1 5 images totaling 200kB
2.2 10 images totaling 200kB
2.3 30 images totaling 200kB

3. Connection type

3.1 Standard cable connection (100mbps)
3.2 Mobile 3G
3.3 Mobile Wifi

I’ve only tested with one email client, Apple Mail for the standard cable connection, and iPhone iOS for mobile 3G and Wifi. Given that different email clients use different rendering engines, I can only assume results vary across email clients, but that’s a test for another day.

Results

Findings

Judging by these results we should have no qualms about sending out a 500kB email. A 1000kB email would perhaps test the patience of someone checking their email on the move. Still, it was only a matter of seconds.

The amount of http requests made had no real effect. The most images used was 30, although they were all the same image. I’m not certain whether Mail and iOS redraw the same image from cache or call it from the server 30 times. A better test would’ve been 30 individual images.

What bothers me is there’s no evidence here of why images occasionally, and intermittently, fail to load in an email? That mystery is yet to be solved.

What is it?

• A HTML5 fluid grid framework whose units remain square.
• Column widths increase or decrease to suit your display size using Media Queries.
• It’s Mobile First, CSS is written for small displays, with Media Queries incorporated as display size increases.
• It works on all modern desktop browsers, as well as iOS, Android and BlackBerry’s mobile WebKit browsers.
• Uses css3-mediaqueries.js to work in IE or any browser that supports JavaScript but not Media Queries.

Check it out here www.fluidsquares.com or download fluid-squares-v2.0.zip (24kb). Use it or modify it any way you wish.

The original version of Fluid Squares used transparent images with max-width:100% to make a box stay square in a fluid grid. Thanks to Marco Lago’s (@marcolago) clever update, transparent images are now history thanks to a few clever lines of CSS:

#unit {
  width:50%;
  padding-bottom:50%; 
}

Marco writes on his blog:

It is possible to make full CSS fluid squares without images hack or javascript workarounds? YES! Just think how paddings (and margins) works in the box-model definition. If the vertical paddings (and margins) are specified in percent (%) values the size is a percent of the width of the containing element. So if you write: width: 50%; height: 0; padding-bottom: 50%; you get a fluid square box with only a three row CSS declaration.

The ingredients

HTML

The basic structure of each unit is a div for content, which is nested in an anchor element:

<a href="url">
  <div>content</div>
</a>

If you don’t want the entire unit to be a link, a class has been created for that purpose. Just add class=”category” to the div and remove the anchor element.

CSS

Media Queries control the number of columns displayed (1, 2, 3, and 4) on browser resize, as well as providing fine control over font sizes.

As far as support goes, Safari 3+, Chrome, Firefox 3.5+, Opera 7+, and IE9 all natively parse Media Queries, as do more recent mobile browsers such as Opera Mobile and all those that run on mobile WebKit. For older browsers and IE less than 9, Version 2 of Fluid Squares uses css3-mediaqueries.js, which makes any browser that supports JavaScript interpret Media Queries.

I’ve also cut down a css reset to bare basics to suit this bare bones grid, customise this to suit your needs.

iOS Safari bug fix

A bug in iOS Safari causes text to run off the screen when switching from portrait to landscape orientation. A JavaScript Safari zoom bug fix fixes this, but I’ve used the non-JavaScript alternative, which is to disable user zooming: <meta name = “viewport” content = “width=device-width, maximum-scale=1“>. Preventing zooming generally isn’t a nice thing to do to a user, but because Fluid Squares uses Media Queries to tailor the layout and font sizes for the mobile device this isn’t a problem. If you wish to support mobile browsers that don’t run on mobile WebKit, use the JavaScript fix instead.

No shiv?

While it’s HMTL5, a shiv isn’t required because it doesn’t use any of the new HTML5 elements. If you want to user <header>, <nav> etc include a shiv. Browsers that don’t natively support new HTML5 elements will then treat them as blocks and allow styling. Consider Remy’s Shiv and Modernizr.

No wrapper?

It uses the body tag as a wrapper, but would certainly work within a standard div wrapper or new HTML5 block elements.

Icons

ico and webclip files are included in the directory. Frustratingly I could not get my Android emulator to display a Web Clip icon when saving a bookmark to the home screen, so removed the apple-touch-icon link rel tag from the head. Matthias Byens has written a thorough article, ‘Everything you always wanted to know about touch icons’, on a subject that is much more convoluted than it should be.

Keeping in touch with the team online

I’d recommend using Campfire with Propane for online team communication, although on this project we’ve been using Skype — out of laziness perhaps — but as we’re building it for ourselves it’s a bit more of a casual arrangement. If you are using Skype with multiple users be careful – it doesn’t save the contents of a chat between more that two people. Yes, I did find that out the hard way.

Remembering everything

Ideas and key points from conversations get pasted into Evernote. I’ve tried Yojimbo and Together – digital scrapbooks – but settled on Evernote because it’s development cycle seems to be the most active. If you’d like to try an alternative check out Together. I also recommend Yojimbo vs Together vs Evernote: a review.

Information Architecture: Sketches

The features and direction weren’t defined well enough to jump straight into wireframing, so I sought feedback from sketches first. The sketches were rough enough not to waste time but clear enough to get the ideas across.

For the novelty of it, and a little added convenience, I sketched on an iPhone App Sketchbook from appsketchbook.com. On standard delivery it arrived in two weeks – far too long. If you’re not in the States get it sent express.

Also check out UI Stencils’ stencils and notepads. UI Stencils iPhone Sketch Pad doesn’t provide enough room for adding comments and notes to screens for me, but they have got great products including a dry erase board with browser chrome, a really great idea.

Information Architecture: Wireframes

The sketches triggered discussion. Once there was general agreement I produced a new round of rough sketches for my own use that covered every screen of the revised app.

The approach I’m taking to the user experience on this project is more casual than what you’d find at a UX studio, which would be defining personas, scenarios and user testing in a more scientific, methodical way. If you’re interested in those processes there’s plenty of fantastic resources online waiting to appear in a results listing. See No excuses – budget usability testing for a start.

Until this project I’ve used Indesign for creating IA documentation — very much a designer’s approach. Professionals advocate Axure, but I was hoping to find something that was more mobile app aware. See The search for the perfect IA application if you want to read a little about Balsamiq, Omnigraffle and some of the other available options. The tool that best suited what I was looking for was FlairBuilder.

The most attractive feature of Flairbuilder is the ability to push a working prototype online with the click of a button. This was a major plus not least of all because our team is spread across Australia, Scotland and Japan. Another great feature is a component library that includes mock iPhone UI elements and device artwork.

Flairbuilder runs on Adobe AIR. Despite some fiddly bugs, which were noted and sent to the developer (who has promised they’ll be ironed out in the next release – thanks Christian!), the app was intuitive enough that I had a 40 screen iPhone IA/prototype with site map built in two days.

Not only could I create a working (clickable if you like) prototype, the ability to add interactivity meant that I was able to create user scenario paths that the other team members could click through. The team could forget about navigating the IA and focus on experiencing how users would complete specific tasks.

I love crafting user experiences, and writing front-end code too for that matter, but what people know me for is interface design. Looking ahead to commercial projects I’d like to partner with a UX team. If you have any recommendations leave a comment or dm me.

Thanks for reading. The next article will focus on interface design. Do you build apps and have suggestions for a mobile workflow? What’s your advice?

Extensis, the outfit known for its font management software Suitcase/Fusion, launched a web font service called WebInk in August 2010.

After a quick snoop around WebInk’s website the two main differences when compared to Typekit are JavaScript not being required to run, and pricing structure.

If you’re a Typekit user like me you’ve been adding two script tags to every page that uses web fonts. Not particularly efficient. WebInk simply uses the @font-face rule in your CSS to load fonts from their server, like this:

@font-face {
font-family: Grotesque;
src: url('http://fnt.webink.com/wfs/?drawer=SSDFR111-0000…&font=ANRVDHQ-VFDSN…');
}

BUT, (that’s a big but btw) one of the benefits of Typekit’s script is that it hides the Flash Of Unstyled Text (FOUT) by concealing the text until it’s ready to display styled. Ironically WebInk provides a script called FOUT-b-gone via its blog to fix this, so technically their “No JavaScript” claim is BS. The problematic browsers in question are IE 7-9 and FF 3.5 and 3.6. Other modern browsers have already pulled into line, so eventually FOUT will be a thing of the past, the script can be deleted and we can all forget it ever happened.

The next main difference is pricing. Typekit charges an annual fee, WebInk is monthly. Typekit calculates bandwidth based on page views, Webink on the actual amount of bandwidth that’s been used serving the fonts (at least that’s how they distinguish it in their plans).

WebInk’s pricing plans:

If you’re hosting a personal site that’s getting less than 5000 visitors a months, Webink would be the marginally cheaper option at $23.88 to Typekit’s $24.99. Negligible. WebInk’s monthly pricing means if your bandwidth varies wildly from month to month your fee will too – check your credit card statements. Typekit state on their pricing page if your bandwidth is exceeded they’ll contact you to recommend a different plan. It does give the impression that WebInk’s fee is more prone to fluctuation.

Typekit’s pricing plans:

Obviously other factors such as font libraries and their browsing experience, and account management also needs to be taken into account. WebInk isn’t ground breakingly different enough to Typekit for me to switch my existing sites over. I’m keen to give it a go on a future project to fully understand the subtle differences.

Personally I also prefer Typekit’s website to WebInk’s (seriously guys, Futura?). Any product or service whose customer base are designers can’t afford not to be obsessive over their aesthetic presentation, and I find the WebInk site a little gloomy. Was using Futura a conceptual statement? It’s a classic typeface but it just doesn’t work for me in this context. (Jim Kidwell from Extensis points out that the fonts used are Proxima Nova and Foco, my bad.)

Typekit.com and WebInk.com

I’m turning a website for traveling surfers, www.surftourist.com, into an iOS app. It’s the first time I’ve designed for iOS, and I’m building my workflow – setting up shop – for future projects.

Step 1: Read the instructions

It took a couple of afternoons to read Apple’s iOS Human Interface Guidelines. I got a bit carried away taking notes and ended up publishing a seven part article, which reformatted the guidelines specifically for designers. It’s been getting roughly 100 hits a day, and is the second result after Apple on Google for iOS Human Interface Guidelines. If you’re reading the HIG, check it out.

Step 2: App Def

Create an App Definition Statement. Challenge yourself to make it as short as possible.

We wanted our app to:

• Let surfers search for surf spots.
• Create and maintain a surf trip itinerary.
• Share their trip progress and surf spot discoveries.
• Give surfers the ability to record their regular day to day surfs.

If that sounds like a lot for a mobile app, you’re probably right. Regardless of it being ambitious or crazy, I managed to whittle it down to the following App Definition:

Plan your surf trips. Share your surfs.

Step 3: Feature List

1. Plan your surf trips
- Search surf spots via either map or country
- Collect spots into trips, check in to those spots during a trip

2. Share your surfs
- Share your regular surfs and trip surfs with comments, ratings and photos

For the purpose of this article that should do. I continued to break the features down into finer detail, turning features into functions, separating functions into groups, and began sketching a basic Information Architecture.

Next: iOS App Design Workflow: Part 2. See what tools I used to create the Surftourist Information Architecture.

Update: This version of Fluid Squares has been superseded by version 2. The original version documented below used transparent images with max-width:100% to make a box stay square in a fluid grid. Thanks to Marco Lago’s clever update, transparent images are now history thanks to a few clever lines of CSS.

Fluid Squares is an HTML5 fluid grid with square units, whose layout switches from four to three to two to one columns depending on browser width. It works on the desktop, iOS, Android and BlackBerry’s mobile WebKit browsers. Check it out here www.fluidsquares.com or download here fluid-squares-v1.0.zip (20kb). fluid-squares-v2.o.zip. Feel free to use it, modify it any way you wish.

Boxes that stay square in a fluid grid

Without a fix, the result of reducing a browser window’s width squashes a fluid grid’s squares into rectangles:

To fix this:

1. A square transparent placeholder image is used in each unit.
2. The image’s max-width is set to 100%.
3. The image’s actual size must match the size of the largest instance you intend to display a grid unit.
4. Content is laid over the top of each image using an absolutely positioned div.

I can’t take the credit for this idea – see the ‘OUR WORK’ text box on electricpulp.com – but as far as I can Google the method hasn’t been published before.

The ingredients

HTML The basic structure of each unit is a placeholder img and a div for content, nested in an anchor element:

<a href="url">
  <img src="img/solid.png" alt="">
  <div>content</div>
</a>

If you don’t want the entire unit to be a link, see the .category div style. While I’ve used text, the grid unit could simply be an image, in which case the content div would be removed and placeholder image substituted with the image you wish to use. CSS Media queries control the number of columns displayed (4, 3, 2, and 1) on browser resize, with additional media queries providing fine control over font sizes, plus two media queries for mobile devices both portrait and landscape. Values for the mobile devices’ max-device-width were taken from Shichuan’s MBP. Which browsers support media queries? Safari 3+, Chrome, Firefox 3.5+, Opera 7+, and IE9 all natively parse media queries, as do more recent mobile browsers such as Opera Mobile and mobile WebKit. Older versions, notably IE, don’t support media queries. I’ve cut down a css reset to bare basics to suit this bare bones grid. Media queries and column widths have been commented. Older browsers IE 8 and below, which don’t support media queries, get the standard 990px four column version via a conditional stylesheet. It is possible to force non-supportive browsers to work with media queries using css3-medaqueries.js. iOS Safari bug fix A bug in iOS Safari causes text to run off the screen when switching from portrait to landscape orientation. A JavaScript Safari zoom bug fix fixes this, but I’ve used the non-JavaScript alternative, which is to disable user zooming: <meta name = “viewport” content = “width=device-width, maximum-scale=1“>. Preventing zooming generally isn’t a nice thing to do to a user, but as media queries tailor the layout and font sizes for the mobile device this isn’t a problem. If you wish to support mobile browsers that don’t mobile WebKit, use the JavaScript fix instead. No shiv? While it’s HMTL5, a shiv isn’t required because it doesn’t use any of the new HTML5 elements. If you want to user <header>, <nav> etc include a shiv. Browsers that don’t natively support new HTML5 elements will then treat them as blocks and allow styling. Consider Remy’s Shiv and Modernizr. No wrapper? It uses the body tag as a wrapper, but would certainly work within a standard div wrapper or HTML5 new block elements. Icons ico and webclip files are included in the directory. Frustratingly I could not get my Android emulator to display a Web Clip icon when saving a bookmark to the home screen, so removed the apple-touch-icon link rel tag from the head. Matthias Byens has written a thorough article, ‘Everything you always wanted to know about touch icons’, on a subject that is much more convoluted than it should be.

Testing on mobile emulators

For those of us not lucky enough to own a pile of mobile devices to test on, we have emulators. If you’re on a Mac like me, you’ll need VMWare or Parallels to run the majority of them. You’ll need to be running Vista or Windows 7 for the Windows Phone 7 emulator, though note that WP7 browser doesn’t currently support media queries.

• BlackBerry device simulators (tested)
• iOS Safari iPhone emulator via xCode (tested)
• iOS iPad emulator (tested)
• Android emulator (tested)
• Windows Phone 7 emulator and WP7 Dev Center
• Palm Pre emulator
• Opera Mini browser (browser based emulator that works in Safari, not Chrome for me)
• Nokia Symbian SDKs

Note that there is a browser-based iPhone emulator but I found it produced subtly different results to the actual device.

Thoughts

I have to leave Fluid Squares alone for now but it’s far from perfect. For instance the IE conditional stylesheet could easily be modified from serving a fixed layout to a fluid one. A grid of images which dim to show text on hover would be fantastic. If you’ve got any suggestions or improvements, speak up.

That was over a year ago now. Life’s been challenging, but good. The one thing that rode me was eventually I was going to have to make a buck again, and the thought of going back to digital felt like dry toast.

I reluctantly returned to the knowledge web, and started reading. Turns out I had a hell of a lot of catching up to do. The smartphone was doing to the desktop web what the web had done to print 15 years ago. It was fresh again, and before I knew it I was hooked. I’d been saved by the mobile web.

I decided to write this article following Andy Clarke’s (@Malarkey) release of 320 and Up this week, and thought it was a nice milestone to take stock. Paul Irish, Divya Manian and Shi Chuan created the Mobile Boilerplate (based on their HTML5 Boilerplate) to accumulate everything we’ve learned till now about designing for the mobile web. Andy’s 320 and Up is very much a Mobile First Boilerplate, and takes a slightly different approach. Let’s take a step back and look at some of the milestones that have led to this point.

Rethinking the Mobile Web

Bryan Rieger (@bryanrieger) from Yiibu reflects that due to the fragmentation of devices and device specs, web developers tend to focus on the iPhone. This is unfortunate, considering the iPhone has a very small piece of the smartphone market. The Rethinking the Mobile Web slideshow is a great piece of work, and the related article is a nice lead in. Here’s some of the things I took away from it:

• 6.8 billion people in the world today,
  1.8 billion with internet connections,
  3.4 billion with mobile devices.
• iPhone has less than 4% global market share.
• Responsive websites work beautifully on the iPhone and Android, but not so on almost every other mobile device.
• The absence of support for media queries is in fact the first media query you should be making.
• Progressively enhance using JavaScript and media queries.
• Adapt content (especially images) appropriately for each device.
• Compress content where possible, and don’t include unnecessary data.

Media queries work great on iPhone and Android, but are only a very small piece of the mobile web. Therefore:

A desktop site + media queries does not equal a mobile website

Thanks to modern desktop browser support for media queries, and the ability to retrofit less supportive desktop browsers with fallbacks, the correct equation is:

Mobile site + media queries = desktop site

And that’s the formula Andy Clarke’s 320 and Up is based on.

Bryan notes that the concept of designing for the lowest common denominator and working up to the desktop goes way back to 2003, with progressive enhancement.

Responsive design! One web! We’re saved!

When I took notice of how CSS3 media queries could shape a desktop site for mobile, particularly thanks to Ethan Marcotte’s Responsive Web Design article on A List Apart, I wondered whether building a separate .mobi or m. website for mobile users was a waste of time. It isn’t, as shown in Rethinking the Mobile Web and expanded on in Jason Grigsby’s article below. You can read more about the One Web idea at New to Mobile? Welcome to the One Web Debate.

No! No! No we’re not! Keep panicking!

Unfortunately CSS media queries just aren’t well supported on mobile today, but that’s not the half of it. Cue Jason Grigsby’s CSS Media Queries is Fools Gold. Jason’s assumption is that speed matters more on mobile:

• Letting the browser scale images is a bad idea
• Using media queries to deliver different images doesn’t work
• Media queries do not optimise HTML or JavaScript
• Media queries aren’t supported well
• The mobile context is ignored

Trying to address these problems, do media query polyfills like respond.js, and responsive image solutions go far enough?

Mobile First

You’d be forgiven for thinking that when the web and smartphones first met, Luke Wroblewski (@lukew) slid out in a fetal position and rose to spread the word. Luke travels the globe evangelising the mobile web and we have him to thank for the concept of Mobile First. He argues that designing for mobile is a discipline that forces design teams to include only the most important aspects of their product, which equates to better user experiences. The salient points in his Mobile First presentation are:

• Smartphone sales will outpace PC sales by the end of 2011.
• Mobile forces you to focus.
• Mobile gives us locative, context-aware capabilities.

Here’s the Mobile First article with links to audio and video of the presentation. I personally found the Mobile First presentation slides (PDF) to be most useful.

Boilerplates

In 2011 version 1.0 of Paul Irish and gang’s Mobile Boilerplate was released. Andy Clarke’s release of 320 and Up has left me scratching my head whether the Mobile Boilerplate is now redundant, or whether I need to roll up my sleeves and bastardise the two of them to create something I’m satisfied with. On the other hand it is still very much reliant on CSS media queries and the One Web concept, which up to this point at least has been far from perfect too. Pulling the two boilerplates apart and putting them into practice will be great fodder for the next article.

• jQTouch
• jQuery Mobile
• PhoneGap
• Sencha Touch
• Titanium

These broadly fall into two categories:

1. Web development frameworks
   Develop in HTML/CSS/JavaScript.
   jQTouch, jQuery Mobile, PhoneGap.
2. Custom API frameworks
   Develop in JavaScript and the framework’s custom API.
   Sencha Touch, Titanium.

Web development frameworks

Web development frameworks are perfect for creating simple mobile apps quickly.

jQTouch

jQTouch was created in 2009 by David Kaneda. It’s now being run by Jonathan Stark. Jonathan’s outlined a roadmap for the library’s future on the jQTouch blog. It has a dependency on the JQuery library (you’ll need both jQuery and jQTouch), and is solely for the iPhone and iPod Touch’s web browser (not iPad’s). David hints support is coming for Android and Palm Pre’s webOS WebKit browsers, but as of March 2011 that hasn’t materialised.

Nativeness
UI controls look iOS-ish, but are undeniably jQTouch UI controls. Supports gestures, animations and transitions.

Cross-browser support
None. iPhone and iPod Touch only.
Updated 29 March 2011: JQTouch is getting close to supporting Android. Michael Mullany, comment #2.
Updated 11 April 2011: You can download the Android-supported version of JQTouch on GitHub now: https://github.com/senchalabs/jQTouch jqtouch.com’s download link will be updated shortly.

Performance
Okay. It’s dependent on the jQuery library, a library built with the desktop browser in mind, and some question its efficiency. Some complain that animations aren’t smooth enough, although this is a complaint of web apps in general.

Ease of development
Probably the easiest way to build an iPhone app. Work directly with HTML, CSS and jQuery. If you’re developing something complex, you may find it limited.

Accessible device hardware
None. Possible by moving your project into the PhoneGap framework.

Price of admission
Open and free under an MIT license.

jQuery Mobile

jQuery Mobile, developed by jQuery, was announced mid 2010 and is still in its early stages (Alpha C released February 2011). It’s very easy to use, and supports more platforms than any other framework by a mile.

Nativeness
Not very. jQuery Mobile aims to look consistent regardless of platform. UI controls are themeable with ThemeRoller, but you won’t be able to create a proper native experience. Supports gestures, animations and transitions.

Cross-browser support
The best available. jQuery Mobile supports Android, bada, BlackBerry, iOS, MeeGo, Symbian, webOS, and Windows Phone. What you sacrifice in native experience you gain in coverage.

Performance
Average. Apps created with web app frameworks don’t perform as well as those created with custom API frameworks. Dave Feldman’s tests indicated Sencha Touch (custom API framework) performed noticeably better and more reliably than either jQTouch or jQuery Mobile, with the exception of initial load time.

Ease of development
The easiest after jQTouch. Work directly with HTML, CSS and jQuery. If you’re developing something complex, you may find it limited.

Accessible device hardware
None. Possible by moving your project into the PhoneGap framework.

Price of admission
Open and free under an MIT and GPL license.

PhoneGap

It’s currently the preferred way for wrapping jQTouch, jQuery Mobile and Sencha Touch web apps natively so they can be sold in app stores. It’s not just a wrapper though – you can create web apps from scratch in this framework writing HTML/CSS/JavaScript. PhoneGap allows you to access some device hardware features too, an advantage it has over jQTouch, jQuery Mobile and Sencha Touch.

Nativeness
PhoneGap’s API doesn’t let you access native UI elements like Titanium does, although plugins are available. It does provide (limited) access to a device’s hardware, unlike jQTouch and jQuery Mobile.

Cross-browser support
Very good. Android, BlackBerry, iOS, Symbian and webOS.

Performance
Average. Despite being wrapped native, web apps still perform like web apps. You’ll find better performance with Titanium.

Ease of development
Good. If you’re a web developer you’ll be comfortable working directly with HTML, CSS and JavaScript.

Accessible device hardware
GPS, Vibration, Camera, Microphone, (plus Accelerometer and Compass on some devices).

Price of admission
PhoneGap is free for all while in beta, and will remain that way always for open source projects.

Custom API Frameworks

Custom API frameworks are more powerful than web development frameworks. They claim to allow you to write once for multiple platforms, but in reality it’s not that simple. See here (search iPhone Android dual targeting) and here for examples showing there’s no such thing as a silver bullet.

Sencha Touch

Overview
David Kaneda handed over maintenance of jQTouch to Jonathan Stark so he could focus on Sencha Touch. Sencha Touch is geared more towards software developers than web developers, with a pure JavaScript API.

Sencha Touch’s custom API framework offers more power and flexibility than web dev frameworks like jQuery Mobile or PhoneGap. A popular approach is to build an app with Sencha, then wrap it as a native app with PhoneGap.

Nativeness
Better than jQTouch or jQuery Mobile, but if you want your app to look native, it’s unlikely you’ll fool anyone.

Cross-browser support
Android, iOS, and BlackBerry (from Sencha 1.1).
Updated 29 March 2011: Intention to support Meego and IE9 mobile for Nokia once phones ship with them. Michael Mullany, comment #2.

Performance
Better than jQTouch and jQuery Mobile, not as good as Titanium.

Ease of development
Steep learning curve. You’ll be working with Sencha’s API and JavaScript, with little to no HTML/CSS. Dave Feldman says the framework feels huge compared to jQuery Mobile, and while the documentation is extensive there are “odd holes”. See Dave’s article Comparing Mobile Web Frameworks from February 2011.

Accessible device hardware
Apparently none, but PhoneGap could be used as a bridge to access device hardware.

Price of admission
The commercial license for Sencha Touch is free. A paid support option is also offered for US$300 per annum.

Titanium

Since its 1.0 release, Titanium shifted from producing apps that were native-wrapped web views (like PhoneGap’s), to being more natively integrated. Titanium’s JavaScript API acts as a bridge between you and the platform’s API, resulting in apps that perform better and feel more native. Incidentally you can also use Titanium to deploy desktop apps too (Windows/Mac/Linux).

Nativeness
Good. More than any other framework it comes closest to providing a native experience. Titanium has a comprehensive UI API that can control all kinds of native UI controls.

Cross-browser support
Weak. Limited to iOS (including iPad) and Android for now. BlackBerry may be in the works. A single development environment for both platforms, but getting your app working on both requires work, and can be a headache.

Performance
As good as it gets without being native. Dave Feldman writes his app’s performance under Titanium blew away the web app frameworks in comparison.

Ease of development
Steep learning curve. High proficiency in JavaScript and willingness to learn Titanium’s API required. Lack of ability to debug properly is cited as a problem.

Accessible device hardware
GPS, Vibration, Accelerometer, Compass, Camera, Microphone.

Price of admission
The fully supported Titanium option costs US $199 a month per developer.

There’s also a Ruby-based framework, Rhodes

If you’re into Ruby, you may want to consider Rhodes. See Mauro Dalu’s article on Titanium versus Rhodes.

Conclusion

As it stands today, no framework is clearly better than its competition, and we’re left to weigh up which one is best on a project by project basis. If your JavaScript proficiency is basic your options are limited to jQTouch, jQuery Mobile and PhoneGap. If your JavaScript proficiency is high, Sencha Touch, Titanium and other custom JavaScript API frameworks allow you to build powerful apps that come close to the performance and feel of native apps. Titanium’s ability to deploy apps natively, performance and access to device hardware make it a stronger option that Sencha Touch, but its lack of device coverage and reported clunkyness in writing once for iOS and Android would make me seriously consider outsourcing native development as an alternative.

Emulating a native experience
Best: Titanium
Worst: jQuery Mobile

Device support
Best: jQuery Mobile
Worst: jQTouch and Titanium

Flexibility and power
Best: Titanium
Worst: jQTouch and jQuery Mobile

Futher reading

This article was written from the perspective of someone setting out to create a mobile app and trying to make sense of the various approaches to doing it. There was no comprehensive comparison online for hands-on experience with frameworks that I could find, which is why I wrote this. I’ve done the best I could to make sure information is accurate, but for the benefit of others who will read this article, please let me know if any information is incorrect. All sources are listed below:

jQTouch blog
jQuery Mobile blog
jQuery Mobile’s Strategy
JQuery Mobile Framework Announced on Hacker News.
Sencha Touch blog
jQTouch and Sencha Touch: Which is right for you? by David Kaneda
Appcelerator Titanium
PhoneGap blog
Rhodes blog
Comparison between Corona, PhoneGap and Titanium at Stack Overflow.
For specific information on PhoneGap vs Titanium in the link above, search Now, are they any different?
iWebKit vs jQTouch vs iUI at Stack Overflow.
Comparing Mobile Web Frameworks by Dave Feldman.
Titanium versus Rhodes by Mauro Dalu.
Comparing the difference between JavaScript libraries and frameworks at Quora.
Mobile Developer’s Guide 7th edition at enough.de

I was blown away when first introduced to CSS media queries and Responsive Web Design in Ethan Marcotte’s ALA article.

It’s been equally enlightening to read a counter-argument against media queries and Fluid Images in CSS Media Query for Mobile is Fool’s Gold by Jason Grigsby.

Jason claims a one shoe fits all approach is lousy, and it’s difficult to argue with his logic. Using CSS media queries and Fluid Images can compromise an efficient, snappy experience for mobile users. Not to mention it can cost them more.

The Fluid Images technique deliver images at the maximum size they will be used, and by omitting width and height values lets the browser resize them for you. The obvious problem with this is that serving large images used at a fraction of their size is as dumb and inefficient on mobile browsers as it was on desktop browsers.

But what if I’m using media queries and the visibility property to hide the images, I’m cool right?

Not quite. Jason’s tests with iPhone/iOS browser show that despite setting display to none iOS will still download the images. You can’t blame the browser for doing this – an event could switch an image’s visibility at any time and the browser wants that image to be ready to go, not flicker into existence.

However, Trygve Lie comments (9) that Opera Mini and Mobile do not load an image whose visibility is set to hidden. It’s not stated which way Android or webOS swing, but until proven otherwise assume the worst.

Similarly, CSS media queries don’t optimise HTML or Javascript. Despite hiding a div containing fancy functionality for the desktop version of your site, it won’t prevent the mobile browser from loading the scripts it relies on.

These considerations don’t write off CSS media queries altogether, just don’t use them at the expense of the mobile user. They were the reason we started using them in the first place.