The information you put into a commit message needs to be useful to the people who will read it. Instead of going into too much detail, or worrying about abstract questions like whether a given commit is the release version of a thing, focus on a much simpler story: I just did a thing, and this is the thing I just did. In this excerpt from Git for Humans, David Demaree outlines some best practices for crafting effective commits.
In an ideal world, we’d be able to modify a design or graphic for the web while keeping the original intact, all without opening an image editor. We’d save tons of time by not having to manually reprocess graphics whenever we changed stuff. Graphics could be neatly specified, maintained, and manipulated with just a few licks of CSS. Oh. Wait. We can do that! Justin McDowell gives us the lowdown on blending modes.
We use color to influence mood, create an environment, and tell a story. 125 years ago, impressionist painter Claude Monet changed the way we think about color by describing light’s role in it. His observations have largely been lost on design for the web—but a preprocessor like Sass offers us unprecedented power to mix tints and shades that will imbue our palettes with more nuance.
When people think in terms of pages, it might seem natural for component design and page design to occur in tandem. But this can undermine a team’s ability to name components and build a shared vocabulary. With colleagues at Clearleft, Charlotte Jackson developed an exercise to help everyone adopt pattern thinking. She takes us through the process step by step, encouraging us to get away from our screens and focus first on thinking, language, and approach.
Practice makes perfect, but how do you help your team practice difficult conversations? Senongo Akpem shows how roleplay can help new managers learn useful techniques and gain confidence for those tough discussions ahead.
If you only interact with users when they need support or have a feature request, you’re only interacting with the minority of your customers. The ones who don’t reach out to you may be creating their own workarounds to a problem you’d love to hear about, or they may have a use case that would lead to a brilliant feature. Are you guilty of the same developer shyness? Do you build things to enhance a tool or service for your own use, and assume the developer is too busy to want to hear about it? Don’t wait until there’s a need for support: ask your happy customers what they do with your product, and tell developers how you’re using their product.
That never-ending search for the perfect CMS—maybe we’re using the wrong criteria. Too frequently, we approach CMS selection with cost or functionality as our bottom line, leading to solutions that look good, but struggle to adapt to the internal workflow. But finding a tool that matches organizational requirements means shifting focus. Artas Bartas presents three ways of approaching the CMS selection process with your team’s needs and processes top of mind.
Decoupling your CMS can broaden your options for the presentation layer, let team members narrow their focus to what each does best, or provide data for iOS and Android applications along with a responsive site. Maybe the greatest benefit is that having to consider the relationship between the CMS and rendering layer helps break up assumptions about delivery formats, making you more future-friendly along the way. Mark Llobrera shares a couple of tales where headless was the right solution.
Because every site has unique needs, no two content management systems should ever be alike. When implementing and customizing a new CMS, writes Rory Douglas, give your users only as much freedom as they need—but not enough to mess things up. They’ll love you for it.
Responsive web design changed everything about how we think and work on the web—and five years on, we’re still exploring the best ways to approach our practice. If we want a web that is truly universal, we must consider our users, our medium, and our teams in new, adaptable ways. Looking at where we’ve come from and where we’re going, Paul Robert Lloyd proposes a philosophical framework for our work on the responsive web.