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.

Check out the eBook Promotional Template and 4 other cool Web Design Templates for just $3.99

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

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

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]-->

The Dys-Functional Specifications

If you are a HTML5/CSS/jQuery Web Developer, here's a ThanksGiving Offer

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.

Who came first - Content or Design

Well, I believe that to make good design you should know what content is. It’s because design is about how to deliver content the right way. On the other hand, not only content matters, but also form of delivery, medium (read “design”) could make a competitive advantage, become a key idea of customer’s business.

But, obviously, it’s not about content only, there is user study, context of usage, company possibilities and business interest. All these things should influence design.

Get as much of the content before designing as you can.

I've long believed that real data delivers really effective design. Using actual content, information, and activity throughout the design process to inform and guide decisions results in product designs that scale well and communicate effectively.

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

This philosophy could be thought of as "death to lorem ipsum". Lorem Ipsum, in case you are wondering, is dummy text originally used in the print industry to lay out page designs. It has since been re-appropriated byWeb designers (and worse yet software designers) to lay out Web site and application designs.

Using dummy content or fake information in the Web design process can result in products with unrealistic assumptions and potentially serious design flaws. A seemingly elegant design can quickly begin to bloat with unexpected content or break under the weight of actual activity. Fake data can ensure a nice looking layout but it doesn't reflect what a living, breathing application must endure. Real data does.

It's also important to note that Lorem Ipsum can cause you to make some awful design decisions if you are relying on a certain volume of content that will not actually be there in the end, whether it be too much or too little.

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

The Web and its Open Doors

Don't try to lock-in your customers. Let them get their information when they want it and how they want it. To do that, you've got to give up the idea of sealing in data. Instead, let it run wild. Give people access to their information via RSS feeds. Offer apis that let third-party developers build on to your tool. When you do, you make life more convenient for customers and expand the possibilities of what your app can do.

People used to think of rss feeds as merely a good way to keep track of blogs or news sites. Feeds have more power than that though. They also provide a great way for customers to stay up to date on the changing content of an app without having to log in repeatedly. With Basecamp feeds, customers can pop the URL into a newsreader and keep an eye on project messages, todo lists, and milestones without having to constantly check in at the site.

APIs let developers build add-on products for your app that can turn out to be invaluable. For example, Backpack supplies an API which Chipt Productions used to build a Mac OS X Dashboard widget. The widget lets people add and edit reminders, list items, and more from the desktop. Customers have raved to us about this widget and some have even said it was the key factor in getting them to use Backpack.

Other good examples of companies letting data run free in order to get a boomerang effect:

The Google Maps API has spawned interesting mash ups that let people cull information from another source (e.g. apartment listings) and plot that data on a map.

Linkrolls offer a way for people to get their latest del.icio.us bookmarks displayed on their own sites.

Flickr allows other businesses access to commercial APIs so customers can buy photo books, posters, dvd backups, and stamps. "The goal is to open it up completely and give you the biggest variety of choices when it comes to doing things with your photos," says Stewart Butterfield of Flickr.

Yet Another Post About JavaScript Scopes and Closures

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

When discussing scope it’s important to consider where a variable is defi ned as well as its lifetime.Where is the variable accessible? In the case of JavaScript, scope is maintained at the function level,not the block level. Hence, variables defi ned with the keyword var and parameters are visible only inside the function in question.

A nested function has access to its outer function’s variables, except for this and arguments. The mechanism through which a nested function continues to keep the references of its outer function even after the outer function fi nishes execution is called closure. Closures also help to reduce namespace pollution.


Each time an enclosed function is called, a new scope is created, although the code doesn’t change. The following code shows this behavior.

function getFunction(value){
return function(value){
return value;
}
}
var a = getFunction(),
b = getFunction(),
c = getFunction();
console.log(a(0));
0
console.log(b(1));
1
console.log(c(2));
2
console.log(a === b);
false

When defining a standalone function (not bound to any object), this is bound to the global namespace. As a direct result, when creating an inner function within a method, the inner function’s this variable is bound to the global namespace, not the method. To circumvent this situation, the enclosing method’s this variable is assigned to an intermediate variable called that, by convention.

obj = {};
obj.method = function(){
var that = this;
this.counter = 0;
var count = function(){
that.counter += 1;
console.log(that.counter);
}
count();
count();
console.log(this.counter);
}
obj.method();
1
2
2

Organize your CSS Code

Are you a HTML5/CSS/jQuery Web Developer? Check out these templates

Organizing your CSS helps with future maintainability of the site. Start with a master style sheet. Within this style sheet import your reset.css, global.css, flash.css (if needed) and structure.css and
on occasion a typography style sheet. Here is an example of a “master” style sheet and how it is embedded in the document:

1. h2 { }
2. #snapshot_box h2 {
3. padding: 0 0 6px 0;
4. font: bold 14px/14px "Verdana", sans-serif; }
5. #main_side h2 {
6. color: #444;
7. font: bold 14px/14px "Verdana", sans-serif; }
8. .sidetagselection h2 {
9. color: #fff;
10. font: bold 14px/14px "Verdana", sans-serif; }

Organize your CSS-styles, using flags. “Divide your stylesheet into specific sections: i.e. Global Styles – (body, paragraphs, lists, etc), Header, Page Structure, Headings, Text
Styles, Navigation, Forms, Comments, Extras

/* -----------------------------------*/
/* ---------->>> GLOBAL <<<-----------*/
/* -----------------------------------*/

Organize your CSS-styles, making a table of contents. At the top of your CSS document, write out a table of contents. For example, you could outline the different
areas that your CSS document is styling (header, main, footer etc). Then, use a large, obvious section break to separate the areas.

Organize your CSS-styles, ordering properties alphabetically. “I don’t know where Igot the idea, but I have been alphabetizing my CSS properties for months now, and
believe it or not, it makes specific properties much easier to find.”

1. body {
2. background:#fdfdfd;
3. color:#333;
4. font-size:1em;
5. line-height:1.4;
6. margin:0;
7. padding:0;
8. }

Separate code into blocks.. “This might be common sense to some of you but sometimes I look at CSS and it’s not broken down into “sections.” It’s easy to do an it
makes working with code weeks, months, or years later much easier. You’ll have an easier time finding classes and elements that you need to change. Examples: /*
Structure */, /* Typography */ etc.” 

Hook, line, and sinker. Once you have your CSS and sections in place start considering where your selector “hooks” will live by using structural hooks in your mark up. This is
your saving grace for future editing and maintenance of the site. This will also give youstrength in your document.”

Break your style sheet in separate blocks. “I break down my style sheet into three separate blocks. The first is straight element declarations. Change the body, some links
styles, some header styles, reset margins and padding on forms, and so on. […] After element declarations, I have my class declarations; things like classes for an error
message or a callout would go here. [..] I start by declaring my main containers and then any styles for elements within those containers are indented. At a quick glance, I can see
how my page is broken down and makes it easier to know where to look for things. I’ll also declare containers even if they don’t have any rules.”