Here's your last chance to attend a native iOS workshop by me in the UK. Come to Brighton on November 23-25 to join me for three days of hands-on hacking as you learn the foundations of Objective-C, Cocoa Touch, and Xcode. We'll be covering iOS5 and Xcode 4.2 (the latest versions).

Tickets are commemoratively priced at £666.66 + VAT. Places are limited.

Do tell your friends :)

For more information, see the Native iOS Development Dojo web site.

All photos by Victoria Dawe Photography.

In my post yesterday, I outlined how to present high-resolution images in web pages using CSS media queries to users using a high-PPI screen such the iPhone 4's new Retina display. I also mentioned that while this works for background images in CSS, the only solution currently for carrying out this same substitution for images linked to using the <img> tag is to use JavaScript. Finally, I suggested that browsers should natively support substituting high-resolution versions of images when they detect that the user is using a high-PPI display. In this post, I'd like to formalize that suggestion a bit.

Proposal for native browser support of high-resolution image substitution

Authoring web sites to use resolution independent images that display beautifully on high-resolution displays should be made as easy as possible for developers and should not require JavaScript to accomplish.

To accomplish this, I propose a new HTML Meta Tag, resolutions, that can be used to specify that high-resolution versions of images linked to from the page are available and that the browser should use them in place of the lower-resolution default images if it detects that a user is using a high-resolution screen. The resolutions meta tag lists the device-pixel ratios supported by images in the page.

So, for example…

<meta name="resolutions" content="2x"

… means that the developer is telling the browser that she has created 2x resolution images for the images linked to from the current page and named them with a @2x suffix.

To illustrate, if her image tag is as follows…

<img src="/images/flower.jpg" alt="A flower">

… then she has two image files under /images: the low-resolution default (flower.jpg), and a higher-resolution (200%) version named flower@2x.jpg.

(This is the same naming convention already used by Apple in its Cocoa Touch framework for automatically loading in higher-resolution versions of images.)

Based on the meta tag, if the browser detects that the user is running at a min-device-pixel-ratio of 2.0, it will automatically ask for the 2x version of the image (flower@2x.jpg) instead of the default image as specified in the image tag.

Finally, so as not to flood external sites with high-resolution image requests, this functionality would only work for local images specified via relative links.

Multiple resolutions

The resolutions tag can also contain a list of supported device-pixel ratios so as to support even higher-resolution displays when and if they become available in the future.

For example:

<meta name="resolutions" content="2x, 4x, 8x">

In this case, the developer would provide 2x, 4x, and 8x versions of all images. So, in the running example, she would make flower.jpg, flower@2x.jpg, flower@4x.jpg, and flower@8x.jpg.

Advantages

The advantages of this approach are several:

1. Makes it very simple for developers to support high-resolution displays like the iPhone 4's Retina screen
2. Does not require JavaScript
3. Does not change the default way that things work (if the meta tag is not specified, the browser simply behaves as it always has).

So, how do we make this happen?

I have to admit that I'm rather clueless about whom to contact about making this happen and wouldn't even know whom to approach in the W3C so I'm planning on leading my rather more clued-up friends to this post and seeing what happens. If you think that this is a good idea and want to point the right people here to get the ball rolling, I'd appreciate it.

Update: I've now submitted this as a proposal to WhatWG. Check it out on the MetaExtensions Wiki page.

And, of course, I'd love to hear your feedback and thoughts.

Since libusb is a simple library, installing it manually isn't difficult and the files you need are already in the libusb.pkg file. To install them:

1. Control-click the libusb.pkg file and select Show Package Contents.
   
2. In the Contents folder, select the Archive.pax.gz file and copy it to your ~/Desktop.
   
3. Double-click it to unarchive the archive.
4. Copy the contents of the resulting usr folder to the actual /usr folder. You can do this using Terminal with the commands below. That's it, libusb is now installed and you can continue with the rest of the instructions on Mac|Life.

sudo cp ~/Desktop/usr/local/bin/* /usr/local/bin/
sudo cp ~/Desktop/usr/local/include/* /usr/local/include/
sudo cp ~/Desktop/usr/local/lib/* /usr/local/lib/
sudo cp ~/Desktop/usr/local/lib/pkgconfig/* /usr/local/lib/pkgconfig/

After installing libusb and following the other instructions on Mac|Life, I was able to successfully downgrade to OS 3.1.3.

One warning: I wasn't able to restore my latest restore – I got an error telling me that my OS version was too low. (I had to install my last 3.1.3 backup instead.) Caveat emptor.

Hope this helps if you run into the same issue.

Yesterday afternoon, while wiling away time liking stuff on Facebook I got to thinking why voting couldn't be as easy as clicking a like button and decided to whip up a little like-your-candidate app in a few minutes using the new Facebook Like button and it became Facelection.

Who do you like in the UK General Election: Gordon Brown, Nick Clegg, or David Cameron? Vote with a click and tell your Facebook friends.

Technical details

As with most things, "a few minutes" when building the site turned into "a few hours" due mainly to annoying issues and a certain lack of polish that the Facebook APIs apparently have. Here are few of the issues I ran into, briefly summarized, in case they help anyone else out.

iFrames = trouble-free

First off, using the iFrame version of the Like and Share buttons worked like a charm and I initially thought I was done within about half-an-hour. I realized, however, that the iFrame version of the Facebook Like button doesn't let you customize the message that is displayed. To do that, as well as to allow the user to leave a comment and share their like on their wall, you have to use the XFBML version of the Like button.

XFBML gotchas

Using XFBML requires adding several namespaces to your (X)HTML file and adding a piece of JavaScript to your page.

What the docs fail to mention is _where_ you should add said JavaScript, which should be right after the opening <body> tag. I had it at the end of the page and that resulted in the Like button not initializing / not rendering.

Here's an example of the XML namespaces added to an HTML5 document:

 
<!DOCTYPE html>
   <html xmlns="http://www.w3.org/1999/xhtml"
         xmlns:og="http://opengraphprotocol.org/schema/"
         xmlns:fb="http://www.facebook.com/2008/fbml">
 

xd_receiver.htm wtf?

Also, some of the (outddated?) docs keep mentioning that you should create or download (using the application creation wizard) an xd_receiver.htm file. I found that this was unnecessary with XFBML and lost some time fiddling with it.

Link version of Share button doesn't like fb:like button

The other issue I ran into was that when I started mixing the fb:like button with the link version of the Share button, my Like buttons started not rendering some of the time (usually, they would render on the second load of the page, following a refresh). When I replaced the Share button with the XFBML version (fb:share), this problem also went away and things started working predictably again.

box-type share button with no shares

I also lost a bit of time due to what must be sloppy coding on the part of Facebook: the box-type (stacked) fb:share button does not render / layout correctly when it doesn't have a number of shares to display in its speech bubble. This bug does not appear to be present in the link version of the Share button which works fine.

Another difference is that the link version of the Share button displays the number of shares immediately following the first share whereas the XFBML version only appears to display the number after a few shares have occurred (I read somewhere that the actual number is three; I noticed mine pop up when five people had shared it.)

Hope these brief notes help you if you're currently pulling your hair with these issues.

It would be nice if Facebook devoted a little time to reviewing its developer documentation and removing outdated documents as well as possibly writing a few simple getting started guides to get developers up to speed with their APIs, especially the XFBML stuff.

(In hindsight, I would not use XFBML but rather follow the instructions in Using HTML to Imitate XFBML.)

Enjoy + share the ❤

Hope you enjoy Facelection. If you do, please don't forget to share it with your friends on Facebook! And, if you haven't seen Feathers for Facebook, my iPhone app for pimping your Facebook status messages with 200+ symbols, fancy text styles, and cute emoticons, check out the one-minute screencast here.! :)

To test out the hovercards feature, hover over my Twitter handle: @aral

Sign up for and play with @anywhere today.

Can't wait to play further with this!

Hey, we still have 365 days... you never know!

The virtual whore house those scrawny-necked geeks had set up at his geocoordinates was a blemish on the otherwise spotless reputation of his fine foods business. Bitches and caviar didn't mix. And Mr. Reed was not about to let anyone jeopardize the success he had scraped together from the crumbs of so many sacrifices.

Follow request: The_Cleaner_Brighton.

The_Cleaner_Brighton is now following you on Twitter.

d @The_Cleaner_Brighton: Need to remove porn geolayer at 50.826298,-0.139132. Pls help.

d @RitchesFoods: £5K to TheCleanerBrigton@googlemail.com via PayPal. I will handle it Tues.

d @The_Cleaner_Brighton: Sent.

Tuesday, May 23rd, 2013.

Refresh… porn… refresh… hookers… refresh… nothing.

Mr. Reed smiled for the first time in months. The_Cleaner_Brighton was good. The seedy geolayer would soon be a distant memory; a humorous conversation piece at the club. How refreshing to have one's top worry once again be whether to stock Norwegian or Scottish salmon next month.

His smile faded as his glance fell on the morning paper.

GEOHACKERS FOUND DEAD IN BRIGHTON.

d @The_Cleaner_Brighton What did you do?

d @RitchesFoods I handled it.

@The_Cleaner_Brighton You killed them?

d @RitchesFoods That wasn't a direct message.

d @RitchesFoods Don't worry, I'll handle it.

Given such a limited and valuable resource, you should be looking to make the most of how you invest it. In other words, which tools and technologies should you devote this limited resource to learning?

If you want to develop on mobile devices, you have a plethora of choices: do you invest time, like I did, into learning Objective-C and Cocoa to develop native applications for the iPhone? Or do you devote that same time into learning Java to develop for the Android? Or do you devote that same time instead into learning C++ and some proprietary framework that will only let you develop for Samsung's upcoming smartphone platform?

The question you should be asking yourself as a developer whenever you decide to invest your most valuable resource is this: how much of a return can I get from this investment? In other words, you need to calculate your Developer's Return on Investment on Time (DROIT).

Developers considering ROI, has the world gone mad?

These are not the DROITs you're looking for

Here's a very simple guide to help you decide whether or not you should invest time in learning a new tool, technology, or platform:

Seek: open standards and open platforms.

Avoid: proprietary platforms and walled gardens.

Let's examine why proprietary platforms and walled gardens constitute bad investments of your time and why open standards and platforms are the logical alternative.

Avoid: proprietary platforms and walled gardens

A proprietary platform is a platform that is developed and controlled by one (or primarily one) commercial entity. While there may be short-term economic incentives for learning and developing on proprietary platforms (for example, the evangelizing company may offer economic incentives or run high-cash-prize contests, or there may be lucrative enterprise contracts), their long-term return may be less certain. More dangerously, you will be locked into developing for a single platform and may have a harder time re-using your knowledge elsewhere. And what if the company in question decides to abandon the technology or stop investing in it?

Case in point: say you decided to learn the proprietary platform that Samsung is building for its next generation of smartphones. You cannot use those skills to develop for the iPhone or Android devices (or for the Web, or for desktop applications). This is a bad investment with a very low DROIT. This is one of the reasons why Samsung will fail dramatically in smartphones – they don't understand developers or the importance of maximizing DROIT.

Semi-open and Openwashing

Unlike Samsung, most companies with proprietary platforms are usually well aware of how unattractive lock-in can be for developers and this is why they often to embrace – at least superficially – open standards. Of course, just because a platform supports XML or some other open technology or standard, it doesn't mean that the platform is open. Most proprietary platforms feature some degree of Openwashing wherein the owners of the platform go to great lengths to make the platform appear more open than it truly is. Adobe did this for a long with the Flash Platform, stating that SWF was an open standard while actively barring anyone else from creating a Flash Player (this has now changed, and the SWF format has truly been opened up but its development and future direction are still primarily controlled by Adobe.)

When in doubt, of course, prefer proprietary platforms that do support as many open standards as possible to increase the reusability of your knowledge and maximize your DROIT. So, a good rule of thumb is:

Prefer semi-open over closed.

But there's an even better rule:

Prefer open over semi-open or closed

Open standards, technologies and platforms – by their very nature – offer you the highest DROIT.

As a developer who wants to maximize her DROIT, you owe it to yourself and your career to invest time in learning these open technologies. The advantages of open over closed are the following:

• No lock-in and skill reuse: the technologies you learn will be applicable across different platforms and devices; both today and in the future
• No walled gardens: to paraphrase Oliver, you don't have to ask "please, sir, may I deploy my app" to deploy or sell your apps

So, as a developer looking to enter the exciting world of mobile development, what technologies should you learn?

Based on the simple guide, above, and on a desire to maximize your DROIT, the answer is plainly clear:

Learn HTML5, CSS3, and JavaScript

The web is the best example of an open platform that we have today. It is the antithesis of a walled garden: you can deploy what you want, when you want, and don't have to ask anyone for permission.

While iPhone developers wait months on end for a response from Father Apple, you can deploy dozens of apps to the web without hassle.

And the technologies of the web, open standards all, have the highest reusability of any technology to date. Perhaps the saying should go: Learn HTML, CSS, and JavaScript and you shall never go hungry.

"But, Aral," I hear you say, "surely there are drawbacks to building apps using web technologies."

"Surely someone like yourself, with such a strong focus on User Experience, should understand that it would be untenable to create experiences using such generic technologies that match the experiences possible with native tools and technologies on mobile platforms."

Thus, surely, an iPhone web app must offer a lesser experience than the same app built using Objective-C and Cocoa Touch. Thus, surely, we must embrace the Lowest Common Denominator and sacrifice UX if we develop using cross-platform technologies.

Not at all.

Embracing Write Once, Compile Anywhere, not Write Once, Run Anywhere.

The ability to re-use code and easily port your applications between platforms and devices does not imply that we take a Lowest Common Denominator, Write Once, Run Anywhere (WORA) approach to UX.

Write Once, Run Anywhere has long been seen as the Holy Grail of software development. Sun promised us this elusive ideal years ago with Java and failed to deliver on it. Flash managed to deliver it across browsers and operating systems insofar as the web was concerned but Adobe then decided to embark on a futile mission to replicate this success across desktop applications and mobile devices. And browsers – and HTML, CSS, and JavaScript – were, and continue to be, criticized for failing to deliver on this due to the many browser incompatibilities that plagued developers in the early days of the web before we had better standards support in browsers and JavaScript libraries like JQuery that abstract out the more painful inconsistencies in the DOM.

But what do we mean by Write Once, Run Anywhere in today's world? And is it even a goal worth having?

No, it's not.

Not as the term has traditionally been understood in any case.

Defining Write Once, Run Anywhere (WORA)

Write Once, Run Anywhere implies that you create an application once and it runs the same way (or similarly) on anything. If you're Adobe, pushing Flash, "anything" may include the Web, desktop, and mobile devices.

If you have any understanding of User Experience, you will instinctively realize that regardless of whether or not WORA is technically attainable, it is definitely not a desirable goal to have as far as the user experience is concerned.

User Experience is about focus and optimization. You cannot write a web application and have it be a great user experience on the iPhone, for example, without optimizing the user experience for the iPhone. Optimizing in this sense of the word doesn't just mean scaling your interface down to fit within the dimensions of the iPhone's screen. It may mean having to completely recreate the UI of your app, including user gestures and interactions, to give your iPhone users the best possible experience on their device.

The same goes for when you want to run that same application on an Android phone or the Palm Pre. Where the changes may be less pronounced than those required to go from Web or Desktop to Mobile, the difference in feature sets and operating system expectations between the devices will require UX optimizations that may dramatically affect the structure of your user interfaces.

So while you can port an application that uses open web technologies across platforms and devices, you must still optimize the User Experience for each platform and device that you support. I won't downplay the importance of this: it may mean that you have to do a lot of work and invest a lot of time and money into altering your user interface radically to best support the unique features of the platform or device you are supporting.

However, it will mean that you do so without changing technologies and without changing your entire codebase (this is where maintaining a clear separation of concerns between your View and Model begins to pay real dividends.)

Even though Write Once, Run Anywhere is undesirable insofar as UX is concerned, it doesn't reduce your DROIT in open technologies. While the re-usability of your applications may not extend to the UI layer (or may apply less to it depending on how similar your various target platforms are), it will still apply to other parts of your application.

Using open technologies will make it easier to port your applications across platforms and devices. This does not mean, however, that there is a magic bullet that will make your applications usable on every platform. The concept of Write Once, Run Anywhere is a relic from the Age of Features that has no place in the Age of User Experience.

But what about the argument that applications built using web technologies cannot be as optimized for UX as native applications?

In a nutshell, it fails to hold water, and brings us to the alternative to WORA.

The alternative to WORA: Write Once, Compile Anywhere (WOCA)

There are currently a plethora of tools and technologies – both open and closed – that allow you to re-use your DROIT in open technologies to build native applications across various platforms without sacrificing UX. In fact, this is one the most exciting trends of our time and one of the reasons why it's a great time to be a developer.

Examples abound: the open source Phonegap framework, for example, lets you build applications using your existing DROIT in open web technologies while compiling your app into native applications on iPhone, Android, and Blackberry.

And it's not the only one. Check out Titanium and Appcelerator, and also look at web frameworks like iUI, xUI, Magic Framework, and JQTouch – all of which increase your DROIT.

Commercial and proprietary platforms are also embracing WOCA. Adobe, for example, realized that WOCA was the way to stay relevant with the iPhone and their upcoming Flash IDE in CS5 allows developers to create iPhone applications by re-using their DROIT in the Flash IDE while outputting native iPhone apps. (I hope Adobe wakes up and realizes that it has a far brighter future if it focusses on its development tools and native compilation with WOCA instead of spending time and money on trying to get native support for Flash on devices. Flash support in mobile browsers is necessary for a faithful rendering of today's web but native Flash support for applications adds absolutely no value to a platform.)

(Another proprietary WOCA solution to keep an eye on is Unity3D.)

Beyond WOCA: Palm leads the way with WebOS

The WOCA solutions we have today are a wonderful way of increasing DROIT in open web technologies. But mobile platforms can do better by actually embracing web technologies as first class citizens on their platform. (Not as crippled subsets like Apple's initial foray on the iPhone.) In fact, one company is already doing that and doing it beautifully.

While Microsoft drifts aimlessly with Windows Mobile trying to play a fruitless game of cat and mouse with Apple, and while Google – the defender of all things open and web – invests in Java with Android, one company has come out of left field with a solid vision to embrace open web technologies for its mobile platform. That company is Palm and its platform is called WebOS. And you should stand up and take notice because it is one of the most important developments in the mobile world today.

With WebOS, you don't need to compile your HTML, CSS, and JavaScript to native applications because they are the native technologies of the platform.

Beyond supporting open web technologies, Palm also supports the ethos of the Web. You are not bound to Palm's store (even though they have one) and can deploy your apps to the web without asking permission from anyone. (If you do want to use their store, you can do that also and get the best of both worlds – the impulse buys and worry-free purchasing that the store provides coupled with the freedom to also distribute your apps yourself.)

More than that (and this is a personal point), having been to the Palm developer event in London recently and met Dion and Ben (who head up Palm's developer relations), I have to say that Palm has some genuinely nice people working for them. I love their approach and their vision. They have hired developers who have contributed to the open web and believe in its future. In other words, Palm has the right people running the show. And I wish them all the success.

(And this has nothing to do with the fact that they gave me a free Palm Pre to play with. In fact, if anything, I find it unfortunate that the hardware of the Pre doesn't allow the software and Palm's vision to shine currently. But it is a Version 1.0 phone and I look forward to seeing how the hardware evolves with the Palm Pixi.)

In conclusion

As a developer, your scarcest resource is time. It is thus of paramount importance that you invest this time wisely in learning the relevant open web technologies of today – namely HTML5, CSS3, and JavaScript – in order to maximize your DROIT.

Thanks to WOCA solutions like Phonegap and native web platforms like Palm's WebOS, you no longer have to sacrifice either your investment in open web technologies or your commitment to creating great user experiences. In other words, you can have your cake and eat it too!

Bon appetite!

It was really getting to the point where I was ashamed of the blog and thus not posting to it. And my 60,000 or so unique visitors (and you are, all of you unique, don't you forget that) deserved better.

I hope you like the new design. It's running on the excellent Sharpfolio 2 theme by WebRevolutionary.

One note: some of the posts, especially the older ones, may not appear entirely optimized for the new design but it is quite a task to ensure that eight years of content displays correctly when you go pulling the rug from under it by changing the design. I have tried to keep the formatting of existing posts as much as possible and I'm going to continue to tweak the design in the coming days to handle font issues, colors, etc. (I'm not happy with everything yet but I thought I'd put it out there and then evolve it as I go.)

Oh, and finally, I haven't even tested this on Internet Explorer, and nor do I particularly care for it. Just sayin'

Here's to a new year on Earth and a new look for my blog. Hope you like it!