Questionning questions - Rashmon

Most often we hear people asking for concise and compact answers. This is only acceptable when the two parties share a common understanding of the context. Due to the inherent ambiguity of the natural languages is the cause of the problem. More so, if one of the parties tries to play with words (showoff!) and other ignoramus obiliges.

An example of this is the popular illustration: "Panda eats, shoots and leaves" vs. "Panda eats, shoots, and leaves". The difference is that, of a panda doing what pandas do, or a clinteastwood western classic.

More dangerous are the glitches that show up when some one with a uncanny knack for finding loopholes (lawyers!) comesup with a ridiculous conclusion that wasn't even half expected. This makes, usage of simple language and active voice, of paramount importance. I have recently read a joke to illustrate this:

David and John were walking by a church. David suddenly had one of those electrifying moments and popped a question to John.
David: "John, is it ok to smoke and pray at the same time".
John: "Why don't we ask the preacher."
David: "Ok" (goes into the church)
David: "Father, Is it ok to smoke while praying to God?"
Priest: "Son, such things are unacceptable while praying"
(David comesout and tells John)
John: "Are you sure about that? I will go and ask once again" (John goes in)
John: "Father, Is it ok to pray when we do other things in life"
Priest: "Son, It is the most ideal thing to do"

(Moral: Ask the right questions to get the right answers)

In the movie "Rashmon" the director Akira Kurosawa, showcases the human eccentricity in narration and interpretation of the events. Life would be a better place, if every interviewer/questioner deals with fact finding than interpretation.

Pleasant surprises

Every one who has worked with UI designers (people who swear by Fireworks and Photoshop) know how insolent they can be. We laymen, find it difficult to appreciate how much effort has gone into a button or some other image, until we put things side by side. Programmers don't care for the gloss that shows up, designers and end users do. So do sales folks. Never ignore the fact that it is the cream that sells the cake and not the crust.

When you see a button, you should feel like clicking it. Not like the button images that the current template uses. A button bulges up, takes a large font and has a finish that pops out. Like Disney’s animal pictures, with huge eyes and soft texture. These are achieved by tinkering around opacities, gradients, crops and colour combinations. Sounds simple, next time try going for a round of shopping with a bunch of girls. You can appreciate the nuances (rather forced to).

After all, we are not Borg, we do have individual tastes. That said, the next time you go shopping dont' forget to check the cakes' crust as well!

Some java script snippets - Using Event Handler - part 2

Earlier we saw how to define a cross browser compatible event handler, we will see how to use it. Three different styles are demonstrated

Note: Copy the code into notepad or someother custom editor for more legibility

/**************************************************************************
Sample Event Listener definition begins
**************************************************************************/

var Handles = function(){
    
    var test1 = function (aEvent){    
        alert(1);
    }
    var test2;
    return {
        test1: test1,
        test2: test2
    }
}
Handles.prototype.test2 = function test2(aEvent){
    alert(2);
}
var HANDLES = new Handles();
/**************************************************************************
Event Listener definition ends
**************************************************************************/

function init(){
    cleanup();    
    /* Three different ways to register functions, 
       the event Type and function's name are parameters  */
    // test1 is defined in HANDLES
    HANDLER.registerEventHandlerWithType("load", "HANDLES.test1");
    // test2 is added as prototype later on
    HANDLER.registerEventHandlerWithType("load", "Handles.prototype.test2");    
    // cleanup is a globally visible function
    HANDLER.registerEventHandlerWithType("unload", "cleanup");
}

function cleanup() {
    /* Three different ways to unregister functions */    
    HANDLER.unregisterEventHandlerWithType("load", "HANDLES.test1");
    HANDLER.unregisterEventHandlerWithType("load", "Handles.prototype.test2");    
    HANDLER.unregisterEventHandlerWithType("unload", "cleanup");
}

The html code for the above contains

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<!-- 
    Document   : test2
    Created on : 03-Jul-2008, 11:24:42    
-->

<html>
  <head>
    <title></title>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

        <script type="text/javascript" src="../js/File1.js">            
        </script> 
        <script type="text/javascript" src="../js/File2.js">            
        </script>
        <script type="text/javascript" >
            init();            
        </script>
  </head>
  <body onload="observeEvent(event)" onresize="observeEvent(event)">
    <div>
        Me
    </div>
  </body>
</html>

Some java script snippets - Event Handler - part 1

This is the first part of a sample event handler. We will see the declaration here

Note: Copy the code into notepad or someother custom editor for more legibility

     var HANDLER = new EventHandler();
/**************************************************************************
Event Handler definition begins
**************************************************************************/
/* Cross browser event handler, that allows multiple handlers to handle the event */
function EventHandler () {    
    /* This is an array of eventHandler arrays, essentially a hashMap 
    defined using associative arrays.
    Example content at run time would be
    events["onload"] = ["adjustDiv", "centerAlignText"...];
    where righthand side is a array of event Handling functions
    */
    var eHandler = this;
    eHandler.events = [];
    
    function getHandlersForEventType(aEventType) {
        /* if this is the first time we are listening the event,
        create handlers array
        */        
        if(eHandler.events[aEventType]==undefined) {
            eHandler.events[aEventType] = [];
        }
        return eHandler.events[aEventType];
    }
    
    function detectEvent(event) {
        // grab the event object (IE uses a global event object)
        event = event || ((this.ownerDocument || this.document || this).parentWindow || window).event;
        return event;
    }
    
    function registerEventHandlerWithType(aEventType, handlerFnc){        
        var handlers = getHandlersForEventType(aEventType)
        handlers[handlerFnc] = handlerFnc;        
    }
    
    function unregisterEventHandlerWithType(aEventType, handlerFnc){
        var handlers = getHandlersForEventType(aEventType);
        /* if this handler is not registered*/
        if(handlers[handlerFnc]==undefined) {
            return;
        }    
        delete handlers[handlerFnc];    
    }
    
    function handleEvent(aEvent){
        aEvent = detectEvent(aEvent);        
        var handlers = getHandlersForEventType(aEvent.type);
        var diagMsg = "";
        for(var handle in handlers){     
            // construct the method call from the function name and pass parameter            
            eval(handle)(aEvent);
        }
        /* stop the event bubbling now, this ensures browser compatibility */
        if(typeof aEvent.cancelBubble != undefined){            
            // IE event model
            aEvent.cancelBubble = true;
        }        
        if (aEvent.stopPropagation){            
            // Gecko event model
            aEvent.stopPropagation();
        }
    }
    
    return {
        /* public methods that are being exposed */
        registerEventHandlerWithType: registerEventHandlerWithType,        
        unregisterEventHandlerWithType: unregisterEventHandlerWithType,
        handleEvent: handleEvent        
    }
}

/**************************************************************************
Event Handler definition ends
**************************************************************************/

function observeEvent(aEvent){    
    HANDLER.handleEvent(aEvent);
}

How to post code?

Markup tags are detected using '<' and '>'. So these are skipped when encountered. This is the reason we don't see content making use of these symbols (well-formed xml content for example). Indentation is another aspect. Luckily the '<pre>' tag comes to our rescue. If we want to paste some code, we need to escape the '<' and '>' so that they are rendered properly. Rather than doing it manually, there are certain resources that help us accomplish the same. Certainly we can write our own custom code, another lazy way I found out is to use the following

http://www.bware.biz/default.htm?http://www.bware.biz/DotNet/Tools/CodeFormatter/WebClient/CodeToHtml.aspx

http://www.stanford.edu/~bsuter/js/convert.html

Robust Web Design - part 4 -last

Beware of java programmers in guise of java script programmers

Will you ever use a Japanese interpreter for your trip to China? Just because things appear the same doesn’t mean they are the same. One may understand things, but is it sufficient? I personally feel that there are two styles of programming, sniper style and landmine style. One has precision and the other has visibility. Good programmers use precision, they know what to do and the impact of what they are doing. Others still in the learning cycle, try to apply intution or make assumption. Learning languages helps, learning the purpose of the language is saviour. Ever heard about the ‘Golden hammer anti-pattern’? It is important to know what to use and where to use it.

Java script shares a lot in common with Java, human minds being very adaptive at least perceive so. The reality is different. It is easier for a Java programmer to master java script. All I am interested is, if any effort is invested in that direction.

Philosophical differences between Java and Java script:

1. Java is static typed, java script is dynamic; there is no type checking in place so use of proper naming convention is vital.
2. Java is application language with support for class invariants. Java script was designed to live in web browsers (I know jdk 6, FX and desktop support, but please…). Web browsers are not supposed to support business invariants, they support view (V of MVC). If someone uses Math library in java script, take him into custody.
3.Java doesn’t support closures (not yet till jdk 6). Java script does. In case, you are wondering, Closure is just a set of statements that can be passed here and there (as parameter). It is just a different style of doing things, you know!!
4.Java is inherently object oriented most of the time with a central control structure. Java script on the other hand is functional and event-driven.

One symptom of java programmer not doing his homework, is use of ‘==’/’!=’ in place of ‘===’/‘!==’.

Namespace contamination horrors

A good java script programmer tries to keep namespace contamination to a minimum by using object based style. ‘Revealing module pattern’ and ‘Singleton’ are some examples. We can also get huge performance benefits by reusing objects than recreating them. Magic numbers in code can be kept to a minimum using the above. In fact a good piece of work also show cases, cross browser compatible event handling.

Some references: On java script patterns

We can achieve similar things in CSS by using a unique template id and referring to it in all selectors. This non-semantic declaration is worth its cost. When programming in a large team, these decisions become important.

The class of web 2.0: IE, Mozilla, Opera…

Each of us is unique, that aspect makes ‘each’ of ‘us’. So are browsers. Some prominent aspects I left of earlier are summarised here

Event model

W3C standard even model speaks of three phases capture, target and bubble. Not all browsers support this. So there is a need to hack into the event model and support the least common factor. A custom event model should also prevent function overriding, (usually happens when two different functions are tied to the same event)

Dom model

Not all browsers support Dom functions uniformly. We need to have a custom common wrapper library for the most useful ones and refer to the library. These assets can be reused across assignments.

Xslt wonder

Java script is not the only way to present a view. Certain sections of the user community/application may be reluctant to use scripts. Xslt is the answer for such. It is rich specification with support for reg-ex as well!

AJAX, JQuery, DOJO and others

We discussed the group of java script dissidents; as the world exists we also have a section of aficionados. These guys are those who enjoy the privilege of huge broadband, fast processors and humungous main memory when compared to the past era (read 4 years ago). Writing our own scripts and testing for cross browser compatibility is painful. Why not ask someone else to help us out here? Dojo, JQuery, YUI from yahoo, GWT from Google, JMaki and several others have been targeting these goals.

Robust Web Design - part 3

Third posting

CSS – Domino effect

A home made avalanche vs. a child’s play kit? Is something I used to wonder when I first understood the purpose of CSS. I would never teach CSS to someone who is starting web-design, who cares about consistent styling or the fact that the way content is uniformly laid, ok I was kidding. These things are better learnt by feeling the flare, the flare of inconsistent design, the wrath of the end-user, the harm to ones own pride, the legend of Zelda, the story of war craft…(ok I exaggerated a bit).

CSS even its simplest form (inline style definition) shows its’ merits. Forget about layouts, forget about cross browser compatibility. The amount of code that is reduced (read more coffee breaks) is itself rewarding. “The lesser the code, the fewer bugs” - a well known adage. I used to correlate CSS with Dominos. Remember those videos on youtube. Anyone who designs a large project faces the same challenges. Things rarely go so well when put to practice. So there are certain firewalls, redundancies put in place. CSS is essentially huge collection of domino chips, with provisions for firewalls and redundancies (read CSS selectors). These provisions allow certain chips (rules) to take precedence over others. Each chip (rule) causes an effect (sets style properties). The game is to place the chips and firewalls appropriately. The challenge is the game floor. Not every stadium/court is the same! There are certain tricks and tips to raise our bar, when playing in not so friendly arenas (hacks). These tricks work well for that given court alone and don’t go well with the big picture.

A check list for the techies:

• Learn your selectors


• Negotiate for the most recent browsers and restrict their number (I know I sound like a weasel)


• Overwrite browser defaults


• Negotiate for the minimum window size, especially height of the scrollable content in px. May be critical for java script disabled scenarios. Fluid layouts need specs in ems


• Avoid mixing margin & width attributes. Inconsistencies across browsers rise from the misinterpretation of box-model


• Alternatively; use padding, and/or border styles with width and color matching the background; to achieve the same effect


• Avoid tables for layout. Most accessibility problems rise from this fact


• Seek dispensation for complex UI features. Almost, all known browsers till date fail the Acid tests. It is difficult to achieve standard compliance using non-standard compliant user agents


• Avoid CSS expressions


• Try to build your styles based on the least common selectors


• Test your styles across browsers

a. Test for well formed content in absence of CSS
b. Test for accessibility
c. Test for text enlarge, compact scenarios
d. Avoid classitis and divitis. Use grouped declaration of selectors and pseudo declarations. Divitis may not be avoided always
e. Document the use of extraneous divs (if any being used for layout)
f. Separate styles based on usage pattern i.e. layout, color, font-styles
g. Use a namespace to avoid style-conflict

Horror of hacks

Ever heard of 3 pixel jog? Knowing your browser is of paramount importance. There is a difference in addressing symptoms and addressing the cause. Which one would you prefer? There are a huge number of resources that speak about these. I personally like ‘CSS Mastery’ by Andy Budd and ‘Pro CSS Techniques’ from Apress. I haven’t read others, but I feel one or two books help you realise the game.