Ajax Bestiary » Tips http://www.ajaxbestiary.com AJAX Development, News, Techniques & More Wed, 01 Feb 2012 12:46:54 +0000 en hourly 1 http://wordpress.org/?v=3.3.1 Getting Started With Chrome Frame http://www.ajaxbestiary.com/2011/06/06/getting-started-with-chrome-frame/ http://www.ajaxbestiary.com/2011/06/06/getting-started-with-chrome-frame/#comments Tue, 07 Jun 2011 02:47:24 +0000 Don Albrecht http://www.ajaxbestiary.com/?p=416

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:

<meta 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.

  1. Identify the range of pages / screens in your web app that you can’t support in IE.
  2. Identify the navigation routes to those pages.
  3. Leverage the routes to find natural locations for gatekeepers.
      1. Login Screens (the perfect location)
      2. Tutorial Screens (A natural context fit for users)
      3. 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.
  4. Create an interception event for IE users.  You can bake this into your app, but the easy way is with conditional comments.
    1. Identify the Dom Nodes in your layout that must be presented to the user for them to progress.
    2. <div id=’loginbox’>…</div>
    3. Create a conditional comment to hide the nodes and prompt the user to install Chrome Frame.
    1. 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.
    2. 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.
    3. 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.

    5. <html>
    <body> <div id='prompt'></div>     <!--[if IE]>
    <script type="text/javascript"
    src="http://ajax.googleapis.com/ajax/libs/chrome-frame/1/CFInstall.min.js"></script>
    <style>
    #loginBox{
    display:none;
    }
    </style>
    <script>

    window.attachEvent("onload", function() {
    CFInstall.check({
    mode: "inline",
    }); });
    </script> <![endif]-->
    </body>
    </html>

    Other Lessons Learned

    Here’s a few lessons learned from deploying this.

     

]]> http://www.ajaxbestiary.com/2011/06/06/getting-started-with-chrome-frame/feed/ 1 !! You’re True (or False) http://www.ajaxbestiary.com/2007/12/24/your-true-or-false/ http://www.ajaxbestiary.com/2007/12/24/your-true-or-false/#comments Mon, 24 Dec 2007 17:10:11 +0000 Don Albrecht http://www.ajaxbestiary.com/2007/12/24/your-true-or-false/

Ok, so you probably know that Javascript like most other programming languages treats “0″ as false and any other numerical value as true in logic statements. Usually, this is sufficient, unfortunately, sometimes, you need a bit more consistent behavior. For example, ( 2 && 3 && true ) = 2.

Luckily there is a simple fix. Since, ! only operates on boolean data. !(0) is true and !( any other non-null value is false). Therefore, !! returns the boolean value of the original expression.

Another way of coding it, would be “Boolean ( expression );” and directly casting the expression to a Boolean. All things being equal, this would honestly be my preferred way of doing it. After all, legibility in code is one of the utmost considerations for most development, but since bandwidth is also a major consideration in javascript and !! is reasonably intuitive, I personally use it wherever necessary.

]]> http://www.ajaxbestiary.com/2007/12/24/your-true-or-false/feed/ 0 Standardizing On A Framework http://www.ajaxbestiary.com/2007/10/16/standardizing-on-a-framework/ http://www.ajaxbestiary.com/2007/10/16/standardizing-on-a-framework/#comments Tue, 16 Oct 2007 19:56:06 +0000 Don Albrecht http://www.ajaxbestiary.com/2007/10/16/standardizing-on-a-framework/

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.

]]> http://www.ajaxbestiary.com/2007/10/16/standardizing-on-a-framework/feed/ 0 Coping With Growing Pains: Tricks for Load Balancing In AJAX. http://www.ajaxbestiary.com/2007/10/14/coping-with-growing-pains-tricks-for-load-balancing-in-ajax/ http://www.ajaxbestiary.com/2007/10/14/coping-with-growing-pains-tricks-for-load-balancing-in-ajax/#comments Sun, 14 Oct 2007 15:29:48 +0000 Don Albrecht http://www.ajaxbestiary.com/2007/10/14/coping-with-growing-pains-tricks-for-load-balancing-in-ajax/

Here’s a great resource for load balancing AJAX applications. Unlike most load balancing strategies.  This one outsources some of the responsibility for balancing to an AJAX client to reduce costs and increase availability.

 http://www.digital-web.com/articles/client_side_load_balancing/

]]> http://www.ajaxbestiary.com/2007/10/14/coping-with-growing-pains-tricks-for-load-balancing-in-ajax/feed/ 0 Great Tutorial on OO programing in Prototype 1.60 http://www.ajaxbestiary.com/2007/10/11/great-tutorial-on-oo-programing-in-prototype-160/ http://www.ajaxbestiary.com/2007/10/11/great-tutorial-on-oo-programing-in-prototype-160/#comments Thu, 11 Oct 2007 17:52:35 +0000 Don Albrecht http://www.ajaxbestiary.com/2007/10/11/great-tutorial-on-oo-programing-in-prototype-160/

Prototype 1.6 is fast approaching and we’re already seeing loads of developers adopting the update in projects.  As this tutorial shows, The improvements to Class & inheritance in are truly compelling reasons to jump.

Prototype 1.6 Inheritance tutorial via Ajaxian

]]> http://www.ajaxbestiary.com/2007/10/11/great-tutorial-on-oo-programing-in-prototype-160/feed/ 0 Javascript Menus: The Good, The Bad & The Superfluous http://www.ajaxbestiary.com/2007/10/08/javascript-menus-the-good-the-bad-the-superfluous/ http://www.ajaxbestiary.com/2007/10/08/javascript-menus-the-good-the-bad-the-superfluous/#comments Mon, 08 Oct 2007 14:32:27 +0000 Don Albrecht http://www.ajaxbestiary.com/2007/10/08/javascript-menus-the-good-the-bad-the-superfluous/

Menu widgets: Every toolkit’s got one or more and they sure are easy to use & impressive so the temptation is there to just slap them everywhere. After all, you’re already pushing the toolkit to the client anyway, why not make the most of it.

Before you do, tho I encourage you to consider the following & ask yourself if the javascript solution is really appropriate.

The Good: Reasons to use Javascript Menus

Event Handling.

The biggest reason to use a frameworks menu system is event handling, plain and simple. If you have built an ajax ap that utilizes centralized event brokering. A dynamic menu is all but a necessity for maintainable code & consistent user experience. That said, if the menu doesn’t need to be integrated with the scripts on the page (e.g. A site wide navbar), a dynamic menu is likely superfluous.

Branding.

Lets face it, those slick menus with animated effects are damn sexy. Used effectively, they can really help you capture an audience & encourage a greater depth of exploration by visitors in even the simplest of brochureware sites. Even better, since the menus can be built from <li> elements they provide excellent accessibility.

The Bad: Reasons to Avoid Javascript Menus

Reduced Accessibility

JAWS especially doesn’t deal well with DOM elements created on the client side. While there are many improvements in accessibility that can come from javascript frameworks (improved tab order, shortcut keys, etc). Those all require an investment in time and energy at setup. These allowances, however, do not fully address the issue of users on reduced capability devices or reliably interface with legacy accessibility tools.

Rendering Overhead

Any dynamically generated menu will add to the initial rendering time of the page. While this may not be an issue on a modern machine running the latest release of an A level browser. Performance hits can be quite dramatic on a machine loaded down with spyware, vintage hardware or other sub-optimal deployment environments.

Visual Noise.

This goes without saying, KISS is one of the primary rules of interface design. A big fancy menu will likely call attention to itself at the expense of other content. After all, what’s going to bring more value to the site and project a slick menu, or quality, fast loading content.

Page Complexity

KISS applies to markup too. It’s a simple fact that the more complex the code, the more opportunities for bugs to slow down the development process. More significantly, the more complex the code, the longer it takes to grok it again when it comes time to make revisions.

I realize that many of these widgets require little or no markup, so the complexity issue can be a mute point in terms of markup. The big risk is of course that the code you use will be deprecated or outright removed from the next release of the framework.

The Superfluous:

This article was inspired by a recent discussion with a fellow developer. He spent 2 days struggling to integrate a pretty slick fish eye menu into the navbar of a website. While the comp’s of the bar looked great & everything was functioning well. The finished site seemed to lack something. It turns out that so many concessions had been made in the design to accommodate the menu’s space & bandwidth requirements. That the entire rest of the project was lackluster for better or worse. Don’t let this happen to you.

Remember, menu’s are not the value added prospect of any site. They are there to make it easy for our users to find the content & navigate.

]]> http://www.ajaxbestiary.com/2007/10/08/javascript-menus-the-good-the-bad-the-superfluous/feed/ 0 Excellent Resource for Learning MooTools http://www.ajaxbestiary.com/2007/10/04/excellent-resource-for-learning-mootools/ http://www.ajaxbestiary.com/2007/10/04/excellent-resource-for-learning-mootools/#comments Thu, 04 Oct 2007 19:56:38 +0000 Don Albrecht http://www.ajaxbestiary.com/2007/10/04/excellent-resource-for-learning-mootools/

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

]]> http://www.ajaxbestiary.com/2007/10/04/excellent-resource-for-learning-mootools/feed/ 0 Building a Form in a Modal Panel with YUI http://www.ajaxbestiary.com/2007/09/19/building-a-form-in-a-modal-panel-with-yui/ http://www.ajaxbestiary.com/2007/09/19/building-a-form-in-a-modal-panel-with-yui/#comments Wed, 19 Sep 2007 23:20:49 +0000 Don Albrecht http://www.ajaxbestiary.com/2007/09/19/building-a-form-in-a-modal-panel-with-yui/

Building a Modal Filtering List with YUI

In this tutorial we will build a simple form and embed it in a modal panel.

Building the form
There are two approaches we could take towards building the form : dynamic or static. A dynamically loaded interface is built by the javascript executed on page load, a static interface lurks hidden inside the html source and is displayed when needed. For the sake of simplicity, we will be using a static interface in this tutorial.

Our form is quite simple. It consists of 3 tiers of options and a submit button:

<div id="filterpanelform" style="display:none">
<fieldset><legend>Type</legend>
<input name="type" value="berry" type="checkbox">Berry
<input name="type" value="citrus" type="checkbox">Citrus
<input name="type"value="drupe" type="checkbox">Drupe
<input name="type" value="Melon" type="checkbox">Melon
</fieldset>

<fieldset><legend> Size </legend>
<input name="size" value="small" type="checkbox">Small
<input name="size" value="medium" type="checkbox">Medium
<input name="size" value="large" type="checkbox">Large
</fieldset>

<fieldset><legend> Color </legend>
<input name="color" value="red" type="checkbox">Red
<input name="color" value="orange" type="checkbox">Orange
<input name="color" value="yellow" type="checkbox">Yellow
<input name="color" value="green" type="checkbox">Green
<input name="color" value="purple" type="checkbox">Purple
<input name="color" value="pink" type="checkbox">Pink
</fieldset>

<button value="Filter" name="doFilter" type="button"id="doFilter">Filter</button>
</div>

Notice the style=”display:none;” on the containing div? This is to hide the contents from view until our user calls the modal dialog.

Building the Modal Interface

Now we need to build a YUI panel to contain the filtering interface. Unlike the form elements, the panel we will build dynamically. The panel will be created on page load, but will remain hidden until called for.

// Instantiate a Panel from script
YAHOO.example.container.FormPanel = new YAHOO.widget.Panel("formPanel", { width:"320px", visible:false, draggable:true, close:true} );
YAHOO.example.container.FormPanel.setHeader("Form Panel");

//populate the panel with the form we've hidden in the HTML
YAHOO.example.container.FormPanel.setBody( document.getElementById("filterpanelform").innerHTML );

YAHOO.example.container.FormPanel.render("container");

]]> http://www.ajaxbestiary.com/2007/09/19/building-a-form-in-a-modal-panel-with-yui/feed/ 4 Blueprint CSS Tip (Use first when it’s not first) http://www.ajaxbestiary.com/2007/09/17/blueprint-css-tip-use-first-when-its-not-first/ http://www.ajaxbestiary.com/2007/09/17/blueprint-css-tip-use-first-when-its-not-first/#comments Mon, 17 Sep 2007 20:09:08 +0000 Don Albrecht http://www.ajaxbestiary.com/2007/09/17/blueprint-css-tip-use-first-when-its-not-first/

Here’s a tip for all you Blueprint CSS users.  If you want to extend a background into the margin beyond a column, apply the first & last classes to the column.  Even if it’s not the first column in a row, it will extend the div 10 px into the gutter between columns.

]]> http://www.ajaxbestiary.com/2007/09/17/blueprint-css-tip-use-first-when-its-not-first/feed/ 0