As a web developer, over the years I’ve asked the producers/project managers I’ve worked with “and what browsers are we supporting?” more than once, for every project I have worked on as though its fine to think there are some browsers we just don’t support. We understood that the internet is accessed by a wide range of browsers, it should be accessible and inclusive and project’s content should be viewable for as many people as possible. But, we have a limited about of time and resources and there was only so much graceful degradation and progressive enhancement we could do.
AREA 17 operates primarily out of studios in New York and Paris. But we also have satellite offices in several other parts of the world. At times there can be a nine hour time differential between staff members. Thankfully email, Hipchat, Google Hangouts, Skype, and a few years of practice means this isn’t much of a problem for us. However, I sometimes still have problems with doing the mental arithmetic necessary to calculate what time it is for everyone everywhere else—especially when organising meetings. To try and alleviate this, I built a web app over the holidays that displays all of the primary timezones in which AREA 17 operates so with quick glance you can see what time it is in those places.
On a recent static style guide build I got tired of manually inserting sample code content into
<code> tags; especially as I hadn’t fully made up my mind on exactly what the markup should be. Each change meant I was copy and pasting the new markup into a new window in my text editor and search and replacing the < and > so that it would render as expected in the browser. I see most problems as a Front End problem so I wrote a quick function to do this for me. I’m writing this down and sharing because a quick Google search didn’t reveal any similar functions.
The first time I used jQuery on a website was June 2007; I used it for an image carousel that faded between sponsor logos. During the rest of 2007 and 2008 I used jQuery, MooTools and Prototype.js until settling on jQuery for everything in 2009. And I’ve been using jQuery on every site since. Until now.
Recently a friend of mine and fashion blogger, @inthefrow, asked me if I’d help her determine who her most popular Instagram followers are. I knew Instagram had an API so I assumed the task would be trivial. Of course, it wasn’t as straight forward as I first assumed…
From a sample of 21,239 Instagram users:
- 6133 had protected accounts – thats 28%
- Average number of followers: 843
- Median number of followers: 194
- Average number of people followed: 822
- Median number of people followed: 265
- Average follower/follows ratio: 1:1.76
- 533 or 2.5% are disabled or other wise invalid accounts
About a year ago, Ned proposed the idea of switching our method of displaying icons and other small graphics in websites that didn’t use sprites. He suggested we used individual SVGs instead.
At the time we were making sprites and had become become quite adept at building them; though they were a constant source of frustration. In the middle of 2012 Apple released the Mac Book Pro with a Retina screen, which added new impetus to seek out ways of making sprites appear sharp on high resolution screens. Our first solution was to make double size sprite files and resize them with CSS for high resolution screens. This solved the problem; but gave us more problems. Now we had two sprites to maintain and more frustration.
So an SVG solution was worth seeking out.
It turns out re-rendering or rendering ajax’d into place Pinterest buttons is quite straight forward. Not that you can find this in the Pinterest docs…
Update the way you include the Pinterest js:
<script defer="defer" src="//assets.pinterest.com/js/pinit.js" data-pin-build="parsePins"></script>
defer defers loading of the script until after the page has loaded. The important bit is the
data-pin-build attribute. This makes the
pinit.js expose its internal
build function as
parsePins on the global
And then to use:
// parse a DOM element window.parsePins($("#element")); // parse the whole page window.parsePins();
The function is looking for a DOM node and not a jQuery object which is an array like object; so selecting the DOM node the jQuery object wraps is needed.
And thats it.
For years I’ve been saving out graphics for websites as either 8-bit PNG or 24-bit PNG. Photoshop always gave me just those two options and so I assumed they were the only two options; if we needed fully transparent backgrounds we used 24-bit and if we didn’t we used 8-bit. IE6 had trouble with 24-bit PNG with the alpha channel so we often just fell back to 8-bit with 1 colour transparent backgrounds. And thats the way things where.
Is it time we build websites for retina displays first and then, maybe, optimise for sub-retina displays afterwards?
Much to my annoyance, lightboxes have become pretty ubiquitous on the internet. I’m bored of seeing them and bored of making them. And the more I use my phone for viewing websites, I’m frustrated that the vast majority of sites use them regardless of the device accessing the site.
This week saw the Clone Wars animated series air its 100th episode. Much has been written about this series; after the mixed reactions to the prequel trilogy this series has given new life to the franchise to viewers young and old.
The English chain restaurant Pizza Expresshas long been praised for its email campaigns (well for at least over a year now, so file this under “not new news”). The praise comes largely because of how the emails appear with images disabled. From my understanding of how email is read these days, images being disabled is an increasing problem.