A handy in-browser image compression tool. Drag, drop, tweak, and export.
Rachel does some research to find out why people use CSS frameworks like Bootstrap—it can’t just be about grids, right?
In our race to get our site built quickly, our desire to make things as good as possible for ourselves as the designers and developers of the site, do we forget who we are doing this for? Do the decisions made by the framework developer match up with the needs of the users of the site you are building?
Not for the first time, I’m reminded of Rachel’s excellent post from a few years ago: Stop solving problems you don’t yet have.
Harry divides his web performance work into three categories:
I feel like a lot of businesses are still unsure where to even start when it comes to performance monitoring, and as such, they never do. By demystifying it and breaking it down into three clear categories, each with their own distinct time, place, and purpose, it immediately takes a lot of the effort away from them: rather than worrying what their strategy should be, they now simply need to ask ‘Do we have one?’
How mucking about in HTML and CSS can lead to some happy accidents.
‘Sfunny, people often mention the constraints and limitations of “designing in the browser”, but don’t recognise that every tool—including Sketch and Photoshop—comes with constraints and limitations. It’s just that those are constraints and limitations that we’ve internalised; we no longer even realise they’re there.
“What if someone doesn’t browse the web like I do?”
I share many of Cole’s concerns. I think we’re in fairly similiar situations. We even share the same job title: Technical Director …whatever that even means.
I worry about our over-reliance and obsession with tools because for many these are a barrier to our discipline. I worry that they may never really make our work better, faster or easier and that our attention is increasingly focussed not on the drawing but on the pencils. But I mostly worry that our current preoccupation with the way we work (rather than necessarily what we work on) is sapping my enthusiasm for an industry I love and care about immensely.
The beauty of this approach is that the site doesn’t ever appear broken and the user won’t even be aware that they are getting the ‘default’ experience. With progressive enhancement, every user has their own experience of the site, rather than an experience that the designers and developers demand of them.
A case study in applying progressive enhancement to all aspects of a site.
This is an interesting tool: mess around with styles on any site inside Chrome’s dev tools, and then hit a button to have the updated styles saved to a URL (a Gist on Github).
Another great video from Jen as part of her Layout Land series. This time she addresses the question of the overwhelming technology landscape for developers and where they should invest their time.
A very thoughtful post from Stuart, ostensibly about “view source”, but really about empowerment, choice, and respect.
I like that the web is made up of separate bits that you can see if you want to. You can understand how it works by piecing together the parts. It’s not meant to be a sealed unit, an appliance which does what the owner wants it to and restricts everything else. That’s what apps do. The web’s better than that.
There are of course things worth your time and deep consideration, and there are distractions. Profound new thinking and movements within our industry - the kind that fundamentally shifts the way we work in a positive new direction are worth your time and attention. Other things are distractions. I put new industry gossip, frameworks, software and tools firmly in the distractions category. This is the sort of content that exists in the padding between big movements. It’s the kind of stuff that doesn’t break new ground and it doesn’t make or break your ability to do your job.
It’s possible to create components in a vacuum, but ultimately you have no idea whether or not those components can successfully address your user and business needs. I’ve witnessed firsthand several design system initiatives crash and burn due to components created in isolation.
I’ve thought often of how our design and prototyping tools for the web are often not of the web. Tools like Photoshop and Sketch and Invision create approximations but need to walk the line between being a tool to build native apps and to build web apps. They do well in their ability to quickly validate designs but do little to validate technical approach.
The ideas and images that come to mind when you think of technology as an instrument are more useful than if you think of it as a tool. Instruments — I’m specifically talking about musical instruments — are a way to create culture.
You approach instruments with a set of expectations and associations that are more humane. It’s built into their very purpose. Instruments are meant to make something for other people, not making things. When you use an instrument, you have an expectation that it is going to take effort to use it well. Using an instrument takes practice. You form a relationship with that object. It becomes part of your identity that you make something with it. You tune it. You understand that there’s no such thing as a “best” guitar in the same way that there’s not necessarily a “best” phone.
This really, really resonates with me:
I think the thing I struggle the most with right now is determining when something new is going to change the way our industry works for the better (like responsive web design did 5 or 6 years ago), and when it’s just a fad that will fade away in a year or three (which is how I feel about our obsession with things like Angular and React).
I try to avoid jumping from fad to fad, but I also don’t want to be that old guy who misses out on something that’s an important leap forward for us. I spend a lot of time thinking about the longer term impact of the things we make (and make with).
I think being simultaneously curious and skeptical of new technology is healthy attitude to have.
I want to learn new things in order to keep making good websites. I also think there’s a lot of value in talking about the difficulty in learning new things.
I know that Jeffrey and I sound like old men yelling at kids to get off the lawn when we bemoan the fetishisation of complex tools and build processes, but Jeffrey gets to the heart of it here: it’s about appropriateness.
As a designer who used to love creating web experiences in code, I am baffled and numbed by the growing preference for complexity over simplicity. Complexity is good for convincing people they could not possibly do your job. Simplicity is good for everything else.
And not to sound like a broken record, but once again I’m reminded of the rule of least power.
The focus here is on performance, but these tools are equally useful for shining a light on just how bad the situation is with online surveillance and tracking.
A good developer…
- follows the KISS principle (and respects YAGNI)
- knows how to research
- works well with others
- finds good developer tools
- tests code
Prompted by his recent talk at Smashing Conference, Mark explains why he’s all about the pace layers when it comes to design systems. It’s good stuff, and ties in nicely with my recent (pace layers obsessed) talk at An Event Apart.
Structure for pace. Move at the appropriate speed.