cake on tap

Dear diary

(Cross posted from the company blog at MetaBroadcast)

Hello! I’m Dan. I insist I’m not really a programmer, or a designer or even a photographer, but I’m probably all three. My crippling impostor syndrome battles daily my addiction to creating Stuff, so I compulsively whittle words, code and photos until they’re so supernaturally shiny that they glow with an otherworldly light. And then I decide that they’re rubbish. Enough about me though, because I’ve joined MetaBroadcast to eat cake and make things pretty.

It’s been a surreal experience being an agency side designer/developer joining a product-lead company of software developers. MetaBroadcast is a strange land preoccupied with purple and pink, where we don’t use sass and html is templated in with javascript. We also seem to have an entire team dedicated to keeping the building stocked with cake.

The MetaBroadcast crew stop for refreshment

On top of the culture shock I’ve also gone from full time to part time and there’s a whole lot to cram into a two day week: from the unfeasibly filling Foodie Fridays, to the Metaversaries, to daily Happy Hour meetings (which I don’t really understand but everyone sounds awfully clever), to the actual work: prototyping cool stuff with metadata.

Happily I also happened to join right before the quarterly away day, which this time featured a fairly chilled putter about central London exploring various alleys in search of the fabled and illusive Seven Noses of Soho which are totally a thing. It was curious and interesting on its own, and once you factor in the sun, okonomiyaki in Russell Square and more coffee and icecream than you can easily deal with; it was a great day out.

Nose hunt!

I’m outside my comfort zone, I’m learning fast, and I’m making cool stuff. Once I put Sass in all the things and get the hang of saying no to cake it’s going to be a grand old time.

Adventures in the West Country


Leap of surewhynot

It felt surreal to be going back west a couple of weeks after Glastonbury for similar frolics, this time to take pictures at the Bristol Pride after party. I had no idea what to expect but the trip featured loads of odd situations that made me so happy to have gone, like magical scratch-card train tickets, being backstage and getting in Corona’s way, chatting about life on the road with Boogaloo Stu, papping with a legit staff wristband, secret smoking areas, and accidentally being in the security team meeting where they talked about the kind of night it was.

Of course the highlight was papping Harry and Cola as they welcomed the crowds and posed with punters, dressing them up, rubbing them down and generally getting everyone in a great mood. It was a wonder to watch them work; radiating fun, goodtimes, glitter and babyoil for four hours straight. And then two bonus hours of gogo dancing!

Facebook pages (still) suck

I put my favourite snaps on Flickr, the full set’s on my Facebook page, but it might be the last thing I post there. I get orders of magnitude more buzz about an album posted on my personal profile, where randoms can request tags (unlike on unLiked Pages) and it’s not assumed you’ll pay to promote posts. You can’t promote albums even if you wanted to so it all seems pretty pointless. It goes both ways too; I’d love to keep abreast of the photographers I Like on Facebook but they never come up on my feed, instead I get random conversations of people I don’t know and four word posts from a week ago. Sad times.

Bristol was pretty sweet though.

Subcontracting: fun but hard

Dear diary

I’d spent 3 months thinking about going freelance before I made the jump, so I had a pretty good handle on what it would involve. Or I thought I did!

  • Faff with the finances Yes but 3 months worth?? I was living off savings until the financial stars aligned and I could actually get paid.
  • More money True but between time off, a new Macbook Pro and a holiday later this year I’m pretty much back where I started. Damned capitalism!
  • Bring your laptop I didn’t actually see this coming, I bought the MBP for conferences and mobility, but everywhere I’ve worked asked me to bring it along so it’s become my work computer.
  • Hard work Between my freelancer presence being an emergency measure and wanting to impress new colleagues, every day is crunch day. It’s not entirely a bad thing; it’s pushed me to learn quickly and produce some great work. Still, I’ve already burnt out a couple of times, leading to…
  • More time off Yeah, sometimes whether you like it or not! I expected that but what didn’t occur to me is how booking in a holiday or conference ahead of time makes it awkward to get work for that whole month.
  • Stressing about finding work It takes up a load of time and energy in my “days off” which is a waste of time as something usually come up, last-minute and from an unexpected quarter.
  • Variety! Shorter term contracts have been great; I’ve gotten to learn new tools and environments, work across different sites and with different people. As a convenient comparison, before going freelancer I spent 6 months working on a site that’s still not gone live, and in the 6 months since I’ve had 6 projects go live!

I’ve definitely enjoyed it, but I can’t ignore that between pushing hard on workdays and spending restdays preoccupied with finding more workdays, my photography has slowed to a trickle and I’ve stopped blogging altogether. I don’t what to lose that, so when an opportunity to go part-time at a programmer-heavy, in-house, product and prototype lead place with a great ethos I had to go for it, for all those reasons. If I can find a new balance with more places to do part time or small bits of work it could be the best of both worlds.

Besides, the main reason I went contractor in the first place is to expand my horizons, speed up my learnings and eschew the comfort zone, so I’m pretty excited about starting at Metabroadcast tomorrow. To celebrate, I’m blogging and putting up photos for the first time in 3 months! Feels good.

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!

Yahoo suck at UX.


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.

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?

Choose your own RWD adventure


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.

Welcoming 2014

Dear diary Recaps

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!

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!

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.