Tags: libraries

Design systems and Postel’s law | Journal | The Personal Disquiet of Mark Boulton

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.

On Building Component Libraries | Clearleft

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.

Clarity 2016 Wrapup by Chris Coyier on CodePen

As well as compèring the event, Chris took the time to make notes at the Clarity conference, dedicated to all things patterny.

Clarity Conf: Brad Frost

I wish I could’ve made it to the Clarity conference—I had a Salter Cane gig to play—but luckily for me, Brad took lots of notes.

Front-End Style-Guides: Definition, Requirements, Component Checklist

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.

A 5 day sprint with Clear Left exploring library self-service machine software – Leon Paternoster

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.

Together • Ludwig Wendzich

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.

From Pages to Patterns: An Exercise for Everyone · An A List Apart Article

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.

Confidence and Overwhelm

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.

The JavaScript-Dependency Backlash: Myth-Busting Progressive Enhancement

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.

Stop Breaking the Web

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.

Why we left AngularJS: 5 surprisingly painful things about client-side JS

It’s funny: while I agree with the warning that this article provides (“rich client-side JavaScript frameworks aren’t a good fit for every site, especially content sites”), the reasons given here aren’t the reasons that I have any issues with.

Progressive Enhancement: Still Not Dead. - That Emil

A great post by Emil on the importance of using progressive enhancement for JavaScript — an increasingly unpopular position in today’s climate of client-side-only frameworks and libraries.

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.

In defense of reinventing wheels | Lea Verou

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.

Stop solving problems you don’t yet have | this is rachelandrew.co.uk

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.

Home - LOCKSS

Lots Of Copies Keep Stuff Safe — a digital preservation initiative based at Stanford.

AJAX Libraries API - Google Code

Google is now hosting all the major JavaScript libraries. The caching benefits should be good news for your users.

JavaScript Libraries: The Big Picture

Simon's slides from his talk at XTech on JavaScript libraries (which I missed). Good stuff contained within.

rikrikrik: Wasted Javascript

How much page weight is being wasted on JavaScript. It's time to shed those pounds.

The JavaScript Library World Cup [JavaScript & DHTML Tutorials]

Dan Webb does an excellent job of comparing the big four JavaScript libraries that were discussed at @media.

Devlounge | Cameron Adams aka The Man In Blue

Cameron shares his thoughts on Ajax, Hijax, libraries and having fun.

Yahoo! 360° - The Department of Style - Choose Your Ajax

Douglas Crockford proposes an acid test for JavaScript libraries - "If JSLint finds problems in a library, then dump it and move on to the next one."