As well as compèring the event, Chris took the time to make notes at the Clarity conference, dedicated to all things patterny.
You know that front-end pattern libraries have hit the mainstream when the Nielsen Norman Group get in on the action.
As ever, I’m not sure their sweeping generalisations can be applied to every project, but their checklist approach makes for a good starting point.
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.
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.
I’m so proud of Charlotte right now: last week she gave a conference talk and today she has an article published in A List Apart. Superb work on both fronts!
She does a great job of talking through a collaborative exercise to help teams move from thinking in pages to thinking in patterns.
Following on from her great conversation with Jen on The Web Ahead podcast, Rachel outlines a strategy to avoid feeling overwhelmed by the deluge of tools, frameworks, libraries, and techniques inundating front-end developers every day:
Learn your core skills well. Understand HTML and CSS, be able to build a layout without leaning on a framework. Get a solid understanding of how a website actually gets from the server to a browser, an understanding of security and accessibility. These are the basics, the constants. These things change slowly. These things sit underneath all the complexity and the tooling, the CMSs and the noise of thousands of people all trying to make their mark on this industry.
She also makes this important point:
As you are doing this don’t forget to share what you know.
Progressive Enhancement remains the best option for solving web development issues such as wide-ranging browser support, maintenance and future-proofing your application.
You Don’t Need jQuery! – Free yourself from the chains of jQuery by embracing and understanding the modern Web API and discovering various directed libraries to help you fill in the gaps.
The tone is a bit too heavy-handed for my taste, but the code examples here are very handy if you’re weaning yourself off jQuery.
Angry, but true.
Don’t lock yourself into a comprehensive technology that may just die within the next few months and leave you stranded. With progressive enhancement you’ll never go wrong. Progressive enhancement means your code will always work, because you’ll always focus on providing a minimal experience first, and then adding features, functionality, and behavior on top of the content.
There’s something fundamental and robust about being able to request a URL and get back at least an HTML representation of the resource: human-readable, accessible, fault tolerant.
Maybe it’s because I’m a bit of a control freak, but I can really empathise with what Lea is saying here: sometimes the developer convenience you get from using someone else’s code can result in quite a bit of redundant code. I feel that this is particularly a problem on the front end.
Lots Of Copies Keep Stuff Safe — a digital preservation initiative based at Stanford.
A detailed comparison of jQuery and MooTools.
Cameron shares his thoughts on Ajax, Hijax, libraries and having fun.