Really enjoyable post by Mono designer Johan Ronsse on how to design great web forms. I especially like the simple before and after animated gifs that illustrate exactly what changes to make and where.
From Medium, a one stop shop for everything about writing high quality text for the web. Everything from custom underlines to print styles, it’s all here. For web developers/designers, the best part is a technical supplement that outlines a lot of the CSS Medium uses to achieve its typography and layout.
As designer Mike Borsare writes over at the Thoughtbot blog, selecting a color palette for your web site or app doesn’t have to be a painful process. Limit your options to three, use the color wheel, and get inspiration from what’s around you.
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 single source from Typewolf on how and where to add various special typographic characters. There’s grammar tips, examples to copy and paste, keyboard shortcuts, and HTML entities for the web.
A simple web tool to create linear CSS-based gradients. It’s fast and just as effective (if not more) as almost any desktop graphical tool. Just enter a base and shift a few sliders.
The Froont blog strikes again with a wonderful set of animated gifs that explain where web design started way back in the early 90s and where it’s going. The responsive web design animation is especially gorgeous.
I’ve bounced between web design and development for years. As someone who has never had a formal instruction in visual design, Erik Kennedy’s primer on this Medium post isn’t a bad start for those new. I especially like his thought processes behind rule three: double your white space. Might be a bit overkill compared to what’s absolutely necessary, but it’s one of the first mistakes I see from design newbies, especially developers starting to dabble in design work.
Another great find that I heard from a speaker at Sass Summit. It’s a really ingenious methodology to write a running style guide for your work in your source Sass or CSS directory. Basically by writing souped up comments direct in your CSS with a mixture of HTML and Markdown, you can run a ruby process and autogenerate a great looking style guide to the destination of your choice.
For Gulp fans, there’s a simple plugin as well as an alternative to the Ruby gem.
Wonderful mini tips roundup from teacher Paul Scrivens (Makers Cabin) on a tool I find myself turning to more and more. I’m doubt I’ll ever fully leave Photoshop entirely given the web’s remaining reliance on raster graphics, but it’s exciting to see a focused tool like Sketch gain so much momentum.