Articles Tagged ‘HTML5’

Sketchnotes from #LWS3D – A 50-line WebGL app

After a summer break, London Web Standards was back with an evening of WebGL with Ilmari Heikkenen from Google and a short demo from Carlos Ulloa of HelloEnjoy. Sketchnotes are below

Carlos Ulloa of Brighton-based HelloEnjoy showed off two demos that he made using Three.js and WebGL. The first was HelloRacer, an interactive look at the 2010 Ferrari F1 car that you can even drive and do handbrake turns in. The second demo got it premiere at LWS, an interactive music video for Ellie Goulding’s “Lights”. Honestly, it was extremely cool, on a Ro.me “3 dreams of black” scale. It’ll appear at the linked URL in the next week or so. There’s a great Q&A session on the London Web Standards blog of the event for more detail on how they did it.

Ilmari Heikkenen showed the gathered crowd how to make a basic WebGL app using Three.js in about 50 lines. He showed off all of the components that you need: a renderer, scene, camera, mesh and lights (and shadows). He went into more depth about vertex shaders and fragment shaders, the GPU effects that make everything look a lot more real.

Ilmari gave examples of a few uses, including games, 3D bar charts and scatter graphs. He then started animating all of these, including a 10,000 point scattergraph that moved in real-time. Finally, he demonstrated a loader for Collada meshes (supported by Maya) and brought in a monster that with a few lines of code started walking around the screen.

Overall, it was a great introduction to the subject, one worth a lot more of your time.

Ilmari’s slides can be found on his blog.

Responsive web design in practice: making Steve and Emily’s Wedding.co.uk

Over the last few months I’ve been making a web site for my wedding. Emily (my fiancée) and I didn’t want your run-of-the-mill wedding website, hosted by someone on an unrecognisable domain (for example, ewedding.com or gettingmarried.co.uk sub-domains). I wanted something that I had control over, that I could make as the perfect website for us, not a nice template that thousands of others have. We wanted something personal.

Secondly, these pre-packaged themes aren’t suited to modern web standards. They just-about work on small screens, and quite a few of them use flash, or they take 5-10 seconds to load (lots of people, heavily shared servers, you do the math). Don’t get me started on the ones that play music in the background.

So I started with a solid foundation of responsive web design and HTML5. This is how I did it.

Steve an Emily's Wedding homepageThe spine of this site is:

WordPress
I used wordpress because it’s easy to make great themes quickly. You’ve got full control of the output in a simple CMS. Job done, but for one thing: the default theme doesn’t use HTML5 semantics.
I took the WordPress html5 boilerplate from Jeffrey Sambells and used that as my base, giving me a good template for responsive web design.

320 and up
The choice of layout framework, 320 and up, comes from seeing Ethan Marcotte present at Future of Web Design, showing off the Boston.com re-design. I thought it was a wonderful talk and seeing how a site responds to screen size and context on such a high profile site made me rethink my views on responsive design. I used to think that for large, image-heavy sites, it just wasn’t economical to make a site work with media queries.
It’s a change in mind-set to design for mobile first. Thinking like that, instead of retrofitting a smaller design onto your UI, makes the whole proposition a lot more appealing. Andy Clark took this concept and made a framework out of it, and that is 320 and up.

320 and up works on the principle that you code a mobile site, and layer additional layout on top with media queries for each of the sizes you want to support. Coding this way also makes you very aware that the content is very much the purpose of the site, and that nothing should be left out, no matter what screen size you’re on.

Adding 320 and up to the HTML5 WordPress baseline wasn’t as easy as I’d have liked. No offence to Malarkey, but you don’t need all of the 320 framework to make a great site, so I cut a number of the hacks out and updated the respond.js library. Still, it solves many of the gotchas for you, so use it :-)

320 and up has these screen size stops built in: 480, 768, 992, 1182, and a high-dpi option for retina displays . For my this site, I added in 768 and orientation: portrait to deal with iPad portrait mode problems. It’s up to you what stops you use, but these worked for me. If you want to support the galaxy tab and other screen sizes, more media queries are easy to add in.

Steve and Emily's Wedding at 480px
Steve and Emily's Wedding at 1024px
Steve and Emily's Wedding at 1200px

The Design
There’s a lot of CSS3 that’s gone into this site. The background and header uses CSS3 multiple backgrounds to allow the layout to flex without the overhead of another div to layer the extra backgrounds on. Note, I did chicken out and add those extra divs in as it just didn’t look as good on IE7/8 and that’s what 30% of people are using on my this site.

The font choice was very important for me and Emily, and FontSquirrel came to the rescue. It’s got a great selection of script fonts that just aren’t available in the standard set that comes with computers these days. Text shadow adds to the effects but isn’t essential, so it doesn’t look out of place on IE.

My use of box shadow is basically in place of borders. It makes the whole theme pop off the page with slight shadows and a red tint that matches the theme really well. However, box shadow on the iPhone and small screen devices slows down scrolling, and should be used sparingly. Lovingly, responsive web design lets me turn it off for small screens :-)

There’s lots of other little things, like using CSS3 selectors so that class names don’t have to be used all the time, and some nice stuff for the first letter, and also border radius (as standard).

Performance
The site uses appcache to speed up the site loading, and it makes a massive difference. The cache is around 1MB, that’s data I’ll never have to download again. It works on all of the latest browsers and mobiles (where is makes the most difference). I can’t recommend it enough.

For the useful information section, I used local storage to keep the different sections open/closed so that it’s the same when you come to the page next time.

Site performance

Summary
In summary, this site has allowed me to showcase responsive design, mobile first, lots of CSS3 and make it work in IE7/8. Take a look at the source code, and learn. Oh, and wish us well on our wedding :-)

The Limitations of WebSQL and Offline apps

Web applications are the next big thing in the web. Being able to take web sites and make them run alongside native apps, having them work offline and perform just as well as their native counterparts is the next step along the road. As usual, with all new technology, there are some limitations.

There are three pieces of technology that are combined to make a web app: app caching, local storage and a web database technology.
App caching tells browsers what files to store offline and retrieve from disk. These are permanently stored until new instructions are received, unlike traditional caching which works until the cache is full, then starts removing files.

Limitation 1
In iOS 4.3, app caching for offline web apps is broken and does not work.

Local storage is for key/value pairs of information. It’s for simple things like settings and values that need to be retrieved quickly. It’s been called “cookies on crack” before, but it’s really just a very fast dictionary for simple data.

Limitation 2
Depending on your browser, localStorage will keep 5-10MB of data, the equivalent of 200,000-500,000 characters. If all you want to do is store small serialised JSON objects that aren’t related, use this.

Web databases are client-side data storage for larger amounts of more complex data. Whilst you can make web apps with just app caching and local storage, it’s not going to be very interactive, or the data may be unstructured, or there will be lots of Ajax calls to fetch data. Web databases are where this technology gets a bit dodgy.

Originally, there was Google Gears, a plug-in which brought a SQLite database to help web apps run offline. This was then standardised into the WebSQL module and developed as a SQL database available through JavaScript. Google, Apple and Opera all implemented it and it can be found in iOS and Android devices today.

Limitation 3
Chrome has a hard 5MB database size limit – you will need to use a chrome web app to remove this limit.
Limitation 4
Chrome doesn’t support OUTER JOIN or RIGHT JOIN statements.
Limitation 5
Debugging is very difficult with large amounts of data as the web inspector isn’t efficient at displaying a thousand rows (and will crash with around 20,000 rows, around 2MB of data).
Limitation 6
Version numbers are not taken into account. Don’t bother with them.
Limitation 7
All calls are asynchronous – if you rely on results at a certain time, be prepared to write a lot of callback functions. Your code can get messy very quickly.
Limitation 8
Performance is sluggish if you don’t batch up statements into transactions.

Even better still, WebSQL is no longer in development, so these problems will remain. Microsoft and Mozilla said they didn’t like it and wanted to used a different technology: IndexedDB.

IndexedDB is on it’s way, but not mature enough yet to be used, nor is it implemented in any of the mobile browsers.

Advice
For offline apps, you’re better sticking with WebSQL until IndexedDB matures.

Hopefully, some kind developer will come along and write a technology-agnostic wrapper, maybe that person will be you, the reader of this article. If you’re thinking about it, let me know :-)

Javascript Fun at London Web Standards #lwsfun

Last night was London Web Standards‘ April 2011 event, Fun with JavaScript. Speakers Rob Hawkes of Mozilla and Seb Lee-Delisle of Plug-in Media came to talk about all the fun stuff you can do with JavaScript, canvas, and HTML5. Sketchnotes for both talks are below.

We were also joined by a man showing us a quick look at Dreamweaver CS5.5 with it’s new HTML5 features. Unfortunately, the software had a few bugs which showed up in the talk, and after being burned by the very expensive adobe software for years, the crowd didn’t take to the UI very well, which wasn’t helped by a low-res projector. Still, it looks like a big improvement over the old version, but I’ll still use Coda when on my Mac.

Rob Hawkes: multiplayer gaming in HTML5

Sketchnotes of Rob Hawkes' talk Multiplayer Gaming with HTML5

Sketchnotes of Rob Hawkes' talk Multiplayer Gaming with HTML5

Rob is a canvas and animation guru. He’s not far out of uni and has a book out this month! He gave a new talk on multiplayer gaming, and how it was possible in HTML5.

Basically: Canvas + Websockets + a server (rob recommended Node.js) = multiplayer gaming on the web.

Rob didn’t go into much detail as to how to do all this, just talked us through the principles of what you should be doing, what you should avoid, how to prevent cheating and simple tricks to improve performance.

At the end, Rob proposed a HTML5 gaming knowledge repository, a community wiki and tutorial site, so that it’s easier for people to learn. Someone at the event will take him up on the offer, so look forward to more things soon!

Rob has a book on Foundation HTML5 Canvas: Gaming and Entertainment for pre-order on Amazon.co.uk

Seb Lee-Delisle: Fun with JavaScript

Sketchnotes for Creative JS visual effects – Seb Lee-Delisle

Sketchnotes for Creative JS visual effects – Seb Lee-Delisle

Seb is a flash guy, but also a JavaScript guy and a graphics guy. He’s so multi-talented that he doesn’t know what exactly he does any more.

Seb has won two BAFTAs (thanks for correcting me Seb!) for some of his BBC kids web sites. He personally runs a javascript graphics workshop and took us through a few things that we’d do if we went on it.

He started with particles, showing us how to do basic (pseudo) physics in canvas and JavaScript. He then broke out his large array of particle demos, showing how complex effects can be produced with very simple code.

Seb then talked about performance, and how bad canvas is at the moment. DOM elements with hardware acceleration is easily twice as fast as canvas, especially on the iPad. The iPad’s saving grace is its touch screen, which can take 11 touch points (just in case we grow an extra finger). Seb created a simple asteroids game using touch events for input.

Seb finally talked about 3D and how using libraries was a great way to go from 2d to 3D very simply. He recommended Unity as a game engine and framework of choice, and they’re building HTML5 renderers on top of their regular OpenGL and DirectX methods. Exciting stuff indeed.