Tags: change

25

sparkline

Saturday, May 26th, 2018

CSS and Markup in Javascript is an Evolutionary Dead End

The bet to make is that we’re going to see more use of specialized languages. And HTML and CSS are the grandaddy specialized languages that have enough social consensus and capital investment to be the seeds of the next generation.

Thursday, May 10th, 2018

A Book Apart, Get to Know Jeremy Keith

My publishers asked me some questions. My answers turned out to be more revealing of my inner demons than I was expecting. I hope this isn’t too much oversharing, but I found it quite cathartic.

My greatest fear for the web is that it becomes the domain of an elite priesthood of developers. I firmly believe that, as Tim Berners-Lee put it, “this is for everyone.” And I don’t just mean it’s for everyone to use—I believe it’s for everyone to make as well. That’s why I get very worried by anything that raises the barrier to entry to web design and web development.

It’s ironic that, at the same time as we can do so much more with less when it comes to the HTML, CSS, and JavaScript in browsers, many developers are choosing to make things more complicated by introducing complex tool chains, frameworks and processes.

Wednesday, May 9th, 2018

Choosing tools for scaling design

Tools and processes are intertwined. A company or a department or an individual has a way of doing things—that’s the process. They also have software to carry out the process—those are the tools.

Ideally, they should be loosely coupled. You should be able to change your tools without necessarily changing your process. So swapping out, say, one framework or library for another shouldn’t involve fundamentally changing the way you work. Likewise, trying a new way of working shouldn’t require you to use unfamiliar tools.

When it comes to scaling design within organisations, the challenges are almost always around switching processes (well, really it’s about trying to change culture, but that starts with changing processes—any sufficiently advanced process is indistinguishable from culture). All too often, though, I see people getting hung up on the tools.

We need to get more efficient in how we deliver designs …so let’s switch over to this particular design tool.

We should have a design system …so let’s get everyone using this particular JavaScript framework.

I understand this desire to shortcut the work of figuring out processes and jump straight to production solutions. For one thing, it allows you to create an easy list of requirements when it comes to recruiting talent: “Join our company—you must demonstrate experience and proficiency in this tool or that library.”

But when tools and processes become tightly coupled like this, there’s a real danger of stagnation. If a process can be defined as “the way we do things around here”, that’s not something you want to tie to any particular tool or technology. Otherwise, before you know it, you’re in the frustrating situation of using outdated tools, but you can’t swap them out for newer or better-suited technologies without disrupting everyone’s work.

This is technical debt (although it applies just as much to design). You’re paying a penalty in the present because of a decision that somebody made in the past. The problem isn’t so much with the decision itself, but with the longevity of its effects.

I think it’s important to remember what a tool is: it’s a piece of technology that enables you to work faster or better. You should enjoy using your tools, but you shouldn’t be utterly dependent on any particular one. Otherwise, the tail starts wagging the dog—you are now in service to the tool, instead of the other way around.

Treat your tools like cattle, not pets. Don’t get too attached to any one technology to the detriment of missing out on others.

Mind you, if you constantly tried every single new tool or technology out there, you’d never settle on anything—I’m pretty sure that three new JavaScript frameworks have been released since you started reading this paragraph.

The tools you choose at any particular time should be suited to what you’re trying to accomplish at that time. In other words, you’ve got to figure out what you’re trying to accomplish first (the vision), then figure out how you’re going to accomplish it (the process), and only then figure out which tools are the best fit. If you jump straight to choosing tools, you could end up trying to tighten a screw with a hammer.

Alas, I’ve seen plenty of consultants who conflate strategy with tooling. They’re brought in to solve process problems and, surprise, surprise, the solution always seems to involve purchasing the software that their company sells. I’ve been guilty of this myself: I see an organisation struggling to systemise their design patterns, and I think “Oh, they should use Fractal!” …but that’s jumping the gun. They might be better served with something simpler, or something more complex (I mean, Fractal is very, very flexible but it’s still just one option—there are plenty of other pattern library tools out there).

Once you separate out the tools from the process, there’s an added benefit. Making the right technology choice is no longer a life-or-death decision. You can suck it and see. Try out the technology and see if it works. If it’s working, great! Carry on using it. If it’s not working, that’s okay too. Try something different.

I realise I’m oversimplifying things, but I honestly believe that the real challenge is not choosing the right tools, but figuring out the right process for your team.

Tuesday, May 8th, 2018

Process and culture

Cameron has a bone to pick. Why, oh, why, he wonders, are we so quick to create processes when what we really need is a good strong culture?

Strong culture = less process

To stop people breaking stuff: make a process for it. Want to make people act responsibly: make a process for it. Tired of telling people about something? Make a process for it.

For any single scenario you can name it’ll be easier to create a process for it than build a culture that handles it automatically. But each process is a tiny cut away from the freedom that you want your team to enjoy.

I take his point, but I also think that some processes are not only inevitable, but downright positive. There should be a process for handling payroll. There should be a process for handling promotions. Leaving that to culture might sound nice and nimble, but it could also lead to unintentional bias and unfairness.

But let’s leave those kind of operational processes aside and focus on process and culture when it comes to design and engineering. Cameron’s point is well taken here. Surely you want people to just know the way things are done? Surely you want people to just get on with doing the work without putting hurdles in their way?

On the face of it, yes. If you’re trying to scale design at your organisation, then every extra bit of process is going to slow down your progress.

But what if speed isn’t the most important metric of success when it comes to scaling design? You’ve got to make sure you’re scaling the right things.

Mark writes:

This is a post in defence of process. Yes, I know what you’re thinking: ‘urgh, process is a thing put in place to make up for mediocre teams’; or ‘prioritise discussion over documentation’; or ‘I get enough red tape in other parts of my life’.

The example he gives is undeniably a process that will slow things down …deliberately.

Whenever someone asks me to do something that I think seems ill-conceived in some way, I ask them to write it down. That’s it. Because writing is high effort. Making sentences is the easy bit, it’s the thinking I want them to do. By considering their request it slows them down. Maybe 30% of the time or something, they come back and say ‘oh, that thing I asked you to do, I’ve had a think and it’s fine, we don’t need to do it’.

I’ve seen this same tactic employed in standards bodies. Somebody bursts into a group and says “I’ve got a great idea—we should make this a thing!” The response, no matter what the idea is, is to say “Document use-cases.” It’s a stumbling block, and also a bit of a test—if they do come back with use-cases, the idea can be taken seriously; the initial enthusiasm needs to be backed up with hard graft.

(On a personal level, I sometimes use a little trick when it comes to email. If someone sends me a short email that would require a long response from me, I’ll quickly fire back a clarifying question: “Quick question: did you mean X or Y?” Now the ball is back in their court. If they respond swiftly with an answer to my question, then they’ve demonstrated their commitment and I honour their initial request.)

Anyway, it sounds like Cameron is saying that process is bad, and Mark is saying process can be good. Cody Cowan from Postlight thinks they’re both right:

To put it bluntly: people, not process, are the problem.

Even so, he acknowledges Cameron’s concern:

One of the biggest fears that people have about process is that something new is going to disrupt their work, only to be replaced by yet another rule or technique.

I think we can all agree that pointlessly cumbersome processes are bad. The disagreement is about whether all processes are inherently bad, or whether some processes are not only necessary, but sometimes even beneficial.

When Cameron talks about the importance of company culture, he knows whereof he speaks. He’s been part of Canva’s journey from a handful of people to hundreds of people. They’ve managed to scale their (excellent) culture along the way. That’s quite an achievement—scaling culture is really, really challenging. Scaling design is hard. Scaling culture is even harder.

But you know what’s even more challenging than scaling culture? Changing culture.

What if your company didn’t start with a great culture to begin with? What if you’re not Canva? What if you’re not AirBnB? What are your options then?

You can’t create a time travel machine to go back to the founding of the company and ensure a good culture from the outset.

You can’t shut down your existing company and create a new company from scratch, this time with a better culture.

You’ve got to work with what you’ve got. That doesn’t mean you can’t change your company culture, but it’s not going to be easy. Culture is pretty far down the stack of pace layers—it’s slow to change. But you can influence culture by changing something that’s less slow to change. I would argue the perfect medium for this is …process.

Once you know what values you’re trying to embed into your culture, create processes that amplify and reward those values. I totally understand the worry that these processes will reduce autonomy and freedom, but I think that only applies if the company already has a strong culture of autonomy and freedom. If you’re trying to create a culture of autonomy and freedom, then—as counter-intuitive as it may seem—you can start by putting processes in place.

Then, over time, those processes can seep into the day-to-day understanding of how things are done. Process dissolves into culture. It’s a long game to play, but as Cameron points out, that’s the nature of culture change:

Where culture pays off is in the long run. It’s hard work: defining the culture, hiring for the culture and communicating the culture again, and again, and again. But if you want to make a company where people are empowered, passionate, and champions of your organisation then it’s the only path forward.

Thursday, May 3rd, 2018

Orion Magazine | State of the Species

A great piece from Charles C. Mann from five years ago, where you can see the genesis of The Wizard And The Prophet.

For hundreds of thousands of years, our species had been restricted to East Africa (and, possibly, a similar area in the south). Now, abruptly, new-model Homo sapiens were racing across the continents like so many imported fire ants. The difference between humans and fire ants is that fire ants specialize in disturbed habitats. Humans, too, specialize in disturbed habitats—but we do the disturbing.

Wednesday, March 21st, 2018

Empty half the Earth of its humans. It’s the only way to save the planet | Kim Stanley Robinson | Cities | The Guardian

Kim Stanley Robinson explores the practicalities of E.O. Wilson’s Half Earth proposal.

There is no alternative way; there is no planet B. We have only this planet, and have to fit our species into the energy flows of its biosphere. That’s our project now. That’s the meaning of life, in case you were looking for a meaning.

Sunday, February 11th, 2018

No one’s coming. It’s up to us. – Dan Hon – Medium

A terrific piece by Dan Hon on our collective responsibility. This bit, in particular, resonated with me: it’s something I’ve been thinking about a lot lately:

We are better and stronger when we are together than when we are apart. If you’re a technologist, consider this question: what are the pros and cons of unionizing? As the product of a linked network, consider the question: what is gained and who gains from preventing humans from linking up in this way?

Friday, February 2nd, 2018

Pace Layering: How Complex Systems Learn and Keep Learning

There’s a running joke at just about any gathering at Clearleft where we measure TTPL—Time To Pace Layers—a measurement of how long we can discuss anything before making an inevitable reference to Stewart Brand’s framing.

It’s one of those concepts that, once your brain has been exposed, you start seeing everywhere. Like bad kerning or sexism.

Monday, January 1st, 2018

All That Glisters ◆ 24 ways

I thought this post from Drew was a great way to wrap up another excellent crop from 24 Ways.

There are so many new tools, frameworks, techniques, styles and libraries to learn. You know what? You don’t have to use them.

Chris likes it too.

Saturday, November 11th, 2017

The Medium - daverupert.com

I have to keep reminding myself that I do have some control. I can build The Medium I want. I can cling to what’s good.

Wednesday, November 1st, 2017

Angry Optimism in a Drowned World: A Conversation with Kim Stanley Robinson | CCCB LAB

Nobody can afford to volunteer to be extra virtuous in a system where the only rule is quarterly profit and shareholder value. Where the market rules, all of us are fighting for the crumbs to get the best investment for the market. And so, this loose money can go anywhere in the planet without penalty. The market can say: “It doesn’t matter what else is going on, it doesn’t matter if the planet crashes in fifty years and everybody dies, what’s more important is that we have quarterly profit and shareholder value and immediate return on our investment, right now.” So, the market is like a blind giant driving us off a cliff into destruction.

Kim Stanley Robinson journeys to the heart of the Anthropocene.

Economics is the quantitative and systematic analysis of capitalism itself. Economics doesn’t do speculative or projective economics; perhaps it should, I mean, I would love it if it did, but it doesn’t. It’s a dangerous moment, as well as a sign of cultural insanity and incapacity. It’s like you’ve got macular degeneration and your vision of reality itself were just a big black spot precisely in the direction you are walking.

Tuesday, May 2nd, 2017

leaving the future behind – Al Robertson

Science fiction isn’t about technology, it’s about people …and how people change in response to technology.

So ironically, perhaps the only way that any piece of science fiction can be sure that it will remain resonant as the years pass is to make sure that any technical speculation can drop away once it’s no longer relevant. The science will fall back to Earth like an exhausted booster section, tumbling away from the rocket that will one day reach the stars. And then we’ll be left with stories about how people change when change arrives – and that, for me, is what science fiction is.

Tuesday, November 22nd, 2016

Subscribe to change

A very smart way of matching up the amount of money you spend on entertainment to contributions to causes you care about.

Over 40 million Americans subscribe to Netflix, which means that ~$400 million dollars are taken out of our accounts monthly. Many Americans don’t even notice this. Imagine what could happen if we set up as many automatic contributions to help nonprofits do what they need to do.

Friday, October 21st, 2016

Fermat’s Library | Why the Internet only just works annotated/explained version.

A ten-year old paper that looks at the history of the ARAPNET and internet to see how they dealt with necessary changes.

Changing a large network is very difficult. It is much easier to deploy a novel new protocol that fills a void than it is to replace an existing protocol that more or less works.

Friday, September 30th, 2016

GreenSock | “will-change” must change? Animators beware.

This will-change property that was intended to SOLVE problems for animators may end up doing the opposite.

It seems wise for the browsers to step back and let the spec authors fill in the implementation details and gain consensus before moving forward.

Sunday, June 26th, 2016

Screw Mastery

The joy of starting from scratch:

I remembered a really nice thing: how to be goofily, absurdly proud of myself for figuring something out, a kind of pride I usually reserve for my children. This is the best part of dropping back to zero. The list of things you have to master is endless. And when you get one right — even a little, tiny one — everyone notices and gives you an adult version of an extra candy in your lunchbox.

Friday, January 15th, 2016

The web is okay

It’s okay to feel stress in response to this rapid development. It’s natural. I hate change, I hate it so so much. I like things to be consistent and for it to have it’s own place. If it doesn’t, I get stressed and my obsessive compulsive tendencies run riot in a desperate attempt to preserve order. This both benefits and hinders my work.

Chimes very nicely with the latest episode of Ctrl+Click Cast.

Friday, December 11th, 2015

Where to start?

A lot of the talks at this year’s Chrome Dev Summit were about progressive web apps. This makes me happy. But I think the focus is perhaps a bit too much on the “app” part on not enough on “progressive”.

What I mean is that there’s an inevitable tendency to focus on technologies—Service Workers, HTTPS, manifest files—and not so much on the approach. That’s understandable. The technologies are concrete, demonstrable things, whereas approaches, mindsets, and processes are far more nebulous in comparison.

Still, I think that the most important facet of building a robust, resilient website is how you approach building it rather than what you build it with.

Many of the progressive app demos use server-side and client-side rendering, which is great …but that aspect tends to get glossed over:

Browsers without service worker support should always be served a fall-back experience. In our demo, we fall back to basic static server-side rendering, but this is only one of many options.

I think it’s vital to not think in terms of older browsers “falling back” but to think in terms of newer browsers getting a turbo-boost. That may sound like a nit-picky semantic subtlety, but it’s actually a radical difference in mindset.

Many of the arguments I’ve heard against progressive enhancement—like Tom’s presentation at Responsive Field Day—talk about the burdensome overhead of having to bolt on functionality for older or less-capable browsers (even Jake has done this). But the whole point of progressive enhancement is that you start with the simplest possible functionality for the greatest number of users. If anything gets bolted on, it’s the more advanced functionality for the newer or more capable browsers.

So if your conception of progressive enhancement is that it’s an added extra, I think you really need to turn that thinking around. And that’s hard. It’s hard because you need to rewire some well-engrained pathways.

There is some precedence for this though. It was really, really hard to convince people to stop using tables for layout and starting using CSS instead. That was a tall order—completely change the way you approach building on the web. But eventually we got there.

When Ethan came out with Responsive Web Design, it was an equally difficult pill to swallow, not because of the technologies involved—media queries, percentages, etc.—but because of the change in thinking that was required. But eventually we got there.

These kinds of fundamental changes are inevitably painful …at first. After years of building websites using tables for layout, creating your first CSS-based layout was demoralisingly difficult. But the second time was a bit easier. And the third time, easier still. Until eventually it just became normal.

Likewise with responsive design. After years of building fixed-width websites, trying to build in a fluid, flexible way was frustratingly hard. But the second time wasn’t quite as hard. And the third time …well, eventually it just became normal.

So if you’re used to thinking of the all-singing, all-dancing version of your site as the starting point, it’s going to be really, really hard to instead start by building the most basic, accessible version first and then work up to the all-singing, all-dancing version …at first. But eventually it will just become normal.

For now, though, it’s going to take work.

The recent redesign of Google+ is true case study in building a performant, responsive, progressive site:

With server-side rendering we make sure that the user can begin reading as soon as the HTML is loaded, and no JavaScript needs to run in order to update the contents of the page. Once the page is loaded and the user clicks on a link, we do not want to perform a full round-trip to render everything again. This is where client-side rendering becomes important — we just need to fetch the data and the templates, and render the new page on the client. This involves lots of tradeoffs; so we used a framework that makes server-side and client-side rendering easy without the downside of having to implement everything twice — on the server and on the client.

This took work. Had they chosen to rely on client-side rendering alone, they could have built something quicker. But I think it was worth laying that solid foundation. And the next time they need to build something this way, it’s going to be less work. Eventually it just becomes normal.

But it all starts with thinking of the server-side rendering as the default. Server-side rendering is not a fallback; client-side rendering is an enhancement.

That’s exactly the kind of mindset that enables Jack Franklin to build robust, resilient websites:

Now we’ll build the React application entirely on the server, before adding the client-side JavaScript right at the end.

I had a chance to chat briefly with Jack at the Edge conference in London and I congratulated him on the launch of a Go Cardless site that used exactly this technique. He told me that the decision to flip the switch and make it act as a single page app came right at the end of the project. Server-side rendering was the default; client-side rendering was added later.

The key to building modern, resilient, progressive sites doesn’t lie in browser technologies or frameworks; it lies in how we think about the task at hand; how we approach building from the ground up rather than the top down. Changing the way we fundamentally think about building for the web is inevitably going to be challenging …at first. But it will also be immensely rewarding.

Saturday, May 30th, 2015

Changing culture | susan jean robertson

Susan points out some uncomfortable truths. It’s all very well for us to try and create a culture of performance amongst designers and developers, but it will all be nought if we could change the minds of people higher up the chain …who currently just don’t care.

I think she’s spot on when she points to this possible solution:

I think what I’m asking is, who will be the game changer in this conversation? Who will be the large, bulky site that will work towards performance and make it happen and then we will all point to them and say, see they did it. It seems to me that that is what it takes. Much like we pointed to ESPN and being able to use CSS for layout or The Boston Globe and being able to do responsive at a large scale, who will we point to for the performance overhaul?

Monday, November 17th, 2014

Mobile Last?

This isn’t a scientific data sample, but Jonathan’s anecdotal evidence seems to suggest that most web designers and developers are still thinking with a desktop-first mentality. Which is crazy.