Ajax Bestiary » Development

Getting Started With Chrome Frame

Don Albrecht — Tue, 07 Jun 2011 02:47:24 +0000

As a follow up to my last post, I thought I’d put out an instruction on actually creating a Google Chrome retreat.

Step 1: Add a Chrome Frame header to your site.

Add this to the head of the Chrome Frame dependent pages:

http-equiv="X-UA-Compatible" content="chrome=1">.


If this isn’t practical, You can also configure your server to send an HTTP header of
X-UA-Compatible: chrome=1
I advise against this approach, however because server configs won’t be immediately available to other users on a site.  By its nature, a Chrome Frame retreat should be considered a reasonably unique event.  It’s good to clearly document this dependency for anyone else who may need to debug things later.  Once you’ve started to retreat, make sure you’re applying the header to every page of the site.  The two engines render things differently and you may create an inconsistent experience for your users if they are transitioning between Chrome Frame and Trident environments frequently.  In my experience, border-radius and drop shadow toggling on and off is a pretty strong “It’s Broken” signal for end users.
Step 2: Identify your Dependency Wall.

Identify the range of pages / screens in your web app that you can’t support in IE.
Identify the navigation routes to those pages.
Leverage the routes to find natural locations for gatekeepers.



Login Screens (the perfect location)
Tutorial Screens (A natural context fit for users)
An Advanced Mode (Similar to the “enriched mode” Microsoft uses for ActiveX requiring cloud apps).




If you’re lucky, this will be a screen somewhere beyond your conversion pipeline.


Create an interception event for IE users.  You can bake this into your app, but the easy way is with conditional comments.

Identify the Dom Nodes in your layout that must be presented to the user for them to progress.
…
Create a conditional comment to hide the nodes and prompt the user to install Chrome Frame.


Be careful of z-index.  The chrome install iframe doesn’t work well if IE is floating some other content node on top of the install button.
UN-INSTALL chrome frame once you’ve tested your retreat perimeter.  This is a big deal for ongoing development as you won’t be testing in IE otherwise.
Becareful about your conversion pipeline.  Your key selling points may be behind the perimeter, but the act of demanding Chrome Frame is a pretty severe barrier to forward movement.




 
 




Other Lessons Learned
Here’s a few lessons learned from deploying this.



Notes On My First Few Days With Hype
Don Albrecht — Thu, 02 Jun 2011 10:39:35 +0000


For those of you not aware, Hype is a new OSX app for building interactive HTML5 in a Timeline / WYSIWYG interface.
It’s not the first product in the space (Sencha Animator), it’s the first well publicized version 1.0 I’ve come across.  It’s also pretty reasonably priced at 29.99 a seat.
First the good points:

Ease of use: This is definitely a pretty straightforward tool in this regard.
Interoperability: The Hype API and ability to execute arbitrary javascript inside the page DOM make this a great option for extending the capabilities of an existing web app.  I’d obviously like it to be richer, but it’s a decent compromise for a rev 1 product.
OS integration: For those of us on OSX, the drag and drop support  and polished UI are incredibly nice.

So what needs improvement:

Animation along a path with key frames:  I realize this isn’t as embodied in css3 transforms as other options, but YUI Animation and Sencha Animator do it, so It’s demonstrably possible.
Dynamic Sprite creation: The fact we can play arbitrary timelines from javascript is nice, but I would like to be able to add timelines to the frame.
Direct Sprite manipulation: Changing sprite colors or the text in a block might be useful.






Using the jQuery data method as a local datastore
Dave Mahon — Thu, 15 Oct 2009 23:37:37 +0000


At some point, we all have to store datasets on the client. We can clutter the namespace with ever more variables and try really hard to avoid collisions. We can cram variables into some local object that we’re using in the normal execution of our script anyway. We can attach custom attributes to HTML nodes, violating the sacrosanct purity of XHTML.
Or we can attach the document-specific variables, in script (thus keeping those automated validators happy), to the document itself. This fairly intuitive approach has not been given the notice it deserves.
Some advantages:

Arbitrary value names can be assigned and we can basically assign as many of these variables as we want.
They can be applied to anything jQuery can access, meaning that we can rapidly assign values to entire sets of DOM nodes without having to add CSS classes or clutter the markup.
They can be dynamically added, accessed, changed and removed at will, without network transfers.

There is the disadvantage that they are not persistent across page loads, but we’ve lived with that problem for a long, long time, haven’t we?
So how do we use this handy method? The documentation is pretty clear cut, but I’ll give a slightly more grounded example:
My HTML is very simplistic in this example:

1
2
3
4
5
6
7
8
<body>
 <div>
  <span id="stats"></span>
  <button id="add">Add Data Point</button>
  <button id="reset">Reset Set</button>
 </div>
 <div id="data"></div>
</body>

The JavaScript is similarly intuitive:

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
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
appExample = {
 addDataPoint: function() {
  var dat = this.getDataSet();
  dat[dat.length] = Math.floor(Math.random()*101);
  $('#data').data('points', dat);
 },
 resetDataSet: function() {
  $('#data').removeData('points');
 },
 dataSize: function() {
  var dat = this.getDataSet();
  return dat.length;
 },
 getDataSet: function() {
  var dat = $('#data').data('points');
  if (undefined == dat) return [];
  if (Array != dat.constructor) return [dat];
  return dat;
 },
 updateDisplay: function() {
  $('#stats').text('Data Points: ' + (lim = this.dataSize()));
  var tmp = '';
  var dat = this.getDataSet();
  for (var i = 0; i < lim; i++) {
   tmp += dat[i];
   if (i < lim - 1) tmp += ',';
  }
  $('#data').text('[' + tmp + ']');
 }
}
 
$(document).ready( function() {
 appExample.updateDisplay();
 $('#add').bind('click', function(e) {
  appExample.addDataPoint();
  appExample.updateDisplay();
 });
 $('#reset').bind('click', function(e) {
  appExample.resetDataSet();
  appExample.updateDisplay();
 });
});

In this case, I’m storing everything as an array in points. While I’m storing randomly generated integers, you can just as easily store entire objects, opening the possibility of a JSON solution.
Note that we can identify those objects lacking the chosen dynamic attribute by calling it and testing for undefined.





Backup Systems
Don Albrecht — Mon, 26 Nov 2007 15:23:10 +0000


This is a bit off topic for this blog, but is something that has very much been on my mind lately.  I’ve been maintaining an archive of all of my work over the past 12 years.  Everything from coursework to UI markups, Personal Notes to SVN repositories all lived in a set of redundant 750 gb external hard drives.  Over the years , I’ve found these archives to be an invaluable asset (especially with modern desktop search tools).  Last monday, those drives were stolen.
Although I can cope without the data, I need to start compiling a new personal archive & I’m curious what other people have done for backup systems & how you deal with offsite backup of personal data.





Standardizing On A Framework
Don Albrecht — Tue, 16 Oct 2007 19:56:06 +0000


Organizational standards are wonderful things.  They enforce consistency, help insure institutional competence and can dramatically reduce the learning curve to get additional staff up to speed on a project.  At the same time, in the world of AJAX standards can be too slow to adapt to a constantly changing landscape.  How do you strike a balance between flexibility and consistency?
 Project Specific Framework Selection
This is one of the most common approaches and is definitely the most flexible.  Project specific standards basically let the needs of a given project describe the choice of frameworks.  A project needing lots of animation and color manipulation may be built using mootools, a complex RIA may be built using dojo & a simpler project may use prototype or jQuery.  The problem with this approach is the frequent need to learn new API’s & potential to develop overly superficial knowledge of toolkits that may lead to unnecessarily cumbersome solutions.
Selection of Approved Frameworks
A step beyond project specific framework selection is the adoption of 2 – 4 approved frameworks within an organization.  In this arrangement, you try to achieve a balance between project appropriateness and standardization.  Usually the frameworks are chosen to accommodate different scales of projects.  A natural breakdown is the use of prototype & scriptaculous where scriptaculous may not be used in every project.  Another breakdown may combine a simple framework like prototype with a RIA platform like Dojo & an intermediate toolkit like jQuery.  In any event, it’s usually a good idea to pick platforms with similar coding styles & api’s to maximize the transference of skills between projects.
Standardizing on a Single Framework
This is definitely a popular approach and prevents any problems with developers needing to relearn things to get up to speed on different projects. Unfortunately, it’s a very high risk approach as toolkits frequently aren’t optimal for every project (e.g. dojo for a brochureware site and prototype for a webmail client).  There’s also the unfortunate possibility of a framework transitioning to an inappropriate licensing model or being abandoned as well.
Standardized Coding Practices
This is a strategy that can be adopted independent of your framework strategy.  basically, since so many of the various frameworks share constructs and they are all based on javascript.   Adopting a set of coding standards can dramatically simplify collaborative development.  Some of the strategies to consider are:

Standardized Naming Conventions (camelcase, underscore etc.)
Standardized File Names
Standardized Function Names
Comment Formating
Chaining limits

We’ll discus coding standards more in the future, but since I’ve had several recent discussions on adopting a standard for my organization.  I thought I’d share some of our thoughts with you.





Roll Your Own JS Framework: Is It Necessary?
Don Albrecht — Mon, 08 Oct 2007 15:47:04 +0000


Dustin Diaz recently posted about Rolling out your own javascript interface in his blog.
http://www.dustindiaz.com/roll-out-your-own-interface/ 
While his code is nice and clean and it does provide what he was hoping to achieve:
There are times when using a JavaScript library is called for. Building large web applications that use a wide array of utility functions that help aid in developing multi-tiered class systems, advanced UI components, complex event models, and heavy use of DOM scripting helpers. Yep. Those are all great.

However, there are other times when you don’t need all that. And often what we end up doing is just importing a few of our favorite functions as globals, and work off those. But what ends up happening in this case is that we lose the particular style that these libraries offer.
In essence, he’s offering a light weight solution to the fundamental issue persistent to all javascript development: (“javascript sucks”). His solution is to coble together a light weight version of prototype containing only what he needs.
My questions are three fold:

Is rolling your own framework worth it? The new generation of code profilers for the various toolkits can dramatically decrease download size and focus on the functionality needed.
Is there sufficient demand for a new ultra light weight toolkit to address these issues?
Why not use full toolkits:  Many of them are small enough in compressed form not to make a noticeable difference in load times.






Excellent Resource for Learning MooTools
Don Albrecht — Thu, 04 Oct 2007 19:56:38 +0000


This has been out there for quite a while now, but I thought it should be included in the bestiary out of completeness.
http://clientside.cnet.com





JSONP Robust, CrossDomain JSON
Don Albrecht — Tue, 11 Sep 2007 16:41:46 +0000


Basically, here’s the idea.  Instead of relying solely on the remote host to provide you with your JSON files, JSONP is a standardized way for requesting formating for the JSON data that allows the client to inject code at the beginning of files produced by the server.  It’s not a perfect solution but it does help circumvent some of hobbles placed on Javascript based mashups by security sandboxes.
Remote JSON – JSONP





What To Expect From An AJAX toolkit
Don Albrecht — Wed, 22 Aug 2007 13:52:13 +0000


There’s a myriad of AJAX frameworks out there to streamline the development of interactive sites.  While methods of implementation vary and the functionality toolkits offer can vary dramatically.  All toolkits fundamentally provide you with certain key features.

Basic Features

Simplified AJAX calls.  All frameworks streamline the way in which you process POST and GET requests by abstracting away the cross browser descrepancies.
Improved DOM Access.  All frameworks improve interactions with the DOM through performance benefits and improved API calls.
Object Orientation / Elements.  All frameworks provide a level of object oriented abstraction to simplify and structure coding as well as some level of abstraction for DOM nodes.
JSON Support.  Most if not all frameworks provide strong support for the JSON data interchange standard.

Advanced Features

There are also some advanced features common to most if not all frameworks.



Drag & Drop.  Most frameworks provide tools for manipulating elements via drag & drop.
Animation.  Many frameworks provide animation tools to enhance the interface.  These can vary dramatically between toolkits in performance & available effects, however.
Event Handling.  Since the default javascript event model can be slow and buggy at times.  Most frameworks abstract away the default event system with a new slots & sockets approach.