I recently attended the third annual CSSConf here in NYC. The conference scheduled sixteen speakers over two days with varied content and subject matter. Some speakers talked about the gap between design and development. Others touched on coworker relationships and styling for the web’s future, “post CSS”. Most focused on CSS-based web development. Here are a few takeaways that are easy for almost anyone to integrate into their workflow.
Mark Llobrera, writing on a wonderful post regarding Facebook’s Instant Articles and web performance over at A List Apart:
For most of us, even the ones I would describe as pro-performance, everything in the contemporary web design production pipeline works against the very focus required to keep the web fast. Unless you make some fundamental choices and set up clear constraints, you can—and will—build and ship beautiful sites without feeling a single ounce of the pain and frustration that your users encounter when all of that beautiful imagery, CSS, and JavaScript comes trickling down their mobile network.
Interesting piece from Alastair Coote on how to determine if a user is accessing your web property via either full browser or in-app web view. It effectively is a user agent string check, which by it’s nature means you’re not batting 100% accuracy, but it’s a cool idea nevertheless.
Essential reading by the Filament group on how to speed up the “critical path” of your web site’s load performance. The post includes coverage of asynchronous JavaScript loading and inlining critical CSS.
Great web projects don’t succeed on good design or development chops alone. Communication and collaboration among both designers and developers is just as important.
I’ve seen firsthand otherwise solid designers and developers botch a project just from miscommunication. And those poor relationships persisted beyond the life of the project. I’ve also seen novice designer-developer teams work in unison and deliver amazing results. They resolved potential pitfalls early, delivered their projects on time, and iterated quickly. Coordination isn’t just for projects either; a well coordinated team is a happier team. There are less misunderstandings and less tension if tasks aren’t going as planned.
The collaboration between design and development teams becomes critical in responsive web design (RWD) projects. There are now many devices to account for. Fixed, “pixel perfect” design is exchanged for fluid ratios and proportions. There are also extra image assets to optimize for different device sizes and resolutions.
In short: with RWD, there are more variables, more deliverables and more obstacles. Here are several techniques to overcome these hurdles in any RWD project.
Most designs start from a static perspective. You pick a viewport width and height, then sketch or mockup from there. What do you focus on first with the dev team? What should be the first high-fidelity deliverables to hand off? Which devices get considered early for technical constraints?
I usually recommend to start designing with the smallest and largest common device sizes. When in doubt, base your range on general 2015 web analytics. 320px by 568px, the iPhone 5 in portrait, is a good choice for the small end. Apple’s older flagship is still popular yet small compared to other modern smartphones. For the large end, I like 1600px by 1000px, the size of a large browser on a desktop. Your audience may be different: skewed more towards mobile devices or desktop/laptop users. Check your analytics and change the range as appropriate.
You’re forced to make hard choices when you start with the smallest viewport size. You have to decide on the most important features in your design due to limited space. With the large end viewport, opposite considerations come into play. How much content is too much? Are text columns going too wide, affecting readability in a negative way? Should select elements receive extra white space? And addressing viewport extremes isn’t just about sizing, it’s also for different input methods. The smallest viewports generally use touch, while the largest rely on mouse and keyboard.
It’s easy to forget RWD is a fluid platform given the design attention on static wireframes and comps. Most of your audience won’t see the exact view as your static design. Instead these will tend to be a bit larger or smaller. So consider the layout adjustments necessary between different breakpoints and static comps you design. For example, when sizing down, text content may shrink in size. Image assets can drop into a single column.
Avoid making assumptions about what those adjustments will be with your development team. Be proactive: bring up adjustments before your developers are too deep in their work. For complex layout changes, create another wireframe or sketch to illustrate them. Where specificity is less important, a discussion or an email describing transitions can suffice.
A common stumbling block between designers and developers is image formats and sizes. Smaller elements and icons might be PNGs, JPGs, icon fonts, or SVGs. There’s no one right answer; it depends on the content and resources available. But it’s important to agree on one format and stick with it. Also, you’ll likely develop patterns for common image sizes as your web project progresses.
Yet for modern RWD, that’s just the starting point. You’ll need at least two assets for raster formats (JPGs). One will be for normal displays and the other for high resolution ones. Advanced responsive image techniques need more assets to optimize for different viewport sizes.
Avoid leaving decisions on responsive image formats to the end of a project. At the bare minimum, have a strategy for display density. Read up on srcset and polyfills like Picturefill to ensure good cross-browser support. If it feels overwhelming, start small. Just altering a few image elements with the srcset attribute is a good first step. See how the process goes and grow from there.
My RWD workflow is influenced by Brad Frost’s thoughts on Atomic Web Design and Jonathan Snook’s SMACSS. Both frameworks rely on reusable, small components as the basis for strong web architecture.
So for developer handoffs, I like to concentrate on small and reusable components first. Smaller components generally keep the same UX and visuals across different devices. That consistency can be easier to digest for the development team. To boot, small components tend to be more reusable between pages on your design. So if you design an effective solution, it’s that much easier to re-apply it later on.
Imagine you’re designing a signup page with a headline, large graphic, and signup form. Depending on the device, these elements may shift around or change in size. Early on, focus on the smaller details of the signup form with the dev team. How does it look? What kind of validation is appropriate? How may a form component change with touch input versus mouse and keyboard?
Some designers shield developers from product meetings, usability sessions, and other opportunities for feedback. There’s a kickoff meeting, a handoff meeting, and little else. That’s a mistake. Remember that experienced developers are often an underrated knowledge base. They could have intimate knowledge of the product, especially if they worked on it for an extended period of time.
The skills of front end developers and designers also often overlap. Designers are starting to write their own code. Developers are learning about rapid prototyping, wireframing and aesthetic design. RWD has only exacerbated this trend. A developer can bring strong design insights without a formal “designer” title.
Granted, there’s still value in a separation of roles and responsibilities. Yet small steps toward inclusion can significantly assist the design of the final product. So for your next usability test, bring in a developer to discuss the outcome. Or if you’re on a design brainstorm, consult your developers for a second opinion.
All these techniques need planning and buy-in from others. With so much attention on launching products and hitting deadlines, that can be hard. But designer-developer relations are often underrated, especially for RWD projects. A small investment at the onset can have an exponential payoff for your team.
This post originally appeared as a guest post on InVision’s designer blog.
Excellent explanation of how the Flexbox CSS operator determines layout. I especially enjoy how the author breaks down the math calculations and proportion.
I’m not 100% onboard with everything developer Hugo Giraudel recommends in this long set of recommendations for writing Sass. Yet there’s an incredible amount of solid advice here, especially the bits on numbers, measurement calculations, and selector nesting.
Felicity Evans writes a “manifesto” for well written Sass in A List Apart:
Yet alongside the wide-scale adoption of Sass (which I applaud), I’ve observed a steady decline in the quality of outputted CSS (which I bemoan). It makes sense: Sass introduces a layer of abstraction between the author and the stylesheets. But we need a way to translate the web standards—that we fought so hard for—into this new environment. The problem is, the Sass specification is expanding so much that any set of standards would require constant revision. Instead, what we need is a charter—one that sits outside Sass, yet informs the way we code.
A small collection of Sass mixins, helpers, and functions for common styling on elements. Many if not most I probably wouldn’t use, but a few here, like clearfix, a pseudo triangle, and centering with transforms I rely on all the time for my day job. Worth a look.
Some universally excellent bundles to add on to Sublime Text as a front end developer on CSS Tricks. It’s a short article but touches on importance of extra syntax highlighting along with Emmet for shortcuts, and that’s a great set of tools to kick work off.
