Articles by

Robin Rendle

Ethan Marcotte on digital disenfranchisement and why we should design lightning fast, accessible websites:

We're building on a web littered with too-heavy sites, on an internet that's unevenly, unequally distributed. That’s why designing a lightweight, inexpensive digital experience is a form of kindness. And while that kindness might seem like a small thing these days, it's a critical one. A device-agnostic, data-friendly interface helps ensure your work can reach as many people as possible, regardless of their location, income level, network quality, or device.

Another swell post by Ire Aderinokun, this time on the curious minmax() CSS function and how it works alongside the CSS Grid features that we've been experimenting with lately.

What's especially great here is the examples where Ire explains how we can avoid media queries altogether. With just a couple of lines of CSS we can now build pretty complicated layouts.

Bruce Lawson explores many of the misconceptions that web designers might have when building websites. The crux of his argument is that we should be focusing on designing for users that are just getting online and for those that have frustratingly slow internet connection speeds.

He even makes a bold prediction:

Many of your next customers will come from the area circled below, if only because there are more human beings alive in this circle than in the world outside the circle.

Kelly Sutton has written a post called Deletability and I've been thinking about it all day and how his ideas relate to writing CSS:

By working with code, we see that modularity and deletability are closely related. Properly modularized code is easy to delete.

Writing deletable code is writing good code.

Apparently, this is a common approach to writing software although I've never heard of this concept when taken to the front-end side of things. But! I think it should be a goal for us to have in mind when we’re naming classes or building complex layouts. And after mulling over this idea all day I think that questions like "can I throw this code away easily?" should be a measuring stick for whether we're doing a good job at writing CSS.

(more…)

Manton Reece and Brent Simmons have just published their thoughts on JSON Feed which is a new standard for making a feed, like a collection of blog posts. The format itself is similar to RSS and Atom but since it's in JSON it's easier to read and a lot more familiar to developers:

For most developers, JSON is far easier to read and write than XML. Developers may groan at picking up an XML parser, but decoding JSON is often just a single line of code.

Our hope is that, because of the lightness of JSON and simplicity of the JSON Feed format, developers will be more attracted to developing for the open web.

My favorite part about this project? The spec is just so gosh darn easy to read.

Late last year the team at the Financial Times launched a redesign that focused specifically on web performance and improving the user experience. And so in a post detailing their findings, James Webb writes about how this design impacted their business:

We wanted to keep page load time to an absolute minimum; our target was to become the fastest site in the publishing industry.

To emphasize the importance of a faster website to key internal stakeholders, we had to understand the true impact site speed had on user engagement. Fortunately, our analytics team had developed a sophisticated internal engagement metric that accurately predicts the likelihood of renewing a subscription.

Through a rough a series of A/B tests, we slowed the site down to see how site speed correlates to the loss of engagement and revenue. Test results showed that for every one-second increase in speed, our engagement score increased by 5%. In subscription and ads inventory, this translates into millions in revenue. Speed therefore became a principal element of the site.

If you find case studies like this useful, see WPO Stats.

Chen Hui Jing has written an excellent post on the history of CSS fonts and the way that the W3C writes the specification and strange CSS properties like font-effect, font-emphasize and font-presentation.

As part of my perpetual obsession with typography, as well as CSS, I've been looking into how we got to having more web fonts than we can shake a stick at. What I love about how the W3C does things is that there are always links to previous versions of the specification, all the way back to the first drafts.

Although those are missing the full picture of the various discussions and meetings among all the individuals involved in crafting and implementing the specifications, it does offer some clues to how things got to where they are.

Stuart Frisby documents that you shouldn't use the font shorthand when using a System Font Stack:

...don't use -apple-system at the head of a shorthand font declaration, and test thoroughly, especially when playing around with proprietary stuff like system font declarations. If it looks like a vendor prefix and smells like a vendor prefix, chances are at least one browser is going to treat it like a vendor prefix.

Use font-family instead.