Subscribe: Adactio
Added By: Feedage Forager Feedage Grade B rated
Language: English
conference  container queries  container  css  day  design  it’s  patterns day  patterns  progressive web  queries  web 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Adactio

Adactio: Journal

The online journal of Jeremy Keith, an author and web developer living and working in Brighton, England.


Posting to my site

Wed, 26 Jul 2017 12:14:58 GMT

I was idly thinking about the different ways I can post to I decided to count the ways. Admin interface This is the classic CMS approach. In my case the CMS is a crufty hand-rolled affair using PHP and MySQL that I wrote years ago. I log in to an admin interface and fill in a form, putting the text of my posts into a textarea. In truth, I usually write in a desktop text editor first, and then paste that into the textarea. That’s what I’m doing now—copying and pasting Markdown from the Typed app. Directly from my site If I’m logged in, I get a stripped down posting interface in the notes section of my site. Bookmarklet This is how I post links. When I’m at a URL I want to bookmark, I hit the “Bookmark it” bookmarklet in my browser’s bookmarks bar. That pops open a version of the admin interface tailored specifically for links. I really, really like bookmarklets. The one big downside is that they don’t work on mobile. Text message This is something I knocked together at Indie Web Camp Brighton 2015 using the Twilio API. It’s handy for posting notes if I’m travelling somewhere and data is at a premium. But I don’t use it that often. Instagram Thanks to Aaron’s OwnYourGram service—and the fact that my site has a micropub endpoint—I can post images from Instagram to my site. This used to happen instantaneously but Instagram changed their API rules for the worse. Between that and their shitty “algorithmic” timeline, I find myself using the service less and less. At this point I’m only on their for the doggos. Swarm Like OwnYourGram, Aaron’s OwnYourSwarm allows me to post check-ins and photos from the Swarm app to my site. Again, micropub makes it all possible. OwnYourGram and OwnYourSwarm are very similar and could probably be abstracted into a generic service for posting from third-party apps to micropub endpoints. I’d quite like to post my check-ins on Untappd to my site. Other people’s admin interfaces Thanks to rel="me" and IndieAuth, I can log into other people’s posting interfaces using my own website as the log-in, and post to my micropub endpoint, like this. Quill is a good example of this. I don’t use it that much, but I really should—the editor interface is quite Medium-like in its design. Anyway, those are the different ways I can update my website that I can think of right now. Syndication In terms of output, I’ve got a few different ways of syndicating what I post here: RSS feeds for my journal, links, articles, and notes. JSON feeds for my journal, links, articles, and notes. Twitter accounts for my journal, links, articles, and notes (that one is my main Twitter account). I syndicate most of my my photos to my Flickr account. I syndicate most of my journal posts and articles to my Medium account. I used to syndicate my links to my Delicious account but at some point that became fairly pointless. Whenever I post a link, The Internet Archive gets pinged and makes a copy for the wayback machine. Here’s an example of a recent link. I syndicate just about everything to my Facebook account using If This, Then That recipes (RSS to Facebook posts). Facebook is a roach motel. I never post any original content there—everything starts here on my site. Just so you know, if you comment on one of my posts on Facebook, I probably won’t see it. But if you reply to a copy of one of posts on Twitter or Instagram, it will show up over here on thanks to the magic of and webmention. [...]


Wed, 26 Jul 2017 11:26:07 GMT

I was listening to some items in my Huffduffer feed when I noticed a little bit of synchronicity.

First of all, I was listening to Tom talking about Thington, and he mentioned seamful design—the idea that “seamlessness” is not necessarily a desirable quality. I think that’s certainly true in the world of connected devices.

Then I listened to Jeff interviewing Matt about hardware startups. They didn’t mention seamful design specifically (it was more all cricket and cables), but again, I think it’s a topic that’s lurking behind any discussion of the internet of things.

I’ve written about seams before. I really feel there’s value—and empowerment—in exposing the points of connection in a system. When designers attempt to airbrush those seams away, I worry that they are moving from “Don’t make me think” to “Don’t allow me to think”.

In many ways, aiming for seamlessness in design feels like the easy way out. It’s a surface-level approach that literally glosses over any deeper problems. I think it might be driven my an underlying assumption that seams are, by definition, ugly. Certainly there are plenty of daily experiences where the seams are noticeable and frustrating. But I don’t think it needs to be this way. The real design challenge is to make those seams beautiful.

Putting on a conference

Mon, 24 Jul 2017 12:53:59 GMT

It’s been a few weeks now since Patterns Day and I’m still buzzing from it. I might be biased, but I think it was a great success all ‘round—for attendees, for speakers, and for us at Clearleft organising the event. I first had the idea for Patterns Day quite a while back. To turn the idea into reality meant running some numbers. Patterns Day wouldn’t have been possible without Alis. She did all the logistical work—the hard stuff—which freed me up to concentrate on the line-up. I started to think about who I could invite to speak, and at the same time, started looking for a venue. I knew from the start that I wanted it to be one-day single-track conference in Brighton, much like Responsive Day Out. I knew I wouldn’t be able to use the Corn Exchange again—there’s extensive rebuilding going on there this year. I put together a shortlist of Brighton venues and Alis investigated their capacities and costs, but to be honest, I knew that I wanted to have it in the Duke Of York’s. I love that place, and I knew from attending FFconf that it makes for an excellent conference venue. The seating capacity of the Duke Of York’s is quite a bit less than the Corn Exchange, so I knew the ticket price would have to be higher than that of Responsive Day Out. The Duke Of York’s isn’t cheap to rent for the day either (but worth every penny). To calculate the ticket price, I had to figure out the overall costs: Venue hire, A/V hire, Printing costs (for name badges, or in this case, stickers), Payment provider commission—we use Stripe through the excellent, Speaker’s travel, Speaker’s accommodation, Speaker’s dinner the evening before the event, Speaker’s payment. Some conference organisers think they can skimp on that last part. Those conference organisers are wrong. A conference is nothing without its speakers. They are literally the reason why people buy tickets. Because the speakers make or break a conference, there’s a real temptation to play it safe and only book people who are veterans. But then you’re missing out on a chance to boost someone when they’re just starting out with public speaking. I remember taking a chance on Alla a few years back for Responsive Day Out 3—she had never given a conference talk before. She, of course, gave a superb talk. Now she’s speaking at events all over the world, and I have to admit, it gives me a warm glow inside. When it came time for Patterns Day, Alla had migrated into the “safe bet” category—I knew she’d deliver the perfect closing keynote. I understand why conference organisers feel like they need to play it safe. From their perspective, they’re already taking on a lot of risk in putting on a conference in the first place. It’s easy to think of yourself as being in a position of vulnerability—”If I don’t sell enough tickets, I’m screwed!” But I think it’s important to realise that you’re also in a position of power, whether you like it or not. If you’re in charge of putting together the line-up of a conference, that’s a big responsibility, not just to the attendees on the day, but to the community as a whole. It’s like that quote by Eliel Saarinen: Always design a thing by considering it in its next larger context. A chair in a room, a room in a house, a house in an environment, an environment in a city plan. Part of that responsibility to the wider community is representation. That’s why I fundamentally disagree with ppk when he says: The other view would be that there should be 50% woman speakers. Although that sounds great I personally never believed in this argument. It’s based on the general population instead of the population of web developers, and if we’d extend that argument to its logical conclusion then 99.9% of the web development conference speakers should know nothing about web development, since that’s the rough ratio in the general population. That makes it sound like a conference’s job is to represent the [...]

Container queries

Thu, 20 Jul 2017 12:35:45 GMT

Every single browser maker has the same stance when it comes to features—they want to hear from developers at the coalface. “Tell us what you want! We’re listening. We want to know which features to prioritise based on real-world feedback from developers like you.” “How about container quer—” “Not that.” I don’t think it’s an exaggeration to say that literally every web developer I know would love to have container queries. If you’ve worked on any responsive project of any size, you’re bound to have bumped up against the problem of only being able to respond to viewport size, rather than the size of the containing element. Without container queries, our design systems can never be truly modular. But there’s a divide growing between what our responsive designs need to do, and the tools CSS gives us to meet those needs. We’re making design decisions at smaller and smaller levels, but our code asks us to bind those decisions to a larger, often-irrelevant abstraction of a “page.” But the message from browser makers has consistently been “it’s simply too hard.” At the Frontend United conference in Athens a little while back, Jonathan gave a whole talk on the need for container queries. At the same event, Serg gave a talk on Houdini. Now, as I understand it, Houdini is the CSS arm of the extensible web. Just as web components will allow us to create powerful new HTML without lobbying browser makers, Houdini will allow us to create powerful new CSS features without going cap-in-hand to standards bodies. At this year’s CSS Day there were two Houdini talks. Tab gave a deep dive, and Philip talked specifically about Houdini as a breakthrough for polyfilling. During the talks, you could send questions over Twitter that the speaker could be quizzed on afterwards. As Philip was talking, I began to tap out a question: “Could this be used to polyfill container queries?” My thumb was hovering over the tweet button at the very moment that Philip said in his talk, “This could be used to polyfill container queries.” For that happen, browsers need to implement the layout API for Houdini. But I’m betting that browser makers will be far more receptive to calls to implement the layout API than calls for container queries directly. Once we have that, there are two possible outcomes: We try to polyfill container queries and find out that the browser makers were right—it’s simply too hard. This certainty is itself a useful outcome. We successfully polyfill container queries, and then instead of asking browser makers to figure out implementation, we can hand it to them for standardisation. But, as Eric Portis points out in his talk on container queries, Houdini is still a ways off (by the way, browser makers, that’s two different conference talks I’ve mentioned about container queries, just in case you were keeping track of how much developers want this). Still, there are some CSS features that are Houdini-like in their extensibility. Custom properties feel like they could be wrangled to help with the container query problem. While it’s easy to think of custom properties as being like Sass variables, they’re much more powerful than that—the fact they can be a real-time bridge between JavaScript and CSS makes them scriptable. Alas, custom properties can’t be used in media queries but maybe some clever person can figure out a way to get the effect of container queries without a query-like syntax. However it happens, I’d just love to see some movement on container queries. I’m not alone. I know container queries would revolutionize my design practice, and better prepare responsive design for mobile, desktop, tablet—and whatever’s coming next. [...]

The magical and the mundane

Wed, 19 Jul 2017 10:53:12 GMT

The iPhone—and by extension, the smartphone—is a decade old. Ian Bogost has written an interesting piece in The Atlantic charting our changing relationship with the technology.

First, it was like a toy dog:

A device that could be cared for, and conspicuously so.

Then, it was like a cigarette:

A nervous tic, facilitated by a handheld apparatus that releases relief when operated.

Later, it was like a rosary:

Its toy-dog quirks having been tamed, its compulsive nature having been accepted, the iPhone became the magic wand by which all worldly actions could be performed, all possible information acquired.

Finally, it simply becomes …a rectangle.

Abstract, as a shape. Flat, as a surface. But suggestive of so much. A table for community. A door for entry, or for exit. A window for looking out of, or a picture for looking into. A movie screen for distraction, or a cradle for comfort, or a bed for seduction.

Design dissolves in behaviour. This is something that Ben wrote about recently in his excellent Slapdashery series: “Everything’s amazing and nobody’s happy.”

Technology tweaks our desire for novelty; but as soon as we get it we’re usually bored. There are no technologies that I can think of that haven’t become mundane.

This is something I touched on in my talk last year at An Event Apart. There’s a thread throughout the talk about Arthur C. Clarke, and of course I quote his third law:

Any sufficiently advanced technology is indistinguishable from magic.

I propose an addendum to that:

Any sufficiently advanced technology is indistinguishable from magic at first.

The magical quickly becomes the mundane. That’s exactly the point that Louis CK is making in the piece that Ben references.

Seven years ago Frank wrote his wonderful essay There Is A Horse In The Apple Store:

I have a term called a “tiny pony.” It is a thing that is exceptional that no one, for whatever reason, notices. Or, conversely, it is an exceptional thing that everyone notices, but quickly grows acclimated to despite the brilliance of it all.

We are surrounded by magical tiny ponies. I mean, just think: right now you are reading some words at a URL on the World Wide Web. Even more magically, I just published some words at my own URL on the World Wide Web. That still blows my mind! I hope I never lose that feeling.


Tue, 18 Jul 2017 17:44:35 GMT

Last month I went to CSS Day in Amsterdam, as an attendee this year, not a speaker. It was an excellent conference comprising the titular CSS day and a Browser API Special the day before.

By the end of CSS Day, my brain was full. Experiencing the depth of knowledge that’s contained in CSS now made me appreciate how powerful a language it is. I mean, the basics of CSS—selectors, properties, and values—can be grasped in a day. But you can spend a lifetime trying to master the details. Heck, you could spend a lifetime trying to master just one part of CSS, like layout, or text. And there would always be more to learn.

Unlike a programming language that requires knowledge of loops, variables, and other concepts, CSS is pretty easy to pick up. Maybe it’s because of this that it has gained the reputation of being simple. It is simple in the sense of “not complex”, but that doesn’t mean it’s easy. Mistaking “simple” for “easy” will only lead to heartache.

I think that’s what’s happened with some programmers coming to CSS for the first time. They’ve heard it’s simple, so they assume it’s easy. But then when they try to use it, it doesn’t work. It must be the fault of the language, because they know that they are smart, and this is supposed to be easy. So they blame the language. They say it’s broken. And so they try to “fix” it by making it conform to a more programmatic way of thinking.

I can’t help but think that they would be less frustrated if they would accept that CSS is not easy. Simple, yes, but not easy. Using CSS at scale has a learning curve, just like any powerful technology. The way to deal with that is not to hammer the technology into a different shape, but to get to know it, understand it, and respect it.

Patterns Day videos

Tue, 11 Jul 2017 16:55:48 GMT

Eleven days have passed since Patterns Day. I think I’m starting to go into withdrawal.

Fortunately there’s a way to re-live the glory. Video!

The first video is online now: Laura Elizabeth’s excellent opener. More videos will follow. Keep an eye on this page.

And remember, the audio is already online as a podcast.


Mon, 10 Jul 2017 00:47:41 GMT

I like words. I like the way they can be tethered together to produce a satisfying sentence.

Jessica likes words even more than I do (that’s why her website is called “wordridden”). She studied linguistics and she’s a translator by trade—German into English. Have a read of her post about translating Victor Klemperer to get an inkling of how much thought and care she puts into it.

Given the depth of enquiry required for a good translation, I was particularly pleased to read this remark by John Le Carré:

No wonder then that the most conscientious editors of my novels are not those for whom English is their first language, but the foreign translators who bring their relentless eye to the tautological phrase or factual inaccuracy – of which there are far too many. My German translator is particularly infuriating.

That’s from an article called Why we should learn German, but it’s really about why we should strive for clarity in our use of language:

Clear language — lucid, rational language — to a man at war with both truth and reason, is an existential threat. Clear language to such a man is a direct assault on his obfuscations, contradictions and lies. To him, it is the voice of the enemy. To him, it is fake news. Because he knows, if only intuitively, what we know to our cost: that without clear language, there is no standard of truth.

It reminds me of one of my favourite Orwell essays, Politics and the English Language:

Political language — and with variations this is true of all political parties, from Conservatives to Anarchists — is designed to make lies sound truthful and murder respectable, and to give an appearance of solidity to pure wind.

But however much I agree with Le Carré’s reprise of Orwell’s call for clarity, I was brought up short by this:

Every time I hear a British politician utter the fatal words, “Let me be very clear”, these days I reach for my revolver.

Le Carré’s text was part of a speech given in Berlin, where everyone would get the reference to the infamous Nazi quote—Wenn ich Kultur höre … entsichere ich meinen Browning—and I’m sure it was meant with a sly wink. But words matter.

Words are powerful. Words can be love and comfort — and words can be weapons.

Patterns Day

Sun, 02 Jul 2017 18:08:36 GMT

Patterns Day is over. It was all I hoped it would be and more. I’ve got that weird post-conference feeling now, where that all-consuming thing that was ahead of you is now behind you, and you’re not quite sure what to do. Although, comparatively speaking, Patterns Day came together pretty quickly. I announced it less than three months ago. It sold out just over a month later. Now it’s over and done with, it feels like a whirlwind. The day itself was also somewhat whirlwind-like. It was simultaneously packed to the brim with great talks, and yet over in the blink of an eye. Everyone who attended seemed to have a good time, which makes me very happy indeed. Although, as I said on the day, while it’s nice that everyone came along, I put the line-up together for purely selfish reasons—it was my dream line-up of people I wanted to see speak. Boy, oh boy, did they deliver the goods! Every talk was great. And I must admit, I was pleased with how I had structured the event. The day started and finished with high-level, almost philosophical talks; the mid section was packed with hands-on nitty-gritty practical examples. Thanks to sponsorship from Amazon UK, Craig was videoing all the talks. I’ll get them online as soon as I can. But in the meantime, Drew got hold of the audio and made mp3s of each talk. They are all available in handy podcast form for your listening and huffduffing pleasure: Patterns Day: Laura Elizabeth on Huffduffer Laura Elizabeth Patterns Day: Ellen de Vries on Huffduffer Ellen de Vries Patterns Day: Sareh Heidari on Huffduffer Sareh Heidari Patterns Day: Rachel Andrew on Huffduffer Rachel Andrew Patterns Day: Alice Bartlett on Huffduffer Alice Bartlett Patterns Day: Jina Anne on Huffduffer Jina Anne Patterns Day: Paul Lloyd on Huffduffer Paul Lloyd Patterns Day: Alla Kholmatova on Huffduffer Alla Kholmatova If you’re feeling adventurous, you can play the Patterns Day drinking game while you listen to the talks: Any time someone says “Lego”, take a drink, Any time someone references Chrisopher Alexander, take a drink, Any time someone says that naming things is hard, take a drink, Any time says “atomic design”, take a drink, and Any time says “Bootstrap”, puke the drink back up. In between the talks, the music was provided courtesy of some Brighton-based artists Hidde de Vries has written up an account of the day. Stu Robson has also published his notes from each talk. Sarah Drummond wrote down her thoughts on Ev’s blog. I began the day by predicting that Patterns Day would leave us with more questions than answers …but that they would be the right questions. I think that’s pretty much what happened. Quite a few people compared it to the first Responsive Day Out in tone. I remember a wave of relief flowing across the audience when Sarah opened the show by saying: I think if we were all to be a little more honest when we talk to each other than we are at the moment, the phrase “winging it” would be something that would come up a lot more often. If you actually speak to people, not very many people have a process for this at the moment. Most of us are kind of winging it. This is hard. No one knows exactly what they’re doing. Nobody has figured this out yet. Those sentiments were true of responsive design in 2013, and they’re certainly true of design systems in 2017. That’s why I think it’s so important that we share our experiences—good and bad—as we struggle to come to grips with these challenges. That’s why I put Patterns Day together. That’s also why, at the end of the day, I thanked everyone who has ever written about, spoken about, or otherwise shared their experience with design systems, pattern libraries, style guides, and[...]

Progressing the web

Tue, 27 Jun 2017 11:06:45 GMT

Frances has written up some of the history behind her minting of the term “progressive web app”. She points out that accuracy is secondary to marketing: I keep seeing folks (developers) getting all smart-ass saying they should have been PW “Sites” not “Apps” but I just want to put on the record that it doesn’t matter. The name isn’t for you and worrying about it is distraction from just building things that work better for everyone. The name is for your boss, for your investor, for your marketeer. Personally, I think “progressive web app” is a pretty good phrase—two out of three words in it are spot on. I really like the word “progressive”, with its echoes of progressive enhancement. I really, really like the word “web”. But, yeah, I’m one of those smart-asses who points out that the “app” part isn’t great. That’s not just me being a pedant (or, it’s not only me being a pedant). I’ve seen people who were genuinely put off investigating the technologies behind progressive web apps because of the naming. The name is one of the reasons I didn’t look into PWAs 6 months ago. Can we change the name itself? 😎— Julian Gaviria (@juliangav) March 24, 2017 Here’s an article with the spot-on title Progressive Web Apps — The Next Step In Responsive Web Design: Late last week, Smashing Magazine, one of the largest and most influential online publications for web design, posted on Facebook that their website was “now running as a Progressive Web App.” Honestly, I didn’t think much of it. Progressive Web Apps are for the hardcore web application developers creating the next online cloud-based Photoshop (complicated stuff), right? I scrolled on and went about my day. And here’s someone feeling the cognitive dissonance of turning a website into a progressive web app, even though that’s exactly the right thing to do: My personal website is a collection of static HTML files and is also a progressive web app. Transforming it into a progressive web app felt a bit weird in the beginning because it’s not an actual application but I wanted to be one of the cool kids, and PWAs still offer a lot of additional improvements. Still, it could well be that these are the exceptions and that most people are not being discouraged by the “app” phrasing. I certainly hope that there aren’t more people out there thinking “well, progressive web apps aren’t for me because I’m building a content site.” In short, the name might not be perfect but it’s pretty damn good. What I find more troubling is the grouping of unrelated technologies under the “progressive web app” banner. If Google devrel events were anything to go by, you’d be forgiven for thinking that progressive web apps have something to do with AMP or Polymer (they don’t). One of the great things about progressive web apps is that they are agnostic to tech stacks. Still, I totally get why Googlers would want to use the opportunity to point to their other projects. Far more troubling is the entanglement of the term “progressive web app” with the architectural choice of “single page app”. I’m not the only one who’s worried about this. I’ve seen too many devs assume PWA is a subset of SPA. We need to improve our messaging— Jake Archibald (@jaffathecake) June 4, 2016 Here’s the most egregious example: an article on Hacker Noon called Before You Build a PWA You Need a SPA. No! Not true! Literally any website can be a progressive web app: switch over to HTTPS, add a JSON manifest file with your metacrap, and add a service worker. That last step can be tricky if you’re new to service workers, but it’s not unsurmountable. It’s certainly a lot easier than completely rearchitecting your existing website to b[...]