Thursday, September 20, 2012

To Carousal or Not

In an effort to squeeze more content on web pages, designers sometimes turn to novel navigation features such as carousels that advance or rotate objects in a fixed space. These are great for displaying related products or showing facets of the same product, such as pants presented in different colors or with different tailoring options (cuffed or not, straight vs. relaxed cut, etc.). Some carousels are relatively simple slide-show-like implementations, while others present selectable objects in a 3-D, circular view.

For ThanksGiving, I am offering 5 exclusive website templates for just $3.99. Purchase Here.



This carousel, used on Amazon.com, effectively displays related products within a small space.  It clearly communicates the total number of pages or items available.

When using novel interaction such as a carousel, web site designers and content writers need to remember usability basics such as reinforcing a sense of place and keeping users in control. For example, common usability problems we have seen with carousels include:

1. Users can easily lose track of what they have previously viewed when sites do not display how many items or sets of items exist or their current location within the set.



This type of carousel makes users work harder to remember which items they have previously viewed, especially if items are not visually distinctive or otherwise memorable.

One site we tested displayed content below the carousel when an item was selected. Users were not always aware of which item was selected, and some did not associate the dynamic content with the carousel selection at all.

2. Complex navigation within a carousel can be very problematic. Rich navigation is possible using a carousel model, whereby the carousel changes “pages” that each present their own set of navigation opportunities via links or embedded objects.  We have seen users become lost or miss key messages within this type of navigation scheme.  Interaction designers need to take extra care to convey location and navigation options through labels, headings, and other visual cues.

Tuesday, September 18, 2012

Some IE CSS Tips for Transparency, min-max width and Conditional Comments


You can force IE to apply transparency to PNGs. In theory, PNG files do support varied levels of transparency; however, an Internet Explorer 6 bug prevents this from
working cross-browser.

1. #regular_logo
2. {
3. background:url('test.png'); width:150px; height:55px;
4. }
5. /* \ */
6. * html #regular_logo
7. {
8. background:none;
9. float:left;
10. width:150px;
filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(src='test.
png', sizingMethod='scale');
11.
12. }
13. /* */

You can define min-width and max-width in IE. You can use Microsoft’s dynamic expressions to do that.

1. #container
2. {
3. min-width: 600px;
4. max-width: 1200px;
width:expression(document.body.clientWidth < 600? "600px" :
document.body.clientWidth > 1200? "1200px" : "auto");
5.
6. }

You can use Conditional Comments for IE. The safest way of taking care of IE/Win is to use conditional comments. It feels more future-proof than CSS hacks – is to use
Microsoft’s proprietary conditional comments. You can use this to give IE/Win a separate stylesheet that contains all the rules that are needed to make it behave properly.

1. <!--[if IE]>
2. <link rel="stylesheet" type="text/css" href="ie.css" />
3. <![endif]-->

Posted on 9:35 PM | Categories:

Tuesday, September 11, 2012

The Dys-Functional Specifications


So what's functional about a Functional Spec?

These blueprint docs usually wind up having almost nothing to do with the finished product. Here's why:

Functional specs are fantasies
They don't reflect reality. An app is not real until builders are building it, designers are designing it, and people are using it. Functional specs are just words on paper.

Functional specs are about appeasement
They're about making everyone feel involved and happy which, while warm and fuzzy, isn't all that helpful. They're never about making tough choices and exposing costs, things that need to happen to build a great app.

Functional specs only lead to an illusion of agreement
A bunch of people agreeing on paragraphs of text isn't a true agreement. Everyone may be reading the same thing but they're thinking something different. This inevitably comes out later on: "Wait, that's not what I had in mind." "Huh? That's not how we described it." "Yes it was and we all agreed on it — you even signed off on it." You know the drill.



Functional specs force you to make the most important decisions when you have the least information
You know the least about something when you begin to build it. The more you build it, the more you use it, the more you know it. That's when you should be making decisions — when you have more information, not less.

Functional specs lead to feature overload
There's no pushback during spec phase. There's no cost to writing something down and adding another bullet point. You can please someone who's a pain by adding their pet feature. And then you wind up designing to those bullet points, not to humans. And that's how you wind up with an overloaded site that's got 30 tabs across the top of the screen.

Functional specs don't let you evolve, change,and reassess
A feature is signed off and agreed on. Even if you realize during development that it's a bad idea, you're stuck with it. Specs don't deal with the reality that once you start building something, everything changes.

So what should you do in place of a spec? Go with a briefer alternative that moves you toward something real. Write a one page story about what the app needs to do. Use plain language and make it quick. If it takes more than a page to explain it, then it's too complex. This process shouldn't take more than one day.



Then begin building the interface — the interface will be the alternative to the functional spec. Draw some quick and simple paper sketches. Then start coding it into html. Unlike paragraphs of text that are open to alternate interpretations, interface designs are common ground that everyone can agree on.

Confusion disappears when everyone starts using the same screens. Build an interface everyone can start looking at, using, clicking through, and "feeling" before you start worrying about back-end code. Get yourself in front of the customer experience as much as possible.

Forget about locked-in specs. They force you to make big, key decisions too early in the process. Bypass the spec phase and you'll keep change cheap and stay flexible.