Tags: ratio

369

sparkline

Tuesday, August 10th, 2021

Care at Scale | Comment Magazine

A superb piece of writing by Debbie Chachra on infrastructure, fairness, and the future.

Alone in my apartment, when I reach out my hand to flip a switch or turn on a tap, I am a continent-spanning colossus, tapping into vast systems that span thousands of miles to bring energy, atoms, and information to my household. But I’m only the slenderest tranche of these collective systems, constituting the whole with all the other members of our federated infrastructural cyborg bodies.

Monday, August 9th, 2021

Turning 30 · Matthias Ott – User Experience Designer

I have no idea what the web will look like in another 30 years. But I am sure that we will look back at the first 30 years of the Web like we look back at the silent era in cinema today: as the formative years of a medium that was about to evolve to even higher heights.

The Web has always been about what each and every one of us contributes. And contributing is easier and more important than ever. So let’s not leave the future of the Web to big tech alone. Inclusiveness, accessibility, performance, security, usability, decentralization, openness – in almost all areas, the Web is far from done.

Thursday, August 5th, 2021

Updating Safari

Safari has been subjected to a lot of ire recently. Most of that ire has been aimed at the proposed changes to the navigation bar in Safari on iOS—moving it from a fixed top position to a floaty bottom position right over the content you’re trying to interact with.

Courage.

It remains to be seen whether this change will actually ship. That’s why it’s in beta—to gather all the web’s hot takes first.

But while this very visible change is dominating the discussion, invisible changes can be even more important. Or in the case of Safari, the lack of changes.

Compared to other browsers, Safari lags far behind when it comes to shipping features. I’m not necessarily talking about cutting-edge features either. These are often standards that have been out for years. This creates a gap—albeit an invisible one—between Safari and other browsers.

Jorge Arango has noticed this gap:

I use Safari as my primary browser on all my devices. I like how Safari integrates with the rest of the OS, its speed, and privacy features. But, alas, I increasingly have issues rendering websites and applications on Safari.

That’s the perspective of an end-user. Developers who have to deal with the gap in features are more, um, strident in their opinions. Perry Sun wrote For developers, Apple’s Safari is crap and outdated:

Don’t get me wrong, Safari is very good web browser, delivering fast performance and solid privacy features.

But at the same time, the lack of support for key web technologies and APIs has been both perplexing and annoying at the same time.

Alas, that post also indulges in speculation about Apple’s motives which always feels a bit too much like a conspiracy theory to me. Baldur Bjarnason has more to say on that topic in his post Kremlinology and the motivational fallacy when blogging about Apple. He also points to a good example of critiquing Safari without speculating about motives: Dave’s post One-offs and low-expectations with Safari, which documents all the annoying paper cuts inflicted by Safari’s “quirks.”

Another deep dive that avoids speculating about motives comes from Tim Perry: Safari isn’t protecting the web, it’s killing it. I don’t agree with everything in it. I think that Apple—and Mozilla’s—objections to some device APIs are informed by a real concern about privacy and security. But I agree with his point that it’s not enough to just object; you’ve got to offer an alternative vision too.

That same post has a litany of uncontroversial features that shipped in Safari looong after they shipped in other browsers:

Again: these are not contentious features shipping by only Chrome, they’re features with wide support and no clear objections, but Safari is still not shipping them until years later. They’re also not shiny irrelevant features that “bloat the web” in any sense: each example I’ve included above primarily improving core webpage UX and performance. Safari is slowing that down progress here.

But perhaps most damning of all is how Safari deals with bugs.

A recent release of Safari shipped with a really bad Local Storage bug. The bug was fixed within a day. Yay! But the fix won’t ship until …who knows?

This is because browser updates are tied to operating system updates. Yes, this is just like the 90s when Microsoft claimed that Internet Explorer was intrinsically linked to Windows (a tactic that didn’t work out too well for them in the subsequent court case).

I don’t get it. I’m pretty sure that other Apple products ship updates and fixes independentally of OS releases. I’m sure I’ve received software updates for Keynote, Garage Band, and other pieces of software made by Apple.

And yet, of all the applications that need a speedy update cycle—a user agent for the World Wide Web—Apple’s version is needlessly delayed by the release cycle of the entire operating system.

I don’t want to speculate on why this might be. I don’t know the technical details. But I suspect that the root cause might not be technical in nature. Apple have always tied their browser updates to OS releases. If Google’s cardinal sin is avoiding anything “Not Invented Here”, Apple’s downfall is “We’ve always done it this way.”

Evergreen browsers update in the background, usually at regular intervals. Firefox is an evergreen browser. Chrome is an evergreen browser. Edge is an evergreen browser.

Safari is not an evergreen browser.

That’s frustrating when it comes to new features. It’s unforgivable when it comes to bugs.

At least on Apple’s desktop computers, users have the choice to switch to a different browser. But on Apple’s mobile devices, users have no choice but to use Safari’s rendering engine, bugs and all.

As I wrote when I had to deal with one of Safari’s bugs:

I wish that Apple would allow other rendering engines to be installed on iOS devices. But if that’s a hell-freezing-over prospect, I wish that Safari updates weren’t tied to operating system updates.

Wednesday, July 28th, 2021

Rationality Is Not A Way Out Of Group Action Problems like Climate Change and Covid – Ian Welsh

Rationality does not work for ethical decisions. It can help you determine means, “what’s the best way to do this” but it can’t determine ends.

It isn’t even that great for means.

Friday, July 9th, 2021

Goomics

These comics by a former Googler give a cumulative insight into the decaying culture there.

Friday, June 25th, 2021

Organize your CSS declarations alphabetically – Eric Bailey

Until there is movement on developers taking CSS more seriously and understanding its full capabilities, we are caught in an awkward loop where introducing too much complexity in your project’s CSS will do more harm than good.

Wednesday, June 9th, 2021

Introducing Astro: Ship Less JavaScript

In Astro, you compose your website using UI components from your favorite JavaScript web framework (React, Svelte, Vue, etc). Astro renders your entire site to static HTML during the build. The result is a fully static website with all JavaScript removed from the final page.

YES!

When a component needs some JavaScript, Astro only loads that one component (and any dependencies). The rest of your site continues to exist as static, lightweight HTML.

That’s the way to do it! Make the default what’s best for users (unlike most JavaScript frameworks that prioritise developer convenience at the expense of the end user experience).

This is a tagline I can get behind:

Ship Less JavaScript

Monday, May 17th, 2021

Faster Integration with Web Components - Cloud Four

It’s good to hear stories like this—makes me feel like the slow-burn of the theoretical benefits of web components is starting to spark and flame up.

Monday, May 10th, 2021

More talk

The Clearleft podcast is currently between seasons, but that’s not going to stop me from yapping on in audio files at any opportunity.

By the way, if you missed any of season two of the Clearleft podcast, be sure to check it out—there’s some good stuff in there.

I’ve been continuing my audio narration of Jay Hoffman’s excellent Web History series over on CSS tricks. We’re eight chapters in already! That’s a good few hours of audio—each chapter is over half an hour long.

The latest chapter was a joy to narrate. It’s all about the history of CSS so I remember many of the events that are mentioned, like when Tantek saved the web by implenting doctype switching (seriously, I honestly believe that if that hadn’t happened, CSS wouldn’t have “won”). Eric is in there. And Molly. And Elika. And Chris. And Dave.

Here’s the audio file if you want to have a listen. Or you can subscribe to the RSS feed in your podcast-playing app of choice.

If you’re not completely sick of hearing my voice, you can also listen to the latest episode of the Object Oriented UX podcast with Sophia V. Prater. Our chat starts about eleven minutes into the episode and goes on for a good hour.

It was nice to be on the other side of the microphone, so to speak. The topic was Resilient Web Design but the conversation went in all sorts of directions.

I do enjoy a good natter. If you’ve got a podcast and you fancy having a chat, let me know.

Wednesday, April 28th, 2021

Earth Restored — Toby Ord

Beautifully restored high-resolution photographs of the Earth taken by Apollo astronauts.

Thursday, April 22nd, 2021

Midweight Design Engineer | Clearleft

Want to work with me? If so, come and be a design engineer at Clearleft!

What’s a design engineer? A front-end developer at the front of the front end who values accessibility, performance, and progressive enhancement.

We’re looking for a design-friendly front-end developer with demonstrable skills in pattern-based prototyping and production to join our friendly and supportive team in the heart of Brighton.

Even if this isn’t for you, please spread the word …especially to potential candidates who aren’t mediocre middle-aged white dudes (I’ve already got that demographic covered).

Sunday, March 28th, 2021

Content Design Basics by Giles Turnbull - YouTube

This is a great series of short videos all about content design. The one on writing for humans is particularly good.

Tuesday, March 16th, 2021

Done

Remember how I said I was preparing an online conference talk? Well, I’m happy to say that not only is the talk prepared, but I’ve managed to successfully record it too.

If you want to see the finished results, come along to An Event Apart Spring Summit on April 19th. To sweeten the deal, I’ve got a discount code you can use when you buy any multi-day pass: AEAJEREMY.

Recording the talk took longer than I thought it would. I think it was because I said this:

It feels a bit different to prepare a talk for pre-recording rather than live delivery on stage. In fact, it feels less like preparing a conference talk and more like making a documentary.

Once I got that idea in my head, I think I became a lot fussier about the quality of the recording. “Would David Attenborough allow his documentaries to have the sound of a keyboard audibly being pressed? No! Start again!”

I’m pleased with the final results. And I’m really looking forward to the post-presentation discussion with questions from the audience. The talk gets provocative—and maye a bit ranty—towards the end so it’ll be interesting to see how people react to that.

It feels good to have the presentation finished, but it also feels …weird. It’s like the feeling that conference organisers get once the conference is over. You spend all this time working towards something and then, one day, it’s in the past instead of looming in the future. It can make you feel kind of empty and listless. Maybe it’s the same for big product launches.

The two big projects I’ve been working on for the past few months were this talk and season two of the Clearleft podcast. The talk is in the can and so is the final episode of the podcast season, which drops tomorrow.

On the one hand, it’s nice to have my decks cleared. Nothing work-related to keep me up at night. But I also recognise the growing feeling of doubt and moodiness, just like the post-conference blues.

The obvious solution is to start another big project, something on the scale of making a brand new talk, or organising a conference, or recording another podcast season, or even writing a book.

The other option is to take a break for a while. Seeing as the UK government has extended its furlough scheme, maybe I should take full advantage of it. I went on furlough for a while last year and found it to be a nice change of pace.

Monday, March 8th, 2021

Preparing an online conference talk

I’m terrible at taking my own advice.

Hana wrote a terrific article called You’re on mute: the art of presenting in a Zoom era. In it, she has very kind things to say about my process for preparing conference talks.

As it happens, I’m preparing a conference talk right now for delivery online. Am I taking my advice about how to put a talk together? I am on me arse.

Perhaps the most important part of the process I shared with Hana is that you don’t get too polished too soon. Instead you get everything out of your head as quickly as possible (probably onto disposable bits of paper) and only start refining once you’re happy with the rough structure you’ve figured out by shuffling those bits around.

But the way I’ve been preparing this talk has been more like watching a progress bar. I started at the start and even went straight into slides as the medium for putting the talk together.

It was all going relatively well until I hit a wall somewhere between the 50% and 75% mark. I was blocked and I didn’t have any rough sketches to fall back on. Everything was a jumbled mess in my brain.

It all came to a head at the start of last week when that jumbled mess in my brain resulted in a very restless night spent tossing and turning while I imagined how I might complete the talk.

This is a terrible way of working and I don’t recommend it to anyone.

The problem was I couldn’t even return to the proverbial drawing board because I hadn’t given myself a drawing board to return to (other than this crazy wall of connections on Kinopio).

My sleepless night was a wake-up call (huh?). The next day I forced myself to knuckle down and pump out anything even if it was shit—I could refine it later. Well, it turns out that just pumping out any old shit was exactly what I needed to do. The act of moving those fingers up and down on the keyboard resulted in something that wasn’t completely terrible. In fact, it turned out pretty darn good.

Past me said:

The idea here is to get everything out of my head.

I should’ve listened to that guy.

At this point, I think I’ve got the talk done. The progress bar has reached 100%. I even think that it’s pretty good. A giveaway for whether a talk is any good is when I find myself thinking “Yes, this has good points well made!” and then five minutes later I’m thinking “Wait, is this complete rubbish that’s totally obvious and doesn’t make much sense?” (see, for example, every talk I’ve ever prepared ever).

Now I just to have to record it. The way that An Event Apart are running their online editions is that the talks are pre-recorded but followed with live Q&A. That’s how the Clearleft events team have been running the conference part of the Leading Design Festival too. Last week there were three days of this format and it worked out really, really well. This week there’ll be masterclasses which are delivered in a more synchronous way.

It feels a bit different to prepare a talk for pre-recording rather than live delivery on stage. In fact, it feels less like preparing a conference talk and more like making a documentary. I guess this is what life is like for YouTubers.

I think the last time I was in a cinema before The Situation was at the wonderful Duke of York’s cinema here in Brighton for an afternoon showing of The Proposition followed by a nice informal chat with the screenwriter, one Nick Cave, local to this parish. It was really enjoyable, and that’s kind of what Leading Design Festival felt like last week.

I wonder if maybe we’ve been thinking about online events with the wrong metaphor. Perhaps they’re not like conferences that have moved online. Maybe they’re more like film festivals where everyone has the shared experience of watching a new film for the first time together, followed by questions to the makers about what they’ve just seen.

Saturday, March 6th, 2021

Why Generation X will save the web - Hi, I’m Heather Burns

Today’s young tech policy professionals are are, quite rightfully, responding to the only internet in the only world they have ever known. The awful one. The one where the internet was and is a handful of billion-pound companies. The one where the internet has only ever been petrol on a fire. The one where the internet has been essential infrastructure like water and heat, not a thing you had to request and master. The closed internet made for them. Not the open internet I got to make.

So if you think that the biggest threat to encryption is elderly politicians who still need their secretaries to print out emails for them, it’s time you found yourself in a meeting with someone under the age of 30 who is going to war against encryption because he has never needed encryption in his life.

Tuesday, February 23rd, 2021

239: New CSS Tricks and Design Engineers | CSS-Tricks

We need engineers, we need designers, and we absolutely need design engineers to make that connection across the great divide between the front-of-the-front-end and the back-of-the-front-end. It’s only then that we can make truly great things together.

Friday, February 19th, 2021

Design Engineering - Snook.ca

Here’s a seven-year old post by Snook—this design engineer thing is not new.

Design engineer

It’s been just over two years since Chris wrote his magnum opus about The Great Divide. It really resonated with me, and a lot of other people.

The crux of it is that the phrase “front-end development” has become so broad and applies to so many things, that it has effectively lost its usefulness:

Two front-end developers are sitting at a bar. They have nothing to talk about.

Brad nailed the differences in responsibilities when he described them as front-of-the-front-end and back-of-the-front-end web development:

A front-of-the-front-end developer is a web developer who specializes in writing HTML, CSS, and presentational JavaScript code.

A back-of-the-front-end developer is a web developer who specializes in writing JavaScript code necessary to make a web application function properly.

In my experience, the term “full stack developer” is often self-applied by back-of-the-front-end developers who perhaps underestimate the complexity of front-of-the-front development.

Me, I’m very much a front-of-the-front developer. And the dev work we do at Clearleft very much falls into that realm.

This division of roles and responsibilities reminds me of a decision we made in the founding days of Clearleft. Would we attempt to be a full-service agency, delivering everything from design to launch? Or would we specialise? We decided to specialise, doubling down on UX design, which was at the time an under-served area. But we still decided to do front-end development. We felt that working with the materials of the web would allow us to deliver better UX.

We made a conscious decision not to do back-end development. Partly it was a question of scale. If you were a back-end shop, you probably had to double down on one stack: PHP or Ruby or Python. We didn’t want to have to turn away any clients based on their tech stack. Of course this meant that we had to partner with other agencies that specialised in those stacks, and that’s what we did—we had trusted partners for Drupal development, Rails development, Wordpress development, and so on.

The world of front-end development didn’t have that kind of fragmentation. The only real split at the time was between Flash agencies and web standards (HTML, CSS, and JavaScript).

Overall, our decision to avoid back-end development stood us in good stead. There were plenty of challenges though. We had to learn how to avoid “throwing stuff over the wall” at whoever would be doing the final back-end implementation. I think that’s why we latched on to design systems so early. It was clearly a better deliverable for the people building the final site—much better than mock-ups or pages.

Avoiding back-end development meant we also avoided long-term lock-in with maintainence, security, hosting, and so on. It might sound strange for an agency to actively avoid long-term revenue streams, but at Clearleft it’s always been our philosophy to make ourselves redundant. We want to give our clients everything they need—both in terms of deliverables and knowledge—so that they aren’t dependent on us.

That all worked great as long as there was a clear distinction between front-end development and back-end development. Front-end development was anything that happened in a browser. Back-end development was anything that happened on the server.

But as the waters muddied and complex business logic migrated from the server to the client, our offering became harder to clarify. We’d tell clients that we did front-end development (meaning we’d supply them with components formed of HTML, CSS, and JavaScript) and they might expect us to write application logic in React.

That’s why Brad’s framing resonated with me. Clearleft does front-of-front-end development, but we liaise with our clients’ back-of-the-front-end developers. In fact, that bridging work—between design and implementation—is where devs at Clearleft shine.

As much as I can relate to the term front-of-front-end, it doesn’t exactly roll off the tongue. I don’t expect it to be anyone’s job title anytime soon.

That’s why I was so excited by the term “design engineer,” which I think I first heard from Natalya Shelburne. There’s even a book about it and the job description sounds very much like the front-of-the-front-end work but with a heavy emphasis on the collaboration and translation between design and implementation. As Trys puts it:

What I love about the name “Design Engineer”, is that it’s entirely focused on the handshake between those two other roles.

There’s no mention of UI, CSS, front-end, design systems, documentation, prototyping, tooling or any ‘hard’ skills that could be used in the role itself.

Trys has been doing some soul-searching and has come to the conclusion “I think I might be a design engineer…”. He has also written on the Clearleft blog about how well the term describes design and development at Clearleft.

Personally, I’m not a fan of using the term “engineer” to refer to anyone who isn’t actually a qualified engineer—I explain why in my talk Building—but I accept that that particular ship has sailed. And the term “design developer” just sounds odd. So I’m all in using the term “design engineer”.

I can imagine this phrase being used in a job ad. It could also be attached to levels: a junior design engineer, a mid-level design engineer, a senior design engineer; each level having different mixes of code and collaboration (maybe a head of design enginering never writes any code).

Trys has written a whole series of posts on the nitty-gritty work involved in design engineering. I highly recommend reading all of them:

Wednesday, February 17th, 2021

You’re on mute: the art of presenting in a Zoom era. | by Hana Stevenson | Feb, 2021 | Medium

Hana recounts the preparation she did for an online presentation, including some advice from me. I’m right in the middle of preparing my own online presentation right now, and I should really heed that advice. But I fear what I told Hana was “do as I say, not as I do.”

Sunday, January 31st, 2021

Data Visualization and the Modern Imagination - Spotlight at Stanford

There are some beautiful illustrations in this online exhibition of data visualisation in the past few hundred years.