Putting a coin in the “container queries would solve this problem” jar.
Wednesday, January 31st, 2018
Reading Traction by Gino Wickman.
It’s designed to read as a progressive enhancement when you look at the HTML it’s addressing.
Tuesday, January 30th, 2018
Famous first words
Monday, January 29th, 2018
GDPR and Google Analytics
Enforcement of the European Union’s General Data Protection Regulation is coming very, very soon. Look busy. This regulation is not limited to companies based in the EU—it applies to any service anywhere in the world that can be used by citizens of the EU.
It’s less about data protection and more like a user’s bill of rights. That’s good. Cennydd has written a techie’s rough guide to GDPR.
The Open Data Institute’s Jeni Tennison wrote down her thoughts on how it could change data portability in particular. While she welcomes GDPR, she has some misgivings.
Blaine—who really needs to get a blog—shared his concerns in the form of the online equivalent of interpretive dance …a twitter thread (it’s called a thread because it inevitably gets all tangled, and it’s easy to break.)
It’s increasingly looking like GDPR is a massive scaled-up version of the idiotic and horrifically mis-managed “cookie law”.— Blaine Cook (@blaine) January 28, 2018
The interesting thing about the so-called “cookie law” is that it makes no mention of cookies whatsoever. It doesn’t list any specific technology. Instead it states that any means of tracking or identifying users across websites requires disclosure. So if you’re setting a cookie just to manage state—so that users can log in, or keep items in a shopping basket—the legislation doesn’t apply. But as soon as your site allows a third-party to set a cookie, it’s banner time.
Under the old “cookie law”, using a third-party cookie-setting service like that meant you had to inform any of your users who were citizens of the EU. With GDPR, that changes. Now you have to get consent. A dismissible little overlay isn’t going to cut it any more. Implied consent isn’t enough.
Now this situation raises an interesting question. Who’s responsible for getting consent? Is it the site owner or the third party whose script is the conduit for the tracking?
I’m just using Google Analytics as an example here because it’s so widespread. This also applies to third-party sharing buttons—Twitter, Facebook, etc.—and of course, advertising.
In the case of advertising, it gets even thornier because quite often, the site owner has no idea which third party is about to do the tracking. Many, many sites use intermediary services (y’know, ‘cause bloated ad scripts aren’t slowing down sites enough so let’s throw some just-in-time bidding into the mix too). You could get consent for the intermediary service, but not for the final advert—neither you nor your site’s user would have any idea what they were consenting to.
Interesting times. One way or another, a massive amount of the web—every website using Google Analytics, embedded YouTube videos, Facebook comments, embedded tweets, or third-party advertisements—will be liable under GDPR.
It’s almost as if the ubiquitous surveillance of people’s every move on the web wasn’t a very good idea in the first place.
Sunday, January 28th, 2018
A clever little hack to preserve an aspect ratio for any HTML element.
We use two important attributes:
- SVG knows how to maintain aspect ratio
- CSS grid knows how to make overlapping items affect each other’s size
A nice analogy to help explain what it’s like to navigate with a screen reader—and how much well-structured markup can help make it easier.
Saturday, January 27th, 2018
Friday, January 26th, 2018
Ben makes the very good point that template literals allow you to do a lot of useful stuff that previously would’ve required a library:
Template Literals afford a lot of power with no library overhead. I will definitely continue to use them when complexity of handlebars or similar is overkill.
Chris made a similar observation a little while back. Throw in a little script like lit-html and now you’ve got DOM-diffing too. You might not need insert-current-framework-name after all.
Kinda cool that these mini-libraries exist that do useful things for us, so when situations arise that we want a feature that a big library has, but don’t want to use the whole big library, we got smaller options.
The gorgeous website for this year’s Ampersand conference might well be one of the first commercial uses of variable fonts in the wild. Here, Richard documents all the clever things Mark did to ensure good fallbacks for browsers that don’t yet support variable fonts.
Chris has set up a whole site dedicated to someone-else’s-server sites with links to resources and services (APIs), along with ideas of what you could build in this way.
Off-site backups of humanity’s knowledge and culture, stored in different media (including pyramidal crystals) placed in near-Earth orbit, the moon, and Mars.
We are developing specialized next-generation devices that we call Archs™ (pronounced “Arks”), which are designed to hold and transmit large amounts of data over long periods of time in extreme environments, including outer space and on the surfaces of other planetary bodies.
Our goal is to collect and curate important data sets and to install them on Archs™ that will be delivered to as many locations as possible for safekeeping.
To increase the chances that Archs™ will be found in the future, we aim for durability and massive redundancy across a broad diversity of locations and materials – a strategy that nature itself has successfully employed.
The past, present and future of RSS.
If I had to choose my Twitter account over my RSS setup I wouldn’t hesitate for a second — I’d throw Twitter right into the ocean.
Thursday, January 25th, 2018
Julie is organising the Brighton edition of the Global Diversity Call-For-Proposals Day (and I’m providing the venue) on Saturday, February 3rd from 11am to 3pm. If you’ve ever wanted to speak at a conference, please come along:
On Saturday 3rd February 2018 there will be numerous workshops hosted around the globe encouraging and advising newbie speakers to put together your very first talk proposal and share your own individual perspective on any subject of interest to people in tech.
Paul weighs up the pros and cons of using silos (like Twitter and Facebook) and using the Indie Web. This bit made me want to stand on my desk and cry, “Oh captain, my captain!”:
“The market has proven that consumers want freely available social networks that are easy to use, and used by everyone else. Only centralised services can provide this, not familiarity with a command line and a succession of acronyms and protocols”, says my not entirely fictional naysayer.
I’m not sure this argument follows. While the human desire to connect and communicate easily with each other has been proven many times over, it’s becoming clear that all-encompassing centralised networks are not the solution. That way lies algorithmically-skewed streams of consciousness, layered upon sordid business models and Californian ideology. Fuck that.
The web is agreement, but that doesn’t mean we agree to use the same websites.
Design ops for design systems
Leading Design was one of the best events I attended last year. To be honest, that surprised me—I wasn’t sure how relevant it would be to me, but it turned out to be the most on-the-nose conference I could’ve wished for.
Seeing as the event was all about design leadership, there was inevitably some talk of design ops. But I noticed that the term was being used in two different ways.
Sometimes a speaker would talk about design ops and mean “operations, specifically for designers.” That means all the usual office practicalities—equipment, furniture, software—that designers might need to do their jobs. For example, one of the speakers recommended having a dedicated design ops person rather than trying to juggle that yourself. That’s good advice, as long as you understand what’s meant by design ops in that context.
There’s another context of use for the phrase “design ops”, and it’s one that we use far more often at Clearleft. It’s related to design systems.
Now, “design system” is itself a term that can be ambiguous. See also “pattern library” and “style guide”. Quite a few people have had a stab at disambiguating those terms, and I think there’s general agreement—a design system is the overall big-picture “thing” that can contain a pattern library, and/or a style guide, and/or much more besides:
- Styleguides, Pattern Libraries and Design Languages
- Design Systems vs. Pattern Libraries vs. Style Guides – What’s the Difference?
- Design Systems, Style Guides, and Pattern Libraries: Oh My!
- What’s the difference between style guides, pattern libraries, and design systems?
None of those great posts attempt to define design ops, and that’s totally fair, because they’re all attempting to define things—style guides, pattern libraries, and design systems—whereas design ops isn’t a thing, it’s a practice. But I do think that design ops follows on nicely from design systems. I think that design ops is the practice of adopting and using a design system.
There are plenty of posts out there about the challenges of getting people to use a design system, and while very few of them use the term design ops, I think that’s what all of them are about:
- Why Design Systems Fail
- Tips for in-house teams in a free market software culture
- Putting your design system into practice
Clearly design systems and design ops are very closely related: you really can’t have one without the other. What I find interesting is that a lot of the challenges relating to design systems (and pattern libraries, and style guides) might be technical, whereas the challenges of design ops are almost entirely cultural.
I realise that tying design ops directly to design systems is somewhat limiting, and the truth is that design ops can encompass much more. I like Andy’s description:
Design Ops is essentially the practice of reducing operational inefficiencies in the design workflow through process and technological advancements.
Now, in theory, that can encompass any operational stuff—equipment, furniture, software—but in practice, when we’re dealing with design ops, 90% of the time it’s related to a design system. I guess I could use a whole new term (design systems ops?) but I think the term design ops works well …as long as everyone involved is clear on the kind of design ops we’re all talking about.
Yet another cryptocurrency …except that this was meant to be satire.
This has gotten crazy out of hand, I apologize but we will no longer be selling PonziCoin on this site because this was a joke.
This looks like an interesting alternative to TinyLetter for writing and sending email newsletters, like all the cool kids are doing.
I love this analogy and I love this approach—starting with the simplest possible thing and building up from there. This article talks about taking that approach for UI design, but it’s pretty much the same thing I talk about for development in Resilient Web Design.
As Shakespeare once didn’t say, progressive enhancement by any other name would smell as sweet.
Squee! The next time there’s an update for OS X and iOS, Safari will magically have service worker support! Not only that, but Safari on iOS will start using the information in web app manifests for adding to home screen.
That’s an impressive turnaround.
Wednesday, January 24th, 2018
This is a fascinating way to explore time and place—a spyglass view of hundred year old maps overlaid on the digital maps of today.
I still haven’t used React (I know, I know) but this looks like a nice explanation of React and Redux.
A nice description of syndication via POSSEing.
(I never thought I’d find myself linking to quality content on Go Daddy.)
Tuesday, January 23rd, 2018
This evening I discussed HTML from first principles with five brilliant @CodebarBrighton students, and I really, really, really enjoyed it.
Oh, no! Ursula K. Le Guin.
In fact, you can do more than saving the date: you can snap up a super early bird ticket for whopping £85 saving.
Monday, January 22nd, 2018
A thoroughly enjoyable adventure game in your browser. You are the AI of a colony starship. Humanity’s future is in your hands.
All the books, Montag.
If we want a 100% encrypted web then we need to encrypt all sites, despite whether or not you agree with what they do/say/sell/etc… 100% is 100% and it includes the ‘bad guys’ too.
I’m on Team Dave.
Sunday, January 21st, 2018
Coming to a bookshelf near you in March 2018: the untold story of the women who made the internet.
What it says on the tin—a few suggestions to ensure the accessibility of your site.
Saturday, January 20th, 2018
Google won the analytics war because dropping one line of JS in the footer and handing a tried and tested interface to customers is an obvious no brainer in comparison to setting up an open source option that needs a cron job to parse the files, a database to store the results and doesn’t provide mobile interface.
Given the choice between making something my problem, and making something the user’s problem, I’ll choose to make it my problem every time.
It’s true that this often means doing more work. That’s why it’s called work. This is literally what our jobs are supposed to entail: we put in the work to make life easier for users. We’re supposed to be saving them time, not passing it along.
I’ve often thought the HTML design principle called the priority of constituencies could be adopted by web developers:
In case of conflict, consider users over authors over implementors over specifiers over theoretical purity. In other words costs or difficulties to the user should be given more weight than costs to authors.
- Identify core functionality.
- Make that functionality available using the simplest possible technology.
Now I’m wondering if I should’ve clarified that second step further. When I talk about choosing “the simplest possible technology”, what I mean is “the simplest possible technology for the user”, not “the simplest possible technology for the developer.”
Time and time again, I see decisions that favour developer convenience over user needs. Don’t get me wrong—as a developer, I absolutely want developer convenience …but not at the expense of user needs.
I know that “empathy” is an over-used word in the world of user experience and design, but with good reason. I think we should try to remind ourselves of why we make our architectural decisions by invoking who those decisions benefit. For example, “This tech stack is best option for our team”, or “This solution is the best for the widest range of users.” Then, given the choice, favour user needs in the decision-making process.
There will always be situations where, given time and budget constraints, we end up choosing solutions that are easier for us, but not the best for our users. And that’s okay, as long as we acknowledge that compromise and strive to do better next time.
But when the best solutions for us as developers become enshrined as the best possible solutions, then we are failing the people we serve.
That doesn’t mean we must become hairshirt-wearing martyrs; developer convenience is important …but not as important as user needs. Start with user needs.
I can’t help but also wonder if we’re using tools to solve problems they weren’t meant to solve, like how to communicate with or manage a team.
Most of my online friends and acquaintances will never understand or participate in the IndieWeb, and so I require a bridge between these worlds. On one side I choose what content to post and how it is stored, and it exists mainly on an island that few visit regularly. On the other side is nearly everyone I know, blissfully ignorant of my real home on the web and unable to see any content shared there without manual intervention or working plugins.
This does not all seem bad, though. Maintaining control will require more attention be placed on managing my content, and this time must come from somewhere. I imagine that I’ll slowly begin using social media less, writing more, and learning more about how to develop solutions to problems that arise within my setup.
If you are one of those old or young bloggers, please join in. Drop Facebook, drop Twitter and drop Medium for original thought. Own your traffic. You can use them to engage in discussion. But don’t get lost in there. Write daily. Publish as often as you have something to say. Link to other blogs.
Friday, January 19th, 2018
I wrote about Google Analytics yesterday. As usual, I syndicated the post to Ev’s blog, and I got an interesting response over there. Kelly Burgett set me straight on some of the finer details of how goals work, and finished with this thought:
You mention “delivering a performant, accessible, responsive, scalable website isn’t enough” as if it should be, and I have to disagree. It’s not enough for a business to simply have a great website if you are unable to understand performance of channel marketing, track user demographics and behavior on-site, and optimize your site/brand based on that data. I’ve seen a lot of ugly sites who have done exceptionally well in terms of ROI, simply because they are getting the data they need from the site in order make better business decisions. If your site cannot do that (ie. through data collection, often third party scripts), then your beautifully-designed site can only take you so far.
I don’t want to come across all old-man-yell-at-cloud here, but I’m trying to remember at what point self-hosted software for analysing your log traffic became not good enough.
Related: according to Google Analytics, 0% of your customers are using ad-blockers that block requests to Google’s servers. Again, that’s not necessarily a true fact.
So I completely agree than analytics are a good thing to have for your business. But it does not follow that Google Analytics is a good thing for your business. Other options are available.
In a word, no.
Thursday, January 18th, 2018
Reading Time Travel: A History by James Gleick.
Here’s a clever idea from Harry if you’re willing to play the long game in tracking down redundant CSS—add a transparent background image to the rule block and then sit back and watch your server logs for any sign of that sleeper agent ever getting activated.
If you do find entries for that particular image, you know that, somehow, the legacy feature is potentially still accessible—the number of entries should give you a clue as to how severe the problem might be.
There’s nothing quite so crushing as building a beautifully performant website only to have it infested with a plague of third-party scripts that add to the weight of each page and reduce the responsiveness, making a mockery of your well-considered performance budget.
My latest realization is that delivering a performant, accessible, responsive, scalable website isn’t enough: I also need to consider the impact of third-party scripts.
He’s started the process by itemising third-party scripts. Frustratingly though, there’s rarely one single culprit that you can point to—it’s the cumulative effect of “just one more beacon” and “just one more analytics script” and “just one more A/B testing tool” that adds up to a crappy experience that warms your user’s hands by ensuring your site is constantly draining their battery.
Actually, having just said that there’s rarely one single culprit, Adobe Tag Manager is often at the root of third-party problems. That and adverts. It’s like opening the door of your beautifully curated dream home, and inviting a pack of diarrhetic elephants in: “Please, crap wherever you like.”
But even the more well-behaved third-party scripts can get out of hand. Google Analytics is so ubiquitous that it’s hardly even considered in the list of potentially harmful third-party scripts. On the whole, it’s a fairly well-behaved citizen of your site’s population of third-party scripts (y’know, leaving aside the whole surveillance capitalism business model that allows you to use such a useful tool for free in exchange for Google tracking your site’s visitors across the web and selling the insights from that data to advertisers).
The initial analytics script that you—asynchronously—load into your page isn’t very big. But depending on how you’ve configured your Google Analytics account, that might just be the start of a longer chain of downloads and event handlers.
As I understand it, there are two main categories of goals: events and destinations (there are also durations and pages, but they feel similar to destinations). You use events to answer questions like “Did the user click on this button?” or “Did the user click on that search field?”. You use destinations to answer questions like “Did the user arrive at this page?” or “Did the user come from that page?”
So I have a hypothesis. I think that destination-based goals are less harmful to performance than event-based goals. I might well be wrong about that, and if I am, please let me know.
With that hypothesis in mind, and until I learn otherwise, I’ve got two rules of thumb to offer when it comes to using Google Analytics:
- Try to keep the number of goals to a minimum.
- If you must create a goal, favour destinations over events.
The transcript of a talk by Charles Stross on the perils of prediction and the lessons of the past. It echoes Ted Chiang’s observation that runaway AIs are already here, and they’re called corporations.
History gives us the perspective to see what went wrong in the past, and to look for patterns, and check whether those patterns apply to the present and near future. And looking in particular at the history of the past 200-400 years—the age of increasingly rapid change—one glaringly obvious deviation from the norm of the preceding three thousand centuries—is the development of Artificial Intelligence, which happened no earlier than 1553 and no later than 1844.
I’m talking about the very old, very slow AIs we call corporations, of course.
Tuesday, January 16th, 2018
I’m all in favour of HTTPS everywhere, but this kind of strong-arming just feels like blackmail to me.
All new CSS properties won’t work without HTTPS‽ Come on!
I thought Mozilla was better than this.
- Fitts’s Law
- Hick’s Law
- Jakob’s Law
- Law of Prägnanz
- Law of Proximity
- Miller’s Law
- Parkinson’s Law
- Serial Position Effect
- Tesler’s Law
- Van Restorff Effect
- Murphy’s Law
- Sturgeon’s Law
A step-by-step guide to implementing drag’n’drop, and image previews with the Filereader API. No libraries or frameworks were harmed in the making of this article.
Monday, January 15th, 2018
I like a good em dash, me.
Better Typography with Font Variants - Jonathan Harrell | CSS Blogger & Teacher, UI/UX Designer, Front-End Developer
A quick guide to all the
font-variant-... stuff in CSS.
Sunday, January 14th, 2018
In this excerpt from his forthcoming book, Cennydd gives an overview of what GDPR will bring to the web. This legislation is like a charter of user’s rights, and things don’t look good for the surveillance kings of online advertising:
The black box will be forced open, and people will find it’s full of snakes.
dialogs are here.
An initiative by David Brin and the Arthur C. Clarke Center For Human Imagination at UC San Diego. You are confronted with a what-if scenario, and your task is to recall any works of speculative fiction that have covered it.
Accessing more than a hundred years of science fiction thought experiments, TASAT taps into a passionate, global community of writers, scholars, librarians, and fans. We aim to curate a reading list applicable to problems and possibilities of tomorrow.
If only our digital social networks were to exhibit this kind of faded grandeur when they no longer exist.
Remember those offshore forts that would get taken over and repurposed as tax/data havens? Well, this is like that …but in space. Half design fiction, and half ponzi scheme, this will give those libertarian seasteaders a run for the money (in a made-up currency, of course).
Saturday, January 13th, 2018
From the proceedings of the Electronic Computer Symposium in 1952, the remarkable Ida Rhodes describes a vision of the future…
My crystal ball reveals Mrs. Mary Jones in the living room of her home, most of the walls doubling as screens for projected art or information. She has just dialed her visiophone. On the wall panel facing her, the full colored image of a rare orchid fades, to be replaced by the figure of Mr. Brown seated at his desk. Mrs. Jones states her business: she wishes her valuable collection of orchid plants insured. Mr. Brown consults a small code book and dials a string of figures. A green light appears on his wall. He asks Mrs. Jones a few pertinent questions and types out her replies. He then pushes the start button. Mr. Brown fades from view. Instead, Mrs. Jones has now in front of her a set of figures relating to the policy in which she is interested. The premium rate and benefits are acceptable and she agrees to take out the policy. Here is Brown again. From a pocket in his wall emerges a sealed, addressed, and postage-metered envelope which drops into the mailing chute. It contains, says Brown, an application form completely filled out by the automatic computer and ready for her signature.
Friday, January 12th, 2018
Third-party scripts are probably the #1 cause of poor performance and bad UX on the web.
A well-written (and beautifully designed) article on the nature of the web, and what that means for those of us who build upon it. Matthias builds on the idea of material honestly and concludes that designing through prototypes—rather than making pictures of websites—results in a truer product.
A prototyping mindset means cultivating transparency and showing your work early to your team, to users – and to clients as well, which can spark excited conversations. A prototyping mindset also means valuing learning over fast results. And it means involving everyone from the beginning and closely working together as a team to dissolve the separation of linear workflows.
Thursday, January 11th, 2018
Training a neural network to do front-end development.
I didn’t understand any of this.
Wednesday, January 10th, 2018
An absolutely fantastic talk (as always) from Maciej, this time looking at the history of radio and its parallels with the internet (something that Tom Standage touched on his book, Writing On The Wall). It starts as a hobbyist, fun medium. Then it gets regulated. Then it gets used to reinforce existing power structures.
It is hard to accept that good people, working on technology that benefits so many, with nothing but good intentions, could end up building a powerful tool for the wicked.
Making low effort/high impact changes to interfaces.
This reminds me of something we talk about at Clearleft a lot called “tiny lessons”—it’s the idea that insights and learnings don’t always have to be big and groundbreaking; there’s a disproportionate value in sharing the small little things you learn along the way.
Suggestions for small interface tweaks.
Tuesday, January 9th, 2018
We need to keep our eyes on the prize: making sure the internet does not suck for as many people as possible for as long as possible. That’s the work we need to be doing. And we should do it not from a place of fear or despair, but from a place of joy.
And since we are speculating, we’ll use those powerful pseudo-laws, the Principles of Mediocrity and Minimal Assumption.
— A Fire Upon The Deep
The German word for that brief vertigenous moment between going to the toilet and remembering you ate beetroot.
I signed this open letter.
We are a community of individuals who have a significant interest in the development and health of the World Wide Web (“the Web”), and we are deeply concerned about Accelerated Mobile Pages (“AMP”), a Google project that purportedly seeks to improve the user experience of the Web.
The text of a fascinating talk given by Tim Berners-Lee back in 1995, at a gathering to mark the 50th anniversary of Vannevar Bush’s amazing article As We May Think. The event also drew together Ted Nelson, Alan Kay, Douglas Engelbart, and Bob Kahn!
Peter looks into his crystal ball for 2018 and sees computers with eyes, computers with ears, and computers with brains.
The philosophy behind these tools matches my own philosophy (which I think is one of the most important factors in choosing a tool that works for you, not against you).
Good news! Google will graciously allow non-Google-hosted AMP pages to get the AMP blessing in search results.
Bad news! It requires publishers to package up their AMP pages in a new packaging format that browsers don’t support yet.
Monday, January 8th, 2018
Even more concerning than browser-specific websites is seeing browsers ship non-standardized features just because they want them, not behind any vendor prefix or flag. There was a time when web developers would have got out the pitchforks if a browser was doing this, but I sense some complacency seeping in.
Slides from a conference talk with a really clear explanation of how
await works with promises.
Sunday, January 7th, 2018
This is a “what if?” scenario, but it’s all too plausible.
For site owners, the (partial) solution is to have a strong Content Security Policy.
(In the wake of Spectre and Meltdown, this is now a perfectly legitimate action for security-conscious web users to take; I hope your site can support that.)
A nice clear explanation of specifying colour using HSB (not to be confused with HSL).
Saturday, January 6th, 2018
Ana goes into exhaustive detail on all the differences in the shadow DOM and styling of
input type="range" across browsers.
I’m totally fine with browsers providing different styling for complex UI elements like this, but I wish they’d at least provide a consistent internal structure and therefore a consistent way of over-riding the default styles. Maybe then people wouldn’t be so quick to abandon native elements like this in favour building their own UI components from scratch—the kind of over-engineering that inevitably ends up being under-engineered.
While not every white man who dislikes The Last Jedi overtly dislikes its gender balance or diversity, many feel a level of discomfort with this film that they can’t name, and that expresses itself through a wide variety of odd, conflicting complaints about its filmmaking.
Friday, January 5th, 2018
I write to understand and remember. Sometimes that will be interesting to others, often it won’t be.
But it’s going to happen. Here, on my own site.
A nice overview of the Payment Request API, which is getting more and more browser support.
Paul walks us through the process of making some incremental accessibility improvements to this year’s 24 Ways.
Creating something new will always attract attention and admiration, but there’s an under-celebrated nobility in improving what already exists. While not all changes may be visual, they can have just as much impact.
Ooh, this is clever! Scott shows how you can use
Thursday, January 4th, 2018
Wednesday, January 3rd, 2018
A report on Science Hack Day Berlin (published on the excellent eLife website).
It’s a shame that this archiving project is coming to end. We don’t always know the future value of the present:
Researchers have come to realize that the Proceedings of the Old Bailey, transcriptions from London’s central criminal court, are the only record we have of the spoken words of many people who lived centuries ago but were not in the educated or elite classes. That we have them talking about the theft of a pig rather than the thought of Aristotle only gives us greater insight into the lived experience of their time.
I’m always happy to see a thriving market of competition amongst browsers—we had a browser monopoly once before and it was a bad situation.
(That said, UC Browser has its own issues.)
Tuesday, January 2nd, 2018
Annoying WiFi passwords in cafes:
all one word
And the whole thing is available here for free under a Creative Commons licence!
Liberally licensed SVG illustrations by Katerina Limpitsouni with customisable colour schemes.
The field of front-end has yet to be defined, because our industry moves too quickly and the range of skills required seems to grow with every passing day. We need to realise that it is impossible to be an expert in every one of those skills, and that’s perfectly fine.
Monday, January 1st, 2018
A great round-up of Leading Design—one of the best events I attended in 2017.
Summarising a year of writing, eating, listening, and reading:
Words I wrote in 2017
I wrote 78 blog posts in 2017. That works out at an average of six and a half blog posts per month. I’ll take it.
Here are some pieces of writing from 2017 that I’m relatively happy with:
Going Rogue. A look at the ethical questions raised by Rogue One
In AMP we trust. My unease with Google’s AMP format was growing by the day.
A minority report on artificial intelligence. Revisiting two of Spielberg’s films after a decade and a half.
Progressing the web. I really don’t want progressive web apps to just try to imitate native apps. They can be so much more.
CSS. Simple, yes, but not easy.
Intolerable. A screed. I still get very, very angry when I think about how that manifestbro duped people.
Акула. Recounting a story told by a taxi driver.
Hooked and booked. Does A/B testing lead to dark patterns?
Ubiquity and consistency. Different approaches to building on the web.
I hope there’s something in there that you like. It always a nice bonus when other people like something I’ve written, but I write for myself first and foremost. Writing is how I figure out what I think. I will, of course, continue to write and publish on my website in 2018. I’d really like it if you did the same.
Food I ate in 2017
Portugal will always be a culinary hotspot for me, particularly Porto (“tripas à moda do Porto” is one of the best things I’ve ever tasted). When I was teaching at the New Digital School in Porto back in February, I took full advantage of the culinary landscape. A seafood rice (and goose barnacles) at O Gaveto in Matosinhos was a particular highlight.
The most unexpected thing I ate in Porto was when I wandered off for lunch on my own one day. I ended up in a little place where, when I walked in, it was kind of like that bit in the Western when the music stops and everyone turns to look. This was clearly a place for locals. The owner didn’t speak any English. I didn’t speak any Portuguese. But we figured it out. She mimed something sandwich-like and said a word I wasn’t familiar with: bifana. Okay, I said. Then she mimed the universal action for drinking, so I said “agua.” She looked at with a very confused expression. “Agua!? Não. Cerveja!” Who am I to argue? Anyway, she produced this thing which was basically some wet meat in a bun. It didn’t look very appetising. But this was the kind of situation where I couldn’t back out of eating it. So I took a bite and …it was delicious! Like, really, really delicious.
Later in February, we went to Pittsburgh to visit Cindy and Matt. We were there for my birthday, so Cindy prepared the most amazing meal. She reproduced a dish from the French Laundry—sous-vide lobster on orzo. It was divine!
Later in the year, we went to Singapore for the first time. The culture of hawker centres makes it the ideal place for trying lots of different foods. There were some real revelations in there.
We visited lots of other great places like Reykjavík, Lisbon, Barcelona, and Nuremberg. But as well as sampling the cuisine of distant locations, I had some very fine food right here in Brighton, home to Trollburger, purveyors of the best burger you’ll ever eat.
I also have a thing for hot wings, so it’s very fortunate that The Joker, home to the best wings in Brighton, is just around the corner from the dance studio where Jessica goes for ballet. Regular wing nights became a thing in 2017.
I started a little routine in 2017 where I’d take a break from work in the middle of the afternoon, wander down to the seafront, and buy a single oyster. It only took a few minutes out of the day but it was a great little dose of perspective each time.
But when I think of my favourite meals of 2017, most of them were home-cooked.