asgaard

Figure out which element is scrolled to jQuery

Mon, 23 Apr 12 20:39:46 +0000

Does what it says on the tin. It takes a set of elements and tries to determine which one is featured most predominantly on the page. Change the $sections selector (line 3) to target the element-set of your choice, or rewrite as a plugin :)

Towards the bottom, the element which is deemed to be in view will be given a 'highlight' class.

Note that we are binding directly to the scroll event which is generally a bad idea. Whether it is a bad idea for you depends upon various factors. If you find it negative impacts performance on your page, factor out the scroll event and call it after a short timer (and cancel the timer on the next scroll).

(function() {
  "use strict";
  var $sections = $('.panel'),
      $sectionsReversed = $($sections.get().reverse()),
      $last = $({});
  
  $(window).scroll(function(ev) {
    var pos = $(document).scrollTop(), 
        $nearest = $sections.eq(0),
        amount = 0; // amount of the screen occupied
        
    // scrolled to extremes - take the top or bottom element as appropriate
    // There's a little bit of leeway on the bottom scroll detection as 
    // Firefox sometimes seems to lose a pixel.
    if (pos === 0 && false)
      $nearest = $sections.eq(0);
    else if (pos >= $(document).height() - $(window).height() - 10) {
      $nearest = $sectionsReversed.eq(0);
    }
    // otherwise do something a little cleverer
    else {
      var windowHeight = $(window).height(),
          start = pos,
          end = start + windowHeight;
      $sections.each(function() {
        // we're going to try to figure out which element
        // takes up the important parts of the screen.
        var $this = $(this),
            top = $this.offset()? $this.offset().top + $this.outerHeight() : //IE?
              $this.offset().top,
            bottom = $this.offset().top + $this.outerHeight(),
            topVisible = top >= start && top <= end,
            bottomVisible = bottom >= start && bottom <= end,
            candidateAmount = 0;
            

        if (top <= start && bottom >= end) {
          // occupies entire screen
          // we have a winner
          $nearest = $this;
          amount = 1;
          return false;
        }
        // no part of the element visible - nope
        else if (!topVisible && !bottomVisible) return;
        
        else if (topVisible && bottomVisible) {
          // full element is visible. We'll take this one
          // since it's highest on the screen.
          amount = (bottom-top)/windowHeight;
          $nearest = $this;
          return false;
        }
        else if (bottomVisible) {
          // occupies part of the screen from the top down only
          candidateAmount = (bottom - start)/windowHeight;
        }
        else if (topVisible) {
          // occupies part of the screen from the bottom up only
          candidateAmount = (end - top)/windowHeight;
        }
        
        if (candidateAmount > amount) {
          amount = candidateAmount;
          $nearest = $this;
        }
      });
    }
    
    if ($last !== $nearest) {
      $last.removeClass('highlight');
      $nearest.addClass('highlight');
      $last = $nearest;
    }
  });
  $(window).trigger('scroll');
})();

Design and Usability on the Web

Sun, 22 Apr 12 20:40:55 +0000

I have a problem with a lot of the UI widgets being deployed on websites.

Many web effects focus on *hiding* information and dedicating a large percentage of screen estate to showing the controls for showing the information. This is really silly. Sometimes there is a risk that you are showing a lot of information that the user isn't interested in and finding a way to filter it is a good idea, but let's be honest here, the main driving force behind most of these effects is that someone thought it would look good, not that it would improve usability. What usually happens is we reinvent a worse way to show information than simply laying it out flat on the page.

As developers and designers (I'm not a designer), *we* aren't in the same position as users because *we* couldn't care less about the content on the web page. We want to make the site look good and/or work, but we don't actually want to use it or read the content. This means that we often don't consider how annoying it is for a user to have to click 10 different things to get a general overview of the full information s/he's interested in. Particularly if it's for a client rather than for our own users.

On a site we did recently for a company, we had on the home page 13 different images in a horizontally scrolling element which showed approximately 2.9 images at a time. Each of these images had a title and a summary which was of some descriptive relevance to the company and by extension, of interest to its stakeholders/visitors. The image was just a simple single colour logo, not a photograph or anything like that. The way the 'design' worked was that you had to hover over each image to get the information to pop up

I implemented this (for reasons that are long and complicated), and I got a few comments of "oh yeah, it looks really good" from other people in the office. I think this demonstrates pretty well the disconnect I'm getting at. It wasn't really good at all, it was a UI nightmare. The user is presented with 2.9 cryptic logos and has to hover over each one to get any idea what it means. On the last one, they only get to see 0.9 of the text without scrolling a bit further (okay that was a design oversight). If they are interested, they have to go through this process another 4 times to see the whole set, and the fact is they might only be interested in two or three of them, which probablistically aren't going to be adjacent, so they'll have to keep scrolling back and forward through this initially interesting but now hugely annoying element.

Another good example is the lightbox, which might be acceptable in rare circumstances but generally the lightbox is awful. I hate lightboxes. If the page genuinely, and I mean *genuinely*, needs to request some user interaction before it can *genuinely* continue, then so be it, but that's a pretty rare circumstance on the web, and more often they're used to display secondary content or make the user respond RIGHT NOW to something that could have been done in a much less obnoxious manner. I see really stupid arguments for lightboxes being used for user interaction like "it lets the user focus on x without getting distracted". There is nothing more annoying than a piece of software that thinks it knows better than its user, except possibly for a piece of software that thinks it knows better than its user AND treats them like an idiot.

As for content, Lightboxes are far worse than simply opening a new browser tab because they replace useful and expected user interface functionality provided by the browser with something much less powerful, less standardised, and generally much worse implemented and much more flakey. If you open a new browser tab, you still get all the browser controls. You can still flick between the two tabs/windows. If the lightbox is used to request user interaction then there's a good chance that whatever you're requesting is coupled to the page you just made unusable and the user would have preferred to be able to view your page before deciding what to do (or whether to do anything at all) - and if it's not, then why have you interrupted that page at all?

It's another attempt at hiding content and making it as frustrating as possible for a user to interact with your page and view its content in the way they expect to be able to, for the misguided end result of making your page stand out. It does that, I guess, but not for the right reasons. I don't think I have ever seen a situation online where a lightbox has genuinely been a good choice outside of occasionally content-authoring situations (e.g. inserting an image from a media library into a rich text editor). If you need user interaction, you should be doing it like (for example) Grooveshark does, by popping up a little widget in the corner. My own jKnotify(Ui)? provides unintrusive notifications in a similar way. You don't have to use it. I'm sure there are others. But the concept demonstrated is how such dialogue should be done.

Free private git repositories

Sun, 08 Apr 12 21:15:01 +0000

I hadn't realised this until now, but it turns out that Bitbucket offers free private Git repos. I thought Bitbucket was just Mercurial, but evidently not. Free users get unlimited private repositories; the restriction comes in that only 5 developers may access any one repository, which is still very generous.

Most of my code is public on GitHub (who want $7USD per month for 5 private repos), but very occasionally it makes more sense to keep something private.

In related news, it's been fun here with the Easter holiday to be getting back into some real development in my own time. Ironically, since I started getting paid to do it 40 hours a week, the amount of development I've been doing has fallen greatly, and in the evenings it's generally more tempting to boot up TF2 or Tribes Ascend than to start anything particularly mentally taxing. I'd almost forgotten how much fun it is to code on Linux and to do something more interesting than just fiddling with layouts and occasionally hacking a CMS all day.