Advertise here via BSA

Like webfonts, responsive design wasn’t something you heard much about until CSS3 specs started making it into popular browsers. Now, it’s the cool thing to do, and for good reason — it means one site to maintain for all devices. But it’s also a really challenging approach to web design. In this article, we look at 10 tools that’ll help you handle the challenge.

320 and up

Most responsive designs are built with full desktop size in mind and scaled down from there. Andy and Keith Clark, the developers behind 320 and up, believe the opposite approach works best: design for the small screen, and implement the layout working upwards in size. 320 and up contains Media Query increments for five viewport sizes, a vertical grid, preset styles for typography and components from HTML5 Boilerplate.

inuit.css

inuit.css is a HTML5 framework that uses a grid system that scales down to small screens ‘out of the box’. It’s a minimalist approach, giving you just what you need to get started without unnecessary styles, but it’s extensible and there are a range of handy plugins available for it — such as one that creates breadcrumb trails out of ordered lists.

Skeleton

Skeleton is a light collection of CSS and JavaScript files that make designing responsive sites based on the 960px grid easy. Skeleton includes some basic styling and typography presets to get you out of the gate quickly. This project is the brainchild of Dave Gamache, formerly of esteemed UX firm ZURB and now on Twitter’s design team.

Less Framework

Less Framework is a CSS starter with four layouts — default at 992px, and tablet, mobile and wide mobile sizes — based on a grid system and including a selection of typography presets. Because Less Framework is one of the most popular options, there’s a range of supporting tools such as a Rails gem, OmniGraffle stencil and Compass plugin built around Less.

BluCSS

BluCSS is a CSS framework that, as usual, uses a flexible grid to facilitate responsive design. One feature that stands out is its responsive images, something many of these frameworks leave out; apply a class to your images and they’ll scale with your design. No need to include multiple files at multiple sizes, though be wary of unnecessary load on mobile devices with this approach.

Mobile Boilerplate

From the developers behind the famous HTML5 Boilerplate comes Mobile Boilerplate, a responsive template that puts the focus on mobile devices, namely those running Android, iOS, Blackberry and Symbian software. Everything from viewport scaling to HTML5 offline caching to home screen icons are ready to go.

Tiny Fluid Grid

If you find all these CSS frameworks to be too much for your needs, Tiny Fluid Grid may be the alternative you’re looking for. Simply tell it how many columns your grid will need, how big you want your gutters and how wide the site will be, and this site will spit out a responsive fluid grid you can use right away.

Golden Grid System

The Golden Grid System is a 16 column grid that uses a folding method inspired by the DIN paper system to collapse down to 8 columns on tablet-size screens and 4 columns on mobile screens, making it work for designs that range from 240 to 2560 pixels wide. The GGS developers say their folding method is superior to others because the gutters are better at staying in proportion with the content, producing less of a squeezed (or sparse, depending on direction) look.

1140 CSS Grid

The 1140 CSS Grid takes the opposite approach of the 320 and up system. This is primarily aimed at people who really want to design for a wider 1280 pixel screen, and are sick of catering to a 1024 pixel baseline. 1140 CSS Grid allows them to do that while fluidly re-arranging to fit on smaller screens all the way down to mobile.

Respond.js

Even before you start working on a responsive design, you may be worried about visitors using browsers that don’t support media queries, the CSS3 feature that responsive sites depend on. With Respond.js, this problem is easily solved; the script makes min-width and max-width work in Internet Explorer 6, 7 and 8, and should work with other browsers lacking support.

Bonus: ZURB Foundation

ZURB’s Foundation is a newer entry among responsive design frameworks, and is one of the most promising, having already won over many users of other frameworks. Billed as an easy-to-use yet powerful framework for building both prototypes and production deployments that work across all kinds of devices, Foundation makes use of a flexible grid, a library of styles and elements for rapid prototyping, and professes to take the pain out of creating layouts for different formats with the same markup.

Advertise here via BSA

The very promising jQuery Mobile project is now in its first Alpha release! What better time to give it a spin with our (err… my) favorite web framework?!

You should read jQuery Mobile’s official introduction section to familiarize yourself with its principles, but in a few words: you include it on the page, format your markup to conform to its requirements and reap the benefits. Yay, let’s write a (very contrived) CRUD application with Rails 3 and jQuery Mobile!

Setup

Our application will allow us to create, read, update and delete blog posts (remember when I said it was contrived? Uhm..yah) from mobile devices. If you don’t have Rails 3 installed yet, you can get it via RubyGems:

gem install rails

Use the rails command line tool to generate a new application. We’ll call it jqmoblog.

rails new jqmoblog
# ... a bunch of files are created
cd jqmoblog

As of Rails 3.0.1 you cannot specify jQuery as the JavaScript tool of choice when you generate a Rails application, but we can easily swap it in by using the handy, dandy jquery-rails gem. Edit the Gemfile in the project’s root directory and add a dependency on the gem. Once finished your Gemfile will look something like this:

source 'http://rubygems.org'

gem 'rails', '3.0.1'
gem 'sqlite3-ruby', :require => 'sqlite3'
gem 'jquery-rails'

Install the required gems using the bundle command line tool:

bundle install

Now we’ll use the Rails generator added by the jquery-rails gem to get all the jQuery files we need:

rails generate jquery:install

When prompted, allow it to overwrite rails.js.

We’re almost ready. The application skeleton is in place and jQuery has replaced the Rails default JavaScript libraries, but we’re missing the basic model, controller, and views for our application.

Thankfully, Rails has a generator which will create these files for us and its called the scaffold generator. We’ll keep the blog posts in our app super-simple since we’re really just using them to learn about jQuery Mobile. Each post will have a title and a body. Generate the scaffold for a Post resource like this:

rails generate scaffold Post title:string body:text

This command will provide a list of files and directories it created. There should be a model (app/models/post.rb), a controller (app/controller/posts_controller.rb), and a directory of views (app/views/posts) for our Post resource.

Run the database migration that was created from the scaffold command so our database has a posts table with the required columns for storing our posts:

rake db:migrate

At this point you can fire up a Rails server and the app will load up in your browser:

rails server

Point your browser to http://localhost:3000 and you should see this:

Hmm, before we get to mobilizing this application, let’s make the root url load the list of our posts instead of the default Rails index file:

rm public/index.html

Edit the config/routes.rb and set the root route like so:

Jqmoblog::Application.routes.draw do
  resources :posts
  root :to => "posts#index"
end

Now load up http://localhost:3000 again and you should see the empty list of posts.

We still need to get the jQuery Mobile files on the page. Lets use the ones hosted on jquery.com. Add them to the application’s layout file so they’ll be on every page that gets served. In app/views/layouts/application.html.erb, edit the head section to look like this:

<head>
  <title>Jqmoblog</title>
  <link rel="stylesheet" href="http://code.jquery.com/mobile/1.0a1/jquery.mobile-1.0a1.min.css" />
  <%= javascript_include_tag :defaults %>
  <script src="http://code.jquery.com/mobile/1.0a1/jquery.mobile-1.0a1.min.js"></script>
  <%= csrf_meta_tag %>
</head>

Okay, everything is in place. Now we’re ready to turn this into a mobile app!

Getting Started

Before we flesh out our mobile CRUD actions, let’s get the posts index looking decent in mobile browsers. jQuery Mobile relies directly on the page’s markup to work its magic, so to invoke it we just need to change our views to conform to its conventions.

Each “page” in a jQuery Mobile application needs to be wrapped in a div with a data-role attribute of page. I put “page” in quotes because there can actually be many of them on a single webpage loaded from the server. In our app we’ll be loading each “page” from Rails, so we should just add this to our layout file which will wrap each of our individual views:

Before

<body>
  <%= yield %>
</body>

After

<body>
  <div data-role="page">
    <%= yield %>
  </div>
</body>

Next edit the post’s index (index.html.erb) and change the markup to create a header and a content section which lists all the posts in the database.

Before

<h1>Listing posts</h1>

<table>
  <tr>
    <th>Title</th>
    <th>Body</th>
    <th></th>
    <th></th>
    <th></th>
  </tr>

<% @posts.each do |post| %>
  <tr>
    <td><%= post.title %></td>
    <td><%= post.body %></td>
    <td><%= link_to 'Show', post %></td>
    <td><%= link_to 'Edit', edit_post_path(post) %></td>
    <td><%= link_to 'Destroy', post, :confirm => 'Are you sure?', :method => :delete %></td>
  </tr>
<% end %>
</table>

<br />

<%= link_to 'New Post', new_post_path %>

After

<div data-role="header">
  <h1>Listing posts</h1>
</div>

<div data-role="content">
  <ul data-role="listview">
    <% @posts.each do |post| %>
    <li>
      <%= link_to post.title, post %>
      <%= link_to 'edit post', edit_post_path(post), "data-icon" => "gear" %>
    </li>
    <% end %>
  </ul>
</div>

Load up the page and it should look like this:

Two things to note here. First, we are once again using the data-role attribute to create the header and the styled list. This is a major theme of jQuery Mobile (as of the Alpha, I’m told they *might* be switching to class names instead of data- attributes). Second, each list item has two links, and jQuery Mobile automatically knows that this means we want to use a split button list. Pretty cool, huh?

Let’s add a button which will take us to a page where we can create new posts. Add this line to the end of the header div:

<%= link_to 'Add', new_post_path, "data-icon" => "plus", "class" => "ui-btn-right" %>

Again, jQuery Mobile “just knows” that this should be a button in our header and we pass it a class and a data-icon attribute to tell it where to place it and which icon to use. We now have a button in the header which links to the new post path!

Create

We’re gonna need to create posts so we can read, update and delete them, so lets handle creation first. The “Add” button on the posts index links to the new.html.erb view. It works as is and looks okay too. We’ll just tweak the markup to make it fit into the jQuery Mobile styles:

<div data-role="header">
  <h1>New Post</h1>
</div>

<div data-role="content">
  <%= render 'form' %>
</div>

We can now add new posts using the mobile interface! Go ahead and create a few so the posts index shows a list with links to edit each post:

Read

People will read posts from their show.html.erb view. Again, no change to the underlying controller or model code needs to happen. Just update the view file to look like this:

<div data-role="header">
  <h1><%= @post.title %></h1>
  <%= link_to 'Home', posts_url, "class" => "ui-btn-right" %>
</div>

<div data-role="content">
  <%= @post.body %>
</div>

Update

When we set up the posts index we added links to the edit.html.erb view using the gear icon on the right side of the split list. Now we just need to change the markup on that view to conform to jQuery Mobile’s requirements. Have you sniffed out a pattern to this development process yet?

<div data-role="header">
  <h1>Editing Post</h1>
</div>

<div data-role="content">
  <%= render 'form' %>
</div>

Again, it just works as expected and it will look great on many mobile devices. On to the final action, delete!

Delete

To facilitate deleting a post we just have to modify the delete links created by Rails’ scaffold generator to fit the rest of the mobile site. I think the edit page is a good place to add a delete link, so lets add a button to the header of edit.html.erb:

<%= link_to 'Delete', @post, :method => :delete, "data-icon" => "delete", "class" => "ui-btn-right" %>

The edit view is now complete, and it lets us update and delete our post.

Closing Up

If you’ve made it this far, you’ve probably realized that working with jQuery Mobile is pretty painless and it fits in with Rails quite well. There are a bunch of other things that jQuery Mobile can do, but this should hopefully whet your appetite. Remember, the framework is still in the Alpha stage so things can and probably will change.

I encourage you to read more about the project and get involved at an early stage so we can all benefit from a strong community!

***Download the source code for the application built in this post***

Advertise here via BSA

The trend toward rich client-side web applications has brought with it a need for robust JavaScript development tools. Firebug lead the way in this arena, but WebKit’s Web Inspector has caught up in a big way and ships with all recent versions of Safari and Chrome.

One powerful tool inside Web Inspector that is likely under utilized is the Profiles pane. I write a lot of client-side JavaScript and it still took me a long time to work up the gusto to dig into this tool and get anything out of it. If you find yourself in the position I was in, hopefully this post will give you what you need to get up and running quickly.

Basics

The JavaScript profiler is used to find and alleviate CPU bottlenecks in your code. To use it you invoke one or more “profile” runs in which Web Inspector tracks all JavaScript executed on the page and the time taken to execute it. In the picture below you will see a single profile called “Profile 1” being displayed.

There are two ways to run a profile:

1) Manually

The pane itself has a little button in the lower left-hand corner which can be used to start and stop a profile. This is the least precise of the two methods, but is sometimes good enough for one-off profiles. Click it once, go perform whatever action on the page that invokes the code you want profiled, and then click it again to stop.

2) Programmatically

The way I suggest you invoke profile runs is by calling into the console directly from your code. This will allow you to precisely position the start and stop of the profile for maximum signal to noise ratio. Here is how you might profile a totally contrived for loop programmatically:

console.profile('for loop');
for (var i = 0; i < 100; i++) {
  console.log('i is: ', i);
}
console.profileEnd('for loop');

After that bit of code is executed a new profile titled “for loop” will appear in the Profiles pane to be reviewed. The string argument to these functions is optional. If you don’t provide one it will simply increment “Profile [x]” like it does when run manually.

The Lingo

Now we know what the Profiles pane looks like and how to make it run, but its of no use unless we can derive meaning from the results. We can’t do that without understanding the terms used, so here are explanations as I understand them:

Self — the amount of time spent directly in the corresponding function

Total — the amount of time spent in the corresponding function and all functions called by it

Calls — how many times the corresponding function was called

Average — the value of the corresponding function’s Self divided by its Calls

Of these, Self and Total are the most confusing. The key thing to know is that the profiler tracks not only the time spent in each individual function, but also the time spent in functions called by that function. This is very useful when “drilling down” on a stack of function calls because you can look to see if the Total is bigger than the Self and if it is you know the time-consuming function is nested beneath the current one.

Everything’s Relative (or Absolute)

By default the Profiles pane displays all information in relative times so that each function is assigned a percentage of the total time of the profile. This is helpful in some scenarios, but I find the absolute times (measured in milliseconds and seconds) much more useful most of the time. To switch the profile result to absolute times, just click the little % sign at the bottom of the pane.

Top to Bottom. Bottom to Top

You can also sort the profile results using two different approaches. The default is the “Heavy” view or bottom up approach, which will more quickly float up the offending functions to the top of the heap. This is helpful to quickly identify trouble areas, but sometimes confusing because it doesn’t follow the logical structure of your code. For that, switch to the “Tree” view or top down approach. It looks like this instead:

Focus

One more feature of the Profiles pane is the ability to remove sections of the results and focus solely on the interesting bits. Do this by highlighting the interesting function and clicking the little eye icon in the lower lefthand corner. Other results will disappear and time percentages will be recalculated in the scope of the focused function.

Conclusion

I hope the above information explains what Web Inspector’s Profiles pane is, how to invoke it, what the results mean, and how to better organize them to increase their value. Give this power tool a try the next time you have some CPU intensive JavaScript that needs optimizing!

Advertise here via BSA

Probably one of the first topics covered when you get started learning about jQuery events is the concept of canceling the browser’s default behavior. For instance, a beginner click tutorial may include this:

$("a.toggle").click(function () {
    $("#mydiv").toggle();
    return false; // Prevent browser from visiting `#`
});

This function toggles the hiding and displaying of #mydiv, then cancels the browser’s default behavior of visiting the href of the anchor tag.

It is in these very first examples that bad habits are formed as users continue to use return false; whenever they want to cancel the default browser action. I am going to cover two very important topics in this article relating to the canceling of browser events:

• Use the right method for the job: return false vs. preventDefault, stopPropagation, and stopImmediatePropagation
• Top, bottom or somewhere in the middle: where in the event callback should you cancel default behavior?

Note: in this article when I refer to event bubbling, I am talking about how most events will fire on the original DOM element, and then on each parent element in the DOM tree. Events do not bubble to siblings or children (When events “bubble” downward, it is called event capturing). Learn more about bubbling and capturing.

Use the Right Method for the Job

The main reason return false is so widely misused is because it appears to be doing what we want. Link callbacks no longer redirect the browser, form submit callbacks no longer submit the form, etc. So why is it so bad?

What return false is really doing

First off, return false is actually doing three very separate things when you call it:

1. event.preventDefault();
2. event.stopPropagation();
3. Stops callback execution and returns immediately when called.

“Wait a minute,” you cry! I only needed to stop the default behavior! I don’t need these other two items… I think.

The only one of those three actions needed to cancel the default behavior is preventDefault(). Unless you mean to actually stop event propagation (bubbling), using return false will greatly increase the brittleness of your code. Lets see how this misuse plays out in a real world scenario:

Here is our HTML for the example:

<div class="post">
    <h2><a href="/path/to/page">My Page</a></h2>
    <div class="content">
        Teaser text...
    </div>
</div>
<div class="post">
    <h2><a href="/path/to/other_page">My Other Page</a></h2>
    <div class="content">
        Teaser text...
    </div>
</div>

Now lets say we want the actual article to load into the corresponding div.content when a user clicks on either title link:

jQuery(document).ready(function ($) {
   $("div.post h2 a").click(function () {
      var a    = $(this),
          href = a.attr('href'), // Let jQuery normalize `href`,
          content  = a.parent().next();
      content.load(href + " #content");
      return false; // "cancel" the default behavior of following the link
   });
});

All is well (currently) and our dynamic page is well under way. Down the road we decide another piece of functionality we want is to add the class "active" to any div.post that has been clicked (or when a child element has been clicked) most recently. So, we decide to add a click handler to them as well:

// Inside Document Ready:
var posts = $("div.post");
posts.click(function () {
    // Remove active from all div.post
    posts.removeClass("active");
    // Add it back to this one
    $(this).addClass("active");
});

Will this work when we click a title link? NO! The reason it won’t work is because we used return false in the link click event instead of using what we really meant! Because return false really means event.preventDefault(); event.stopPropagation(); the click event never bubbled up to the parent div.post and our new event has not been called.

This becomes even more of an issue when mixing normal events with live or delegate events:

$("a").click(function () {
    // do something
    return false;
});

$("a").live("click", function () {
    // THIS WON'T FIRE
});

So what DO you really want?

preventDefault()

In most situations where you would use return false what you really want is e.preventDefault(). Using preventDefault requires you allow for the event parameter to be accessed in your callback (In this example, I use e):

$("a").click(function (e) {
    // e == our event data
    e.preventDefault();
});

This does everything we want without prohibiting parent elements from receiving these events as well. The fewer restrictions you place on your code the more flexible it will be to maintain.

stopPropagation()

Sometimes you just want to stop the propagation. Take the following example:

<div class="post">
    Normal text and then a <a href="/path">link</a> and then more text.
</div>

Now, lets pretend we want one thing to happen when you click anywhere in the div except on the link, and you want the user to actually be able to follow the link if they click on it. (From a usability standpoint, this is a poor example. You probably don’t want something else to happen if a user slightly misses clicking on the link!)

$("div.post").click(function () {
   // Do the first thing;
});

$("div.post a").click(function (e) {
    // Don't cancel the browser's default action
    // and don't bubble this event!
    e.stopPropagation();
});

In this case if we had used return false the div’s click event would not have fired, but the user would also not have been directed to the correct destination either.

stopImmediatePropagation()

This method stops any further execution of an event, even to other handlers bound on the same object. All events bound to a particular item will fire in the order they were bound. Take the following example:

$("div a").click(function () {
   // Do something
});

$("div a").click(function (e) {
   // Do something else
   e.stopImmediatePropagation();
});

$("div a").click(function () {
   // THIS NEVER FIRES
});

$("div").click(function () {
   // THIS NEVER FIRES
});

If you think this example looks contrived, it really is. However, the situation is a very real one. As you build more abstracted code, different widgets and plugins may be adding events to the same code you are working with. This makes understanding and using stopImmediatePropagation worth while when you come across a situation that needs it!

return false

Only use return false when you want both preventDefault() and stopPropagation() and your code can support not canceling the default behavior until you reach the end of your callback execution. I strongly encourage against using this method in any examples you may write for new jQuery developers. It promotes a poor use of event cancellation and should only be used when you are consciously deciding you need what it provides..

Top, Bottom or Somewhere in the Middle

Before, when you were (mis)using return false, it always had to go at the end of your function, or at least at the end of a particular line of logic where no further execution was needed. With e.preventDefault we have more choices. It can be called at any time during a callback function to take effect. So where should you put it?

1. During development, it should (almost) always be the very first line. The last thing you want is for your form you are trying to AJAXify to actually submit to another page while you try to debug a JavaScript error in the callback.

2. In production, if you are following progressive enhancement, put it at the bottom of the callback, or at the end of execution flow. If you are progressively enhancing a normal page, then your link click event or form submit event has the proper server side fallbacks needed for browsers that don’t support JavaScript (or don’t have support enabled). The benefit here, however, is not related to browsers with JS turned off, but rather browsers with it turned on in the situation where your code throws an error! Take a look at the following code:

var data = {};
$("a").click(function (e) {
    e.preventDefault(); // cancel default behavior

    // Throws an error because `my` is undefined
    $("body").append(data.my.link); 

    // The original link doesn't work AND the "cool"
    // JavaScript has broken. The user is left with NOTHING!
});

Now, lets take a look at the same event with the preventDefault call being placed at the bottom:

var data = {};
$("a").click(function (e) {
    // Throws an error because `my` is undefined
    $("body").append(data.my.link); 

    // This line is never reached, and your website
    // falls back to using the `href` instead of this
    // "cool" broken JavaScript!

    e.preventDefault(); // cancel default behavior
});

The same applies for form submit events as well, provided you have the proper fallback information in place. Never count on your code always working. It is far better to plan for a nice fallback than assume errors will never occur!

3. In production, if the functionality is JavaScript only, keep the call on the first line. Remember, it doesn’t necessarily have to be the first line in the function, but it should come as early as fits with your program logic. The concept here is this: If this part of your functionality was added with JavaScript in the first place, then a fallback is not really as necessary. In this case, having it first will just ensure random # characters don’t appear in the URL or cause the page to jump around. Obviously, provide as much error handling as needed to ensure your users aren’t left with nothing for their efforts!

Conclusion

I hope this article presented enough information for you to make the right choice when you cancel events. Remember to only use return false when you really need it, and make sure you cancel the default behavior at the right location in your callback. Always work to make your code as flexible as possible, and stop using return false!

Advertise here via BSA

JavaScript is a powerful language, but it lacks some of the handy utilities that developers of other languages like Ruby & Python have come to know and love. Underscore.js is your utility belt. In the author’s own words:

Underscore is a utility-belt library for JavaScript that provides a lot of the functional programming support that you would expect in Prototype.js (or Ruby), but without extending any of the built-in JavaScript objects. It’s the tie to go along with jQuery’s tux.

Underscore.js provides collection functions like each, map, include, and reduce. It makes arrays more powerful by adding flatten, uniq, and intersect. It extends objects with many useful functions like keys, values, functions, isNaN, and many more.

A few examples to whet your appetite:

Using the each function to write each array value to the console:

// object-oriented way
_(['John', 'Paul', 'George', 'Ringo']).each(function(beatle) {
    console.log(beatle);
});
// functional way
_.each(['John', 'Paul', 'George', 'Ringo'], function(beatle) {
    console.log(beatle);
});

Using the reduce method to round three numbers down and sum the results:

_.reduce([1.5,2,3.7], 0, function(memo, num) { return memo + Math.floor(num) });
// => 6

Using the pluck method to to extract just the names from an array of objects:

var beatles = [
  {name: 'John', dead: true},
  {name: 'Paul', dead: false},
  {name: 'Ringo', dead: false},
  {name: 'George', dead: true}
]

_.pluck(beatles, 'name');
// => ["John", "Paul", "Ringo", "George"]

The library weighs in at just 2.5kb once packed and gzipped, so there is little excuse not to take advantage of its offerings. There are over 60 functions included, the documentation on how to use each function is great, the source code is freely available on GitHub, and the library is completely DOM-free which means you can use it server-side as well.

Thanks to Jeremy Ashkenas and the folks at DocumentCloud for a great open-source library that we can all benefit from!

Advertise here via BSA

jQuery plugins come in all shapes and sizes. They perform very simple or very complex tasks depending on their intended use. When it comes time for you to design your own plugin, its really important to understand what patterns other developers use and what will best suits your needs.

As a side note, I have built a number of plugins for my own projects and client work that will never be released. The jQuery community needs to stop thinking of plugins only as releasable, open-source projects, and start thinking of them instead as a reusable pieces of code that can help optimize and DRY up a complex website. Take this little plugin as an example:

$.fn.notice = function(){
    return this.slideDown(500).delay(4000).slideUp(500);
}

It simply abstracts the animation for displaying a notice (using jQuery 1.4). Would I ever release this on an open source site? Of course not! But it is still a fully functioning jQuery plugin that can be used over and over throughout a website.

Design Pattern Series Overview

• Basics & Structure (this article)
• Options & Updating
• Callbacks & Custom Events
• Misc. General Practices

Basics

Filename

Every jQuery plugin sits in its own JS file, and is normally named using the following pattern:

jquery.pluginname.js
jquery.pluginname.min.js

Released plugins often also have a version number:

jquery.pluginname-1.3.js
jquery.pluginname-1.3.min.js

If you end up building a lot of plugins for your website, consider also including a namespace to keep all your files together (And of course you would combine and minify them for production, right?):

jquery.mysite.pluginname.js
jquery.mysite.pluginname.js

Basic File Layout

After any comments you choose to put at the top of your file, the very next thing you should have is a self executing anonymous function that will actually wrap your entire plugin. Say what!? Don’t worry, you have seen it before, and it looks like this:

(function($){

   ... code here ...

})(jQuery);

This gives your plugin a private scope to work in, and also allows your plugin to be used with $.noConflict mode without creating a problem. By passing jQuery into the function, the $ will equal jQuery inside the function even if $ means something different outside your plugin.

Structure

There are three basic structures you will see when you look at released plugins:

Contained Function

In this structure, (almost) all the code to run your plugin is contained within the function used to call your plugin. This is the most common format:

(function($){

   $.fn.myPlugin = function(){
      return this.each(function(){
         // do something
      });
   }

})(jQuery);

You should use this this structure when you are writing a simple plugin that acts once upon the jQuery result set on each execution. For complex plugins that need to maintain an adjustable state, you should consider the “Class and Function” structure.

Class and Function

In this structure, a class is used and an instance is created for each DOM element in the result set. You may see these objects attached in some way to the DOM elements they modify:

(function($){
   var MyClass = function(el){
       var $el = $(el);

       // Attach the instance of this object
       // to the jQuery wrapped DOM node
       $el.data('MyClass', this);
   }

   $.fn.myPlugin = function(){
      return this.each(function(){
         (new MyClass(this));
      });
   }

})(jQuery);

You should use this structure if you need to be able to access the object later that is associated with a DOM element. It is far easier to attach a single object vs several key/value pairs using the data() method. In this approach, you can access the object by calling $('selector').data('MyClass'). This functions more like a widget and is a plugin that maintains state and can adjust its state on the fly (Learn how in the next article.).

Note: Widget Factory: The next release of jQuery UI is going to see the addition of a Widget Factory that will be designed to specially assist in developing widget-like plugins.

Extend

In my opinion, this is the least idiomatic way to create a jQuery plugin. It uses the jQuery.fn.extend method instead of jQuery.fn.pluginName:

(function($){

   $.fn.extend({
     myPlugin: function(){
      return this.each(function(){
         // do something
     },
     myOtherPlugin: function(){
      return this.each(function(){
         // do something
     }
   });

})(jQuery);

You will find this structure helpful if you need to add a large number of plugin methods to jQuery. I would contend, however, that if your plugin needs to add that many methods, there may be a better way to structure its implementation.

I feel the extend method is used more by programmers transitioning from other JS libraries. I personally find the simple $.fn.pluginName = structure to be easier to read, and more in line with what you will normally see in jQuery plugins.

Up Next

In the next part of this series, we will look at passing options and providing methods for updating settings and functionality after a plugin has been called.

Advertise here via BSA

Winners Announced

I was really happy to see so much participation in this giveaway! After seeing how many people entered, I was feeling really bad that only one of them would leave with a copy of the book. I talked to Cody, and he graciously provided two more free copies so we can award a total of three books! I randomly picked three winners (using Random.org) and am happy to announce the following winners:

• Brad Rhine (truetech.org)
• Mila
• Geoff Woodburn (woodburndesigns.com)

Book Review

Late in 2009, Cody Lindley published a PDF book on jQuery titled jQuery Enlightenment. Today we are presenting our view of the book as well as offering a free copy to one lucky reader.

About The Author

Cody Lindley is a core team member of the jQuery project, and the original developer of the well known Thickbox plugin for jQuery. I had the pleasure of meeting and listening to Cody present at the jQuery Conference last year in Boston. He describes himself on his website:

Today I am a Christian, husband, son, brother, professional Web developer, and outdoor enthusiast. I spend a majority of my time sleeping and working, but who doesn’t? In between the daily routines of the average American, I desire an existence that entails a relationship with God, my family, and nature. I would like to consider myself a bookworm (a novice theologian at best), but truth be told, I simply enjoy watching movies and playing xBox way too much. I guess I also have the luxury of pursuing my profession as a personal passion. Yes, I often work even when I am not at work.

Overview

jQuery Enlightenment is a different type of book than I am used to seeing in the tech field. A list of what it is not might help shed light on what I mean. It is not documentation, a tutorial/walkthrough, or just conceptual material. jQuery Enlightenment is an amazingly clear montage of principals and code samples every jQuery developer needs to know grouped by topic. Cody covered topics both basic and profound throughout the pages of the book.

I consider myself quite adept at using jQuery, but found myself constantly amazed at the things I was learning while reading this book. Cody says it picks up where the jQuery documentation leaves off. I can see his point, but I think this book would be a better starting place for a new jQuery developer than even reading through the jQuery API site.

Pros

Code Samples

Code samples make up over 70% of the book (rough estimation). The book is not written in an editorial way at all. It is about presenting what you need to know, demonstrating it with an example, and moving on. For this reason the book is an extremely fast read and perfect for reference on a day to day basis.

Possibly one of the neatest features of the book itself is that (almost) every code sample provided in the book has a link to the same code on JSBin.com. JSBin is an online playground for testing and demonstrating JavaScript, HTML, and CSS technologies. jQuery Enlightenment isn’t a flat reading experience, it allows you to immediately jump in and play with the code samples until everything makes sense.

Additional Notes

Many of the topics are followed by a little box titled ‘Notes’. I am glad Cody didn’t choose some cheesy title for these boxes, but ‘Notes’ really does not sum up what they provide. You will find many undocumented (or hard to find) tips and tricks about the finer points of jQuery in these boxes. Skip over them at your own peril!

No Fluff Quality

Cody doesn’t waste any time on any of the topics presented in the book. The pattern used is simple: explain, demonstrate, move on. I personally will be using this book not just for reference, but for a quick read-through every few weeks to keep my jQuery senses sharp.

Cons

You will be hard pressed to find something negative to say about this book, and it wasn’t until I reached the end that I had one complaint about the content. The chapter on Ajax (Chapter 11) was far too short. Perhaps this is because the documentation is very clear, but I still wanted to learn more and have more examples to glean from. Perhaps the second edition of the book (which will cover jQuery 1.4) will provide more detail on jQuery’s AJAX implementation and associated methods.

Conclusion

I am confident new users and seasoned users alike will find much to learn in jQuery Enlightenment. After reading the book, my only concern is that I won’t remember all of the cool things I learned while reading it!

Win a FREE Copy!

Next Wednesday we will be selecting a winner to receive a free copy of jQuery Enlightenment. Entering the competition is easy!

Head over to jQuery Enlightenment and quickly look through table of contents. Then, leave a comment below telling us what chapter you think you would learn the most from if you were to win the book. Only comments referencing one of the actual chapters in the book will be eligible to win. We will randomly select a winner next Wednesday and announce it here on the site.. Sorry, but the contest is over!

Advertise here via BSA

When you do a lot of development with backend technologies, it can be frustrating to then move to the front end and feel like you are using a completely different syntax. One thing I really miss is the helper methods, especially when using Ruby on Rails on the server. Little helpers like titleize() or downcase() get replaced in javascript by a custom function and toLowerCase() respectively. You don’t have to feel lost anymore! There is a way you can extend the native objects found in JavaScript to make your environment feel a little more like “home.”

This is accomplished by using the prototype object. Each native object in JavaScript includes a prototype object. Don’t get this confused with the PrototypeJS framework… the prototype object is a way to extend all objects that have inherited from the base object you extended. You can easily extend the prototype object by adding functions to it like this:

Object.prototype.functionName = function(){

}

You can then call them directly:

var obj = new Object();
obj.functionName();

There are a number of advanced uses of the prototype object, but this is the important thing to remember: any function added to the prototype of an object is available on any object that inherits from it. So if you extend the prototype on the Number object, all numbers will have access to the new function; if you extend the Array object, all arrays can access your custom function. You only use the prototype.functionName syntax when declaring the new function, not when calling it.

Enough theory, lets see some (somewhat) practical uses:

Do you find yourself capitalizing a lot of words in a particular JavaScript app? Just add a capitalize method to the String object.

String.prototype.capitalize = function(){
  if(this.length == 0) return this;
  return this[0].toUpperCase() + this.substr(1);
}

Now you can capitalize any string in your application by calling "lower".capitalize() and get "Lower" in return. Since it returns a string, you could chain it with any other function you can execute on a string.

Do you always find yourself forgetting you can call Number(”25″) to turn a string into a number? Just add a toNumber() function to the String prototype:

String.prototype.toNumber = function(){
  return Number(this);
}

If you need to split large JSON arrays into groups of two or three each, you could extend the Array object like this:

[js]
Array.prototype.inGroupsOf = function(num){
	var ret = [],
		length = this.length,
		groups = Math.ceil(length / num);

	for(var i = 0; i < groups; i++){
		var start = i * num,
			end   = start + num;

		ret.push(this.slice(start, end))
	}
	return ret;
}

Now calling inGroupsOf(3) on any Array would return that same array split into as many parts as needed to ensure no group has more than three items in it.

There are a number of objects you can extend, but the ones you will use the most are String, Array, Object, Number, Date. One trouble area you might face is calling methods on numbers. The following example will fail:

Number.prototype.to_s = function(){
  return this + "";
}

25.to_s();

The prototype function is correct, but the way we called it is wrong. There are two ways to call our custom functions on numbers:

var n = 25;
n.to_s(); // Returns "25"

(25).to_s(); // Also returns "25"

Think Start, Not End

Its important when deciding what object to extend that you focus on what object type you are starting with, not so much which type you plan on ending with. For instance, if you wanted to extend an object to easily parse Twitter date strings you would not extend the Date object. You would extend the String object, and your function would return a Date object.

Load Your Extensions First

It is normally a good idea to load these extensions prior to any other library, including jQuery. Anytime you extend the prototype object, the new method is instantly available to all objects of the same type or any object that has inherited from that type. However, since you want to be sure your methods are always available, you guarantee their availability by loading them first.

How to Group The Extensions

Naming your files Prototype.Date.js and Prototype.Array.js is an easy way to keep all your extensions in one part of your JS folder, and easy to access during development. If you follow this method, you would simply put Date.prototype methods in the Prototype.Date.js file, etc. This starts to break down when you have parallel functions. You might have a toDateFromTwitter() method on the String object and a toTwitterFromDate() method on the Date object. Putting these in separate files might not make sense. At that point, you should put both these extensions in a file named TwitterHelpers.js or something similar. Obviously use what makes sense to you and works with your flow.

Don’t Bloat

Just because you write 500+ awesome Array extensions in the next 2 years, does not mean you need to include them on every project. Be sure to only use this technique when it makes sense for the project and when it helps clean up your code.

Advertise here via BSA

Ok, maybe they won’t exactly “Rock Your World” but they might completely change the way you look at your jQuery development. At the very least, I hope this simple technique will help you build clean, reusable and extendable front-end code.

A Quick ‘n’ Dirty Overview

If you are the “just the facts” type of person, here is the 20 second overview. You can trigger custom events on any DOM object of your choosing using jQuery. Just trigger it using the following code:

$("#myelement").trigger('fuelified');

You can subscribe to that event using either bind or live functions in jQuery:

$("#myelement").bind('fuelified',function(e){ ... });
$(".cool_elements").live('fuelified',function(e){ ... });

You can even pass additional data about the event when triggering it and reference it on the listeners end:

$("#myelement").trigger('fuelified',{ custom: false });
$("#myelement").bind('fuelified',function(e,data){ if(data.custom) ... });

The element the trigger has been called on, is available to listener’s callback function as the variable this.

A Little Philosophy

I encourage you to view your front end code in parts and pieces instead of one huge piece of front-end code. If you look at each part separately, you can build better, reusable pieces of code. You won’ t have a lot of duplicated code in your web-site, and you will be able to extend what you have built later on. A rating site might have widgets that are used to take in the ratings. You may have another widget that monitors the rating widgets and tallies the scores. Making the pieces as independent as possible makes reuse and extension a breeze.

A Fun Example

For those who like tutorials or walkthroughs, this should be a fun demonstration of the power of jQuery custom events.

Preparation

To get started, download my blank website template. Then head over to Starter for jQuery and create two jQuery plugins using the following settings:

1. Class Name: ColorBlock
   Include: Options, Getter (Not Comments)
2. Class Name: ColorObserver
   Include: Options, Getter (Not Comments)
   Default Options: colorObjs|div.color_block

After you enter each item, click Create then Download. Save each file to the js/ directory of our Blank Website Template. Then add <script> tags linking both files into the index.html file. Finally, put a blank jQuery document.ready block into the head, just below the scripts. When you are finished, the scripts in <head> area should look like this:

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js" type="text/javascript" charset="utf-8"></script>
<script src="js/jquery.colorblock.js" type="text/javascript" charset="utf-8"></script>
<script src="js/jquery.colorobserver.js" type="text/javascript" charset="utf-8"></script>
<script type="text/javascript" charset="utf-8">
 	$(document).ready(function(){

  	});
 </script>

HTML

Copy and paste the following HTML markup into the <body> tag of the index.html file:

<div id="color_blocks">
  	<div class="color_block"></div>
  	<div class="color_block"></div>
  	<div class="color_block"></div>
  	<div class="color_block"></div>
  	<div class="color_block"></div>
  	<div class="color_block"></div>
  	<div class="color_block"></div>
  	<div class="color_block"></div>
</div>

<div id="observer-one" class="observer"> </div>
<div id="observer-two" class="observer"> </div>

Normally I might delegate the creation of the div.color_block elements to a script as well, but that is not the point of this exercise!

CSS

Copy and paste the following CSS into the layout.css file. Basically it sets simple styling for our elements. The important part is that it sets a width and height of 50px for our .color_block elements, and floats them to the left. If you were to load index.html in a browser right now, you wouldn’t see too much.

.color_block {
	width: 50px;
	height: 50px;
	cursor: pointer;
	float: left;
	margin: 0 5px 5px 0;
}

.observer {
	clear: left;
	margin: 10px 0;
	padding: 10px;
	float: left;
	background: #eee;
	font-family: Helvetica, Arial;
}

#observer-one { border-top: solid 2px red; }
#observer-two { border-top: solid 2px blue; }

JS

The plugins you created using Starter for jQuery have added two new functions to our jQuery objects. We are going to call both of them in our <head> script area. Paste the following code between the opening and closing braces of the document.ready function:

$(".color_block").colorBlock();
$("#observer-one").colorObserver();

The first line calls our colorBlock plugin on all the blocks. The second, calls our colorObserver method on one of our observer divs. If you load the page now, you should not get any errors, but nothing should do anything yet either.

ColorBlock

We want to give our ColorBlocks an array of colors. They will all start on color 1 (index position 0) and every time you click on them, they will change to the next color. To do this, we will add code to our jquery.colorblock.js file.

Note: Most of you are probably not familiar with Starter for jQuery, or the code it puts out. I plan on writing an article about it sometime, but for this article remember these important principles. Anywhere in the plugin class itself ($.ColorBlock for example) base refers to base object. And base.el and base.$el refer to the DOM element and the jQuery wrapped DOM element the base object is connected to.

The plugin supports override-able options. We need to use this for our plugin, so find the $.ColorBlock.defaultOptions and paste this between the curly braces:

colors: ["red","blue","green","yellow"]

Now, we need to give our object the ability to change colors. Paste the following code after the base.init function definition (but before the base.init() call. That should always come last in the plugin) :

base.setColor = function(new_color_index){
	if( new_color_index != base.current_color_index ){
		base.current_color_index = new_color_index;
		base.$el.css({backgroundColor: base.options.colors[base.current_color_index]});
	}
}

base.nextColor = function(){
	var new_color_index = base.current_color_index + 1;
	if ( new_color_index > ( base.options.colors.length - 1 ) )
		new_color_index = 0;
	base.setColor( new_color_index );
}

base.getColor = function(){
	return base.options.colors[base.current_color_index];
}

This gives our object three methods. A method to set the color using an arbitrary index. A method to trigger the next color in the cycle. And finally a way to retrieve which color is currently in use. Nothing so far is rocket science.

Finally to enable our little widget, we add two lines of code to the base.init function after the line that initializes the options.

base.$el.click(function(){ base.nextColor(); });
base.setColor(0);

The first line triggers base.nextColor() every time our object is clicked. And the second line just initializes our object using the first color in the array (index position 0).

Now, if we load index.html in our browser, you will be able to cycle through the colors on each block simply by clicking on them.

In our make believe world, we can be happy that we made a working jQuery plugin. YAY! However, bad news also occurs in our world, and our client requests a way to monitor which colors are currently showing. So, along comes our ColorObserver widget.

Already we are making educational progress, because we realize the functionality to monitor all color_blocks is not the function of the ColorBlock widget (You do realize that right?).

ColorObserver

Our observer needs a method to find all ColorBlocks and find out which colors are showing. The following code should do the trick. Paste the following code into the jquery.colorobserver.js file, after the base.init definition, but before the base.init(); call.

base.discoverColors = function(){
	var colors_count = {};
	$(base.options.colorObjs).each(function(){
		var color = $(this).data('ColorBlock').getColor();

		if(!colors_count[color])
			colors_count[color] = 1;
		else
			colors_count[color] += 1;
	});

	var output = "";
	$.each(colors_count, function(key,value){
		output += key + "=" + value + "<br />";
	})
	base.$el.html(output);
}

In a nutshell, this code uses the selector from our defaultOptions or an overridden option to find which objects are ColorBlocks. It then gets the color, and either adds it to the colors_count array, or increases its count by one if it already exists. It then puts together a HTML snippet, and updates its base.$el content with our snippet. (Remember that base.$el refers to the jQuery wrapped DOM element we originally tied the widget to. In this case, #observer-one)

The Most Important Part

Now we need to tie to two objects together. You might be tempted to hardwire some $("#observer-one").getColorObserver().discoverColors() call into your setColor function over on the ColorBlocks. It would work for sure, but it makes your code more and more dependent on each other… making future changes more likely to break your code.

Instead we will use custom events to solve our problem. Put the following line inside the base.setColor function on the ColorBlock, inside the if statement as the last line:

base.$el.trigger('color_changed');

Now, any time the color changes on a single block, a ‘color_changed’ event fires. Now, put the following two lines in the base.init function of the ColorObserver class (After the options setup code):

$(base.options.colorObjs).live('color_changed', function(){ base.discoverColors(); });
base.discoverColors();

The first line binds to our custom event and tells the ColorObserver class to rediscover the visible colors. The second line is just the initial call to find out the starting state of the colors.

At this point our job is done, and our two widgets are correctly wired together. Load index.html up in your browser and see for yourself. Every time you change a block color, the observer knows about it and changes its data to match.

The best part is that you could delete the <script> tag that links the ColorObserver to our document, and remove the line that initializes it, and the ColorBlock’s would continue to work just fine!

Even More Coolness

You might not have even noticed, but even more flexibility was baked into our project. Add the following line to our <head> script block:

$("#observer-two").colorObserver({colorObjs:$(".color_block:lt(3)")});

Now our second observer only observes the first 3 color blocks. We over-rode the colorObjs default selector with our own.

Conclusion

I hope this opens new doors to you when using jQuery for development. Its a great way of compartmentalizing and easily extending your code. If you still have trouble understanding its practicality, consider an advanced jQuery rich internet application. It could trigger events for every major interactions, and you could build a GoogleAnalyticsObserver class to listen for those actions and send them on to Google to track.

Let me know if this helps you out, or how you think you could use Custom jQuery Events.

Advertise here via BSA

There are a few things you have to know in order to be a front-end web developer. Where to start and what to learn. This guide will take you through the steps of becoming a front-end web developer.

First things first

Before we start seeing stuff on the screen, we have to make something out of nothing. We start at the basics of web developing: HTML. This markup language will draw shapes on the web page and display text.

HTML is not only very important, your whole markup will depend on it. Don’t touch CSS yet! We’ll come to that later.
CSS is worthless with a bad markup supporting it.

1. Learn HTML

1. Learn basic HTML
2. Learn about xhtml and validation
3. Make valid xhtml and validate

Learning perfect HTML will take some time but it will really pay off later. It’s way easier to prevent mistakes and track down bugs when the markup is perfect.

Next step is what you’ve been waiting for; applying CSS.

2. Know CSS

1. How to apply CSS
2. Know all the important aspects of styling
3. Learn about positioning
4. Get to advanced CSS

You don’t have to be perfect at CSS. But being good at it will save a lot of time for your designer.

If you plan on becoming a server side programmer you are best off learning a server side language to generate HTML pages now. Take a look at PHP, ASP.NET, JSP etc. if you want to know more.

Now that you know good HTML and CSS it’s time to put in a little Javascript.
Don’t start by using a framework now, you first need to understand what Javascript is and what it can do to alter the layout of the web page.

3. Rock Javascript!

1. Read a good book about Javascript.
2. Get to know some funny Javascript effects and concepts. (There are a lot on the Internet)

After I read a good book and experimented with Javascript on some projects a bit, I wanted to get everything out of Javascript by making nice effects like the other guys do. For this there are a lot of frameworks available, which also happen to make your Javascript coding a lot easier!

4. Pick your framework

There are a few great Javascript frameworks out there. The biggest players in the game are: MooTools, jQuery and script.aculo.us.

MooTools is a lightweight Javascript framework which can be used to utilize simple effects on the elements on your page. It doesn’t have a lot of fancy features, but it does the job. Good choice for beginners.

jQuery might be the most popular one out there. Not without a reason! It’s easy to apply, it has great docs, maybe even easier to learn and does a wonderful job. Does require some plugins for extra functionality but it’s a really nice framework. Also has a large community.

script.aculo.us is the mother ship of the Javascript frameworks. It’s big and weights a ton. It might be a bit slower and requires a bit more programming than its competitors, but it is powerful in what it does. The capabilities of script.aculo.us take a lot up in speed, but for that you get complete control. You can create excellent Rich Internet Applications with this framework.

Conclusion

In just a few step you can become a front-end web developer. This might take a while and it might take some time to get used to a language, but it will pay-off in the end.
There is a lot to be learned on the Internet and it is never too late to try out web development and make the web a little more exciting.

Advertise here via BSA

As a webdesigner you might have had this problem: “I’ve got a nice looking wide image, but I don’t want my visitors to scroll horizontally.”

A colleague showed me a new project he was working on. A large image appeared and I had the ability to drag and move the image around in a container. Not super efficient if you ask me, I still had to grab the image and move it around holding my mouse button. Can’t there be an easier way?

This article will show you my solution to the problem and maybe even a different approach on navigation.

The example page is located here:
http://www.fuelyourcoding.com/scripts/photonav/

And the archive is downloadable here:
http://fuelyourcoding.com/scripts/photonav/jqueryphotonav.zip

What is it?

This photo container has been adjusted to “move” with the cursor. To achieve this I used Javascript and a library called jQuery.

What do we have and what do we need to do?

1. Create a HTML layout for the picture to get in.
2. Adjust the CSS.
3. Make a call to PhotoNav in Javascript.

1. Create a HTML layout

This is the easiest step. It might just as well be a copy paste of the code below. But be aware of three things.
First give the overall container an id (so Javascript can grab the object).
Then make sure the div with classname fixed gets a second classname to correspond with the CSS (I used opt1 and opt2).
Determine if you want to have links inside of the container, if not; you can leave the container empty.

Take a look at the code below:

<div class='photo' style='display: none;' id='navigate'>
	<div class='fixed opt1'>
		<!-- this is optional --!>
		<a href='http://gayadesign.com/post/' class='button1'>

		</a>
		<a href='http://gayadesign.com/portfolio/' class='button2'>

		</a>
		<a href='http://gayadesign.com/about/' class='button3'>

		</a>
		<a href='http://gayadesign.com/partners/' class='button4'>

		</a>
		<a href='http://gayadesign.com/contact/' class='button5'>

		</a>
	</div>
</div>

The overall container “navigate” will always be hidden prior to the actual Javascript call. I also gave the fixed div a second class. This classname will point to the options of the container; the height and the background image (the actual image that needs scrolling).
You can add <a> tags to the fixed container. I gave them all classnames so they can be positioned in the CSS. This part is optional.

Remember to include the jQuery library and the PhotoNav Javascript files in the header. Also include the CSS file photonav.css.

<script src="js/jquery-1.3.2.min.js" type="text/javascript"></script>

<script src="js/photonavjQuery.js" type="text/javascript"></script>
<link href='css/photonav.css' rel='stylesheet' type='text/css' />

2. Adjust the CSS

The top part of the CSS has to stay the way it is, do not adjust it if you don’t know what you are doing. I put a comment at the spot where you can start to edit the CSS.
I’ll describe what to do at each part of the CSS.

.photonav .photo:

.photonav .photo {
	width: 400px;
	margin: 10px;
	border: 1px solid gray;
}

Adjust the width of the total container. This has to be a fixed width in order for it to work in IE6. I have no idea why, but if the width was set to 100%, the height was 0px. You can do 100% in other browser with the !important trick.
The margin and border are optional, just make it as you’d like.

.photonav .photo .opt1:

.photonav .photo .opt1 {
	height: 100px;
	background-image: url();
}

This is the height of the photo container, at least, the fixed container. But notice the .opt1, it is the second classname we added to the fixed container in the HTML part.
The background image is the image that has to be viewed inside the container.

The next part is optional and only if you want buttons inside the container.

a.button*:

a.button1 {
	margin-left: 20px;
	margin-top: 30px;
	width: 100px;
	height: 90px;
	background-image: url();
}

a.button1:hover {
	background-image: url();
}

In order to create a menu navigation like I did on the preview page, you need to add a tags with different classnames. Define the pixels from the left side and the top of the container in the margin values. State the width and height of the button and the background image (if needed).
To create an onhover effect you can add an other image in the :hover part.
If you want a second a tag next to the other, subtract the height of the previous button from the margin-top.

3. Make a call to PhotoNav in Javascript

Now that you’ve got all the necessary HTML and CSS set, you can call the PhotoNav functionality. The following code can be put in a js file or in a script tag.

document.getElementById('navigate').style.display = 'block';
PhotoNav.init('navigate', 758, 1412, false);

The specification is:
function init(String id_of_container, int width_of_container, int width_of_panorama_picture, bool debugMode);

String id_of_container:
The id of the container.

int width_of_container:
Give the width in pixels of the fixed container. For calculating reasons.

int width_of_panorama_picture:
Give the width in pixels of the panoramic picture. For calculating reasons.

bool debugMode:
Enable debug mode. Outputting value to the HTML element with id ’status’. (default: false)

If you want to enable debug mode, you have to insert the following code somewhere in your HTML:

<div id='status'>
	&nbsp;
</div>

Conclusion

Now that everything is set, you can fire the thing up! Enable the navigation on loading a page or by triggering an event in Javascript. If you have implementations of this script, post your examples in the comment section, I’d like to see them.

Good luck!

Advertise here via BSA

AJAX is one the nicest concept I’ve seen in web development. The basics are simple and quite easy to use.
There are a lot of AJAX frameworks around like jQuery, Prototype and backbase. These frameworks help you create an AJAX application with ease.
But is AJAX really that good? No, but if you use it correctly, it is!

In this article I wish to share my view on AJAX and the possibilities it gives to web developers and designers, and why AJAX is wrong in several situations.

Case 1: Page loading

What’s up with websites and dynamically loading pages through AJAX? Isn’t it a bit strange that when you want to switch to another page, there is no real page switch?
Sure, I like it when content is loaded into the website dynamically, saving me bandwidth, time and irritation. But a whole page? Isn’t that kind of missing the point?

• First of all: What about the back and forward buttons of your browser? No use for them if you load a whole page in AJAX.
• Second: Funny when a user tries to copy the URL and send it to a friend. Oops, the page is loaded without the content the user expected.
• Third: Search Engines can’t pick it up since it is not really a new page.

A better way to load content through AJAX is to load only small parts of information on the page. If the users wishes to visit another page, let the browser go to another page.
Loading content in a small part of the page isn’t a bad thing. If you have a container with tabbed content, it’s easy to load the content of other tabs with AJAX, not a problem.

Loading a whole page in AJAX is just overusing the functionality and really missing the point of web browsing.

Case 2: The content manager

Being able to adjust the information of your web profile on a web page with the use of AJAX is cool. Fast feedback, fast loading times and convenient. But is it really secure?
I’ve seen sites where the HTTP calls to the server contained the key and value of the part they wanted to configure. Which means the record which will be adjusted is defined. This means you could also change information of other rows in the database. Why? You need to wonder what parts of the profile can be adjusted, and if it applies only to the user who is trying to configure their information, why do you need a key to tell the server which record to adjust?
In PHP, for example, it only takes little effort to remember a value in a session. With this, you know which user is using the website and if you open the session in the AJAX server side pages, you can still read that session. Makes it easy to tell which record to update and doesn’t give a user the opportunity to mess around in your system.

If you do want to send along a key + value, which could be needed in some situations (like inserting a comment), be sure to check the given values in the server side scripts. Can’t say this enough to people, but please be sure the user that is trying to insert / update data has access to that data. This also applies to normal usage of forms, but adjusting an AJAX request is harder for most users. Still it is possible! So be on your guard.

Case 3: One click update

This one is something I love about AJAX. The vote buttons on sites, the follow button on Twitter, delete entry buttons and many more of those. The convenience of just clicking once without having to refresh the page is awesome. It’s so simple, yet so powerful.
If you are using such a thing, keep case 2 in mind.

Case 4: Content loading

One of the most important things of dynamic loading: it has to be quick. Sending a request to a server doesn’t always have to take up most of the time, but loading the response can be a real pain.
Keep the response clean and small. I’ve seen examples (I’ve been guilty in the past) of people giving HTML back in the response. With this they’ll adjust the innerHTML of a container. In the worst case they’ll load a whole new page (like in case 1).

To solve this, please use JSON or anything of that kind. JSON helps you convert server side variables to Javascript variables. The response the server will give are Javascript variables for Javascript to read. JSON has been implemented in PHP since version 5.2.0 and is easy to use.

Don’t give HTML back to your web page, but arrays of information. This helps keeping the presentation of your site and the calculation apart from each other. Do the adjusting of the DOM in Javascript.

Case 5: External Services

When you use external services and feeds to build a web page in server side scripting, you rely on an external service. This can also result is pages loading slower than needed. The is why AJAX is ideal for loading external services.

Load information from an external source after loading the page. This will prevent slow loading of the rest of the page and let’s the information just easily slip in the page when it’s ready.

Conclusion

I hope I’ve given my point of view on AJAX and how to use it. If you wish to discuss the things that I’ve said; please do so!

Share your AJAX stories with me =)

Advertise here via BSA

The GarageDoor effect – creating one has now been made easy! This tutorial explains everything you need to know on how to create the same effect yourself.

An example of the GarageDoor effect in work is found here: http://www.fuelyourcoding.com/scripts/garagedoor/
Download the following archive containing everything you need: http://www.fuelyourcoding.com/scripts/garagedoor/garagedoor.zip

Unzip the contents of the archive and upload the contents to your server, the set folders can be adjusted to your needs.

First we need to make the script ans style of the GarageDoor work. To make that happen, you’ll need Scriptaculous. This library enables interface effects, so you don’t have to create it yourself. So grab Scriptaculous and upload it to your server. Make sure you also upload the prototype.js file (in the lib folder).

Add the following code in the <head> tag of your page:

<script src="js/prototype.js" type="text/javascript"></script>
<script src="js/scriptaculous.js" type="text/javascript"></script>

<script src="js/garagedoor.js" type="text/javascript"></script>
<link href='css/garagedoor.css' rel='stylesheet' type='text/css' />

This will load the scripts and styles needed for the GarageDoor to work. Adjust the paths where needed.

The next thing you want to do is to create the HTML layout for the garagedoors. The following code shows the structure you need to create for your document:

<div class='garagedoor' id='garagedoor'>
	<div title='linktofile' class='item'>
		<div class='underlay'>
			Caption text
		</div>
		<img src='uritooverlayimage' class='overlay' />
		<div class='mouse'><img src='images/nothing.gif' />&nbsp;</div>
	</div>
	<div title='linktofile' class='item'>
		<div class='underlay'>
			Caption text
		</div>
		<img src='uritooverlayimage' class='overlay' />
		<div class='mouse'><img src='images/nothing.gif' />&nbsp;</div>
	</div>
</div>

This contains two items that will be the garagedoor. The keywords linktofile and uritooverlayimage have to be adjusted in order to make it work. Linktofile is the URL of the page the button has to link to, might be confusing because it’s not an a tag, but Javascript fixes it for you.

The items have a default size of: 100px width and 80px height. Create overlay images according to these dimensions. In order to change the size, take a look in the garagedoor.css file andadjust the width and height of several elements.

All there is left to do is call the GarageDoor to enable the effect!

<script>
	GarageDoor.scrollY = -55;
	GarageDoor.scrollX = 0;
	GarageDoor.setBindings('garagedoor');
</script>

The first line in the <script> tag sets the amount of scrolling the overlay has to do when the cursor is floating over an item. In this example the overlay has to go 55 up, which means move -55px on the Y-axis.
You can also make it scroll horizontal.

Give the id of the garagedoor container to the setBindings method and the GarageDoor effect will be initialized! Be sure to make the call after creating the html.

You are now set to use the GarageDoor Effect. Good luck!