This is mostly on-purpose research. More passive input, things encountered by chance or in a similarly roundabout way, is filed under ephemera. See also output. Follow via RSS.
Published
Check out WAI’s alt Decision Tree. Really useful for considering how alt text should work against any image.
And more broadly, their tutorials seem great, super practical and succinct. Don’t know how I’d missed them before. The whole WAI website is an unbelievable resource, we’re so lucky to have it.
Published
So CommandR hasn’t been reloading my VSCode window. But the “Reload window” command in the palette (ShiftCommandP to open palette) shows that it should work. Charles told me how to fix it!
To sort it out, click the cog icon next to the “Reload window” command in the palette to open the Keyboard Shortcuts settings for that command. Then under the “When” column, right-click isDevelopment and select “Change when expression”. Delete the contents, then press enter. There should now be a dash under “When” to indicate that it’s empty. Close the Keyboard Shortcuts file, then try reloading a window by typing CommandR and it should work.
Published
Good enough for now, and safe enough to try
Yesterday, Gemma gave the SuperHi community a great talk on her work with Common Knowledge, a not-for-profit worker cooperative of technologists, designers, researchers and facilitators. She mentioned sociocracy, a governance framework that Common Knowledge works with to keep running smoothly.
When faced with a decision that requires consensus, the group evaluates whether or not the proposal is “good enough for now and safe enough to try”.
This was a bit of a lightbulb moment for me. There are so many groups that I have been a part of that would have been liberated by this approach.
But not even that, my own brain would be freed up a bit by this approach. I sometimes get hung up on figuring out the best solution to something, when figuring out a good solution to something might cause significantly less stress and quicker results.
I suppose when you apply it to your own decisions, it’s similar to “perfect is the enemy of good”. But that’s more vague. I like that this phrase is more direct, something you can actually apply to the decision making process.
Published
To read: “Let a 1,000 flowers bloom. Then rip 999 of them out by the roots.” by Peter Seibel
Peter Seibel was the lead of Twitter’s Engineering Effectiveness group. This 2015 essay is an extended version of a talk that he gave on the same subject. The TL;DR as he describes it: “as an industry we mostly don’t know how to do it and consequently massively under-invest in making our engineering orgs actually effective.” It’s a really interesting play-by-play of how the complexity and scale of Twitter as an app changed and grew over time.
Side note: With what’s going on at Twitter now, I’d bet my booty that the Engineering Effectiveness group is no longer of this world. Though perhaps that happened before Elon, who knows.
Shared by RS during one of our SuperHi Engineering chats.
Published
I think the best creative advice I ever got was from my tutor at CSM.
Don’t dot every I and cross every T, don’t tie up every loose end. Leave some questions unanswered. A piece of art, a movie, a song, a performance, they all tend to be more compelling when they leave you wondering.
I tended to be very goal-oriented in my visual art practice, with an idea of exactly what I wanted the final product to be. This usually left me with frustration when I couldn’t quite get it there, and a piece that was overworked and somehow boring, despite my efforts. When I spent a little more time just focusing on the process and letting go of the result, it was both more fun and far more interesting to look at in the end.
I don’t have much of an art practice at the moment, though sometimes I look at this website as one big, long-haul creative endeavor.
Published
I’m working on a site with a complex entanglement of blend modes, SVG backgrounds, gradient backgrounds, positioning, and transitions. I’ve run in to a bunch of issues with mix-blend-mode not working as expected, and it almost always has to do with an inappropriate stacking context.
For posterity, this StackOverflow answer is a really good run-down of CSS combos that create new stacking contexts.
Now to see what I can do about browsers rendering color profiles slightly differently… 💀
Edit: UGHHHHHH it’s different in different browsers. Check out this CodePen in Chrome and Firefox vs Safari. This is why we can’t have nice things.
Edit 2: See the answer to the cross-browser problem from the previous CodePen, via Gregory Cadars (view thread). So Safari is actually behaving correctly, but it’s still a stacking context issue.
To recap: I’m trying to display a “fixed” gradient background with content that scrolls over the top of it. Within this content, only the images have mix-blend-mode: overlay. In the original CodePen, I’m achieving this via a fixed position, 100% width + 100% height element with a linear gradient. This is within the same wrapper as the content.
My example is working in Chrome and Firefox. In Safari, it is effectively as if the blend mode hasn’t been applied. Though I’m not sure why the difference between browsers, it does make sense that a fixed position element would still create a new stacking context regardless of its parent.
In Gregory’s example, he’s removed the fixed position element with the gradient and instead applied the gradient background to the wrapper, as well as background-attachment: fixed via the background shorthand. This achieves the exact same effect, without stacking context issues.
The only thing that gives me pause is performance… I remember running in to some issues when I considered using background-attachment: fixed for Elizabeth Peyton’s Eternal Return. I can’t remember what it was exactly but it had to do with repainting on every scroll event (so, a lot!). I think that this article may give some context, but I’ll have to dig in to it further.
Related: See this CSS gradients resampling tool by Rutherford Craze for smoother gradients, shared by Gregory in the thread.
Twitter is a crappy place a lot of the time, but I love it for things like this.
Published
Just finished the article “Ontological Design Has Become Influential In Design Academia – But What Is It?” by JP Hartnett for AIGA Eye on Design, via the Feminist Open Source Investigations Group chat.
This is somewhat related to the previous post, the “we are our experiences” concept. But much more formal than my ramblings, better philosophical underpinnings for sure!
I’d heard of ontological design but hadn’t really dug in to it. This article is a useful dive in.
In very few words (specifically professor of design theory Anne-Marie Willis’s words, not mine): “Design designs us”. In more words, from Hartnett’s article:
A human being cannot exist independently of its surrounding environment — it is not possible to be without being-in-the-world. Being, then, is always relational: with everything that surrounds us, including the full complexity of the completely designed worlds that we inhabit. This point is crucial for ontological design theorists: design doesn’t just perform certain functions — a car transports you from A to B, a poster displays information, etc. — the interrelated totality of designs construct the world through which humans are brought into being and come to be defined through. Human beings, in turn, design the world, which, in turn, designs them… and so on. The process is circular, like an endless loop.
And on the consequences of embracing ontological design in practice instead of relegating it to theory and academia:
One welcome outcome of an embrace of ontological design theory would be the death of the individualism that has plagued the design profession — “iconic” designs, individual designers, celebrated in isolation as they usually are in design publications — don’t make any sense in this context.
That would be welcome indeed.
I don’t quite see how it can happen unless there is a true revolution in the way we talk and think about design—more holistic and less about singular problems, more collective and less individual—but maybe circumstances are ripening for such a change.
Published
I’m working on an Eleventy site at the moment, the first Eleventy site I’ve done that’s been complex enough CSS-wise to warrant using Sass. I’ve turned to Phil Hawksworth’s Sass + Eleventy technique for the job. It’s a great, simple way of using Sass with Eleventy with a little bit of preprocessing courtesy of Gulp.
Hit a wall at one point though, it was smooth sailing and then my CSS updates just stopped working.
Turns out I had added /_includes/main.css (the compiled styles) to my .gitignore file since I prefer not to commit compiled files, but I forgot that Eleventy uses the .gitignore file + the .eleventyignore file to decide what not to compile. So Eleventy was just ignoring it. 🤦🏻♀️
I did this .gitignore change as an end-of-day commit, tidying things up before closing my laptop. When I picked the project back up days later, it took me longer than I’d like to admit to figure out what was going on!
To sort it, I just had to opt out of using .gitignore by adding eleventyConfig.setUseGitIgnore(false); to the .eleventy.js config file, and then adding the necessary files listed in .gitignore to .eleventyignore. Then I re-ran gulp watch & npx eleventy --serve, and all was well.
Separate but related to static site generators: Check out Astro. Would be curious to see a detailed comparison of Eleventy vs Astro since Eleventy is currently top-of-the-list for me in terms of static site generators.
Published
I missed these two articles by Tom MacWright from last year.
Second-guessing the modern web, 10 May 2020
If not SPAs, What?, 28 October 2020
In both, he outlines few upsides and downsides about the single page app (SPA) approach to websites and has a few points that I have really struggled to articulate in the past.
From “Second-guessing”:
There is a swath of use cases which would be hard without React and which aren’t complicated enough to push beyond React’s limits. But there are also a lot of problems for which I can’t see any concrete benefit to using React. Those are things like blogs, shopping-cart-websites, mostly-CRUD-and-forms-websites. For these things, all of the fancy optimizations are trying to get you closer to the performance you would’ve gotten if you just hadn’t used so much technology.
I’ve dabbled with React and Vue in small side projects and experiments. But the point above is the big reason I’ve never taken the time to sit down and learn either of them properly. For almost every client site I’ve ever done, it just didn’t make sense to make it an SPA.
And I’m not 100% sure, but I think this might contribute to longevity. Some of my clients are still working with the same sites I built for them nearly 10 years ago, a few with just minor security-related updates in the meantime and no other maintenance strictly required. That’s not to say that those sites couldn’t use a “lick of paint” to bring them in to the 2020s; the point is that they work. And for organizations working on really tight budgets, or budgets that fluctuate wildly due to public funding, stability is really important. They can’t afford a developer on retainer to keep things running smoothly.
But of course the SPA vibe is pretty attractive, particularly for cultural orgs. MacWright has some decent alternatives suggested in “If not SPAs” including Turbolinks, Barba.js, and instant.page. Will also mention MoOx/pjax since I’ve used it before for page transitions with very good results, but probably won’t use it in the future as it hasn’t been updated in a while.
And again, there’s the rub. The more non-native scripts, plugins, etc I use in a project, the more likely that it’s going to be a major headache (and thus major time/money for the client) for me to change things down the line if or when that bit of tech is no longer supported or has changed significantly.
So it’s not even so much about being wary of React or Vue, it’s about not making assumptions, being cautious and cognizant of future needs or restrictions when proposing a tech stack. Any tech stack you choose will ultimately become a ball-and-chain, not just those based on JavaScript frameworks. It’s just that the ball can sometimes be heavier than it needed to be, and you can anticipate that with a little foresight.
Published
This Q&A is compiled from conversations I have had with many, many clients and collaborators who have had a hard time navigating things like the GDPR, privacy policies, cookie notices, consent messaging, and other related topics.
Here are all the questions covered below: