Animations are among the simplest and most effective ways to evoke an emotional response from a website. But whenever you introduce a flourish to web design, there’s always some risk.
Web animations create an element of surprise that can be incredibly attention-grabbing—when used in moderation. A designer should never introduce animations just for the sake of having them. They should be subtle and organic, and not detract from your content.
There are drawbacks: the options can be overwhelming and they can complicate an otherwise simple project. Like whose role is it to determine the animations? the strategist? designer? developer?
Animations can be hard to conceptualize and difficult to then communicate to a project team or client—there are so many different terms to describe the same thing and it’s hard to know if you’ll be on the same page. Also, they can just go horrifically wrong. The client might hate it which has potential to derail a project.
Let’s take a look at some bad animations, good ones and then I’ll offer some tips for doing it right.
Remember when inviting someone to check out your website meant spelling the whole thing out for them: “Double-U, double-u, double-u, dot etc etc, dot com”? (“Wait, how many Ws?”) And if they didn’t remember to type those exact letters and you weren’t nicely SEOed, they might never find you?
Since then a familiar and comfortable taxonomy has emerged, aided by clever browsers that fill in the blanks for us. If you know I work for domain7, you’ll instinctively type in domain7.com—if Chrome doesn’t beat you to the punch by autofilling the URL. On the web, dot-com is the lingua franca. We are all well-versed.
If it turns out someone’s squatting on the dot-com, you could confidently venture to dot-ca (here in Canada). If it’s a non-profit, you could rely on dot-org; for a university, we just jump right to dot-edu; etc. In the old web property game, TLDs had meaning, weight and exclusivity. There was a finite number of options for legitimate websites.
Things got fun a few years ago when companies started experimenting with country codes. We saw a rash of clever URLs...
We get asked all the time about the difference between UX and Usability. A while ago I wrote a blog about it.
That post has been so popular, it seemed worthwhile expanding on it in a way that can be easily passed along:
The old model of completing a degree and landing in your dream career isn’t really a reality anymore.
More and more, the person hiring you wants to see some practical experience and a level of passion and interest in the industry before taking a risk on someone unproven.
It can feel chicken-and-egg-ish. So it’s no surprise I’m frequently asked by recent grads or those transitioning careers: “How do I get the experience I need without a job in my industry?”
The answer is, historically, working for the sake of experience—yup, internships and volunteering. But what about those of us who can’t take time out of work and life to volunteer or work for free? Or those who have passed the age window when an internship seems socially acceptable?
Our president, Shawn Neumann, recently wrote about his experience taking a MOOC—a Massive Open Online Course—through the University of Virginia. MOOCs and other variations of fast-paced, uncredited learning are becoming valuable add-ons and there have never been so many high quality options for professional development. In...
While we love hashing out ideas for client projects as a team, lots of Domain7 discussion / scheming / imagining happens behind the scenes on our Google+ intranet. Often these discussions turn into real life projects or are reflected in client work, but sometimes they're just fun to contribute to and learn from.
Here's transcript of a recent conversation about the interfaces we should or shouldn't use, in cars:
Always cool to see people tackling terrible UI experiences. There are few places that could use innovation more than vehicle...
Developing and following design conventions was incredibly important in the web’s infancy. Every interaction was new to every user. We had no pre-existing knowledge about how to use something, where to find it, or how to get back to where we started.
So we worked hard to establish protocol for human-computer interaction on the web, to protect our users’ sanity and ensure they could get around and do what they needed to do. Specific widths, text sizes, ways of styling things emerged—all of these design standards that assumed the web would always be contained on a 19" ViewSonic CRT monitor.
But since the glory days of Yahoo we’ve seen a glut of innovation in hardware design and in the technologies that drive the web: a proliferation of mobile devices led by Apple, gradual adoption of larger displays for non-graphic professionals, sophistication of front-end technologies, and maturation of browsers in order to handle these new technologies. Bringing the web to all different kinds of environments, screen sizes and contexts has basically destroyed any and all of the conventions we’ve held onto for so long.
As designers are forced to solve new problems...
We see two kinds of projects when building the web: build-to-spec projects, where you bring the idea, we make it happen, and solve-a-problem projects, where we collaborate to find the best opportunity, together.
Our clients seem to happily bring us the second option when the project is a campaign or a fairly standard CMS build. But when clients needs a very tailored custom developed tool or application—the kinds that really involve in-depth problem solving—there is a strange tendency to bring build-to-spec projects to our team.
Here’s the plain fact: most of the time, build-to-spec projects leave big opportunities on the table. A set of specs laid out before you have a understanding of the strength of our design, UX, and technical architecture chops, mean you probably aren’t accessing the full breadth and skill of a custom dev team.
“But we already know what we need,” you might say. “We know what pieces of tech will solve our business problem, and we just need someone to build it.”
That’s why we need to talk. I believe it’s right there—the part where a problem is defined—where we find the most fertile ground for growing a...
- 1 of 49
- Older posts