Shamefully, I haven’t been doing one-to-ones with my front-end dev colleagues at Clearleft, but I’m planning to change that. This short list of starter questions from Lara will prove very useful indeed.
I really, really like what Ember is aiming for here:
That’s how you get the holy grail of resilience and performance:
Subsequent visits and interactions are therefore nearly instantaneous, because they don’t rely on the network.
I sincerely hope other frameworks are paying attention to this layered approach.
Oh, and I also like this observation:
There’s an age-old argument about the difference between “web pages” and “web apps”. In reality, there’s a continuum between the two.
Depending on how you’re currently structuring your CSS and class attributes, web components might not make all that much of a difference to your workflow.
Charlotte outlines the process she used in creating her talk at Dot York. It was a real joy to see it come together.
Jon introduces a new tool with a very interesting observation: up until now, all our graphic design tools have been imperative rather than declarative…
With our current tools we’re telling the computer how to design the vision we have in our head (by tapping on our input devices for every element on the screen); in our future tools we will tell our computers what we want to see, and let them figure out how to move elements around to get there.
Marvellous insights from Mark on how the robustness principle can and should be applied to styeguides and pattern libraries (‘sfunny—I was talking about Postel’s Law just this morning at An Event Apart in Boston).
Being liberal in accepting things into the system, and being liberal about how you go about that, ensures you don’t police the system. You collaborate on it.
So, what about the output? Remember: be ’conservative in what you do’. For a design system, this means your output of the system – guidelines, principles, design patterns, code, etc etc. – needs to be clear, unambiguous, and understandable.
There’s a lot I disagree with here. I don’t think this pattern library process is very elegant or scalable, and it certainly wouldn’t work for me.
But I’m still linking to it. Why? Because I think it’s absolutely wonderful that people share their processes like this. It doesn’t matter one whit whether or not it would work for me.
Frontend development may have gotten a lot more complicated, but the simple premise of sharing what you’ve learned hasn’t.
I couldn’t agree more!
An engaging look at the history of word processing, word processed by Josephine Livingstone.
Rachel and Drew have been beta-testing Mark’s Fractal project for organising a library of components for Perch’s interface. Sounds like it’s working out very, very well indeed!
Mark has dumped his brains!
Seriously, there is a lot of thought that has gone into this, and it’s just the beginning: Mark recounts the experience that Clearleft has had with delivering pattern libraries, laying the groundwork for releasing the library-generating tool that he has been building.
Watch this space.
Eric asked me some questions and I was only too happy to give some answers.
A look at the tools that AirBnB have made to help them in their design and development process. I hope they’ll share them.
Jon outlines his technique for keeping “the 30,000 foot” view when patterns are coalescing during a project.
See also: Andy P.’s experience of working with Jon this way.
A lovely outlook on designing with progressive enhancement:
There will always be users coming from places you didn’t expect, using devices you didn’t test for.
Myself and Batesy spent last week in Ipswich doing an intense design sprint with Suffolk Libraries. Leon has written up process from his perspective as the client—I’ll try to get a case study up on the Clearleft website soon.
This is really great write-up; it captures the sense of organised chaos:
I can’t recommend this kind of research sprint enough. We got a report, detailed technical validation of an idea, mock ups and a plan for how to proceed, while getting staff and stakeholders involved in the project — all in the space of 5 days.
Linting CSS seems like a very good idea, especially if you’re not the only one writing the CSS. This guide is going to come in very handy when I give it a try.
Well, this pretty much sums up the front-end team at Clearleft:
I’ve often said that at Clearleft, development is always in the service of design. And like Brad, I often find myself defining that work by what it isn’t:
They understand UX principles and best practices, but may not spend their time conducting research, creating flows, and planning scenarios
They have a keen eye for aesthetics, but may not spend their time pouring over font pairings, comparing color palettes, or creating illustrations and icons.
They understand the importance of backend development, but may not spend their time writing backend logic, spinning up servers, load testing, etc.
Really interesting to see how Jason, Lyza, and co. are handling the process side of responsive design by using Agile sprints. This is how we’re doing it at Clearleft too.
There’s a really good point in here about starting with small-screen sketching:
For most of the sprint, we focus on small screens. We’re often asked how things will work on wider screens early in a sprint, but we try to resist thinking about that yet.
If you’ve managed to organize your life to fit inside a New York City apartment, you’re not going to have any trouble adjusting to a big house in the suburbs. The same is true of responsive designs.
If you nail the small screen design, the larger sizes will be easy by comparison.
Bootstrap is a product of Twitter. If you want your team to work like Twitter’s team, then by all means use Bootstrap. Pick up their design language. Their tool chain. Their decisions. Don’t be surprised when it feels off every time you use it. It will.
The same goes for Material Design. Foundation. These are all products built by other teams to work for their process. Their structure.
Finding the right tool is not what I am advocating for. Making it is.
We’re about to start trying out OKRs (Objectives and Key Results) at Clearleft. It’s a terrible, jargony label, and a lot of the discussion around them is steeped in valleywank, but I think they could be a useful way of helping shared understanding within a company.
I’ll be having a read through the accompanying guide.
Brad follows up with his thoughts on Dan’s article, emphasising the importance of a developer’s role in not just slavishly recreating what’s in a static comp, but seeing through to the underlying pattern beneath:
It’s so incredibly crucial to treat development as a key part of the design process.
Two sides of a debate on progressive enhancement…
Andrey “Rarst” Savchenko wrote Progressive enhancement — JS sites that work:
Joe Hoyle disagrees:
Caspar acknowledges this:
I don’t have any problem buying into pragmatism as the main and often pressing reason for not investing into a no-JS fallback. The idealistic nature of a design directive like progressive enhancement is very clear to me, and so are typical restrictions in client projects (budgets, deadlines, processes of decision making).
But concludes that by itself that’s not enough reason to ditch such a fundamental technique for building a universal, accessible web:
Ain’t nobody got time for progressive enhancement always, maybe. But entirely ditching principle as a compass for resilient decision making won’t do.
Mikey compares a few different decision-making processes (and in the process describes the fundamental difference between the W3C and the WHATWG).
Very thoughtful and sensible thinking from Paul.
When another company achieves success, there’s a lot of pressure to investigate what they did right and apply that to our own organizations.
But we still have a chance. As long as we run brave organizations made up of even braver souls who are willing to embrace expression, trust their intuition and experiences, and stand up when everyone else is sitting down, we will survive.
This sounds like it could be a very useful tool to introduce early in projects to get a shared understanding of progressive enhancement.
The system makes the website. Don’t blame the web developer, blame the organisation. A web developer embedded in a large system isn’t the one making the websites.
To make a progressively enhanced website that performs well and loads quickly even on slow connections, you need to first make an organisation that values those qualities over others.
This article first appeared in Fast Company almost twenty years ago. It’s a fascinating look into the culture and process that created and maintained the software for the space shuttle. It’s the opposite of Silicon Valley’s “move fast and break things.”
To be this good, the on-board shuttle group has to be very different — the antithesis of the up-all-night, pizza-and-roller-hockey software coders who have captured the public imagination. To be this good, the on-board shuttle group has to be very ordinary — indistinguishable from any focused, disciplined, and methodically managed creative enterprise.
Two-thirds of the way through our 100 days project, Batesy takes stock of his journey so far.
(I should probably mention that I love each and every one of the pieces of hand lettering that he’s done …talented bastard.)
I think the distinction between ‘how it works’ and ‘how it looks’ is blurrier than we think.
I really like this idea of Jared’s. Finish up a meeting by having everyone write down the answers to these three questions in 60 seconds:
- What was the big idea? (What was the most important thing you heard at the meeting?)
- What was your big surprise? (What was the thing you saw or heard that surprised you the most?)
- What’s your big question? (What’s the biggest unanswered question you have at this time?)
I can certainly relate to these findings:
We find that it’s not unusual to discover that different people in the room had just attended completely different meetings. People are surprised by things that other people take as a matter of course. People take away a different emphasis about what was discussed. People’s fears and concerns are reflected in their outstanding questions.
SmashingConf Oxford 2015: Richard Rutter on Don’t Give Them What They Want, Give Them What They Need
A great case study from Richard, walking through the process of redesigning the website for the Royal Borough of Kensington and Chelsea.
Superb. Absolutely superb.
A magnificent tour-de-force by Frank on the web’s edgelessness.
Read. Absorb. Read again. This is the essence of responsive web design, distilled.
Always worth bearing in mind when some perspective is needed.
If it is possible that our future species will go on to create simulations of our civilisation forerunners (us), then it is far more likely that we are currently in such a simulation than not.
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.
Sensible words from Christian.
Web applications don’t follow new rules.
And frameworks will not help:
A lot of them are not really fixing fundamental problems of the web. What they do is add developer convenience. … This would be totally OK, if we were honest about it.
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.
An important clarification from Stephen:
You don’t actually design in the browser
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.
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.
Good advice from Chris, particularly if you’re the one who has to live with the CSS you write.
As Obi-Wan Kenobi once said, “You must do what you feel is right, of course.”
This isn’t a scientific data sample, but Jonathan’s anecdotal evidence seems to suggest that most web designers and developers are still thinking with a desktop-first mentality. Which is crazy.
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.
This was a fun podcast—myself and Cyd from Code For America talk to Karen and Ethan about how we worked together. Good times.
The audio is available for your huffduffing pleasure.
Patty Toland — Design Consistency For The Responsive Web (Smashing Conference Freiburg 2014) on Vimeo
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.
My name is Jeremy and I am a boring front-end developer.
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.
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.
The first in a series of posts looking at the process behind builfing this “quantified self” site:
As with most decisions in my life, I asked myself: What would Tony Stark do?
Today, a basic HTML/CSS site seems almost passé. But why? Is it because our new tools are so significantly better, or because we’ve gone overboard complicating simple things?
He’s right, y’know.
A nice summation by Dan of when it makes sense to use a graphic design tool like Photoshop and when it makes sense to use a web browser.
The transcript of Malarkey’s recent talk. Good thoughtful stuff.
Yaili is documenting the process of retrofitting ubuntu.com to be responsive. I’ll be avidly reading each post in this series.
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.
A great write-up of the design process behind The Guardian’s responsive site. It’s really gratifying to see UX designers talking about performance.
Words of wisdom from Seb when it comes to personal projects: finish what you start.
Most people don’t finish their projects so simply by getting it done, you’re way ahead of the crowd.
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.).
Des is right, y’know.
Scope grows in minutes, not months. Look after the minutes, and the months take care of themselves.
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.
This looks interesting: a CSS postprocessor that polyfills support for perfectly cromulent styles.
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.
John shares his concerns about the increasing complexity involved in developing for the web.
The transcript of Mark’s talk from last week’s Handheld conference in Cardiff.
There are mountains.
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.
Empathy is for everyone:
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.
A nice reminder from Viv.
A call for developers to let standards bodies know what we want:
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.
A terrific case study in progressive enhancement: starting with a good ol’ form that works for everybody and then adding on features like Ajax, SVG, the History API …the sky’s the limit.
An intriguing initiative to tighten up the loop between standards development and implementation.
Jon gives some insight into how and why we use pattern portfolios as deliverables at Clearleft.
Trent hammers home the point that the kind of compartmentalisation that’s traditionally been part and parcel of the web dev workflow just won’t cut it anymore.
Dave talks about the kind of deliverables that get handed over in a responsive project. Sounds a lot like what we do at Clearleft.
Responsive deliverables should look a lot like fully-functioning Twitter Bootstrap-style systems custom tailored for your clients’ needs.
Some cautionary tales of over-engineering solutions before doing some quick user-testing to establish what the real problems are.
It’s a pleasant delusion to believe that all our problems require hard solutions.
A terrific, in-depth round-up and recollection of the Responsive Day Out by Laura that ties all of the strands together.
Anna documents her tea-making process.
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…
Some thoughts and soul-searching prompted by talks at the Responsive Day Out.
Some nice recollections from the Responsive Day Out.
A nice write-up of the Responsive Day Out with all the right take-aways.
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.
James’s notes from the most recent Hack Farm show that, even without a finished product, there were a lot of benefits.
Gorgeous colour-processed images from NASA probes. I could stare at the fountains of Enceladus all day.
Beauteous and true.
Real design is political.
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:
Design for every state, not the best state.
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”.
Another responsive design case study. This one’s got numbers too.
I love seeing the process behind responsive projects. This one is particularly nice.
A really terrific piece about wireframing for responsive designs. Again, it’s all about the prototypes.
Less wireframing, more prototyping.
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.
A peak behind the scenes at the responsive design and development workflow at Bearded. It makes a lot of sense.
Does Zed Shaw look like a bitch to you?
I said does Zed Shaw look like a bitch to you?
A nice look at some possible ways to approach workflow on a responsive project.
A lovely bit of hypertext.