You know, we use ad-blockers as well. We gotta keep those servers running though.
Did you know that we publish useful books and run
friendly conferences — crafted for pros like
yourself? E.g. our upcoming SmashingConf Barcelona,
dedicated to smart front-end techniques and design patterns.
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 front-end/UX workshops, webinars and loves solving complex UX, front-end and performance problems in large companies. Get in touch.
Not all products are created equal. While we repeatedly buy some products almost mindlessly, for others, we take a lot of time to make a purchasing decision. For a price tag that meets a certain threshold or if we are particularly invested in the quality of a product, we want to be absolutely certain that we are making the right choice and are getting a good product for a good price. That's where a feature comparison table makes all the difference.
Feature comparison tables are helpful not only in their primary function, though. When designed properly, they can aid in decision-making way beyond placing product specifications side by side. They can also add meaning to an otherwise too technical product specification sheet, explaining why a certain feature is relevant to the customer or how a certain product is better than the others.
When we think about a slider, we usually imagine an image gallery slider, or the infamous carousel, or perhaps off-canvas navigation, with the overlay sliding in from the side. However, this article is not about those kinds of sliders. Instead, we’ll look into the fine details of designing better slider controls for selecting a value or a range of values. Think of price range sliders, 360-degree-view sliders, timeline sliders, health insurance quote calculators, or build-your-own-mobile-plan features.
In all of these use cases, a slider is helpful because it allows users to explore a wide range of options quickly. For precise input, a slider can never beat a regular input field, but we can use a slider to nudge our customers to explore available options and, hence, aid them in making an informed decision.
After a close look at perfect accordions and date and time pickers, let’s turn our attention to sliders, with do’s and don’ts and things to keep in mind when designing one. But first, we need to figure out when a slider makes sense in the first place. (Please note: that article is quite large, and contains many animations and videos.)
What could be so difficult about designing a decent date picker? Basically, we just need an input field and an icon that represents a calendar clearly enough, and once the user clicks on that icon, we pop up a little overlay with the days lined up in rows. Right?
Well, not every date picker fits every interface, just like not every interface actually needs a date picker. But when a date picker is required, quite often it's just a bit too tedious and annoying to specify that one date, and too often it produces irrelevant results or even a zero-results page, although just a few minor refinements would make it much easier to use.
Design patterns. An almost mythical phrase that often inspires either awe or resentment. As designers, we tend to think of design patterns as generic off-the-shelf solutions that can be applied to various contexts almost mechanically, often without proper consideration. Navigation? Off-canvas! Deals of the day? Carousel! You get the idea.
Sometimes we use these patterns without even thinking about them, and there is a good reason for it: Coming up with a brand new solution every time we encounter an interface problem is time-consuming and risky, because we just don’t know how much time will be needed to implement a new solution and whether it will gracefully succeed or miserably fail in usability tests.
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.