Vitaly Friedman loves beautiful content and doesn’t like to give in easily. Vitaly is writer, speaker, author and editor-in-chief of Smashing Magazine. He runs responsive Web design workshops, webinars and loves solving complex UX, front-end and performance problems in large companies. Get in touch.
Smashing Magazine is changing: a new design, a new layout, a new technical stack, a new printed magazine, a new Smashing Membership, and the same good ol’ obsession with quality content. Here’s a sneak preview of what’s coming up.
Today marks an important milestone in Smashing Magazine’s life, and this very page is an early preview of what’s coming up next: many experiments, new challenges, but still a good ol’ obsession with quality content. A complete overhaul, both visually and technically, a fine new printed magazine, and a shiny new Smashing Membership, with nifty features and goodies for you, our lovely community. Curious? Well, fasten your seatbelt and browse around — it’s going to be quite a journey!
With a couple of days left until New Year's Eve, it's just about time to set aside 60 minutes to clean up, sort out and back up your digital footprint, to ensure a good smooth start to 2017. So many little details tend to get forgotten or overlooked every single time, only to get fixed hastily later — but doesn't it just feel right when everything is in the right place, neatly organized, even if you aren't a compulsory cleaner or an obsessed perfectionist?
This is not a generic article about unspectacular things like getting to inbox zero or changing the copyright year in your footer (although that's a good idea!) — we published a detailed checklist of all of those details a couple of years ago. Instead, you'll find below an overview of all of those obscure little things that I forget about every year; so, I decided to gather them all in one place once and for all.
Are you using progressive booting already? What about tree-shaking and code-splitting in React and Angular? Have you set up Brotli or Zopfli compression, OCSP stapling and HPACK compression? Also, how about resource hints, client hints and CSS containment — not to mention IPv6, HTTP/2 and service workers?
Performance isn’t just a technical concern: It matters, and when baking it into the workflow, design decisions have to be informed by their performance implications. Performance has to be measured, monitored and refined continually, and the growing complexity of the web poses new challenges that make it hard to keep track of metrics, because metrics will vary significantly depending on the device, browser, protocol, network type and latency (CDNs, ISPs, caches, proxies, firewalls, load balancers and servers all play a role in performance).
Imagine a cloudy, rainy November evening. After a long day, you walk home along the streets, following the dimmed street lamps. Everybody seems to be busy, rushing somewhere, crossing paths with strangers and lonely stores. It's dark and cold outside, and it's difficult to see things through, so you decide to take a shortcut route to shorten the path.
Suddenly you see a bright light and music streaming from one of the remote corners of the street. Out of curiosity, you slowly walk towards the light, and hold your breath for a second. You discover a little cozy place with a fireplace, packed with people, jazzy tunes, and the smell of pizza, pasta and red wine. You see people smiling. Talking. Laughing. Sharing. Inviting you to join them.
It’s been quite a journey for this very sentence to wind up on this little website. Not many people know it, but every single Smashing article goes through a thorough editorial review, including multiple passes for editing and refinement, before being published.
In this series of articles dedicated to our upcoming 10th anniversary (mid-September 2016), we’d love to shed some light on our editorial process, explain our workflow and introduce the people behind the scenes, as well as address how our little company is earning money to keep the website alive and running.
“Be agile; release early; release often.” We know the drill. But is it strategically wise to keep rolling out features often? Especially once a product you’re building reaches a certain size, you probably don’t want to risk the integrity of your application with every new minor release.
The worst thing that can happen to your product is that loyal users, customers who have been using that one little feature consistently over the years, suddenly aren’t able to use it in the same convenient way. The change might empower users more, but the experience becomes less straightforward.
Design patterns often have a bad reputation. They are often considered to be quick, lazy, off-the-shelf solutions that are applied blindly without consideration of the context of a problem. Solutions such as the almighty off-canvas navigation, the floating label pattern or carousels for featured products are some of the prominent ones.
This article isn’t about these patterns, though. This article features some of the slightly more obscure design patterns, such as responsive car-builder interfaces, mega dropdown navigation, content grids, maps and charts, as well as responsive art direction. Please note that this article isn’t technical; it explores interesting UX patterns out in the wild, rather than code samples. Beware: You will not be able to unsee what you are about to see, and that’s probably a good thing.
So how do you sell a design system to the client? How do you establish a shared commitment within the company to put a pattern library on the roadmap? As designers and developers, we often know and see the benefits of an overarching system that radiates consistency throughout the different experiences of a company. But sometimes it's seen as a very unpredictable investment, and the value isn't necessarily visible right away.
In his article on Selling Design Systems, Dan Mall suggests to illustrate how fractured an organization is by printing out its different presences online and putting them on a large board as an example of all the wasted money and effort that goes into making sites from scratch, one-by-one, needlessly reinventing the wheel every time.
You know how it works: you spend hours trying to find a workaround for a problem that you have encountered, just to realize that it doesn't quite work in, you know, that browser. Finding little techniques and tricks to help you get to results faster can immensely improve your productivity, so you don't have to waste time on solutions that will never see the light of day.
I love finding those little useful front-end goodies that make our lives easier. Since technologies emerge and evolve permanently, keeping track on what's going on is often difficult, especially since specifications change and so does the browser support. For a replacement talk at SmashingConfOxford last week, I've decided to collect some of the useful techniques from various articles, conversations and my workshops in a slide deck — and since it proved to be useful for many front-end developers I've spoken to after the talk, I'm very privileged to share it with the entire community as well.