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.
As digital product engineers, there are a few over-riding principles that govern our work. As an agency, one of the most critical of these is “build once, use many times.” Using existing building blocks for standard features allows us to develop rapidly while leaving budget for the innovative features that will actually differentiate our clients’ product.
In many cases, these building blocks are part of our own arsenal of code, standardized for reuse. In other cases, we evaluate 3rd party services that allow us to introduce production-ready features without the expense of developing and maintaining them.
“[Web] Performance is a lot like plumbing. It’s hard to get people to pay attention to it until something is wrong.” — Tim Kadlec
Performance is an often invisible part of our online experience. As Tim Kadlec notes, most people don’t notice it until something’s wrong. Performance is, in fact, the cornerstone of any successful user experience.
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.
For years we were using Compass with Sass with our product, Krrb, to make our lives (mine at least) a bit easier:
- no browser prefixes to take care off
- cool shortcuts
- easy image sprites generation
However, there were still performance issues.
Compass is huge and take lots of time to compile—from five to eight seconds for each deploy. So I decided to get rid of it completely.
Implementing an analytics tool for analyzing site traffic and basic user behavior is pretty easy these days. For most people Google Analytics will work just fine — it’s free, it has a great interface, and it’s trivial to implement.
At Krrb our needs are slightly more complex. While Google Analytics supports the majority of our traffic analysis, it doesn’t give us everything we need.
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.
Kohana provides a nice exception handler (and an error handler that transforms errors into exceptions using PHP’s ErrorException class) which displays all kind of useful information in a development environment.
In addition to the error/exception related information, you also get environment-specific information that can help you troubleshoot your application : path of your application, php extensions, server software, and so on. Of course, it is always bad to display this kind of information on a live website.
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.
Why build something when their is a web services for it? Over the years, more and more web services have offered the ability to add functionalities to the apps we create so that we can focus on the core business. But in doing so, we often find ourselves in a situation where our data is spread across multiple services.
Syncing data manual is tedious and doing direct API integration takes time away from working on the core services of the apps we create. And when we want to sync data between two web services, direct integration is not an option. Until now….
If you have OS X Lion installed, there’s a small trick that will allow you to switch to HiDPI resolution display modes. It doesn’t work on the MacBookAir because the screen is too small and the resolution will drop below the minimum required resolution for HiDPI. It works on a MacBook Pro but the maximum HiDPI resolution you can get is 720×450. However if you are on an iMac or have a display with higher resolutions, then this trick should do the trick.