HTML5 is a new standard for developing web-based applications with rich interfaces similar to what can traditionally only be achieved in a desktop environment or by using browser plug-ins such as Adobe Flash. Support for HTML5 is being built right into all modern web browsers, with many features already available. While this is very good for the web community, it’s also very good for the mobile space; all modern smartphones come with a browser that is working to support HTML5. This means that instead of re-writing the same application for each mobile platform, one single version can be written in HTML5 that works across all of them.

The main motivation for choosing HTML5 is that the smartphone market is diverging, while support for HTML5 is converging. Each mobile platform in the expanding mobile space has its own API and distribution model, and any new platforms will likely follow suite. Contrast this with support for HTML5, where all these platforms are rushing to implement the same specification. How will this look in a few years? We will have even more platforms to develop separate clients for, but all of them will have increasingly better support for HTML5.

Another big reason for choosing HTM5 is that it has a strong, predictable future. In addition to picking up traction all over the web, the specification for HTML5 is mapped out to the year 2022, over ten years from now (but that doesn’t mean HTML5 is not ready to use right now). With the current smartphone market, it’s difficult to predict which clients will even be around in a few years, let alone which ones will still be popular. Using an HTML5 client removes much of the guesswork surrounding which platforms to support, and as it becomes the default standard for web browsers, any future platforms will support it as well.

There are other benefits to an HTML5 client, such as the control it grants you over your application. With the iPhone, for example, Apple must approve any change that is made to a native application, even after it is released. With an HTML5 application, there is no need for an approval process — in fact, it’s not even possible; device manufacturers and OS providers have no ability to regulate web content.

HTML5 is a great choice for mobile development in the current market. If you find yourself struggling to decide which platform(s) to develop for, or concerned about the future landscape of the mobile space, or unsure about having to seek approval from a manufacturer before your application can be deployed, consider the possible advantages of HTML5; it won’t be right for every scenario, but creating a native app isn’t either.

Note: This post is also available at http://www.macadamian.com/blog/post/why_html5_makes_sense_for_mobile/.

<tangent>This post was probably inspired in part by a recent similar post on Outspoken Media.</tangent>

Don’t bite off more than you can chew.

My first idea for this week’s post was massively ambitious. A popular site I follow posted an article last week about something I know a lot about, and didn’t do a very good job of it — and it was one of those dreaded list-posts where you can tell some of the items were just filler to boost the count up to a nice, rounded number. I was sure I could write a better post about the topic, so I got started! I was picking apart all the things the other article did wrong, doling out advice for how it could have been improved, coming up with my own, significantly better advice and conclusions, it was epic!

And then I read over what I had so far.

It was atrocious. My bold calling-out of a not-so-great post with examples of how to do it right was reading like a vicious tirade about why I’m better than they are. It was awful! Then I looked up the post’s author; he’s been blogging since I was in high school, has guest posts on some of my favourite blogs, and has made a hugely positive impact in his niche. What was I doing? This guy was a role model. So he had an off-post. It wasn’t all that bad, and even if I could find a few things wrong with it, that doesn’t translate to a better post — especially if I’m being a jerk about it.

So I trashed it. It was probably the longest post I’ve written for this blog to date, and I wholly regret wasting so much time on it before pulling the plug. On the plus side, I’ll think twice about it next time, and hopefully one of you will too.

Posts about current events can backfire.

My back-up idea for this week was based on a gem of a rant I went on over Skype when I found out that YouTube pulled the original RickRoll’d video for a Terms of Service violation. This was a solid post with some legitimately good content that I was all set to write — until I found out that YouTube restored the video.

This is the problem with such ephemeral topics. How long would that post have been relevant for? A few days? Then what? I update it to say “rejoice! the video is restored!” and the rest of my post is moot? Ridiculous. Next time I’ll remember to wait until the news is more official before assuming I’m set for next week’s post.

Are you really a good candidate to write this post?

My third idea was to write a post based on some story I found via Slashdot; one of those trendy posts about an ongoing saga of human rights dilution in a far-away land. This was obviously a good idea, because it was something I cared about! Not so.

What kind of insight would I have on such an issue? Sure I’m passionate about it, but so are millions of other people. Do I know more than the majority of them do? Probably not. Am I going to have some wacky angle that no one else has covered yet? I doubt it. Is there anything significant I can contribute in this space? Not really. So, no post. It was my fault for choosing a topic I was under-qualified to write about.

Please learn from my mistakes.

It’s been a long couple of days. It wasn’t easy throwing out idea after idea, especially after I’d invested time and energy into each one. But in the end I’m glad I did it; I didn’t publish something stupid that I’d probably regret later (or worse: completely forget about), and the silver lining turned out to be a handful of valuable lessons, ready for their own post.

Exhibit A: The iPhone’s Clock.app

Let me tell you a story. A few weeks ago, the fiancée and I were scheduled to meet with a potential wedding venue early Saturday morning. Given that it was a bit out of the way and we tend to oversleep, we thought we’d be smart and set an alarm using the iPhone’s default clock app.

So Friday night, we set an alarm thinking it would wake us up Saturday morning. It did not; it turns out the alarm we set was for weekdays only! While this was entirely our fault, I’m still going to call Apple out on not taking context fully into account: when we set the alarm, why didn’t the app warn us that the alarm wouldn’t go off the next morning? I would imagine it’s very rare that anyone sets an alarm more than a day in advance. It’s much more likely that when someone sets an alarm at night, they expect it to wake them up the next day. This is a case where a neat feature is actually an annoyance because context isn’t handled as well as it could be.

Exhibit B: Google Maps

Continuing our story, while I was frantically trying to get ready I was loading Google Maps to get directions to our appointment. After punching in the address and asking it to route us there, Google Maps told me the trip would take over 9 hours. I freaked out! We don’t have 9 hours, we have 30 minutes; is this the right address? Did we accidentally book an appointment at a venue 9 hours out of Ottawa?

Actually, it turns out I had Google Maps set to give walking directions. Again, my fault, but again, where were the developers on this one? Did they really think I wanted to walk over 9 hours to get somewhere? Why not recognize that I was probably looking for driving directions and put a message at the top of the screen asking if that’s what I meant?

(For the curious, this story did have a happy ending: we made it there a slight 15 minutes late, and this was the venue we eventually chose for our wedding.)

Exhibit C: Firefox’s Spell-Check

Firefox is an incredible piece of software. It is currently the browser of choice for about one quarter of all internet users, and in many ways helped to revolutionize the web browser market. But one area where it hasn’t really advanced as far as it could have is its built-in spell checker. I don’t have a fancy story for this one; the data speaks for itself. Here is a list of words that show up as spelling errors in Firefox 3.6:

Some of the internet’s most popular websites:

• YouTube
• Facebook
• Myspace
• Flickr

Well-known web technologies:

• Skype
• Silverlight
• Webkit
• Wordpress, CMS
• PHP, CSS (it gets HTML)

Very common computer words:

• Inbox
• USB

Extremely successful desktop software:

• Photoshop
• PowerPoint

Apple products:

• iPod, iPhone, iPad
• Macbook
• iMac
• OSX (it gets Linux and UNIX)

These are all very common words in internet parlance, and it’s ridiculous that they are highlighted as possible spelling errors. Why not add them to the dictionary? A simple white-list that could be crowd-sourced to the community seems right up Firefox’s alley; I wouldn’t be at all surprised to see this addressed in a future release.

What can we learn from this?

My main take-away here is that context is a big factor in software development, and one of the hardest to get right. Even the big guns have room for improvement, which means the rest of us likely do as well.

In other news, today is my birthday! You don’t have to get me anything, but if you really want to make my day here is something small you can do: Think of your favourite post on this blog, and email me or leave a comment below to tell me what it is. Simple, right? But it would really mean a lot.

• DHTML started to take over some of the really basic use-cases for dynamic events like rollovers and showing/hiding content.
• AJAX made truly dynamic content easier for the non-flash world.
• The mobile web started to take off, with most devices not capable of supporting Flash.
• Microsoft released Silverlight, a competitor to Flash in the rich interface space.
• Apple started releasing wildly popular devices that intentionally avoided supporting Flash.
• Browsers started implementing support for HTML5 and CSS3, which are slowly being adopted by designs that would historically require Flash.

Slowly but surely, alternatives to Flash have been picking up speed, and things beyond Adobe’s control have prevented Flash from penetrating certain markets (mobile in particular). What does this mean for Flash as a technology?

Flash isn’t going away anytime soon…

This isn’t one of those posts about how HTML5 or the iPad or global warming is going to spell the end of Flash. Flash is a major player in many areas of the web, most of which won’t change anytime soon. In particular:

Games — There are tons of online Flash games. This is a huge market that Flash has absolutely dominated since day one, and none of the technologies mentioned above can compete with Flash on this level of interactivity.

Video — Like it or not, HTML5 is not yet strong enough to handle cross-browser, web-based video. Even when it is (and it will be sooner than you think) Flash will still be used well into the future because it’s the only solution for legacy browsers, and the vast majority of users don’t update their browsers as often as they should.

On top of that, Adobe has created an entire ecosystem of software and a vibrant community for designing, building, and publishing Flash-based applications. Plenty of people are heavily invested in these tools, and no amount of evangalism is going to convince them that their problems could be better solved by today’s Flash-alternative du jour.

…but Flash will start having a reduced role on the web in general.

It would be unrealistic to pretend that these new technologies aren’t eating into Flash’s market share. For one, even in the most complex cases, some projects are choosing Silverlight over Flash. Not the majority (not even close) but more than none, and Microsoft is a powerful competitor that can compete with Adobe on the development tools and community levels.

Secondly, HTML5 and CSS3 can do some pretty neat things. For cases such as modern, dynamic navigation and simple logo animation, it will soon make much more sense to use features supported by the browser than a heavyweight proprietary plug-in; especially if all you need is a quick piece of eye candy.

Finally, there are the problems caused by Apple. I can think of three:

No iPad/iPhone Support — The longer this keeps up (and I don’t see it changing anytime soon), the more likely it is that someone will create a cool, interesting way to do fancy, Flash-like things in an iFriendly format. And then a general-mobile format. And then a web format. The last thing Flash needs right now is for some brilliant start-up to shake things up even further.

Macbooks are getting popular — Adobe claims that Flash runs on every platform ever, but as Chris Rawson astutely points out in this excellent article, that’s been easy to say while most of the world has been running Windows. With Apple’s laptops gaining popularity, people are starting to realize that Flash doesn’t run as well in OSX. The more Macbooks Apple sells, the more Adobe’s claims of market domination will start to dissolve.

No iPad/iPhone Support: take two — I want this website to be viewable on the iPhone, the iPad, and whatever whimsical hardware Apple comes up with next. That alone means I’m not going to use Flash in my blog’s design, ever. I’m admittedly in a minority here, but I wouldn’t be surprised if today’s kids getting into web design are also going to want to show off their cool, new, standards-compliant sites on their cool, new, iApproved devices. This sort of trend will slowly but surely push Flash out of the cool-new-site space.

Getting along with OSX is something that Adobe is going to have to work towards to keep Flash competitive, especially as new markets evolve out Apple’s hardware.

I’m not anti-Flash.

I’ve been using Flex Builder to build cutting-edge Flash applications for years, and I still believe there are many cases where Flash is a legitimate choice for creating a rich internet experience; there just aren’t as many as there used to be, and this combination of new, exciting technologies and pressure from Apple are making for some exciting times in the world of web design.

2010 is shaping up to be a wild ride for Flash and its competitors, and I can’t wait to see where it takes us. What are your predictions?

Then Apple releases the iPad, which promises to do everything I was planning to use my Macbook for at nearly 1/3 the price. Now what? Do I keep eying the Macbook or start counting the days until the iPad hits stores? I’m completely torn.

First let’s get a few things out of the way. I don’t want the 3G version of the iPad. I have enough monthly bills already, and my iPhone covers all my 3G needs. I’m also not the kind of person that needs much space, so the low-end iPad suits me just fine. And I don’t want a Macbook Pro; a regular Macbook is easily enough power for me, though I would probably take the ram upgrade for an extra $100. With that in mind, we’re looking at $500 for the iPad vs $1200 for the Macbook.

I want something I can use while sitting on my couch, and all it has to support is writing blog posts and your standard email/browsing activities. Both machines are perfectly capable of performing these tasks, and I’m already fluent in both OSX variants from owning an iBook and an iPhone.

Now for the interesting part: the advantages each device offers.

Advantages of the iPad:

• It’s significantly less expensive, as we’ve already discussed.
• You can turn it sideways. That may sound ridiculous, but I much prefer web browsing on a screen with more height than width.
• I love the form factor. Watching the video on Apple’s website… It doesn’t look like he’s holding a tablet and running a browser; it looks like he’s holding a browser. This level of UX is absolutely a step above anything else on the market, Macbook included.
• It has substantially more novelty, and all kinds of potential that we don’t know about yet.

Advantages of the Macbook:

• It’s a well-established line. You know exactly what you’re getting, and how awesome it is.
• Multitasking. I’d like to be able to have a browser open at the same time as Twitter and an IM client.
• The platform is more open. I like using browsers other than Safari, running commands in Terminal, and hacking together useful AppleScripts.
• What if I want to do some iPhone development? I’d need a Macbook, unless Apple releases some sort of iPhone-specific XCode for iPad (and who’s to say they won’t?)

It’s a mess. There are so many differences, but the advantages of each individual device are so appealing that I can’t make up my mind. Worst of all, I’ll probably regret either decision — if I go with the Macbook, I’ll sigh longingly every time I see an iPad; if I go with the iPad, I’ll curse every time it can’t do something that the Macbook can. I’m still undecided, and that’s not likely to change anytime soon.

What’s your take?

Should I go with the iPad or the Macbook? Are you in a similar position?

I’d like to say it’s because I’ve been busy (I have) or because the computer I normally use for blogging won’t boot (it won’t) but the truth is I had a really good post I wanted to write that I didn’t get done, and that’s lame. I’ll have it up in a couple of days, but until then I’ve prepared a list of pretty things for you to look at while you wait.

Last week, a friend of mine asked me what design blogs I currently follow, and here’s what I sent back:

Smashing Magazine — Easily the most popular name on the list. I find they do post a fair bit of noise, but they have some really good stuff every now and then that’s certainly worth following for.

For a Beautiful Web — Probably the best design blog I follow. Lots of interesting stuff, highly recommend.

I Love Typography — This is the only strictly-typography blog that I follow. Gives a very good summary of new and interesting type-related things once/week and a few other misc posts here and there (which are usually pretty interesting).

100 Redesigns — This guy is doing something really cool: every week he picks some ugly looking major website and posts a redesign for it. They’re good designs, and I find them inspiring because redesigning web sites is a valuable skill.

Dustin Curtis — This guy makes a completely new design for every post on his blog, and he’s a totally ace designer. Oh, and his posts are great too.

Jason Santa Maria — This guy has some remarkable credentials and his blog is a great source for interesting design-related ideas (though posts are often few and far between).

Stop Design — Another guy with an awesome design blog that doesn’t update often. He’s a graphic designer that used to work for Google but now works for Twitter, and his website is literally the best-designed website I’ve ever seen. Every time I visit I find something new about it that I totally love.

Colour Lovers — This isn’t really a design blog, but it’s good inspiration for colour palettes, and every once in a while they post a gem of an article about colour theory or how colours are interpreted on a biological level.

The Oatmeal — Ok, so this is clearly a web comic of sorts, but the design of the comics is always top-notch and I learn more from one of these comics than I do from ten self-proclaimed ‘awesome CSS galleries’.

Who do you Follow?

If you follow any great design blogs, I’d love to hear about them; leave your own list in the comments.

I’ve been meaning to write up a good post regarding my take on Google Wave pretty much since I launched this blog in October ‘09. The trouble was, I could never find a really good use-case that demonstrated how powerful and useful Wave is — until now. So without further ado:

I don’t understand how people planned weddings before there was Google Wave.

My fiancée and I are both the type to do a lot of research and planning before a big financial decision. So when it came to booking a venue, with so many different options and associated costs, we both dove right in. The only problem was that we had a really hard time staying in sync; we would both research the same venue or lose track of contact information for a place we really liked — it was a disaster. We tried ad-hoc discussions in person (this didn’t work; human memory is far too fallible) and a mess of emails (I had to scrub my inbox with a sponge after that one) but we found we were still stepping on each others’ toes. Then it dawned on me:

What we really needed was a wiki.

We needed someplace where we could both see and add and edit information, highlight important dates or phone numbers, and easily compare venues to one another. Nothing huge (a CRM would have been way overkill), just a light-weight wiki that would be approachable for my not-very-geeky soulmate.

So I fired up Google Wave and spent a couple of minutes explaining it to her. Now we have a wave for wedding venues, where each wavelet (that’s what the posts in a wave are called) is about one venue. When either of us comes across a cool-looking venue, we can quickly scan the wave to see if it’s already there, and if it isn’t we can add it and fill in some quick details. If we want to contact them, we highlight the contact info, and if we make an appointment to visit a venue, we highlight the date as well; this way even at a quick glance we can quickly see when our appointments are and if there are any left to make. If either of us have comments about a venue, we can reply to its wavelet; this takes care of the usual meta-discussion in an informal but persisted way (the indent makes it easy to ignore when skimming).

So far, this is working incredibly well. We’re both completely in sync all the time, and it’s easy to find key information by quickly looking in one place. We’re already starting to add new waves for other things we’ll both want input on, like the photographer, the DJ and the cake. I have no idea how else we could be doing this as efficiently as we are; Wave is suddenly crucial to our planning process.

What went right?

I’d like to touch briefly on why this has worked out so much better than my previous experiences with Wave. I think one of the big problems with Wave is that information tends to get scattered — it’s easy to lose something in a mountain of replies, and the inability to hide or mass-delete old content causes a lot of unnecessary and frustrating sifting. What I did differently this time was enforce some basic rules about how the wave should be structured: one venue per wavelet, replies are allowed for discussion if required. This way there’s no checking to see if that golf course with the gorgeous gazebo is nested somewhere in a chain of replies, or deciding what depth to add that maple farm that four different people have recommended. They’re both easy decisions, and sticking to these informal rules really pays off in terms of keeping the wave easy to read and update.

Have you found a good use for Wave?

I’m curious to know what other creative uses people have found for Wave. If you’ve got something good, please share!

• In person
• Over the phone
• In a mailed letter
• Through a printed announcement (say, in a newspaper)

Fast forward to today, a mere 20 years later. How much has changed? In addition to the ways mentioned above, look at all the new tools we have:

• Voice chat (Skype, Google Voice)
• Video conference (Skype, iChat)
• Instant message (from any number of clients)
• Text message (or MMS)
• Email
• Facebook (status update, wall post, private message)
• Twitter (tweet, @someone, DM)
• Blog post

And this is just what I used on Monday; there are many others. We’re more connected than ever before. We can reach more people, faster, through whatever means is convenient for them, and the list of applicable technologies just keeps growing. It’s incredible!

A brief take-away

Monday reminded me how many tools there are for spreading messages that I don’t normally use, and made me realize that sometimes I have to look outside of my usual channels to reach people in a way that is most effective to them. I’m sure there are other things I will think of over the next little while that I can communicate more efficiently using tools other than my defaults; perhaps the same is true for you?