Tea round is far too constrained in terms of the inputs (no spaces are allowed) and adding new names / clearing names takes far too long. Not to mention that if you run two ‘spins’ one after another, everyone is still included in the ‘spin’. Mine would be different. So I started to build a skeleton app using javascript and I had it working in an hour or two.

The styling replicates the look and feel of a native iOS app and can also run perfectly well on desktop or tablets.

The end result is an app that looks like a native app; is cached on your device so you don’t need an internet connection – like a native app; and has the same interactions & speed that you would expect from a native app.

So how long before the native app is dead?

Well the only thing stopping it is access to functions within the device itself. Things like the camera (although there are workarounds – see PicUp) or GPS, gyroscope / accelerometer. All you need is a secure API to access that information with the user’s consent (imagine a popup screen similar to the ones you get with Facebook authorisation for apps) and you can say bye bye to a lot of native apps. So how long until this happens? Well, probably a long time.

The app business is worth £billions now so allowing anyone to create their own and not have it pass through an app store (so the creator gets all the money) is unlikely. Also you will lose the curation of apps  so there won’t be any guidelines to adhere to in order to be published. So you could get any old Tom, Dick or Harry publishing a crappy app… like the internet then.

Really though, everything is eventually going to be web based. So it’s just a matter of time.

Check it out

Have a look at the app on your phone or tablet (or even in your browser) and use it.

Try Pickr for free

This is great! Dan recommends that you use $('.bouncy').addClass('bounceInDown'); to add the class with jQuery and this is the simplest method to get you started. In fact this is the method I used when I started my site redesign.

I quickly ran into issues though. Now, it wasn’t anything that animate.css does or doesn’t do. More the fact that there was no way to replace jQuery animations with the CSS3 fancy-pants ones.

“What did you do?” I hear you ask.

Well, I’ll tell you. I wrote a little function that handled adding the classes to any element dynamically. This gave me a little improvement in terms of ease of use and speed. There was still something missing though. I only realised when I had 3 animations that needed to run one after each other, that there was no way to determine when a CSS3 animation had completed so I could run another one. In the interim I set a delay parameter so I could say ‘do this, wait 3 seconds then do this’.

This ‘callback’ functionality does exist and CSS3 animations do indeed trigger an event when they finish, you just need to set a javascript event listener to detect that so you can apply some actions. After a little Googling I added this to my function. This now worked in a very similar way to jQuery’s own animate function so it was very familiar.

Then came the plugin

A few weeks later, Dan (@_dte) mentioned me in a tweet saying that my site was using his animate.css and looked good. I thanked him and showed him my jQuery function that helped. He seemed suitably impressed and asked if he could use it. It was already a public gist on github so I said no problem. That evening I decided it would be even better if it was an actual plugin that could be used in an even similar way to jQuery’s native functions. And so jQuery animateCSS was born.

To use it is pretty easy.

Basic

$('#your-id').animateCSS('fadeIn');

With callback

$('#your-id').animateCSS('fadeIn', function(){
    alert('Boom! Animation Complete');
});

With delay (in ms)

$('#your-id').animateCSS('fadeIn', 500);

With delay AND callback

$('#your-id').animateCSS('fadeIn', 1000, function(){
    alert('Boom! Animation Complete');
});

If you want to hide an element when the page loads and then apply an effect, it might look something like this:

<style>
    .js #your-id {
        visibility:hidden;
    }
</style>

$(window).load( function(){
    $('#your-id').animateCSS('fadeIn', 1000, function(){
        alert('Boom! Animation Complete');
    });
});

Remember to use a .js (or .no-js depending on how you role) so that the element still displays for non javascript users (and Google previews).

Again, the plugin is available here: https://github.com/craigmdennis/animateCSS/

That’s it guys. Have fun.

This is unlikely to change soon but the differences are becoming fewer and fewer. To make the most of this you need to choose a browser in which to make your design / functionality work the way you want it to and then compromise fix it in Internet Explorer other browsers.

Let there be light!

The main thing to realise is that all browsers are not created equal. Older browsers lack support for new technologies (CSS3 / HTML5) and render pages in sometimes odd ways. They also tend to be less forgiving with various structural models and dynamic scripting languages like JavaScript. Something often forgotten is that some users may decide to turn off features in browsers or may be impaired in a manner which affects their browsing habits.

Examples include:

• disabling JavaScript
• disabling images
• not using a mouse
• using a screen reader
• using a text-to-speech device

Now while it is near impossible to include in a design every aspect that could affect the way someone experiences a website, there are things that can be done to improve the experience where possible.

Graceful degradation

“Graceful degradation means that your Web site continues to operate even when viewed with less-than-optimal software in which advanced effects don’t work.”

– Fluid Thinking, by Peter-Paul Koch

Graceful degradation is finally being addressed as the wrong way to approach the problem – design utilising the most advanced features of a browser and where a browser is not capable of implementing those features, a compromise needs to be made. The testing of older browsers is often done towards the end of the development cycle. More often than not this results in a less pleasing site for those using older browsers. This mainly affects IE6 which is still widely adopted throughout the corporate world. Using this approach focuses on using the latest technologies and not considering the experience for people with older browsers, disabilities or with certain functionalities disabled.

So how do you add bells and whistles to a site while maintaining  focus on usability and experience? The answer is in the design process. By first focusing on what ‘everyone’ will see and use, you can address the broadest issues. Bear in mind that a good experience with a site does NOT mean pretty pictures (although they can help) and a person can have a good experience on a simple site, for no other reason than being able to do what they want to do with ease and no interference.

Progressive enhancement

Leading on from core usability is the inclusionof  features to improve the experience for those people who are able to experience them – this is known as ‘layering’, starting with semantic  (X)HTML, wrapped in some CSS and finally some JavaScript on top.

“Progressive enhancement uses web technologies in a layered fashion that allows everyone to access the basic content and functionality of a web page, using any browser or Internet connection, while also providing those with better bandwidth or more advanced browser software an enhanced version of the page.”

– Wikipedia

There is a far more tasty explaination using an M&M that defines the same point:

“Start with your content peanut, marked up in rich, semantic (X)HTML. Coat that content with a layer of rich, creamy CSS. Finally, add JavaScript as the hard candy shell to make a wonderfully tasty treat (and keep it from melting in your hands).”

– Aaron Gustafson

Good for SEO too?

When you write rich, semantic (X)HTML you are making life easier for search engines to index your site. It is written in a predictable, organised fashion and as such means the search-bots are more likely to pick up on any extra information as well as index it in the way it is intended. If you think about a search-bot ‘seeing’ in a similar way to a screen-reader, they generally only read text and links and with progressive enhancement you have given them both the best opportunity to get the most out of your site.

In practice…

It’s difficult to keep this in mind when you want to use newer technologies to make your life easier. CSS3’s rounded corner declaration or shadow facility would be great, but what happens when you meet a browser that doesn’t support it? As long as the contrast of text to background is suitable and the corners are not an integral part of the design then they will just have square boxes and normal text – something that doesn’t affect their experience too much and won’t affect the usability in any way.