Old technology seldom just goes away. Whiteboards and LED screens join chalk blackboards, but don’t eliminate them. Landline phones get scarce, but not phones. Film cameras become rarities, but not cameras. Typewriters disappear, but not typing. And the technologies that seem to be the most outclassed may come back as a the cult objects of aficionados—the vinyl record, for example. All this is to say that no one can tell us what will be obsolete in fifty years, but probably a lot less will be obsolete than we think.
Sunday, August 4th, 2019
Saturday, August 3rd, 2019
I was chatting with Rachel at work the other day about conversational forms, and I mentioned that I kicked that whole thing off with the mad libs style form on Huffduffer. Here’s the research that Luke later did on whether this style of form could increase conversion.
Thursday, August 1st, 2019
Chris broke both his arms just to avoid speaking at the JAMstack conference in London. Seems a bit extreme to me.
Anyway, to make up for not being there, he made a website of his talk. It’s good stuff, tackling the split.
It’s cool to see the tech around our job evolve to the point that we can reach our arms around the whole thing. It’s worthy of some concern when we feel like complication of web technology feels like it’s raising the barrier to entry
Wednesday, June 26th, 2019
Over the last fifty years, we have come to recognize that the fuel of our civilizational expansion has become the main driver of our extinction, and that of many of the species we share the planet with. We are now coming to realize that is as true of our cognitive infrastructure. Something is out of sync, felt everywhere: something amiss in the temporal order, and it is as related to political and technological shifts, shifts in our own cognition and attention, as it is to climatic ones. To think clearly in such times requires an intersectional understanding of time itself, a way of thinking that escapes the cognitive traps, ancient and modern, into which we too easily fall. Because our technologies, the infrastructures we have built to escape our past, have turned instead to cancelling our future.
James writes beautifully about rates of change.
The greatest trick our utility-directed technologies have performed is to constantly pull us out of time: to distract us from the here and now, to treat time as a kind of fossil fuel which can be endlessly extracted in the service of a utopian future which never quite arrives. If information is the new oil, we are already, in the hyper-accelerated way of present things, well into the fracking age, with tremors shuddering through the landscape and the tap water on fire. But this is not enough; it will never be enough. We must be displaced utterly in time, caught up in endless imaginings of the future while endlessly neglecting the lessons and potential actions of the present moment.
1,841 instances of dark patterns on ecommerce sites, in the categories of sneaking, urgency, misdirection, social proof, scarcity, obstruction, and forced action. You can browse this overview, read the paper, or look at the raw data.
We conducted a large-scale study, analyzing ~53K product pages from ~11K shopping websites to characterize and quantify the prevalence of dark patterns.
Sunday, June 16th, 2019
IntersectionObserver to lazy load images—very handy for webmention avatars.
Thursday, June 6th, 2019
Here’s the video of the talk I gave at State Of The Browser last year. The audio is a bit out of sync with the video.
The talk is called The Web Is Agreement. It’s ostensibly about web standards, but I used that as a jumping off point for talking about life, the universe, and everything.
I enjoyed giving this talk, but I’ve only ever given it this one time. If you know of any events where this talk would be a good fit, let me know.
Thursday, May 30th, 2019
Indie web events in Brighton
Homebrew Website Club is a regular gathering of people getting together to tinker on their own websites. It’s a play on the original Homebrew Computer Club from the ’70s. It shares a similar spirit of sharing and collaboration.
Homebrew Website Clubs happen at various locations: London, San Francisco, Portland, Nuremberg, and more. Usually there on every second Wednesday.
I started running Homebrew Website Club Brighton a while back. I tried the “every second Wednesday” thing, but it was tricky to make that work. People found it hard to keep track of which Wednesdays were Homebrew days and which weren’t. And if you missed one, then it would potentially be weeks between attending.
So I’ve made it a weekly gathering. On Thursdays. That’s mostly because Thursdays work for me: that’s one of the evenings when Jessica has her ballet class, so it’s the perfect time for me to spend a while in the company of fellow website owners.
If you’re in Brighton and you have your own website (or you want to have your own website), you should come along. It’s every Thursday from 6pm to 7:30pm ‘round at the Clearleft studio on 68 Middle Street. Add it to your calendar.
(I’m at Homebrew Website Club Brighton right now, writing this. Remy is here too, working on some very cool webmention stuff.)
There’s something else you should add to your calendar. We’re going to have an Indie Web Camp in Brighton on October 19th and 20th. I realise that’s quite a way off, but I’m giving you plenty of advance warning so you can block out that weekend (and plan travel if you’re coming from outside Brighton).
If you’ve never been to an Indie Web Camp before, you should definitely come! It’s indescribably fun and inspiring. The first day—Saturday—is a BarCamp-style day of discussions to really get the ideas flowing. Then the second day—Sunday—is all about designing, building, and making. The whole thing wraps up with demos.
It’s been a while since we’ve had an Indie Web Camp in Brighton. You can catch up on the Brighton Indie Web Camps we had in 2014, 2015, and 2016. Since then I’ve been to Indie Web Camps in Berlin, Nuremberg, and Düsseldorf, but it’s going to be really nice to bring it back home.
The event will be free to attend, but I’ll set up an official ticket page on Ti.to to keep track of who’s coming. I’ll let you know when that’s up and ready. In the meantime, you can register your interest in attending on the 2019 Indie Webcamp Brighton page on the Indie Web wiki.
Tuesday, May 21st, 2019
I’m not trying to convince anyone they aren’t a full-stack developer or don’t deserve that particular merit badge — just that the web is a big place with divergent needs and ever-morphing stacks that all require different sets of skills.
Monday, May 20th, 2019
Page web bloat score (WebBS for short) is calculated as follows:
WebBS = TotalPageSize / PageImageSize
Yes, this is a tongue-in-cheek somewhat arbitrary measurement, but it’s well worth reading through the rationale for it.
How can the image of a page be smaller than the page itself?
Tuesday, May 7th, 2019
Wednesday, April 24th, 2019
I missed this when it was first posted three years ago, but now I think I’ll be revisiting this 12 minute interview every few months.
Everything that Kyle says here is spot on, nuanced, and thoughtful. He talks about abstraction, maintainability, learning, and complexity.
I want a transcript of the whole thing.
Monday, April 8th, 2019
Frameworks (arguably) make building complex applications easier, but they make doing simple stuff more complex.
And that’s why I think people should learn vanilla JS first. I’ve had many students who tried to learn frameworks get frustated, quit, and focus on vanilla JS.
Some of them have gone back to frameworks later, and told me that knowing vanilla JS made it a lot easier for them to pick up frameworks afterwards.
Friday, April 5th, 2019
This article by Ian Bogost from a few years back touches on one of the themes in the talk I gave at New Adventures:
“Engineer” conjures the image of the hard-hat-topped designer-builder, carefully crafting tomorrow. But such an aspiration is rarely realized by computing. The respectability of engineering, a feature built over many decades of closely controlled, education- and apprenticeship-oriented certification, becomes reinterpreted as a fast-and-loose commitment to craftwork as business.
Friday, March 29th, 2019
Not only does the differentiation of terms create a divide within the industry, the term ‘web app’ regularly acts as an excuse for corner cutting and the exclusion of users.
We kid ourselves into thinking we’re building groundbreakingly complex systems that require bleeding-edge tools, but in reality, much of what we build is a way to render two things: a list, and a single item. Here are some users, here is a user. Here are your contacts, here are your messages with that contact. There ain’t much more to it than that.
I love the way that Benjamin is documenting his activities at Homebrew Website Club Brighton each week:
Another highly productive 90 mins.
Homebrew website club is on every Thursday evening 6.00-7.30pm at Clearleft. You should come along!
Friday, March 22nd, 2019
Two of my favourite things: indie web and service workers.
This makes me so happy. I remember saying when my book came out, that the best feedback I could possibly get would be readers making their websites work offline. The same can be said for the talk of the book.
Saturday, March 9th, 2019
Updating email addresses with Mailchimp’s API
I’ve been using Mailchimp for years now to send out a weekly newsletter from The Session. But I never visit the Mailchimp website. Instead, I use the API to create a campaign each week, and then send it out. I also use the API whenever a member of The Session updates their email preferences (or changes their details).
I got an email from Mailchimp that their old API was being deprecated and I’d need to update to their more recent one. The code I was using had been happily running for about seven years, but now I’d have to change it.
Everything went pretty smoothly. I was able to create campaigns, send campaigns, add new subscribers, and delete subscribers. But I ran into an issue when I wanted to update someone’s email address (on The Session, you can edit your details at any time, including your email address).
Here’s the set up:
use \DrewM\MailChimp\MailChimp; $MailChimp = new MailChimp('abc123abc123abc123abc123abc123-us1'); $list_id = 'b1234346'; $subscriber_hash = $MailChimp -> subscriberHash('email@example.com'); $endpoint = 'lists/'.$listID.'/members/'.$subscriber_hash;
Now to update details, according to the API, I can use the
patch method on that endpoint:
$MailChimp -> patch($endpoint, [ 'email_address' => 'firstname.lastname@example.org' ]);
But that doesn’t work. Mailchimp effectively treats email addresses as unique IDs for subscribers. So the only way to change someone’s email address appears to be to delete them, and then subscribe them fresh with the new email address:
$MailChimp -> delete($endpoint); $newendpoint = 'lists/'.$listID.'/members'; $MailChimp -> post($newendpoint, [ 'email_address' => 'email@example.com', 'status' => 'subscribed' ]);
That’s somewhat annoying, as the previous version of the API allowed email addresses to be updated, but this workaround isn’t too arduous.
Anyway, I figured it share this just in case it was useful for anyone else migrating to the newer API.
Update: Belay that. Turns out that you can update email addresses, but you have to be sure to include the
$MailChimp -> patch($endpoint, [ 'email_address' => 'firstname.lastname@example.org', 'status' => 'subscribed' ]);
Okay, that’s a lot more straightforward. Ignore everything I said.
Wednesday, March 6th, 2019
Are many of the modern frontend tools and practices just technical debt in disguise?
Ooh, good question!
Tuesday, March 5th, 2019
How to Think Like a Front-End Developer by Chris Coyier
Alright! It’s day two of An Event Apart in Seattle. The first speaker of the day is Chris Coyier. His talk is called How to Think Like a Front-End Developer. From the website:
The job title “front-end developer” is very real: job boards around the world confirm that. But what is that job, exactly? What do you need to know to do it? You might think those answers are pretty cut and dried, but they’re anything but; front-end development is going through something of an identity crisis. In this engaging talk, Chris will explore this identity through the lens of someone who has self-identified as a front-end developer for a few decades, but more interestingly, through many conversations he’s had with other successful front-end developers. You’ll see just how differently this job can be done and how differently people and companies can think of this role—not just for the sake of doing so, but because you’ll learn to be better at your own jobs by understanding how other people are good at theirs.
I’m going to see if I can keep up with Chris’s frenetic pace…
Chris has his own thoughts about what front-end dev is but he wants to share other ideas too. First of all, some grammar:
I work as a front-end developer.
I work on the front end.
Those are correct. These are not:
I work as a front end developer.
I work on the front-end.
And this is just not a word:
Lots of people are hiring front-end developers. So it’s definitely a job and a common job title. But what does it mean. Chris and Dave talked to eight different people on their Shop Talk Show podcast. Some highlights:
Eric feels that the term “front-end developer” is newer than the CSS Zen Garden. Everyone was a webmaster, or as we’d say now, a full-stack developer. But if someone back then used the term “front-end developer”, he’d know what it meant.
Mina says it deals with things you can see. If it’s a user-facing interface, that’s front-end development.
Trent says that he thinks of himself as a web designer and web builder. He doesn’t feel he has the deep expertise of a developer, and yet he spends all of his time in the browser.
So our job is in the browser. You deal with the browser (moreso than other roles). And by the way, there are a lot of browsers out there.
Maybe the user is what differentiates front-end work. Monica says that a back-end developer is allowed not to care about the user if their job is putting a database together. It’s totally fine not to call yourself a front-end developer, but if you do, you need to care about the user.
There are tons of different devices and browsers. It’s overwhelming. So we just gave up.
So, a front-end developer:
- Is a job and a job title.
- It deals with browsers, devices, and users.
- But what skills does it involve?
It’s taken for granted that you can use a computer. There’s also the soft skills of interacting with co-workers. Then there are the language-specific core skills. Finally, there are the bonus skills—all the stuff that makes you you.
The languages you need to strongly understand to read, write and maintain them.
Peggy believes that as a front-end developer you need to have a basic proficiency in accessibility too. This is, after all, about user-facing interfaces.
The Figma team have a somewhat over-engineered graphic of all the skillsets that people might have, between “baseline” and “supplementary”.
Perhaps we all share a common trunk of skills, and then we branch in different directions.
You could imagine two people called front-end developers meeting, and having nothing in common to talk about. Maybe sports.
Brad says he doesn’t want to be configuring build tools. He thinks of himself as being at the front of front-end development, whereas other people are at the back of front-end development.
This divide is super frustrating to people right now.
Let’s look at CodePen. There’s a little heart icon on each pen. It’s an icon component. And the combination of the heart and the overall count is also a component. And the bar of items altogether—that’s also a component. And the pen it sits under is a component. And the page it’s in is a component. And the URL for that page is a component. Now the whole site is a front-end developer’s concern.
In the past, a front-end developer would ask a back-end developer for an API endpoint. Now with GraphQL, the front-end developer can craft a query to get exactly what they need. Sure, the GraphQL stuff had to be set up in the first place, but that’s one-time task. Once it’s set up, the front-end developer has everything they need.
All the old work hasn’t gone away either. Semantics, accessibility, styling—that’s still the work of a front-end developer as well as all of the new stuff listed above.
Hiring is a big part of this. Lara Schenk talks about going for an interview where she met 90% of the skills listed. Then in an interview, she was asked to do a fizzbuzz test. That’s not the way that Lara thinks. She would’ve been great for that job, but this single task derailed her. She wrote about it, and got snarky comments from people who thought she should’ve been able to do the task. But Lara’s main point was the mismatch between what was advertised and what was actually being hired for.
You see a job posting for front-end developer. Who is that for? Is it for someone into React, webpack, and GraphQL? Or is it for someone into SVG, interaction design, and accessibility? They’re both front-end developers. And remember, they can learn one another’s skills, but when it comes to hiring, it has to be about the skills people have right now.
Peggy talks about how specialised your work can be. You can specialise in SVG. You can specialise in APIs and data.
We’re probably not going to solve this right now. The hiring part is definitely the worst part right now. One solution is to use plain language in job posts. Make it clear what you’re looking for right now and explain what background you’re coming from. Use words instead of a laundry list of requirements.
Heydon Pickering talks about full-stack developers. Their core skills are hardcore computer science skills.
Brad Frost concurs. It tends not to be the other way around. The output tends to be the badly-sketched front of the horse.
Even if there is a divide, that doesn’t absolve any of us from doing a good job. That’s true whether it’s computer science tasks or markup and CSS.
Despite the divide, performance, accessibility, and user experience are all our jobs.
Maybe this term “front-end developer” needs rethinking.
The brain game
Let’s peak into the minds of very different front-end developers. Chris and Dave went to Dribbble, pulled up a bunch of designs and put them in front of their guests on the Shop Talk Show.
Here’s a design of a page.
- Brad looks at the design and sees a lot of components of different sizes and complexity.
- Mina sees a bunch of media objects.
- Eric sees HTML structures. That’s a heading. That’s a list. Over there is an unordered list.
- Sam sees a lot of typography. She sees a type system.
- Trent immediately starts thinking about how the design is supposed to work in different screen sizes.
Here’s a different, more image-heavy design.
- Mina would love to tackle the animations.
- Trent sees interesting textures and noise. He wonders how he could achieve those effects without exporting giant image files.
- Brad, unsurprisingly, sees components, even in a seemingly bespoke layout.
- Eric immediately sees a lot of SVG.
- Sam needs to know what the HTML is.
Here’s a more geometric design.
- Sam is drawn to the typography.
- Mina sees an opportunity to use writing modes.
- Trent sees a design that would reflow and reshape itself well.
- Eric sees something with writing mode, grid, and custom fonts.
Here’s a financial mobile UI.
- Trent wants to run it through a colour-contrast analyser, and he wants to know if the font size is too small.
Here’s a crazy festival website.
- Mina wonders if it needs a background video, but worries about the performance.
Here’s an on-trend mobile design.
- Monica sees something that looks like every other website.
- Ben wonders whether it will work in other parts of the world. How will the interactions work? Separate pages or transitions? How will it feel?
Here’s an image-heavy design.
- Monica wonders about the priority of which images to load first.
Here’s an extreme navigation with big images.
- Ben worries about the performance on slow connections.
- Monica gets stressed out about how much happens when you just click on a link.
- Peggy sees something static and imagines using Gatsby for it.
Here’s a design that’s map-based.
- Ben worries about the size of the touch targets.
- Monica sees an opportunity to use SVGs.
Here’s a card UI.
- Ben wonders what the browser support is. Can we use CSS grid or do we have to use something older?
- Monica worries that this needs drag’n’drop. Now you’ve got a nightmare scenario.
Chris has been thinking about and writing about this topic of what makes someone a front-end developer, and what makes someone a good front-end developer. The debate will continue…