La Sportiva Vapor Nano Review

I recently (yesterday) had a chance to demo the Nano at Smugglers' Notch Vermont during the Backcountry Demo days. Conditions were very mixed - with some mashed potatoe style powder, breakable crust, hard pack and bumps. I was using a pair of BD boots w/ a tech binding. I'm 5 10 and 155 pounds. Pretty good skier.

My standard setup is a pair of older Dynastar Legend Pro's with a Marker Duke binding. My immediate reaction to putting the Nano's on was "holy shit, these are light". Not just a little bit lighter, but light like "did these fall off my feet by mistake light". Freaky light is the only way I can put it.

First run was down some well skied main lines and I found the ski to be pretty scary at speed on hard pack. The lightness let the ski get pushed around a bit by bumps and bits of crud and I had to really control my speed to stay happy.

Next run was down a very steep mixed (some packed, some ice and some mush) chute - narrow enough to require jump and fast turns. Here the skis were both amazing and scary. The ease with which I could snap the ski around from one landing zone to the other was incredible. With some practice I think I could probably make a 4' vertical leap with these things on. Make a jump turn or quick chute kick turn was stupid easy and I found myself just jumping over obstacles that I might have side stepped over normally.

Again - the light weight was so incredibly light that I didn't feel terribly secure when work across the fall line on ice and hard pack, but the maneuverability was pretty amazing.

Last run was through a combination of fresh spring 'powder' (think sierra cement) and some breakable crust. Here the flex pattern and weight really came into play - with the tip riding up and over nicely. Tail seems stiff enough so that I could get out of the backseat pretty easily. Excellent float.

My take away was that these would be ridiculous to have on a nice powder day in the back country - really easy to skin up with and sweet through trees and pow. As an inbounds and out of bounds ski they are just too light to be trust worthy (not to mention I'd hate to break a $1,200 pair of skis skiing shit conditions).

For really steep skiing I'd again want to have a little more substance under foot.

-bill

Responsive web design and form fields

Love them or hate them, entry forms and form fields are a part of life. Sign up, registration, log in, purchase, update, contact us... the variety of forms we encounter online today are endless.

As the prevalence of online forms increases, so do the variety of devices people are using to view and complete online forms. From desktop devices to iPhones, iPads, Android devices and Wii browsers it is becoming increasingly important to ensure that online forms can be easily completed from any device.

I was reminded once again of the importance of multi-device testing when developing forms and form fields  last month when testing (just prior to launch...) a simple online comment submission form. The page we had developed had a fixed footer which was 'glued' to the bottom of the web page so visitors would always have access to important site links while they were browsing the site.

<screen shot 802 quits>

When testing an entry form from desktops this footer served as a nice graphical element and didn't interfere with the entry process. The problem was that when viewed on an iPad or iPhone, clicking on the text area entry element caused the entry pad to appear behind the fixed footer - rendering it impossible to complete the form. If we hadn't tested our form on an iPad we would have never discovered this bug.

After sorting out this issue (we simply modified the footer on the form page to be at the end of the page as opposed to fixed to the bottom of the window) I began searching for best practices for form field management across multiple devices. Creating a truly responsive and multi-device optimized form turns out to be quite challenging and is a topic for multiple blog posts.

For starters I want to focus on a single type of form field - date entry. Developers typically use some sort of JavaScript based date picker to 'enhance' the user experience by spawning a graphical calender on click (see example below).

The problem is that when this same code is used on a mobile device you end up seeing:

Clicking on the date field causes both the calendar graphic AND the input type pad on the iPhone to appear - rending them both unusable.

There are several possible solutions - ranging from complex to easy.

The complex and ideal solution is to take advantage of the fact that all mobile devices can now read HTML5 form field types - like date.

Creating an entry field for this example would use code something like:
<input type="date" name="pickme">
Clicking on a form field coded like this on an iPhone or iPad would cause the native date picker function to appear on the iPhone - giving you a nice input experience like this:

The problem is that not all browsers understand an entry field of type "date" so you have to allow for both HTML5 friendly browsers and those that aren't. This requires using some more Javascript wizardy and writing a function to cause either the native date picker or our fancy graphical date picker to appear depending on the device.

It turns out there is another simpler solution. We can simply add the "readonly" attribute to the example we first encountered. Adding this attribute makes the iPhone keypad stay hidden, while the graphical calendar appears.

The result is shown below:

Because I like my graphical date picker better than the native iPhone date picker, this is my preferred solution.

Next time you are using your iPad or iPhone to enter dates (hotel reservations or airline bookings are my favorite test cases) pay attention to the behavior of the date fields. You'll immediately be able to tell if the developers were thinking responsive when they put together the code.

Next topic - optimized number entry fields.

Happy coding.

Jquery sparkline does not work when loading remote HTML content

To speed the load time for a page on my site I use jquery to load a remote page that contains usage statistics and a usage chart.

By allowing the primary page to load first - and then loading the stats content separately I was able to dramatically reduce the primary page load time - improving user experience.

The page's initial design loaded the stats content in line and displayed one of the elements using sparkline.js:

class="sparkline" data-values="1,2,3"

The problem was that when I loaded this content using:
$(document).ready(function(){ $("#people-list").load("stats-source.asp");
The sparkline js wasn't applying to the remotely loaded content. The solution was to fire the sparkline JS again after the content was loaded: <script> $(document).ready(function(){ $( "#stats" ).load( "stats-source.asp", function() { // alert( "Load was performed." ); $('.sparkline').each(function(){ var $box = $(this).closest('.infobox'); var barColor = !$box.hasClass('infobox-dark') ? $box.css('color') : '#FFF'; $(this).sparkline('html', {tagValuesAttribute:'data-values', type: 'bar', barColor: barColor , chartRangeMin:$(this).data('min') || 0} ); }); }); }); </script>
By applying the sparkline js function after successful load, the sparkline appeared just fine on the HTML loaded sparkline data.
Happy coding.