thebeebs

Is Pinterest’s HTML5 app short-changing users?

thebeebs — Tue, 21 Feb 2012 16:50:00 GMT

It seems you virtually can’t move online without running into an article on Pinterest. As a platform, it’s certainly captured people’s (or at least the blogosphere’s) imagination. Core to the attraction is just how easy it makes sharing the stuff we all find every day on the web.

To its credit, Pinterest has taken a decidedly mobile first approach to developing the site – they understand that people find stuff on the move and want to share it instantly. They have a smart IOS app which gives all the functionality of the site and makes good use of the limited screen real estate. But at the same time they admit that they are lagging behind in developing a similar app for other platforms.

So, in a post on the Pinterest blog, they’ve recently announced a new HTML5 mobile version of the site which delivers a fair amount of the features most users need:

What we’re launching today is a streamlined experience for iOS and Android. You can view pins and boards, look at profiles, follow people and of course, repin all the things you find. In the coming weeks, we’ll be adding the ability to search and browse by category, edit pins, and create new boards. Support for other touch based devices like Windows Phone 7 and Blackberry will be coming soon. Of course, we’ll be fixing bugs as we find them as well.

All well and good. Until that is you take a look at the comments on the post. This, apparently, is not what users want – not at all e.g:

A mobile version is not the same as an app. An Android App is definitely needed.

The question, of course, is why?

From where I’m standing there are a number of issues:

These days, good enough just isn’t good enough for many users – not when it’s so easy to see what they’re missing out in comparison to a native app
There is still a perception that web apps are second class citizens – a lingering hangover from the days of WAP
Companies seem to think that HTML5 is the cheap alternative to developing a native app – this leads to them assigning too little budget and making some unavoidable compromises
And, for their part, developers typically have less experience developing apps in-browser

It doesn’t have to be this way. The work that the likes of the FT and Lanyard have done on their HTML5 apps is outstanding. They deliver an utterly comparable experience to a native app. So it’s certainly possible.

Of course, Pinterest’s effort is a work in progress. As they put in their post, more features are coming. So it remains to be seen whether they can deliver and turn the criticism on its head. If they can, they’ll gain an easy to update app that runs across multiple devices. If not, they may find their time in the sun comes to a premature end.

Overlaying data on a video

thebeebs — Tue, 21 Feb 2012 16:07:30 GMT

I got asked by Gordon Rae on twitter today:

@thebeebs Martin, can you recommend a good tutorial for overlaying data on video in HTML5 ?
— Gordon Rae (@socialtechno) February 21, 2012

Firstly beware that just because a browser supports HTML5 video it might not be capable of overlays… this is true particularly on mobile devices. This is because to save battery many HTML5 capable mobile browsers pass the video playing over to the phones native player. These players are external to the web page and so can’t display DOM elements over the video.

On most desktop browsers, tablets and a small selection of phones it is possible to place content over the top of the video element.

In general most people want to synchronise DOM elements to appear and disappear at certain points during the video. This can be achieved in JavaScript by creating a loop that polls the current position of the video. When the video reaches a certain position the developer fires events. These events could hide or show content or perhaps change a textual element on the screen.

If you don’t fancy writing your own framework to handle this you could use Popcorn.js there is a great tutorial on the framework over on net tuts which shows how easy it is to synchronise video and your content.

If you are just looking to add subtitles to videos then a player like leanback supports the track element (by using a JavaScript Polyfil since no current browsers support the feature natively) http://www.leanbackplayer.com/example_subtitles.html

Gradients in Internet Explorer

thebeebs — Mon, 20 Feb 2012 17:39:51 GMT

Last week at the digital barn I gave a talk called “The Way the web should be” in it I talked about the importance of Web Standards in the development of IE. In a follow up blog post Ian Parr made an interesting point:

One point that I think MS people sometimes miss is that it’s one thing having comparable features in browsers, but it’s another thing all-together ensuring that these features can be implemented consistently. I think a great example of this is implementing a linear gradient with opacity using CSS3. It’s great that you can now do this in CSS but if you look at the difference between doing this in Firefox and Webkit (with a nice tidy rgba value) and IE9 (with a confusing 8-digit hex code… thing) then it shows there is still one way for IE and one way for everyone else.

I understand Ian’s frustration on this one, and just wanted to share my own views on this.

It’s worth saying straight out of the gate, our implementation of linear gradients in IE10 is experimental and does not necessarily reflect what will appear in the final version of the browser. This is indicated by the vendor prefix –ms that is applied to the attribute. We put the vendor prefix for one of 2 reasons, we recognise that our implementation is not complete or we think the specification is likely to change.

Secondly as far as I am aware you can happily use RGBA values for transparency of linear gradients as this quick demo shows (works, in IE10 and latest versions of FF,Chrome, Opera and Safari). There has been some discussion around the specifics of over on the W3C mailing list but as far as we are aware platform preview 4 currently supports linear gradients in the same way WebKit, Opera and Mozilla does.

I completely agree with Ian with Ian's sentiment, however, and have said many times before “a bad implementation is worse than no implementation” Implementing stuff which wasn’t ready or properly thought out was the exact thing we did wrong with IE6…. And we are still paying for it 11 years later.

If you want to play around with CSS3 Gradients the IE team have put together this rather nice CSS3 gradient maker.

Are you developing for all browsers or just your favourite?

thebeebs — Mon, 20 Feb 2012 12:33:48 GMT

The choice of browsers today is wider than ever before. And, for the most part, if you develop for one modern browser, your site will pretty much work on all the others (albeit with a little tweaking here and there). It’s pretty amazing, and this browser interoperability is down to the great work standards bodies and standards advocates have been doing since the beginning of the web.

However, there is one area that is causing some concern amongst standards advocates and that is – vendor prefixes.

If you want some background, Bruce Lawson has a pretty comprehensive post on the subject as does Peter Gasston over on Ubelly.

Essentially for more experimental features, each vendor uses its own version of the code and prefixes it with an identifier (e.g. -ms-linear-gradient, –moz-linear-gradient, –webkit-linear-gradient). This prefix demonstrates that it is an experimental interpretation of the specification (linear-gradient). As such, it’ll be ignored by other browser vendors.

However, as with browser sniffing, this can have unintended results. Developers often use the experimental code released by an individual browser, but because it’s not implemented by all browsers at that point in time they only implement one browsers interpretation.

WebKit is often first out of the gate with a specification, and so many developers find themselves implementing WebKit first. Due to release timings and pressure to put sites live, it’s often the case that developers don’t get the chance to enable the experimental features for other browsers.

This means that while the site may look perfect on one browser, it can look broken on another (even though that browser is perfectly capable of displaying the element as the developer intended).

The question is, what to do about it. There are two sides to that. 1. What can browser vendors do and 2, What can developers do

In the case of browser vendors there have been a number of suggestions:

It’s been suggested that -webkit vendor prefixes could be adopted by the other browsers
Likewise, some have advocated a move to –beta or –experimental instead to create a single cross-browser prefix for experimental code
Or all browsers could accept any prefix which would achieve the same effect
Alternatively, the answer could simply lie in getting developers to fix or update their code as Daniel Glazman has suggested

What I’m doing as a developer:

With production websites I try to avoid using vendor prefixes that have only been implemented by one browser vendor.
If I am going to pass my code over to someone else… I will try to avoid vendor prefixes, because as the implementations change I won’t be able to go back and fix my code.
If I am using a vendor prefix I will, where possible, place it in a separate CSS file. I use a bundler that combines them at build into a single CSS file. This is helpful because it means all of my experimental code is in one single file, separate from the standard CSS.
I use all of the vendor prefixes, for each feature. Even if the particular vendor doesn't have an implementation of that feature.
I use the standard un-prefixed version of the feature, even if the feature hasn’t been standardised yet.

The real answer, long term, is for us in the browser community to work together to solve the issue. It’s not a quick fix, sure. But, we’ve already taken the first steps and I’m hopeful we’ll deliver something that’s fully in line with the open web.

Until then we all need to do whatever we can to ensure sites are coded for every browser, not just the developer’s favourite.

Using App Cache

thebeebs — Fri, 17 Feb 2012 17:01:09 GMT

There are many new features in HTML5 but in think that App Cache is potentially one of the most important. App Cache allows you to create a manifest file that details all of the files your application uses offline. When you visit your website with no internet connection the files that you list will be available to your application.

Over on the IE blog they have a great write up of how they used App cache to build an offline recipe book it details how they used app cache and how you can use it in your applications too.

8 things you should know before building an HTML5 app

thebeebs — Wed, 15 Feb 2012 08:01:00 GMT

A few days ago, Seth Porges put up an interesting post on Mashable: 8 Things You Should Know Before Building a Mobile App. While, as the name implies, Seth’s post focused on native apps, it got me thinking – how does his 8 questions relate to creating an HTML5 app? So here goes...

1. What does it cost to make an app?

Overall, with HTML5 the costs will be broadly similar to a native app. However, you may find your people costs come down as it’s generally easier to find HTML developers than those for native apps. Plus, the resulting application will work across multiple devices – with some customisation – which could bring your total development costs down further. I wrote a more in-depth summary of my opinions in a blog post a few weeks ago.

2. What should you charge for your app?

It is certainly more difficult to charge for an HTML5 app. But then again, go ask most Android developers whether they’re seeing revenues from their efforts (alternatively, take a look at this article). As with Android, the solution will probably involve either an ad-supported or freemium model.

3. When will you get paid?

This very much depends on the model you adopt (see above) but you probably don’t want to hold your breath if you expect to be paid just for download.

4. How do you write your iTunes description?

The simple, flippant answer is: you don’t. But this, of course raises a wider issue of how you get your app in front of people. There are now a burgeoning number of app stores such as Intel’s AppUp Center, ZeeWe and OpenAppMkt among others. But certainly, you’ll need to give careful consideration to how you market your app and create the necessary buzz and recommendations. The upside of course is that you won’t have to give 30% of your revenues to Apple or demand that users jailbreak their phones.

5. What’s the best way to beta test?

The good news here is that pretty much anyone with a browser can test your app. All you need to do is make it available to them. If you don’t have a test team on hand then there are numerous companies online who will test your mobile sites across numerous devices for relatively small fees. As I haven’t used any of these online services I can’t recommend any but if you have a favourite do let us know in the comments.

6. What happens when you get featured on iTunes?

Well, again, you won’t. Although you may get featured if you go to one of the HTML5 app stores listed above. Of course the real question here is about scale – if Lady Gaga tweets about your app, will you be able to cope? So it pays to ensure you’re hosted somewhere that will deal with hundreds, thousands or millions of downloads. A cloud solution such as Azure or Amazon should be part of your launch plans.

7. How do you get press?

Fortunately, just now, simply developing in HTML5 has a certain newsworthy aspect about it. You’re already a bigger fish in a smaller sea. It won’t last forever of course, but now is the time to strike while the iron’s hot.

8. How do you avoid the spam?

This is probably not an issue you’ll face just yet. Spammers are far more focused on IOS developers.

So those are my eight. How about you? If you’ve built an HTML5 app, what do you wish you knew back then that you know now?

A look at the new CSS3 units of measure

thebeebs — Mon, 13 Feb 2012 17:00:00 GMT

So if you have been developing for any length of time then you are probably familiar with ‘em’, ‘%’and ‘px’ as units of measurements in CSS. As part of the CSS3 specification there are a few new units of measurement that I think are worth casting an eye over.

‘ex’ This represents the height of a lowercase character in the elements font, it’s sometimes referred to as the x-height because in many cases it is equal to the height of the lower case x, it resents about half size of a font’s height. The usefulness of this measurement is questioned in this blog post.
‘ch’ width of the "0" glyph in the element's font. At first this might not appear to be that useful, but in monospace fonts it can be used to accurately measure text. Here is a real world use for this measurement.
‘rem’ font size of the root element. In practical terms the root element is the HTML element. This way you can set a font size on the HTML element and then use a rem to size a font relative to that element anywhere in the document. There is a nice blog post here detailing it’s real world use.
‘vw’ viewport's width – You can resize elements based upon the width of the viewport (the rectangular viewing region of the browser) that is currently viewing the website. It’s use is discussed here.
‘vh’ viewport's height - You can resize elements based upon the height of the viewport that is currently viewing the website. It’s use is discussed here.
‘vm’ minimum of the viewport's height and width – This tells you what is smaller out of either vw or vh. In the specification there is currently an issue which asks if this is still required. Since a developer could simply use the new min function instead. e.g min(1vh, 1vw);

Like apps? Like Facebook?

thebeebs — Mon, 13 Feb 2012 08:04:00 GMT

How did you find the mobile apps you use the most? I’m guessing that some of you came across them on a blog or in a mag somewhere (10 Apps Every Developer Should Own). You might have found others browsing through an app store of whatever flavour. But, if you’re anything like me, you’ll have found quite a few simply through the recommendations of your friends (both real and virtual).

Considering how many thousands of apps there are, they can be surprisingly tricky to find. In my experience, the search function of most app stores leaves something to be desired (and I’m being kind here). And even though most stores feature user reviews, it can still be hard to distinguish the reality between the ‘This is the best app EVER!!!’ reviews and the ‘This is total rubbish, I want my 69p back or I’m going to sue!!!’ ones.

So what about Facebook as a platform for finding (and distributing) new apps? Techcrunch recently pointed to a new feature Facebook are trying out – placing links to third-party apps at the top of its mobile newsfeed instead of hiding them down the bottom. This, of course, follows on from the launch last October of its mobile app platform (which offers the company 30% of the revenues generated by in-app purchases).

So is this the answer for developers? Put your app on Facebook, run a bit of promotion and let the social world Like it to stardom? It’s an appealing idea.

However, as Techcrunch points out, Facebook’s app platform hasn’t exactly been a roaring success so far. So is it destined to go the same way as their previous Facebook Marketplace idea? Or could we see the same stellar performance as social gaming?

Putting my developer hat on, the question for me is: Will Facebook give my apps access to a larger audience than they’d get elsewhere? Certainly the user numbers are there but what about engagement? And crucially, can they harness the recommendations that are lacking on other platforms?

If they manage this, they could become a serious contender for app distribution. But I’m not holding my breath just yet.

What about you? What would you need to see on Facebook before you’d commit to putting your apps on there?

10 myths holding HTML5 back

thebeebs — Wed, 08 Feb 2012 08:00:00 GMT

While the momentum is certainly with HTML5, for some of us progress can’t happen fast enough. Yet, annoyingly, all too often we find ourselves facing the same old questions and challenges – ones that really have no basis in reality. So in this post, I want to focus on the 10 myths that I have to put down most often.

Myth 1: HTML5 is a Flash-killer

It’s not. There are some things that are simply better done in Flash or Silverlight (see my earlier post for details). And it’s not just this, for the foreseeable future there will also be issues simply in finding people with the right skills (at the right price) to develop in HTML5. So while HTML5 will certainly dent the use of Flash, we shouldn’t be digging its grave just yet. The myth holds back HTML5 because it causes unnecessary tension between flash developers and HTML5 developers. The HTML5 movement would benefit from the skills, expertise and creative flair that exists in the Flash community.

Myth 2: Using HTML5 as an Umbrella term is bad.

When most people say HTML5 they mean: HTML5, JavaScript, CSS3 and related specifications. Using the wrong language is almost guaranteed to polarize any group of developers. But you know what? Outside of developers, no one cares. So while I agree that if it’s a developer-to-developer conversation, we should try to be specific, we should cut everyone else a break. Because it’s more important that the world has confidence in moving to these new standards rather than getting distracted by developer infighting over semantics.

Myth 3: HTML5 is the next revolution

Hand on heart, there’s virtually nothing that can be done in HTML5 that couldn’t be done before. Sure, HTML5 can do it better and IMHO more elegantly but it is better to see it in terms of the latest evolution in the overall web revolution. For one thing, this is more accurate and for another, it’s less scary.

Myth 4: HTML5 doesn’t work in IE

Now, you’d expect me to take issue with this one. The truth is that IE9 supports the HTML5 features that can be used today and supports them well. IE10 supports practically the whole specification and there is more to come before final release. In fact IE8 supports a number of features too such as localStorage. With a little bit of care you can create elegant fall backs for older versions of IE. While of course I have a vested interest here, the point is a wider one. Because IE still has so much of the world browser market, this myth gets used as an excuse not to develop in HTML5. The reality is really quite different.

Myth 5: HTML5 won’t be ready until 2022

Well, no, 2022 was a date mentioned in an article back in 2008 but the date for HTML5 to reach W3C Recommendation level is 2014. So does that mean you can’t use HTML5 till 2014? No… This is just the date where there should be 2 browsers with 100% interoperable implementations of the specification. Remy sharp put’s this into perspective nicely in this article when he states that CSS 2.1 didn’t become a candidate recommendation until 2009… since Remy's article it went back to working draft in 2010 and then became a W3C Recommendation on 7 June 2011. Did Facebook, Google, YouTube [enter you favourite Site here] wait till 2011 before they started using CSS 2.1? No. Likewise with HTML5 you don’t need to wait until W3C Recommendation. With the current widespread browser support, why wait?

What’s really important is the user. Can they get a better experience with HTML5? If the answer’s yes, that’s good enough for me.

Myth 6: HTML5 will make websites more/less accessible

Fundamentally, it’s developers who make sites accessible. It’s their empathy with users that delivers an accessible site. And that’s not dependent on HTML5. Yet, perversely, this can be used as an excuse to wait.

Myth 7: It’s not possible to develop decent games

May I refer you to my post about Cut the Rope. Seriously, the issue here is that if a game is designed and built in HTML5, it is altogether possible to deliver a really great experience. The issues come when a game is simply ported from somewhere else. Are there better gaming platforms? Sure… Does that make HTML5 a bad gaming platform? No.

Myth 8: HTML5 is the answer to write once, run everywhere

Well, it certainly gets us closer. But a better description would be that HTML5 enables us to ‘write once, customise everywhere’. It provides a solid platform to develop from but not a universal panacea that makes all the differences between browsers and devices magically disappear. Touting HTML5 as a panacea creates division between developers and the resultant arguments hold us back from implementing HTML5 today.

Myth 9: There are no tools for HTML5

Certainly there’s a lack of major WYSIWYG editors (though they are coming). But this needn’t be a deal breaker. There are masses of code editors available and, at the end of the day, that’s really all you need. My editor of choice is Visual Studio, a tool I’ve been using for the past 8 years. If you have an editor that works well with JavaScript and HTML, you’re good to go.

Myth 10: HTML5 isn't ready for prime time

Right now, most HTML development is simply basic old JavaScript and HTML (i.e. the web stuff that’s worked in browsers for years). If you’re smart you can start mixing in some new HTML5 features for browsers that support it and create web applications that rival native applications. Take a look at the new lanyard mobile application as a great example of this. Seriously prime time.

Ultimately, the issue with all these myths is that they can act as an unnecessary brake on development and acceptance. And while some issues certainly do exist, let’s focus on the real challenges rather than phantom ones.

Why Don't you need to close tags in HTML5?

thebeebs — Mon, 06 Feb 2012 17:00:00 GMT

HTML5 is a much more forgiving when it comes to Mark-up than XHTML. With XHTML you needed to make sure that each opening HTML tag had it’s own closing tag. So you would always close an image tag like this:

<img alt="A pretty car" src="image.jpg" />

If you forgot to close the tag, like this:

<img alt="A pretty car" src="image.jpg" >

And you tried to validate the document then you would end up with an error like this:

However, try the same thing with the W3C HTML5 validator and you will discover that it' doesn't have an issue with it.

The HTML5 specification has standardised the way that browsers deal with the problem of malformed HTML5 so you don’t need to worry about it… unless of course you want to. You see, you can use XHTML5 which insists that every tag must be explicitly closed (amongst other things). In short the issue of people not correctly closing tags was so widespread that it was considered a better approach for all the browser manufacturers to agree on how they should deal with such issues rather than fighting an up hill battle to convince everyone to write XML based mark-up.

For what it is worth, I continue to close tags even though I don’t need to… it makes makes the OCD side of my personality happy.

Turning up our noses at browser sniffing

thebeebs — Mon, 06 Feb 2012 08:00:00 GMT

Did you notice it? Well if you’re an Opera user you might. As of last week, if you go to Bing using Opera, you’ll get to see the HTML5 background video in all its glory.

Now, let’s be clear, it’s not as if Opera couldn’t play the video before. It just never got the chance.

You see Bing used browser sniffing to determine what it thought visitors’ browsers could and could not deal with. Browser Sniffing is, to my mind, a relic that should have been put to rest years ago. But, like a bad smell, it’s just hung around.

The problem with browser sniffing is – and I believe this is the technical term – it’s just a bit pants. With so many browsers and so many user agent strings (not to mention browsers pretending to be other browsers) you simply can’t guarantee the right result.

This means you’ll tend to exclude at least a portion of your audience (probably unnecessarily as most browsers deal with most code just fine – as in the Bing example with Opera).

The solution to Browser Sniffing? Feature detection… Rather than guessing at what the browser is capable of, you use JavaScript to test the browser. In general this is far more accurate and delivers far better results.

To learn more about feature detection – and particularly how to write a feature detection tests in JavaScript – check out my earlier post. And to see a demo in action, take a look at the tutorial video I created with Ubelly detailing how Sky News used feature detection in a proof of concept project I worked on last year.

Learning HTML5 & CSS3

thebeebs — Tue, 31 Jan 2012 10:02:00 GMT

How did you learn to code?

I ask because a couple of recent chance encounters have got me thinking that there are some pretty big gaps in people’s knowledge of HTML5 and CSS3.

For example, I was chatting to a student who approached me at an event last Saturday. He asked me where he could go to learn HTML5. I suggested a few books and started explaining how HTML5 differs from HTML4. He interrupted and said, "Sorry you don't understand… I have no idea about HTML 4 either."

Is it me or is there a real problem here? After all, the guy was enthusiastic, he wanted to learn but was struggling to find the right resources for him. The problem seems to be that too many of the current books and sites assume that you’re simply moving up from an earlier version. So they spend a lot of time putting HTML5 into context by making exactly the same mistake as I did – explaining how it was different from HTML4 (or 3 for that matter).

When I started web development back in the late 90's (when dinosaurs ruled the world) I remember starting with WebMonkey.com. Then I moved on to learn DHTML from DHTMLcentral.com. And then on to 4guysfromrolla.com to learn server-side programming.

Is there a modern day equivalent? A resource that guides people from complete beginner to web developer. Or do we simply expect all new developers to find their own way?

What site, book, course etc would you recommend to people that are just beginning in web design and development?

The Curse of Quirks

thebeebs — Tue, 31 Jan 2012 08:00:00 GMT

<rant>

At the danger of causing my Klout score irreparable damage, I want to spend this post using their site to highlight a mistake I’ve seen three times in the last week.

The problem? In a word: Quirks.

I went to Klout.com in IE and rather than seeing the nice, clean, well-structured design they intend, you’ll see a hodgepodge of mangled DIVS and misaligned blocks of colours. Not pretty.

The cause? The developer has placed something before the DOCTYPE of the page. This makes IE assume there is no DOCTYPE and switch to Quirks mode.

You can check to see if a website has had this particular variant of fresh hell heaped upon it by pressing F12 and checking the document mode. If it has been set to Quirks then something is wrong.

Beating quirks is simple

There’s no real rocket surgery here. The 3 most common causes behind the Quirks I see on a regular basis are:

The developer has placed a verification comment above the DOCTYPE. (Services often ask developers to place a comment with a particular code in their web page so that the site can verify that they are the owner of the site before allowing access to the service. Remember if you are doing this add the verification inside the head tag.)
The developer added comments about the source code before the DOCTYPE. The solution is to simply move the comments below the DOCTYPE.
Or, as Klout did, the developer added a body tag before the DOCTYPE. Weirdly, if you change the user agent string to Chrome it serves up content that’s not malformed (ie the body tag doesn’t appear before the DOCTYPE). This leads me to think they’re doing some form of browser sniffing. (Browser Sniffing is another pet hate of mine as it makes problems like these even harder to pin down.)

3 simple rules

Always use a DOCTYPE
Never place any content before the DOCTYPE declaration
Check you sites regularly in the W3C validator. Even if you are not looking to get valid HTML, at least you’ll know the issues and can then make an informed decision as to whether you want to fix them

</rant>

I want to use Canvas but need to support IE8

thebeebs — Fri, 27 Jan 2012 17:00:00 GMT

Ok so you have a great idea for how you’re going to use Canvas in your next application… problem is you still have tons of visitors that use IE8 (which doesn't support the Canvas element). Not to worry, all is not lost. In many instances you can use something like FlashCanvas. This is what us HTML5 junkies like to refer to as a polyfil or fall-back. Fundamentally a rather smart person has implemented the HTML5 Canvas API using some JS and Flash Wizardry so that you can get your canvas code working in versions of internet Explorer that don’t support canvas.

It’s has it’s limitations of course, and you may need to modify your code in some instances to get things working, but if you are looking for a quick and simple solution and you are not doing anything too crazy or intensive then this polyfil might be the answer to your prayers.

How to build Mobile websites

thebeebs — Thu, 26 Jan 2012 16:55:00 GMT

With the explosion of devices that access websites, it's becoming more important that your website works well on mobile devices. I found the process of learning how to create websites that worked on mobile devices confusing so I created the list below to help anyone that is new to this field of web development. As always if you have any good links to tutorials on any of the 5 topics below please comment and I’ll update the post accordingly.

The Viewport Meta Tag

By using the viewport tag you can tell some mobile browsers how to scale and zoom your website. You can often improve the default reading experience of your website just by adding the following meta tag:

<meta name="viewport" content="width=device-width, initial-scale=1">

This article from Gil Think explains the Tag in a very straight forward way.

Media Queries

Media Queries allow you to serve different CSS rules depending on the way your site is being viewed. For example if your site is being viewed on a mobile phone you can write CSS specifically for a screen with a 320px screen width.

The great thing about Media Queries is that you can tailor your main site to look great across various screen resolutions and widths. This article from my counter part in Belgium does a good job of explaining Media Queries and responsive design.

Touch Events

Touch is tricky as there are a number of different implementations, Ted Johnson shares a technique for handling touch events across Android, iOS and IE10 over on the IEBlog.

On the Clarity consulting's blog they discuss touch more generally along with some sample code that I found really useful.

Mobile Frameworks

There are a number of frameworks that can help you build web applications for mobile. Whilst many of these frameworks are commonly used to create standalone applications, rather than enhancing existing websites, familiarising yourself with how they deal with screen resolutions and touch can teach you how to build better websites that work well on mobile.

jQuery Mobile - http://jquerymobile.com
MooTools Mobile - http://mootools.net/forge/p/mobile
M-Project - http://www.the-m-project.org
Sencha Touch - http://www.sencha.com/products/touch
jQTouch - http://jqtouch.com
NimbleKit - http://www.nimblekit.com/index.php

Differences between IE for the desktop and IE for Mobile

If you want to know what the differences are between IE9 on the desktop and IE9 on mobile I wrote a post a few months ago that lists them all out.

How to write a feature detection script in JavaScript

thebeebs — Wed, 25 Jan 2012 18:00:00 GMT

When I use a HTML5 feature in my website I will often test the browser that is visiting to see if it is capable of using the feature. If it is not capable I will Fall-back to something that the browser is a capable of supporting. In practice, I use modernizr for this purpose, however, there maybe instances where you want to write your own tests.

In most instances writing these feature detection tests is quite straight forward.

The example below tests to see if a browser is capable of supporting HTML5 Audio.

return !!document.createElement('audio').canPlayType;

If the browser is able to create the audio element and the canPlayType property is true, this test will return true. If the browser is unable to create the audio element the test will fail.

Mark Pilgrim has a great resource that shows you how to test almost any HTML5 feature.

To use the code above I might create my own little library and call it myTests. I add the property audio and assign a self executing function (this basically means that the function runs as soon as it is created) and then the returned value is saved into the variable audio.

  var myTests = {
            audio: (function () {
                return !!document.createElement('audio').canPlayType;
            }())
        }

To test audio I can then just call

myTests.audio

So for example the following code would use my test when the browser loads:

 window.onload = function () {
            if (myTests.audio) {
                alert("Your browser supports Audio")
            }
            else {
                alert("Your browser dosen't support Audio")
            }
        }

Demo view here

What if I want to use Modernizr and my own custom tests?

Modernizr has a rather nice feature that allows you to add custom tests to the library.

Modernizr.addTest("myAudioTest", function(){  
	 return !!document.createElement('audio').canPlayType;
});

You can then just call it like this (note that even though we added the test name in capitals Modernizr lowercases the property name) :

Modernizr.myaudiotest

So the demo above would look like this:

window.onload = function () {
            if (Modernizr.myaudiotest) {
                alert("Your browser supports Audio")
            }
            else {
                alert("Your browser dosen't support Audio")
            }
        }

Demo view here

Is HTML5 cheaper to develop with?

thebeebs — Wed, 25 Jan 2012 07:30:00 GMT

There is an argument for HTML5 that runs: because it can run across multiple devices, HTML5 can help you slash the costs of developing new apps. Now, rather than dealing with the time and cost of developing native apps, you can simply write once and deploy everywhere (near as damn it).

Now, I’d dearly love to simply agree with this. But, as with so many things in tech, the reality is not quite so clear cut.

Over on his blog, my boss has been talking about the reasons why people build applications. This leads me to think, the motivation for building an app and the skill set of its current developers will ultimately determine if HTML5 is a less expensive option.

But, of course, the cost argument is a powerful one. So let’s look at four ways in which HTML5 may save you money:

HTML and JavaScript developers are available in abundance. While the best people are always in demand, it should be easier to find talent from such a large pool. And because there are more of them, there’s less of a specialist premium on their hourly rates (if you don't know what a specialist premium is, go ask a COBOL developer).
Solutions to common issues are often widely shared among developers. This means you can solve problems faster (and therefore more cheaply). The JavaScript and HTML5 world is massive, so you’re often just a Bing search away from a solution to a problem – other search engines are available ;). Plus with great sites like Stack Overflow, JavaScript is one of the most documented languages in the world.
HTML5 and JavaScript development requires no specific hardware, you can develop on pretty much any OS you want. Compare this to the challenge of being, say, a Microsoft or Linux shop and wanting to dev for IOS. In this case, you’re going to have to invest in some Mac hardware since you can't virtualise Mac OS legally.
Finally, as I suggested above, if your codebase is HTML and JavaScript, there’s a good chance you’ll have great code reuse across platforms. Of course, let’s not kid ourselves, you will have to make modifications to go across all platforms but at least you won’t have to start from scratch.

So is HTML5 the cheap option? In the final analysis, the answer is: Yes. No. Maybe. It depends. Not the most satisfying I know but probably the closest to the truth.

I'd love to know what you think.

Are you being pushed to HTML5 for cost reasons?

Are you happily going that way anyway?

Do you think cost is irrelevant?

Let me know.

Using HTML5 to Jump to the search box using autofocus

thebeebs — Mon, 23 Jan 2012 17:00:00 GMT

Autofocus is a HTML5 attribute that you add to input elements, which cause the browser to automatically focus on the input element when the page loads. Google and every other search engine have been doing this since the dawn of time (slight exaggeration) with JavaScript but now you can do it with some simple markup.

Demo view here Source on GitHub

Of course the autofocus attribute tag is not supported by every browser, but a great polyfill created by Amiel Martin exists which uses JavaScript to add support to unsupported browsers.

You just need to add the scripts to your document:

<script src="http://blogs.msdn.com/scripts/jquery-1.5.1-vsdoc.js" type="text/javascript"></script>
<script src="html5support.js" type="text/javascript"></script>

Add a some script to initialise the library

$(document).ready(function () {           
	$.autofocus();       
});

You will then autofocus on elements with the attribute, such as:

 <input autofocus type="text" name="search" />

Will HTML5 be the death of PDF magazines?

thebeebs — Mon, 23 Jan 2012 07:30:00 GMT

Do you still read magazines? Newspapers? If so, are they printed publications or have you gone digital?

With the wild popularity of the iPad and the predicted stampede for the Kindle Fire (not to mention all the other tablets hitting the market) there has been a headlong rush by many publishers to get onto these new devices and do it fast.

So far, most seem to have gone the PDF route. It’s easy to understand why. They’re probably already developing their print publications in InDesign so it’s a relatively easy step to output a version to PDF. Plus Adobe have done a pretty good job of helping publishers add some nice bells and whistles (check out Wired’s iPad edition to see what I mean).

But PDF isn’t the only option. And some would say – myself included – that it isn’t the best option either. Of course, you won’t be surprised to hear me claim that HTML5 offers significant advantages over PDF.

So here are four reasons why I think HTML5 trumps PDF for digital magazines:

A major advantage is file size. An HTML5-based publication will come in at something between a tenth and a fifth of the size of a PDF one. So this means less waiting for users and less space taken up on their devices.
Text can remain live (rather than simply rendering as an image) so you can zoom in as much as you like with no pixilation (it also means you can select, copy and paste text should you want).
Because the text is live, you can search it too.
And then there’s the whole cross-platform thing. Sure you can scale a PDF to different screen sizes but that just makes everything bigger or smaller. With HTML you can scale in a more intuitive way that’ll preserve text sizes for easy reading (no matter how small your screen).

It’ll be really interesting to see how this market develops. While the iPad is the runaway leader at the moment, the Kindle Fire could mount a pretty serious challenge with access to all of Amazon’s content (and it’s own dedicated magazine store).

The new KF8 format on the Fire supports both HTML5 and CSS3 – some 150 formatting styles if Amazon is to be believed (full list here). This means publishers can take full advantage and produce some serious eye candy without file-bloat.

So will HTML5 be the death of PDF magazines? In truth, it’ll probably be a mixed bag while everyone finds their feet. But in the long run, my money is on HTML5.

What do you think?

Further reading

InterfaceLab has a good article (although it is over a year old): Is this really the future of magazines or why didn’t they just use html 5?
The Guardian has a good round up of Apple Newsstand which covers some of the issues around PDFs: Apple Newsstand: can it crack the news market?
Elliot Jay Stocks has a good post on his blog (unless you’re from Adobe that is): Adobe's digital publishing mistake – the comments are particularly interesting

Do I need to use WIA-ARIA with HTML5?

thebeebs — Fri, 20 Jan 2012 17:00:00 GMT

Accessibility for Rich Intranet Applications (WIA-ARIA) is a specification that makes it easier for people using screen readers to navigate and use web applications. Many of the new HTML5 elements like section and article have been added to the specification along with more controls so the obvious question is… Do I need to use WIA-ARIA at all?

If you want a one word answer: I’d say yes. Use HTML5 semantic elements and the built in controls but you should use WIA-ARIA where appropriate as it will improve accessibility. Combining HTML5 and and WIA-ARIA can cause issues, many of which this blog discusses however in most situations you are going to be improving accessibility by spending a little time applying ARIA support.

If your doctype is HTML5 then ARIA will validate using the W3C validation service as this example shows.

To dive deeper into the subject I’d suggest reading the following articles on the subject:

Making forms easier to fill out using placeholder text

thebeebs — Thu, 19 Jan 2012 17:00:00 GMT

Placeholder is a HTML5 attribute that you add to input elements, it makes it easier for users to fill out your forms.

Demo view here Source on GitHub

It works for on regular input fields but also works on on password types. Of course the placeholder tag is not supported by every browser, but a great polyfill created by Amiel Martin exists which uses JavaScript to add support to unsupported browser.

You just need to add the scripts to your document:

<script src="http://blogs.msdn.com/scripts/jquery-1.5.1-vsdoc.js" type="text/javascript"></script>
<script src="html5support.js" type="text/javascript"></script>

Add a some script to initialise the library

 $(document).ready(function () {
            $.placeholder();
        });

Add some CSS to style the placeholder text

.placeholder
        {
            color: #888;
        }

Using CSS3 to make your web pages better when they are printed.

thebeebs — Wed, 18 Jan 2012 16:51:00 GMT

I recently walked past someone in the office who was reading a web article that they’d printed off. Now putting to one-side the environmental impact of printing the internet there is also another disadvantage to reading printed webpages… the hyperlinks don’t work. Wouldn’t it be nice if you could somehow add the textual link next to a hyperlink but only when a document was printed, well you can using CSS :after selector.

Demo view here

Firstly you will need to add a print style sheet. This is just a regular stylesheet which is only applied when the document is being printed. This requires a regular style sheet link with the attribute media=”print”.

<link href="print.css" rel="stylesheet" type="text/css" media="print" />

Inside this style you just need to the following CSS. I tend to switch text decoration (the underlining) off of printed hyperlinks because it’s easier to see URL when they are printed without the underlining (but this is entirely optional and there are reasons why you might not want to do this)

a:after
{
    content: " (" attr(href) ")";
}
a
{
    text-decoration: none;
}

The demo page will then look like the below image when it is printed:

If you would rather use inline style then you could write it like this:

<style>
        @media print
        {
            a:after
            {
                content: " (" attr(href) ")";
            }
            a
            {
                text-decoration: none;
            }        
        }
</style>

So many devices, so little time

thebeebs — Wed, 18 Jan 2012 09:36:00 GMT

It didn’t seem so at the time but not so long ago, developing for the web was actually comparatively simple. Sure there were some significant differences between browsers and some (ahem) got a pretty hard time for lagging behind. But at least there was a pretty finite range of screen sizes and PCs of broadly similar capabilities.

Looking at where we are today – especially in light of all the new toys pouring out of the recent CES exhibition – those not so distant days seem positively quaint.

These days we don’t have to just worry about laptops and desktops but also netbooks and iPods, smartphones and tablets (IOS, Android and Windows) plus internet TVs to name just a few. Some are simply running a classic browser (in various guises), some are more app-focused. And who knows what’ll be next?

Also, the range of stuff we’re developing has never been greater. Native apps, web apps, sites, widgets, desktop apps, SaaS. Even in my own area focused on web development, the choices are bewildering.

Of course, as you’ll very well know, the issues don’t end when you ship. Keeping up to date, fixing the inevitable bugs, and guarding against your work going out of spec as devices, standards and operating systems change is the stuff of nightmares.

This is where HTML5 has the potential to really come into its own. The promise of create once, deploy everywhere is tantalisingly close. It’s not there just yet and it demands compromises (but all development does that). But it’s coming.

I was reading the recent Mobile Web Metrics Report from Netbiscuits which has a whole section on devices’ HTML5 capabilities. The picture is one of HTML5 growing (albeit a little patchily depending on where you live) as a core supported feature of the majority of today’s devices.

For example, the research found that out of the top 10 devices in the US:

Offline Web Application Support is the best supported HTML5 feature with 9 out of the top 10 devices supporting it

Geolocation API and 2D Animation Rendering are both supported by 8 out of 10 devices

Webstorage is supported by 7 out of 10 devices

Sadly, in the UK, we’re not at these levels (or those seen in most of Europe and, of course, across Asia). It’s only a matter of time though.

As I always try to make clear, this isn’t to say native apps are toast. If you’ve got the time and the cash, do both a native app and an HTML5 web app. But, if you want maximum reach across multiple devices, right now HTML5 is a good bet.

Some further reading

Will HTML5 help battle mobile fragmentation in 2012?

How HTML5 Is Aiding in Cross-Platform Development

Is HTML5 Ready for Mobile Cross-Platform App Development?

A good round-up of everything that came out of CES 2012 can be found on The Verge (and on a million other sites and blogs).

HTML5 - Not just because it’s new and shiny

thebeebs — Mon, 16 Jan 2012 13:31:14 GMT

After my giddy excitement over the Cut the Rope HTML5 game, Rob Ashton’s comment got me thinking a bit more.

In some ways I take Rob’s point – using HTML5 because it’s new or shiny or cool isn’t the best of reasons for doing this kind of thing. (Although I admit, I like cool stuff as much as anyone.)

To my mind, the performance of the game does illustrate what’s possible with a bit of ingenuity – and yes, I agree it must be carefully worked around. The fact that the experience is near as damn it indistinguishable from the iPad should, in some small way, show that HTML and JavaScript are capable of more than they’re sometimes given credit for. Which, to my mind, is the point of doing this – and why developers should care about it.

In addition, it shows that games in particular do not need to be propped up by Flash to work. Take Angry Birds for Chrome, for example. While pretty much everything is HTML5, audio is Flash. If you’re going to do this, you might as well stick with Flash. Instead, Cut the Rope uses SoundManager which uses HTML5 audio in the first instance and falls back to flash for browser that have trouble with doing it natively. If flash isn’t available, you’re not going to get locked out.

That aside, where I am in violent agreement with Rob is where he says “it is a wonderful way to deploy games to a large number of uses across nearly all devices in a standard manner.” It’s this ability to extend the reach of an app that makes HTML5 such a valuable addition to the developer’s kitbag.

If the tech beauty parade at CES shows anything, it’s that the proliferation of devices is in rude health. And while this feeds the soul of my inner geek, it presents a real challenge for developers. Now, HTML5 might not be the only solution but it is becoming a viable option for a growing number of these challenges.

How you can allow a user to edit pages with HTML5

thebeebs — Mon, 16 Jan 2012 10:53:00 GMT

When a user wants to change some information on a webpage it's often very jarring to ask them to go to another form to edit the content. Users find it difficult to understand how the changes they make on a form will effect the resultant page.

Therefore it's become common practice to allow users to edit the content in place. It's easy enough to do this by switching out content areas with Form Fields however HTML5 offers us another solution called contenteditable. It's not a particularly new feature, having been in IE since version 5.5 but its addition to the HTML5 specification and now broad support means that you can confidently use it on your website .

Jack Osborne of HTML5 Doctor fame, gives a great overview of the feature with a number of examples including how to save the edited content.