| 5th | 10th | 15th | 20th | 25th | 30th | ||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 12am | |||||||||||||||||||||||||||||||
| 4am | |||||||||||||||||||||||||||||||
| 8am | |||||||||||||||||||||||||||||||
| 12pm | |||||||||||||||||||||||||||||||
| 4pm | |||||||||||||||||||||||||||||||
| 8pm |
This great post by Hui Jing is ostensibly about CSS shapes and exclusions, but there’s a much broader message too:
Build demos, and play around with anything that seems remotely interesting. Even if that feature is in early stages, or only supported by 1 browser. And then talk about it, or write and tweet about your experience, your use cases, what you liked or disliked about it.
We can shape the web to what we want it to be, but only if we get involved.
I’m impressed by Mozilla’s commitment to designing in the open—one of the hardest parts of any kind of brand work is getting agreement, and this process must make that even more difficult.
I have to say, I quite like both options on display here.
A great collection of styled and accessible form elements:
Form controls are necessary in many interfaces, but are often considered annoying, if not downright difficult, to style. Many of the markup patterns presented here can serve as a baseline for building more attractive form controls without having to exclude users who may rely on assistive technology to get things done.
Some interesting ideas for evolving the web browser. I’m very interested in the ideas about navigating our browser history—that feels like a very underappreciated goldmine with a direct lineage to the “associative trails” imagined for the memex.
Magnets: How Do They Work?
Magnetism might be the most romantic of all the topics in science to be metaphorically butchered by poets.
A forthcoming documentary about the company spun out of Apple to create a handheld communication device …in 1990.
From mobile computing, social media, downloadable apps and e-commerce to touchscreens, emoji and USB, the products and services that now dominate the tech industry and our day-to-day lives were born at General Magic.
Focusing on the median or average is the equivalent of walking around with a pair of blinders on. We’re limiting our perspective and, in the process, missing out on so much crucial detail. By definition, when we make improving the median or average our goal, we are focusing on optimizing for only about half of our sessions.
Tim does the numbers…
By honing in on the 90th—or 95th or similar—we ensure those weaknesses don’t get ignored. Our goal is to optimize the performance of our site for the majority of our users—not just a small subset of them.
This piece by @rauchg has aged very well in the last four years…
https://rauchg.com/2014/7-principles-of-rich-web-applications
Another great video from Jen as part of her Layout Land series. This time she addresses the question of the overwhelming technology landscape for developers and where they should invest their time.
She references my most recent talk, where I’ve been drawing a distinction between “materials” (HTML, CSS, JavaScript) and “tools” (everything else).
On the beach.
Um …if I’m reading this right, then my IFTTT recipe will also stop working and my Facebook activity will drop to absolute zero.
Oh, well. No skin off my nose. Facebook is a roach motel in more ways than one.
Delicious food from @mestiza.filipina last night—a real treat!
Aw, this is so nice! Chris points to the way that The Session generates sheet music from abc text:
The SVG conversion is made possible entirely in JavaScript by an open source library. That’s the progressive enhancement part. Store and ship the basic format, and let the browser enhance the experience, if it can (it can).
Here’s another way of thinking of it: I was contacted by a blind user of The Session who hadn’t come across abc notation before. Once they realised how it worked, they said it was like having alt text for sheet music! 🤯
Fascinating snippets of information about some of the most interesting buildings in Brighton.
(The website was made by Lydia and Tash as a project for Code First: Girls)
’Twas an honour to host the @CodebarBrighton WebGL workshop in @68MiddleSt on the weekend—thank you to everyone who gave up their Saturday for this!
Ascension.
Checked in at Murmur. 🐟 — with Jessica
Big waves in Brighton.
Anchor seems to be going for the YouTube model. They want a huge number of people to use their platform. But the concentration of so much media in one place is one of the problems with today’s web. Massive social networks like Facebook, Instagram, and YouTube have too much power over writers, photographers, and video creators. We do not want that for podcasts.
“It’s almost too easy now, and too unsatisfying that you only can put your work in a community full of advertisements and full of tracking,” she said. “I think there will be this urge, on the one hand, to have a local internet of small communities, and, on the other hand, a decentralized internet again.”
“You can still make websites nowadays,” Heemskerk said. “People think it’s complex, but it isn’t —you just register your domain and make your website and that’s about it.”
The petrichor cometh!
The slides and video from a really great well-rounded talk by Aaron, filled with practical examples illustrating concepts like progressive enhancement and inclusive design.
A directory of progressive web apps.
Bidding farewell to @Boxman on his last day at @Clearleft. 😢
A lovely bit of data visualisation from Nadieh showing the differences and commonalities in constellations across cultures. As always, she’s written up the process too.
Imagine if all the energy consumed by mining Bitcoin were used for SETI@home instead.
Or maybe that’s the solution to the Fermi paradox: the Great Filter is cryptocurrencies.
Danielle has posted a brief update on Fractal:
We decided to ask the Fractal community for help, and the response has been overwhelming. We’ve received so many offers of support in all forms that we can safely say that development will be starting up again shortly.
It’s so gratifying to see that other people are finding Fractal to be as useful to them as it is to us. We very much appreciate all their support!
Although Fractal itself is barely two years old, it’s part of a much longer legacy at Clearleft…
It all started with Natalie. She gave a presentation back in 2009 called Practical Maintainable CSS . She talks about something called a pattern porfolio—a deliverable that expresses every component and documents how the markup and CSS should be used.
When Anna was interning at Clearleft, she was paired up with Natalie so she was being exposed to these ideas. She then expanded on them, talking about Front-end Style Guides. She literally wrote the book on the topic, and starting curating the fantastic collection of examples at styleguides.io.
When Paul joined Clearleft, it was a perfect fit. He was already obsessed with style guides (like the BBC’s Global Experience Language) and started writing and talking about styleguides for the web:
At Clearleft, rather than deliver an inflexible set of static pages, we present our code as a series of modular components (a ‘pattern portfolio’) that can be assembled into different configurations and page layouts as required.
Such systematic thinking was instigated by Natalie, yet this is something we continually iterate upon.
To see the evolution of Paul’s thinking, you can read his three part series from last year on designing systems:
Later, Charlotte joined Clearleft as a junior developer, and up until that point, hadn’t been exposed to the idea of pattern libraries or design systems. But it soon became clear that she had found her calling. She wrote a brilliant article for A List Apart called From Pages to Patterns: An Exercise for Everyone and she started speaking about design systems at conferences like Beyond Tellerrand. Here, she acknowledges the changing terminology over the years:
Pattern portfolio is a term used by Natalie Downe when she started using the technique at Clearleft back in 2009.
Front-end style guides is another term I’ve heard a lot.
Personally, I don’t think it matters what you call your system as long as it’s appropriate to the project and everyone uses it. Today I’m going to use the term “pattern library”.
(Mark was always a fan of the term “component library”.)
Now Charlotte is a product manager at Ansarada in Sydney and the product she manages is …the design system!
Thinking back to my work on starting design systems, I didn’t realise straight away that I was working on a product. Yet, the questions we ask are similar to those we ask of any product when we start out. We make decisions on things like: design, architecture, tooling, user experience, code, releases, consumption, communication, and more.
It’s been fascinating to watch the evolution of design systems at Clearleft, accompanied by an evolution in language: pattern portfolios; front-end style guides; pattern libraries; design systems.
There’s been a corresponding evolution in prioritisation. Where Natalie was using pattern portfolios as a deliverable for handover, Danielle is now involved in the integration of design systems within a client’s team. The focus on efficiency and consistency that Natalie began is now expressed in terms of design ops—creating living systems that everyone is involved in.
When I step back and look at the history of design systems on the web, there are some obvious names that have really driven their evolution and adoption, like Jina Anne, Brad Frost, and Alla Kholmatova. But I’m amazed at the amount of people who have been through Clearleft’s doors that have contributed so, so much to this field:
Natalie Downe, Anna Debenham, Paul Lloyd, Mark Perkins, Charlotte Jackson, and Danielle Huntrods …thank you all!
I like the questions that the TELUS team ask about any potential components to be added to their design system:
- Is it on brand?
- Is it accessible?
- Has it been tested?
- Can it be reused?
They also have design principles.
Here’s an intriguing proposal that would allow web apps to indicate activity in an icon (like an unread count) in the same way that native apps can.
This is an interesting one because, in this case, it’s not just browsers that would have to implement it, but operating systems as well.
Thank you @iambenwhite for literally organising a piss-up in a brewery.
Conducting important @Clearleft research in Lewes.
I’ve become so used to using Instragram’s progressive web app that, on the rare occasions that I open the native app, I find the ads (and notification nudging) overwhelming.
Luke has written up the selection process he went through when Clearleft was designing the Virgin Holidays app. When it comes to deploying on mobile, there were three options:
The Virgin Holidays team went with that third option.
Now, it will come as no surprise that I’m a big fan of the second option: building a progressive web app (or turning an existing site into a progressive web app). I think a progressive web app is a great solution for travel apps, and the use-case that Luke describes sounds perfect:
Easy access to resort staff and holiday details that could be viewed offline to help as many customers as possible travel without stress and enjoy a fantastic holiday
Luke explains why they choice not to go with a progressive web app.
The current level of support and leap in understanding meant we’d risk alienating many of our customers.
The issue of support is one that is largely fixed at this point. When Clearleft was working on the Virgin Holidays app, service workers hadn’t landed in iOS. Hence, the risk of alienating a lot of customers. But now that Mobile Safari has offline capabilities, that’s no longer a problem.
But it’s the second reason that’s trickier:
Simply put, customers already expected to find us in the App Store and are familiar with what apps can historically offer over websites.
I think this is the biggest challenge facing progressive web apps: battling expectations.
For over a decade, people have formed ideas about what to expect from the web and what to expect from native. From a technical perspective, native and web have become closer and closer in capabilities. But people’s expectations move slower than technological changes.
First of all, there’s the whole issue of discovery: will people understand that they can “install” a website and expect it to behave exactly like a native app? This is where install prompts and ambient badging come in. I think ambient badging is the way to go, but it’s still a tricky concept to explain to people.
But there’s another way of looking at the current situation. Instead of seeing people’s expectations as a negative factor, maybe it’s an opportunity. There’s an opportunity right now for companies to be as groundbreaking and trendsetting as Wired.com when it switched to CSS for layout, or The Boston Globe when it launched its responsive site.
It makes for a great story. Just look at the Pinterest progressive web app for an example (skip to the end to get to the numbers):
Weekly active users on mobile web have increased 103 percent year-over-year overall, with a 156 percent increase in Brazil and 312 percent increase in India. On the engagement side, session length increased by 296 percent, the number of Pins seen increased by 401 percent and people were 295 percent more likely to save a Pin to a board. Those are amazing in and of themselves, but the growth front is where things really shined. Logins increased by 370 percent and new signups increased by 843 percent year-over-year. Since we shipped the new experience, mobile web has become the top platform for new signups. And for fun, in less than 6 months since fully shipping, we already have 800 thousand weekly users using our PWA like a native app (from their homescreen).
Now admittedly their previous mobile web experience was a dreadful doorslam, but still, those are some amazing statistics!
Maybe we’re underestimating the malleability of people’s expectations when it comes to the web on mobile. Perhaps the inertia we think we’re battling against isn’t such a problem as long as we give people a fast, reliable, engaging experience.
If you build that, they will come.
A very thoughtful post from Stuart, ostensibly about “view source”, but really about empowerment, choice, and respect.
I like that the web is made up of separate bits that you can see if you want to. You can understand how it works by piecing together the parts. It’s not meant to be a sealed unit, an appliance which does what the owner wants it to and restricts everything else. That’s what apps do. The web’s better than that.
Typography meets astronomy in 16th century books like the Astronomicum Caesareum.
It is arguably the most typographically impressive scientific manual of the sixteenth century. Owen Gingerich claimed it, “the most spectacular contribution of the book-maker’s art to sixteenth-century science.”
Sara shows a few different approaches to building accessible toggle switches:
Always, always start thinking about the markup and accessibility when building components, regardless of how small or simple they seem.
Some lovely little animation experiments from Cameron.
Like a government diverting money from defence to education, humans diverted energy from biceps to neurons.
— Sapiens
Reading Sapiens: A Brief History Of Humankind by Yuval Noah Harari.
Travelling back from Taipei to Blighty via Hong Kong’s nascent spaceport.
Checked in at The Long Bar. Killing time between flights — with Jessica
A nifty little responsive demo from Nick, recreating a 1948 Coca-Cola ad that was designed to be responsive to different wall spaces.
This is a perceptive overview of three different species of agencies—consulting-led, engineering-led, and design-led. Clearleft fits squarely into that last category …and the weaknesses of that particular flavour of agency ring very true:
Design firms have historically lacked the business strategy chops and pedigree of the consultants.
It will probably come as no surprise that Clearleft has been getting “more strategic” recently.
Design needs more MBAs with C-suite relationships and an almost arrogant assumption that of course they belong there, advising the CEO and truly bringing design thinking to business. It’s time to do strategy for real. The market has never been more receptive to it than it is right now.
There are of course things worth your time and deep consideration, and there are distractions. Profound new thinking and movements within our industry - the kind that fundamentally shifts the way we work in a positive new direction are worth your time and attention. Other things are distractions. I put new industry gossip, frameworks, software and tools firmly in the distractions category. This is the sort of content that exists in the padding between big movements. It’s the kind of stuff that doesn’t break new ground and it doesn’t make or break your ability to do your job.
Andy describes the technical approach he took building his handy reporting tool, My Browser:
Although the site is built with bleeding edge technology such as web components, it’s built with a progressive-first approach. This means that in order to get the best experience, you need to be on a modern browser, but to do the most basic function—reporting data, you can still do it by pressing a “generate report” button, which is the default state.
Not only is this a liberating way to work, it really pays off in performance:
We’re given so much for free to make a progressively enhanced website or web app. We’ve got feature detection and
@supportsin CSS which means that “My Browser” ships with no polyfills, fallbacks or hacks like Autoprefixer. The app degrades gracefully instead.This has been a very refreshing way to work that I’ve enjoyed a lot. The fact that the whole thing comes in around 25kb tells you how effective progressive enhancement can be for performance too.
Léonie makes a really good point here: if you’re adding aria attributes to indicate interactions you’re making available through JavaScript, then make sure you also use JavaScript to add those aria attributes.
This is a great description by Chris of the problems that webmentions aim to solve.
If you use Twitter, your friend Alice only uses Facebook, your friend Bob only uses his blog on WordPress, and your pal Chuck is over on Medium, it’s impossible for any one of you to @mention another. You’re all on different and competing platforms, none of which interoperate to send these mentions or notifications of them. The only way to communicate in this way is if you all join the same social media platforms, resulting in the average person being signed up to multiple services just to stay in touch with all their friends and acquaintances.
Given the issues of privacy and identity protection, different use cases, the burden of additional usernames and passwords, and the time involved, many people don’t want to do this. Possibly worst of all, your personal identity on the internet can end up fragmented like a Horcrux across multiple websites over which you have little, if any, control.
This is a great interview with Rich on all things related to web typography—including, of course, variable fonts.
I’m so lucky that I literally get to work side by side with Rich; I get to geek out with him about font stuff all the time.
Digital things look ‘finished’ too soon. When something is a work in progress on a wall, it looks unfinished, so you keep working on it. moving things around, reshaping things, connecting things, erasing things, and making them again. Walls make it easier to iterate. Iteration, in my opinion, is massively correlated with quality.
Ethan’s ode to the fr unit in CSS grid.
The web can be used to find common connections with folks you find interesting, and who don’t make you feel like so much of a weirdo. It’d be nice to be able to do this in a safe space that is not being surveilled.
Owning your own content, and publishing to a space you own can break through some of these barriers. Sharing your own weird scraps on your own site makes you easier to find by like-minded folks. If you’ve got no tracking on your site (no Google Analytics etc), you are harder to profile. People can’t come to harass you on your own site if you do not offer them the means to do so
Aubergine; fried tea leaves; Kung Po chicken; rice.
Distant 101.
Checked in at 四哥之店. Lunchtime feast — with Jessica
Checked in at 正大休閒茶園. Tea for two — with Jessica
Dumplings, dumplings, dumplings. 🥟
Tower and temple.
I like that this introduction to React doesn’t assume any knowledge (or desire) to create an entire app from scratch through command line invocations. Instead, here’s a clear explanation of how you can add React—which is, after all, some JavaScript—to an existing project. Oh, and you can write your CSS in CSS.
(Caveat: because everything’s happening in script elements in the browser, what’s outlined here will only do client-side rendering.)
The street and the tower.
I’m a fan of fast websites. Your website needs to be fast. Our collective excuses, hand-wringing, and inability to come to terms with the problem-set (There is too much script) and solutions (Use less script) of modern web development is getting tired.
I agree with every word of this.
Sadly, I think the one company with a browser that has marketshare dominance and could exert the kind of pressure required to stop ad tracking and surveillance capitalism is not incentivized to do so.
So the problem is approached from the other end. Blame is piled on authors for slow first-party code. We’re told to use certain mobile publishing frameworks that syndicate to proprietary CDNs to appease the gods of luck and fortune.
Craft.
Yong Kang Beef Noodle.
Erika has written a great guest post on Ev’s blog. It covers the meaning, the impact, and the responsibility of design …and how we’ve been chasing the wrong measurements of success.
We design for the experience of a single user at a time and expect that the collective experience, and the collective impact, will take care of itself.
Taipei from above.
Megastructure.
Roast pork.
Dumplings.
It’s possible to create components in a vacuum, but ultimately you have no idea whether or not those components can successfully address your user and business needs. I’ve witnessed firsthand several design system initiatives crash and burn due to components created in isolation.
A fun way to play around with the options in variable fonts.
Rachel follows up on my recent post about CSS grid in old IE with her thoughts.
As Jeremy notes, the usefulness of a tool like Autoprefixer is diminishing, which is a good thing. It is becoming far easier to code in a way that supports all browsers, where support means usable in an appropriate way for the technology the user has in front of them. Embrace that, and be glad for the fact that we can reduce complexity based on the increasing interoperability of CSS in our browsers.
Sesame noodles with miso egg soup.
National Palace Museum.
Blue skies and water.
Checked in at Taipei 101 (台北101). with Jessica
Checked in at National Palace Museum (國立故宮博物院). with Jessica
Street noodles.
Checked in at 福德涼麵. Sesame noodles and miso soup — with Jessica
Crab’n’clams. 🦀
Night market.
Chicken of the street.
Restorative beef noodle soup.
The streets of Taipei.
Welcome to Taipei.
Checked in at Gate 40. Next stop: Taipei — with Jessica
Going to Taipei. brb
Salads’n’wings.
Grillin’ chicken.
Codebar Barcelona meets Codebar Brighton!
When I was in Boston, speaking on a lunchtime panel with Rachel at An Event Apart, we took some questions from the audience about CSS grid. Inevitably, a question about browser support came up—specifically about support in Internet Explorer 11.
(Technically, you can use CSS grid in IE11—in fact it was the first browser to ship a version of grid—but the prefixed syntax is different to the standard and certain features are missing.)
Rachel gave a great balanced response, saying that you need to look at your site’s stats to determine whether it’s worth the investment of your time trying to make a grid work in IE11.
My response was blunter. I said I just don’t consider IE11 as a browser that supports grid.
Now, that might sound harsh, but what I meant was: you’re already dividing your visitors into browsers that support grid, and browsers that don’t …and you’re giving something to those browsers that don’t support grid. So I’m suggesting that IE11 falls into that category and should receive the layout you’re giving to browsers that don’t support grid …because really, IE11 doesn’t support grid: that’s the whole reason why the syntax is namespaced by -ms.
You could jump through hoops to try to get your grid layout working in IE11, as detailed in a three-part series on CSS Tricks, but at that point, the amount of effort you’re putting in negates the time-saving benefits of using CSS grid in the first place.
Frankly, the whole point of prefixed CSS is that is not used after a reasonable amount of time (originally, the idea was that it would not be used in production, but that didn’t last long). As we’ve moved away from prefixes to flags in browsers, I’m seeing the amount of prefixed properties dropping, and that’s very, very good. I’ve stopped using autoprefixer on new projects, and I’ve been able to remove it from some existing ones—please consider doing the same.
And when it comes to IE11, I’ll continue to categorise it as a browser that doesn’t support CSS grid. That doesn’t mean I’m abandoning users of IE11—far from it. It means I’m giving them the layout that’s appropriate for the browser they’re using.
Remember, websites do not need to look exactly the same in every browser.
A nice walkthrough of a CSS grid in production. I was surprised to see percentages used as units—I wonder if it would feel “cleaner” if they were converted to fr units?
A bold proposal by Heydon to make the process of styling on the web less painful and more scalable. I think it’s got legs, but do we really need another three-letter initialism?
We waste far too much time writing and maintaining styles with JavaScript, and I think it’s time for a change. Which is why it’s my pleasure to announce an emerging web standard called CSS.
If you’re at @FullStackCon today, don’t miss the talk by @CassieCodes at 12:15—it’s going to be great!
I tried very hard in that book, when it came to social media, to be platform agnostic, to emphasize that social media sites come and go, and to always invest first and foremost in your own media (website, blog, etc.) and mailing list.
I still stand by that advice, but if I re-wrote the book now, I would encourage artists to use much more caution when it comes to using social media websites like Facebook, Twitter, and Instagram.
A near-future sci-fi short by Hannu Rajaniemi that’s right on the zeitgest money.
The app in her AR glasses showed the car icon crawling along the winding forest road. In a few minutes, it would reach the sharp right turn where the road met the lake. The turn was marked by a road sign she had carefully defaced the previous day, with tiny dabs of white paint. Nearly invisible to a human, they nevertheless fooled image recognition nets into classifying the sign as a tree.
I have been to Brighton, and seen the summer here, and have concluded that Britons must never be permitted to have summer again. It was as hot and wet as God’s lungs, and there was a man playing the banjo on a beach with no sand. A seagull screamed at me with the voice of a human baby.
Four WWII-era American planes flew over Brighton this morning. It was beauteous! Pretty sure I saw a Lightning, a Corsair, and maybe a Flying Fortress.
I’ve thought often of how our design and prototyping tools for the web are often not of the web. Tools like Photoshop and Sketch and Invision create approximations but need to walk the line between being a tool to build native apps and to build web apps. They do well in their ability to quickly validate designs but do little to validate technical approach.
I love seeing people going offline with Going Offline…
Here’s the first part of a chat I had on Friends Talk Frontend about Resilient Web Design and Going Offline.
A little while back, I switched from using Chrome as my day-to-day browser to using Firefox. I could feel myself getting a bit too comfortable with one particular browser, and that’s not good. I reckon it’s good to shake things up a little every now and then. Besides, there really isn’t that much difference once you’ve transferred over bookmarks and cookies.
Unfortunately I’m being bitten by this little bug in Firefox. It causes some of my bookmarklets to fail on certain sites with strict Content Security Policies (and CSPs shouldn’t affect bookmarklets). I might have to switch back to Chrome because of this.
I use bookmarklets throughout the day. There’s the Huffduffer bookmarklet, of course, for whenever I come across a podcast episode or other piece of audio that I want to listen to later. But there’s also my own home-rolled bookmarklet for posting links to my site. It doesn’t do anything clever—it grabs the title and URL of the currently open page and pre-populates a form in a new window, leaving me to add a short description and some tags.
If you’re reading this, then you’re familiar with the “journal” section of adactio.com, but the “links” section is where I post the most. Here, for example, are all the links I posted yesterday. It varies from day to day, but there’s generally a handful.
Should you wish to keep track of everything I’m linking to, there’s a twitterbot you can follow called @adactioLinks. It uses a simple IFTTT recipe to poll my RSS feed of links and send out a tweet whenever there’s a new entry.
Or you can drink straight from the source and subscribe to the RSS feed itself, if you’re still rocking it old-school. But if RSS is your bag, then you might appreciate a way to filter those links…
All my links are tagged. Heavily. This is because all my links are “notes to future self”, and all my future self has to do is ask “what would past me have tagged that link with?” when I’m trying to find something I previously linked to. I end up using my site’s URLs as an interface:
At the front-end gatherings at Clearleft, I usually wrap up with a quick tour of whatever I’ve added that week to:
Well, each one of those tags also has a corresponding RSS feed:
adactio.com/links/tags/serviceworkers/rssadactio.com/links/tags/sci-fi/rssadactio.com/links/tags/frontend/rss…and so on.
That means you can subscribe to just the links tagged with something you’re interested in. Here’s the full list of tags if you’re interested in seeing the inside of my head.
This also works for my journal entries. If you’re only interested in my blog posts about frontend development, you might want to subscribe to:
Here are all the tags from my journal.
You can even mix them up. For everything I’ve tagged with “typography”—whether it’s links, journal entries, or articles—the URL is:
The corresponding RSS feed is:
You get the idea. Basically, if something on my site is a list of items, chances are there’s a corresponding RSS feeds. Sometimes there might even be a JSON feed. Hack some URLs to see.
Meanwhile, I’ll be linking, linking, linking…
From smart dust and spimes, through to online journaling and social media, to machine learning, big data and digital preservation…
Is the archive where information goes to live forever, or where data goes to die?
I posted a lot to my website yesterday: https://adactio.com/archive/2018/07/10
It makes me feel guilty and proud at the same time—like I’m somehow being really productive by wasting time on the internet.
Thank you, @NikkitaFTW, for sticking around after the workshop in @68MiddleSt today to coach at @CodebarBrighton — much appreciated!
Reading Dawn by Octavia Butler.
Checked in at The Joker. Beer and wings at the end of a long but rewarding day — with Jessica
The ideas and images that come to mind when you think of technology as an instrument are more useful than if you think of it as a tool. Instruments — I’m specifically talking about musical instruments — are a way to create culture.
You approach instruments with a set of expectations and associations that are more humane. It’s built into their very purpose. Instruments are meant to make something for other people, not making things. When you use an instrument, you have an expectation that it is going to take effort to use it well. Using an instrument takes practice. You form a relationship with that object. It becomes part of your identity that you make something with it. You tune it. You understand that there’s no such thing as a “best” guitar in the same way that there’s not necessarily a “best” phone.
Since support for service workers landed in Mobile Safari on iOS, I’ve been trying a little experiment. Can I replace some of the native apps I use with progressive web apps?
The two major candidates are Twitter and Instagram. I added them to my home screen, and banished the native apps off to a separate screen. I’ve been using both progressive web apps for a few months now, and I have to say, they’re pretty darn great.
There are a few limitations compared to the native apps. On Twitter, if you follow a link from a tweet, it pops open in Safari, which is fine, but when you return to Twitter, it loads anew. This isn’t any fault of Twitter—this is the way that web apps have worked on iOS ever since they introduced their weird web-app-capable meta element. I hope this behaviour will be fixed in a future update.
Also, until we get web notifications on iOS, I need to keep the Twitter native app around if I want to be notified of a direct message (the only notification I allow).
Apart from those two little issues though, Twitter Lite is on par with the native app.
Instagram is also pretty great. It too suffers from some navigation issues. If I click through to someone’s profile, and then return to the main feed, it also loads it anew, losing my place. It would be great if this could be fixed.
For some reason, the Instagram web app doesn’t allow uploading multiple photos …which is weird, because I can upload multiple photos on my own site by adding the multiple attribute to the input type="file" in my posting interface.
Apart from that, though, it works great. And as I never wanted notifications from Instagram anyway, the lack of web notifications doesn’t bother me at all. In fact, because the progressive web app doesn’t keep nagging me about enabling notifications, it’s a more pleasant experience overall.
Something else that was really annoying with the native app was the preponderance of advertisements. It was really getting out of hand.
Well …(looks around to make sure no one is listening)… don’t tell anyone, but the Instagram progressive web app—i.e. the website—doesn’t have any ads at all!
Here’s hoping it stays that way.
I really, really like the way that this straightforward accessibility guide is subdivided by discipline. As Maya wrote in the blog post announcing its launch:
Each person on a team, whether you’re a manager, designer, or developer, has a role to play. Your responsibilities are different depending on your role. So that’s how we structured the guide, with a separate section for each of five roles:
- Product management
- Content design
- UX design
- Visual design
- Front-end development
A @beerleft on the beach.
A good explanation of web components, complete with some code examples.
Web Components are not a single technology. Instead, they are series of browser standards defined by the W3C allowing developers to build components in a way the browser can natively understand. These standards include:
- HTML Templates and Slots – Reusable HTML markup with entry points for user-specific markup
- Shadow DOM – DOM encapsulation for markup and styles
- Custom Elements – Defining named custom HTML elements with specific behaviour
There are a lot of static site generators out there!
I remember Jason telling me about this weird service worker caching behaviour a little while back. This piece is a great bit of sleuthing in tracking down the root causes of this strange issue, followed up with a sensible solution.
Workshoppers.
This strikes me as a sensible way of thinking about machine learning: it’s like when we got relational databases—suddenly we could do more, quicker, and easier …but it doesn’t require us to treat the technology like it’s magic.
An important parallel here is that though relational databases had economy of scale effects, there were limited network or ‘winner takes all’ effects. The database being used by company A doesn’t get better if company B buys the same database software from the same vendor: Safeway’s database doesn’t get better if Caterpillar buys the same one. Much the same actually applies to machine learning: machine learning is all about data, but data is highly specific to particular applications. More handwriting data will make a handwriting recognizer better, and more gas turbine data will make a system that predicts failures in gas turbines better, but the one doesn’t help with the other. Data isn’t fungible.
Paul Ford explains version control in a way that is clear and straightforward, while also being wistful and poetic.
I had idle fantasies about what the world of technology would look like if, instead of files, we were all sharing repositories and managing our lives in git: book projects, code projects, side projects, article drafts, everything. It’s just so damned … safe. I come home, work on something, push the changes back to the master repository, and download it when I get to work. If I needed to collaborate with other people, nothing would need to change. I’d just give them access to my repositories (repos, for short). I imagined myself handing git repos to my kids. “These are yours now. Iteratively add features to them, as I taught you.”
We tend to like false dichotomies in the world of web design and web development. I’ve noticed one recently that keeps coming up in the realm of design systems and components.
It’s about separation of concerns. The web has a long history of separating structure, presentation, and behaviour through HTML, CSS, and JavaScript. It has served us very well. If you build in that order, ensuring that something works (to some extent) before adding the next layer, the result will be robust and resilient.
But in this age of components, many people are pointing out that it makes sense to separate things according to their function. Here’s the Diana Mounter in her excellent article about design systems at Github:
Rather than separating concerns by languages (such as HTML, CSS, and JavaScript), we’re are working towards a model of separating concerns at the component level.
This echoes a point made previously in a slidedeck by Cristiano Rastelli.
Separating interfaces according to the purpose of each component makes total sense …but that doesn’t mean we have to stop separating structure, presentation, and behaviour! Why not do both?
There’s nothing in the “traditonal” separation of concerns on the web (HTML/CSS/JavaScript) that restricts it only to pages. In fact, I would say it works best when it’s applied on smaller scales.
In her article, Pattern Library First: An Approach For Managing CSS, Rachel advises starting every component with good markup:
Your starting point should always be well-structured markup.
This ensures that your content is accessible at a very basic level, but it also means you can take advantage of normal flow.
That’s basically an application of starting with the rule of least power.
In chapter 6 of Resilient Web Design, I outline the three-step process I use to build on the web:
- Identify core functionality.
- Make that functionality available using the simplest possible technology.
- Enhance!
That chapter is filled with examples of applying those steps at the level of an entire site or product, but it doesn’t need to end there:
We can apply the three‐step process at the scale of individual components within a page. “What is the core functionality of this component? How can I make that functionality available using the simplest possible technology? Now how can I enhance it?”
There’s another shared benefit to separating concerns when building pages and building components. In the case of pages, asking “what is the core functionality?” will help you come up with a good URL. With components, asking “what is the core functionality?” will help you come up with a good name …something that’s at the heart of a good design system. In her brilliant Design Systems book, Alla advocates asking “what is its purpose?” in order to get a good shared language for components.
My point is this:
Those two good ideas are not in conflict. Presenting them as though they were binary choices is like saying “I used to eat Italian food, but now I drink Italian wine.” They work best when they’re done in combination.
Workshopping in @68MiddleSt with @vlh and @sarah_edo.
Rachel goes into detail on how she uses pattern libraries—built with Fractal to build interfaces. I know it sounds like we paid her to say all the nice things about Fractal, but honestly, we didn’t even know she was writing this article!
After discovering Fractal two years ago, we have moved every new project — large and small — into Fractal.
Web animation workshop, day two:
@aboydleslie, @cassiecodes, @sarah_edo, and @vlh.
Is it a graphic design tool? Is it a text editor? Is it just good fun?
I talked for an hour about service workers ‘n’ stuff
(Also available on Huffduffer.)
A collection of sci-fi short stories, featuring Becky Chambers and Madeline Ashby …and it’s free!
Browser implementations of Sol LeWitt’s conceptual and minimal art, many of which only exist as instructions like this:
Vertical lines, not straight, not touching, covering the wall evenly.
BBC News has switched to HTTPS—hurrah!
Here, one of the engineers writes on Ev’s blog about the challenges involved. Personally, I think this is far more valuable and inspiring to read than the unempathetic posts claiming that switching to HTTPS is easy.
Update: Paul found the original URL for this …weird that they don’t link to it from the syndicated version.
A website is not a magazine, though it might have magazine-like articles. A website is not an application, although you might use it to purchase products or interact with other people. A website is not a database, although it might be driven by one.
The title is quite clickbaity, but this is a rather wonderful retelling of web history on how Content Management Systems may have stifled a lot of the web’s early creativity.
Also, there’s this provocation: we like to rail against algorithmic sorting …but what if the reverse-chronological feed was itself the first algorithm?
Said goodnight to @vlh, @sarah_edo and @dizzyd …and proceeded to bump into @kytrinyx. Seems like everyone’s in Brighton this week!
Pizza! 🍕
Checked in at The Flying Saucer. with Jessica
This is very neat! Test out how Google Fonts will look on your website: type in your URL and away you go. Works well on mobile too.
Testing the theory that putting the word “total”, “complete”, or “absolute” in front of any noun automatically makes for an excellent insult.
So many ways to screw the pooch, and just one staggeringly complex, scrupulously modelled, endlessly rehearsed, indefatigably tested way to succeed.
— Hidden Figures
Paul Yabsley wrote to let me know about an error in Going Offline. It’s rather embarrassing because it’s code that I’m using in the service worker for adactio.com but for some reason I messed it up in the book.
It’s the trimCache function in Chapter 7: Tidying Up. That’s the reusable piece of code that recursively reduces the number of items in a specified cache (cacheName) to a specified amount (maxItems). On page 95 and 96 I describe the process of creating the function which, in the book, ends up like this:
function trimCache(cacheName, maxItems) {
cacheName.open( cache => {
cache.keys()
.then( items => {
if (items.length > maxItems) {
cache.delete(items[0])
.then(
trimCache(cacheName, maxItems)
); // end delete then
} // end if
}); // end keys then
}); // end open
} // end function
See the problem? It’s right there at the start when I try to open the cache like this:
cacheName.open( cache => {
That won’t work. The open method only works on the caches object—I should be passing the name of the cache into the caches.open method. So the code should look like this:
caches.open( cacheName )
.then( cache => {
Everything else remains the same. The corrected trimCache function is here:
function trimCache(cacheName, maxItems) {
caches.open(cacheName)
.then( cache => {
cache.keys()
.then(items => {
if (items.length > maxItems) {
cache.delete(items[0])
.then(
trimCache(cacheName, maxItems)
); // end delete then
} // end if
}); // end keys then
}); // end open then
} // end function
Sorry about that! I must’ve had some kind of brainfart when I was writing (and describing) that one line of code.
You may want to deface your copy of Going Offline by taking a pen to that code example. Normally I consider the practice of writing in books to be barbarism, but in this case …go for it.
Update: There was another error in the code for trimCache! Here’s the fix.
Hui Jing describes her motivation for creating the lovely Penang Hokkien site:
People who grew up their whole lives in a community that spoke the same mother tongue as themselves would probably find this hard to relate to, but it really was something else to hear my mother tongue streaming out of the speakers of my computer.
She ends with an impassioned call for more local language websites:
If the Internet is meant to enhance the free flow of information and ideas across the world, then creation of content on the web should not largely be limited to English-speaking communities.
Planning train parkour to get from Oxford to Brighton without getting pulled into the gravity well of the London Maw.
https://traintimes.org.uk/ from @dracos is proving to be a life saver—and it’s a progressive web app too!
Checked in at Jericho Tavern. Getting ready to speak at Oxford Geek Night
This is a lovely review of Going Offline from Garrett:
With his typical self-effacing humour (chapter titles include Making Fetch Happen and Cache Me If You Can), and easy manner, Jeremy explains how Service Workers, uh, work, the clever things you can do with them, and most importantly, how to build your own.
Best of all, he’s put it into action!
To that end, this site now has its own home-grown, organic, corn fed, Service Worker.
Going to Oxford. brb
On the beach with Rob and Leah.
Today’s oyster.
(I’m loving this weather!)
Facebook doesn’t have a mind-control problem, it has a corruption problem. Cambridge Analytica didn’t convince decent people to become racists; they convinced racists to become voters.
Are we headed toward an Orwellian future where a handful of corporations monitor and control our lives? Or are we on the verge of creating a better version of society online, one where the free flow of ideas and information helps cure disease, expose corruption, reverse injustices?
It’s hard to believe that anyone—even Zuckerberg—wants the 1984 version. He didn’t found Facebook to manipulate elections; Jack Dorsey and the other Twitter founders didn’t intend to give Donald Trump a digital bullhorn. And this is what makes Berners-Lee believe that this battle over our digital future can be won. As public outrage grows over the centralization of the Web, and as enlarging numbers of coders join the effort to decentralize it, he has visions of the rest of us rising up and joining him.
Okay, I think I’m going to have to get this pack of three notebooks: Mercury, Gemini, and Apollo.
I was in Boston last week to give a talk. I ended up giving four.
I was there for An Event Apart which was, as always, excellent. I opened up day two with my talk, The Way Of The Web.
This was my second time giving this talk at An Event Apart—the first time was in Seattle a few months back. It was also my last time giving this talk at An Event Apart—I shan’t be speaking at any of the other AEAs this year, alas. The talk wasn’t recorded either so I’m afraid you kind of had to be there (unless you know of another conference that might like to have me give that talk, in which case, hit me up).
After giving my talk in the morning, I wasn’t quite done. I was on a panel discussion with Rachel about CSS grid. It turned out to be a pretty good format: have one person who’s a complete authority on a topic (Rachel), and another person who’s barely starting out and knows just enough to be dangerous (me). I really enjoyed it, and the questions from the audience prompted some ideas to form in my head that I should really note down in a blog post before they evaporate.
The next day, I went over to MIT to speak at Design 4 Drupal. So, y’know, technically I’ve lectured at MIT now.
I wasn’t going to do the same talk as I gave at An Event Apart, obviously. Instead, I reprised the talk I gave earlier this at Webstock: Taking Back The Web. I thought it was fitting given how much Drupal’s glorious leader, Dries, has been thinking about, writing about, and building with the indie web.
I really enjoyed giving this talk. The audience were great, and they had lots of good questions afterwards. There’s a video, which is basically my voice dubbed over the slides, followed by a good half of questions afterwards.
When I was done there, after a brief excursion to the MIT bookstore, I went back across the river from Cambridge to Boston just in time for that evening’s Boston CSS meetup.
Lea had been in touch to ask if I would speak at this meet-up, and I was only too happy to oblige. I tried doing something I’ve never done before: a book reading!
No, not reading from Going Offline, my current book which I should encouraging people to buy. Instead I read from Resilient Web Design, the free online book that people literally couldn’t buy if they wanted to. But I figured reading the philosophical ramblings in Resilient Web Design would go over better than trying to do an oral version of the service worker code in Going Offline.
I read from chapters two (Materials), three (Visions), and five (Layers) and I really, really liked doing it! People seemed to enjoy it too—we had questions throughout.
And with that, my time in Boston was at an end. I was up at the crack of dawn the next morning to get the plane back to England where Ampersand awaited. I wasn’t speaking there though. I thoroughly enjoyed being an attendee and absorbing the knowledge bombs from the brilliant speakers that Rich assembled.
The next place I’m speaking will much closer to home than Boston: I’ll be giving a short talk at Oxford Geek Nights on Wednesday. Come on by if you’re in the neighbourhood.
Here’s a treasure trove of eighties nerd nostalgia:
In the 1980s, the BBC explored the world of computing in The Computer Literacy Project. They commissioned a home computer (the BBC Micro) and taught viewers how to program.
The Computer Literacy Project chronicled a decade of information technology and was a milestone in the history of computing in Britain, helping to inspire a generation of coders.
Rob attended the excellent Ampersand event last Friday and he’s made notes for each and every talk.
A nice little tutorial from Aaron.
A fascinating treasure trove of objects recovered from the canals of Amsterdam.
Here’s the video of the talk I gave at Design4Drupal last week in Boston. There’s a good half an hour of questions at the end.
Mike talks about the pros and cons of working with companies at different stages of design maturity:
Before social media monoliths made us into little mechanical turks for advertising platforms, we had organic homes on the web. We had pages that were ours. And they could look however you wanted. And you could write whatever you wanted on there.
There weren’t comments if you didn’t want them. There were no photo dimensions to adhere to. No 140-character limits. No BS. Or lots of BS. Either way, the choice was yours because you owned your site and you could do whatever you wanted.
