BlogmyQuery – BMQ

When we started Smashing Magazine, we didn’t expect anything. We didn’t have a grand master plan for a successful online magazine for designers and developers. We created something that we found useful and that we thought others would find useful, too. We did not lose focus, we relied on instinct more than once, we stayed patient, and we pulled the occasional night shift. That was 2006.

And then you came along.

You have passed the word along, left comments, dropped us emails. You let us know that we matter. You let us know that we are doing something meaningful. And you let us know that our humble work deserved your attention. And we listened — carefully.

Five years have passed, and the magazine has changed. That small, obscure blog of list posts and round-ups has evolved into a professional publication with a publishing policy, editorial structures and a house style guide. The Smashing family no longer has only two members, but rather a dedicated team of experienced authors, research assistants, expert advisors, editors and proofreaders.

We all do our best to bring you the trusted advice, techniques, tutorials, resources and opinions that Smashing Magazine is known for nowadays and that the Web design community around the world has come to rely on.

Smashing Magazine is a quality-obsessed, passionate team, but it is also you: you and every single reader who has been reading Smashing Magazine for all these years. Thank you for being with us; thank you for your support, criticism and encouragement over all these years. We could not exist without you.

A Smashing Magazine Anniversary Treat

Today, Smashing Magazine turns five. It’s hard to believe that the years have passed so quickly. Many things have changed, but when we look back, we realize how wonderful and sometimes even intoxicating the journey has been so far. And you — who made us what we are today — deserve a special thank-you.

To honor the occasion, we have a humble gift for you: the free “Best of Smashing Magazine” Anniversary eBook.

The eBook is available in PDF, ePUB and Mobipocket formats. This eBook is our gift to you for your support, criticism and encouragement over all these years. We’d like it to be your very own memory box of your last five years with Smashing Magazine — something perhaps to bring back memories a couple of years from now. We’d like you to have a part of Smashing Magazine with you when you are on the go.

What’s in the eBook?

The eBook contains the best articles that have been published on Smashing Magazine in the last five years — and by “best,â€� we mean the most useful, most interesting or most inspiring. The articles have been carefully edited, proofread and updated for your convenience and reading pleasure on your eBook reader.

It discusses usability issues and the principles of effective Web design. It covers the guidelines for beautiful and effective typography, and it spotlights methods of responsive Web design. In addition, you’ll learn how to master professional Photoshop techniques, explore storytelling in your designs, and focus on three key areas to polish your content strategy. Never thought that harmony between designers and developers was possible? Dig in to see how the two camps can collaborate productively and learn from each other.

Table of Contents

• “Thirty Usability Issues to Be Aware Ofâ€�  —  Vitaly Friedman
• “Ten Principles of Effective Web Designâ€�  —  Vitaly Friedman
• “Clever JPEG Optimization Techniquesâ€�  —  Sergey Chikuyonok
• “Typographic Design Patterns and Best Practicesâ€�  —  Smashing Editorial team
• “Ten Useful Usability Findings and Guidelinesâ€�  —  Dmitry Fadeyev
• “Setting Up Photoshop for Web and iPhone Developmentâ€�  —  Marc Edwards
• “The Ails of Typographic Anti-Aliasingâ€�  —  Tom Giannattasio
• “Mastering Photoshop: Noise, Textures and Gradientsâ€�  —  Marc Edwards
• “Better User Experience With Storytellingâ€�  —  Francisco Inchauste
• “The Beauty of Typography, Writing Systems and Calligraphyâ€�  —  Jessica Bordeau
• “Web Designers, Don’t Do It Aloneâ€�  —  Paul Boag
• “Making Your Mark on the Web Is Easier Than You Thinkâ€�  —  Christian Heilmann
• “Responsive Web Design: What It Is and How to Use Itâ€�  —  Kayla Knight
• “I Want to Be a Web Designer When I Grow Upâ€�  —  Michael Aleo
• “Persuasion Triggers in Web Designâ€�  —  David Travis
• “What Font Should I Use?â€�  —  Dan Mayer
• “The Design Matrix: A Powerful Tool for Guiding Client Inputâ€�  —  Bridget Fahrland
• “Why User Experience Cannot Be Designedâ€�  —  Helge Fredheim
• “Dear Web Design Community, Where Have You Gone?â€�  —  Vitaly Friedman
• “Make Your Content Make a Differenceâ€�  —  Colleen Jones
• “Two Cats in a Sack: Designer-Developer Discordâ€�  —  Cassie McDaniel
• “Print Loves Webâ€�  —  Mark Cossey

Previews of the Smashing Anniversary eBook

Take a look at the following preview to get a taste of the eBook’s contents.

Use the practical and inspiring articles in the Smashing Anniversary eBook to refuel, and get those brilliant ideas rolling again!

Download It Now For Free

Again, you can download the eBook in for free in PDF, ePUB and Mobipocket formats.

• Download your free copy from Apple’s iTunes Store
• Download your free copy from Smashing Magazine’s server (.zip, 55 Mb).

Please note that due to differing publishing policies around the world, downloading via iTunes is currently available only to customers with an iTunes account in the US, Canada, Australia, Great Britain, France and Germany. We are working hard to make future Smashing Magazine publications available to all of our readers around the world.

Cheers, dear friends. And here is to the next five years!

(al) (vf) (il)

© Smashing Editorial for Smashing Magazine, 2011.

As web designers and developers we tend to view the web somewhat differently than most. Our work keeps our focus tuned to the finer points of the field as we browse, even in our time off. We tend to get inspiration from this way of seeing the web. Hints of techniques or approaches to attempt for our next projects emerge from all corners of the web. And given that our next client could emerge from any arena, we need to be prepared for any and everything. Like for instance our next client could be some sort of charitable organization that works off of donations, and as such, they might need us to design them a site complete with a donation page.

Now there are many considerations that need to be made when we are designing, especially a page whose calls to actions are often vital to the mission for the client behind it. Which is why we have gathered together a showcase of well designed donation pages for our readers, complete with some resources at the end of the post to help prepare them for those potential clients to come calling. Take a peek down through to see some examples of both subtle and more extravagant designs that have tackled this task with style.

The Showcase

Operation Warm is a nice site with comfortable, welcoming color scheme. The donation page calls vary in color, however the main calls to action blend with a majority of the site given that they are the same color. The secondary calls stand out a bit more as they break from the blue.

Manna FoodBank uses a natural, earth-tone color scheme which goes well with their mission. The call to action button stands apart nicely even with only the slight changes in color, next to the information about their cause.

The Red Nose Day site uses a simple two tone color scheme. The red colors pervading the donation page denoting the passion for the mission, and driving people to take action.

Oxfam is another site whose donation page design focuses all of its attention on the necessary mission and calls to the readers.

Network for Good has a wonderful design, with three courses of action that their readers may follow. Each with a large, eye catching call to action button.

Save the Children has a sleek design for its donation page with designated avenues for assistance that the users have at their disposal. With so many courses of action for users, it could easily become a cluttered mess, but the design keeps it all organized well.

The Make-A-Wish donation page, while constructed well, does suffer from a lack of distinction for its calls. The blue becomes somewhat overwhelming with the amount of information it contains.

Mozilla has a subtle donation page design with a creative header attached to their site where fans and users can donate to keep their mission alive.

American Heart Association‘s donation page is stylish and focuses the users attention directly towards the calls. The color scheme works well, with the subtle uses of white inserted into the blue.

The Kiva site’s donation page is sharp and focused on multiple routes to lending a helping hand, and the large boldly colored call to action buttons stand out from the rest of the page nicely.

Doctors without Borders has a great donation page design, using tabbed windows to separate the various paths that users can take to pitch in. Overall the design is simple and effective.

Virgin Money Giving is a unique donation page, with a category breakdown so users can find the type of charitable organization they are looking to support.

Giving to Johns Hopkins has a stylish design pushing its cause. The contrast in colors on the header and call to action button work wonderfully in making them stand out.

Humane Society‘s donation page uses large images and bold buttons to draw the users attention and persuade them to take action.

Keep a Child Alive has a very sleek design with large buttons with various ways to contribute to the mission. With a slight grungy effect used to highlight areas of the page, the design stands out.

ASPCA has another subtle donation page design with the purple calls standing out from the overall orange design colors. Soft coloring imparts a sense of comfort and eases the readers into the cause and taking action.

Invisible Children has a donation page that is as stirring and emotive as their mission. With large images of the children the world tends to overlook connects the design with the cause in a simple yet effective way.

MJFF uses warm and inviting colors which work well for engaging the readers. The gradient on the actual donate button does help it stand out, but the coloring is still a bit too similar to the rest of the accents to really draw the eye.

The Natural Resources Defense Council has a very simplistic design with overly large and bold call to action buttons. This no frills approach puts pure focus on the mission.

Planned Parenthood‘s donation page uses a form for the main appeal to the readers, with secondary (more subtle) calls in the upper right corner. Overall, the large header and large body text compliment each other leading the reader into the ‘action center’.

Donate Life California has a somewhat whimsical design, with pink calls to action buttons that really stand out from the rest of the site, yet match with the logo of the organization.

Red takes minimalism to stylish levels with their donation page design. The overly large typographical elements really do wonders for boldly drawing the eyes to the action areas.

The Nature Conservancy has another simple, sleek donation page. Mostly text covers the page, with two subtle calls positioned under the header where users tend to expect the navigation to be.

Charity: Water‘s donation page is keeps the focus on the mission with the aid of this understated design.

The Action for Children page design has a large, eye catching call to action area which sets off the donation area nicely and effectively pulls the reader to it.

Tutorials & Tools

Below are a small handful of resources that you can use for making the most of any donation page you have to design. Go through them now, or save them for when your next client needs their site to go this route. Either way, we hope you find them useful.

Donation Page Optimization Basics

WordPress Donate Plugin

Increasing Online Giving: 10 Tips to Optimize Your Donation Landing Pages

Paypal Custom and Donation Forms

How To – Create A Donation Page for WordPress

The Most Effective Online Donation Page Ever

(rb)

You’re developing a new website and have decided to use some CSS3 and HTML5, now that many of the new specifications are gaining widespread support. As you’re coding the theme and thinking of how much easier these new technologies are making your job, you decide to stop for a while and test in other browsers, feeling a bit guilty for getting carried away and having forgotten to do so for a while. “Please work,� you whisper to your computer, while firing up all of the browsers you have installed. Browser A, check. You smile, feeling a bit relieved. Browser B, check. Your smile widens, and you start to feel better already. Browser C, “FFFFUUUUUUUUUUU…!�

Sound familiar? You might be surprised to hear that this is not necessarily your fault. With the competition in the browser market these days and the fast pace at which the new specifications are developing, browser makers are implementing new stuff in a hurry, sometimes without properly testing it. CSS3 and HTML5 are much more complex than their predecessors. The number of possible combinations of new features is huge, which leads to the most common cause of bugs: two (or more) things that weren’t tested together. As a result, developers these days stumble upon browser bugs much more frequently than they used to.

Why Should I Bother Reporting Bugs?

If you don’t, perhaps no one else will. Maybe the bug you’ve discovered is so rare that no one else will stumble on it. Or maybe they will, but they won’t know how to report it. They might think that it’s their fault, just as you originally did. Besides, if you’ve used these new technologies in a way that triggers the bug now, you will likely do so again in the future as well, so you would directly benefit from the bug getting fixed. And in the process, you’d be helping thousands of other developers avoid the frustration you’ve faced.

You might think that reporting the bug would be pointless, because it would take ages to fix, and would take even longer for users to upgrade to the fixed version. However, for all browsers except Internet Explorer (IE), this is not true anymore. Users of Firefox, Opera, Safari and Chrome upgrade really quickly these days, because the software pushes them to do so or (in the case of Chrome) doesn’t even give them a choice. Also, some bugs get fixed quite quickly, especially the ones that come with a decent report. Keep reading, and your own bug reports will likely fall in this latter category.

Making A Reduction

The first step is to reduce the problem to its bare minimum. If it turns out to be a browser bug, you will need to include this “reduction� in your bug report. Also, this will help you figure out a potential workaround until the browser vendor fixes it. Even if it’s not actually a browser bug, doing this will help you realize what you did wrong and fix it. Lastly, it’s a valuable aid in debugging in general.

Here is the process I follow to create reductions:

1. Make a copy of your project. If it includes server-side code, then first save the rendered page locally; the rest of the process will be identical from this point on.
2. Start removing CSS and JavaScript files. Eventually, you’ll find that removing one makes the problem go away. Add that one back and remove the others (except any files it depends on). In some rare cases, you might find that the bug persists even after removing all CSS and JavaScript code. In these cases, the bug is more than likely HTML-related.
3. Now you need to find the exact code in the file that triggers the problem. Start commenting out parts of the code until the problem goes away (being careful not to introduce any new problems in the process). I find that the quickest way to do this is like doing a binary search: first, comment out around half of the code; if the bug persists, then remove that code and comment out half of the remaining code, and so on; if the bug disappears, then remove the uncommented code and proceed with that. You might find that deleting and undoing is quicker than commenting and uncommenting. Sometimes you have to do this process twice in the same file, because some bugs can be reproduced only with a particular combination of different code parts.
4. Put the remaining CSS and JavaScript code inline by transferring it from the external file to a <style> or <script> element in the HTML document. This will make the reduction even simpler because it will be contained in only one file.
5. Now, simplify the HTML. For example, if it’s a CSS bug, then remove everything that CSS rules don’t apply to. If the rules apply to a nested element, try applying them to the <body> instead and see whether the bug reproduces. If it is, then remove all of the <body>’s descendants.
6. Change the document’s <title> to something relevant to the bug. Check the whole thing carefully for details that you wouldn’t want other people to see, because you usually can’t edit it after attaching it to your bug report. (I learned this the hard way.)

Now that you have your reduction, examine the code. Is it actually correct? Browser makers can’t be held accountable for the way their products handle invalid code — except for HTML5 markup, which has strictly defined error-handling. Validating the code might help, but take its output with a grain of salt. (Note that CSS vendor prefixes are valid, even if the CSS validator disagrees.)

If you have some time and want to be extra nice, here are some other things you can do to make an even better reduction:

• Test to see whether the bug is more general than the case you have discovered. For example, if you discovered that an engine doesn’t handle border-radius: 50% correctly, then test whether the same thing happens with other percentage-based values. Or if a CSS gradient from black to transparent does not display correctly, see whether the same thing happens when you use a transition from background-color: transparent to background-color: black; if it does, then that would mean the problem stems from general interpolation and is not limited to CSS gradients. Even if you find that it’s not more general than the case you originally stumbled on, do mention your experiments in the bug description, so that the developers don’t have to repeat them.
• Try to find a workaround. Can you change or add something in the code to make the bug go away? This could be as easy as converting ems to pixels or as hard as adding a whole new declaration. Be sure to mention the workaround in the bug report.
• Make it function like a test case, or create an additional test case. These are the special kinds of reductions that QA engineers make for automated testing systems. Such tests show the color green in browsers that don’t have the bug and red in the ones that do. Other colors may be shown, but not red and green at the same time. This is an easy task with some bugs, and incredibly hard with others.

Sometimes the nature of the problem is quite obvious, so creating a simple test case from scratch is quicker. I’ve found JSFiddle to be an invaluable aid in this. However, bear in mind that browser vendors usually prefer that you upload your own simple HTML files rather than provide JSFiddle links. If you do decide to use JSFiddle, then uncheck the “Normalized CSSâ€� setting, remove any JavaScript libraries (unless your bug needs them to be reproduced), and append /show to the URL, so that it leads only to your test case, without the rest of the JSFiddle UI.

If you don’t have the time to make a reduction, reporting the bug is still a good idea. A bad bug report is better than none at all, and the same goes for reductions. In this case, the browser developers will have to create the reduction themselves. The difference is that they’re burdened with doing this for many more bugs than you can imagine. You only have to do it for one: yours.

Should I Report It?

There are many reasons why you might not need to report the problem as a bug after all:

• It turns out it’s not really a bug,
• It has already been fixed in the latest nightly build,
• It has already been reported.

Let’s tackle these one by one.

Is It Really a Bug?

In most cases, when you isolate the problem to a simple reduction, it’s fairly obvious whether it’s a browser bug or not. However, there are some caveats to this.

A while ago, I realized that even though outline-color: invert was in the CSS specification, it didn’t work in all browsers that support outlines. In particular, it didn’t work in Webkit browsers or Firefox. Those browsers didn’t drop the declaration, but just treated it as though it was currentColor. So, I went ahead, created a reduction, and filed bug reports with both browsers. After a while, I was informed that a footnote in the specification actually permits user agents to do this, so it wasn’t actually a bug. The moral of the story is to check the specification carefully — not just the table that is included in every CSS property, but the whole thing. Knowing these details will make you a better developer anyway.

On another occasion, I was reading the “CSS3 Backgrounds and Bordersâ€� module and found that it allowed percentages to be used for border-width, unlike CSS 2.1. I tested it, and it didn’t work in any browser. So, I filed bug reports in some of them, only to be informed that this was dropped in the “devâ€� version (i.e. the not-yet-published version) of the specification. The moral of this story is that, for specs still under development, don’t check the published specifications to determine whether your issue is actually a bug. Instead, look at dev.w3.org, where the most up-to-date versions of the specs reside.

Of course, in many cases, a bug is not really a bug or a lack of understanding of the spec, but just one of those stupid mistakes that we all do (aka brain farts). I remember once how distraught I was over my JavaScript not working at all in Safari, even though it gave no errors. After a while of struggling to make a reduction, I realized that I had previously disabled JavaScript in that browser to test how a website worked without it and had forgotten to enable it.

Likewise, a few days ago, my SVGs weren’t displaying as backgrounds in Firefox, even though they displayed when I opened them in new tabs. I then realized that I had two background images in the same declaration, the other one being a CSS gradient, and I had forgotten to add the -moz- version.

The one I’m most embarrassed about is when I actually reported a bug to Opera about pointer-events not working in <select> menus and was then informed that Opera hadn’t implemented pointer-events in HTML elements at all. D’oh!

In some rare cases, the bug is indeed a bug but not a browser bug. Specifications have their fair share of bugs, too. If the spec defines something other than what happens or if it defines something that conflicts with the rest of the spec, then it most likely has a bug. Such bugs should be reported in the relevant mailing list (www-style for CSS) or the W3C bug tracker. Even if this is the case, many of the guidelines mentioned below still apply.

Is It Reproducible in the Latest Nightly Builds?

If you haven’t already installed the nightlies of browsers, you should. These are the latest (potentially unstable) versions of browsers. Download them from these links:

• IE 10 Platform Preview 2
• Firefox Nightly
• Opera Next
• Chrome Canary
• Webkit Nightly Builds

Obviously, if your bug is not reproducible in the latest nightly of the browser, then you don’t have to report it. Just wait until the build propagates to a stable release. In other words, all you need is patience, young Padawan.

Has It Already Been Reported?

If after checking the specifications and the latest nightly, you’re still confident that it is a bug, then you need to search whether it has already been reported. Your best bet is to use the search engine of the relevant bug tracker. Don’t forget to search all statuses, because the default on some bug-tracking systems is to search only confirmed and open bugs (excluding unconfirmed and fixed or otherwise closed ones).

Be vague in your search, especially if the bug affects a feature that’s not very popular. For example, for this Webkit bug, a search for “multiple fileâ€� would show the bug, whereas a search for “input file multiple dom propertyâ€� would not; I was inexperienced when I filed it and didn’t know the exact terminology at the time. If the bug tracker is public, sometimes searching on Google also helps (adding site:url-of-bug-tracker after your keywords).

If your issue has indeed been reported, some bug trackers allow voting. Mozilla’s Bugzilla gives every user a limited number of votes (the limit is in the thousands), which the user can use on any bug they wish. Also, Chrome’s bug tracker features a star in the top-left corner, which you can click to indicate that you consider the bug important. I’m not yet sure whether the developers take this into account, but voting certainly doesn’t hurt.

Different Engines, Different Bug Trackers

Every browser has its own bug-tracking system (BTS).

• Internet Explorer (new bug)
• Firefox (new bug)
• Opera wizard
• Webkit (new bug)
• Chrome (new bug)

Safari and Chrome share the same engine (Webkit), so bugs that can be reproduced in both should be reported in Webkit’s BTS. Chrome has its own BTS as well, intended for bugs that are reproducible only in it. Also, if you’re dealing with a JavaScript bug in Chrome, report it to the V8 bug tracker.

You will need to create a free account to file bugs with any of these bug trackers (except Opera’s Wizard). But it’s a one-time thing, and it’s useful because it allows you to easily track bugs that you’ve reported.

All of the browsers’ bug trackers are public, with one exception: Opera’s. You can report Opera bugs through the public form I linked to above, but to access the BTS and to discuss your bug and monitor its progress, you will need to become an Opera volunteer (or an employee!) and sign an NDA. Volunteering is by invitation only, but if you submit a lot of good bug reports, there’s a good chance you’ll be invited.

Filing A Good Bug Report

The most important part of a good bug report (and the one most commonly done wrong) is the reduction. Hopefully, you’ve done that already, so the hardest part is over with. The rest probably won’t take you more than five minutes.

Providing a Good Summary

A good summary is the second-most important part of a bug report. Don’t be afraid to be verbose, if it actually adds something (don’t just babble). To take one from an actual report,

Background image disappears when body{display:table} is used (common CSS hack for correct centering + scrolling in Firefox)

… is better than “Background image disappears when body{display:table} is used,â€� which in turn is better than “Disappearing background image.â€� Of course, all three are better than “CSS broke. Please fix!!!!11â€�

Sometimes you may want to add keywords to the beginning of the summary to make the report more findable. For example, if your bug is about CSS3 gradients, you could prepend the summary with “[css3-images].â€� To get an idea of the exact tags used in a module, look at other bug reports. It will usually be the same as the id of the specification, which is located at the end of its URL path. For example, for the CSS3 module “Backgrounds and Borders,â€� the URL is http://www.w3.org/TR/css3-background/, and the spec’s id is css3-background. Also, these summary “tagsâ€� can be OS-specific. For example, if your bug is reproducible only in Mac OS X, then prepend your summary with “[Mac].â€� If the bug is about something that used to work fine in previous versions, then prepend your summary with “[Regression],â€� or add “regressionâ€� as a keyword if the BTS has such a feature.

Categorizing the Bug

The category to which your bug belongs is usually quite obvious, provided you take a few seconds to check them all. For CSS bugs, these are the most common candidates:

• Internet Explorer: “CSS and HTMLâ€�;
• Firefox: “Style System (CSS),â€� all the “Layoutâ€� components;
• Opera Wizard: “Web page problemâ€�;
• Webkit: “CSS, Layout and Renderingâ€�;
• Chrome: doesn’t let you categorize bugs (its developers do it for you).

John Resig suggests some ways to categorize JavaScript bugs.

Other Fields

• You can be as verbose in the “Descriptionâ€� field as you need to be. Explain the bug in detail (what you expected to see, what was actually displayed, etc.) and any interaction needed to reproduce it. Then mention any workarounds you found, how other browsers handle the case, and any other notable observations. But don’t start babbling about what you were doing when you discovered the bug, no matter how funny or interesting you think it is. QA time is precious; please don’t waste it with irrelevant detail.
• The “Productâ€� will usually be “Core.â€� If you have a choice between “Coreâ€� and the browser’s name, choose “Core,â€� because bugs filed under the browser’s name are usually for the UI.
• Regarding “Platformâ€� and “OS,â€� try to test in other operating systems if you can. (You do test your websites in different operating systems, right?) If the bug is reproducible in all OS’, then select “All.â€� If it’s reproducible in only one, then mention that in your description and/or summary.
• Avoid changing the “Severityâ€� or “Priorityâ€� fields, because you will tend to overestimate.
• Most people who report bugs don’t fill in the “CCâ€� field. But if you know someone who works for a given browser vendor, especially someone who frequently replies to similar bug reports (browse the reports if you’re not sure), then cc’ing them might help the bug get noticed more quickly. In some cases, this could mean the difference between a bug report getting noticed in a few days and one going unnoticed for months.
• If you have the time to take a screenshot, by all means do so, especially if the bug is reproducible in only one OS.

What Not to Do

Never, ever report multiple bugs in the same report. Handling these is very hard for browser developers. Think about it: what status should they assign to a report if they fix one bug, but the other turns out to be a duplicate? Or only one of the two turns out to be a bug? You get the idea.

I can understand that you might be frustrated from having had to deal with that bug, but being rude won’t help. Stay polite, and keep thoughts like “I can’t believe you can’t even get this right, you morons!� to yourself.

Some Examples

Example 1: Reducing the Original Problem, Realizing It Was Your Mistake

While developing twee+, a handy little app for posting long tweets (and my entry in the 10K Apart contest), I found out that even though it worked in mobile Safari for reading, it crashed when you tried to make an edit. I had no idea what might have been causing this, so I made a copy and started reducing. After commenting out parts of the JavaScript, I found that if I removed the onresize event handler, the problem stopped occurring. And then it made total sense: I adjust the rows of the textarea when the user resizes the window. However, in Mobile Safari, this triggered a resize event, resulting in a dreaded infinite loop. So I removed the resize event handler for mobile. It’s not like the user can resize the window there anyway.

Example 2: Making a Reduction From Scratch, Filing a Bug

A big part of my upcoming CSS3 workshop in Amsterdam is hands-on challenges. Attendees will download my slide deck (which is essentially an HTML + CSS + JavaScript app) and try to solve some 5- or 10-minute challenges on everything taught. A challenge slide would look like this:

I prepared a lot of the slides in Chrome. When I opened them in Firefox, I was greeted with this ugly sizing of the textarea:

In this case, I didn’t follow the reduction process laid out above, because I had a hunch that the bug was related to the way I sized the textarea. So, I fired up JSFiddle and made this simple example, in which the bug could still be reproduced. I then tested it in Opera and observed that it behaved like Firefox, so it was probably Webkit that was buggy. I tested it in the Webkit nightlies and saw that it hadn’t yet been fixed.

Before going any further, I tried to see whether the bug was more generic. Does it happen only with textareas or with all replaced elements? I went ahead and tested <img> and <input> and found that it happens only with form fields. I did another test to see whether it also happened with top/bottom rather than left/right. It did not. I also tested on Windows, and it’s reproducible there as well.

The specification confirmed that it was indeed a bug: “The used value of ‘width’ and ‘height’ is determined as for inline replaced elements.� After a bit of searching on Google, I found this blog post, which describes the bug but does not mention an official bug report. So, I searched Webkit’s bug tracker for “textarea absolute,� “textarea positioned� and “input positioned� and couldn’t find anything relevant. It was bug-reporting time!

I went ahead and created this bug report. Let’s hope it goes well.

What Happens Next?

At some point, usually after a few days or weeks, someone will modify your bug’s status. If it turns out to be a “duplicate,� don’t feel bad: it happens to the best of us, even employees of the browser vendors themselves. If the status gets “confirmed� (usually with the status “new�), this is a good indication that it is indeed a bug and that you did the right thing by reporting it. Last but not least, if the new status is “assigned,� it means someone is actively working on the issue (or plans to do so soon), so it has a high chance of getting fixed soon.

When your bug gets a status of “resolved,� check the “resolution� field. If it says “wontfix,� it means that they’re not planning to rectify the issue, for reasons usually stated in detail in an accompanying comment. The reason is usually either that it’s not a bug (in which case, the most appropriate resolution status is “invalid�) or that they just don’t want to work on it for the time being. If the latter, you could argue your case and explain why the bug is important, but don’t get your hopes up. Last but not least, if it’s “fixed,� you can congratulate yourself on doing your part to make the Web a better place.

Further Reading

• “A Web Developer’s Responsibility,â€� John Resig
• “Test Case Reduction,â€� Webkit
• “The Most Important Field in a Bug Report: The Summary,â€� David Baron
• “How to Submit Good Bug Reports,â€� Opera
• “How to Submit a Good Bug Report,â€� Internet Explorer

Thanks a lot to David Storey, Divya Manian, Paul Irish, Elika Etemad and Oli Studholme for their helpful tips and reviews.

Front Cover: Image source

(al)

© Lea Verou for Smashing Magazine, 2011.

It’s a pretty safe bet to say that the vast majority of people like movies. They’re usually entertaining and sometimes even informative or thought-provoking. But most designers probably don’t pay too much attention to how they might be able to offer inspiration for website or other designs.

But most movies, especially those with large budgets, have extensive art direction and production design happening to make sure the entire look of the movie is exactly the way the screenwriter and director have envisioned it. Whether it’s a fantasy film, a family movie, a historical drama, or anything in between, there’s a good chance that a team of dozens of people worked hard to make sure the visual design of the film was absolutely perfect.

Below are a number of popular films from the past few years. Many of these have won awards for their art direction and production design, but not all of them have. In addition to the stills included below, try to watch some or all of these films with an eye on the design of the sets and costumes, as well as how the characters interact with them.

Harry Potter and the Deathly Hallows: Part 1

Harry Potter and the Deathly Hallows: Part 1 (also referred to as Harry Potter 7) had some phenomenal art direction. It was nominated for an Academy Award for Best Art Direction in 2010.

In this image, there are a few different design principles going on. First of all, it’s a beautiful example of asymmetrical balance. The men in the image are considerably larger and darker than Dolores Umbridge in this shot. But the pink of Umbridge’s dress gives her more visual impact, balancing out the men in the image.

Speaking of the pink of Umbridge’s dress, that’s another great design element. Because of Umbridge’s undeniably evil nature, the pink is a surprising choice. These kinds of unexpected choices add interest and irony to the production design, and can be applied to any kind of design.

The last design element in this particular shot, and one that almost goes unnoticed, is the pattern in the floor. The circular nature of the flooring creates a natural flow and directs the viewer’s eye from right to left. Flow like this is an important element that indicates to your visitors where they should be looking on the page and helps control their interaction and user experience.

This still of the Weasley twins offers some ideas that aren’t often discussed in terms of web design, but can add a lot more visual interest to your designs. The main take-away from this image is the idea of repetition, but with subtle changes made. The twins are identical, visually the same, and yet there are subtle differences in their costumes and general appearance. The shift in color and pattern, while maintaining the same basic shape and size, adds a lot more visual interest while still maintaining the consistency that repetition provides.

The King’s Speech

Period films, by their very nature, have extra attention paid to the details of their production design, because anything that is out of place can ruin a viewer’s experience by pulling them out of the story. The King’s Speech is no different.

This still from the film is an excellent example of creating priority in an image without going over the top. The entire color palette consists of three basic hues in various shades: brown, gold, and black (with just a hint of white). So how do you make the King stand out in such a muted color scheme?

The answer is simple: you make him slightly lighter and brighter than his surroundings. This is an easy one to accomplish in web design, and goes to show that you don’t need something to be jarring in order to draw attention to it. Using a highlight color that still blends seamlessly into the rest of your palette for the most important element in your design sets it apart while still remaining elegant and understated.

Pride and Prejudice

There have been a number of adaptations of this novel by Jane Austen, but I’m going to focus on the one from 2005 with Keira Knightley and Donald Sutherland. This film had fantastic production value, perfectly capturing the mood of the novel.

The first thing Pride and Prejudice can teach us about is contrast. And particularly how contrast and color can contribute to our perception of things and the mood created. In this particular scene, Mr. Darcy is shown wearing almost entirely black, while Lizzy is in a white, flowing dress. It creates stark contrast between their characters, painting Darcy as the villain while Lizzy is pegged as the heroine. This example of color and contrast is a simple, yet effective, way of creating a positive/negative relationship.

By the end of the film, though, Darcy’s costumes have lightened considerably, while Lizzy’s have darkened. Basically, their characters have now arrived at the same place. Here, the lesson is that reducing the contrast creates harmony between potentially conflicting elements.

Alice in Wonderland

Tim Burton’s reimagining of Alice in Wonderland won the Academy Award for Art Direction in 2010, and rightfully so. It’s a masterpiece of visual design, and used a surprising number of practical set elements, rather than just CGI.

If there’s one thing that Alice in Wonderland can teach us about design, it’s not to be afraid to play with the scale and size of elements. Alice changes size numerous times throughout the film, often requiring interesting alterations to her costumes. Other characters, namely the Queen of Hearts, have disproportionately large body parts. The results in every case are stunning, and show the potential of unexpected scale. In your website designs, consider creating very large or very small elements that can surprise your visitors.

This still from the film has important lessons about working with complex, busy designs. The background elements in this particular shot are very busy, but through creative use of lighting, the focus is placed squarely on Alice and the direction in which she’s going. This makes it easy for viewers to know where they should direct their attention, and keeps the busy design from feeling overwhelming. Clear direction like this is invaluable in web design, and can be created by placement of elements, color choices, and scale.

Sweeney Todd: The Demon Barber of Fleet Street

Sweeney Todd is another Tim Burton film, and won the Academy Award for Best Art Direction in 2007.

The biggest lesson Sweeney Todd can teach us is the importance of mood in a design. Throughout the entire film, the mood is kept consistent through the use of various design elements. In this case, the mood is macabre and run-down, and is established through the use of dull, lifeless colors and dark lighting. There are very few flashes of color (and most of them are from blood). The result is a film that is completely immersive and draws the viewer in. It wouldn’t have been nearly as effective if the sets had been more typical of period pieces, or if brighter colors had been used throughout the set designs.

Regardless of what mood you want to establish with your site, making conscious choices throughout the design that establish and reinforce that mood will certainly result in a more immersive experience for your visitors. It also strongly influences how your audience will feel about the site, and whatever that site is offering, whether it’s selling a product or providing information.

There Will Be Blood

There Will Be Blood is another Academy Award nominated film for Best Art Direction, from 2007.

This particular shot from There Will Be Blood shows us a lot about the importance of what isn’t there, and how it reacts with what is. White or negative space in a design is just as important as any other design element, and yet it’s often overlooked or not used as well as it could be.

Note here how the character, Daniel, interacts with the negative space created by the blue sky. There’s no clear delineation between the occupied space and the negative space because of the way he bridges the two.

Another prominent feature here is the contrast created by the muted greens and browns of the main elements in the scene and the blue of the sky. But even though the blue contrasts the rest of the scene, there’s still a muted quality to it which ties everything together.

The Imaginarium of Doctor Parnassus

The Imaginarium of Doctor Parnassus is a whimsical, off-beat film with lots of set changes, costume changes, and even actor changes. It was also Heath Ledger’s final onscreen performance.

The biggest thing we can learn, as designers, from this film is not to disregard the importance of a sense of whimsy. The scenes from inside the Imaginarium are off-the-wall and unexpected (if not a bit creepy at times). They had no problem trying new things, and blending elements that might not normally be included together.

Water for Elephants

Water for Elephants is another period piece, this time set in the early part of the 20th century.

The main thing this image can show us is how to use different textures to create contrast between elements. Jacob’s costume and props are all rough materials: leather, burlap, and denim. In contrast, Marlena’s dress is satin, the opposite of everything Jacob is wearing. It reinforces the differences between them. Texture is relatively easy to incorporate into website designs, but is often only there to provide visual interest. Consider using it, instead, as an integral part of the page’s design, one that provides visual clues to the relationships between different elements.

The Chronicles of Narnia: The Voyage of the Dawn Treader

The third installment of The Chronicles of Narnia series, based on the books of the same name, was released in 2010.

This image is another great example of how to handle visually complex designs. There’s a lot going on here, between the background and foreground elements, the characters, and the lighting effects, but it’s all made less overwhelming by the use of a clear focal point. Lilliandil is cast in a circle of light, making her significantly brighter than her surroundings. The light orbs in the rest of the image reinforce her position as the focus of the scene.

Make sure that any complex design you create has a clear focal point. This provides grounding for your visitors: they know where they’re supposed to be looking. It gives clear purpose to your design, allowing you to create a design that is rich and visually complex without being cluttered.

Stardust

Stardust, based on the Neil Gaiman graphic novel and novel of the same name, was released in 2007.

This still from the film has a few lessons to teach us. First of all is the Golden Ratio (which is similar to the rule of thirds, but places important elements just a bit closer to the center than the rule of thirds does). Tristran and the gap in the stone wall are both positioned almost perfectly in regard to the Golden Ratio in this image. The right-hand side of the wall is also positioned along the Golden Ratio, which lends further balance to the composition. Using the Golden Ratio in your own layouts creates a more balanced and harmonious design.

Another element here is the angle of the stone wall. It leads our eye further into the image, creating a sense of depth and motion. The same can be done through the use of perspective and lines in your designs. It adds a more dynamic layer to your designs, giving a sense of energy that’s often missing.

Star Trek

The JJ Abrams reboot of the Star Trek franchise has been polarizing to say the least. But the set and costume designs used were undeniably well done.

This may sound a bit too simple, but one of the biggest things Star Trek can teach us is not to be afraid of a white background. Throughout the film, white sets on the Enterprise are prominent. What this does is allow the important elements—the characters and the action—stand out.

Now, that doesn’t mean that the backgrounds are just plain, stark white. There’s still a lot going on there. Take that as your cue to play with texture and pattern, while maintaining a light and neutral background color.

Monsters

Monsters was an indie movie set and filmed in Mexico. There are a couple of important things it can teach us about good design.

Designers tend to shy away from splitting their designs right down the middle, or putting the focal point of a design right in the middle, with little else on either side. This still from Monsters, though, shows us just how much impact that technique can have. When you want to make a statement with your design, creating a more symmetrical layout with your focal point right in the center can be a powerful way to do so.

Another thing that Monsters teaches us, that’s harder to capture from a movie still, is that hinting at things can be just as powerful as showing us something outright. Throughout the film, the Monsters are rarely seen or even heard from, which creates a sense of suspense—we know they’re out there, but we don’t know where or when they might attack. A similar sense of suspense and mystery can be applied to your designs in various ways.

Defiance

Defiance is set in Germany during WWII.

This still from Defiance shows us the impact that creating a sense of motion around a stationary focal point makes that focal point stand out more. At the same time, the motion keeps the design from feeling stagnant, as can happen when the focal point is too strong without much happening around it.

Conclusion

If there’s one thing film art direction can teach us, it’s that paying attention to all the little details in a design can have a big payoff in the end. Would Alice in Wonderland have won an Oscar for Best Art Direction if so much effort had not been put into the look and feel of the film? Certainly not. The same can be said of any of the others above.

The next time you watch a film, look carefully at the background sets, the costume choices, and even the lighting of each scene. Look at the mood it creates, and how sometimes unexpected elements can offer a lot of extra visual impact and irony to the overall production. Then think of ways to incorporate the same kinds of things into your own designs.

(rb)

One of the news in HTML5 is that links are now allowed to contain block level elements. In HTML 4, only inline elements are allowed.

Linking block level elements such as headings and paragraphs can be useful, but there are some things to be aware of in order to avoid reducing the usability and accessibility of such links to screen reader users.

Read full post

Posted in Accessibility, HTML 5.

Copyright © Roger Johansson