Pages

Friday, November 23, 2012

HeadJS Site Redesign

Currently working on a complete redesign of the headjs.com website.

At first i actually wanted to do the redesign by using Twitter's excellent Bootstrap framework, but after a little testing and thinking things over i thought it was a shame to be publishing a micro responsive-design framework, and then using someone else's code to design the site :-/

So, the site will be responsive, and mobile handset browsable, however all responsive parts are powered by HeadJS itself !


The site will be broken down into 4 pages

  • About/Pitch
    • Quick intro to what it is
  • Api Documentation
    • Complete step by step documentation of each feature of the responsive design & loader parts
  • Test Page
    • Unit Test
    • Habitual test pages top, bottom, src, head
  • Download
    • Quick Downloads
    • Full featured builder to customize everything 

Here's a screenshot of the work in progress of the builder



Looks simple enough, but the "Responsive Configuration" section originally took up almost as much space as in the screenshot above, but was only exposing the screen breakpoints section !

Now it's basically the head_conf section pasted into a <pre> with lots of dynamic stuff tacked on top.

It's just a question of hovering over a variable, double clicking to toggle a bool, or clicking the little plus sign to add a breakpoint ..much simpler to use i find.


Some new features i've been playing with that might or might not make it to v1.00 are:

  • Change min/max browser breakpoints into an array
    • Like this you don't have to cycle from Chrome8 to Chrome25 if you only want to generate some special use cases for Chrome8 and Chrome18
  • Report current browser and current version systematically no matter what breakpoints are defined
    • Performance wise it costs nothing, and there's a good chance that that's enough for 90% of users out there, without having to enable specific browser breakpoints
  •  Clean up CSS Router generated classes
    • More specifically, remove dots in class names
  •  Playing with hashchange() a bit and evaluating if it's worth adding a class that targets #hashes from the url
    • Should be pretty trivial to add something that works all the way back to IE6
  •  Then there is also v2.00, which will switch api usage around a bit, since if we include height classes (which i personally find is a must have) we of course can't continue with a simple lt800, gt800, but will have to differentiate h-gt800 & w-lt800
  • Feature detections have also been broken out of the css3.js, and are now using a npm style package system. Packages are read directly from the source control and injected into the builder on the fly.
    • This will make it wayyyy easier to contribute feature tests to the project, and also always have a up to date listing on the builder page

Packages are as simple as writing this (geolocation.json):
{
   "name": "geoLocation",
   "test": function() {
      return "geolocation" in navigator;
   }
}

And in the root of the source control, we have a (inventory.json) that contains, among others:
{
   "id"         : "geolocation",
   "title"      : "GeoLocation",
   "category"   : "browser",
   "description": "Test for browser geolocation support",
   "package"    : "features/browser/geolocation.json",
   "url"        : "http://caniuse.com/#feat=geolocation"
}

Things are split into 2 packages on purpose for the sake of size, as inventory.json is just a descriptor file used by the builder to get packages and expose complementary information.

Another cool thing about the builder, is that it's a client-side only solution. Everything from loading packages, minification & bundling, to triggering the final download dialog is completely JS driven, and works rather well in IE, FF, and Chrome.


Well, that's about as much as i can think of for now.

Till next time!
Robert