Its the nifty little tool that lets you do this.

Normally you would need to include the prototype supplied by Douglas Crockford on the page for you to be able to use this, but if you are using the Mootools library then its already built in.

String Method: Substitute

Enabling the back button isn't quite as difficult as it might sound, especially for a project that your starting from scratch. Here's a simple example and then we'll go through the techniques needed to make this happen.

Change Background Color To

• Denim
• Maroon
• Black

If this is not working for you, then you can try this test page.

As you click the different buttons, you should notice the URL of this page is changing. The key is this portion below.

#change-background:990000

When we change the hash of the page, we aren't requesting a new page from the server, the browser thinks we are navigating to a new portion of the page. (Some people know that if there was an ID of change-background:990000 on the page, the browser would attempt to focus on that element) Because of this, it creates a history entry that we can use to track back button usage, and deep linking.

Note on browser inconsistencies

Now obviously not all browsers handle this the same way, thus we use a library which abstracts all these problems away from you and lets you only worry about your application. The library we are using here is RSH (Really Simple History). Here are a few other libraries you could use.

• SWFAddress
• History Event: jQuery Plugin
• HistoryManager: Mootools Plugin

Code

Lets look at the code necessary to implement this feature.

This is the HTML for the 3 buttons, some of the important things to note here.

• I tagged each button with a "post-internal" class. This allows me to create a generic function that attaches the history logic.
• I attached the history information to the element. I typically use the rel to attach information to elements, I don't know why, its just the way its always been done.
• I've added an href, so if the user doesn't have Javascript enabled, they could navigate to the separate index pages in the color directories which would know they need to color the page. This is certainly overkill for a background color change, but its one of the important aspects of unobtrusive Javascript.

Obviously the heavy lifting is in the Javascript.

This is the entire contents of my sample script file, so we'll go down through each section.

RSH creates itself in the property window.dhtmlHistory, so thats already going to be there for you. RSH uses some JSON to track its history data, so you'll need to supply it some methods for serializing and de-serializing. It does come with these methods in a separate file, but since Mootools already includes these, I just used the ones from Moo.

This you can go ahead and do outside of any events.

A bunch of stuff here, we attach our initialization logic to the window load event as RSH explicitly states

RSH will break, especially in IE, if you try to initialize it from any flavor of DOMContentLoaded.

Once in the loaded event, we call initialize to start the process, and then we add our listener. This listener function is what will get called every time someone hits the back button, forward button, or even the page being loaded with a hash value.

Inside the onload event, we add our onclick event for the buttons.

When the button is clicked, we use the add() method of RSH to add a new history entry. While the listener method is probably 40% of the logic you will need to provide to implement history tracking, this single call is the other 40%. Really those two features make up the meat of it.

The value we pass to the add needs to be descriptive enough that we can figure out what to do with the information in our listener event. In my example, I'm appending "change-background:" to the hash code, so when my listener fires, I know that it has the information I want (someone else isn't doing some other history tracking) and that I know what to change the background to.

Now when you add a history entry, RSH does NOT fire the history change event listener. (It really should, more later) So you need to also attach your logic for the event as well, which is a simple changeBgColor method with the rel information of the clicked on link.

Lastly, we don't want to actually go to the URL specified in the anchor tag so we use preventDefault() to cancel that.

This is our event that gets fired every time the history changes. When our listener here gets fired, it looks to see if any change-background information is in the URL, and then it parses out the hex value and calls the changeBgColor method.

With this method, you'll want to start thinking of the URL as a full description of the state of your application. The less you track in your URL, the less the user can bookmark to, and the less they can back button out of. The extent to which you implement this is totally up to you, and admittedly this could make your URL quite complex...

Gripes about RSH

I wanted to use RSH because its had quite a bit of development on it, so I assumed it would be a solid bug free library. Plus it has one purpose, Ajax applications history tracking, unlike SWFAddress which has some integration with Flash and thus feels like using the wrong tool for the job sometimes.

Though I have a big problem with it not firing the listener event when we use the add() method. Since we put all the information in the URL, and we have to write the listener method to parse that information and set the page to that state, there's no reason to put that logic anywhere else. Be aware you won't always have to duplicate your code like this in the other libraries, SWFAddress specifically.

One last note about Deep linking

When you implement the back button, you get deep linking for free. I know, you rarely get things solved for free, but since we are using the URL to describe the state of our application, when the page loads up RSH will fire off our listener event notifying us theres some information in the hash. From there, our application doesn't care how that information go there, its just going to operate on it.

Download Sample Code

Justise-BackButton.zip

This is the first version of the Demeter Group website, it's a flat HTML site with no CMS and has some usage of JavaScript to allow for in page browsing.

Some notes from this project.

• Working with people who you recognize is lots of fun. These guys actually worked with Method the soap company; GU2O is a product I've used in the past during my runs; and I keep seeing their products at various stores which gives me a sense of pride that in some small (very very small) way I contributed to the success of that product.
• I experimented with another layout for my JavaScript. I'm trying to find the right type of techniques for each different size of website; in this one I did a new class for each page, and since some of the pages were similar, I utilized a base class for those.
• On this project, I estimated about a day for the back button implementation as the last time I did it on Method.com it took forever. When it came time to implement it, it took about 2 hours. Now I've done it so many times, 30 minutes is enough time.
• Getting a new designer in the middle of the project sucks. Unfortunately the designer who created the design moved back to Seattle right before I started coding, so a new designer had to pick up where he left off. This wasn't fun for either of us as its hard for another designer to answer to the original designers intent.
• In JS Libraries like M and jQuery, you should use lowercase in your CSS selector searches. WebKit based browsers (Safari, Chrome) don't like the uppercase tag names. I really haven't investigated it, but I would assume the tag names are in lower-case and the libraries tend to use methods that do css searches that care about such things. (querySelectorAll, querySelector).

• Make sure you cancel your animations for mouse-over events if the user navigates to another element with an animation.
• Content is the hardest part of any project. Its hard to create, hard to plan for without, and rarely fits at the end.

For our latest project, we did templates for the Sun JavaFX website. One of the more common things they are doing over there is posting JavaFX samples and tutorials on how to program with the new framework. In so doing, they ended up doing quite a bit of lists and sub-lists. We all expected this not to be a problem, but when it came time to input the content we found the reset stylesheet was a little two agressive. 

Here is what you would expect a normal list with some sub-lists inside of it to look like.

Now after we've applied the following CSS ripped right from the Yahoo Reset css file, we will have killed all the bullets and numbers.

From here, everything seems kosher, except that we now need to add some bullets and numbers back in. From here it gets hairy. 

For all browsers except the one you love to hate (IE 6 -8) you can do this.

That will bring back the browser based list style inheritance.  Yet for IE, this doesn't work, you get no bullets/numbers at all. Certainly annoying, but we have to work past this, so lets think about a solution.

Then we have to account for UL's inside UL's being different and UL's inside UL's inside UL's... yea...

because what if the content developer needs to add another UL list? Sigh. 

So recently I've been either deleting this statement from the Reset CSS file, or having a special class applied to the bullet type you want, and then you just apply that to the list. This irks me in many ways, but IE tends to do that to me.

Day 2 was easily the most information packed and exciting of the 3 days.

IE8 was a Sponsor this year, yet their involvement was still quite small in the conference. They did have several speakers, but you can tell the conference is still being driven by the Sitepen (Dojo), Google (GWT, Chrome) and Mozilla (jQuery, etc) groups.

Faster then Light JavaScript

The opening talk was from Brendan Eich. Brendan is in a strange situation where is his the master and overlord of JavaScript, yet you can tell he's a bit more intellectual then the typical JavaScript guru. He focuses a lot about lower language constructs and less about closures and the like, which is just kind of weird.

• Tracemonkey
  • Incrementally Rewritten to be much faster
  • Now fast as almost anything.
• V8, SpiderMonkey
  • Both are very fast and really good codebases.
  • Getting Close to C Speed
• IE
  • Seaworthy (Showed picture of a beaten down houseboat)
  • Kind of missing in the JavaScript performance arena. 
• Whats it all mean?
  • Browsers get near native JS Performance
  • Mobile browsers too, without sucking massive amounts of power
  • IE being guilted/pressured into getting better
  • Developers make your voices heard!
• Canvas
  • Actual image processing capable
  • Ray Tracking Possible now, will be 3-4 times faster in 1 year
  • HTML5 Web Worker threads
• On the Horizon
  • CSS Transformations
  • CSS3 Selectors
  • Border image
• Trying to put SVG Back into the web (Though John Resig already voiced his doubts that without a hail mary miracle that SVG is pretty much a goner)

I'm trying to get this out the door, so here's some notes from the rest of the conference, very much abbreviated.

• YUI Test was showcased. Check out more here.
  • Still looks a little more complicated then it should be.
  • I think John Resig mentioned a testing framework as a Firebug plugin. That sees like the way it should be.
• Someone was using the tool Programmers Notepad, which seemed cool so I made a note of it.
• UX Design for Ajax Apps
  • Design is how things work.
  • The Design of Everyday Things (Recommended Book)
  • Instructions don't make things usable. 
  • Must do Research to determine usability.
    • Don't ask customers what they want, find out what they do.
  • Universal Principles of Design (Another Highly Recommended Book)
  • Tool: Kuler - Generates color palletes
  • Don't Pretend
    • Pretending to be the user means your pretending to be stupid, which just isn't possible. Clients aren't stupid in general, just when dealing with whatever you happen to develop/design.
    • Pretend instead to be the application.
• Performance from Yahoo
  • Amazon did a test and added a 100ms delay to the loading of their site. They experienced a 1% drop in sales as a result.
  • Yahoo did another test, adding 400ms to their load time, they recieved 5-9% drop in full page traffic.
  • Google, same thing, +500ms to their load time, 20% fewer searches.
  • Get YSLOW! It was an overarching theme of the session.
  • Flush the buffer early if you can, gets the browser working while the server does the rest of its work.
  • Use GET for Ajax requests.
    • Only 1 TCP packet is sent with GET
    • Post sends a headers, and posts body seperately and has a lot more content.
  • Post-load components
    • Whats absolutely necessary to render the page?
    • User percieves site is loaded after site looks visiually loaded. 
    • JS can load in after site looks visually complete.
  • Pre-load components (3 Different types)
    • Unconditional: Google preloads its results images on the google search page.
    • Conditional: On search typing, start preload of images.
    • Anticipated: Anticipating new release? Start pushing out those images for the next release early so the users cache isn't completely empty.
  • Avoid Filters (AlphaImageLoader)
    • Blocks Rendering of the page.
    • Increases memory consumption
    • New filter per usage, not per page.
    • Avoid completely if you can.
    • Use PNG8, works just fine, no grey background, but boolean transparency only.
  • PNG8 Does support alphatransparency, and in IE8 the alpha-transparent bits will show as completely transparent. Didn't understand how to get this to work though, they were vague on it.
  • IPhone
    • Total Cache 1024k
    • 25kb limit on a single file no longer exists.
  • Look out for your users (Don't hurt your users speed)
  • Harvest low hanging fruit
  • Balance features with speed
    • They explained this as, balance the perf budget.
  • Verify Assumptions!
  • Make Perf part of your process.
  • Measure and track results
    • Firebug
    • IBM Page Detailer
    • YSLOW
    • Gomez
    • Smushit.com
  • Ask Questions and Challenge answers

Keynote

This was a pretty similar keynote to the one last year. 

• There was a brief mention of UX being crucial to the evolution of great, but no more follow up.
• Ben and Dion did this thing where they setup a random buzzer and when it sounded they would trade off on who was speaking. Sure kept things interesting. 
• More of a hello, this stuff is exciting talk.

We (as in Method SF) were pulled in about 2 weeks ago to help out on a project that was frankly going into the toilet, quickly. The team had estimated about 8 days of work, for 3 developers to get it all done, and it turns out they were just freakishly optimistic.

The first thing that happens is that our two best flash guys get immediately put on the super hard feature of the site which is this fancy flash video selector.  Then, me and another guy get pulled in to do QA on HTML templates, which have yet to be integrated with the system. Finally, we pull in the last remaining guy on our tech team who wasn't involved with the project (now 5 of us) to do additional QA and help out any way he can.

Now besides the fact that we know this is a recipe for failure (people go around quoting Mythical Man Month, and something about 9, 1 month baby's) we still think it is the only way to get the project done by Monday. No not this next Monday (its Tuesday as I write this) but yesterday, which was supposed to be the end of development and the start of QA. They actually worked over the weekend to try to his this date, which doesn't seem that silly but it gets more ridiculous.

They worked over the weekend, did a whole bunch of work, but it still turns out we won't be ready to integrate what we are doing in our office with the other groups work till Thursday. We don't actually expect to be done with development till Friday, and of course they are presenting to the client on Monday.

Now if its a little hard to understand the big WTF here, the gist is that they plan to code 12-14 hour days just to get every feature implemented by Friday, so they can show the client their nearly finished product. The expectations here are not beta quality, but QA complete, getting ready to ship work. That's never going to happen. The project will be smoke, mirrors, and most likely a Blue Screen of Death.

Monday also happens to be the day that the other group is planning to start phase 2 of the project, with a whole new set of requirements. Not only do they plan to be finished with the current site, they want to add on a whole new batch of work, basically making a QA pass impossible.

All through this process we've made attempts to get the left over work estimated and real expectations set, tried to get the customers expectations modified, and basically try to do everything in a smart intelligent way considering we know that the site won't actually be ready when everyone is really really hoping it will be.

Hoping won't change reality, if there are 10 people working on 30 features, and its going to take a month, then stop hoping and start doing something productive. Like managing the client, telling them you F'd up and that its going to take longer then expected.

I can't believe I'm on a project like this, absolutely horrendous.

 

Stackoverflow is sort of like the anti-experts-exchange (minus the nausea-inducing sleaze and quasi-legal search engine gaming) meets wikipedia meets programming reddit. It is by programmers, for programmers, with the ultimate intent of collectively increasing the sum total of good programming knowledge in the world. No matter what programming language you use, or what operating system you call home. Better programming is our goal.

 

The core directive Jeff and Joel set out to address was the issue of a good place to go for development knowledge. If you had a question, there should be once place that you know it should either be answered already, or shortly after you ask it.  

Jeff even goes as far as putting up a witty inspirational image with the caption STACKOVERFLOW: None of us is as Dumb as All of Us. Which again references that knowledge-base aspect of the site.

But I'm finding the real value in this site is actually for entertainment purposes. I probably take a break 2-3 times a day, and with my iPhone, when I'm waiting for a meeting or Appt., I can be just browsing the internet 10-12 times a day just killing time. For me to be able to browse StackOverflow and check out what the latest greatest questions that have been asked, questions that I might be able to help out with, or just questions with funny answers that means I get to do more then kill time reading Digg I actually get to learn as my entertainment. 

With that in mind, I think you could take the following Venn diagram Jeff uses to describe the site, and move the Digg/Reddit circle right on top of that asterisk.

From their website...

The AJAX Libraries API is a content distribution network and loading architecture for the most popular open source JavaScript libraries. By using the Google AJAX API Loader's google.load() method, your application has high speed, globaly available access to a growing list of the most popular JavaScript open source libraries

Ignore that part about the google.load part, its really not necessary and just makes you include a JS file thats not really needed. The usage page provides URL's for you to include on your page that load either the full version of the library or a YUI compressed version.

The important bits of the above quote really though are

• Content Distribution Network for one of your JS files, usually one of the larger files.
• As browsers have limits to the amount of files they can download from one domain, this allows the browser to download this file while it otherwise would have been waiting in the download queue.
• Files are cached based on their URL, and if you would have happened to already have visited a site that uses this same library and version of that library then you'll skip downloading it on this site. Thats right, partial page caching, even if you've never visited the site.

After news of this feature broke, we had a large email chain at our office about putting one of the most core files for your site out of your control. Back and forth we went, even some snide remarks, but essentially theres no way around the trust issue. You can have your own backup plans for if the file isn't included, but now your adding complexity for a relatively small gain, and at that point you might as well just include a local copy of the library and skip the Googl eAPI completely.

The Google API supports 5 (4 really) libraries that you can remote load this way.

• jQuery
• prototype
• script.aculo.us
• MooTools
• dojo

Though unfortunately MooTools is a little behind the times.  1.2 was announced on June 12th, thats a month and a half ago from the creation of this post and its still not in the Google API. I checked the other libraries and they are all up to date, but haven't been updated since this service went live. So we don't yet know if this is a service that will be going stale as time progresses.

So it turns out, it doesn't work. Not only does the font-family not get inherited but any other rules you specified get ignored as well.

Super annoying.  So I did what any good citizen would do. I complained.

Bug: #448142

The great thing about FireFox is that if they decide to fix this issue, they can have it pushed to the general public of FireFox users and this issue could be eradicated in weeks time. So here's hoping.