archive.rollingstone.com – another feather in our cap

With the successful launch of the new iPad-enabled Rolling Stone Archive, I figured I’d take the time out to congratulate our client, Bondi Digital, and my team at Applied Information Sciences (AIS): Jim Jackson, Robin Kaye, Ian Gilman and Siva Mallena  (with additional help from Leslee Sheu and Kevin Hanes).

Built on the same technology that we used to launch i.Playboy.com, the Rolling Stone archive combines our Silverlight viewer and the Html5, touch-optimized iPad viewer in a single site, sharing peripheral components such as menus and search features.  Per client requirements for Rolling Stone all desktop users will get the Silverlight-based viewer, with its keyboard and mouse integration, and deep zoom of images, while iPad users are automatically switched to the Html5 viewer.

Building and optimizing a highly graphics intensive app like this for the excellent, but admittedly limited, iPad browser has been a thoroughly enjoyable challenge. Showcasing our work to the public through another premier publication like Rolling Stone makes it all the more satisfying.

Our team is already onto the next publishing project – stay tuned…

Practical example of jQuery 1.5’s deferred.when() and .then()

"“Fun with jQuery Templating and AJAX” by Dan Wellman is a generally interesting article, but I found the code in the “Getting the Data” block especially interesting – see how each get function RETURNS the $.ajax function call, which can then be called inside a when() function, vastly simplifying the workflow (there’s an error in the listed code – getTweets() is supposed to return the ajax function, not simply execute it).

http://net.tutsplus.com/tutorials/javascript-ajax/fun-with-jquery-templating-and-ajax/

Even more interesting is this pattern, suggested by commenter Eric Hynds (whose blog has now been added to my Google Reader list):

http://net.tutsplus.com/tutorials/javascript-ajax/fun-with-jquery-templating-and-ajax/comment-page-1/#comment-357637

$.when( $.get('./tmpl/person.tmpl'), $.getJSON('path/to/data') )
   .then(function( template, data ){
      $.tmpl( template, data ).appendTo( "#people" );
   });

The deferred.done() and then() methods will take as arguments the results from each function called in the when() function – in order – i.e. the output of the get will map to template, and the output from the getJson will be mapped to data.  This is pretty sweet!

Perhaps a simpler to observe example of the behavior is shown here: http://jsfiddle.net/austegard/ZaFVg/ - no prize for correct guesses as to the result of this…

/* Hello and World are both treated as resolved deferreds - they 
can be replaced with any function, like a $.get, etc */
$.when( "Hello", "World" ).then(
   function(x, y){ alert(x + " " + y); }
);

"Microsoft has completely lost the web development community."

Last year Mark Pilgrim released a free e-book/site called “Dive Into Html5” (http://diveintohtml5.org/).  The site/book has served as a valuable resource on a recent Html5 project we’re working on here at AIS, and I have frequently gone back for details on topics such as local storage and canvas.  It is an excellent book for any bleeding edge web developer.  It is so choice. If you have the means, I highly recommend picking one up.

This week, Mark posted his observations on how publishing a free e-book (which is also purchasable in print format) works well for him, and that it gives great insight into what parts of the book are being read, and by whom. He then makes the following observation:

6% of visitors used some version of Internet Explorer. That is not a typo. The site works fine in Internet Explorer — the site practices what it preaches, and the live examples use a variety of fallbacks for legacy browsers — so this is entirely due to the subject matter. Microsoft has completely lost the web development community. (emphasis mine)

I forwarded this internally within AIS, and a nice debate ensued.  One common complaint was the hyperbole of the statement, and I agree; a more accurate line would likely be "Microsoft as a browser vendor has lost significant mindshare in the bleeding edge web development community."

Personally one of the things I love about Html5 (using the term the way the hypers would – to mean modern web development with client-driven UI interactions using JavaScript, CSS(3) and some HTML5 semantics) is that it has in some ways unified the web development community:  The debate a few years ago was about JSP vs .NET vs PHP vs Python vs Rails vs someotherservertechnology.  Folks from different camps seldom interacted and learned from each other.  With Html5, the backend processes are completely irrelevant, as long as they don’t muck with the Html (ASP.NET webforms is still a major sinner here, unfortunately) and developers using all sorts of backend software and operating systems are now adding to the collective knowledge, mostly working towards the common goal of getting as much functionality as possible, pushed to end users through mostly standards compliant browsers. 

For instance, our Html5 app is backed by ASP.NET MVC 2 and SQL server.  We do all our development on Windows, in Visual Studio – we’re looking to deploy to Azure.  Clearly we’re MS developers.  But we could just as well have done the app in Php against MySql running on linux and apache, and we’re taking cues from folks using python, java, Rails, Node.js, php and God knows what on the backend.

At the same time I haven’t used IE by choice for about 5 years, maybe more…

I was asked what I thought MS could do to gain back some developer mindshare – so here goes:

• My thoughts are that if Html5 and the set of bleeding edge technologists that go with it are any kind of priority for MS,  they need to do some or all of the following:
• Find a way to upgrade the legions of IE 6, 7  and 8 users to IE9.  This will obviously not be easy,  but they could do something similar to what Google did with Chrome frame (i.e. make IE9 a plugin for the older browsers),  or they could do something like the makers of the “IE Tab” Chrome and Firefox extensions do,  allow IE to be hosted inside Chrome,  and only activate it for certain sites.  Or let users install IE9 side by side with the older versions.   All of these would have as goal to encourage end users to use the latest possible browser for the task they need it for,  and to make them install IE9 instead of Chrome or Firefox.
• Make IE9 the paragon of standards compliance.   (They are actually getting close to this...)
• Bring IE9 to WP7 and whatever tablet software they're coming out with.
• Reduce the focus of Silverlight as a browser plugin,  and make it more about web-deployed desktop apps.
• Drastically improve the support for css and javascript in Visual Studio, including debugging and unit testing.   And give this toolset away in the form of VS Express.
• Evolve the Dev tools in IE9 to become better than Chrome's inspector and the Firebug plugin.
• Separate the IE development from Windows to allow quicker iterations
• Do more things like the jQuery deal. The world of CSS is a mess (we desperately need mixins and code forks like those provided by media queries), MS could take the lead here…

The point is, whether Mark’s browser percentages are statistically valid as an indication of web developer’s preferences, or to what degree Microsoft is lagging/losing developer mindshare; these are not the pertinent questions.  The fact is that Microsoft is now not a leader in emerging web development areas – maybe they never were – but should they want to be, they need to take action. IE9 is shaping up to be a great browser, and they need to push it aggressively.

Undersore.js Performance Tests Revisited (this time with pretty charts)

Out of sheer vanity, I added my own blog feed to my Google Reader, as I was curious if anyone ever Liked my posts.
Answer: Nope. :-(

Anyhow, I came across my post on Underscore.js, and since MS just dropped Platform Preview 3 of IE 9, I thought I’d redo the comparison in Chrome6, IE8 and IE9 (though I know this is hardly any complete benchmark test, it’s still telling).  The results are below: 

As I said in my last post, I can’t wait for IE9 to replace every previous IE version…  I haven’t been this excited about an IE product since IE4, which was more than 10 years ago.

IE 8 – still a dog.

IE 9 PP3 – Starting to look good!  Faster than Chrome in some tests!

Chrome 6 – still the winner in most categories, though the lead is shrinking

Bottom line, though – if you’re doing a lot of looping/mapping, you should use Underscore rather than jQuery.

MOSS: Add Incoming Links to a Wiki Page with jQuery

Sharepoint’s wiki implementation is rudimentary, but still useful.  One of the corners cut in the implementation is that incoming links are on a separate page – you have to click the Incoming Links link (and wait for the screen to refresh) to see them.  It’d be much more user-friendly to show these links on the same page as the content.

Turns out with jQuery this is a fairly trivial exercise,  at least for a single Wiki page*:  Simply add a Content Editor Web part to the page and copy the following code into the Source Editor.

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js" type="text/javascript"></script>
<script type="text/javascript">
$(function() {
  //get the url for the incoming links page
  u = $("a[id$=WikiIncomingLinks_LinkText]")[0].href;

  //create a target container and load it with the incoming links
  //filtered to show the links list only
  l = $("<div id='incomingLinks' style='border-top: solid 1px  silver'>").load(u + " .ms-formareaframe");

  //append the new container to the wiki content
  $(".ms-wikicontent").append(l);
});

</script>

It may be noted that the above code could even be combined into one single chain – I prefer the above for readability and debugging purposes.  Also not sure if I need to dispose of the local variables – this is a POC more than anything else.

The incoming links are now on the page, right below the content:

A more thorough implementation might position the links in a box in the upper left corner, and simultaneously removing the “Incoming Links” link.

*I haven’t quite thought out how to inject this throughout a wiki.  Any suggestions?