identifying the problem

As we have seen before, long pages work. But we always have an issue in the process: if one wants to navigate to other section of the site you have to scroll all the way up or use your other hand to hit the [Home] key.
Given that the average internet user (I would say more than 90%) use their mouse to browse the web, either having to use your other hand and hunt for a key, scrolling up repetitively or clicking on that very top portion of that 16px wide scrollbar adds complexity to the task we are doing and decreases our efficiency.
Users love to hunt for information from page to page, and our task as user experience designers is to give them the tools to ease their stay.

the wrong approach

The classic solution of spreading links all over the place has great design, usability and accessibility problems.
From the design point of view you either come up with a clever way to disguise the links or just leave them out there clogging the visuals. Not good either way!
Usability wise, do you really know when the user wants to go back to the top of the page? Is there a need to spam the user with back to top links?
And that spamming also means for decreased accessibility, screen reader or keyboard users will be constantly spammed with those meaningless links. They already know how to get back to the top of the page without the need for your "shortcuts".
Shouldn't there be a wiser and cleaner solution?

developing a solution

Fortunately, there is a fairly good solution. And armed with a bit of javascript and standards compliant CSS we can pull the trick.
Did I just say javascript? why, yes! The back to top link is a navigational aid for mouse users and not real content in your page, think of it as an escape pod for when you want to get away from the current page.
When developing this together with Nicolas Sanguinetti for Operator11 our main goals were:
- keep it clean
- be unobtrusive
- keep it usable
The final solution ended as a tiny piece of code written with the aid of Prototype.
However as you may know, my personal and professional focus is into the mootools library and for this reason the solution presented today will be an adaptation from the original code.

methodology and code

Q: So when should we show the back to top link?
A: Once we think the user needs it.
Getting this metric can be a bit tricky and it's mostly arbitrary, but we finally settled for 80% of a full page scroll. It's around this point that we need at least two mouse wheel scrolls to reach the top and hitting the back to top link becomes more efficient.
the javascript:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

window.addEvent('load', function(){
  new Element('span', {
    'id': 'back-to-top', 
    'styles': {'opacity': 0.6},
    'events': {'click': function() {
      if (window.location.hash) { window.location.hash = "page"; } 
      else { window.scrollTo(0, 0); }
    }}
  })
  .setText('back to top')
  .injectInside(document.body);
 
  window.addEvent('scroll', function() {
    var fn = window.getScrollTop() > (window.getHeight() * 0.8) ? "addClass" : "removeClass";
    $('back-to-top')[fn]('visible');
  });
});

and this simple CSS:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

#back-to-top,
#back-to-top.visible {
  display: none;
}
 
body>#back-to-top {
  position: fixed;
  bottom: 0;
  right: 0;
  cursor: pointer;
  padding: 3px 17px 3px 7px;
  font: bold 14px Arial, Helvetica, sans-serif;
  color: #fff;
  background: #555 url(triangle-gray-up.png) no-repeat right center;
}
 
body>#back-to-top.visible {
  display: inline;
}

pitfalls and caveats

Just a few notes on usage and explanation of the methodology are needed.
The code as you see purposely ignores IE6 as it has inexistent support for position: fixed. By using a CSS2 selector we gracefully degrade and ignore that browser and only display the link on standards compliant browsers.
There is also another issue with IE (6 and 7) that throws the infamous Operation aborted error and it's the reason behind using the onload event instead of ondomready.
Last, but not the least, removing the hash part in the URL reloads the page instead of just cleaning that part of the location. This happens *at least* in Firefox and it is enough to conclude that setting window.location.hash = "" is not an option. For this is that we check the existence of the hash in the current location, and if not present we scroll to the top with javascript or else we set the location to the topmost element in our page.
Be warned then, that if you use internal anchors in your site, you must have an element with an ID at the top of your page, preferably the body tag.
For the curious, we re-set the hash part just for bookmarking purposes. If you hit the back to top link, then you are supposedly at the top and not on #someplace in the page.

compatibility, download and legal bits

The code is tested and works under Firefox, Opera 9, Safari 3 (both Windows and Mac) and Internet Explorer 7.
As for mootools, you just need the "Element.Event" and "Window.Size" modules, pretty much standard stuff.

By the way, you should have already noticed the back to top link in action in this post, feel free to try it out before leaving your comments ;)

Download back-to-top.zip

License: Creative Commons Attribution-Share Alike 3.0

2009/02/27 – Update: The original code above was originally intended for mootools 1.11 (bleeding edge at that time in 2007), but given that 1.2 has been out for a long time I guess it's time for a quick update for mootools 1.2.x
I also took a few minutes to clean-up the CSS (no more CSS2 descendant rule to hide from IE6) and moved the "fixed" styles to the Element creation in the JS. Now all that remains in the CSS is the customization on font, color, padding and background. The effect now also uses a fade in tween if it's available in your custom Mootools build.
Download back-to-top for mootools 1.2.x [zip]

addendum: original Prototype code

Being that I was struck by a very strange bug in mootools 1.11 a lame overriding of the addEvent function by the Wordpress.com Stats plugin, I'm putting here also the original Prototype-based implementation either for comparison or just for those Prototype users out there:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

BackToTop = {
    initialize: function() {
        document.body.appendChild(
            BackToTop.link = new Element('span', {id: 'back-to-top'})
                .update("back to top")
                .setOpacity(0.6)
        );
        BackToTop.link.observe("click", BackToTop.onLinkClick);
        Event.observe(window, "scroll", BackToTop.onWindowScroll);
    },
    onLinkClick: function() {
        if (window.location.hash) {
            window.location.hash = "page";
        } else {
            window.scrollTo(0, 0);
        }
    },
    onWindowScroll: function() {
        if (document.viewport.getScrollY() > (document.viewport.getHeight() * 0.8)) {
            BackToTop.link.addClassName('visible');
        } else {
            BackToTop.link.removeClassName('visible');
        }
    }
};
Event.observe(window, 'load', BackToTop.initialize);

notice that this was first written to be a LowPro behaviour (and fitting more of Nicolas' coding style) but given the Operation Aborted bug in IE we reverted back to plain Event.observe from Prototype.

And no, it's not a problem of being a newbie in wordpress, it's just that there's too much duplicated code revolving on the structure, at least on the default Kubrick theme that is supposed to be the one that shows off most of wordpress "features".

the first challenge:

adding a wrapper around the content and sidebar.
This could have been easy, if only I didn't have to dig through six different files and manually inject the same code on each one of them. Yay for templates!
Come on wordpress staff, you can do it better, i want my header, footer and basic layout on *every* page of the site *unless* I specify the contrary, it's a big let down if my "templated system" makes me go through every top-level page to inject two lines of code on each of them. Learn from Ruby-on-Rails, CakePHP or Symphony, where you specify your top-level layout and it's used site-wide unless you direct the framework not to do it.

on the second day, God created blog entries:

and did it the wrong way. The same issue as with the layout, was now worsened with entries. I had to dig through five different files to *try* to unify the way entries were to be displayed on every page of my site. Appart from being tiresome it's horribly error prone, what get us to the third point…

there's no f*cking undo:

if you mistakenly hit the "update file" button in the middle of an edit while there are still errors to fix there's no way to go back. Even worse, I was editing my CSS externally and copy&pasting on the wordpress admin the whole stuff… all was fun and games until I accidentally overwritten the Main Index Template. Poof! all my previous edits gone without a single undo button. How hard could have been to implement an undo feature like the one in gmail?

now *that* is something to write home about

the sad conclusion:

after going through all of this I figured out I went with the wrong blogging software [duh!].
However, it's too late to go back and start from scratch. May be next time (or when free time is on my side again) I will choose another blogging software suite.
And yes, I think the same as you: this is the saddest attempt at a first blog entry in the whole history of the blogosphere… so be it! :)