Seeing Hoefler and Frere-Jones jump into the web font game with their own custom delivery solution is super exciting. Can’t wait to see web sites jump on board this; I’d bet money the quality will be uniformly excellent.
The legendary Jeremy Keith, talking about best practices for responsive web design:
And here’s the key: try to come up with as few major breakpoints as possible. That might sound crazy, since we’re talking about responsive design. After all, we have media queries, so let’s use about 12 of them, right? No! If a linear layout works for every screen and is appropriate for your particular concept, then there’s no need for different layouts.
I’ve learned this the hard way in my early responsive work; you find writing more and more media queries easy, and next thing you know your responsive code gets out of control. Follow Keith’s advice here; simpler is generally better.
Given the stellar quality of Zurb’s web framework Foundation, I’m going to try this “responsive image solution” out on some side project, just to see how the internals come together. But the syntax is a bit worrisome, a bit like the srcset attribute, but not all close to the picture element, which I’m currently favoring. I’ll still keep an eye on this one.
The New Yorker’s Matt Buchanan:
When I spoke to Google designers across a number of products over the past couple of months, they rejected the idea that this was a top-down revolution. They described it instead as a conversation across the company. While an ascendant Larry Page “put the emphasis on beauty and gave us the freedom to go beyond,” said Gilbert, there’s “no organizational authority making it happen.”
Whatever the real story, from grass roots to a top-down skunkworks factory, it’s working. A year or two ago I wrote off Google’s design chops, especially on an aesthetic level, as dull and uninspired. No longer.
Developer Lucas Rocha:
Why is it so important to have designers and engineers working very closely? First, there are a number of issues that you only spot once you actually try the design ideas. If designers don’t engage with engineers, the product will likely stick with broken and/or unintended design.
Furthermore, design issues are tricky in that they have this qualitative side that tends to be invisible to untrained eyes. Design problems will not necessarily be caught by even the most competent QA team or the most solid UI tests—because both are usually focused on the functional correctness of the product.
As I’ve said many times here, close collaboration between a tech team’s designers and engineers isn’t just a “nice to have”. It’s essential for success, especially in smaller organizations like startups.
Designer Khoi Vinh:
It’s much more common for designers to be expected to master the engineering vernacular than vice versa, but that shouldn’t stop designers from asking engineers what they know about design. Designers might hesitate to ask if the engineer understands anything about typography, color, images, branding systems and logos, but I say why not? It’s perfectly fair game to ask if an engineer understands why a given design solution works…An engineer who understands these things is a tremendous asset in shipping great products, and designers are best equipped to assess that.
Developer Philip Walton:
A Rails developer isn’t considered good just because his code works to spec. This is considered baseline. Of course it must work to spec; its merit is based on other things: Is the code readable? Is it easy to change or extend? Is it decoupled from other parts of the application? Will it scale?
These questions are natural when assessing other parts of the code base, and CSS shouldn’t be any different.
I think Philip goes a bit into the deep end with his class naming conventions. Nevertheless, especially with his points about code reuse and modularity, this is essential CSS reading, one of the best articles I’ve read on the subject in weeks.
Designer and Paravel founder Trent Walton on the strength of small teams with a skill set balanced among planning, design and development:
When various skill sets are combined in this way, people learn from each other. Rather than creating to-do lists filled with nudges and site tweaks for developers, designers could learn CSS and edit designs in the browser alongside more intensive development. Developers could hone their design sensibilities and contribute by making enhancements such as gestures, geolocation, and performance a part of the design process.
Trent’s right. The faster we mix and integrate our teams, the less “siloed” work and more “T shaped” contributors, the stronger our web work becomes.
I’ve got a lot of respect for web designer Chris Coyier. His Css Tricks is pretty much the definitive resource I head to when looking up CSS techniques. That’s when, via a pretty random Google search, I came upon this talk he gave late last year. Really great advice here, from development setup to deployment strategy. Chris is a entertaining speaker as well; you won’t get bored.
Almost any modern web designer now has to decide between potentially thousands of custom web fonts. To rapidly prototype different combinations in the browser, even with good front end development chops, can be pretty time consuming.
Typecast is a web app that tries to address this problem. You get a much more visual, WYSIWYG interface for trying out font combinations, but with the advantages of actual font rendering in the browser. I don’t see a personal need for the app given the cost ($29 a month isn’t a minor expense) and considering at my day job we’re mostly focused on Proxima Nova. But especially in an agency environment, this could be a huge time saver.