Jeremy Keith

Jeremy Keith

Making websites. Writing books. Speaking at events. Living in Brighton. Working at Clearleft. Playing music. Taking photos. Answering email.

Journal 2711 sparkline Links 8835 sparkline Articles 76 sparkline Notes 5617 sparkline

Tuesday, August 18th, 2020

Monday, August 17th, 2020

Design Principles For The Web—the links

I’m speaking today at an online edition of An Event Apart called Front-End Focus. I’ll be opening up the show with a talk called Design Principles For The Web, which ironically doesn’t have much of a front-end focus:

Designing and developing on the web can feel like a never-ending crusade against the unknown. Design principles are one way of unifying your team to better fight this battle. But as well as the design principles specific to your product or service, there are core principles underpinning the very fabric of the World Wide Web itself. Together, we’ll dive into applying these design principles to build websites that are resilient, performant, accessible, and beautiful.

That explains why I’ve been writing so much about design principles …well, that and the fact that I’m mildly obsessed with them.

To avoid technical difficulties, I’ve pre-recorded the talk. So while that’s playing, I’ll be spamming the accompanying chat window with related links. Then I’ll do a live Q&A.

Should you be interested in the links that I’ll be bombarding the attendees with, I’ve gathered them here in one place (and they’re also on the website of An Event Apart). The narrative structure of the talk might not be clear from scanning down a list of links, but there’s some good stuff here that you can dive into if you want to know what the inside of my head is like.

References

adactio.com

Wikipedia

Mind the gap

In May 2012, Brian LeRoux, the creator of PhoneGap, wrote a post setting out the beliefs, goals and philosophy of the project.

The beliefs are the assumptions that inform everything else. Brian stated two core tenets:

  1. The web solved cross platform.
  2. All technology deprecates with time.

That second belief then informed one of the goals of the PhoneGap project:

The ultimate purpose of PhoneGap is to cease to exist.

Last week, PhoneGap succeeded in its goal:

Since the project’s beginning in 2008, the market has evolved and Progressive Web Apps (PWAs) now bring the power of native apps to web applications.

Today, we are announcing the end of development for PhoneGap.

I think Brian was spot-on with his belief that all technology deprecates with time. I also think it was very astute of him to tie the goals of PhoneGap to that belief. Heck, it’s even in the project name: PhoneGap!

I recently wrote this about Sass and clamp:

I’ve said it before and I’ll say it again, the goal of any good library should be to get so successful as to make itself redundant. That is, the ideas and functionality provided by the tool are so useful and widely adopted that the native technologies—HTML, CSS, and JavaScript—take their cue from those tools.

jQuery is the perfect example of this. jQuery is no longer needed because cross-browser DOM Scripting is now much easier …thanks to jQuery.

Successful libraries and frameworks point the way. They show what developers are yearning for, and that’s where web standards efforts can then focus. When a library or framework is no longer needed, that’s not something to mourn; it’s something to celebrate.

That’s particularly true if the library of code needs to be run by a web browser. The user pays a tax with that extra download so that the developer gets the benefit of the library. When web browsers no longer need the library in order to provide the same functionality, it’s a win for users.

In fact, if you’re providing a front-end library or framework, I believe you should be actively working towards making it obselete. Think of your project as a polyfill. If it’s solving a genuine need, then you should be looking forward to the day when your code is made redundant by web browsers.

One more thing…

I think it was great that Brian documented PhoneGap’s beliefs, goals and philosophy. This is exactly why design principles can be so useful—to clearly set out the priorities of a project, so that there’s no misunderstanding or mixed signals.

If you’re working on a project, take the time to ask yourself what assumptions and beliefs are underpinning the work. Then figure out how those beliefs influence what you prioritise.

Ultimately, the code you produce is the output generated by your priorities. And your priorities are driven by your purpose.

You can make those priorities tangible in the form of design principles.

You can make those design principles visible by publishing them.

Netlify redirects and downloads

Making the Clearleft podcast is a lot of fun. Making the website for the Clearleft podcast was also fun.

Design wise, it’s a riff on the main Clearleft site in terms of typography and general layout. On the development side, it was an opportunity to try out an exciting tech stack. The workflow goes something like this:

  • Open a text editor and type out HTML and CSS.

Comparing this to other workflows I’ve used in the past, this is definitely the most productive way of working. Some stats:

  • Time spent setting up build tools: 00:00
  • Time spent wrangling the pipeline to do exactly what you want: 00:00
  • Time spent trying to get the damn build tools to work again when you return to the project after leaving it alone for more than a few months: 00:00:00

I have some files. Some images, three font files, a few pages of HTML, one RSS feed, one style sheet, and one minimal service worker script. I don’t need a web server to do anything more than serve up those files. No need for any dynamic server-side processing.

I guess this is JAMstack. Though, given that the J stands for JavaScript, the A stands for APIs, and I’m not using either, technically it’s Mstack.

Netlify suits my hosting needs nicely. It also provides the added benefit that, should I need to update my CSS, I don’t need to add a query string or anything to the link elements in the HTML that point to the style sheet: Netlify does cache invalidation for you!

The mp3 files of the actual podcast episodes are stored on S3. I link to those mp3 files from enclosure elements in the RSS feed, which is what makes it a podcast. I also point to the mp3 files from audio elements on the individual episode pages—just above the transcript of each episode. Here’s the page for the most recent episode.

I also want people to be able to download the mp3 file directly if they want (or if they want to huffduff an episode). So I provide a link to the mp3 file with a good ol’-fashioned a element with an href attribute.

I throw in one more attribute on that link. The download attribute tells the browser that the URL in the href attribute should be downloaded instead of visited. If you give a value for the download attribute, it will over-ride the file name:

<a href="/files/ugly-file-name.xyz" download="nice-file-name.xyz">download</a>

Or you can use it as a Boolean attribute without any value if you’re happy with the file name:

<a href="/files/nice-file-name.xyz" download>download</a>

There’s one catch though. The download attribute only works for files on the same origin. That’s an issue for me. My site is podcast.clearleft.com but my audio files are hosted on clearleft-audio.s3.amazonaws.com—the download attribute will be ignored and the mp3 files will play in the browser instead of downloading.

Trys pointed me to the solution. It turns out that Netlify can do some server-side processing. It can do redirects.

I added a file called _redirects to the root of my project. It contains one line:

/download/*  https://clearleft-audio.s3.amazonaws.com/podcast/:splat  200

That says that any URLs beginning with /download/ should redirect to clearleft-audio.s3.amazonaws.com/podcast/. Everything after the closing slash is captured with that wild card asterisk. That’s then passed along to the redirect URL as :splat. That’s a new one on me. I hadn’t come across that terminology, but as someone who can never remember the syntax of regular expressions, it works for me.

Oh, and the 200at the end is the status code: okay.

Now I can use this /download/ path in my link:

<a href="/download/season01episode06.mp3" download>Download mp3</a>

Because this URL on the same origin, the download attribute works just fine.

Sunday, August 16th, 2020

Reading Agency by William Gibson.

Solid Start

A four-point checklist for inclusive design:

Are you a person that makes digital things for other people? Awesome—because this page is all about making things for people. There are four ways you can improve your creation for everybody. All four are testable, fixable and they improve usability for everybody.

The Clearleft podcast and the decline of design · Paul Robert Lloyd

Now this is the kind of response I was hoping to stir up with the first season of the Clearleft podcast!

With echos of design’s subjugation reverberating across all six episodes, this first season inadvertently told the story of how my profession has been captured by a desire to serve business interests above all others, while being disarmed by its tendency for introspection and need to be recognised.

Can digital design redeem itself? I hope so. Maybe in the next season of the Clearleft podcast, we’ll find out how.

2020: an isolation odyssey on Vimeo

What a brilliant homage! And what a spot-on pop-cultural reference for The Situation.

2020: an isolation odyssey is a reenactment of the iconic finale of 2001: A Space Odyssey (Stanley Kubrick, 1968). Restaged in the context of home quarantine, the journey through time adapts to the mundane dramas of self-isolation–poking fun at the navel-gazing saga of life alone and indoors.

Saturday, August 15th, 2020

Friday, August 14th, 2020

Marxian Alienation And Web Development: HeydonWorks

As a web designer or developer burnout comes calling when you try to do good work, but you’re not allowed.

  • You want to make the app more performant; your boss wants to fill it full of third party trackers
  • You want to make the app more accessible; your boss wants you to focus on the ‘able market’ instead
  • You want to word the app more clearly; your boss wants to trick users with misleading language

If you are a good developer, and a good person, asked to do shit work, you will burn out.

Thursday, August 13th, 2020

Season one of the Clearleft podcast

The Clearleft Podcast has finished its inaugural season.

I have to say, I’m pretty darned pleased with the results. It was equal parts fun and hard work.

Episode One

Design Systems. This was a deliberately brief episode that just skims the surface of all that design systems have to offer. It is almost certainly a theme that I’ll revisit in a later episode, or even a whole season.

The main goal of this episode was to get some answers to the questions:

  1. What is a design system exactly? and
  2. What’s a design system good for?

I’m not sure if I got answers or just more questions, but that’s no bad thing.

Episode Two

Service Design. This is the classic topic for this season—an investigation into a phrase that you’ve almost certainly heard of, but might not understand completely. Or maybe that’s just me. In any case, I think that coming at this topic from a viewpoint of relative ignorance is quite a benefit: I have no fear of looking stupid for asking basic questions.

Episode Three

Wildlife Photographer Of The Year. A case study. This one was a lot of fun to put together.

It also really drove home to just how talented and hard-working my colleagues at Clearleft are. I just kept thinking, “Damn! This is some great work!

Episode Four

Design Ops. Again, a classic example of me asking the dumb questions. What is this “design ops” thing I’ve heard of? Where’d it come from?

My favourite bit of feedback was “Thanks to the podcast, I now know what DesignOps is. I now also hate DesignOps”

I couldn’t resist upping the ante into a bit of a meta-discussion about whether we benefit or not from the introduction of new phrases like this into our work.

Episode Five

Design Maturity. This could’ve been quite a dry topic but I think that Aarron made it really engaging. Maybe the samples from Bladerunner and Thunderbirds helped too.

This episode finished with a call to action …with the wrong URL. Doh! It should’ve been surveymonkey.co.uk/r/designmaturity

Episode Six

Design Sprints. I like how the structure of this one turned out. I felt like we tackled quite a few angles in less than 25 minutes.

That’s a good one to wrap up this season, I reckon.

If you’re interested in the behind-the-scenes work that went into each episode, I’ve been blogging about each one:

  1. Design Systems
  2. Service Design
  3. Wildlife Photographer Of The Year
  4. Design Ops
  5. Design Maturity
  6. Design Sprints

I’m already excited about doing a second season …though I’m going to enjoy a little break from podcasting for a little bit.

As I say at the end of most episodes, if you’ve got any feedback to offer on the podcast, send me an email at jeremy@clearleft.com

And if you’ve enjoyed the Clearleft podcast—or a particular episode—please share it far and wide.