A few weeks back we put OATV.com and it’s underlying code up on GitHub.
At the time, I thought it would serve as a repo for sharing some of the work we’d done in designing our new site. And my hope was that it would be helpful for someone looking to build a site with a similar look and feel.
Then, last week, something happened.
There are some pretty complex testing tools for responsive designs out there. I even see people constantly resizing their browser window using on-screen rulers. The easiest approach to me is just a simple page with a bunch of iframes, like Matt Kersley’s test page. Because I always ended up…
I’ve been pretty bored lately, so I decided to redesign my site and found an awesome social icon set by Alex Peattie (http://www.alexpeattie.com) to go with the new design. The set is minimalistic and really cool! Unfortunately, I wasn’t as happy to work with it as I would have liked to…
ICE is a customizable JavaScript library that will allow you to track changes in any element that is contenteditable, or in a TinyMCE or Wordpress text editor. At this early stage, ICE has some limitations, but we think it is a very useful tool and hope that others will help us expand the project. Patches and forks are welcome at our repository, https://github.com/NYTimes/ice/. An ICE demo is at http://nytimes.github.com/ice/demo/.
The JavaScript InfoVis Toolkit provides tools for creating Interactive Data Visualizations for the Web.
Datalove is the love of communication. No matter what kind of communication. “Let data flow” is nothing else but “keep communication alive”.
Datalove is so exciting! It’s all about the availability of data. What people do with it is not the question. The point is: people need data. Need to get it. Need to give it. Need to share it. Need to do things with it, by means of it.
Datalove is caring about what makes things possible. After that - here come the difficulties. And the possibilities. Datalove is embracing the uncertain.
Sadly, old misconceptions and rivaling interests exist and try to hinder the flow of communication, and thus the datalove.
Learn HTML & CSS is a book about code that doesn’t read like a 1980s VCR manual…
Learn HTML & CSS is not just for programmers, it’s written and presented to make it easy for designers, bloggers, content and e-commerce managers, marketers to learn about the code used to write web pages…
BackboneConf is a two-day conference about the Backbone.js library, large scale JavaScript applications, and JavaScript common sense, featuring a keynote from: Jeremy Ashkenas.
GPU memory management with hardware accelerated CSS transitions.
See that? That’s the difference that GPU hardware acceleration of CSS transitions can make on an iOS device. If you don’t know what CSS transitions are, you might want to stop reading now.
For those that are left, I won’t bore you with how CSS transitions can provide basic animations, or how they can be GPU hardware accelerated on iOS devices, which can make an incredibly low-powered platform like an iPad offer smoother animation than big desktops running javascript.
Instead I’ll run through how Bardot currently does the “next page” trick, and how I’m trying to improve it.
As a caveat, I’m just imparting what I’ve learnt through trial, error and Google - I wouldn’t count myself as an expert on this.
Bardot is built in “pages” and “spreads”. Pages are… er, pretty self explanatory, and spreads are the equivalent of opening a magazine spread (ie two or more pages facing each other). Bardot actually has three piles of spreads *, at any one time you see only one spread on-screen - in the “viewport”. Either side of the viewport are two other piles, and when you hit the “next page” button, the piles all shuffle along one direction or the other.
The mechanism for doing this on most modern browsers is simplicity itself. Spreads in each pile have a particular class (“.read”, “.active”, “.unread”) and to move them around means changing their class via javascript, CSS transitions and transforms do the rest for you. As an aside, that makes quick changes to the animation a doddle (Make it quicker? Tweak the CSS style. Add a 3D flip out movement? Tweak the CSS style).
That all looks fine on desktop browsers, but iOS devices need a bit more help. They’ve got pretty limited processing power, and extremely limited memory, which often ends up with low frame-rates, sudden disappearances, or giving the “tiling” effect you see in the video above. This is especially true when you’re creating something off-screen, then moving it into view (like we are here), because mobile devices are optimised to only deal with on-screen pixels to keep them lean and mean.
To get around that, we can hand off the “compositing” of certain elements to the 3D GPU chip in the iPad or iPhone, which is way more adept at flinging tiles around a screen. You can move an element to the GPU by adding a 3D CSS style to an object (some use “-webkit-transform:translateZ(0)”, others use “-webkit-transform:scale3d(1)”)
In the case of Bardot, I created a style class called “.zippy” with a transform of “translateZ(0)”. When a page-forward event occurs, the top of the “.unread” pile is changed to a class of “.active.zippy”, and the retreating spread is given a class of “.read.zippy”. So “.read” and “.active” are the classes that determine where the spreads move to, and “.zippy” is the class that adds a sprinkling of acceleration.
The question begs: “So why don’t we hand everything off to the GPU with 3D CSS?”. Well, the GPU is also really limited in the amount of memory it can handle, and the more you stuff into it, the more it stutters and you’re back to where you started. In Bardot, one of those spreads could be thousands of pixels in size, it doesn’t take many of those to really bung up a GPU.
The trick is memory management. In Bardot, only the “.zippy” spreads are hardware accelerated, and once a spread is moved off-page, the “.zippy” class is removed to reduce the load on the GPU.
The result is buttery smooth animations in both directions. Simples.
* Note: I’ve tried building systems with a long continuous “conveyor belt” of pages in the past, and although the theory behind that is cleaner (moving a huge track of pages past the viewport), I find working in three piles is easier to manage, especially when you get into dealing with layouts that are many spreads long. A track would becomes tens thousands of pixels wide and you have to deal with big margin offset numbers. Not pretty.
Ben Bodien from Neutron Creations shares how he built an HTML5 audio player for Tim Van Damme’s podcast The Box.
Yellow Boat Paint Texture by L.C.Nøttaasen on Flickr.
This Tumblr theme implements the hatom microformat. The code for this theme is hosted on github here. Please feel free to add to and improve upon the code in any way you can.
The complete source ready to copy straight into your Tumblr customize page can be found here.
See the README file for further instructions.
