I can’t help but also wonder if we’re using tools to solve problems they weren’t meant to solve, like how to communicate with or manage a team.
Saturday, January 20th, 2018
Tuesday, January 9th, 2018
The text of a fascinating talk given by Tim Berners-Lee back in 1995, at a gathering to mark the 50th anniversary of Vannevar Bush’s amazing article As We May Think. The event also drew together Ted Nelson, Alan Kay, Douglas Engelbart, and Bob Kahn!
Sunday, November 19th, 2017
A plug-in that lets multiple people collaborate on the same document in Atom. Could be useful for hackdays and workshops.
Wednesday, November 15th, 2017
I really like this exercise by Harry. I’ve done similar kinds of grading using dot-voting in the past. It feels like an early step to establishing design principles: “this over that.”
By deciding what we value up-front, we have an agreement that we can look back on in order to help us settle these conflicts and get us back on track again.
Relative Requirements remove the personal aspect of these disagreements and instead focuses on more objective agreements that we made as a team.
Thursday, October 19th, 2017
Susan reviews Alla’s superb book on design systems:
If you’re interested in or wanting to create a design system or improve the one you have or get buy in to take your side project at work and make it part of the normal work flow, read this book. And even better, get your colleagues to do the same, so you’ll have a shared understanding before you begin the hard work to build your own system.
Susan also published her highlights from the book. I really like that!
Thursday, September 14th, 2017
When every new website on the internet has perfect, semantic, accessible HTML and exceptionally executed, accessible CSS that works on every device and browser, then you can tell me that these languages are not valuable on their own. Until then we need to stop devaluing CSS and HTML.
Tuesday, September 12th, 2017
Some great ideas here about using metaphors when explaining technical topics.
I really like these four guidelines for good metaphors:
Tuesday, August 29th, 2017
Adam Wathan wrote an article recently called CSS Utility Classes and “Separation of Concerns”. In it, he documents his journey through different ways of thinking about CSS. A lot of it is really familiar.
Phase 1: “Semantic” CSS
Ah, yes! If you’ve been in the game for a while then this will be familiar to you. The days when we used to strive to keep our class names to a minimum and use names that described the content. But, as Adam points out:
My markup wasn’t concerned with styling decisions, but my CSS was very concerned with my markup structure.
Phase 2: Decoupling styles from structure
This is the work pioneered by Nicole with OOCSS, and followed later by methodologies like BEM and SMACSS.
This felt like a huge improvement to me. My markup was still “semantic” and didn’t contain any styling decisions, and now my CSS felt decoupled from my markup structure, with the added bonus of avoiding unnecessary selector specificity.
But then Adam talks about the issues when you have two visually similar components that are semantically very different. He shows a few possible solutions and asks this excellent question:
For the project you’re working on, what would be more valuable: restyleable HTML, or reusable CSS?
For many projects reusable CSS is the goal. But not all projects. On the Code For America project, the HTML needed to be as clean as possible, even if that meant more brittle CSS.
Phase 3: Content-agnostic CSS components
Naming things is hard:
The more a component does, or the more specific a component is, the harder it is to reuse.
Adam offers some good advice on naming things for maximum reusability. It’s all good stuff, and this would be the point at which I would stop. At this point there’s a nice balance between reusability, readability, and semantic meaning.
But Adam goes further…
Phase 4: Content-agnostic components + utility classes
Okay. The occasional utility class (for alignment and clearing) can be very handy. This is definitely the point to stop though, right?
Phase 5: Utility-first CSS
Oh God, no!
Once this clicked for me, it wasn’t long before I had built out a whole suite of utility classes for common visual tweaks I needed, things like:
- Text sizes, colors, and weights
- Border colors, widths, and positions
- Background colors
- Flexbox utilities
- Padding and margin helpers
If one drink feels good, then ten drinks must be better, right?
At this point there is no benefit to even having an external stylesheet. You may as well use inline styles. Ah, but Adam has anticipated this and counters with this difference between inline styles and having utility classes for everything:
You can’t just pick any value want; you have to choose from a curated list.
Right. But that isn’t a technical solution, it’s a cultural one. You could just as easily have a curated list of allowed inline style properties and values. If you are in an environment where people won’t simply create a new utility class every time they want to style something, then you are also in an environment where people won’t create new inline style combinations every time they want to style something.
I think Adam has hit on something important here, but it’s not about utility classes. His suggestion of “utility-first CSS” will only work if the vocabulary is strictly adhered to. For that to work, everyone touching the code needs to understand the system and respect the boundaries of it. That understanding and respect is far, far more important than any particular way of structuring HTML and CSS. No technical solution can replace that sort of agreement …not even slapping
!important on every declaration to make them
I very much appreciate the efforts that people have put into coming up with great naming systems and methodologies, even the ones I don’t necessarily agree with. They’re all aiming to make that overlap of HTML and CSS less painful. But the really hard problem is where people overlap.
The older I get, the more every problem in tech seems to be a matter of getting humans to work together effectively, and not tech itself.— Laurie Voss (@seldo) August 23, 2017
Monday, May 22nd, 2017
Calum’s write-up of the workshop I ran in Nuremberg last week.
Tuesday, April 18th, 2017
Frank has published the (beautifully designed) text of his closing XOXO keynote.
Tuesday, January 3rd, 2017
I understand how bloated and non-reusable code can get when a dozen people who don’t talk to each other work on it over a period of years. I don’t believe the problem is the principle of semantic markup or the cascade in CSS. I believe the problem is a dozen people working on something without talking to each other.
Wednesday, December 21st, 2016
This article examines what I thought was the most interesting aspect of Rogue One—the ethical implications for technologists.
Don’t dismiss this essay just because it’s about a Hollywood blockbuster. Given the current political situation, this is deeply relevant.
Sunday, October 23rd, 2016
This is a very thoughtful analysis of different approaches to writing maintainable CSS, which—let’s face it—is the hard bit.
I often joke that I don’t want to hire a code ninja. Ninjas come in the middle of the night and leave a bloody mess.
I want a code janitor. Someone who walks the hallways of code, cleaning up pieces, dusting up neglected parts, shinning up others, tossing unnecessary bits. I prefer this gentler, more accurate analogy. This is the person you want on your team. This is a person you want in your code reviews.
Also, can I just say how refreshing it is to read an article that doesn’t treat the cascade like a disease to be wiped out? This article even goes so far as to suggest that the cascade might actually be a feature—shock! horror!
The cascade can help, if you understand and organize it. This is the same as any sophisticated software design. You can look at what you’re building and make responsible decisions on your build and design. You decide what can be at a top-level and needs to be inherited by other, smaller, pieces.
There’s a lot of really good stuff in here to mull over.
My hope for this article is to encourage developers to think ahead. We’re all in this together, and the best we can do is learn from one another.
Sunday, July 24th, 2016
The story of Science Hack Day …as told in the Proceedings of the National Academy of Sciences of the United States of America!
(a PDF version is also available)
Thursday, July 21st, 2016
I think Tyler’s onto something here:
I noticed three qualities that recurred in different combinations. Without at least two, the projects seemed doomed to failure.
I certainly think there’s a difference in how you approach a pattern library intended as a deliverable (something we do a lot of at Clearleft) compared to building a pattern library for an ongoing ever-evolving product.
Tuesday, June 28th, 2016
Story of my life:
I have to confess I had no idea what a technical leader really does. I figured it out, eventually.
Seriously, this resonates a lot with what I find myself doing at Clearleft these days.
Saturday, June 4th, 2016
I really like this list. I might make a similar one for the Clearleft office so what’s implicit is made explicit.
It’s ok to:
- say “I don’t know”
- ask for more clarity
- stay at home when you feel ill
- say you don’t understand
- ask what acronyms stand for
- ask why, and why not
- forget things
Monday, May 30th, 2016
I know exactly how Tim feels. It’s hard not to feel guilty when you’re reading something instead of spending the time doing “real work”, but it always ends up being time well spent:
Reading time can be hard to justify, even to oneself. There is no deadline. It’s not going to move any immediate projects forward (most likely). And it often feels like a waste of time, especially if your interests are diverse. But it’s important. Most great work is the product of collaborative thinking.
Saturday, March 5th, 2016
A new publication from MIT. It deliberately avoids the jargon that’s often part and parcel of peer-reviewed papers, and all of the articles are published under a Creative Commons attribution licence.
The first issue is dedicated to Marvin Minsky and features these superb articles, all of which are independently excellent but together form an even greater whole…
When the cybernetics movement began, the focus of science and engineering was on things like guiding a ballistic missile or controlling the temperature in an office. These problems were squarely in the man-made domain and were simple enough to apply the traditional divide-and-conquer method of scientific inquiry.
Science and engineering today, however, is focused on things like synthetic biology or artificial intelligence, where the problems are massively complex. These problems exceed our ability to stay within the domain of the artificial, and make it nearly impossible for us to divide them into existing disciplines.
This essay proposes a map for four domains of creative exploration—Science, Engineering, Design and Art—in an attempt to represent the antidisciplinary hypothesis: that knowledge can no longer be ascribed to, or produced within, disciplinary boundaries, but is entirely entangled.
The designers of complex adaptive systems are not strictly designing systems themselves. They are hinting those systems towards anticipated outcomes, from an array of existing interrelated systems. These are designers that do not understand themselves to be in the center of the system. Rather, they understand themselves to be participants, shaping the systems that interact with other forces, ideas, events and other designers. This essay is an exploration of what it means to participate.
As our technological and institutional creations have become more complex, our relationship to them has changed. We now relate to them as we once related to nature. Instead of being masters of our creations, we have learned to bargain with them, cajoling and guiding them in the general direction of our goals. We have built our own jungle, and it has a life of its own.