A handy browser-based tool for examining font files to see which features they support.
Wednesday, March 21st, 2018
Sunday, March 4th, 2018
Friday, March 2nd, 2018
Just change it
Amber and I often have meta conversations about the nature of learning and teaching. We swap books and share ideas and experiences whenever we’re trying to learn something or trying to teach something. A topic that comes up again and again is the idea of “the curse of knowledge“—it’s the focus of Steven Pinker’s book The Sense Of Style. That’s when the author/teacher can’t remember what it’s like not to know something, which makes for a frustrating reading/learning experience.
This is one of the reasons why I encourage people to blog about stuff as they’re learning it; not when they’ve internalised it. The perspective that comes with being in the moment of figuring something out is invaluable to others. I honestly think that most explanatory books shouldn’t be written by experts—the “curse of knowledge” can become almost insurmountable.
I often think about this when I’m reading through the installation instructions for frameworks, libraries, and other web technologies. I find myself put off by documentation that assumes I’ve got a certain level of pre-existing knowledge. But now instead of letting it get me down, I use it as an opportunity to try and bridge that gap.
The brilliant Safia Abdalla wrote a post a while back called How do I get started contributing to open source?. I definitely don’t have the programming chops to contribute much to a codebase, but I thoroughly agree with Safia’s observation:
If you’re interested in contributing to open source to improve your communication and empathy skills, you’re definitely making the right call. A lot of open source tools could definitely benefit from improvements in the documentation, accessibility, and evangelism departments.
What really jumps out at me is when instructions use words like “simply” or “just”. I’m with Brad:
“Just” makes me feel like an idiot. “Just” presumes I come from a specific background, studied certain courses in university, am fluent in certain technologies, and have read all the right books, articles, and resources. “Just” is a dangerous word.
But rather than letting that feeling overwhelm me, I now try to fix the text. Here are a few examples of changes I’ve suggested, usually via pull requests on Github repos:
- The instructions on the AMP validator page.
- The documentation for Composer, the PHP dependency manager.
They all have different codebases in different programming languages, but they’re all intended for humans, so having clear and kind documentation is a shared goal.
I like suggesting these kinds of changes. That initial feeling of frustration I get from reading the documentation gets turned into a warm fuzzy feeling from lending a helping hand.
Saturday, February 24th, 2018
Luke Stevens is trying to get untangle the very mixed signals being sent from different parts of Google around AMP’s goals. The response he got—before getting shut down—is very telling in its hubris and arrogance.
I believe the people working on the AMP format are well-intentioned, but I also believe they have conflated the best interests of Google with the best interests of the web.
Wednesday, February 14th, 2018
So, to recap, the web community has stated over and over again that we’re not comfortable with Google incentivizing the use of AMP with search engine carrots. In response, Google has provided yet another search engine carrot for AMP.
This wouldn’t bother me if AMP was open about what it is: a tool for folks to optimize their search engine placement. But of course, that’s not the claim. The claim is that AMP is “for the open web.”
Spot on, Tim. Spot on.
If AMP is truly for the open web, de-couple it from Google search entirely. It has no business there.
Look, AMP, you’re either a tool for the open web, or you’re a tool for Google search. I don’t mind if you’re the latter, but please stop pretending you’re something else.
Saturday, January 20th, 2018
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.
Wednesday, January 10th, 2018
Suggestions for small interface tweaks.
Tuesday, January 9th, 2018
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.
Friday, December 15th, 2017
A rather handsome looking free serif typeface based on Gargantua. Spectral is available under an Open Font License.
Sunday, November 5th, 2017
With echoes of Anil Dash’s The Web We Lost, this essay is a timely reminder—with practical advice—for we designers and developers who are making the web …and betraying its users.
You see, the web wasn’t meant to be a gated community. It’s actually pretty simple.
A web server, a public address and an HTML file are all that you need to share your thoughts (or indeed, art, sound or software) with anyone in the world. No authority from which to seek approval, no editorial board, no publisher. No content policy, no dependence on a third party startup that might fold in three years to begin a new adventure.
That’s what the web makes possible. It’s friendship over hyperlink, knowledge over the network, romance over HTTP.
Tuesday, October 31st, 2017
A nice free and open source font designed for digital interfaces:
Inter UI is a font for highly legible text on computer screens.
JP Rangaswami also examines the rise of the platforms but he’s got some ideas for a more sustainable future:
A part of me wants to evoke Jane Jacobs and Christopher Alexander when it comes to building sustainable platforms. The platform “community” needs to be cared for and looked after, the living spaces they inhabit need to be designed to last. Multipurpose rather than monoculture, diverse rather than homogeneous . Prior industrial models where entire communities would rely on a single industry need to be learnt from and avoided. We shouldn’t be building the rust belts of the future. We should be looking for the death and life of great platforms, for a pattern language for sustainable platforms.
This is the clickbaitiest of titles, but the post has some good sobering analysis of how much traffic driven by a small handful players. It probably won’t make you feel very cheery about the future.
(For some reason, this article uses all-caps abbreviations for company names, as though a stock ticker started generating hot takes: GOOG, FB, AMZN, etc. It’s a very odd writing style for a human.)
Sunday, October 29th, 2017
The meaning of AMP
But when I hear AMP described as an open, community-led project, it strikes me as incredibly problematic, and more than a little troubling. AMP is, I think, best described as nominally open-source. It’s a corporate-led product initiative built with, and distributed on, open web technologies.
But so what, right? Tom-ay-to, tom-a-to. Well, here’s a pernicious example of where it matters: in a recent announcement of their intent to ship a new addition to HTML, the Google Chrome team cited the mood of the web development community thusly:
Web developers: Positive (AMP team indicated desire to start using the attribute)
If AMP were actually the product of working web developers, this justification would make sense. As it is, we’ve got one team at Google citing the preference of another team at Google but representing it as the will of the people.
This is just one example of AMP’s sneaky marketing where some finely-shaved semantics allows them to appear far more reasonable than they actually are.
At AMP Conf, the Google Search team were at pains to repeat over and over that AMP pages wouldn’t get any preferential treatment in search results …but they appear in a carousel above the search results. Now, if you were to ask any right-thinking person whether they think having their page appear right at the top of a list of search results would be considered preferential treatment, I think they would say hell, yes! This is the only reason why The Guardian, for instance, even have AMP versions of their content—it’s not for the performance benefits (their non-AMP pages are faster); it’s for that prime real estate in the carousel.
The same semantic nit-picking can be found in their defence of caching. See, they’ve even got me calling it caching! It’s hosting. If I click on a search result, and I am taken to page that has a URL beginning with
https://www.google.com/amp/s/... then that page is being hosted on the domain
google.com. That is literally what hosting means. Now, you might argue that the original version was hosted on a different domain, but the version that the user gets sent to is the Google copy. You can call it caching if you like, but you can’t tell me that Google aren’t hosting AMP pages.
That’s a particularly low blow, because it’s such a bait’n’switch. One of the reasons why AMP first appeared to be different to Facebook Instant Articles or Apple News was the promise that you could host your AMP pages yourself. That’s the very reason I first got interested in AMP. But if you actually want the benefits of AMP—appearing in the not-search-results carousel, pre-rendered performance, etc.—then your pages must be hosted by Google.
So, to summarise, here are three statements that Google’s AMP team are currently peddling as being true:
- AMP is a community project, not a Google project.
- AMP pages don’t receive preferential treatment in search results.
- AMP pages are hosted on your own domain.
I don’t think those statements are even truthy, much less true. In fact, if I were looking for the right term to semantically describe any one of those statements, the closest in meaning would be this:
A statement used intentionally for the purpose of deception.
That is the dictionary definition of a lie.
Update: That last part was a bit much. Sorry about that. I know it’s a bit much because The Register got all gloaty about it.
I don’t think the developers working on the AMP format are intentionally deceptive (although they are engaging in some impressive cognitive gymnastics). The AMP ecosystem, on the other hand, that’s another story—the preferential treatment of Google-hosted AMP pages in the carousel and in search results; that’s messed up.
Still, I would do well to remember that there are well-meaning people working on even the fishiest of projects.
Except for the people working at the shitrag that is The Register.
(The other strong signal that I overstepped the bounds of decency was that this post attracted the pond scum of Hacker News. That’s another place where the “well-meaning people work on even the fishiest of projects” rule definitely doesn’t apply.)
Saturday, October 7th, 2017
I’ve written before about how I use apps on my phone:
If I install an app on my phone, the first thing I do is switch off all notifications. That saves battery life and sanity.
The only time my phone is allowed to ask for my attention is for phone calls, SMS, or FaceTime (all rare occurrences). I initiate every other interaction—Twitter, Instagram, Foursquare, the web. My phone is a tool that I control, not the other way around.
To me, this seems like a perfectly sensible thing to do. I was surprised by how others thought it was radical and extreme.
I’m always shocked when I’m out and about with someone who has their phone set up to notify them of any activity—a mention on Twitter, a comment on Instagram, or worst of all, an email. The thought of receiving a notification upon receipt of an email gives me the shivers. Allowing those kinds of notifications would feel like putting shackles on my time and attention. Instead, I think I’m applying an old-school RSS mindset to app usage: pull rather than push.
Don’t get me wrong: I use apps on my phone all the time: Twitter, Instagram, Swarm (though not email, except in direst emergency). Even without enabling notifications, I still have to fight the urge to fiddle with my phone—to check to see if anything interesting is happening. I’d like to think I’m in control of my phone usage, but I’m not sure that’s entirely true. But I do know that my behaviour would be a lot, lot worse if notifications were enabled.
I was a bit horrified when Apple decided to port this notification model to the desktop. There doesn’t seem to be any way of removing the “notification tray” altogether, but I can at least go into System Preferences and make sure that absolutely nothing is allowed to pop up an alert while I’m trying to accomplish some other task.
It’s the same on iOS—you can control notifications from Settings—but there’s an added layer within the apps themselves. If you have notifications disabled, the apps encourage you to enable them. That’s fine …at first. Being told that I could and should enable notifications is a perfectly reasonable part of the onboarding process. But with some apps I’m told that I should enable notifications Every. Single. Time.
Of the apps I use, Instagram and Swarm are the worst offenders (I don’t have Facebook or Snapchat installed so I don’t know whether they’re as pushy). This behaviour seems to have worsened recently. The needling has been dialed up in recent updates to the apps. It doesn’t matter how often I dismiss the dialogue, it reappears the next time I open the app.
In the grand scheme of things, it’s not a big deal, but I would appreciate some respect for my deliberate choice. It gets pretty wearying over the long haul. To use a completely inappropriate analogy, it’s like a recovering alcoholic constantly having to rebuff “friends” asking if they’re absolutely sure they don’t want a drink.
I don’t think there’s malice at work here. I think it’s just that I’m an edge-case scenario. They’ve thought about the situation where someone doesn’t have notifications enabled, and they’ve come up with a reasonable solution: encourage that person to enable notifications. After all, who wouldn’t want notifications? That question, if it’s asked at all, is only asked rhetorically.
I’m trying to do the healthy thing here (or at least the healthier thing) in being mindful of my app usage. They sure aren’t making it easy.
The model that web browsers use for notifications seems quite sensible in comparison. If you arrive on a site that asks for permission to send you notifications (without even taking you out to dinner first) then you have three options: allow, block, or dismiss. If you choose “block”, that site will never be able to ask that browser for permission to enable notifications. Ever. (Oh, how I wish I could apply that browser functionality to all those sites asking me to sign up for their newsletter!)
That must seem like the stuff of nightmares for growth-hacking disruptive startups looking to make their graphs go up and to the right, but it’s a wonderful example of truly user-centred design. In that situation, the browser truly feels like a user agent.
Thursday, September 14th, 2017
There’s going to be a CodePen meetup in Brighton as part of the Brighton Digital Festival. Should be fun! See you there.
Wednesday, August 23rd, 2017
Paul Ford jots down his thoughts on that report on Ev’s blog:
The web is inherently decentralized, which has made it much easier for large companies to create large, centralized platforms. It’s a paradox and very thorny. I’m writing this on a centralized platform called Medium. Clap!
I like his geeky idea for mini self-contained social networks:
What I want is like, 5 of these little computers and whenever I see a truly trusted friend, I just give them one. And they take it home, and plug it in somewhere, and now we’re on the same, secure network together. Sharing files and with a little messageboard. Maybe after 5 computers the network can’t get any bigger. And if you unplug one your whole archive goes down. I don’t know. I’m riffing here.
Tuesday, August 22nd, 2017
A few technical words about Upsideclown, and some thoughts about audiences and the web (17 Aug., 2017, at Interconnected)
Matt writes about the pleasure of independent publishing on the web today:
It feels transgressive to have a website in 2017. Something about having a domain name and about coding HTML which is against the grain now. It’s something big companies do, not small groups. We’re supposed to put our content on Facebook or Medium, or keep our publishing to an email newsletter. But a website?
But he points out a tension between the longevity that you get from hosting the canonical content yourself, and the lack of unified analytics when you syndicate that content elsewhere.
There’s no simple online tool that lets me add up how many people have read a particular story on Upsideclown via the website, the RSS feed, and the email newsletter. Why not? If I add syndication to Facebook, Google, and Apple, I’m even more at sea.
Tuesday, July 11th, 2017
We don’t want the field to de-democratize and become the province solely of those who can slog through a computer science degree.
So we need new tools that let everyone see, understand, and remix today’s web. We need, in other words, to reboot the culture of View Source.