Tags: ratio

334

sparkline

Wednesday, July 1st, 2020

The design systems between us. — Ethan Marcotte

Smart thoughts from Ethan on how design systems can cement your existing ways of working, but can’t magically change how collaboration works at your organisation.

Modern digital teams rarely discuss decisions in terms of the collaborative costs they incur. It’s tempting—and natural!—to see design- or engineering-related decisions in isolation: that selecting Vue as a front-end framework only impacts the engineering team, or that migrating to Figma only impacts designers. But each of these changes the way that team works, which impacts how other teams will work and collaborate with them.

Friday, June 19th, 2020

Monday, June 15th, 2020

Tuesday, May 26th, 2020

as days pass by — Browsers are not rendering engines

You see, diversity of rendering engines isn’t actually in itself the point. What’s really important is diversity of influence: who has the ability to make decisions which shape the web in particular ways, and do they make those decisions for good reasons or not so good?

Stuart responds to a post from Brian that was riffing off a post of mine from a while back. I like this kind of social network.

Saturday, May 23rd, 2020

Integration

Back when I started staying at home under lockdown, Robin Sloan wrote a blog post called An integration loop. In it, he tells the story of The Disintegration Loops by William Basinski:

Monitoring a radio station in New York City, the composer William Basinski hears the melody, records it. He intends to use a fragment as a loop in an avant-garde music project. The tape goes into a box. It is the 1980s.

It is decades later: the summer of 2001. Digitizing a room full of forgotten material, Basinski finds this loop again. But the tape is old; as it moves through the player, it starts to come apart, the magnetic medium peeling off its plastic backing, more and more with each repetition. Enthralled, Basinski keeps recording as the melody disintegrates before his eyes, his ears.

Standing on his rooftop in Brooklyn, Basinski watches the World Trade Center collapse. It is September 11, 2001. Suddenly, the summer’s recordings have a meaning, a purpose. He titles them The Disintegration Loops and offers them as an elegy for the dead.

I hadn’t heard this before. Listening to it, I found it incredibly moving, haunting, and strangely cathartic.

Robin included a clip in his blog post of an ensemble of computer-generated sequences made from Basinki’s source material. He called it an integration loop, pt. 1.

He also published the sheet music for the looping musical phrase:

Sheet Music3

Anyone reading the blog post was encouraged to record that phrase on any instrument (or voice) and send it to Robin. I recorded the phrase on mandolin. Jessica recorded it on a muted fiddle.

Robin then assembled all the submissions into a seven minute piece called an integration loop, pt. 2. You can hear Jessica at 3:33. I’m at 4:33.

All the submissions and the final piece are released under a public domain license.

I very much relate to Robin’s interpration of this creation:

In my imagination, each contribution is a rung in a ladder out of the pit of confusion and loss, all of us both (a) carrying the melody forward and (b) being carried by it, up towards something new, something whole.

Tuesday, May 19th, 2020

Five Key Milestones in the Life of a Design System - daverupert.com

Five moments in the lifecycle of a design system. They grow up so fast!

  1. Formation of the Design System Team
  2. First Page Shipped
  3. Consumable Outside the Main Product
  4. First Non-System Team Consumer
  5. First Breaking Change

Dave makes the observation that design systems are less like open source software and more like enterprise software—software you didn’t choose to use:

Often, in my experience, for an internal Design System to have widespread adoption it requires a literal executive mandate from the top floor of the building.

Also: apparently design systems have achieved personhood now and we’re capitalising them as proper names. First name Design, last name System.

“Please, call me Design. Mr. System was my father.”

Wednesday, May 13th, 2020

Why does writing matter in remote work? — Tim Casasola

Some good writing advice in here:

  • Spell out your acronyms.
  • Use active voice, not passive voice.
  • Fewer commas. More periods.

Tuesday, May 12th, 2020

Robin Rendle ・ Notes about product design

Some good thought morsels from Robin on product design:

Bad product design is when folks talk more about the UI than what the UI is built on top of.

There’s a lot of talk about how great design is invisible—mostly boring conversations with little substance—but! I think that’s true when it comes to product design.

Bad product design is when your interface looks like your org chart.

Friday, May 8th, 2020

Employee-surveillance software is not welcome to integrate with Basecamp - Signal v. Noise

Look, employers are always free to – and should! – evaluate the work product produced by employees. But they don’t have to surveil someone’s every move or screenshot their computer every five minutes to do so. That’s monitoring the inputs. Monitor the outputs instead, and you’ll have a much healthier, saner relationship.

If you hire smart, capable people and trust them to do good work – surprise-surprise – people will return the sentiment deliver just that! The irony of setting up these invasive surveillance regimes is that they end up causing the motivation to goof off to beat the very systems that were setup to catch such behavior.

Thursday, April 30th, 2020

Dams Public Website

I had the great pleasure of visiting the Museum Plantin-Moretus in Antwerp last October. Their vast collection of woodblocks are available to dowload in high resolution (and they’re in the public domain).

14,000 examples of true craftmanship, drawings masterly cut in wood. We are supplying this impressive collection of woodcuts in high resolution. Feel free to browse as long as you like, get inspired and use your creativity.

Monday, April 20th, 2020

Overlay gap

I think a lot about Danielle’s talk at Patterns Day last year.

Around about the six minute mark she starts talking about gaps and overlaps.

Gaps are where hidden complexity live. If we don’t have a category to cover it, in effect it becomes invisible. But that doesn’t mean it’s not there. Unidentified gaps cause inconsistency and confusion.

Overlaps occur when two separate categories encompass some of the same areas of responsibility. They cause conflict, duplication of effort, and unnecessary friction.

This is the bit I keep thinking about. It’s such an insightful lens to view things through. On just about any project, tensions are almost due to either gaps (“I thought someone else was doing that”) or overlaps (“Oh, you’re doing that? I thought we were doing that”).

When I was talking to Gerry on his new podcast recently, we were trying to figure out why web performance is in such a woeful state. I mused that there may be a gap. Perhaps designers think it’s a technical problem and developers think it’s a design problem. I guess you could try to bridge this gap by having someone whose job is to focus entirely on performance. But I suspect the better—but harder—solution is to create a shared culture of performance, of the kind Lara wrote about in her book:

Performance is truly everyone’s responsibility. Anyone who affects the user experience of a site has a relationship to how it performs. While it’s possible for you to single-handedly build and maintain an incredibly fast experience, you’d be constantly fighting an uphill battle when other contributors touch the site and make changes, or as the Web continues to evolve.

I suspect there’s a similar ownership gap at play when it comes to the ubiquitous obtrusive overlays that are plastered on so many websites these days.

Kirill Grouchnikov recently published a gallery of screenshots showcasing the beauty of modern mobile websites:

There are two things common between the websites in these screenshots that I took yesterday.

  1. They are beautifully designed, with great typography, clear branding, all optimized for readability.
  2. I had to install Firefox, Adblock Plus and uBlock Origin, as well as manually select and remove additional elements such as subscription overlays.

The web can be beautiful. Except it’s not right now.

How is this dissonance possible? How can designers and developers who clearly care about the user experience be responsible for unleashing such user-hostile interfaces?

PM/Legal/Marketing made me do it

I get that. But surely the solution can’t be to shrug our shoulders, pass the buck, and say “not my job.” Somebody designed each one of those obtrusive overlays. Somebody coded up each one and pushed them into production.

It’s clear that this is a problem of communication and understanding, rather than a technical problem. As always. We like to talk about how hard and complex our technical work is, but frankly, it’s a lot easier to get a computer to do what you want than to convince a human. Not least because you also need to understand what that other human wants. As Danielle says:

Recognising the gaps and overlaps is only half the battle. If we apply tools to a people problem, we will only end up moving the problem somewhere else.

Some issues can be solved with better tools or better processes. In most of our workplaces, we tend to reach for tools and processes by default, because they feel easier to implement. But as often as not, it’s not a technology problem. It’s a people problem. And the solution actually involves communication skills, or effective dialogue.

So let’s say it is someone in the marketing department who is pushing to have an obtrusive newsletter sign-up form get shoved in the user’s face. Talk to them. Figure out what their goals are—what outcome are they hoping to get to. If they don’t seem to understand the user-experience implications, talk to them about that. But it needs to be a two-way conversation. You need to understand what they need before you start telling them what you want.

I realise that makes it sound patronisingly simple, and I know that in actuality it’s a sisyphean task. It may be that genuine understanding between people is the wickedest of design problems. But even if this problem seems insurmoutable, at least you’d be tackling the right problem.

Because the web can’t survive like this.

How I’m teaching the kids coding for the web

I love how Remy explains front-end development to his kids:

The bones are the HTML. Each bone has a name, we call them tags (or elements).

…the skin and the paint on the skin, this is CSS.

Finally, the brain and behaviour, the way the website can be interacted with is using the third layer: JavaScript.

Thursday, April 16th, 2020

Didn’t I Write This Story Already? When Your Fictional Pandemic Becomes Reality | Tor.com

Naomi Kritzer published a short story five years ago called So Much Cooking about a food blogger in lockdown during a pandemic. Prescient.

I left a lot of the details about the disease vague in the story, because what I wanted to talk about was not the science but the individuals struggling to get by as this crisis raged around them. There’s a common assumption that if the shit ever truly hit the fan, people would turn on one another like sharks turning on a wounded shark. In fact, the opposite usually happens: humans in disasters form tight community bonds, help their neighbors, offer what they can to the community.

Monday, April 6th, 2020

Performance, security, and ethics: influencing effectively

I wrote something recently about telling the story of performance. Sue Loh emphasis the importance of understanding what makes people tick:

Performance engineers need to be an interesting mix of data-lovers and people-whisperers.

Local-first software: You own your data, in spite of the cloud

The cloud gives us collaboration, but old-fashioned apps give us ownership. Can’t we have the best of both worlds?

We would like both the convenient cross-device access and real-time collaboration provided by cloud apps, and also the personal ownership of your own data embodied by “old-fashioned” software.

This is a very in-depth look at the mindset and the challenges involved in building truly local-first software—something that Tantek has also been thinking about.

Thursday, April 2nd, 2020

Visual Design Inspiration from Agency Websites–And Other Tangential Observations | Jim Nielsen’s Weblog

Tyring to do make screenshots of agency websites is tricky if the website is empty HTML with everything injected via JavaScript.

Granted, agencies are usually the ones pushing the boundaries. “Pop” and “pizazz” are what sell for many of them (i.e. “look what we can do!”) Many of these sites pushed the boundaries of what you can do in the browser, and that’s cool. I like seeing that kind of stuff.

But if you asked me what agency websites inspired both parts me, I’d point to something like Clearleft or Paravel. To me, they strike a great balance of visual design with the craft of building for an accessible, universal web.

CSS Architecture for Modern JavaScript Applications - MadeByMike

Mike sees the church of JS-first ignoring the lessons to be learned from the years of experience accumulated by CSS practitioners.

As the responsibilities of front-end developers have become more broad, some might consider the conventions outlined here to be not worth following. I’ve seen teams spend weeks planning the right combination of framework, build tools, workflows and patterns only to give zero consideration to the way they architect UI components. It’s often considered the last step in the process and not worthy of the same level of consideration.

It’s important! I’ve seen well-planned project fail or go well over budget because the UI architecture was poorly planned and became un-maintainable as the project grew.

Wednesday, April 1st, 2020

How to build a bad design system | CSS-Tricks

Working in a big organization is shocking to newcomers because of this, as suddenly everyone has to be consulted to make the smallest decision. And the more people you have to consult to get something done, the more bureaucracy exists within that company. In short: design systems cannot be effective in bureaucratic organizations. Trust me, I’ve tried.

Who hurt you, Robin?

Sunday, March 15th, 2020

Twitter thread as blog post: Thoughts on how we write CSS | Lara Schenck

CSS only truly exists in a browser. As soon as we start writing CSS outside of the browser, we rely on guesses and memorization and an intimate understanding of the rules. A text editor will never be able to provide as much information as a browser can.

Wednesday, March 11th, 2020

Why is CSS frustrating? ・ Robin Rendle

CSS is frustrating because you have to actually think of a website like a website and not an app. That mental model is what everyone finds so viscerally upsetting. And so engineers do what feels best to them; they try to make websites work like apps, like desktop software designed in the early naughts. Something that can be controlled.