We use ad-blockers as well, you know. 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. upcoming SmashingConf New York, dedicated to smart front-end techniques and design patterns.
Reviews, testimonials and word of mouth are winning the war in branding. A sea of research is out there about social proof and what to do and what not to do about soliciting customer reviews. It’s overwhelming to read and digest it all, let alone to know which nuggets are gold and which are fool’s gold. For a designer or business owner or marketer, knowing who or what to listen to can be difficult.
Here’s what I like to do: Find data! I like to find really smart researchers who are in the lab studying the topic du jour, interview them about their work, and then tell you all about it. Using the magic of science to improve how we solicit customers for feedback, testimonials or reviews can be a saving grace to those who would like to share happy customer reviews and remedy any lackluster experiences — in the best way possible, in fact: without sacrificing good UX or losing valuable customers.
Guess what: those tricky mystery riddles are never easy to design. The idea has to be evaluated and brought into life, just to be crashed by painful user tests and then adjusted over and over again until it's easy enough to solve — but difficult enough to not solve fast.
When we started out with riddles, we wanted to have an entertaining yet challenging game that wouldn't be easy to crack, and would keep our dear readers busy for quite some time.
Mark Zuckerberg once said, “The biggest mistake that we made, as a company, is betting too much on HTML5 as opposed to native… because it just wasn’t there. And it’s not that HTML5 is bad. I’m actually, long term, really excited about it.” And who wouldn’t be excited by the prospect of a single code base that works across multiple platforms?
Unfortunately, Facebook felt that HTML5 didn’t offer the experience it was looking to build, and that’s what it’s really about: the experience. I believe what Mark was really trying to say was that their biggest mistake was making a technology-driven decision instead of a user experience-driven decision. At the end of the day, we should be making decisions that deliver value to our customers, and sticking to a particular technology is generally not the best way to achieve that.
The first time I became aware of brand inconsistency was four, maybe five years ago. Companies were extending their appearances to apps, social media and other digital channels. And so did the bank I worked for back then. Unfortunately, no style guides were available to cover these channels.
I remember the dilemma while writing specifications: there were some older corporate identity manuals and some static UI style guides. Then, you’d look at newer web projects and none of them reflected the guidelines. So, what was I to do? Strictly obey the guidelines and produce something that looks outdated, or adapt to modern channels and risking a user experience that diverged from existing customer touch points?
When it comes to web projects, real estate and home appliances go well together, so today we're happy to release a lovely free icon set with 72 related icons. The set includes icons in 4 sizes and in 8 formats: AI, CSH, EPS, SVG, PDF, PNG, Sketch and Webfont. The icon set is free to use in personal and commercial projects. Designed by Funline Icons.
Feel free to modify the size, color or shape of the icons. No attribution is required, though reselling bundles or individual pictograms isn't allowed (and it isn't cool either). Please note that the set is released under a Creative Commons Attribution 3.0 Unported license. We'd kindly like to ask you to provide credits to the creator and link to this article if you would like to spread the word.
The Internet of Things (IoT) has enabled the Internet to reach beyond the browser. Made up of electronically networked devices, these “things” are able to interact with the physical world via sensors that feed data they capture back into their ecosystems.
Currently, these devices are mostly products, designed with a specific purpose in mind, a typical example being a fitness band that tracks activity. It reports the information gathered to an app, which is then able to analyze the data and offer suggestions and motivation to push the user further.
In many projects, responsive images aren’t a technical issue but a strategic concern. Delivering different images to different screens is technically possible with srcset and sizes and <picture> element and Picturefill (or a similar) polyfill; but all of those variants of images have to be created, adjusted and baked into the logic of the existing CMS. And that's not easy.
On top of that, responsive images markuphas to be generated and added into HTML as well, and if a new image variant comes into play at some point (e.g. a file format like WebP or a large landscape/portrait variant), the markup has to be updated. The amount of extra work required often causes trouble — so if you have a perfect product shot, you need to either manually create variants for mobile and portrait and landscape and larger views, or build plugins and extensions to somehow automate the process.
Nothing is perfect on the web. We can't make sure that our websites always work as intended, but we can try our best to design resilient and flexible websites that aren't that easy to break — both in terms of interface design and security. Yet neither resilience nor flexibility are usually reflected in our deliverables and mock-ups.
In practice, mock-ups usually represent a perfect experience in a perfect context with perfect data which doesn't really exist. A good example for it are “optimal" usernames which are perfectly short, fit on a single line on mobile and wrap nicely, or perfect photography that allows for perfectly legible text overlays. It's not realistic. We need to work with dynamic content in our prototypes, with both average and extremes being represented.
This week I mostly spent time on fixing bugs, improving a deployment workflow and on getting another new front-end project structured. One major takeaway from this was that it’s good to have a proper deployment workflow in place already in the early stages of a project.
To document appropriately in git what has been done in a commit instead of sleazily writing “changed [XY] because of [some arbitrary reason]”. By doing so, it becomes easier for myself, or someone else, to identify bugs at a later stage.