No occasion required

A couple of weeks ago. Lyndal surprised me with a little gift. It's a "now playing" stand to hold my record covers. It might seem like a small gesture, but it gives me so much pleasure every time I glance over at the stereo.

Now, I play music and I think of how lucky we are to have each other. Everyone should have someone in their life who gives gifts for no occasion rather than gifting out of a sense of obligation.

*Planetarium* – Sufjan Stevens, Bryce Dessner, Nico Muhly and James McAlister
*Tallulah* – The Go-Betweens

User experience is about real life

His final note, filled with anger toward Robinhood, says that he had “no clue” what he was doing.

Source: Forbes "20-Year-Old Robinhood Customer Dies By Suicide After Seeing A $730,000 Negative Balance"

There's a lot of talk around about having to prove the value of good user experience. The short answer is that it can save lives.

The way we convey messages to and interact with the people who choose to use the things we create: that's our responsibility. But saving lives is a goalie's curse in the job of experience design. In the goalie's curse, your job is only recognised for its value when you fail.

The story of this young man is tragic. His pain possibly could have been avoided by targeting stress cases.

Deaths like this are the result of many levels of negligence. Pledging major changes is not good enough. Immediate action is what is required: Immediate action at the cost of the company that can cause deaths.

Robinhood's response is not good enough. They are committing to… considering additional criteria and education for customers. We see language of inaction like this all the time. A tragedy caused by inaction is met with the promise to think about future action.

That is not good enough.

Take immediate action. What can you do today that will stop this happening tomorrow? Ignore the financial cost and take responsibility for your mistakes.

This is not just something that one company needs to do. Every single company that provides similar services should do the same.

Until that happens, ex post facto apologies and decisions to consider a change in action should be considered admissions of guilt of negligence.

Good designers should always be thinking about what damage can come from the things we're building. Everyone in a business who makes a decision that affects others can be considered a designer for this purpose.

It’s the perfect apostrophe, Charlie Brown

I wanted to start a new writing project, so of course, what I needed to do was:

Actually, all I needed to do was sit down with a pen and paper.

This is a classic case of Merlin Mann’s "perfect apostrophe" effect.

In fact, as I’m writing this, I’m procrastinating as "an experiment" to see about writing in Editorial and sending it to the WordPress iOS app.

My ability to delay work with important tasks is a monkeys paw (maybe I’m using that wrong – Ed.). It gives me the illusion of being productive without actually producing anything valuable.

In writing this piece alone I've created three new Editorial snippets and adjusted the settings on the iOS keyboard.

It's a slow process but I believe it's possible to be more aware of when I'm being productive and when I'm just being busy to avoid the hard thing.

When I first heard the "Perfect Apostrophe", I learnt that I wasn't the only one. The phrase became a shortcut in my lexicon.

But enough about that. I should probably get to writing.

On Indian Roads

“Whirring through Delhi’s side streets and dirt lanes, the e-rickshaws leave passengers with dust-filled lungs and shaken bones. Drivers often go against traffic, playing chicken with oncoming buses and trucks. The vehicles’ open sides, handy for hopping on and off, require that riders hang on or risk falling out.”

This article makes traffic in India sound so much more dangerous than it feels. I mean, sure, people drive on the wrong side of the road and go the wrong way down one-way streets, all into oncoming traffic, but everyone is driving according the only road rule that applies here: Don’t crash.

CSS-in-JS Sucks: a romantic rant


What is CSS-in-JS?

CSS-in-JS is the generic name for a group of really powerful developer tools that allow us to code a product’s styles in Javascript.

In the olden days, people used to inject CSS into html via Javascript, which created inline CSS on the element it was working on.

We all know inline CSS is evil. Even the people making CSS-in-JS tools know that it’s evil. That’s not what this is.

CSS-in-JS lets developers coding in React to code CSS so that it matches React’s component-based development practice. It creates its own stylesheets that are included in the DOM exactly the way we normally would for regular ol’ CSS.

You can even use it to define critical CSS styles that sit in a style tag within the DOM’s head. It’s pretty amazing.

So, why do you hate it so much, Josh?

So, did I waste your time with some ridiculous link-baity title that Esther came up with and I agreed to?

No. I didn’t. CSS-in-JS fills me with a fear for the sustainability of our web products. I think we use the speed and convenience of being able to code things quickly that we know will scale as products scale to save our customers money now even though they are going to pay more for it down the track.

html & css & js

The way the web renders is a thing of beauty. I really love it. It’s come so far and CSS is what prompted me to start learning to code websites. I understood it implicitly. When I started working with a bunch of Java developers, I could troubleshoot their CSS in seconds. When Ethan Marcotte developed responsive CSS practices, I shouted from the rooftops and changed the way I did everything. Now that the CSS grid spec is being adopted, I’m over the moon about the things we can do with it.

Built into the web, into this wonderful triumvirate of markup and script that gives us cat memes, infinite Medium articles about the same topic, and a hundred different ways to say we liked someone’s photo, is this idea that we can make changes to any one of these pieces and maintain the fidelity of the others. The backbone of the web is modular, in this way.

Nothing made this more clear to me than CSS Zen Garden. It’s a beautiful website that allows anyone to take an existing and standard piece of html and code their own CSS for it, and then share it with the world.

It revealed to me the beauty and simplicity of great web development:

1. html

Everything starts with planned html. Naming is important. Understanding inline vs block elements is important. Understanding the difference between semantic and non-semantic elements is important. These things are important because so many technologies rely on them being the way they were designed. Good html forces us to understand the content that we’re coding for.

  • Is something a button or is it a link?
  • What is the hierarchy of information we want to mansplain?
  • What kind of list is that? Oh, it has terms and then definitions for those terms? Well, it’s a definition list which is totally a thing that most people don’t know exists.

The way html was designed should force us to think about what it is we’re putting on the page. Without either of html’s other webdev buddies, a well-constructed site will still work. It might be ugly and require a lot more scrolling than we wanted, but it will still make sense and the interactions will still work.

2. html + CSS

Then we add CSS to it. For all the beauty in html’s design, it’s a giant oaf compared to the finesse CSS brings to it.

CSS is not just about making things look more visually appealing. That’s part of it. But in reality it’s a deeper dive into the meaning of what we’re creating. This is where selectors, IDs, classes, attributes, pseudo classes and combinators come in. They get us to understand and better display the meaning of what we’re producing by forcing us to make more difficult decisions.

Using CSS, we can make use of the different physical tools people use to interact with what we’ve built. We can create subtleties and nuance and add emotion to something that previously was just words and pictures.

We’re forced to think about how and why something looks and reacts the way it does. We can create emotional responses in our users.

But, in order to do this, we need to really think about what it is that we’re putting on the screen. We need to think about how the html is constructed and what responses we want to elicit from our user. One of the ways we do this is through CSS’s greatest power: the cascade.

The cascade runs through importance, specificity and source order to give us better control over how something will display, but also to give us constraints that tie very closely in with the html, so that what we’re displaying matches the original intention of the page.

This is why class names are so important. Good, semantic class names in the html give us clues about the intention of the page we’re presenting. That intention won’t be fulfilled by the big, clumsy baby that is html. It can only truly be made true by the CSS we produce for it.

As CSS Zen Garden showed us, a single, well-constructed html document can be given all sorts of nuanced meaning through the CSS we attach to it. This nuance should be able to evolve over time as we learn new things about how the users are interacting with our product. We should be able to tweak the stylesheets over time or create new stylesheets for new media that becomes important, by just writing some new CSS. We can create stylesheets specifically for printing so that we can make the digital analogue (although almost nobody does and almost all websites look terrible when printed).

This is why CSS-in-JS bothers me so much. What we gain in speed of development, we lose in sustainability and adaptability. CSS-in-JS is an abstraction from the very nature of the thing we’re producing. It takes away the burden of having to think about the screen and the devices that might interact with it. It removes the value of the cascade by hacking the specificity so that we don’t have to think about it.

By doing that, it removes us, our very selves, further away from the intention of our product. It denies us the privilege of designing the front-end experience at its very DNA.

3. html + css + js

Javascript is an immensely powerful tool. React is an amazing framework that makes coding web applications so much easier. All the different CSS-in-JS tools help us code web applications so much faster. So many articles I read in trying to articulate my argument talk about the reduction of cognitive load that comes with CSS-in-JS. But with that convenience comes a cost that we might not see straight away.

When a client goes through a rebrand, they shouldn’t have to rebuild all of their web assets. When a new technology comes along, future developers shouldn’t have to deal with inherited tech-debt just to make something work.

The web and the specs that define it, give us the perfect opportunity to combine research, design and development, to work in parallel in true agile teams, building with a true lean production ethos. CSS-in-JS strips us of that and leaves us in the old waterfall approach of designers handing over comps to developers, who then just make it work on the screen.

I think we’re better than that.


Some Reading

I need to meet Hugo

Last night I successfully deployed Netlify to create a Hugo-based website. You can see it (at time of writing) but it's just a silly default template pretending to be a coffee website.

Screencap of the test post I uploaded last night.

The problem is that Netlify does too much of the work for me, which means I'll still be relying on someone else's service to create the new site. If I'm going to take control, I need to take control properly. I'm taking Willem's advice and I'm going to roll my own.

There's going to be a big learning curve here. I'm going to need to learn about Hugo and its templating system; deal with GitHub pages; establish a workflow that can post based on Markdown files from my computer as well as from my mobile devices.

I use Editorial for text files when mobile. There are workflows available to do all of this, but it's going to take a lot of configuring.

At the same time, I have to play around with the design of the site, look at how I'm going to make the best use of CSS grid and work out how to implement it all.

Looking for a Simpler Way

I've wanted to do a few little tinkering projects recently around CSS Grid and also maybe a git-based CMS for blogging.

Writing shouldn't be a chore. I write all my notes in Markdown.I have for years. I work in text editors whenever possible and hate having to rely on services inside a browser to collaborate or create content.

WordPress has done marvelous things over the past few years. They've come a long way into the domain of true commercial CMS competitors. They achieved the goals I always knew they were capable of.

But at the same time, I feel like it now surpasses my needs. I almost never post anymore. I'm more time poor than I used to be and WordPress became an unfamiliar landscape based around SEO and social media and competing with platforms like Squarespace.

I just want to type and post. I want to dabble and play. I want to test out concepts and designs in a much simpler way.

So, I'm going to experiement, starting with Netflify. The theory is that I should just be able to write a blog post in a text file in my text editorand push it to my git repository.

So I'm going to try to minimise the friction between writing and publishing. I used to find it easy and enjoyable. I wonder if I'll get to do that again.

At the moment I'm still waiting for the DNS to propogate, so there's nothing there. This, I'm sure, will be small steps taken over a long time. But I've needed a project around this part of my life for some time.

Post Script: Also, WP doesn't seem to be playing nicely with my Firefox settings at the moment, so that's just another barrier. Sigh.