in Photography

Going Lo-fi

While I’ve been stressing over the details of going contractor my photography’s been quietly ticking over; I’ve done a couple of nights at Club Debbie and some crowds-eye shots at a couple of drag shows and conferences. I’ve found even half-assed conference shots have legs, probably down to the kind of people on Flickr.

I’d seen Dan Rubin give a great talk at MK GeekNight so I jumped at the chance to attend his workshop in cameraphone photography organised by Zoe Timmers, I even joined Instagram to better take advantage of it. I was pleased / surprised / intimidated how much good stuff is on there, showcasing the kind of eye I admire and aspire to.

Though I think I’ve gotten better at club shots I still suck at composition and portraits, and while I’m comfortable editing on the computer it’d be great to be better at setting up the shot: there were some nice photos of Italy but finding them in the 1000+ I’d taken was laborious.

The workshop was a really lovely day out; Dan and Zoe giving great tips on seeing the shot, looking for details in the everyday, what kind of editing is possible, which apps to use, and insights on the workings of Instagram, its community and hashtags. It was funny being the only non-iphone user in the group – slumming it with my humble Moto G – Dan giving periodic Android-specific asides just for my benefit.

It was great meeting everyone chatting over lunch and editing pics in VSCOcam, wandering around the beautiful Town Hall Hotel who kindly served as hosts and venue, and along the canal to Broadway Market in the sun. I’m so glad I went and I’ll be keeping an eye out it for future photowalks and such.

Follow me on Instagram, I might get the hang of it eventually!

I’ve been on Flickr since January 2005, way pre-Yahoo. Never been a power user, but I’ve been a paying member for most of that, after all even when the site was languishing without new features for years it still worked better than its contemporaries. The most awkward thing about it for much of that time was simply logging in; it was a fairly regular occurrence that I’d forget my UN/PW and just give up because getting a reminder/reset through was such a palaver, so it was a happy relief when they added one-click sign in a few years ago. I even made another account to celebrate!

So I’m pretty gutted when I check my Flickr today and find this:

Sure enough, my first (forced!) encounter with Yahoo UX is a sign-up form with a submit button that moves from under your mouse when you click it. It’s beyond ridiculous. Did nobody try this?


I’m so angry right now. Can someone just do a photo site well please? I’ve actually just joined Instagram to work on my sucky pre-camera composition, and twitter are upping the anti with multi-picture posts, but after all these years there’s still nowhere that does it right.

in Recaps

Gone contracting

I’m now a contractor! Through Cogs it didn’t take long to find somewhere that needed extra hands on deck, and after months of pure CSS on a big team it’s been a nice change of pace doing all the LESS CSS, JQ, PHP/HTML as the only front-ender on the project. On top of that I’m getting my head around Drupal, finally using GIT and Vagrant professionally and starting out as a newbie Mac user, so there’s been a lot to learn. I think that’s a major advantage to contracting though; being almost permanently out of my professional comfort zone could be great for me.

Not so great has been the finance side of things; I’m still waiting for a couple more bits and pieces before I can even send my first invoice! I should get a professional webpage sorted too, or maybe a total site overhaul with that new angle. I like my current photo page but it doesn’t get a lot of use, and I’m ambivalent to the bio page, I need a better nexus page that I can link everything to.

Also business cards! What do people actually put on those, apart from that nexus/homepage URL?

There’s been debates up and down the internet about the pros and cons of responsive vs adaptive vs native apps, so it’s easy to get bogged down by buzzwords and semantics. Instead, answer some fairly simple questions about real choices and whether to use RWD will answer itself.

Real-world choices

How many layouts will you design?

A few years ago everybody built sites on a 960px grid, and probably most still do.

Designing 3 widths that correspond to “mobile”, “tablet” and “desktop” views is a common approach, though the lines between them are increasingly blurry.

Grids: fixed or fluid?

Giving your layout fixed widths suits the static tools used by most designers and allows for pixel-perfect development.

Fluid grids and elastic design; swap pixels for percentages and make your design stretchy!

How are you going to work out which to show?

Show the exact same content to every device, regardless of size.

Tweak styles, typography and layout with CSS media queries and use feature detection to pull in richer content when the browser can handle it.

By detecting what devices are being used you can infer screen size and capability, however this needs to be done on the server side: serve up entirely different code depending on the kind of device your customer is using

Old school

Responsive might be the new shiznt, but it’s not what you’re looking for. On large screens your content will sit in a centred column, and on small screens zooming and scrolling is necessary.

Classic Responsive Web Design

You’re looking at using a simple layout with some CSS tweaks that’ll elegantly flow into any container that the web of things can throw at it. Consider capping your design at high and low widths, so things don’t get unpredictable at either end of the scale, and be aware that the fluid nature probably means you’ll want to design this partly in the browser. This is a popular choice for mobile-first design or simple content sites like blogs.

Over engineered?

Given you’ve only got a single fixed layout to display, there’s probably no point using device, width or feature detection.

Over engineered?

Although media queries can be used to tweak styles, if you’ve got one design you’ve got one set of mark up so there’s little point in a server side solution.

Liquid layout

Your super-stretch approach predates RWD, but using a fluid grid means at least partly designing in the browser, and depending on your content things can get strange on very narrow and very wide screens, so it’s so probably only useful for a very masonry-like or image-heavy grid layout, lest an awkardly long word break your layout.


If you’re trying to show multiple views you’re going to have to distinguish which are to be shown where, for example by detecting width, browser features or devices.

Server side solutions

Is your site just too heavy to work on a phone? Does it have radically different requirements between desktop and mobile? Serving up different sites to different devices can be a legitimate mobile-friendly solution. However it’s a tailored back-end solution instead of a front-end one-size-fits-all, so it’s not responsive. There’s a few downsides to this approach: it requires a list of all devices which requires constant expensive maintenance, it’s trickier to maintain content parity due to different codebases, and you’ll likely have doorslams as desktop links are picked up on mobile browsers or vice versa.

Also it should be noted that the separate sites might themselves be responsive, for example an “m-dot” mobile site might work on both mobile and tablet devices.

Modern Responsive Web Design

As far as RWD is concerned you’re doing everything right: combining two or more layouts with CSS media queries and progressive enhancement for a rich device-agnostic solution. It’s not easy though, the fluid sections that go between static designs should be designed in close collaboration with the designers. Alternatively abandoning the outmoded page-centric approach and instead design modules with a separate content hierarchy and design the layout directly in the browser!

Mind the gaps!

Targeting certain “best practice” widths that in today’s device-rich market are essentially arbitrary is risky. New form-factors and screen resolutions arrive regularly, they all need to work in portrait or landscape, and there’s already a lot of overlap between mobile, tablet and laptop. It’s fairly likely that a given device won’t your target widths and you’ll need to zoom or scroll as with a single width site.

The plus side is little-to-no designing in the browser, but a semi-fluid approach would be more extensible.

CSS media queries changes up the layout and typography depending on browser widths; there are many examples of media query driven sites, one of my favourites being The Great Discontent. The caveat is that it’s not suited to serving different content or radical redesigns as everything needs to co-exist in the page simultaneaously and reliably, so can be expensive in terms of developer time.

With JavaScript feature detection like Modernizr you can pull in rich imagary or video where appropriate. This progressive enhancement is a great solution when you need to deliver working pages to every browser (even edge cases like kindles and wap phones). Some examples of large responsive content- and accessibility- driven projects include BBC News, The Guardian online, or the new Entertainment Weekly site.

It’s that time of year again: reflection, resolutions, annual report cards.

2013 was pretty good! Did most of last year’s aims, found an awesome flat with Scott and Bob, improved physically (then threw it away over christmas), went on holiday to Florence, got a new camera and built up a flickr stream I’m fairly proud of, learned a heck of a lot at VML London and over a dozen conferences, workshops and meetups,and rebuilt this site from the ground up (AGAIN) with new technologies and in half the time of the last refresh. The only aim I failed was saving money! Oops.

Aside from the obvious of improving social, financial and health, other things I’m looking forward to working on in 2014:

  • Professional: I’ll continue going to conferences (already got a couple lined up), but the big change is I’ll be crossing over to contracting! I handed in my notice yesterday so I’m pretty excited about it, especially getting to see how more agencies and web people tick.
  • Writing: An unexpected twist of 2013 has been that these self-reflection posts are now in the minority, instead I’ve been writing up web conferences and ordering my thoughts on the dark place where front end dev meets entrenched agency process. One of my posts even got taken up for guesting elsewhere, which was nice! More to come.
  • Photography: I’d like to learn more about portraiture and simple studio stuff, pap the Edinburgh Festival and maybe Glastonbury, and try to add gigs, festivals and new clubs to the stuff I already do. It’d be great go to a photography workshop too, if there’s some webconf crossover

It’s going to be (another) interesting year!

in Interwebs

RWD 101

Over 2013 I immersed myself in the emerging discipline of Responsive Web Design, reading dozens of articles on it, spending a day at a workshop and another at a conference about it, building a half dozen websites with it, and writing pages and pages of notes on it all. It’s been an interesting journey and I’ve made a few U-turns on what I thought would be best practice, but it’s time to boil my thoughts down to a post or four. First up what RWD really is:

Before the buzzword, the responsive Origin Story:

The ideas behind responsive web design were initially set out by Ethan Marcotte in his 2010 talk at An Event Apart, which is well worth watching as it’s proven seminal. Boiling it it down to practical axioms, the main tenants were:

  • Media Queries: A method of delivering different CSS rules to pages of different width, allowing page layout and typography to change to fit different sized screens without changing the content or the HTML.
  • Flexible images: Images online have historically been fixed widths to aid browser performance, but thanks to browser evolution and some new CSS there’s a simple way of making foreground images squishy, and another to make background images stretchy, so either way you’re golden.
  • Fluid Grids: Instead of using pixel values for arranging layout, use EMs (a measure relative to font size) for heights and percentages for widths. Very quickly you’ve got a fluid layout that responds to browser widths.

Riding the wave of the mobile explosion the idea of Responsive Web Design took off in a big way, but the meaning’s been clouded, overused and buzzwordised. It started – and at its core still is – a design philosophy, a few CSS tricks that enable a new kind of fluid design. The likes of Jeremy Keith have been evangelising the screen-size independent approach for a decade now, but designing liquid layouts and fluid grids can be difficult without a very good understanding of web technologies and it’s hard to represent in Photoshop; an awkward and ill-suited tool for representing any non-static design.

Four years later that mobile explosion might be old news but it’s only becoming more diverse with every new phone, tablet or “phablet” released. It’s self-evident but often overlooked that mobile devices are increasingly the first choice for social: facebook, twitter and emails full of links being shared. Those links don’t open apps, so sites need to look decent on these multi-platform multi-resolution devices.

RWD and fluid design offers ubiquity, flexibility, content parity and cross-device future-friendly thematic consistency. It’s about generalisation not optimisation. It’s less about the mobile, tablet and desktop views, more about the gaps and the overlap between them that an increasing number of devices fall into. It’s not a silver bullet; you need great design, a solid performance strategy and probably progressive enhancement to deliver the goods. It’s also not just something for developers to worry about.

Next on RWD, navigating the sea of buzzwords to work out if Responsive is really what you need!

in Interwebs

Waterfall legacy

I recently wrote about the specter of the “infallible” PSD hanging over the development process, and how it can be damaging to have the success or failure of a site dictated by something that describes a website so poorly. It was taken up by Typecast (which was awesome), edited a bit and posted on their blog . It was interesting to read the comments, though they mostly the missed my point a little: they were discussing using Photoshop as a tool, while I was talking about the PSD specifically as a static artefact, after sign-off and so when the design has stopped.

But that got me thinking: why is that a given? Though nobody argues that content shouldn’t inform the design, invariably design is frozen at sign-off, development stops at go-live, but content can change at any time. Similarly few would say that design should have no input on the subtle UI interactions that make for a tight UX, but as that will never be detailed in a static PSD for sign-off, under the current system it’ll never be in scope.

I don’t know how industry-wide it is or whether it’s a feature of a certain kind of agency, but it seems process dictates that once the look of a site is sold to the client, the designers need move on to selling something else. We have sprints and stand-ups and all the trappings of agile, but outside the umbrella of development the yoke of the waterfall stays with us.

in Interwebs


I went to yet another conference last week, but this one was a little different. For one thing it wasn’t a web conference! Mostly not. At Geekyconf there were a load of talks on a load of subjects as well as games and food. It was more about delight than take-homes and it’s hard to draw together a writeup, so I’ll just point to a few pics I’ve put on my Flickr and touch on some highlights:

Expectedly good:

  • Sex, Love, Dwarves, Bacon
    Dr Esther MacCallum-Stewart
    About “Love” or emotional attachment in computer games, which is hard to manufacture, basically, giving odd abstractions like how the affections of most NPCs can be bought with the right bribe.
  • The Wonders of Stuff
    Zoe Laughlin
    Materials science. Invisible balls, gecko tape that only sticks to smooth surfaces, regenerating concrete, optic concrete; SCIENCE!
  • Scandinavians hitting you with sticks
    James Wallis
    Larping, like tabletop RPG, is something I like to think about but could never provide the level of commitment needed, so it’s nice to hear other people talking about it so knowledgably.
  • How to turn Drunk Ideas into Books
    Mr. Bingo
    That guy with the nasty postcards. Seen a similar version of this talk a couple of years ago but it’s still funny.

Unexpectedly good:

  • Omnibus Racing for Beginners
    Simon Abernethy
    Did you know there used to be such a thing as pirate buses? And because individual buses competed, they used to race to stops? RACING PIRATE BUSES.
  • Determining the fastest person on two wheels
    Edd Sowden
    I begin to switch off when cycling’s brought up as I can’t even ride a bike! But Edd gave an excellent collection of nerdisms and infographics.
  • On The Counting Of Sneezes
    Peter Fletcher
    Hillariously deadpan talk on a frivilous exercise that boiled down to a few profound reflections.
  • Five Facts About Smell
    Alice Bartlett
    Fun, funny, interesting. Explaining how smell works. The answer? NOBODY KNOWS.

It was great, so I was surprised that the attendance seemed to be pretty low. Maybe the vague premise of geekdom is too hard a sell? The (surprisingly lovely) hall could have held double or triple the attendees and looking at their website some speakers, sponsors and caterers must have pulled out or been downsized, leaving when MAC met CHEESE to feed everyone and Giddy Up Coffee to dole out continuous coffee. Maybe it wasn’t a bad thing though as both were really excellent (and free for attendees).

Bottom line is I was in dev / gamer / geek / spicy-mac-n-cheese / deep-fried-oreos / good-coffee-on-tap heaven and I hope it happens again next year!

in Interwebs

Full Frontal

Earlier this month was Full Frontal, a javascript web conference in Brighton. It’s been going for a few years but this is the first I’d attended. Though I’m not as hardcore into JS as many front end devs, I actually found it much more accessible than the jQuery UK conf earlier this year. Basically it was excellent, with good coffee, fab freebies, a nice vibe and above all excellent talks.

ES6 UNCENSORED by Angus Croll

I’m not so much a programmer so I didn’t get the fine points of this, but thanks to clear examples it was easy to see that Angus was excited about the upcoming ES6 JS upgrade enabling terser syntax for a few common tasks, and I do love me some dry code. Honestly though my main take home was that he gave a great talk around a stutter, which made my public speaking anxieties seem awkwardly trivial.


Robots and rabbits and live demos galore! Andrew builds and programs robots to interact with his super cute rabbit. It didn’t think much of the laser pen robot but was pretty keen on the automated food pellet dispenser. Things got real when he fired up the quad copter controlled with an xbox controller, got it send back a video feed of the audience, and then used facial recognition technology to replace everyone’s faces with troll face. Awesome. Oh, right, yeah and it was all done through Node, which is cool. Soon we’ll be running drones from our browsers!


Seems a conference isn’t complete these days without a talk on the importance of mobile, and this one had all the standard impressive charts and stats about the growth of mobile. Joe took it a bit further however, talking about the extended mobile ecosystem from tablets to wearable devices wearables without a screen, and even cars. It tickled me to think of a “mobile device” being so large but apparently cars with built in connectivity is already fairly standard and becoming more so.


This talk was right on the money as I’ve been pretty reluctant to use JS on mobile sites due to performance issues, but apparently mobiles being slow to parse JS isn’t an issue anymore! It was also nice to hear that we shouldn’t waste time modularising as I’ve never gotten on with Require. Lots of easily digestible takehomes, great stuff.


It was funny after a full day workshop on the exciting and fast-moving word of chrome dev tools to hear one of the speakers bemoaning the state of in browser inspectors, though superficially they’ve not really changed since IE dev tools back in the mid 2000s. Still, even relying on Chrome can leave you in hot water when it comes to developing for other browsers and asking devs to actually develop in chrome can be controversial, a dev’s choice of IDE a uses is super partisan, though Sublime Text seems to have been in the ascendant for a while, many will never leave Eclipse, Visual Studio, *cough* Dreamweaver. Anyways his idea was simple, and the solution he’s working on is it connect up Chrome’s api to the IDE and various browsers. He live demoed manipulating a FireFox DOM from chrome devtools to many gasps of delight from the audience, followed but a too-quick plug of his project RemoteDebug.


As a CSS nerd I’ve marvelled at loads of these migical JS-free animations on Codepen and such places, but any time I looked under the hood I ran a mile; waffly code and endless lines of keyframes scares me. It seems I need to take another look though because the special sauce here (apart from some basic trig) is getting around that scary verbosity with SASS, and almost programmatic shortcutting. Definitely something I should tinker with.


Angelina Fabbro
Some mozillians making a framework of mobile app widgets called Brick (not X-Tags). I think I was suffering from a combination of some cake-pop related sugar coma (I might have had 3) and CSS animation mind-splosion because most of this drifted over the top of my head.

TIME by Jeremy Keith

Jeremy Keith’s been one of my favourite speakers as long as I’ve been going to these, and it was a real treat to see him give a lovely talk about the relative ephemeral nature of web work, cut with an old video about powers of ten. The main points were that the old adage about stuff on the web being there forever is just patently false, that we should be thinking about the longevity of our work, and at the moment the closest thing we have is html, mostly because it gracious error handling and human readability. which makes me worry a little about my blog: it totally falls apart if the back end fails. Maybe I should be looking into transferring to Jekyll?

So yeah! One of my favourites this year (the others being Ampersand and Responsive Day Out). Recommended.

As a long time Front End Dev I’ve used Javascript a lot but my focus has always been CSS and I often find debugging JS awkward. So naturally I jumped at the chance to go to a workshop on debugging by Remy Sharp, one of those names that keeps popping up in the field of JS. (You wouldn’t think it to look at him but he’s been a developer since the 90s.)

Though tools like Weinre or Dynatrace were mentioned, “Thy tools” turned out to be mostly Chrome Devtools, but even with that narrower focus there was loads to get through. Remy rattled through dozens of these tips and tricks almost faster than I could follow!

Debugging tips

  • Disable plugins and cache, use incognito mode and create a test user for a clean bug-free slate.
  • Develop right in devtools! Right-click > “map to file system resource” to be able to save to disk!
  • Shortcuts: ctrl-o: open a file, ctrlshift-o: open a function from that file and in DOM inspector press H to hide a given node, clicking “{}” prettifies the JS.
  • For element-specific breaking, right-click simply write click on it and select “break on”. You can also set event listener breakpoints in the right hand nav of the Sources tab.
  • Hover over functions, variables etc to get more info on them.
  • Chrome inspection works both ways: type simply type “inspect this” in the console to jump it’s location in the dom. Genius when you’ve got scope issues.

Bleeding-edge Canary devtools

Once you get past the obvious much can depend on what devtools you’re actually looking at; Chrome autoupdates regularly but the latest beta features are only found in Canary, and even then there’s additional experimental features that are switched off by default. For example to make devtools ignore certain files, you first need to navigate here in Chrome Canary and enable developer tools experiments, then go to Settings (the cog icon) > Experiments (left hand nav) and click “Enable frameworks debugging support”. Close and open the inspecter, head to settings again and under “General” you should now have an option called “Skip stepping through sources with particular names”, where you can type “jquery” or whatever other plugins you’re not interested in debugging. Simples!

Bottlenecks to watch out for.

Connection speed
The network tab is a pretty easy one to parse, looking for too many simultaneous http requests, too many in general, too much content in terms of file size (normally images) any 404s or text files not not g-zipped. Basically you want to streamline everything so you get a quick “Time to glass” because if nothing shows people lose interest fast.

Local memory
When the browser gets slower over time it’s probably down to memory leaks, caused by programmatically setting more and more event listeners and variables. In devtools go to Timeline > Record > Memory, play with the page and watch memory go up. When you force garbage collection it should go back to where it was. For a more detailed view go to Profile > Heap snapshots > Compare snapshots and click around looking for red highlights which mean something garbage collection couldn’t get rid of because they’re still being referenced in the js.

“Jank” is something close to my heart: Google’s name for visual distortions caused by animations not keeping up with the 60fps refresh rate, particularly on scroll. It’s recommended to use setTimeout 16ms, or better yet requestAnimationFrame whenever doing something onScroll. You can check it with Timeline > Frame to see if things are cool. Another problem can occur when small animations cause the entire page to redraw, which can be checked with settings > general > rendering > click things to show what’s redrawn. The only solutions to this that I saw were hacks though, namely selecting an appropriate frame and giving it the style transform: translate3d(0,0,0);

Commands cheatsheet

  • $$ grabs all elements that match
  • $0 grabs the element you just clicked
  • v$_ gives whatever was last returned by the console
  • $_ + copy copys…
  • console.trace() find what calls a thing
  • console.clear() clears, obvs

At the end of the workshop we split into groups and used what we’d learned to check a site randomly allocated from a collection we had submitted; it was surreal to have people baffling about a site some colleagues at VML had built, but then it was also bizzarre how totally thrown a couple of people were by responsive sites. “Whoa! It looks different!”? I’m disappointed if a site doesn’t! I know that it’s a web devs’s conceit to jiggle the portal size on any unfamiliar site but I didn’t think it was purely a front end thing…

Anyways, lots of tips, lots of take homes. It only went too quickly, I honestly could have done with double the time!