A simple search for “Firefox 3 ugly” shows exactly how many people find the new “native”-ness of Firefox not so pleasing. The problem isn’t just about a non-uniform theme, but the fact that every control looks hacked together and an attempt to duplicate the looks and feel of native controls, instead of straight away using them.

This is not a Mac only phenomenon. I noticed this first on Windows when third-party shadow applications like Y’z Shadow would add a drop shadow to Windows’ native context menus, but Firefox menus were simple and shadow-less. But Windows’ own UI being so non-uniform, the difference didn’t strike at that time. After switching and using a Mac for more than half a year (and seeing what the various controls /actually/ look like), I can safely say Firefox needs to rethink their UI strategy.

Simple case: Add a border definition for your INPUT elements and see what happens to the focus highlight. Remove the definition, and you’ll see it pop back in. This is an attempt to duplicate native text box highlighting that Firefox gets wrong because they depend on a master stylesheet, which can be easily overwritten. Digging deeper, the problem becomes clear when you add a style to any form controller. I don’t mean to nitpick on a retarded level, but the way it stands out actually detracts from the experience more than what it adds.

The problem is Firefox’s XUL foundation. XUL is a mashup of the same languages that build the web. The problem with making your container configurable in the same language it is meant to render/run/interpret is clear: how does it effectively differentiate what is meant for the container and what is meant for the contained content. While a stylesheet embedded in a web page cannot change the browser behaviour, it can change how the browser behaves with the page. The lack of an inextensible priority system is an inherent flaw of CSS¹, which XUL has inherited.

I’m not questioning Mozilla’s design decisions for the foundations of Firefox. Obviously they’ve got it correct, if Firefox is eating away at IE’s share and is a favourite with designers and developers alike. I am questioning their design decisions for the interface (telling themselves that they’re trying to make it look native). I’m not a big fan of Safari (or Opera for that matter), but its integration with the OS makes it comfortably uniform, which is always a good thing.

Mozilla has to change Firefox for Mac. They should be using the many existing controllers offered natively rather than trying to duplicate them. Either that, or re-work their XUL GUI toolkit to be able to handle more cases than it does right now. One way or the other they have to make Firefox feel like a part of the OS, and not a bastardised attempt at duplicating it.

In reply to a tweet about wanting PUSH-based construct for web applications, @prasnation pointed me to Comet, which Wikipedia defines as a “WWW architecture in which a web server sends data to a client program (normally a web browser) asynchronously without any need for the client to explicitly request it”. I’ve been reading about it for the past couple of days, and it’s beginning to look like the next thing to hit web-applications. Standardised adoption in browsers will allow mass adoption in applications. That, will make hosting companies work to offer more powerful servers (dedicated/VPS) at cheaper costs, so that they can handle “always alive” connections for more people.

How does Comet work?

Simply put, it is a PUSH based alternative to current methods. The way HTTP works right now, the connection between the browser and the server is severed the moment the transfer of the page data is complete. Any changes happening on the server post-initial transfer, are not reflected on the already loaded page until the user explicitly refreshes. This has absolutely nothing to do with AJ (more on it later), and is purely about the transfer of data between a browser and the server.

Comet works by keeping the connection alive, so as to allow the server to PUSH data to the page as and when it changes. This allows for a more efficient method of serving dynamic pages, one that doesn’t require constant GET calls using AJAX or fancy IFRAMEs. Comet (as proposed) plans to work natively (without client side scripting) in a page, with certain blocks marked out as Comet elements, so that the browser knows that those elements will be updated in the future of the session.

Examples of places where the Comet architecture can be most beneficial are web-chat clients, notification systems — like Facebook’s Beacon or news tickers, and services of the same form. Any page that needs to stay in touch with an ever updating server for “fresh” data, should use the Comet model.

Unfortunately, no browser supports it completely (Opera 8.5+ supports it sparingly), because this is a part of the HTML5 specification¹. HTML5 is still in the decision-making phase, so the entire specification is not complete, which means it will take further time to finally get this out of the door, after which the browsers will have to implement it properly, and back-end servers will have to become powerful enough to handle such connections. It’s safe to say there’s a long wait before we see it peeking out of the hood. That’s why people have already come up with techniques to make up for it’s absence.

Alternatives to Comet

There are many ways of imitating a PUSH-based model, but I prefer only 3 — keeping efficiency in mind. I’ve tried out the following on my shared host, and have discovered a few things which might help you if you want to create an application that uses these alternatives.

XHR polling: The loaded page contains a recursive XHR call to the server that checks for updates every ‘n’ seconds (assuming data changes quickly, like in a chat client). The next XHR is fired the moment the previous is closed, which can be achieved by either polling the server again onSuccess, or making the server send a callback, in which case the second poll is only called in case the previous one was a success. This is a very intensive method, and is the fastest way to bring down weak-shared hosts (I’ve done it twice), so I wouldn’t recommend it unless you’re on dedicated servers. If you do use this, make sure you poll at decent time intervals; 5 seconds is too low, while 30 seconds makes your application seem unresponsive.

XHR streaming: A big improvement on the previous method, this uses the concept of streaming — letting data trickle in in bits and pieces — to make the page dynamic. Of course, this involves keeping the connection open all the time so that the server can continue sending data through. It uses the onreadystatechange (state 3) of XHR to take action every time new data is available. The problem is that existing shared hosts put a maximum execution time on scripts (usually 30), and we need infinite loops to keep the connection alive. This connection will automatically be closed when you hit that execution time limit. So, if you have access to your PHP configuration (which is highly unlikely), you can change the values and fix the issue. Otherwise, this method is pretty useless.

“Forever” IFRAME: This is a spin off the XHR streaming method. An invisible IFRAME is pointed to the server script, while the server spits out callbacks to functions on the main document (by using the top object). The IFRAME will continue to load, which might make the browser behave as if the page is still loading, but that’s a minor setback. Again, for shared hosts, the maximum execution time will limit how long the IFRAME can continue loading the script, but this is where things branch out from the streaming method. You can simple refresh the IFRAME to reset the execution timer, and the user won’t know the difference. The refresh can be a setInterval every ‘x’ seconds, where ‘x’ is the same number as the maximum execution time limit. This is cleaner, and is a much lesser headache.

---

All the above methods require server power, so dedicated hosts are your best bet at the moment. A shared host is alright if you want to play around with this and get the hang of it, but a full blown application will not hold.

Comet is a new way of doing an old thing. Most importantly, it is the correct way of doing it. I want it to get implemented quickly, even if alternatives exist. As the web comes closer and closer to the desktop in terms of applications and their usability, it is much better to work with the correct model than buggier, harder to maintain alternatives. Really.

There’s something about being a designer or just a plain computer person that makes you want to tweak everything to the way you want it to look. I have tweaked the life out of Geekaholic, and am currently in the process of designing my landing page at www.adityamukherjee.com. I would love it if Facebook allowed some tweak-age, but I’m not hopeful. So it was a welcome change to the outlook of my Twitter profile, that I thought of going all ‘designer’ on it since it was the only tweak-able non-tweaked page from/about me on the web. Earlier, it was a copy of Geekaholic’s background with a few colours changed. But since I got a black and white avatar, I thought it was time to jazz it up a little and give it it’s own identity.

I don’t think many people look at Twitter profiles as design opportunities, thinking that people don’t visit those profiles. I think otherwise, although I’d love to see some square figures to back me up on this. I visit a few Twitter profiles everyday to have a look at where the discussions are going, and invariably stumble across a few well designed ones.

I know that there aren’t too many options to change, but that is why it’s a challenge, and what I like about it. Challenges to designers make their job interesting, not cumbersome, and the allowance of changing only the colours of the text and sidebar, and the background image makes it a respectable challenge for any designer looking to stand out from the crowd.

A plain paper textured background is too simple and boring on a page buzzing with activity. Plus, a design replica of Geekaholic on my Twitter page will be a very un-designer-ish thing to do. I began with the avatar. It needed a change, so I put up a new grayscale one because then I would be able to go back to my favourite monochromatic colour scheme. With the new picture up, the design had to be changed around it. The busy-ness of Twitter pages made me want to make a noisy background, but I didn’t want a visit to be a jarring experience. Hence, I looked back to the De Stijl concept, something a friend had introduced me to a couple of years ago. They are very abstract and hence can be moulded to any form creativity allows. What finally emerged might not conform to the De Stijl principles completely, but that’s what derivative art is all about.

There was the thing of the coloured boxes, because a lot of the page is covered by the updates section, and the sidebar drops off after just 25% of the page. Too few would seem empty, too many would deviate from the foundation. But I think a random click here and there got that hitch out of the way real well. The colours for the text and sidebar were a natural pick, to stay with the grey. Although I wanted to pick a light on dark scheme for the sidebar, the foreground colour is universal, and the tweets section’s background is not changeable. I picked a charcoal grey to keep it dark enough to read, but light enough to not be a black. The sidebar colour came from the fill colour on the extreme left box, albeit a little lighter to maintain legibility. Creates a strange kind of harmony between the two sides.

Twitter profiles are one of the better evidences of designing prowess. How much one can do without having complete freedom. If you have a profile design you are proud of, let me know. I’ll be glad to link it in a ‘Best Twitter profile designs’ post sometime in the future.

The very first ‘Search-as-you-type’ control I saw was the in-page searches of browsers. The way words would start highlighting the moment you keyed in the n th letter of the word, was something I found very convenient, but didn’t think of its utilities or mechanism. Then I saw the same technique used for searching through tags and scripts on Userscripts.org (it’s been replaced by the traditional search mechanism now), and found it really cool … again.

Ever since then, I’ve preferred using the constantly updating search results list to a normal “type-in, press Enter” approach to searches. On the web, they’re just fancy forms that don’t really submit much information as much as pass query strings to server pages.

At the operating system level, the search I fell in love with was first Quicksilver’s, then Spotlight’s (not so much in Tiger, but Leopard’s version kicks butt), followed by Google’s Desktop — which was a little CPU intensive because of all the extra junk it would add, but the fast searches were good. Vista’s Instant Search leaves an unpleasant taste in the mouth. I don’t know if its the inefficient indexing or general CPU usage, but Spotlight gives me faster results (much) on the same configuration. One reason might be multiple search queries being fired with every keystroke, which just sounds like bad engineering if it’s the real deal. Otherwise, Vista’s memory management and dangerous/unstable concept of services might be the main culprit. Whatever be the case, it is testament to the inconvenience this type of search can cause if the programming behind it is not correct.

The biggest drawback of traditional searching is that it doesn’t augment the fact that the reason for a ‘search’ is to save time. By increasing the time taken to show results, you are taking the impetus in the wrong direction. The complexity of implementing a search-as-you-type controller keeps developers from putting it to practice. The immediate hurdles seem to be how to trigger the search (number of characters entered, time paused after last keystroke), how to optimise for speed (cancelling incomplete searches, caching results from previous searches) and if one wants to be really fancy, an algorithm which learns search usage patterns (related searches for entered keyword, treating keywords as tags, statistics from previous searches).

I firmly believe the traditional search should be done away with on sites and pages that don’t have a revenue stream tied to these search ‘pages’ (like Google ads for search), for the sake of usability and speed. We have enough tools at our disposal to implement them efficiently, and the beauty of the web being no CPU intensive or ad-hoc memory usage concerns need to be dealt with, makes it less of an optimisers nightmare.

NOTE: I am dealing only with the client side search implementation optimisation — what the user sees and uses. Optimisation for faster searches at the server end and algorithms which serve the results are not my scope.

Simply defining, a conversion engine is tool that one uses to convert one form of text into another. Here, I am talking about converting plain text to formatted coding. If you want a better idea of what I am talking about, take a look at the excellent Markdown text-to-HTML engine. That is what I use to write my posts, and I highly recommend it to anyone who hates filling up their article with < and >s to make them look good.

Conversion engines are amazing because all the changes happen behind the scenes. What we get to see is what we’ve written in our own special formatting (defined by the engine), and what comes out is perfectly coded text. When we come back to edit, we see it the way we left it. It increases readability and usability. You don’t need to know any code to use such engines, but still get the desired output. Of course, a text-to-HTML engine is a rather measly thing (a rich-editor can do the same), but it’s the concept that is so interesting.

I am beginning work on a CSS-engine, which will take specially formatted plain text document, and output W3C valid CSS. This will be my first time writing a parser of any kind, so I am expecting to run into a lot of hurdles and over-night coding sessions. But the outcome will be worth it, in the form of knowledge, and my first major mass-use project.

I picked CSS as the output because it is the second most repetitive markup that I’ve come across (HTML being the first. Damn you angled brackets!). People sometimes end up defining the same styles for the same elements in multiple classes, which adds to bloat and also throws validation errors. There are things like colours and sizes which need to be re-used, but since CSS offers no system of variables and constants, the tedious look up process is annoying. Compression is my last and most important goal. Just like packed JS files are all the rage, I want to try and reduce the file-size of parsed CSS as much as possible. This will be mostly achieved by grouping declarations, removing white-space and unsupported attributes from element selectors. The result will be well formed and very small CSS output, while keeping your side of the style easy to decipher and change in the future.

I will release a pre-development documentation which will contain all the formatting details, limitations, and specifications in the coming days. I plan on documenting the process, for both self-notes and future reference for anyone wanting to embark on the same journey. Wish me luck!

I like how Google service pages load up faster than others. Most of it can be attributed to their minimalistic design, but if you ever open up Firebug’s console, you’ll see the actual reason.

The good thing about Javascript is that it’s multi-threaded — as far as asynchronous calls are concerned at least. When you make an XMLHTTPRequest call to external files, it forgets about the process and continues while the content is loaded in the background. I’m going to call out Deepak on this, because even though his method is good, the problem is what he points out himself. Different browsers handle the loading differently. Also, it involves DOM manipulation, which restricts your script to the speed of (X)HTML.

With an asynchronous call, we are bootstrapping our scripts. It allows them to load nicely in the background, while the browser continues to render the markup. One they’re done, they will always be executed in the sequence they are loaded. Gives you at least one constant to work with. If your scripts are large, they will take longer to load. Calling functions that are yet to be loaded is always dangerous, which is why you should use fallback mechanisms.

---

A call to eval() with the Javascript file’s content passed as a string will result in it being ready for use on the current page. You will have to rewrite your code to JSON so that the evaluation doesn’t throw errors, which will not take too much time. Using the jQuery framework, the code can simply be:

$(document).ready(function(){
    $.ajax({
        type: "GET",
        url: "futureload.js",
        data: "ver=1.0",
        success: function(content){
                eval('js ='+content);
        }
    });
});

And the corresponding Javascript file could be:

{
    alert1: function(){
        alert('Greetings from "alert1"');
    },

    alert2: function(){
        alert('Greetings from "alert2"');
    }
}

Then call js.function-name() to display the required alert. Using the same skeleton, you can complicate your Javascript file while not losing out on page load times.

Your mileage might vary, and this is definitely the wrong way to make something right. But we’re all for hacks, aren’t we?

Lightbox Gone Wild was one of the first to implement this. A Javascript/CSS based modal window, which had to be serviced before access the page was returned. Sort of like a cool looking dialogue box. It was new for the time, and everybody joined on the bandwagon, especially cosmetics conscious designers. There have been many more since then, which increase the ease of implementing them.

The problem is that unlike native browser dialogue boxes, Javascript based boxes don’t come with the same keyboard access. In fact, they don’t come with any access at all. The most annoying example of the need for keyboard access to dialogues is Facebook. Every click of a link pops up a dialogue. Without any keyboard access, it takes the mouse to focus the input, key-presses to provide the input, and the mouse again to submit (a tap of the Enter-key doesn’t do anything).

With whatever reach I have to the developer community, I ask you to please provide keyboard access to form controls whenever you feel the need to use modal dialogues. Sticking to native dialogue boxes isn’t really a bad idea, but if you have to make things look good, at least make them usable.

P.S: Yes, the title is a play on the word ‘model’.

When we get used to an operating system, and memorise the keyboard short-cuts, we see our productivity increase. Tasks that would normally take 3 mouse clicks (after the time taken to move your hand from the keys to the mouse), can be easily executed in 2 or 1 key-presses.The simplest example would be when you accidentally close a tab in Firefox when you don’t mean to. Normally, you would have to go to “History » Recently Closed Tab Pick » Tab”, as compared to “Ctrl+Shift+T” if you’re keyboard friendly.

However, when one switches operating systems, this is the biggest obstacle. We grow accustomed to it, and somehow don’t want to take the pains to learn up new ones again. However, the one thing that remains constant through the changes is the mouse, and how we use it. The point-click interface is the same everywhere. The problem though, is that using the mouse is slow. That’s because it involves too much of movement and everything seems to be far away from the current cursor position. On the keyboard, our hands stay in a fixed position, with every key a finger’s length away at the maximum. To make mouse usage faster, we need an interface overhaul that follows the same principle — minimise movement.

I was introduced to the concept by Firefox’s All-in-one Gestures extension, but it seems this has existed way before that. In either case, if you don’t count the movement back to the keyboard to type in a URL, mouse gestures makes Firefox a lot more faster to use and navigate around in. AioG adds in a few more gestures of its own, called “Rocker” gestures which work with the mouse-wheel.

The issue is this feature being a third-party thing. We need to install extra software to have it as a part of the system. Why can’t Apple (or Microsoft for that matter) add it natively to the operating system so that it is usable throughout? It’ll become definitely easier to navigate around Finder, Preferences, multiple windows etcetera. Instead of moving the mouse all the way to the corners to show/hide Dashboard and windows, a simple gesture could make it so much more convenient.

The good thing is that these gestures are extremely intuitive (drag left to go backwards), and can be made homogeneous across systems. We won’t have to learn them up again, and hence productivity doesn’t take a hit. Of course, one can only program so many gestures to actions, but they could start by including the most basic ones (and offer the rest for re-mapping).

The entire idea here is to reduce the amount of movement it takes to execute actions. The frequent movement (I’m taking a guess here) is towards the menu-bar of windows. Macs have a fixed menu-bar at the top of the screen, so it’s quite intuitive as it is. But on Windows, the menu-bar is a part of the window, hence one has to worry about variable window dimensions, which takes that extra one-to-two seconds. Not to be fussy, but when one uses as much as we do throughout the day, those valuable seconds add up.

The mouse is definitely due a make-over. The context menu is the system designer’s idea of what actions fit the context. There is no easy way to change those. So this seems to be a good way to fix it. After all, the GUI involves graphics — why not use it to it’s potential?

Now that Firefox 3.0 beta 3 has come out (and been blasted by me), I wanted to take time to see which direction the UI refresh was going for the next generation of the browser we’ve all come to love. I’m going to start by saying I don’t like it, to save you the suspense. Also, I’m going to compare only the look (that means no slamming me for extensiveness or features) of the browser out of the box, to its predecessor, as well as other browsers out there.

Disclaimer: I’ve not compared Flock and Safari here. I think Flock’s interface is too cluttered, with there being and insane amount of things built into the browser. Safari has a beautiful and clean look, but it doesn’t sit nicely with Windows. Plus, I was a little too lazy to download them for just one screenshot. And, the screenshots were taken before the template change.

Firefox 3.0

The biggest problem with the UI is the missing feel of a modern day browser. The way we’ve gotten so used to gradients, rounded corners, little icons, glows and shadows … the UI feels utterly unimaginative and painfully boring. I know that developers and programmers care very little about the looks, but when you’re making a browser for the masses, the design takes the second row from the front.

Alex Faaborg, the user experience designer at Mozilla shows us mockups of what the final release might look like. While they’ve taken pains to make sure the browser takes on the native look and feel of the OS it is being used on, they’re not adding anything new which might make it look appealing and ‘new’. UI changes (like the gold star bookmarking and phishing site report) need to be re-worked … or finished, because they look hideous. The location bar completer design is simply bloat.

In fact, comparing it to Firefox 2.0, you can see that it looks almost exactly the same, with the exception that 2.0 feels lighter, sleeker and faster.

Even though it looks dated now, the glassy icons and nicely rounded form elements give it a nice smooth finish. A universal gradient to the theme would have added the remaining touch.

Internet Explorer 7

Even though the browser is a dud, the look and feel goes well with the new design forms we have been getting used to.

In Vista, IE7 looks even better, and right at home with the OS. Highlights and colourful indicators everywhere, as well as the shiny look that’s so “in” right now, visually it is a breath of fresh air at first sight. The lack of a menu bar is a little daunting, but then you get used to it if you use it enough. It seems like they actually studied user behaviour (or made smart guesses) and kept only the required things on screen, hiding everything else away.

Addition of a ribbon-like navigation and Office 2007-like look will set it very high in my books. Of course, features come a close second, and that’s where it fails :P

Opera 9.2

Here is a browser which never took off. They did a lot of things wrong, granted. But the look wasn’t one of them. Opera was easily the prettiest browser in the market even during Firefox 2’s release. I jumped back and forth between the two of them, being wooed by Opera’s speed and look, and Firefox’s usability and extensions.

Even now, while the UI remains unchanged, Opera’s holds its own against other browsers. Gentle highlights on hover, glowing buttons all add to the eye-candy. It lacks the glassy-ness, but you never feel their absence since everything else falls so nicely into place.

Opera is also the only browser to natively have a very functional sidebar. Surprisingly, this has not been picked up by other browsers … going for a top heavy approach. I know Firefox could benefit tons from this, which is why the All-in-one sidebar extension is so useful. Too bad less than 1% actually use Opera.

Maxthon 2

Finally, the most beautiful looking browser today. It’s technically incorrect to call Maxthon an individual browser in itself, but the number of features it adds to IE allows me to cut it slack. I have never used this as my primary browser, and don’t plan to start either. But it deserves the 5 minute spotlight.

What immediately hits you is the gradient. Like a strange version of Safari, the fading Grey makes it immediately stand out from the rest of the applications on your screen. The icons are bright and cheery enough to fit in with Windows, although the spacing could be worked a little more, because out of the box, it looks a little too claustrophobic. There is a functional sidebar, so it’s not top-heavy.

It lacks the expanding UI elements from Firefox 3.0, but then again I find them annoying there, so I like their absence here.

So why is Firefox 3 bad?

One word. Unpolished. Okay, one more … unimaginative. It seems that in their endeavour to make everything easily accessible to the common user, the designers have overly simplified the interface to the level that it’s boring. Even the buttons look out of place, not fitting in with the rest of the theme.

We can easily put aside the ‘speed’ factor. Maxthon, Opera and Safari all prove that the look of the browser has got nothing to do with how fast it works. Firefox has always been inherently slow. I don’t see how it can get any worse (it seems to be getting better in-fact). They can at least make it a slow, but beautiful browser. We’re not switching away any time soon, with the lack of a viable competitor. I’d love to see Personas leveraged as the new way to change the look and feel of Firefox, and given enough privileges that it can affect the look in ways more than just giving a background and changing icons/colours.

Until all that happens, I plan to stick with Firefox 2.0. I’ve become all too comfortable with it.

I’ll be using a programming jargon in this post, so excuse me if you don’t understand things immediately. All explanations are at the bottom.

One thing I love about PHP and sorely miss in C++ is the concept of variable variables. A ‘variable’ variable is when the identifier of a variable is a variable itself. Any language which supports this, will also support other variable controls. If you know what I’m talking about, skip the next section.

‘Variable’ variable

I love the feature. It saves a lot of headaches if you’re not sure of the incoming requests, and you need to serve all kinds of situations. I used it when when I was programming an API for a project I was working on.

It works by taking a string as the name, and then defining a variable with that name. That variable can then be used as a normal variable. Unfortunately, the way this works, you’ll need to have one variable which will contain the identifier as a string. If a language natively supports it, it’s much easier to work with it. However, when there are cases where you do need to use this in Javascript, there is a rather simple way to do it.

‘eval’ is your friend

Using the eval function creatively allows us to create these variable variables and function which can be used throughout. Of course, it’s simpler if you define a function to handle your variable, and do what you would expect a manually defined variable of that sort to do. Take a look at this:

function get(v){
    flag = 0;
    if(typeof(eval(v)) == 'function'){
        for(i in eval(v+'.prototype'))
            flag = (i) ? 1 : 0;
        if(flag == 1)
            return eval('new '+v+'()');
        else
            eval(v+'()');
    }
    else
        return eval(v);
}

Now, whenever you need to work with your variable, just call the function, passing the name as the argument, and it’ll return whatever you expect. The extra bit in the condition for == 'function' is because Javascript treats classes as functions. So we need to check if its prototype has any methods defined. If it does, it is a class, and we return an object of that class, else we just call the function. Hopefully this takes all cases into consideration. If you have a faster way, please let me know! Ruski points to the window[x] method as a faster alternative in the comments.

A practical use of this would be if you wanted to write a script to receive a request for a function, which belongs to a class. I’ll take the example of the Facebook method users.getInfo which returns the info on a user based on the UID and an array of fields passed. Now, I’ll skip the actual definitions, but assume something like the following:

users = function(){
    /* ... characteristics ... */

};
users.prototype = {
    /* ... methods ... */

    getInfo: function(){

        /* ... function body ... */
    }
}

So now, if the page is passed users.getInfo, we can do the following:

request = 'users.getInfo';
method = request.split('.');
    class = get(method[0]);
    get('class.'+method[1]);

That’ll execute the required function. The beauty of this is that you can change the string, and the code remains the same, with result being that the correct method of the required class will get executed.

Of course, if you’re programming at that level, you’ll be better off working with a more powerful server-side language like PHP. But this is a nice way to use those concepts in Javascript if you ever need to. If you have improvements to this, please feel free to shoot them my way :)

About a week back I began work on a couple of UI Javascript effects. An auto-completer, and an accordion. I know libraries come with these plug-ins pre-defined, but they’re heavy. Plus, I wanted to take up the challenge of making one on my own, so that I’d get to learn a few things as well. And boy, learn I did.

I thought I’ll share the few annoyances I ran into, which will maybe change someday.

Adding events

Adding events have always been a C0C0C0_hex area. I’ve seen multiple tutorials which say that the addEventListener property is the way to go when working with scripts. This allows more than one function to be called when an event is triggered. The alternative is to use attributes like onkeyup and onmouseover, and assign a function to that. But consider a scenario as such:

<input id='foo' value='clickme' onclick='javascript:alert('inline'+this.id)'/>
<script type='text/javascript'>
    document.getElementById('foo').addEventListener('click', function(){ alert('js'+this.id); }, true);
</script>

What do you think will happen?

If you execute that bit of code, you’ll see that the Javascript attached event handler triggered first. Now I didn’t know that. I’ve always thought inline definitions got highest priorities, because that’s how pretty much every other language works¹. It seems I was wrong.

You will not find an explicit explanation of this anywhere on the web, but this priority model seems to be uniform in HTML/DOM handling. If you remember your mathematical sets, then speaking in those terms: mutually independent statements get clubbed together, whereas conflicting statements are ordered by last-defined. That being a more general statement, it simply means that whatever you defined last will be executed first. Also note that there is no way to change the order of the above definition. You cannot define the event handler before then element is defined in the DOM. I’ll probably write a small primer on this later.

The cross-browser issue

If you run that script in IE (I’m assuming you’re like me and ran it in Firefox first, which you should always anyway), you’ll see that script never executes. It’s something that struck me at 12 o’ clock in the night lying in bed, which made me feel rather stupid, and hate IE even more.

IE has a different way of adding event handlers. It uses the (very limiting) attachEvent property. I say limiting because it doesn’t allow the event instance queue, which can be used to cancel events (more here). But more importantly, it means two separates blocks of code for two different browsers. Unfortunately, Opera uses the same property as IE, but we don’t bother with Opera, do we? ;)

That issue apart, when you do use the modified code:

<script type='text/javascript'>
    document.getElementById('foo').attachEvent('onclick', function(){ alert('js'+this.id); });
</script>

You’ll see an undefined pop-up. That’s the second IE annoyance, but it’s one that I haven’t understood properly this in IE points to the event, not the object triggering the event. The this pointer in Mozilla browsers, when used from event handlers, points to the object which triggered the event. So this.id will give us what is expected. The problem lies in the different properties that a DOM object holds in the different browsers. You can give it a go here. You’ll see what I’m talking about.

I don’t know why this is the case though It’s because IE is a conniving, non W3C standards following browser. Period.

JQuery

Finally, the framework I’ve been using for the past whatever weeks. The issue mainly was size over features. Taking nothing away from Prototype, I think it’s too big for everyday use. Even though the script.aculo.us library is dependent on it, there are libraries like moo.fx that do a similar job but with oh-so-tempting sizes.

Finally, it came down to either Mootools, or JQuery. I picked the bare-bones framework to work with, deciding that it was about time I started with Javascript from scratch, all over again. Coding back-ends for projects had almost made me useless when it came to interface and UI development. Mootools is a good alternative, of course. It’s got everything Prototype does (including advanced class-handling), but with a little bit of reading and personal tutoring, you can do all those things yourself, and trust me, you’ll be glad you learnt it rather than depend on a framework to handle the brunt. After all, it’s the basics that count.

So, I’ve been using and will continue to use JQuery for all my future escapades into JS land, a couple of which I’ll be revealing in the month to come. Thanks to John Resig for the wonderful element selectors (they’ve really made life easy), and I hope my ramblings till now will help you sometime when you’re close to banging your head against the wall.

I remember when Mozilla first announced that they would be shifting main focus over to Firefox, and what their core aim with this new browser was:

Firefox is simply smaller, faster, and better – especially better not because it has every conflicting feature wanted by each segment of the Mozilla community, but because it has a strong “add-on” extension mechanism. We recognize that different users need many different features; such demand is legitimate on its face. Attempting to “hardwire” all these features to the integrated application suite is not legitimate; it’s neither technically nor socially scaleable.

It’s been 4 years since then, and Firefox has not become any ‘smaller’ or ‘faster’; ‘better’ being a relative term, depending on what you want from your respective browsers. What’s worse is that there are so many features in the browser out-of-the-box, it ‘feels’ heavier than it actually is. Adding extensions on top of this makes a perfectly good browser behave erratically as far as memory and speed goes. Different test and benchmarks I’ve been following show that 3.0 seems to be even more loaded, albeit not at the cost of speed. That doesn’t make the screams of ‘bloatware’ in my head any softer.

It seems like the pressure to make it ‘just work’, and in their attempt to try and reduce the damage caused by broken extensions, Mozilla has lost it’s focus. Adding features upon features, they’ve managed to make it the biggest necessary evil on any computer.

The same goes for operating systems. I know I have vouched for Vista in the past, but I’ll agree that Microsoft actually has traded performance for features. It might be tremendously secure, and very good looking, but it’s slow; and unless you have the hardware to support it, almost non-functional. Not everyone has a Macbook Pro to to blaze through their work, but let’s be honest, if you did have a Pro you wouldn’t be working on Vista anyway. And why is that? Because Leopard (and Tiger more-so) are easily at the pinnacle of usability today. They’re fast, functional, feature-rich while not being bloated. Sure, the changes aren’t as obvious as they are with Windows releases, but I consider that a positive because it keeps the element of familiarity intact.

Measure of usability

I think it’s wrong to measure the usability of software that comes our way through its features. We should judge it by what it has helped us achieve. How much more productive did it make us. Are the features being touted actually used by the common user? Rather than think of a software as good or bad, we should think in terms of good or bad ‘for us’. If you’re a power user who needs 90% of the features, by all means go ahead and use it. But if you want to use Outlook as a mail-client, then obviously you shouldn’t complain of it being heavy on resources.

The same concept should be aimed at developers as well. Whenever you’re planning the next version of your software, don’t plan as a developer. As programmers, we tend to over think the requirements of the common person. I always say, it takes a child to think like one. Put the common man in your place, and let them decide what they want. All you get to do, is see how feasible it is to include that feature, as compared to the time it’ll take. That way, you’ll save yourself tons of time, and make your user base happy as well. This is one of the reasons open-source software works so well.

At the end of the day, you can’t use a sword to cut a steak, no matter how fancy your sword.

I read a lovely article over at Coding Horror about a week back, and I’ve been thinking about how we programmers deal with code. To start with, I think there are mainly two types of programmers today. 1) Programmers who don’t care about the looks of their code, and just care about getting the product out the door, and 2) Programmers who follow all the rules they’ve read in books and on programming sites/blogs, i.e. documenting, indenting and beautifying their code.

But what Jeff Atwood says pretty much sums it all up:

I have a friend who works for an extremely popular open source database company, and he says their code is some of the absolute worst he’s ever seen. This particular friend of mine is no stranger to bad code– he’s been in a position to see some horrifically bad codebases. Adoption of this open source database isn’t slowing in the least because their codebase happens to be poorly written and difficult to troubleshoot and maintain. Users couldn’t care less whether the underlying code is pretty. All they care about is whether or not it works. And it must work – otherwise, why would all these people all over the world be running their businesses on it?

Till now, I’ve only worked on one group project. I’ve always coded for personal projects, and have written my code in a way which works for me. It’s only recently that I’ve started paying attention to what my code ‘should’ look like, so that it is easy to port and debug.

This has involved adoption of ScriptDoc, which I think is an interesting concept. Documentation is a very important part of your coding, since it saves you tons of trouble if your have ‘lots’ of code. Standardizing it will result in all programmers getting ‘tuned’ to analyzing documentation in a certain way. Also, to make the entire coding process fun, I’ve switched full-time to TextMate. Let’s just put it this way: everything you’ve heard about it, and some of the things you’ve not heard, are all correct. Auto-completion, macros, in-built syntax recommendation, and custom bundles makes it just the perfect companion for any coder looking to focus on the coding, rather than the code itself (the layout and formatting, atleast).

A few steps

Spending a hint of time after your coding quota for the day is over to just skim what you’ve just written to add comments here and there, remove unnecessary line-breaks, and add necessary line-breaks is a good habit. Brackets you can do without (or ones you need), indentations and things like that should also be taken care of. This hardly takes more than 15 minutes (I do it, I know), and the end product is code that is pleasing to the eye. When you sit down to it the next day, you will not feel like giving up the moment you start, because your code looks inviting.

I’ve always felt that the more tempting you make something to the eyes, the more easily your mind accepts it. Why should your code be any different?

GUI (Graphical User Interface) is such an integral part of our computing lives, I really doubt we stop and analyze the separate elements that make it what it is –– easy and intuitive to use. It has evolved over years, suggestions and loads of empty coffee cups. It’s one problem designers try to solve always, but no matter what they do, there is a part of it which can always be improved. So here’s my little list of the things I like, and don’t like in user interfaces.

One’s I like

• Check/Radio box: The simplest element. I think it was a natural decider to use this for lists, which would let you select multiple options, or only oneNot many people know, but the difference between the two ‘is’ how they allow you to handle options marking.. I’d really like to see them make checking off more intuitive (shift+first+last to select all in between).

• Tooltips: Help without asking for it. I feel very disoriented whenever I don’t know what a button does, and even moreso when the little help box doesn’t popup telling me what it does. This is partly the reason I love Office 2007, where every button on the Ribbon has a briefly detailed explanation of what it does.

• Ribbon: This is one of the newest elements, present in Microsoft Office ‘07. It’s probably the perfect and complete alternative to the menu bar. Every option is categorized under one tab, and similar options are grouped into sections. Every button has explanatory tooltips, and they do a very nice glowy thing when you mouse over, highlighting the selected section as well as button. Looks like Microsoft got something right :P

• Pie Menu: Last, but my most favourite. This one takes some getting used to, but once you do, it gets annoying when you don’t have it somewhere. The perfect example of this is mouse gestures in Firefox. All it takes it a click, and movement; but movement which is very intuitive (like left for back). I’d love to see this in operating systems, because it’ll be a huge navigation boost!

One’s I don’t!

• Menu bar: I won’t complain about this too much. With the onset of ‘Ribbon’, we can now start to do without the menu bar. Although, this is a better option when conserving screen estate. A retractable Ribbon seems the way to go :)

• Heads Up Display (HUD): This is more of a ‘focus on few things’ kinda thing. An HUD is supposed to be unobtrusive to the ‘bigger’ picture, but the moment all those extra stuff start popping up, you can’t not be distracted by them. That’s one of the reasons research is on to come up with a better way of relaying information to pilots through their visors.

• Sidebar: This my most unliked element. Having something on the edge of your screen constantly is irritating. Dashboard is a ‘much’ better implementation, although it’d be nice if you could keep ‘some’ widgets always visible. Retractable drawers are also a type of Sidebar, but atleast they’re retractable :)

So, there you have it! These elements are a part of our OS, and now with the onset of Web 2.0, most of them are being adapted for use on the web to make things snappy and more OS like. I’d love to see an alternative to sidebars, especially on blogs. It’d just make things a little more interesting ;)

I haven’t touched on UI elements like modal dialogues, throbbers etc., but they are more of symbolic and rare use elements –– used to signify something or alert people of something. They’re important, no matter how irritating they might get. There’s a nice article from Alex Faaborg about his tussle with going modal or using normal dialogue boxes for Firefox, but it kinda answers the basic question (Would you Like to Redesign …)

What elements do you like? And what do you don’t?

Unless you’ve been living under a frozen rock in Antarctica, you’d know about Adobe Apollo. Now, welcome Silverlight! Microsoft’s answer to Adobe, but in the other direction. Silverlight is to the Internet, was Apollo is to the desktop. While initially it didn’t seem cut out, features being revealed slowly but steadily are hinting at a pretty decent enough framework for developers to work with to get people moving towards the Internet. The question I ask here is, “Why are Microsoft and Adobe headed in two different directions?”, and “Is it really worth all the trouble?”

Living in a browser

Weren’t we hailing Web OS, rich Internet applications, stable and asynchronous data flows just a few weeks (or months) back? There were talks of how the only application a person may need on his/her PC would be a decent enough browserMy constant advocation of Firefox might get a little annoying, but in this case, it is necessary because if people argue that Internet Explorer is a decent browser, they will not be half wrong. But IE is a very good RIA killer if you ask me., and Internet applications will help perform the daily things that people presently depend on desktop applications for. Google Office, aims to provide a useful and feature–full online office suite as an alternative (a.k.a replacement) to Microsoft Office. There are countless online image editors (with Adobe’s Photoshop for the web on the way), and many other applications which we have been so used to using on our comfortable desktops. So then why going back to desktop applications, and why not push the Internet application scene further? I’ll try and answer why …

To say the least, the Internet still offers many restrictions when it comes to privacy concerns. When people start bellowing down the doors to a bot scanning one’s mail for ‘contextual’ advertising purposes, you know you’re close to seeing everything. How can these people then trust services with really sensitive documents that may contain goodness knows what from their personal or official lives. The moment you put something up on the Internet, you’ve given away a good part of the privacy away. That is a well known fact. What depends is how is that loss being put to use. But that is not the point here. The point is that people will probably never be able to trust a web service (even with the name Google) enough to let it handle their data. The name ‘Microsoft’ will not help reduce their concerns.

The online storage scene is only now beginning to gain widespread acceptance with services like DivShare coming up which offer a lot of leash when it comes to uploading and storing/sharing files. Google’s rather liberal storage spaces for their different services shows exactly how cheap it has become to save large volumes of data. This will still take some time. There were forecasts of a time when the online copy of your file is the one which is under regular use, and local copy (on your hard–drive) is actually your backup, instead of the other way around. That prediction is a little far away as of now.

Apart from privacy restrictions, the Internet as a platform is in quite a tough spot. There are too many people trying to standardise it in their own way, and failing miserably. The whole XHTML concept is the best example of this. The everyday user wants something that works, and doesn’t care (usually) about how it works. Also, development for the web has only recently hit a peak (as the aftermath of the Web 2.0 boom), as small time desktop developers, seeing the easy and forgiving nature of Internet development languages decided to try their hand at it. If you bring that same ease to the desktop, which is what people are ‘used’ to develop for, why won’t they come back? With that, give them the option of keeping their applications (desktop and online) in sync with each other, and you have a sure winner. That said, Microsoft’s move might tilt the scale, because like it or not, Microsoft happens to define standards wherever it goes. However, the Internet is not really Microsoft domain, so who knows …

That doesn’t mean …

I’m not saying that no–one should develop for the web. Heck no! Without Internet applications, we are all pretty much doomed as the Internet is. What I ‘am’ trying to say is that people‘People’ here are not alpha–geeks, but everyday users, who use Outlook to check mails and a browser to just search and surf much rather work with their desktop applications rather than try and make a shift to their online counterparts. It takes the local geek to introduce them to that world, and show them the advantages of getting used to it. Everyone has their preferences and their individual comfort levels. Companies like Adobe and Microsoft understand this, but they are trying to go two different ways because they both see this differently.

Internet companies should try and bridge the gap between online apps and local ones, so that whenever someone tries to shift, they aren’t disappointed by the lack of features and shift back. When Google’s Spreadsheets came out, complaints of severe disappointment were ringing loud and clear through the corridors of the web, with people saying that Google was losing their touch and (…wait for it!) … they were out of creativity! If Google has made the first impression, things would have been on a different peak today. They are recovering though, and more and more people are beginning to use Docs and Spreadsheets as collaboration tools, and easy access to their files from anywhere I’m glad they are :)

What’ll be interesting to see is if Adobe can actually beat Microsoft at it’s own game, and get a definite upperhand on it’s operating system by having the majority of the applications being developed using their framework, and having them running on Windows. Or will Microsoft gain Internet dominance as well as desktop superiority, and truly change things to a true monopoly. I’d just love that! :)

I think every person who has wanted to get their hands dirty in code, should rethink their strategy and what they want to ultimately end up as. I have said before that ideas will ultimately mean more for hacks than the implementation and the code itself. This, as I’ve experienced, is not just restricted to web application programming. The ultimate “design” is of more interest to a concerned person than the actual implementation itself.

Ideas are what make you creative. Learning to code isn’t so hard, as all it takes is a book and enough hours. It’s how you can apply that knowledge to complement your idea which forms a basis of how good your programming skills are. But before that, you need to have the idea, a clearly thought out plan to execute. Just knowing how to write code doesn’t cut it.

Anyone who has asked me how to get started with programming, has been replied with one question — “What are you planning to do?”, and later followed up with an algorithm, not the code. I want people to understand why something is being done. I want to teach them how to look at a problem, and break it down for them so that they can implement in their own way. From experience, I know that this works much better than handing out individual chunks of code for people to plug in and use.

Here in college I have a subject SDOOP which, very simply put, teaches us how to tackle software development, how to “design”, and not program, a software. Becoming a designer is the ultimate goal. Creating a diagram, a schematic for programmers to follow, and implement in their own way. We are taught to come up with the fastest way of connecting different parts of the software, so that no matter what the code, the algorithm pushes the program to be easy to implement.

Aim for the idea and the working, not the mumbo–jumbo.

Today I bumped into FrogJS. It’s another photo gallery ‘unobtrusive Javascript’ library, which can be used by people to make a Javascript driven animated photo gallery on their pages. My question is simple. Do we really need another one?

The whole list

There are enough libraries out in the field today. Prototype being the more famous and widely used one. Then there are the other players like mootools, SimpleJS and jQuery. These extend Javascript as a language. Individual libraries which add effects and other bling bling to your pages include moo.fx, which uses mootools as it’s base and script.aculo.us with Prototype for it’s base. Then for picture management there is the very famous Lightbox JS with Prototype as it’s base, and script.aculo.us for effects, and now FrogJS using the same. Phew! See what I mean?

It is not a question of which one is better, or faster, or smaller, or easier. It’s based on what ‘use’ you have of a library. There are many (and I emphasize) things in Prototype that go completely unused by people, but they still prefer to use it because it has a ‘few’ functions that help them get the job done faster. It makes more sense to just copy them out, or write your own (like I do). Otherwise, take time to analyse and learn what each library has to offer, and then use them as per your requirement. Don’t go for one because everyone is using it. Pretty much all the libraries offer the same things. ‘mootools’ actually makes things faster because it’s so small, so many people should look at that if they don’t have too many hardcore OOP uses in their scripts. If you do, Prototype is probably the way to go since it has some pretty amazing classes and objects handling.

I went skipping on from Particletree to a nice extension of Prototype, which contains even more teensy weensy functions which we all want and use, albeit with longer drawn out codes. For example, functions to work with cookies and such. It extends an already jam–packed and very useful library! :)

SimpleJS seems like a good deal for very basic use, with small file sizes and independence from any other framework. But it doesn’t offer anything too big, which someone working with a library might be looking for. jQuery on the other hand seems very interesting, with small (compressed) file size and seemingly lot of uses. I’m definitely going to look more into that one. I want to move away from Prototype, but my ‘Search Suggest’ requires script.aculo.us, which uses Prototype. Together, they add about 60–70 Kbs to every page. There is not much difference in time due to caching, but it’s still a heavy deal.

Pick and choose

There seems to be no real perfect choice, or quite a balanced on either. I think libraries can truly be a great addition to your arsenal, but only if you know how to make full use of them. That can always take time, and you need to stick with one to get to know it properly. I’ve used Prototype ever since it came out, in some form or the other, and I still don’t know all it’s uses. So you can imagine how big it can be. I might as well stick to it, because a few of the things I use on my blog need it anyway, and it’s filled to the brim with all the functions one will ever need.

What do you think about the libraries out there? And which do you think is better than the rest?

I had a few other posts waiting to be posted, but this news just deserves priority! When I first heard of Apollo, I wasn’t so excited as a lot of people have been. I was more of the thought that since Adobe just likes to do things their way, no matter what, Apollo will be nothing but a fancier version of Java. I’m glad to say, that reading everything post release, I was right … for the most part.

The similarities end at the ‘cross–OS runtime’, because Apollo aims to become what Java couldn’t. Apollo is going to take what we already know, leverage it to the OS, and hand the controls back into our hands. What this simply means is that, everything you could do with the Internet, is now available for you to do with your own computer. I had written about seamless integration of offline and online applications. Keeping that in mind, this seems like just the thing I was looking for! :)

Why the Java analogy?

For those who don’t know, Sun Microsystems developed Java as a higher level language, which aimed to be completely object–oriented (it does this freakin’ well!), cross–platform and relatively easier to work with compared with lower level C++/C and the likes. But there was a problem. Working with Java meant learning a whole new language. Those familiar, will know that Java’s (only?) failing is its monstrous syntax linessystem.out.write just to write ‘Hi’ on the screen? Don’t get me started on higher functions!. I’m no expert though, and while it is the most popular programming language today, I think it can be seriously improved upon.

This is where Apollo will succeed, since it works by using existing web languages and technologiesHTML, Javascript, CSS, Flex, AJAX and ActionScript (non–web). PHP isn’t supported, and no plans have been revealed yet to do so. I guess one will have to use AS to bridge that gap should the need arise. I don’t know about Flex, so I guess that could be useful too!, and let’s you write applications using them. Web languages have been under heavy use since the Web 2.0 boom, and there are ‘many’ people who know it and use it in everyday life, with more and more beginning to join in the fray. If nothing more, a simple HTML interface to a Javascript backend, with Apollo’s stream controls should be able to help in developing simple and task specific applications. I can sense a Textmate for windows :)

Restricted freedom

This will, however, not be for newbies, surely. You’ll need to be adept at using existing technologies to be able to get your hands dirty with Apollo. You’ll have to be familiar with the basics of a how compilers and memory based languages work. But I think Adobe would have life much easier for everyone. So much so, that the first application that comes to mind is a ‘desktop dashboard’ of your Blogger. It could be synchronised whenever you’d go online, but for the times you were offline, changes could be saved locally, and then using the Blogger ATOM API, upload all the changes to your account. This might be one of the most uncreative uses of this however … :P So you can imagine the possibilities.

So, while Apollo looks and feels amazing, a true analysis can only come when people start to use it and get a feel for it themselves. But mark my words. This is going to be big. So big that next generation applications will be made off Apollo type frameworks. And yes, Apollo is surely going to generate some spinoffs and libraries. But ultimately, if application development becomes easier, why not? :)

Further Reading

Introducing Apollo
Apollo Developer FAQ
Apollo just launched, so go build something

The new Blogger brought a lot of new features. We (the bleet) were a little worried about the future of hacks, and how Blogger’s features would make a lot of past hacks useless, and make future hackery difficult. Now that I look back these past 2-3 months that I’ve been following the new Blogger, hacks for it, and the new generation of hackers, I must say I’m a wee bit disappointed at the situation, and that our fears have come true to some extent.

No longer can I see a Commentosphere, or one to use or extend my favourite hack, the Native Blog Search. One of the best hacks (and I shall call it one), and one of the very few I sincerely revere as a ‘hack’, has been ‘Neo’, the complete blog hack by Ramani. There was serious dedication, and work behind it. Not to mention the idea. And ‘those’ are the qualities that actually make a hack, a ‘hack’.

Scripts to clean your room

A lot of hacks today are mere 20 line functions that work on a feed from Blogger, and print out all it’s contents. My hacks suffer from this lack of innovation as well, with possibly only the Custom Datesscript being something I’d like to call a proper hack. All the asynchronous post and labels loading, fancy pants recent comments or posts, are pretty much commonplace. There isn’t anything new, something that would make someone sit back and actually appreciate the work, wonder in awe at the work behind the script.

It isn’t the lack of skills, but ideas that I believe should be blamed. That said, I come full circle back to the point I had made back when Blogger went into beta. It’ll soon become not what you can code, but what you can think. Coding is just a small aspect of a hack. Coming up with the concept, the design, the functioning, everything, takes a lot more effort than typing out syntax. A hack I’m working on at the moment is seriously taxing my reserves, and with college, it just gets harder. In the end, if it sees the light of day, it’ll be worth it though. I can say it’s on the same lines as the ‘revolutionary categorising hack’ that Avatar had revealed to everyone (back when Bloggeratto existed :P). I hope to break my monotony with that!

A little boring

As Avatar rightly said, Bloggeratto went off the stage at a particularly right time, because the entire Blogger scene seems to have been lulled into silence. When was the last time you saw something big pop out on radar that got the community buzzing? More than half a year ago! Isn’t that bad? There is nothing worse than having a stagnant community. Here I am enjoying Blogger being ranked the topmost blogging platform, and there Wordpress is celebrating the onset of version 2.1 of their platform, with more improvements.

I have discussed these views with people in the past, and they’ve agreed that the concept of a ‘hack’ has somewhere gotten lost. What we come up these days are simply mods (or some other term Avatar came up with :P), where we take an existing source, and just modify it to show something different. It has reached a point where hacks are mere plugins, that people keep adding to their blog to change something or show something. They don’t ‘do’ something, or not something really worthwhile anyway. Also, all the services which were offering JSON(P) feeds, are now also offering widgets for one-click addition into Blogger. This severely reduces things that non-creative hackers can achieve.

We need to ‘create’ a source, not just use one. Every one of the great hacks in the past has either created the source, or used an existing source in a way no-one thought of using it. We need to look at information from a different angle, look for data where it is least expected¹. Build functionality not ordinarily or easily available. We need to “Put the freezer at the bottom!”

The target users shouldn’t necessarily be complete newbies who don’t know a thing about code. One’s code should surprise long time coders into thinking thoughts on the lines of ‘Why didn’t I think of this?’ or ‘That’s fantastic! This is something I could really use!’ And it’s not hard to do if you keep your eyes open. I always try to get the method, the way of thinking, or the idea out if I’m not making a hack. By doing that I hope that someone else will catch on, and using my idea come up with a hack for it, or better.

So stop re-inventing the wheel, or even trying to change it’s shape. Try and invent a new rim, or an axle! :P The community, I’m sure, is looking out for something absolutely fresh!

I got the idea for it when I saw the two fixed menus over at Quirksmode. Now, I’m not a great book publishing, tutorial blog writing coder. But I can write code, so with the new look, I wanted to add that little detail in. It becomes a nuisance when you don’t know what is exactly on the page you’re looking at. Especially if you see one’s like the archive pages, which stretch on foreverBlogger offers no way of restricting the number of posts, or am I missing something here?, and it can get very disorienting.

The concept

I came up with the TOC to be dynamic, as in it would adapt to the page you’re on (rather than just show you the name of the posts on that page, a la Classic Blogger). A simple widget modified a little would have done the trick, but I wanted this one to go a step further and list out the sections in each post. I got into the habit of using headings after reading Postbubble, so those seemed the perfect section markers.

I also wanted the TOC to be visible all the time, but not really fixed like in other places. So here again I took the idea for scrolling it like in Quirksmode. Scroll with the page until it’s about to scroll out, and then get fixed with the page. Creates a catchy effect of the page dragging it. When you scroll back up, it regains it’s original position if you scroll to the top. Perfect! :)

I decided to hide it on post pages, because with just one post, you don’t really need a table of contents. The purpose is to help navigate a page internally when on a multiple posts page. So if you want to see it, the front page would be a good start :)

Finally, to be expandable, or not to be expandable. That was the question. The initial plan was to make the sections list for every post to be expandable. But then the problem of an intuitive interface came up. How do you expand when the user wants to see the sections, and take him to the post itself when he wants to go to the post. I could have created the click-double click interface, but that doesn’t become immediately obvious. So I stuck to an open sections list approach. I had to let it overflow, since this can cause the TOC to extend beyond the page on a page with a lot of posts (with a lot of sections), but that’s only on the archive pages. Search pages see the best application of the TOC, since you get to see a list of posts matching your criteria, and immediately jump to the one you wish to.

Making it and DOM glory

I tried a few methods trying to get the optimum performance with least amount of code. Sure as heck, XPath crossed my path more than once, but I just couldn’t generate a post specific section list. I always ended up with the same sections for every post. I’m sure I was doing something wrong, but I’m new to XPath, so until I perfect it, I rather not depend on it.

I then tried to use if...else statements to pin-point the exact node I wanted to extract information from. Here again I had the option of switching to PHP to easily scrape the data, but making an external call for something so native to a page seemed like overkill. So I decided to go hardcore, and make DOM Javascript do my bidding. This was harder than I had initially thought.

One of the basic mistakes I made was trying to append a bunch of children to one element. This was needed to generate the sections list, and append it as a child to the newly generated post list item. Of course, this would be only if that post had sections. The ideal way is to use document.createDocumentFragment() to create a fragment, then inside the loop I used to search for the headings (a simple nodeName == 'H4' checkEven now, I don’t know why I didn’t use element.getElementsByTagName('h4') to find all the headings in every post body. It wouldn’t have reduced lines of code, but would have saved me a brain wreck.), I created a post list item, an internal linkI have a separate function which runs through the headings inside a post-body element, and gives them an ID of ‘heading-(i)’ where (i) comes from the loop counter (just for uniqueness). Then I create a link to point to the ID of the traversed heading to that heading, and then appending the link to the list item, and then the list item to the fragment, while the current node being traversed had child nodes.

Since code generated by Blogger follows the same pattern, it was easy hardcoding the position of the post body. I then traversed this node for the H4 elements. At the end of the loop, I created a new list, and appended the entire fragment to it. This is the ‘only’ way I know how to work with adding a lot of content in one go, and it also helped me to check if there ‘were’ nodes to append or not. No point adding a list if it has nothing, right? :) The code I ended up with was this:

body = posts[i].childNodes[7]; j=0;//body points to the post body
    fr = document.createDocumentFragment();//the fragment
    while(body.childNodes[j]){
            if(body.childNodes[j].nodeName == 'H4'){
            sec_li = document.createElement('li');
            sec_link = document.createElement('a');
     sec_link.href = '#'+body.childNodes[j].id;//assigns ID of the heading being traversed
  sec_link.innerHTML = '- '+body.childNodes[j].textContent;
  sec_li.appendChild(sec_link);
        fr.appendChild(sec_li);
        }
        j++;
    }//end of body.childNodes
    ul_child = document.createElement('ul');//create a new list
    ul_child.id = 'sectionUL';
    ul_child.className = 'headingList';
    if(fr.childNodes.length > 0)
        ul_child.appendChild(fr);//append fragment to new list if it has children
    if(ul_child.childNodes.length > 0)
        ul.appendChild(ul_child);//append new list to main list if it has children

Notice that I could have easily used innerHTML to come up with the required links and everything, and as the discussion here goes, it would have saved me lines of code. However, the beauty of DOM Javascript tipped the balance. It helped to visualise the hierarchy of the TOC being generated. It would be as simple as:

• First post

• Section 1
• Section 2

Second post

Third post

• Section 1
• Section 2

And so on, with each section list being created only if the post was divided into sections. Remember though, that the way the script is written, a single H4 element in the post body resulted in this section list. I didn’t want to add unnecessary jargon by putting in checks to ascertain the legality of dividing a post into sections.

That is the dynamic part of the function, which analyses the page. The remaining part (which you’ll see if you view the source) works to create static links to the top, footnotes and the bottom content. The best part is, this is very easily extendible if one adds more sections or something. Blogger makes life easy with uniform hierarchy of posts, hence if you write the loop with one post in mind, you’ll effectively be writing it for all of them. I used the excellent getElementsByClassName function to get references to the different post blocks on a page.

The one little thing to notice is that if you click the link before the posts have finished loading, it’ll give an error. That’s because it adds links to various parts of a post, and does that for all the posts. It won’t be able to traverse the DOM properly if elements are missing, and wherever it catches an error, it’ll halt. If that happens, just wait for the page to finish loading, and then click the link again. You’ll have your TOC.

Conclusion

This was a nice and healthy experiment into scripting with proper DOM functions (for the most part). Took some nice brain racking to come up with the fastest method, and the result was a nice and fancy add-on to the page which I think people will appreciate in the long run. I hope to release it in the future, after it’s survived my tests and hammering, and a few tweaks that I have planned for the public version. Hope you enjoy using it as much as I did making it!

Recently, working on my personal blog (I’ll be releasing soon enough :) ), I had a little itch to make a automatically updating ‘Now Playing’ widget, which would automatically take the data from my Winamp, and via some fancy scripting, show it on the blog along with little additions like the album cover art. I did get it done, but it kind of opened my mind to the complicated nature of creating an interface which would allow an offline application to converse with an online one. I say complicated because I am not much into that side of programming yet. I will someday, but until then it will seem to be quite a daunting task.

Make it friendlier

There exists a standard for pretty much everything on the web today. Why not have standards for offline applications as well? It’ll help in having a protocol which will be common amongst communications of a particular kind. For example, to transfer secure data, a different method of obtaining data securely could be developed which would be common to all applications, but when an insecure data needs to be transferred to a public social application on the web, a simple interface should allow that to happen without getting ones hands dirty too much.

I know that once I try and learn that side of programming, I won’t find it so ‘high up there’. After all, a certain amount of knowledge must be involved with getting anything on different platforms to connect. But still, I know it can be made easier if developers just reached some sort of an agreement. Something like a script.aculo.us for the offline applications. A library which helps you get your job done faster. Pre-existing templates, which can be easily integrated and used.

Make it fun

By taking out a majority of the coding, it’ll allow people to think more, since the time required to code it out is cut down. This will see a rise in applications which are more usable and useful. At the moment, I am talking with little knowledge of this side of cross-platform (not in the literal sense) development, hence the predictions. But I have seen the use a platform like Ning has been put to. I also know it’s potential. And here, the problem isn’t lack of resources, but a lack of ideas.

I’d surely like to see more attention being paid to data transfers between such applications. If done correctly, we can actually have a proper online version of our own desktop (security and data intact), to control our computer remotely! Currently, companies like Google and Yahoo! offer APIs which let us use their services in (semi) offline applications. All that is good, but what if you could reverse the process? What if you could program your sticky notes to be auto-synced with your blog? Or maybe have an updated feed of the songs you play on your favourite media player? I’m not being creative enough, but think of the possibilities! :)

There are applications which are constantly in touch with online servers, which we use everyday. Our very own operating system is the perfect example. Those tiny little upgrades it keeps downloading from time to time? Yep! It has to send data for that, doesn’t it? Why not use the sending mechanism, make it easier to implement in applications, and let the people’s mind wander? Hehe!

What use can you think of having your applications talk to each other?

I have recently been experimenting with unicode characters on this blog. You would have noticed them next to links, at the end of the footnotes and very recently, the bullet icon for the label under the title. I use three glyphs at the moment, the outbound arrow (↗) to symbolise external links that open in a new window/tab, the hooked left arrow (↩) for the link back to the text and the star (★) which just looks good next to the labels. If you can’t see them and/or the characters in the brackets, you should get a browser that does. The perfect option is Firefox which has really good support for unicode characters.

I took some inspiration from John Gruber’s Daring Fireball for my choice of characters (the hooked arrow and star), and realised that they actually work better than little icons which people go to the first chance they get. The main advantage is that modern browsers can render it choosing a font for unicode characters quite easily, which means you don’t ‘need’ icons when a good looking character will do! There tons of glyphs to choose from. You could refer to the list at Wikibooks for a complete chart of the characters at your disposal (there are many, you’ll need patience).

The occasional problem of cross browser rendering will surface. Every browser chooses different fonts to show their unicode characters. Which is why it is good to check how certain characters are rendered. One workaround for any problem could be to specify your own list of fonts to try and pick for a unicode character containing element. On this blog, I use Tahoma as the main font, with a font size of ‘7.5em’ I’ve been told off for this many times! I just can’t get myself to have a bigger font size! It just looks too ugly to me!, but when a unicode character is rendered at that size, it becomes too small. Hence, I’ve had to manually increase the font size for them to ‘8.5em’. ‘Tahoma’ is an almost complete typeset, and a modern browser is mostly able to ‘fill-in’ empty characters by finding a font which has the characters. You will have to do some testing to see which one works for you. You can do this by using ‘class > element’ selector. This will not work in Internet Explorer, but the same goes for the character itself. I doubt unicode characters show up at all in Internet Explorer. My solution for that is to get a ‘real’ browser! As simple as that!

As a designer, it helps me remove unwanted graphics from the page, and keep things simple. Especially if one uses a monochrome colour combination for the text (white and dark gray for this blog), it works best to keep it looking uniform and clean! Go ahead, give it a whirl!

One of the things that had plagued us during the time of the old Blogger was the invalid mark-up that Blogger forced us to use so that it could work. When Blogger Beta was announced, this was one of the things that I had genuinely thought could be worked around. When I saw the new template language of Blogger, relying on a more XML based structure, and the errors it asked us to constantly check before we could preview or save our pages Most of them are tag nesting or Blogger Layout tags gone awry. Seems like a start to making Blogger pages more XHTML valid. It still doesn’t catch inline styles (not allowed in XHTML) and wrong use of data tags, which could save us hours of head banging later on if you plan to make the switch to XHTML., I was happy that now we could have well formed XHTML Not that it is a prerequisite, but keeping in the mind the various uses and advantages, it is always good to stick to something a application is looking to receive, rather than give it a jumbled up mark up to sort through first. valid templates.

Unfortunately, that’s not been the case.

For whom the bell tolls

I had done some serious testing of Blogger templates (both default and custom made) for a hack that I have been developing, and the results were pretty bad. None of them strictly adhere to the standards, and many give multiple errors. I know for a fact that their can be no ‘perfect’ check to test our templates, since they contain practically all data (scripts/style/mark-up) in one place, but some level of standard (better than the current one) should be enforced by Blogger’s template editor. The reason I blame Blogger a bit apart from people is because many of the things Blogger auto-inserts (like the Navbar) don’t follow XHTML standards, and you can’t do anything about it. You can’t remove it, and hiding doesn’t make a difference since the code is still there. It is in the long run that having well formed HTML, and even a valid XHTML mark-up will show its advantages. What advantages you ask?

To begin with, because XHTML follows the guidelines of XML, it becomes much easier to work with them in other applications other than a web browser like search engines. RSS feeds are plain XML, and see how useful they are. Extend them to web pages, and you can imagine how much more functional they become. They become more ‘accessible’, and easier to understand for programming languages. It also enforces clean coding habits, which improves readability and correcting. XHTML demands the seperation of style from content, hence no inline styles to be used if you want your document to be valid. W3C lists the main advantages as:

Extensibility: As an XML application, XHTML is extensible by definition. This makes future changes to the language much simpler in comparison to the process of changing HTML. Most browsers are already XML-compliant, so adding elements to the language is simply a matter of changing the document type definition and namespace. It’s no longer necessary to wait for browser developers to implement support for new elements.

Interoperability and portability: A properly structured XHTML document can be reformatted for use on a variety of display devices, including cell phones, PDAs, and other handheld devices. An XHTML document is also interoperable with other XML tools and applications.

So how does one start making their templates XHTML valid? Well, there are some rules to be followed. It is not a ‘whole new language’ and the rules aren’t that different from what you have been following with HTML, just more strict. For example, values for attributes must be put in quotes, like color="#FF0000", and no colour names. Empty tags (like br and hr) should be implicitly closed by putting a forward slash before the angular bracket like <br />, and so on. For a complete list, you can refer to W3C’s documentation, but a brief beginner’s list can be found here.

Following standards isn’t hard at all, just takes a little bit of effort. Other platforms like Wordpress and Expression Engine do offer a higher level of standard strictness by formatting posts and comments automatically, which Blogger has yet to equal. Blogger should help us tidy up our work more than it does at the moment, and Blogger users/template designers should try to keep this in mind and stick with a ‘more’ valid mark-up. It’ll ensure that your pages and designs survive longer, and are more functional/usable in the long run.

Now if only someone from Blogger were to read this, they could do something about it!

---

Microformats - the next big thing in automatic content recognition and relation, is majorly helped by proper systematic and semantic HTML, or XHTML. Suppose you have added the contact information of someone you blogged about. Any of the microformat recognition extensions (Tails, Operator) will recognise the relevant details if the details are semantically marked-up, and offer you quick links to save them if you choose to. Map locations to whatever application you use for maps, contact information to your contact list, and so on! Cool, ain’t it? Here’s a good starting point if you want to know more!