This is the dumbest publishing platform on the web.
Write something, hit publish, and it’s live.
James shares his experience of teaching a class of 9 and 10 year old children how to code, and offers some advice:
- Don’t dumb it down
- Use real-world examples
- Make it hands on
- Set clear expectations
- Award certificates and/or stickers
As members of the web community we have a responsibility to share what we have learned. I can’t think of a better way of doing that then helping kids get started.
Following on from Ben’s post, this is also giving me the warm fuzzies.
I, in no uncertain terms, have become a better designer thanks to the people I’ve had the pleasure of working alongside at Clearleft. I’ll forever be thankful of my time there, and to the people who helped me become better.
Ben is moving on from Clearleft. I’m going to miss him. I found this summation of his time here very moving.
Working at Clearleft was one of the best decisions I ever made. 6 years of some work that I’m most proud of, amongst some of the finest thinkers I’ve ever met.
He also outlines the lessons he learned here:
- Writing and speaking will make you a better thinker and designer.
- Autonomy rules.
- Own stuff.
- Aim high.
Should you ever choose to work with, or work for Clearleft, I hope these words will give you some encouragement — it is an exceptional place to be.
Prompted by his recent talk at Smashing Conference, Mark explains why he’s all about the pace layers when it comes to design systems. It’s good stuff, and ties in nicely with my recent (pace layers obsessed) talk at An Event Apart.
Structure for pace. Move at the appropriate speed.
An interesting piece by Jessica Kerr that draws lessons from the histories of art and science and applies them to software development.
This was an interesting point about the cognitive load of getting your head around an existing system compared to creating your own:
And just because I’ve spent most of last year thinking about how to effectively communicate—in book form—relatively complex ideas clearly and simply, this part really stood out for me:
When you do have a decent mental model of a system, sharing that with others is hard. You don’t know how much you know.
A smart look back at historical examples of regulation and what we can learn from them today, by Justine Leblanc:
- Railways in the UK: Public interest as a trigger for regulation
- Engineering in Canada: Accountability as a trigger for regulation
- The automotive industry in the USA: Public outrage as a trigger for regulation
There was a moment that it seemed like a proliferation of flickr-like webservices would result in a network of deep shared pools of cultural resource, from which every user could build expressions and applications, but the “entrap and surveil” economics of platforms kicked in.
And now we have no history, and rather than communicating via visualizations of our own shared cultural record, we are left waiting like dogs for treats as facebook decides to surface one of our own images from 3 or 8 years ago. Don’t try to search the graph! Advertisers only.
I recently put the call out for freelance front-end devs on Twitter, and my experience mirrors Chris’s.
Not having a personal website was a turn-off. I don’t know if it matters industry-wide or not, but I’m one person with my own opinions and I’m the one making the call so it mattered here. A personal website is the clearest place I can get a sense of your taste, design ability, and writing ability.
This is absolutely brilliant!
Forgive my excitement, but this transcript of Charlie’s talk is so, so good—an equal mix of history and practical advice. Once you’ve read it, share it. I want everyone to have the pleasure of reading this inspiring piece!
It is this flirty declarative nature makes HTML so incredibly robust. Just look at this video. It shows me pulling chunks out of the Amazon homepage as I browse it, while the page continues to run.
Let’s just stop and think about that, because we take it for granted. I’m pulling chunks of code out of a running computer application, AND IT IS STILL WORKING.
Just how… INCREDIBLE is that? Can you imagine pulling random chunks of code out of the memory of your iPhone or Windows laptop, and still expecting it to work? Of course not! But with HTML, it’s a given.
Perspectives other than our own bring a breath of fresh air. They open doors and allow light to flood in. They wrap us in a warm, comforting blanket by letting us know other people go through similar struggles. There is a tonne of writing out there that exists because the author suffered through something. Suffering tends to give you a strong desire to prevent others experiencing similar pain.
This is a fun—and useful—way of improving the interview process. The Rubik’s Cube examples brought a smile to my face.
A directory of the regular science, technology, and creative events happening in Brighton.
Anil documents the steady decline of empowering features from web browsers: view source; in-situ authoring; transclusion, but finishes with the greatest loss of all: your own website at your own address.
There are no technical barriers for why we couldn’t share our photos to our own sites instead of to Instagram, or why we couldn’t post stupid memes to our own web address instead of on Facebook or Reddit. There are social barriers, of course — if we stubbornly used our own websites right now, none of our family or friends would see our stuff. Yet there’s been a dogged community of web nerds working on that problem for a decade or two, trying to see if they can get the ease or convenience of sharing on Facebook or Twitter or Instagram to work across a distributed network where everyone has their own websites.
(Although it’s a bit of shame that Anil posted this on Ev’s blog instead of his own.)
An excellent, thorough, even-handed analysis of AMP’s performance from Tim. The AMP format doesn’t make that much of a difference, the AMP cache does speed things up (as would any CDN), but it’s the pre-rendering that really delivers the performance boost …as long as you give up your URLs.
But right now, the incentives being placed on AMP content seem to be accomplishing exactly what you would think: they’re incentivizing AMP, not performance.
Everything old is new again—sometimes the age-old technique of using a 1x1 pixel image to log requests is still the only way to get certain metrics.
While tracking pixels are far from a new idea, there are creative ways in which we can use them to collect data useful to developers. Once the data is gathered, we can begin to make much more informed decisions about how we work.
An up-to-date list of Brighton design and dev meet-ups. There’s quite a few!
Although design gets conflated with creation, its the act of improving what already exists — organising a room, editing a text, refining an interface, refactoring a codebase — that I enjoy the most.
Mike pours his heart out on Ev’s blog.
I’m not entirely sure if I agree with him about licensing or certification for designers (and developers?), but I absolutely 100% agree on the need for unionisation.
We need to be held accountable for our actions. We’ve been moving fast. We’ve been breaking things. Sometimes on purpose. Sometimes out of ignorance. The effects are the same. The things we’re building are bigger than they used to be, and have more reach. The moment to slow down is here. Because what we’re breaking is too important and too precious. Much of it is irreplaceable.
Maybe I’m weird, but it just feels good. It feels good to reclaim my turf. It feels good to have a spot to think out loud in public where people aren’t spitting and shitting all over the place.