This category features articles on general design principles, Web design, typography, user interface design and related topics. It also presents design showcases and practical pieces on the business side of design. Curated by Alma Hoffmann.
This is not a normal Smashing Magazine post. I’m not going to teach you something new or inspire you with examples of great work. Instead, I want to encourage you to complete a Web design challenge. I believe this will help to address a weakness that exists in many of our design processes.
If you complete this challenge, it will make it easier for clients to sign off on your designs, and it will improve the quality of your work. So, what are we waiting for? Let’s get started.
Metrics can be a touchy subject in design. When I say things like, “Designers should embrace A/B testing” or “Metrics can improve design,” I often hear concerns. Many designers tell me they feel that metrics displace creativity or create a paint-by-numbers scenario. They don’t want their training and intuition to be overruled by what a chart says a link color should be.
These are valid concerns, if your company thinks it can replace design with metrics. But if you use them correctly, metrics can vastly improve design and make you an even better designer. First, when I talk about metrics, I’m talking about making use of a couple of very specific tools, i.e. user analytics as well as A/B or multivariate testing.
With CSS animation now supported in both Firefox and Webkit browsers, there is no better time to give it a try. Regardless of its technical form, whether traditional, computer-generated 3-D, Flash or CSS, animation always follows the same basic principles.
In this article, we will take our first steps with CSS animation and consider the main guidelines for creating animation with CSS. We’ll be working through an example, building up the animation using the principles of traditional animation. Finally, we’ll see some real-world usages.
I was a competitive road cyclist for four years. My bikes were good, but my race results were much less impressive. Instead of medals and trophies, all I had to show for it were shaved legs and a farmer’s tan. Regardless, on the road to becoming a competitive athlete, I followed a rigorous training plan with concrete goals. These goals were specific, measurable, attainable, realistic and timely. With this training plan, I was able to quantitatively and qualitatively assess my progress and adjust my routine to match.
In the years since, I’ve hung up my racing jersey and replaced it with a designer’s hat. While wearing this hat, I (and many others) have been told to “create a good user experience.” We’ve heard this in creative briefs, project kick-off meetings and critiques. It may have been a bullet point in a PowerPoint presentation or uttered by someone trying to sell a client or company on the value of their services. But there’s a fundamental problem with stating that your goal is to “create a good user experience.”
The entire process of designing digital applications comes with many challenges and decisions. For the majority of projects, you will be designing in somewhat familiar territory. But what happens when you have to design something to be used by hundreds of children around the world? How do you accommodate your design for kids of different ages and backgrounds? What special challenges emerge, and how can they be overcome?
For a project of this scale, the design process we follow might require modifications. These modifications would be to accommodate the needs of younger age groups and would shape the entire length of the project, from user research, brainstorming, interface design and interaction design all the way to the final stages of usability testing and user support.
Endless layers in Photoshop. Overstuffed image folders. That jQuery plug-in that has 12 files associated with it. Hundreds or thousands of individual pieces go into making a website. No wonder we go off the deep end when we can’t find a closing div — er, section tag.
We work with a ridiculously large number of things, and how we organize them (or choose not to) is often left to personal preference. But our messy habits result in confusion for the designer or developer who inherits your work. Does it really need to be this way?
I think a lot of us CSS authors are doing it wrong. We are selfish by nature; we get into our little bubbles, writing CSS (as amazing as it may be) with only ourselves in mind. How many times have you inherited a CSS file that’s made you say “WTF” at least a dozen times?
HTML has a standard format and syntax that everyone understands. For years, programmers have widely agreed on standards for their respective languages. CSS doesn’t seem to be there yet: everyone has their own favorite format, their own preference between single-line and multi-line, their own ideas on organization, and so on.