Jemima runs through just some of the exciting new additions to CSS:
Replacing 150+ lines of JavaScript with just a few CSS features is genuinely wild. We’re able to achieve the same amount of complexity that we’ve always had, but now it’s a lot less work to do so.
And Jemima will be opening the show at Web Day Out in Brighton on the 12th of March if you want to hear more of this!
Marcin has outdone himself this time. Not only has he created an exhaustive history of the settings controls in Apple interfaces, he’s gone and made them all interactive!
While it’s easy to be blown away by the detail of the interactive elements here, it’s also worth taking a moment to appreciate just how good the writing is too.
Bravo!
I really like the thinking behind this project:
We believe computers should work for people, and dream of a future where computing, like cooking or word processing, is available to everyone. Where you can solve your own small, unique problems with small, unique apps. Where you don’t just rely on mass-market apps made by expert programmers. Where you share home-made little apps with family and friends.
Scrappy is our contribution to this dream.
Everyone’s raving about this great talk by Marcin, and rightly so!
Here’s a nifty demo of popover but it’s not for what we’d traditionally consider a modal dialog.
This is a wonderful in-depth article by Jen, with lots of great demos.
She makes a very strong case for masonry layouts being part of the grid spec (I’m convinced!). If you have strong feelings one way or the other, get involved
I just attended this talk from Heydon at axe-con and it was great! Of course it was highly amusing, but he also makes a profound and fundamental point about how we should be going about working on the web.
Check out the demo that Rich has put together to go with Amelia’s proposed syntax.
At Clarity last week, I had the great pleasure of introducing and interviewing Linda Dong who spoke about Apple’s Human Interface Guidelines. I loved the way she looked at the history of the HIG from 1977 onwards. This collection of videos is just what I need to keep spelunking into the interfaces of the past:
A curated collection of HCI demo videos produced during the golden age from 1983-2002.
Spot-on analysis by Max:
Generally speaking: The more independence a technology gives you, the higher its barrier for adoption.
I really hope that this when smart folks start putting their skills towards making the ideas of the indie web more widely available:
I think we’re at a special moment right now. People have been fed up with social media and its various problems (surveillance capitalism, erosion of mental health, active destruction of democracy, bla bla bla) for quite a while now. But it needs a special bang to get a critical mass of users to actually pack up their stuff and move.
Folk creations fill a gap. They solve problems for individuals and small communities in a way that that centralised, top-down, industrial creations never can. They are informal, distributed practices that emerge from real world contexts. Contexts where individuals have little or no control over the “official” means of production – of furniture, urban architecture, crockery, artwork, media stories, or taxonomies. In response people develop their own unpolished, unofficial, and deeply practical creations.
Now apply that to software:
Only professional programmers and designers get to decide what buttons go on the interface, what features get prioritised, and what affordances users have access to. Subverting that dynamic is the only way people can get their needs met with the computational tools they have at hand.
When I wrote about democratising dev, I made brief mention of the growing “no code” movement:
Personally, I would love it if the process of making websites could be democratised more. I’ve often said that my nightmare scenario for the World Wide Web would be for its fate to lie in the hands of an elite priesthood of programmers with computer science degrees. So I’m all in favour of no-code tools …in theory.
But I didn’t describe what no-code is, as I understand it.
I’m taking the term at face value to mean a mechanism for creating a website—preferably on a domain you control—without having to write anything in HTML, CSS, JavaScript, or any back-end programming language.
By that definition, something like WordPress.com (as opposed to WordPress itself) is a no-code tool:
Create any kind of website. No code, no manuals, no limits.
I’d also put Squarespace in the same category:
Start with a flexible template, then customize to fit your style and professional needs with our website builder.
And its competitor, Wix:
Discover the platform that gives you the freedom to create, design, manage and develop your web presence exactly the way you want.
Webflow provides the same kind of service, but with a heavy emphasis on marketing websites:
Your website should be a marketing asset, not an engineering challenge.
Bubble is trying to cover a broader base:
Bubble lets you create interactive, multi-user apps for desktop and mobile web browsers, including all the features you need to build a site like Facebook or Airbnb.
Wheras Carrd opts for a minimalist one-page approach:
Simple, free, fully responsive one-page sites for pretty much anything.
All of those tools emphasise that don’t need to need to know how to code in order to have a professional-looking website. But there’s a parallel universe of more niche no-code tools where the emphasis is on creativity and self-expression instead of slickness and professionalism.
Create your own free website. Unlimited creativity, zero ads.
Make a website in 5 minutes. Messy encouraged.
unique tool for web publishing & internet samizdat
I’m kind of fascinated by these two different approaches: professional vs. expressionist.
I’ve seen people grapple with this question when they decide to have their own website. Should it be a showcase of your achievements, almost like a portfolio? Or should it be a glorious mess of imagery and poetry to reflect your creativity? Could it be both? (Is that even doable? Or desirable?)
Robin Sloan recently published his ideas—and specs—for a new internet protocol called Spring ’83:
Spring ‘83 is a protocol for the transmission and display of something I am calling a “board”, which is an HTML fragment, limited to 2217 bytes, unable to execute JavaScript or load external resources, but otherwise unrestricted. Boards invite publishers to use all the richness of modern HTML and CSS. Plain text and blue links are also enthusiastically supported.
It’s not a no-code tool (you need to publish in HTML), although someone could easily provide a no-code tool to sit on top of the protocol. Conceptually though, it feels like it’s an a similar space to the chaotic good of neocities.org, mmm.page, and hotglue.me with maybe a bit of tilde.town thrown in.
It feels like something might be in the air. With Spring ’83, the Block protocol, and other experiments, people are creating some interesting small pieces that could potentially be loosely joined. No code required.
I met up with a supersmart programmer friend of mine a little while back. He was describing some work he was doing with React. He was joining up React components. There wasn’t really any problem-solving or debugging—the individual components had already been thoroughly tested. He said it felt more like construction than programming.
My immediate thought was “that should be automated.”
Or at the very least, there should be some way for just about anyone to join those pieces together rather than it requiring a supersmart programmer’s time. After all, isn’t that the promise of design systems and components—freeing us up to tackle the meaty problems instead of spending time on the plumbing?
I thought about that conversation when I was listening to Laurie’s excellent talk in Berlin last month.
Chatting to Laurie before the talk, he was very nervous about the conclusion that he had reached and was going to share: that the time is right for web development to be automated. He figured it would be an unpopular message. Heck, even he didn’t like it.
But I reminded him that it’s as old as the web itself. I’ve seen videos from very early World Wide Web conferences where Tim Berners-Lee was railing against the idea that anyone would write HTML by hand. The whole point of his WorldWideWeb app was that anyone could create and edit web pages as easily as word processing documents. It’s almost an accident of history that HTML happened to be just easy enough—but also just powerful enough—for many people to learn and use.
Anyway, I thoroughly enjoyed Laurie’s talk. (Except for a weird bit where he dunks on people moaning about “the fundamentals”. I think it’s supposed to be punching up, but I’m not sure that’s how it came across. As Chris points out, fundamentals matter …at least when it comes to concepts like accessibility and performance. I think Laurie was trying to dunk on people moaning about fundamental technologies like languages and frameworks. Perhaps the message got muddled in the delivery.)
I guess Laurie was kind of talking about this whole “no code” thing that’s quite hot right now. Personally, I would love it if the process of making websites could be democratised more. I’ve often said that my nightmare scenario for the World Wide Web would be for its fate to lie in the hands of an elite priesthood of programmers with computer science degrees. So I’m all in favour of no-code tools …in theory.
The problem is that unless they work 100%, and always produce good accessible performant code, then they’re going to be another example of the law of leaky abstractions. If a no-code tool can get someone 90% of the way to what they want, that seems pretty good. But if that person than has to spend an inordinate amount of time on the remaining 10% then all the good work of the no-code tool is somewhat wasted.
Funnily enough, the person who coined that law, Joel Spolsky, spoke right after Laurie in Berlin. The two talks made for a good double bill.
(I would link to Joel’s talk but for some reason the conference is marking the YouTube videos as unlisted. If you manage to track down a URL for the video of Joel’s talk, let me know and I’ll update this post.)
In a way, Joel was making the same point as Laurie: why is it still so hard to do something on the web that feels like it should be easily repeatable?
He used the example of putting an event online. Right now, the most convenient way to do it is to use a third-party centralised silo like Facebook. It works, but now the business model of Facebook comes along for the ride. Your event is now something to be tracked and monetised by advertisers.
You could try doing it yourself, but this is where you’ll run into the frustrations shared by Joel and Laurie. It’s still too damn hard and complicated (even though we’ve had years and years of putting events online). Despite what web developers tell themselves, making stuff for the web shouldn’t be that complicated. As Trys put it:
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.
And yet here we are. You can either have the convenience of putting something on a silo like Facebook, or you can have the freedom of doing it yourself, indie web style. But you can’t have both it seems.
This is a criticism often levelled at the indie web. The barrier to entry to having your own website is too high. It’s a valid criticism. To have your own website, you need to have some working knowledge of web hosting and at least some web technologies (like HTML).
Don’t get me wrong. I love having my own website. Like, I really love it. But I’m also well aware that it doesn’t scale. It’s unreasonable to expect someone to learn new skills just to make a web page about, say, an event they want to publicise.
That’s kind of the backstory to the project that Joel wanted to talk about: the block protocol. (Note: it has absolutely nothing to do with blockchain—it’s just an unfortunate naming collision.)
The idea behind the project is to create a kind of crowdsourced pattern library—user interfaces for creating common structures like events, photos, tables, and lists. These patterns already exist in today’s silos and content management systems, but everyone is reinventing the wheel independently. The goal of this project is make these patterns interoperable, and therefore portable.
At first I thought that would be a classic /927 situation, but I’m pleased to see that the focus of the project is not on formats (we’ve been there and done that with microformats, RDF, schema.org, yada yada). The patterns might end up being web components or they might not. But the focus is on the interface. I think that’s a good approach.
That approach chimes nicely with one of the principles of the indie web:
UX and design is more important than protocols, formats, data models, schema etc. We focus on UX first, and then as we figure that out we build/develop/subset the absolutely simplest, easiest, and most minimal protocols and formats sufficient to support that UX, and nothing more. AKA UX before plumbing.
That said, I don’t think this project is a cure-all. Interoperable (portable) chunks of structured content would be great, but that’s just one part of the challenge of scaling the indie web. You also need to have somewhere to put those blocks.
Convenience isn’t the only thing you get from using a silo like Facebook, Twitter, Instagram, or Medium. You also get “free” hosting …until you don’t (see GeoCities, MySpace, and many, many more).
Wouldn’t it be great if everyone had a place on the web that they could truly call their own? Today you need to have an uneccesary degree of technical understanding to publish something at a URL you control.
I’d love to see that challenge getting tackled.
An account of the mother of all demos, written by Steven Johnson.
I’m 100% convinced that working demo-to-demo is the secret formula to making successful creative products.
Now you can play a demo of Townscaper right in your browser.
There goes your productivity.
Here’s the thing: we need politics in the workplace. Politics—that is, the act of negotiating our relationships and obligations to each other—is critical to the work of building and sustaining democracy. And the workplace isn’t separate from democracy—it is democracy. It is as much a part of the democratic system as a neighborhood association or a town council, as a library or youth center or food bank. By the very nature of the outsized role that work plays in our lives, it’s where most of us have the potential to make the biggest impact on how we—and our families and communities—live.
Mandy, as always, hits the nail on the head.
When we talk about politics belonging outside the workplace, we reduce democracy to an extracurricular instead of a core part of our lives. Democracy cannot be sustained by annual visits to the ballot box—it isn’t something we have, it’s something we practice. Like all things that require practice, if you don’t practice it often, you lose it.
Container queries are like buses: you’re waiting for ages and then two come along at once.
This switch() syntax looks interesting.
After writing about a declarative Web Share API here yesterday I thought I’d better share the idea (see what I did there?).
I opened an issue on the Github repo for the spec.
(I hope that’s the right place for this proposal. I know that in the past ideas were kicked around on the Discourse site for Web platform Incubator Community Group but I can’t stand Discourse. It literally requires JavaScript to render anything to the screen even though the entire content is text. If it turns out that that is the place I should’ve posted, I guess I’ll hold my nose and do it using the most over-engineered reinvention of the browser I’ve ever seen. But I believe that the plan is for WICG to migrate proposals to Github anyway.)
I also realised that, as the JavaScript Web Share API already exists, I can use it to polyfill my suggestion for:
<button type="share">
The polyfill also demonstrates how feature detection could work. Here’s the code.
This polyfill takes an Inception approach to feature detection. There are three nested levels:
button type="share". Great! Don’t do anything. Otherwise proceed to level two.mailto: link to prefill an email with the page title as the subject and the URL in the body. Ya basic!The idea is that, as long as you include the 20 lines of polyfill code, you could start using button type="share" in your pages today.
I’ve made a test page on Codepen. I’m just using plain text in the button but you could use a nice image or SVG or combination. You can use the Codepen test page to observe two of the three possible behaviours browsers could exhibit:
button type="share". Currently that’s none because I literally made this shit up yesterday.button type="share" nor the existing JavaScript Web Share API. This is Firefox and Chrome on desktop (and Edge if you’re on a Mac).See the Pen Polyfill for button type=”share" by Jeremy Keith (@adactio) on CodePen.
The polyfill doesn’t support Internet Explorer 11 or lower because it uses the DOM closest() method. Feel free to fork and rewrite if you need to support old IE.
I’m usually building one of three things: a demo, a prototype, or a minimum viable product (MVP).
I’ve seen some confusion over these terms — some people seem to use them somewhat interchangeable. But they’re not the same thing, and building one when you need another can cause problems.
This is a very useful distinction!