Animate on Arrival

A week or so ago I tweeted about a trend I’ve been referring to as ‘animate on arrival.’ Since then I’ve been seeing more and more of them, and a) wanted to write about it because I haven’t written in a while, and b) compile a list of them.

The reason it caught my attention is that without realising, it really made me focus on the content and actually read the thing. To demonstrate, I’ve listed a few decent examples below and I’m also keeping the others I find tagged on Delicious.

• LayerVault
• Si digital
• Karma
• Blackberry Z10

Apart from all being beautifully designed ― the top 3 particularly ― they were all launched within a few weeks of each other, got quite a bit of attention and of course all featured this technique.

Anyway, I really like it, and if you’re using jQuery just drop in jQuery Waypoint, add a class to trigger your CSS animations, SVG fills or whatever and everyone’s laughing.

And that’s that.

Taking the scenic route

When I was 12, I took up the drums. Like any instrument, or indeed any new skill, there’s an endless amount of seemingly boring stuff to muddle through after the initial excitement has waned. I’m talking about the vocab of learning a language, the admin of starting a business, the theory of a driving test.

In the case of the drums, amongst them were the rudiments. “You’ve got to learn your diddles, paradiddles, drags and flams to be a good drummer,” I’m told. Apart from being fun to say, these are repetitive exercises designed to improve technique. Perhaps typically of my often short-sighted ways, I saw no immediate benefit to learning them… “yeah right, as if the Metallica drummer does this rubbish.”

I took this attitude, put the headphones on and just played along to the music I wanted… the fun stuff. That’s why I took up drums in the first place. This was an ongoing theme until I discovered that the more experience I had, the more I could appreciate what other drummers were doing. I remember vividly how blown away I was by the speed and fluidity of these guys, something I hadn’t really noticed or respected before, and wanted to spend every shred of time I had learning to imitate. A few awe-inspired discussions after an impressive gig revealed their secret.

Taking a slightly more indirect route to my original goal, ‘just playing along to music,’ made it all the more achievable. Pushing myself to learn these unnecessary things only made the necessary things easier, smoother and more natural. It became addictive; the more I did the boring stuff, the more liberated playing for fun became. The flipside is that the more I understood, the more crushing revelations of how much more there was to learn showed their ugly heads. All the more to get going with, then.

Of course, hindsight makes all this seem hideously obvious now.

Back to today, in the world of the web and this experience is more relevant than ever. I write this now because Twitter’s recent changes to their API policy has resulted in three months of evening side project work being flushed down the toilet. As frustrating as this was, I tried a new approach to the way I tackled this project and just like it was with the drums, learning these new techniques only deepened my understanding of the ones I already knew. I’ll call that progress, and I’ll take it.

(Thank you, Twitter.)

Cf: paradiddles are important.

My Dad is Missing

I don’t usually use this space for personal musings, but this is an important one to me. My Dad has been missing for a month now, leaving his house in Surrey on April 2nd, and his car was found in Cornwall one week later, although it could’ve been there since the day he left.

Realistically, he could be anywhere by now and we know nothing of his whereabouts or intentions. Please help us spread the word and get his face known to as many people as possible by sharing the link below on your social networks of choice.

johnbarnettmissing.tumblr.com

Your support is greatly appreciated.

Loving the Web Inspector & Saving its Work

The past couple of months have been pretty intense and fast paced: a project that consisted of two interaction designers, two visual designers and three developers. A small and easy to overlook feature in the Web Inspector has actually had a noticeable impact in the way we’ve worked.

Saving out the CSS straight from the browser; its a bit like using a WYSIWYG editor that isn’t awful.

Its as quick as editing the styles in the Elements tab as I’m sure you do a hundred times a day already, jumping over to the Resources, selecting that stylesheet and hitting Save As in the contextual menu.

Its not that I don’t care about fonts and things…

We all want our work to look its best.

If you work in an agency, you probably work with designers and people who are passionate about typography, layout, colours, and so on. Really, this means you work with people who care about CSS (albeit sometimes indirectly).

I’ve worked on many projects where I’ve seen two people, typically the person in charge of typography, and a front-end developer spending hours in the Web Inspector nudging up and down the line-height values.

My experience is that any web designer worth their salt doesn’t mind taking a few hours to learn the basics of CSS. I’m not suggesting we ask everyone to know about zoom:1, but if the people who make the typography styles can actually adjust the leading, kerning and sizing styles as they will be seen, then this is a good thing.

Teaching your design team the whole ‘Right click, Inspect Element’ thing and perhaps some of the styles below, and then asking them to save out their changes and send them straight to you for merging in can save impressive amounts of time.

• font-size
• font-family
• font-weight
• letter-spacing
• line-height
• margin/padding
• text-transform
• color
• -webkit-font-smoothing ??

Not only does it let you get on with what you’ve got to do, but it allows the people who are in charge of the typography to work on it as and when they want. And thanks to this little feature, they can send you the actual code rather than an updated PSD document.

I’ve considered separating typography styles into its own stylesheet to make the merge process a cleaner one, but I’m sure the basics are there.

I like.

Using HTML5 Canvas for Image Masks

Recently I’ve found myself referring to Jake‘s (the bastard legend that is) HTML5 Video with alpha transparency demo for reference into some pixel manipulation techniques with Canvas. Used in a slightly different context, but largely the same technique, we can use Canvas to apply a full alpha mask to any image element.

For Webkit browsers, a similar effect can be used with CSS Masks, but perhaps you need slightly wider browser support, or you want to use the masked image in Canvas somewhere else.

This function is just a base and should really be tailored to your use case, but it shows how easy it is to read the alpha data from one image, and apply it to another. Using getImageData, a 4-chunk CanvasPixelArray is returned with each pixels’ R, G, B, and A values. The result is achieved reading and ‘merging’ the RGB values from the base image, and the A values from the mask.

That’s all it does, but having it wrapped up into a single function is sometimes easier to work with (again, depending on your use case). The function creates a couple of Canvas elements on the DOM and uses them to mash the pixels together. You just pass in the base and mask images, and get back the single masked image either as a CanvasPixelArray, or as a Base-64 encoded data URL.

To give you an idea of what the images can be, here are the raw images I’m using for the utterly useless demo.

• Base JPEG: playground.benbarnett.net/canvas-mask/img/octagon.jpg
• Mask PNG-24: playground.benbarnett.net/canvas-mask/img/alpha.png

Feel free to head over to the Github repo for further docs.

Adding Selector Support to jQuery.get() to get page fragments

Just wrote a little plugin whilst working on a project because I keep finding myself using this functionality and having to write a handler in my application code. This plugin can be dropped in, just like jQuery Animate Enhanced and weighs in at less than 1KB, and it will enable you to quickly grab a partial or fragment of the AJAX endpoint.

Here’s some dummy code:

There’s not really much more I can say about this. Its unobtrusive, light weight and will simply hand over to the native jQuery.get() method if no selector is supplied.

Further Resources

• Playground & Demo page
• Github for Issues and Source

Skinning the YouTube Player with HTML5 Video Support

Where we are now

So it seems that the YouTube Player API doesn’t offer any support for the HTML5 video player, while the standard Embed code does. It kinds of makes sense with the way they’ve implemented their player API as ultimately it’s just embedding a SWF with a few paramaters, but its still annoying. Its clear that the major players are working towards something, but for now we’re left with finding our own way through.

The reason its annoying is that the only way to truly skin the YouTube player (without its hideous & pointless background colour customization) is to use the Chromeless player and then overlay your own controls. This is relatively easy to do, and a there’s a reasonable demonstration on the YouTube Player Demo page.

What’s the point?

The point is so that you can have a custom YouTube player, and have it work on mobile devices without Flash. It also means that you get the benefits of YouTube’s encoding lair and that the number of ‘Views’ will be counted both on YouTube and from your site.

Making it work

As we need SWFObject on the page in order to embed the Chromeless player for our custom skin, we can use a handy method in its API:

swfobject.hasFlashPlayerVersion(versionStr) // e.g. "8.0.0"

With that, we can do a simple if statement, and hand the logic back to the standard YouTube embed code should that function return false. We do this because the basic embed code will use the HTML5 player where it can, giving us native iPad/iPhone/iWhatever support. You can grab this simply by going to YouTube, clicking Embed, and copying the code it gives you.

Either way, we palm off to YouTube at this point, allowing them to make the correct decision in a non-Flash environment, the logic behind which will probably change quite regularly.

Note: it’s not possible to skin the HTML5 Video Player on Mobile Safari, because it uses the native video player. Not a biggie though, it looks awesome.

Here’s a basic code example:

Demo

This is ugly, rudimentary and not for production. But it demonstrates the technique. Try the link below out on any browser, and on an iPad/iPhone:

clients.brushfiredesign.net/playground/youtube/youtube.html

You’ll see that with some basic styling, you can fairly easily create a completely custom player design using the elements on that page, which also works on your iPad.

CSS3 Text Effects with Webkit Masking

Dead easy but cute little technique this one. I’m working with a design that had an overlay effect over some of the text based headings.

The way I’ve seen it done before (and I have in fact done it myself) is to simply stick a PNG with alpha transparency on top of the text in question. Granted, this technique does work but it felt like a bit of a cludge. It also means you can’t highlight the text underneath it. Annoying and bad for usability.

I then cast my mind back to the stunning Kaleidoscope App website. Using a Webkit browser, look closely at the colour wheel triangle thingy and you’ll notice it’s spinning. Dig deeper in the CSS and you’ll see they’re using a really nice masking technique to achieve that.

Simple enough, but I wanted this effect to appear on all browsers rather than just Webkit.

Detecting Webkit Masking Support

Feature detection is the best way to implement this technique. Rather than just seeing if “browser = Chrome or Webkit”, you can either use the Modernizr library to do this for you, or simply grab the following line of Javascript and insert it above your CSS.

document.documentElement.className = document.documentElement.style.WebkitMask!==undefined?"masking":"nomasking";

That will add a class of ‘masking’ to your HTML tag should the feature be supported. And, by including this pre-CSS, you’ll get no flickering of content. You can then just add the .masking prefix to styles that use it.

Creating the Mask

Basic Photoshop skills should be enough to create pretty much any type of mask. The key point to remember is that they’re unlike Photoshop masks in that they rely on Alpha transparency rather than black or white.

Webkit masks require a PNG with an alpha channel, i.e. a 24 or 32 bit PNG.

Areas of the mask with 0% opacity will hide that section of the element the mask is being applied to. Areas with 100% will render as usual. Then, as you’d expect, you can use anything in-between for partial transparency.

Here’s the mask I’m using. I’ve dropped it in a green container so you can see where the transparency lies.

The CSS

This is the easy bit. For non ‘.masking’ browsers, implement the same ‘overlay’ technique as you’ve no doubt done before.

For browsers that do support Webkit Masking, just override the element (for example, an h1 tag) to set it.

.masking h1 { -webkit-mask-image: url(../img/bg/text-effect-mask.png); }

You can then play with the positioning and things should you need to;

• -webkit-mask-position-y
• -webkit-mask-position-x
• -webkit-mask-repeat

Here’s a screenshot of the output.

A nice, selectable, accessible, progressively enhanced text overlay effect.

Simple right?

This is a rudimentary use of the Webkit mask. As you can see from the Made by Sofa guys (creators of Kaleidoscope App), you can create some amazing effects and choose either to implement a technique for non-supporting browsers, or just degrade gracefully to a static version, as they’ve done.

You can also use them on pretty much any DOM element there is, as the comments on the Surfin’ Safari docs explain.

Enhancing jQuery’s animate function to automatically use CSS3 transitions

On a client project recently, we’ve been working with some heavy full page transitions, which can look extra lovely when on hardware accelerated browsers and devices. I was struggling to find a neat way to write the front-end code, which is using jQuery, to degrade and enhance itself automatically without putting switch statements and creating multiple stylesheets all over the place.

This is where my jquery-animate-enhanced plugin comes in. The idea was to have a one hundred percent seamless integration, and backwards compatibility with older browsers. For this reason, it just extends $.animate() which we all know and love and detects if you’re trying to animate something that would be better off done with a CSS3 transition. Absolutely zero effort required.

The plugin.

Extend $.animate() to detect CSS transitions for Webkit, Mozilla and Opera and convert animations automatically. Compatible with IE6+

Properties supported: (more to come)

• left : using translate(x, y) or translate3d(x, y, z)
• top : using translate(x, y) or translate3d(x, y, z)
• opacity

Note that any properties not mentioned above will simply be handled by the standard jQuery $.animate() method. This plugin adds new functionality without taking any away.

Demo

What it does

The plugin will analyse the properties you’re animating on, and select the most appropriate method for the browser in use. This means your transitions on left, top and opacity will convert to a CSS3 transition on Webkit & Mozilla agents that support it, and Opera 10.50+. If the user is on a browser that has no CSS3 transitions, this plugin knows about it and won’t get involved. Silent degradation

Multiple callback mechanisms are created internally to monitor for DOM manipulation and for all ‘transitionend‘ CSS3 events to be picked up. This means you have one neat callback() for the whole animation regardless on whether the plugin is using CSS3, DOM, or both for its animations.

Progressively enhanced CSS3 animations without having to do any browser detection or special CSS, therefore using the same Javascript across your applications and websites.

As this plugin uses CSS3 translate where available, there is an internal callback mechanism to reset the ‘left’ and/or ‘top’ properties so that your layout is unaffected.

Usage

Usage is identical to the jQuery animate() function, but it comes with 3 new paramaters, which are totally optional and safe to leave untouched for general use:

• avoidTransforms: (Boolean)By default the plugin will convert left and top animations to the CSS3 style -webkit-transform (or equivalent) to aid hardware acceleration. This functionality can be disabled by setting this to true.
• useTranslate3d: (Boolean)By default the plugin will use 2d translations due to wider browser support. Set this to true to use translate3d instead. Recommended for iPhone/iPad development (here’s why).
• leaveTransforms: (Boolean)By default if the plugin is animating a left or a top property, the translate (2d or 3d depending on setting above) CSS3 transformation will be used. To preserve other layout dependencies, once the transition is complete, these transitions are removed and converted back to the real left and top values. Set this to true to skip this functionality.

Give it a go

More information is available either on the GitHub repository, or on the plugin homepage. Thoughts very much welcome.

Writing HTML and CSS for Mobile Safari. Just the same old code?

The answer is “kind of”.

I’m a believer of the “write once, deploy anywhere” attitude. I’m also a big fan of things like WhitherApps; James has done a great job taking the (native) BBC News app and rebuilding it using just HTML and CSS to prove out this very concept.

BUT… people would be lying if they told you it’s exactly the same as writing CSS for desktop browsers. It just isn’t.

No support for the CSS fixed position

You could be forgiven for thinking that it just reverts back to absolute positioning like it does in IE6, but in fact it is not same as explicitly setting an element to absolute. The behaviour is subtly different, and I found that running any CSS3 style webkit transitions were much more performant, and less ‘flickery’ on an element with fixed position, over one with absolute even though the layout was identical.

Very strange considering there’s no support for fixed position. Couldn’t find that one in the specs anywhere either, so I remain baffled. My solution was to try both position attributes and see which performs better.

Usually though, Cubiq’s iScroll will do the trick as it’s more than likely the reason for needing fixed positioning anyway. That plugin genuinely works well by the way. Use it.

Hardware accelerated CSS transformations… but are they, really?

This one took me a good few hours to work out when I could have been quite happily doing far more productive things with my day. I knew already that the ‘-webkit-transform’ and ‘opacity’ attributes were hardware accelerated for webkit transitions. If you’re experiencing a flicker with css3 transitions, this is how to fix it.

It is true that opacity is hardware accelerated. It is also true that -webkit-transform is hardware accelerated, but, if you’re using translateX, translateY or translateZ, you don’t get that luxury. Take a typical CSS transition;

#element {
    -webkit-transition: -webkit-transform 1s linear;
    -webkit-transform: translateX(0);
}

#element.transformed {
    -webkit-transform: translateX(300px);
}

In any webkit browser, you’ll get whatever #element is to move 300 pixels to the right, in a linear 1 second animation. On Mobile Safari, it will likely ‘flicker’ before/during/after the transition. The key is to use translate3d(x, y, z). The simple change shown below makes all the difference.

#element.transformed {
    -webkit-transform: translate3d(300px, 0, 0);
}

It’s ridiculously simple, but honestly why would that be hardware accelerated and not the shorter hand, translateX property?

Avoid Javascript Libraries

You’ll notice that the Javascript engine on the iPhone is incredibly slow. The iPad is greatly improved but its still advisable to minimise Javascript, particularly for things like animations. Always use a translate transition over animating the left or top properties. The CSS3 transitions are perfectly smooth and look great. Arguably you don’t need jQuery for mobile apps as a lot of ‘weight’ comes from dealing with cross browser differences; obviously not being an issue if we’re focussing solely on mobile webkit. With the new CSS selector engine, document.querySelectorAll(); you still get lightening fast ‘jQuery style’ DOM selections. Time to brush off the raw Javascript skills (or just be lazy and wait for jQuery mobile).

Am I being impatient?

There’s only a handful of cases that have proved to be quite time consuming during development, but the point here is a bigger one.

The whole idea of unifying standards across all devices is the way forward. The thing is though that I can’t help feeling that we’re harking back to the “Are you using Netscape or Internet Explorer?” days. I wish we didn’t have to know about these tricks. It means that without position fixed, we need to use (and write) Javascript extensions to help us out, but then we add weight and potential bugs to the desktop side of things. Do we really have to start detecting whether we’re on an iPad and serve up specialised code? What about sites that we wrote before all this came about?

I’m still behind the idea of using HTML powered apps with simple Objective-C wrappers to encase everything into a native application. With a bit of reading up, and more than one or two stabs in the dark, its definitely not impossible to make an HTML driven app “feel” just as native as any other.

I guess one just has to accept that the concept of using exactly the same code on mobile and desktop devices still isn’t quite there.