Building a New Image Format

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

There’s now a newcomer to the stable of images we use for web development. It’s the WebP Image Format (see https://developers.google.com/speed/webp/)

WebP’s goal is to surpass compression file sizes of photographs—a role usually reserved by JPEG. But this JPEG clone has a special talent: animation! So, in essenece, the WebP image format is a hybrid of the GIF and JPEG file format.

The downside to new image formats is their historically slow adoption rate. While transparency support in the PNG format is an obviously amazing benefit for any web designer, Internet Explorer took about four years to support it after the other major browsers did. As of this writing, Mozilla is not yet supporting the WebP format. The benefits of WebP image format seems to merely replace existing features of the GIF and JPEG formats without adding anything new of substance, while it brings in a host of browser compatibility headaches for web designers and developers that could last years.

There are 20+ polyfills for adaptive images with their pros and cons, a couple of which I’ve had a hand in writing. But all these solutions are not solving the real problem. And that problem is that today’s popular raster image formats—PNG, JPEG, GIF—can’t be both low resolution and high resolution at the same. We need an image file format that is, in essence, a storage locker.

Storing Resolutions

The popular .mp3 file format isn’t just any bits of ones and zeros detailing music. It’s actually a meta data information inside an audio tag. This is where, for example, in iTunes record song information like song title, artist, album title, year the song came out and so on.

We need to have a file format for images that’s similar. Instead of capturing meta information for the image, we store different variations of the image. One “image” file might be able to contain a thumbnail image, a mobile friendly image, desktop friendly version, retina display version, and print-friendly image. This responsive image format isn’t something that’s a dream. An image file format already exists that does this called FlashPix.

Developed in 1996 by partners like Eastman Kodak, Micrsofot and Hewlett-Packard, the image file format was ahead of its time.

Benefits of Responsive Image Format

A responsive image format allows the continued use of the img element which is ingrained into the bones, the very marrow, of the Web. There isn’t a need to craft multiple lines of HTML to make one image show up in a web page. Secondly, there’s a simple reason why strict coding styles of XHTML was abandoned and loose HTML4 coding practices were instilled into HTML5—95% of websites don’t validate.

Asking web designers, bloggers, and non-techies to create multiple versions of their images in order to appease every Android, iOS device and desktop browser seems not only like a very non-standards approach, it’s also not a very practical one. Content producers that work with the web at least a little bit know the fundamental one-to-one aspect when it comes to publishing images on the web: one img element somewhat coded correctly results in one image showing up in the browser.

If we go with a solution born from the kin of video and audio elements–where we do need to balance differing file supoprt due to the browser venders’ turf wars and licensing issues, I believe we surrender a bit of the Open Web mentality for not much gain.

Content Publishers That Don’t Code

Another issue is that with a method for inserting images with additional markup means there needs to be widespread change in WYSIWYG editors, their respetive tool bars in Content Management Systems, updated old web pages. That simply is not going to happen. There need something on mini-Y2K levels (see http://www.computerworld.com/s/article/9142555/Y2K_The_good_the_bad_and_the_crazy) to get companies and organizations to start spending that sort of capital to fix the issue. And while retina display is cool, I don’t think this issue rises to that level of concern of blink red light, mission critcial as Y2K did for businesses and governments all over the world.

Save Once, Images Everywhere

If given a choice, I believe web designers would rather export one piece of artwork from Fireworks, Photoshop or whatever their favorite image editor of choice happens to be and then let the software compile multiple resolutions into one container file. This container file can then be stored on a server and referenced via an img element in an HTML page. The simple <img> got us this far and it hasn’t failed us yet. Let’s look to make image formats work smarter, work better by building smarter browsers and servers.

The web needs an image format that, when asked by a browser the server would deliver the right image that contains the right resolution. We need an image format that can work in tandem with server and browser to determine the approprirate resolution. A new image format for web design isn’t impossible. It just feels like that sometimes.

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

JavaScript Devs: Be Careful With Comparison Operators

The results of type coercion in JavaScript can be difficult to predict, even when you know the rules. In this post, we will see how subtle differences in comparisons, can lead to significant changes in the results. Be careful when relying on 'truthyness' for logic. Whenever possible, use comparison operators to clarify your meaning. 'Falsy' values include:

0
undefined
null
empty strings
false

CAUTION - Boolean objects instantiated with new Boolean(false) are 'truthy' because they're objects, and objects are truthy! In order to test against them, you need to use the .valueOf() method. It's better in almost all cases to use true and false, instead.

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

Empty objects and empty arrays are truthy, including objects created with new Boolean(false).

Wrong: Don't use new Boolean()

var myBool = new Boolean(false);
test('Boolean object', function () {
  ok(!myBool, 'Should be falsy'); // Fails
  ok(!myBool.valueOf(),
    'Should be falsy.'); // Passes
});

Right: Use true or false in your boolean declarations

var myBool = false;
test('Boolean object', function () {
  ok(!myBool, '!myBool should be false.');
});

The following series of tests are meant to demonstrate how different types of comparisons in JavaScript that look similar can deliver very different results.

Always be careful that you're using the correct test for your situation:

function truthy(x) {
  if (x) {
    return true;
  } else {
    return false;
  }
}

test('Truthy', function () {
  // Falsy
  equal(truthy(0), true, 'truthy(0)'); // Fail
  equal(truthy(''), true, "truthy('')");  // Fail
  equal(truthy(null), true, 'truthy(null)'); // Fail
  equal(truthy(undefined), true,
    'truthy(undefined)'); // Fail
  equal(truthy(false), true, 'truthy(false)'); // Fail
  // Truthy
  equal(truthy('0'), true, "truthy('0')"); // Pass
  equal(truthy(new Boolean(false)), true,
    'truthy(new Boolean(false))'); // Pass
  equal(truthy({}), true, 'truthy({})'); // Pass
  equal(truthy([]), true, 'truthy([])'); // Pass
  equal(truthy([0]), true, 'truthy([0])'); // Pass
  equal(truthy([1]), true, 'truthy([1])'); // Pass
  equal(truthy(['0']), true, "truthy(['0'])"); // Pass
  equal(truthy(['1']), true, "truthy(['1'])"); // Pass
});

These are the falsy and truthy values we'll use as a baseline for a series of other comparisons.

CAUTION - Often, developers will use if (x) when they really want to see if the value has been set at all. This is especially problematic when 0, empty strings, or false are valid values. In that case, you want the test to pass as long as the expression evaluates to anything other than null or undefined. A good rule of thumb is to only use if (x) to evaluate booleans or the existence of objects or arrays.

function exists(x) {
  if (x !== undefined && x !== null) {
    return true;
  } else {
    return false;
  }
}

test('exists', function () {
  // Falsy
  equal(exists(0), true, 'exists(0)'); // Pass
  equal(exists(''), true, "exists('')"); // Pass
  equal(exists(null), true, 'exists(null)');
  equal(exists(undefined), true, 'exists(undefined)');
  equal(exists(false), true, 'exists(false)'); // Pass
  // Truthy
  equal(exists('0'), true, "exists('0')"); // Pass
  equal(exists(new Boolean(false)), true,
    'exists(new Boolean(false))'); // Pass
  equal(exists({}), true, 'exists({})'); // Pass
  equal(exists([]), true, 'exists([])'); // Pass
  equal(exists([0]), true, 'exists([0])'); // Pass
  equal(exists([1]), true, 'exists([1])'); // Pass
  equal(exists(['0']), true, "exists(['0'])"); // Pass
  equal(exists(['1']), true, "exists(['1'])"); // Pass
});

Of course, a shorter version of that function will return the same results:

function exists(x) {
  return (x !== undefined && x !== null);
}

CAUTION - The == operator can return some problematic results due to type coercion.

For example, say you're checking an array to be sure it contains a valid price, and some items cost $0.00. Your code could fail because ['0.00'] == false. Use === instead.

var isFalse = function isFalse(x) {
  return (x == false);
};

test('isFalse using ==', function () {
  // Falsy
  equal(isFalse(0), true, 'isFalse(0)'); // Pass
  equal(isFalse(''), true, "isFalse('')"); // Pass
  equal(isFalse(null), true, 'isFalse(null)'); // Fail
  equal(isFalse(undefined), true, 'isFalse(undefined)'); // Fail
  equal(isFalse(false), true, 'isFalse(false)'); // Pass

  // Truthy
  equal(isFalse('0'), true, "isFalse('0')"); // Pass
  equal(isFalse(new Boolean(false)), true,
    'isFalse(new Boolean(false))'); // Pass
  equal(isFalse({}), true, 'isFalse({})'); // Fail
  equal(isFalse([]), true, 'isFalse([])'); // Pass
  equal(isFalse([0]), true, 'isFalse([0])'); // Pass
  equal(isFalse([1]), true, 'isFalse([1])'); // Fail
  equal(isFalse(['0']), true, "isFalse(['0'])"); // Pass
  equal(isFalse(['1']), true, "isFalse(['1'])"); // Fail
});

The following code will only return true if x is actually set to false:

var isFalse = function isFalse(x) {
  return (x === false);
};

The following function is dangerous, because it will return true for 1, [1], and ['1'].

var isTrue = function isTrue(x) {
  return (x == true);
};

Use === instead to eliminate the possibility of false positives.

Remember that if (x) will always return true when x is an object -- even if the object is empty. It's common to use ducktyping when you examine objects. (If it walks like a duck and talks like a duck, treat it like a duck.) The idea is similar to using feature detection in browsers, instead of running checks against the browser string. Ducktyping is feature detection for objects.

if (typeof foo.bar === 'function') {
  foo.bar();
}

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

Why are Deferred Objects So Useful

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

Deferred objects are useful when you want to execute functions at the end of some task without having to monitor that task directly, especially when that task is being performed in the background. The code below contains a demonstration, which I’ll then start to modify to add features. It's about using Callbacks with a Long-Lived Task

...
<script type="text/javascript">
$(document).ready(function() {
var def = $.Deferred();
def.done(function() {
displayMessage("Callback Executed");
})
function performLongTask() {
var start = $.now();
var total = 0;
for (var i = 0; i < 500000000 ; i++) {
total += i;
}
var elapsedTime = (($.now() - start)/1000).toFixed(1)
displayMessage("Task Complete. Time: " + elapsedTime + " sec")
def.resolve();
}
$('button').button().click(function() {
displayMessage("Calling performLongTask()")
performLongTask()
displayMessage("performLongTask() Returned")
})
displayMessage("Ready")
})
function displayMessage(msg) {
$('tbody').append("<tr><td>" + msg + "</td></tr>")
}
</script>
...

The process in this example is defined by the performLongTask function, which adds together a series of numbers. I want something simple that takes a few seconds to complete, and this fits the bill.

Tip: On my system, the for loop in the performLongTask function takes about 3.5 seconds to complete, but you may need to adjust the upper limit for the loop to get a similar result on your system. Three to four seconds is a good duration for these examples. It’s long enough to demonstrate the deferred object features but not so long that you have time to make coffee while waiting for the task to complete.

Clicking the button now calls the performLongTask function. That function calls the deferred object’s resolve method when its work is complete, causing the callback function to be invoked. The performLongTask function adds its own message to the table element before it calls resolve, so you can see the sequence of progression through the script. You can see the results:

This is an example of a synchronous task. You push the button, and then you have to wait while each function that you call completes. The best indicator that you are working synchronously is the way that the Go button stays in its pressed state while the performLongTask function does its work. Definitive proof comes in the sequence of messages displayed in the image shown here. The messages from the click event handler come before and after the messages from performLongTask and the callback functions.

The major benefit of deferred objects comes when you are working with asynchronous tasks, tasks that are being performed in the background. You don’t want the user interface to lock up like it did in the previous example, so you start tasks in the background, keep an eye on them, and update the document to give the user information about the progress and result of the work.

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

The simplest way to start a background task is to use the setTimeout function, which means that you are using yet another callback mechanism. This may seem a little odd, but JavaScript lacks the language facilities for managing asynchronous tasks that other languages are designed with, so you have to make do with those features that are available. The code shows the example modified

...
<script type="text/javascript">
$(document).ready(function() {
var def = $.Deferred();
def.done(function() {
displayMessage("Callback Executed");
})
function performLongTask() {
setTimeout(function() {
var start = $.now();
var total = 0;
for (var i = 0; i < 500000000 ; i++) {
total += i;
}
var elapsedTime = (($.now() - start)/1000).toFixed(1)
displayMessage("Task Complete. Time: " + elapsedTime + " sec")
def.resolve();
}, 10);
}
$('button').button().click(function() {
displayMessage("Calling performLongTask()")
performLongTask()
displayMessage("performLongTask() Returned")
})
displayMessage("Ready")
})
function displayMessage(msg) {
$('tbody').append("<tr><td>" + msg + "</td></tr>")
}
</script>
.....

I use the setTimeout function to perform the for loop in the performLongTask function after a delay of 10 milliseconds. You can see the effect this has in the image below. Notice that the messages from the click handler function appear before those from the performLongTask and callback functions. If you run this          example yourself, you will notice that the button pops back into its regular state immediately, rather than waiting for the work to complete.

Callbacks are particular important when working with background tasks because you don’t know when they are complete. You could set up your own signaling system—updating a variable, for example—but you would need to do this for every background task that you perform, which becomes tiresome and error-prone very quickly. Deferred objects allow you to use a standardized mechanism for indicating that tasks have completed, and as I’ll demonstrate in later examples, they offer a lot of
flexibility in how this is done.

Can we do better?

Before you start digging into the feature of deferred objects, I am going to update the example to use the pattern that I tend to work with in real projects. This is purely personal preference, but I like to split out the workload from the asynchronous wrapper and integrate the production of the deferred object into
the function. The code shows the changes.

<!DOCTYPE html>
<html>
<head>
<title>Example</title>
<script src="jquery-1.7.js" type="text/javascript"></script>
<script src="jquery-ui-1.8.16.custom.js" type="text/javascript"></script>
<link rel="stylesheet" type="text/css" href="styles.css"/>
<link rel="stylesheet" type="text/css" href="jquery-ui-1.8.16.custom.css"/>
<style type="text/css">
td {text-align: left; padding: 5px}
table {width: 200px; border-collapse: collapse; float: left; width: 300px}
#buttonDiv {text-align: center; margin: 20px; float: left}
</style>
<script type="text/javascript">
$(document).ready(function() {
function performLongTaskSync() {
var start = $.now();
var total = 0;
for (var i = 0; i < 500000000 ; i++) {
total += i;
}
var elapsedTime = (($.now() - start)/1000).toFixed(1)
displayMessage("Task Complete. Time: " + elapsedTime + " sec")
return total;
}
function performLongTask() {
return $.Deferred(function(def) {
setTimeout(function() {
performLongTaskSync();
def.resolve();
}, 10)
})
}
$('button').button().click(function() {
if ($(':checked').length > 0) {
displayMessage("Calling performLongTask()")
var observer = performLongTask();
observer.done(function() {
displayMessage("Callback Executed");
});
displayMessage("performLongTask() Returned")
} else {
displayMessage("Calling performLongTaskSync()")
performLongTaskSync();
displayMessage("performLongTaskSync() Returned")
}
})
$(':checkbox').button();
displayMessage("Ready")
})
function displayMessage(msg) {
$('tbody').append("<tr><td>" + msg + "</td></tr>")
}
</script>
</head>
<body>
<h1>Jacqui's Flower Shop</h1>
<table class="ui-widget" border=1>
<thead class="ui-widget-header">
<tr><th>Message</th></tr>
</thead>
<tbody class="ui-widget-content">
</tbody>
</table>
<div id="buttonDiv">
<button>Go</button>
<input type="checkbox" id="async" checked>
<label for="async">Async</label>
</div>
</body>
</html>

In this example, I have broken out the workload into a function called performLongTasksync, which is just responsible for performing the calculations. It has no knowledge of background tasks or callback functions. I like to keep the workload separate because it makes testing the code easier during the early stages of development. Here is the synchronous function:

function performLongTaskSync() {
var start = $.now();
var total = 0;
for (var i = 0; i < 500000000 ; i++) {
total += i;
}
var elapsedTime = (($.now() - start)/1000).toFixed(1)
displayMessage("Task Complete. Time: " + elapsedTime + " sec")
return total;
}

I have separated out the code to perform the task asynchronously. This is in the performLongTask function, which is an asynchronous wrapper around the  performLongTasksync function and which uses a deferred object to trigger callbacks when the work has completed. Here is the revised performLongTask function:

function performLongTask() {
return $.Deferred(function(def) {
setTimeout(function() {
performLongTaskSync();
def.resolve();
}, 10)
})
}

If pass a function to the Deferred method, it is executed as soon as the object is created, and the function is passed the new deferred object as a parameter. Using this feature, I can create a simple wrapper function that performs the work asynchronously and triggers the callbacks when the work has finished.

If you are observant, you will have noticed that there is a chance that calling the done method to register a callback function may occur after the task has been completed and the resolve method has been called. This may occur for very short tasks, but the callback function will still be called, even if done is called after resolve.

The other reason that I like to create a wrapper like this is because deferred objects can’t be reset once they are resolved or rejected (I explain rejection in a moment). By creating the deferred object inside of the wrapper function, I ensure that I am always using fresh, unresolved deferred objects. The other change I have made to this example is to add a toggle button that allows the task to be performed synchronously or asynchronously. I will take this feature out of future examples  because this is an article about asynchronous tasks, but it is a good way to make sure you are comfortable with the difference. You can see the output from both modes

References:  Wrox Professional jQuery

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.