When I look around, I see our community spending a lot of time coming up with new tools and techniques to make our jobs easier. To ship faster. And it’s not that I’m against efficiency, but I think we need to consider the implications of our decisions. And if one of those implications is making our users suffer—or potentially suffer—in order to make our lives easier, I think we need to consider their needs above our own.

We hired Charlotte, our first junior developer at Clearleft recently, and my job has taken on more of a teaching role. I’m really enjoying it, but I have no idea what I’m doing, and I worry that I’m doing all the wrong things.

This article looks like it has some good, sensible advice …although I should probably check to see if Charlotte agrees.

The difference between back-enders and front-enders is that the first work in only one environment, while the second have to work with myriad of environments that may hold unpleasant surprises.

Yes!

I feel that the subconscious assumption that a complex JavaScript-driven web site or web app will run in only one monolithic environment is the root cause of many problems front-enders see in back-end-driven web-based projects.

When I speak of designing in the browser, I mean creating browser-based design mockups/comps (I use the terms interchangeably), as opposed to static comps (like the PSDs we’re all used to). So it’s not the design. It’s the visualization of the design—the one you present to stakeholders.

Exactly!

Personally, I think it’s as crazy to start in the browser as it is to start with Photoshop—both have worldviews and constraints that will affect your thinking. Start with paper.

I don’t tend to be a “magic pill” kind of believer, but I can honestly say that embracing progressive enhancement can radically change your business for the better. And I’m glad to see Google agrees with me.

Patty’s excellent talk on responsive design and progressive enhancement. Stick around for question-and-answer session at the end, wherein I attempt to play hardball, but actually can’t conceal my admiration and the fact that I agree with every single word she said.

A look behind the scenes of gov.uk. I like their attitude to Photoshop comps:

We don’t want a culture of designs being “thrown over a wall” to a dev team. We don’t make “high fidelity mock ups” or “high fidelity wireframes”. We’re making a Thing, not pictures of a Thing.

And UX:

We don’t have a UX Team. If the problem with your service is that the servers are slow and the UX Team can’t change that, then they aren’t in control of the user experience and they shouldn’t be called the user experience team.

Mike writes about what it was like being a client for a change. After working with him on the Code for America project, I can personally vouch for him as a dream client:

Clearleft’s pattern deliverables are the special-special that made the final work so strong. Jon Aizlewood’s introduction to the concept convinced me to contact Clearleft. Jeremy Keith’s interest in design systems kicked off the process, and Anna Debenham’s fucking rock star delivery brought it all home.

Some great thoughts in here about web development workflow and communication between designers and developers.

I believe that the solution is made up of a variety of tools that encourage conversation and improve our shared lexicon. Tools such as styleguides, pattern libraries, elemental and modular systems that encourage access not only by developers, but by designers, shareholders and editors as well.

Like Drew, I’ve noticed some real hostility to the idea of progressive enhancement recently. Like Drew, I don’t really understand where this attitude comes from. It’s not like progressive enhancement prevents you from doing anything you would do otherwise: it’s just another way of approaching the way you build for the web.

I hope I’m wrong, but I suspect that some developers are letting their tools dictate their principles—the tail wagging the dog (where the tail is Angular, Ember, etc.).

Craig recently had a piece published in the New Yorker called Goodbye, Cameras. It’s good …but this follow-on piece on his own site is truly wonderful.

Read. Absorb. Ponder.

Being close to the network does not mean being on Facebook, thought it can mean that, too. It does not mean pushing low-res images to Instagram, although there’s nothing wrong with that. What the network represents, in my mind, is a sort of ledger of humanity. The great shared mind. An image’s distance to it is the difference between contributing or not contributing to that shared ledger.

Here’s a heartwarming tale. It starts out as a description of processing.js project for Code Club (which is already a great story) and then morphs into a description of how anyone can contribute to make a codebase better …resulting in a lovely pull request on Github.

This is the talk I gave at the border:none event in Nuremberg last month. I really enjoyed it. This was a chance to gather together some thoughts I’ve been mulling over for a while about how we approach front-end development today …and tomorrow.

Warning: it does get quite ranty towards the end.

Also: it is only now that the video is released that I see I spent the entire talk looking like a dork with a loop of wire sticking out of the back of my head.

Alex starts with a bit of a rant about the phrase “semantic HTML”, which should really just be “well-written HTML, but there then follows some excellent thoughts on the emergence of meaning and the process of standardising on vocabularies.

No matter how many times I go through this journey, it never stops surprising me how easy it is to lose perspective in the heat of a project and forget that there is no difference between a user, a client and a designer. It shouldn’t be so hard to remember that no matter the title, we’re all just people trying to get things done.

It is important that we as developers focus on the right things again. If you encounter a bug, you should not only fix it for your site; you should reach out to browser vendors and web standards people to fix this in a long-term solution. It might cost you a few minutes, but brings a lot of improvement to the whole developer community.

Dr Harry Halpin writing in the Guardian about the crucial crossroads that we have reached with the very real possibility of DRM mechanisms becoming encoded within HTML:

Most of us are simply happy to launch our browsers and surf the web without a second thought as to how the standards like HTML are created. These standards are in the hands of a fairly small set of standards bodies that have in general acted as responsible stewards for the last few years. The issue of DRM in HTML may be the turning point where all sorts of organisations and users are going to stop taking the open web for granted.

Everything old is new again. Ross noticed that many of the themes recurring at the Responsive Day Out hark back to best practices from over a decade ago: progressive enhancement, performance, good ol’ information architecture…

This was the crux of Elliot’s excellent talk at the Responsive Day Out. I heartily concur with this:

Once you overcome that initial struggle of adapting to a new process, designing and building responsive sites needn’t take any longer, or cost any more money. The real obstacle is designers and developers being set in their ways.

I really like Dan’s take on using Photoshop (or Fireworks) as part of today’s web design process. The problem is not with the tool; the problem is with the expectations set by showing comps to clients.

By default, presenting a full comp says to your client, “This is how everyone will see your site.” In our multi-device world, we’re quickly moving towards, “This is how some people will see your site,” but we’re not doing a great job of communicating that.

I really like these thoughts on the importance of design systems for the web. It’s not about providing a few perfect deliverables that won’t survive once they go live; it’s about designing for the unexpected, the unpredictable:

Here’s a really useful case study for anyone who wants to do “guerrilla” responsive design: when you’re handed a fixed-width mockup but you know that responsive is the way to go:

I started by styling up every element, without layout. The result was a fully elastic layout that effectively served as a mobile, or small screen, layout, which just needed some tweaking of horizontal spacing.

Bingo! And this approach had knock-on benefits as it “supported writing component-based, or modular, CSS”.

Mark gets to the heart of the issue with making responsive designs work with legacy Content Management Systems …or, more accurately, Web Publishing Tools. There’s a difference. A very important difference.

Amen, Lyza, Amen. Instead of treating web development for the multitude of devices out there as an overwhelming nigh-on-impossible task, let’s accept the fact that there are certain things that are beyond our control. And that’s okay.

Let’s build on the commonality core to the web where we can. To do this, I think we need to let go of a few things, to lay down our burdens.

Tossing a specification that you’ve written in-house, in secret and already implemented onto a table at W3C, saying “here, standardise this” as you saunter past isn’t a Get Out of Jail Free card for proprietary misdemeanours. And it isn’t standardisation.

An in-depth look behind the scenes of the responsive relaunch of People Magazine’s mobile site that Josh, Karen, and Ethan were involved in. I love it when people share their process and build stories like this.

I don’t really want a label. I hate labels. I loathe the term “user experience designer”, because I still believe that “user experience” is just a fundamental to what you’re doing, and shouldn’t need stating. There is nothing but user experience design if you’re building products for people.

Leisa nails it. The real stumbling block with trying to change the waterfall-esque nature of agency work (of which Clearleft has certainly been guilty) can be summed up in two words: sign off.

And from a client’s perspective, this emphasis on sign-off is completely understandable.

It takes a special kind of client to take the risk and develop the level of trust and integration required to work the way that Mr Popoff-Walker any many, many other inhabitants of agency world would like to work.

This is an excellent idea from Jake: use a preprocessor to automatically spit out a stylesheet for older versions of IE that includes desktop styles (garnered from the declarations within media queries).

If you’re a dab hand with Ruby and you’d like to see this in SASS, you can help.

I had a chat with the guys from Pingdom about performance’n’stuff. If I sound incoherent, that’s because this is a direct transcription of a Skype call, where, like, apparently I don’t, y’know, talk in complete sentences and yeah.

I completely agree with everything Rachel says here. I see far too many projects that start out with pre-emptive conditional comments, JavaScript libraries and polyfills, without knowing whether or not they’re actually going to be needed.