Monday, December 26, 2005

Back In Action

For the record, I never stopped blogging. I just took a three and a half month vacation.

There has been a lot going on in the last couple of weeks. I've missed blogging so much, but it has been hard to even get to see how my blog looks lately. My incoming links have not increased at the same pace as it used to. My hit count has hit an all time low. Google is the only one hitting my site (other than a few guys who come from blogs where I leave an odd comment). The good times had stopped rolling.

All of that is about to change. I shall now, as a rule, dish out posts more frequently, and try to remain focussed on the topic. (Did you notice that none of my recent posts had anything to do with web design?)

To start, here's a (partial) list of things that have happened to me over the last couple of months.

  1. I've quit my job at HSBC Asset Management. I don't want to say bad things about my previous employer here right now. I might change my mind.
  2. I've joined a small company called Iventa Corporation as a Team Lead - User Interface Design and Integration.
  3. I've never thought that work can be as much fun, thanks to a great team and an awesome work culture at Iventa. (And I'm not just saying this because my employer might be watching this blog right now.)
  4. I've started growing a paunch. It's hard work, but it seems to be working.
  5. My computer - Hangy - has died multiple times, and has usually come back alive. She has been asking for a lot of my attention lately.

There's so much more I could add to that list. The last couple of months have been action-packed. But the point of this post is to remind you that this blog is not dead. It has, in fact, just sprung back to life!

PS: Thank you for all those lovely mails asking me to get back to writing. Your mails mean a lot to me. Thank you again. (You know who you are.)

PPS: Almost forgot! Wish you a Merry Christmas and a great New Year! Keep Partyin'!

Monday, September 19, 2005

Google Indexes The Future

I love Google, if you haven't gathered from my blog already. But now I love it even more. If you haven't checked out Google Desktop, you should. What is really cool about it, is that it even indexes files you haven't created yet, so that you can search through it. It makes for a really powerful search, since you can get documents from the future today. Take a look at the screenshot of the indexing status if you don't believe me.

Google Indexes the Future

Monday, September 05, 2005

Yellow Sun, Yellow Plastic

Yellow Sun, Yellow Plastic

I was in Goa a couple of days ago for a "official trip". Though the trip was largely hectic, I did manage to get a shot or two.

This pic was shot at a desolate stretch of beach at Canaconam, Goa.

And sorry for the corny title. Creativity eludes me at the end of a tiring day.

Tuesday, August 30, 2005

One Year...

...and counting.

Monday, August 22, 2005

When Referrals Are Funny

Rather frequently, people enter weird things in the search-box in search engines. Very rarely some of those results point to my site. Almost always I note down those search terms. Here’s a partial compilation of the funny search terms that have landed people on this blog.

  • MSN: Man converting lions to Christianity – And a man with a lot of time at hand.
  • Yahoo: Apologize for electing Bush – What kind of search string is that!
  • Yahoo: Why you always feel smarter after a couple of beers
  • Google: Google hacks Jaipur – And I thought Google was not an evil empire.
  • Google: Picture of devil – for some reason, Google repeatedly thinks that I’m some authority in pics of the devil.
  • Google: Kitchen designer in Mumbai – Why on earth is Google sending this guy to my site?
  • Google: Censored Marathi sex articles – I can understand where this guy comes from, but it’s where he comes to that surprises me.
  • Google: Attack of the nerds – yes, I use my site primarily to congregate nerds so that we can take over the world.
  • Google: Parvathi Goddess MP3 – Wow! I didn’t know she was into modern music delivery formats.
  • Google: Haven Pai – I have no clue what that means.
  • Google: Buildings with CSS in Mumbai – Yeah. It’s CSS that makes buildings look good.
  • Google: Web page not responsive in the cash – Well, ever considered having a business model?
  • Google: What is the search string to turn up camera feeds on Google – someone actually typed this. In Google. A search for a search. Cool, huh?
  • Google: Food preparation using microwave oven and Tamil fonts – Should make for a spicy meal.
  • Google: Rakesh is God – I know that already.
  • Google: Illegal Rakesh – Please read the point above.
  • Yahoo: Gravitation cannot be held responsible for people falling in love – Of course. Only stupidity can.
  • Yahoo: Atlanta booty shake – Sorry to disappoint you on my site, mate.

Thursday, July 28, 2005

Mumbai Under Water

Mumbai is recovering fast from the downpour two days ago. You may want to see pics of it at flickr.

It took me two days to come back home, but I'm fine. Thanks everyone for those mails. Everyone I know is fine too. I hope everyone you know is fine.

Thursday, July 14, 2005

Not Jobless Anymore

I just picked up my offer letter from HSBC Asset Management yesterday, for the position of Executive - Web Design.

I still get to continue doing my freelance projects as I was, though an immediate slow-down is inevitable. I've been doing it for more than two years now, and simply quitting would be impossible.

I am still to settle down at the new job with the new work timings (I'll actually have to get up in the morning), new bunch of work-related problems (for starters, I'll have to make an hour long train commute to work everyday) and new dress code (I understand I can't code in my underwear anymore). I start the routine on Monday.

I hope this means that I'll get a lot more time at hand to do more reading (my feed reader indicates that I have more than 4000 unread items in my box), and writing (and you thought I had plans to wrap up this blog soon). I will also hopefully get more material on and exposure to real-world web-based issues.

Anyway, for now, it's time for celebrations. Time for hitting that bottle of beer. Again. After all, it's a new excuse.

Friday, June 24, 2005

Chainsaw In Red And Blue

Chainsaw in blue plastic wraps

So, two days ago at 3 in the morning, the huge tree opposite my house came crashing down with the wind and rain, breaking a compound wall, shattering a couple of windows in my apartment, and crushing two cars among other things. Fortunately, other than one really dumb guy who ran toward the broken glass to see what happened, no one was hurt. The fire-brigade was there in minutes and chainsawed the tree into managable chunks to clean the place up.

I got this pic when they were busy planning their strategies.

For those interested, I have a couple of more pics on Flickr.

Friday, June 10, 2005

On The Edge Of The World

The Edge Of The World

The funny thing about computer games is that every map has an edge. It's called The Edge Of The World. It always looks like a hazy area fading into blackness. An area you just can't access.

If I was living my life in a computer game as a game character, I'd know it wasn't real if I came to The Edge Of The World.

This pic was shot in Podanur, not too far from where this pic was shot.

Sunday, June 05, 2005

What Would You Do?

Let's say you are a freelancing web developer and designer. You take pride in the quality and technology of the stuff you deliver. You like to work on the bleeding edge of web technology. You will go out of your way if necessary, to implement solutions that are apt for the client's business. You like to study their way of working and the goals of their site, and prepare a solution that makes good sense for their business, both technologically and economically.

You are just starting out with your career. You have no money. You are almost completely broke. You could do with any project that will bring in money.

A prospective client from a wealthy country approaches you with a great deal. He is willing to pay you outrageous amounts of money for getting his website developed. There's only one hitch.

The site contains sexually suggestive content.

What Would You Do?

PS. If you are wondering, I bailed out. I might be the century's biggest fool, but sometimes money isn't everything, I guess. Let's just say I didn't do it because of ideological issues.

Tuesday, May 31, 2005

Gone Fishing

Gone Fishing

This photograph, shot at a beach in Mahe, Kerala, is a panorama composed of 3 photographs arranged in a row. To the extreme right, is a fisherman grabbing his catch for the day.

I was wondering how the panorama would turn out, because of varying exposures in the different frames, the dynamic nature of the sea and the waves, a slight haze in the air, and no real subject. I'll let you judge that, though.

(Yes, I know I could have done a better job of stitching them together, but I wanted to give the Adobe Photoshop CS's Photomerge function a shot. It took all of 5 minutes to stitch them together.)

Friday, May 27, 2005

The Real Problem With Ajax

The real problem with Ajax is that you have to stop thinking of the process of getting information as a linear sequential process, and start thinking of the browser as a true application platform.

Now, only if that problem was easy to solve.

Sunday, May 22, 2005

Communication

Communication


This image was shot in a small town called Podanur, about 15 minutes drive from Coimbatore, Tamil Nadu.

By the way, I wanted to know what tools you use to correct spherical aberrations. Could you please leave me suggestions in the comments? Thanks.

Friday, May 13, 2005

You Know When It Happens...

Today I was at the barbers, and he said that he wouldn't cut my hair too short, because "it would show".

You know when it happens...

Thursday, May 12, 2005

Back From God's Own Country

Kerala Backwaters

Just got back from Kerala, so I'm making a quick post. This image was shot at the backwaters in Kerala somewhere about an hour's drive from Ernakulam.

Oh, I had a great trip too, if you have to ask. Kinda tired. I'll post something more soon.

Wednesday, May 04, 2005

I'll Be Right Back

As if I haven't been ignoring this blog enough, I'll be taking a 10 day break to go to my home-town, Kerala.

When I'm back, I promise to have LOADS of photographs, website design talk and other tech stuff. It's been sitting in my mind/drafts for a long time now, but time has not been a good friend lately.

Until next time!

Thursday, April 14, 2005

Two Women And A Kid

Two women and a kid

Friday, April 08, 2005

What Extensions Do You Use?

I have quite a few extensions installed for my Firefox, some of which I cannot do without, and some others that make me wonder what I was thinking when I installed them. Here's a list, in no particular order.

For the surfer in me

  • GMail Notifier - I've almost substituted this by a Konfabulator widget that does a much better job, but this is still rather useful.
  • Bloglines Toolkit - Because I'm such a Bloglines fan.
  • Mouse Gestures - I admit I'm lazy. And that this is really cool.
  • LiveLines - I never really liked LiveBookmarks anyway.
  • Dictionary Search - Cause my English sucks.

For the web-developer in me
  • DOM Inspector - Always nice to have this around, though I've still to learn to use this well.
  • ieview- Saves me a lot of URL copy-pasting to check my designs in IE.
  • Web Developer - Simply indespensible. It's probably the single most important reason to develop for Firefox, second only to the whole standards thing. This is probably more important than even a good code editor!
  • ColorZilla - For the times when I've forgotten my color codes, or am too lazy to go through that dreaded CSS file again. Or when you just want to steal that cool color. (Wait. Did I just say that?)

For I-don't-know-what
  • Google-Preview - I actually liked this at one time, and was actually using it, until realization dawned upon me that this takes up more bandwidth than it deserves.
  • Mozilla Calendar - It's really cool. For what?
  • BugMeNot - I haven't tried, but does this work with my pr0n sites?
  • SpellBound - Neat idea, but I only wish it wasn't so clunky.
  • fireFTP - I almost fell in love with Firefox all over again thanks to this extension, until I found a bug that didn't let me see my .htaccess file. And, boy, do I need to play with my .htaccess a lot!

Which are your favourite extensions? Maybe I should use some that you are using to simplify my work? Share your list in the comments.

Sunday, April 03, 2005

Call Center Chaos

I was on the floor laughing when I saw this video of an episode of The Tonight Show with Conan O'Brian. It is funny enough to devote an entire post to it, even if short, so go download yourself a copy.

I find it interesting that people are finding humor in this now, as opposed to the initial hatred towards these jobs.

On a side note, I picked up this video from a very close friend's blog. Vikram has only just started his blog, and promises to keep it good. Go over and say hi!

Friday, March 25, 2005

Lunch

Lunch

Lunch seemed interestingly photogenic today.

Monday, March 21, 2005

Protesting To The Gods

After what seems like ages, I turned on television today, and happened to stop by at the local cable channel. The screen, instead of showing the latest Bollywood movie, showed scrolling text on a black background.

Due to the sad demise of Mr. Sanjay Gupta (Cable Operator / Distributor) of New Bombay. We will unanimously keeping the cable channel shut in protest.

Wednesday, March 09, 2005

Firefox's USP

During an idle conversation with a friend this afternoon:

She: You know, these days I get pop-ups with Firefox.
Me: Yeah I know. Those darn advertising guys. They've found a way around the pop-up blocker.
She: But the pop-up blocker was the greatest thing about Firefox. I'm afraid there's not much difference left between Internet Explorer and Firefox this way.

I considered starting an argument about standards, and how Firefox is going to save the world, but I knew that was futile. For the lay-person, Firefox gave a better experience when surfing. And now, that experience is threatened.

She is terrifyingly correct.

Tuesday, March 08, 2005

Script Tag In Internet Explorer

After a sleepless night or two, I just discovered this bug in Internet Explorer the hard way.

I was bascially including a JavaScript file in my XHTML document. The scripts in this file were meant to attach to my XHTML elements unobtrusively, and this file was a unit by itself. So I didn't have any JavaScript within my script tags. This is how my tag looked.

<script language="javascript" type="text/javascript" src="script.js" />

This works like a dream everywhere, except in the world's most popular browser. In IE, the entire page is just blank! The markup is downloaded properly (I can see it when I view source), even my CSS background-color is applied to the page, but there's absolutely nothing on it! I blamed my content-negotiation scripts first (I am serving HTML Transitional to IE and XHTML everywhere else), and then on IE's support for CSS (I thought I made a grave little mistake somewhere). However, on removing this tag, everything worked fine in IE.

Turns out, IE doesn't like the script tags if they are using element minimization. I got the page rendering just as I intended by changing the tag to look like this:

<script language="javascript" type="text/javascript" src="script.js"></script>

Doing some research, I came across this post in theList by Eric Vitiello which clarifies this more. Apparently the DTD declaration for the script tag says <!ELEMENT script (#PCDATA)>, and the XHTML specs says (under Appendix C. 3):

Given an empty instance of an element whose content model is not EMPTY (for example, an empty title or paragraph) do not use the minimized form (e.g. use <p> </p> and not <p />).
So, I guess this isn't really a bug in IE. I'd think instead, that this is a bug in the DTD itself. The script tag doesn't have to contain #PCDATA (in fact, I consider it graceful if it doesn't), and forcing it is, well, stupid.

For now, I am explicitly closing the script tag with a seperate closing tag, and everything seems to be working well. Does anyone have any idea about handling this better, preferably with minimized element closures?

Monday, March 07, 2005

Knopfler Leaves A Mark

Knopfler Leaves A Mark

It was one hell of a night. We had to smuggle in the Vada Pavs and the Bacardis and the Wills and the matches and the ... well, you get the idea. But they managed to catch us when we were smuggling the water in. Damn! Had to waste a whole bottle!

Anyway. I was hoping that he'd play some more of the Dire Straits and atleast one little song of The Notting Hillbillies, but I had to be happy with about 40% of his solos and the rest almost exclusively from Brothers In Arms and Money For Nothing. But who's complaining!

Sorry for the cheezy pic. I had clicked pics at the show, of course. (I had smuggled my cam in too.) But let's just say that the shots turned out to be a little shaky.

Friday, March 04, 2005

Help Me Escape This!

Help Me Escape!

Yup, today is one of those days. I spent my last 10 minutes staring at my text editor, thinking that the syntax highlighting looked trippy. Then I got up to drink some water. When I came back I checked and double checked if my white-space and indenting was correct and consistent. Then I thought I'll get some chips from the kitchen. When I got back I started thinking how I can add more comments to the code to make it readable. Then I was deciding if asterisks work better than slashes as the thing you put before and after a line of comment in the code.

I guess it's fair to say that I am having an utterly unproductive day today. Do you have such unproductive days too? What do you find yourself doing on such days?

Monday, February 28, 2005

MotorShow @ Mumbai

Here are some of my pics from Flickr abouts the Motor Show I had been to recently in Bandra Kurla Complex, Mumbai.

Skoda

Skoda

Crazy Mod

One hell of a crazy mod

Vintage

Isn't she beautiful!

Tuesday, February 22, 2005

The Future, Now In Russian

One of my previous posts titled "Web Applications - The Wave Of The Future" has been translated to Russian by Alexander Kachanov. I myself don't know Russian, but I think it's pretty cool to be able to read a post in a language of your choice after it has gone through a human translation.

So, Russian audiences, head to his site if you prefer to read my post in Russian.

Though I've been getting referals from non-english sites discussing my posts, this would be the first time that one of my posts has been translated to a non-english language.
/me swells chest.

Tuesday, February 15, 2005

Google and Flash

Google And Flash

Now, this is toally surprising to me. I always thought that Flash was bad for SEO, but this search result has proved me completely wrong. I was doing a random search for "All your base are belong to us", and the first hit turned out to be a Flash file!

I didn't know that Google indexes swf files at all. In fact, I always recommended against using Flash for a site primarily for SEO reasons. Since when did Google start indexing Flash files?

Even more interstingly, the little line below the main hit result link shows a link to "View as HTML". Unfortunately, when I tried, none of these links worked. Looks like Google is broken there.

This is really interesting. Not only is Google able to spider and index swf files, it is also able to potentially convert them to HTML files! How can Google access the content of the swf file? How can it sensibly convert that data to an HTML file? (Can someone please have a look at those "View as HTML" links and tell me what you see?) Has this been going on for some time now?

Check it out for yourself. Google swf.

Update: It appears that I spoke too soon without adequate research. Google has been indexing Flash files for almost a year now. Check it out! Even so, don't you think this Google-Flash thing deserves more attention? How come no one has been talking about it? Can someone shed some light on the topic?

Thursday, February 10, 2005

Flowery Fuzz

Flowery Fuzz

I apologize for not posting too frequently anymore. There is a lot of work piled up, and for once I am running short of time.

This post is just my way of saying that this blog is not dead, though it might seem like it at first sight. It is just one of those slow-downs. There are a lot of things I have planned out for this blog, and I'll start doling them out as soon as I am sure I can get it out of the drafts.

P.S. I have entered this photo in the Photo Friday challenge this week, for the theme "Distorted". If you have nothing better to do, please go over and drop me a vote. If I win, I promise you and your entire family GMail Invites. I've got lots! I know that using GMail invites as bribe doesn't work anymore, but I can't afford too much more.

Tuesday, February 01, 2005

Google Hitting Me Hard

One would think that the number of visitors to a blog would drop, considering that it is not updated frequently.

However, in my case, my hits have been steadily increasing over the last two weeks. One of the largest source of these hits (about 14%!) is Google Image Search, pointing to an old post and its pic.

Now, that pic is one of my all time favourites. I had clicked that pic just casually, and the uploaded version is un-touched-up. It is also one of my first macro shots ever. That pic will remain a special one for me.

What makes me curious is, how come I have such a sudden surge of visitors going to see that pic? Unfortunately, the Google Image Search referrer URL doesn't give me any details of the search string, or their referrers. I tried doing basic searches at Google Images, but that didn't turn up my pic for the keywords I could come up with.

If anyone has come here from Google Image Search, could you please tell me how you got here?

Thursday, January 27, 2005

Thoughts on XMLHttpRequest

Some more thoughts on XMLHttpRequest, from my recent experiences with the tool.

Continue Reading...
I was going through my referrer list today, and come across another user who came to me through Eric Meyer’s post about (and in response to my older post) the Economics of XHTML, where he (Eric) talks about how the savings in bandwidth appreciates the value of the site.

These days, I have moved away from talks about markup (as most of you must have noticed), mostly for two reasons.
  1. XHTML is too stringent. It is so stringent, it is not practical.
  2. There are other ways to save bandwidth.
I have to explain. Though I’ve been talking about standards frequently on my site, only recently have I decided to get my hands dirty with a project that talks in XHTML and respects it (which is more difficult that it seems at first glance) at least when talking to browsers that can handle it well.

Reasonable digress: Of late, I have been damn busy. I guess everyone goes through these phases where he thinks that he’s reading too much RSS, but I’ve just stopped keeping myself updated because I don’t have the time anymore. However, I still take the time to comment on the odd good article.

One such post was Roger Johansson’s. He talked about how XHTML can be made easier to use, but in his comments (though he tried hard not to), the discussion shifted to whether XHTML is really worth the effort or not. I maintained that though XHTML is a good way to learn, it is probably not what we’ll use in practice.

That apart, here’s why I am making this post.

I’ve been working on a lot of DHTML these days. Not in the traditional sense – I probably have to call it DOM Scripting to be politically correct. XMLHttpRequest has been my most interesting toy. I’ve been playing with it like a baby boy plays with his first toy truck. He just rides it all over the place. He runs it over terrains that the toy couldn’t possibly take on, just because somewhere in his heart he’s confident that it’ll hold out. XMLHttpRequest has been my toy, and the web is my terrain.

Here are my lessons, good and bad, listed out, while working with XMLHttpRequest.
  • I think this is the most important issue. Using XMLHttpRequest doesn’t change the URL. Think about this. Eric said that a page that loads faster is good for business, and XMLHttpRequest does that for you in more ways than one. But XMLHttpRequest doesn’t respect URL resources, as seen by the address bar. If you use XMLHttpRequest, your page’s URL remains the same, whatever else you do. Do you need permalinks for your content? XMLHttpRequest can't deliver.
  • Using XMLHttpRequest involves a lot of DOM Scripting (especially if you think I am correct when I say that data should be passed as JavaScript over XMLHttpRequest). This is a problem for me, mostly because I use XMLHttpRequest in conjunction with XHTML. A command as simple as element.innerHTML won’t work with XHTML. You’ll have to get into the mess of document.createElement, element.setAttribute and element.appendChild way too often. There are a couple of tutorials on the web to explain these concepts, but mostly you are on your own.
  • XMLHttpRequest doesn’t come without its differences between browsers and their implementations. I don’t mean to scare the one’s who are starting – it’s really not that difficult. But just don’t expect one piece of code to work everywhere. We haven’t reached markup, styling and scripting nirvana yet.
  • I’ve come across a lot of browser bugs in the implementation of XHTML and XMLHttpRequest scripting. I use Firefox, and (ok, probably after Opera) I think Firefox’s support for standards is pretty good. Yet, Firefox catches me off guard sometimes. And don’t get me started about other browsers yet, including the most popular one. (By the way, for the uninformed, XMLHttpRequest is NOT part of the standard – probably why Opera hadn’t supported it until recently.)
  • In the end, probably in a nerdy sort of way, XMLHttpRequest is fun. It makes entire page-loads unnecessary. It makes information easier and faster to get to. It makes the user happy. It doesn’t involve too many UI issues. (I thought a user will never be comfortable unless he sees a page refresh when he clicks on a link in the browser. Obviously, I am wrong.) If well planned, XMLHttpRequest rocks!
  • XMLHttpRequest is tempting to overuse. This not such a problem from the developer’s point of view. However, I am not so sure if it’ll really save you bandwidth in the long run. The problem is that, since users find it so responsive, users will like to pamper themselves with more data than they’d otherwise need. XMLHttpRequest makes it easy, and fast. Just what the users need to have a good experience. I think all those talks about XMLHttpRequest saving the developers’ bandwidth needs to be re-thought. I have no math to back me up, but this is what my hunch tells me.
  • Did I say yet that XMLHttpRequest rocks? It’s the best thing that happened to the web since the invention of HTTP itself. It’s the stuff that’s going to direct the development of the Internet itself for the next half decade. But like every other intoxicating substance, it could be a life-saver or a poison depending on how you use it.
I guess I have no point to make in the end – I am probably too drunk to conclude. (I’ve been celebrating a VERY close friend’s wedding engagement tonight.) But I hope I’ve put across the point that XMLHttpRequest is good and yet bad, in it’s own ways. And that is so much like every other programming tool.

It’s just a matter of what suits the job best. Flying a jet to work is too much power in your hands, but walking down to work is too little, if you know what I mean. You just have to use the right tool at the right time. XMLHttpRequest is just a tool – you have to decide when it’d be good and when it’d be impractical.

For those who are in doubt, XMLHttpRequest is a tool you are not going to be able to do without. I think that web-developers who still work with old style HTML are already on their way to losing out, but now web-developers who haven’t mastered XMLHttpRequest are on their way to meeting the same fate. Yet, it’s a tool like any other – it has to be used at the right time for the right purpose. Every other time, it’s probably more effort than it’s worth.

Monday, January 24, 2005

Jazz By The Gateway

Jazz By The Gateway

This pic was taken at the Gateway of India, during a jazz show as part of the Mumbai Festival. Performing at the show were some of the greatest living exponents of the art of jazz - Al Jarreau, George Duke, Ravi Coltrane and Earl Klugh along with members of The Thelonious Monk Institute of Jazz.

I didn't go for the show, if you had to ask. (I'd probably have got better pics if I had, but I was too late to get the tickets.) This is a Hail Mary shot taken from outside.

For readers who do not understand photography jargon, Hail Mary shots are where the photograph is taken with the camera held above your head, like in a crowd, without looking through the viewfinder. The camera settings have to be adjusted beforehand, and the frame is just plain guessed.

In this case, I was outside a barracade containing the show. I couldn't see this frame - I had a sheet of asbestos between me and the Gateway. I only held my cam above that barracade and shot.

(Ok, I promise that's the last post about the Gateway, its waters, or of the Mumbai Festival.)

Blog Of The Day

This is probably not a big feat, but the excitement is because this is a first.

This blog has been featured as the Blog of the Day for today, on BlogStreet India.

Cheers!

Wednesday, January 19, 2005

Mumbai Fest - Some Pics

There was a huge collaborative street art project at Kala Ghoda, Mumbai as part of the 10-day Mumbai Fest. I happened to be around, and get some pics. (The pics link to Flickr)

Pic 1

Pic 1

Pic 2

Pic 2

Pic 3

Pic 3

Pic 4

Support drugs. Do good karma.

Tuesday, January 18, 2005

Illegal To Display Feeds?

I came across (and I must say this) a really stupid post at The Trademark Blog, where the author accuses Bloglines for illegally reproducing his site's content.

It was brought to my attention that a website named Bloglines was reproducing the Trademark Blog, surrounding it with its own frame, stripping the page of my contact info. It identifies itself as a news aggregator. It is not authorized to reproduce my content nor to change the appearance of my pages, which it does.
I think this kind of thoughts either stem from a poor understanding of feeds, or maybe this guy is just looking for legal issues to talk about (he's a lawyer, after all), or both.

Bloglines might be putting their ads next to my content and earning money out of it. I don't think that constitutes "commercial use" of my content. They are providing a service, for which they are going to need money to run, and ads are a good way to get that done. The ad money I make off my site is barely anything, anyway. I don't mind if I lose an additional $2.05 to Bloglines, considering that my user-base is actually increasing thanks to services like Bloglines. I could think of it as paying them to keep my audience coming.

Besides, it's not like Bloglines is running a site that makes money thanks to my content being published there. The users of Bloglines choose to put a feed in their reader, and Bloglines just provies a means to read that feed easily. Bloglines makes money because they provide a great way for users to read a site's content, grabbing what the site's authors have willingly distributed for just that purpose.

Personally, I read a lot of feeds too, a lot of which I prefer to read in Bloglines and not on the original sites. This is because, with Bloglines, I can strip off the clutter on a site, and grab just the content of the site, in a font, style and layout that I am comfortable with, and that works with all the other 130 sites in my feeds list, consistently.

I did come across a similar problem recently, where a blogger had published one of my recent posts on his site, even though he gave me full credit for the post. I just sent him a friendly mail asking him to get my content off his site, and instead link to me if my articles are really important to his site's audience. Promptly, he removed that entire section off his site. (Apparently, it was his personal link blog, and he has now put that behind an authentication system ensuring that he's the only one reading it.) I am ok with him reading my feeds, really. I guess it would be a problem if he publishes my posts without asking me first. Publishing my post on his site, and reading my feeds are two different things, though. Obviously this blogger respected that when I brought it to his notice, and did the needful to correct the mistake.

In the end, is it illegal to view/display/publish feeds from a site? No, it isn't, considering that the site's author willingly distributed the feeds. Is it illegal to publish one single article on a site without the author's permission? It probably is, but more than that, it's unethical, and should be refrained from doing. Is it illegal to make money by providing a service that reads feeds? Definitely not!

I think I am thankful to Bloglines for making sure that I get a consistent flow of people reading my content, even if they don't ever visit my site. If I don't like Bloglines' idea of reading feeds, I should probably just stop publishing feeds. But that'll just crash my audience-size. In fact, I like the idea of Bloglines displaying my feeds so much, that I had written a post earlier recommending that people read my feeds through Bloglines, and I even added a permanent link on my sidebar making it easier for people to subscribe to my feeds with Bloglines.

How about that, Mr. Lawyer?

Sunday, January 16, 2005

Lights, Camera, Arches!

Lights, Camera, Arches!

Shot the other day at the Gateway of India. I had to clean up the monument a lot with my copy of Photoshop, because the government hadn't done a good job. (Thanks Kaushik, for patiently showing me how to play with Photoshop.)

Previously:

Wednesday, January 12, 2005

I Graduated!!!

News has just come in. I am finally a graduate.

Bachelor of Engineering (Electrical and Electronics). Aaaah! That feels good!

Meet me at my local watering hole tonight to join in the celebrations.

Why XML in XmlHTTPRequest?

The XmlHTTPRequest function was designed so that the client can get small pieces of information from the server without having to do a page refresh. Obviously, the developers thought that XML will be the format of choice for this data exchange.

Thank God they didn’t make XML validation necessary!

I say this because XML will not be the format of choice for this data exchange. Let’s see why.


Firstly, let’s see how the data flow will be in the case of XML over XmlHTTPRequest. A typical scenario is where the data lies in a database on the server, and the data is requested by the client. The steps in the process will be:
  1. Server reads the request, extracts the data from the database.
  2. Server prepares an XML document using this data.
  3. This XML is sent to the client.
  4. Client validates the XML for well-formed-ness.
  5. Client extracts data from the XML markup.
  6. Client calls functions/triggers events which use this data as parameters in some way or other.
For several reasons, this model is not optimum. The questions that come to the mind immediately are:
  • Is it necessary to prepare an XML document (step 2 above)? Isn’t that an extra step that is probably not necessary?
  • Client validation is necessary (step 4 above) to ensure that the XML parser can parse the XML. This puts heavy processing requirements on the client. Is this really necessary?
  • The data from the XML will then have to be extracted (step 5 above). This isn’t really a necessary step either if the data is not marked up as XML. So, then, is it really necessary to use XML?
Then there are more problems. In web applications, where XmlHTTPRequest is most likely to be used, speed is of utmost importance, and optimizing for fast response times will be imperative. In such cases, the amount of time taken for any kind of operation, especially if it happens over the network or the internet, has to be minutely scrutinized and optimized. In such cases, XML is probably not the best suited format for data exchange. XML files are heavy as far as sizes go. A simple text like “Hello World” (11 characters) can be transmitted over XmlHTTPRequest as 11 bytes of data. Marking this up as XML will increase this at least 4 fold (say, and that’s still a conservative estimate) even if whitespaces are stripped off the document, increasing download sizes four times, and reducing response by a factor of 4. Point is, XML comes with its overheads which cannot be tolerated in a web application.

So, in what format will data be transferred over XmlHTTPRequest? The simplest way is as a plain old string of data. This will be the most efficient as far as download speeds are concerned. You will download only 11 bytes where 11 bytes of download is required, not more. Besides, there won’t be any XML parsing or validation in the picture, making the application that much faster.

However, somehow, I don’t see data flowing over XmlHTTPRequest in the form of plain strings of data either. Instead, I think it’ll flow in the form of JavaScript code.

Let me use an example from the guy who deconstructed Google Suggest, and the way XmlHTTPRequest works there. According to him, the code returned by Google when you hit a keystroke looks like this.

sendRPCDone(frameElement, "fast bug", new Array("fast bug track", "fast bugs", "fast bug", "fast bugtrack"), new Array("793,000 results", "2,040,000 results", "6,000,000 results", "7,910 results"), new Array(""));

Basically, what this code does is call a function, with a bunch of parameters. The function called, sendRPCDone, is defined in client side JavaScript code. The parameters are generated depending on server side processing (probably from Google’s cached searches). Then, later in the code, this response text is run through an eval function to execute the function on the client side (eval(_xmlHttp.responseText);).

I think the eval function is really a boon here. It makes JavaScript as the language of choice over XML for XmlHTTPRequest. For who don’t know what eval does, it basically takes a piece of string, treats it as though it is JavaScript code, and executes it. The string could be dynamically generated by client-side code, or as in this case, returned from the server. Just what we need here!

To summarize, here’s why we’ll use JavaScript instead of XML when using XmlHTTPRequest.
  • Downloading XML data will take more time as compared to JavaScript. Depending on the amount of data to be transferred, this difference might be huge.
  • Use of XML will necessitate validation of the markup, so that a parser can read the document – a process that requires extra processing on the client-side. This is not necessary with JavaScript.
  • The XML data is not already in a position to call scripts. Client side code will have to handle that, based on event handlers or such. JavaScript, on the other hand will be ready to be executed on the client.
It's easy to see why XML will not be used as the format of choice over XmlHTTPRequest. A little thought later, JavaScript emerges as the winner as the format of choice for data exchange over XmlHTTPRequest.

Did someone say that JavaScript will be coming out of the closet this year?

Tuesday, January 11, 2005

Google Logos

You are probably aware of the fact that occassionally Google changes their logos to celebrate a festive occassion. These logos (called the Google Doodles) are really nice to look at. Go have a look.

What I didn't know (and I happened to notice it from somewhere) is that Google has different search sites for specific topics. Here's the list of some of them, with their logos:

I could'nt help notice the Google Microsoft Search logo. It is the only one with a non-white background. Somehow, it seems to be mocking MS with its sky and grassy hills combination.

Sunday, January 09, 2005

Reflections

Reflections

Reflections

Was spending a night out on the streets of Mumbai today with a friend's camera. I am totally not used to this camera but I managed to get an interesting shot or two. The cam is a Nikon Coolpix 3100 - the same series as mine, but only slightly less loaded.

This pic shows the reflection of the lights of Hotel Taj in the waters of the Arabian Sea, at the Gateway of India.

Thursday, January 06, 2005

Web Applications - The Wave Of The Future

Web applications are finally beginning to see the light of the day. I am putting all my money on this. I am sure this is the future of the web, application design, networked software architectures, maybe even desktops and operating systems itself.

Web based applications will make inroads into (almost) every kind of application we use today. In this post, I try to list out some of the benefits of using web based apps.

First, a quick introduction to web based apps, for those who just tuned in. Examples of web based applications are GMail, Bloglines, and OddPost. GMail is a full featured mail client that does everything that a desktop mail client does, only ups it a few notches. So does OddPost. Bloglines is a web based feed reader that is directly competing with desktop feed readers, and winning. These web apps are basically applications that run on a server, whose UI is exposed in the form of web pages. By the very nature of its architecture, the program logic lies in a central place (the server), and the UI is available to the client in a piece of software that has been around since the birth of HTTP itself (the browser). The use of JavaScript and the DOM is probably the single most important factor that has made these apps possible.

The use of JavaScript is very different from the way it was used in 1999. Back then, JavaScript was just a cool way to make mouseovers and cool (now irritating) dynamic elements on the page like mouse pointer trails and flashy text that change colors. JavaScript was used because it could be, not because it should be. At one point, I thought JavaScript was dead, indeed like many other developers must have thought. The use of JavaScript became an example of bad web design, and the language was pushed into the dark annals of the world of notorious web pages.

Now, though, JavaScript has matured. It is used just what it was designed for - creating dynamic changes on the client side without introducing a server refresh lag. A dynamic front end in a browser window has always been a problem for application design and is probably the only reason why web based applications have not yet seen the light of the day. Today’s use of JavaScript circumvents that problem.

Now that we can make web applications, here's why we should, and will, do it.

The application lies at only one place

The application logic lies on the server, unlike desktop applications, where the application logic lies on the user’s computer. Since there is only one working copy of the application, it’s much easier to distribute. In fact, distributing applications in the traditional way doesn’t make sense here at all, since the user doesn’t really get a copy of the app at all. All the user gets is the UI, which is really all he needs. Application distribution is a non-existent problem, which means it is as easy as it can get.

The user doesn’t need any software

All the user does is fire his browser and type in a URL. These days, browsers are a standard piece of software that usually gets bundled with the OS itself, so finding a browser on the client is not a problem at all, and really, that’s all the user needs.

The user isn’t the administrator

Typically, when a user has the need for an application, he has to prepare himself to be the administrator of the application. He will have to do the setup, running, maintenance and troubleshooting, and handle all the problems that come with it. But in the case of web apps, since the app is really not with the user at all, the user won’t have to worry about these problems. And really the user shouldn’t. That makes for a happy user. That translates into a good application. This, of course, is impossible with desktop applications.

The administrator is the application’s programmer

Yes, the load on the programmers is more. But if you compare that to the costs of making deployable applications and then managing a service team to help users install, maintain and troubleshoot the application, it’s easy to see which is cheaper, not to mention more efficient. A small team of programmers working at one central location to maintain, manage and troubleshoot applications makes more economic sense to app manufacturers.

The application makes no assumptions about the user

Ok, that is a small lie. The user is assumed to have a capable browser to handle the application. But really, is that such a big deal? Because of the very nature of HTTP, the application is platform independent. This means that the user can use any operating system he wishes to use, and that doesn’t make a difference. This is a huge change from the traditional “Designed for <operating system name here>” applications. The user doesn’t have 512 MB RAM? No problem. The user doesn’t have processing power? No problem. The user has an outdated motherboard? No problem.

Multiple versions is a thing of the past

When a new version of the application is out, every single user gets to use it instantly. Literally. How cool is that! Again, this is possible since the application is centralized, and there’s really only one running copy of the application. All version changes are instantaneous and the user doesn’t need to know how to upgrade. This also means that the app developers don’t have to worry about supporting legacy versions and backward compatibility is not an issue.

It’s lightweight

The user doesn’t really download the whole application before using it. (Take that, Java fans!). He doesn’t even download the whole UI. He only downloads the part of the UI that is required for his use immediately over the URI that he’s on. This makes the application very lightweight and hence responsive and fast. Even very complex applications can load in seconds, maybe less, even over a bad connection, thanks to this.

It’s portable

There’s nothing installed at the users end, so the user can use the app from any location. Any location means literally any location across the globe. You can use the application in your office, and then at home, and then from your vacation in Hawaii, and every time it works just as well, without any problems of portability.

It’s simple and trustworthy

No messy extra protocols or port numbers. If your firewalls lets you see web pages (and which firewall blocks that!) you can access the application. So the user doesn’t have to know a thing, or worry about it. He just fires up his browsers, and enters a URL. Simple. Even better, since the application works in the protected environment of the browser, the application can be trusted and can never mess with the user’s system. No more can an application “slow down your system”, or “crash every once in a while”. Those complaints are a thing of the past.

The app architecture is transparent to the client

So, the programmers think that it would be a good idea to have separate data servers? Maybe split up demanding processes and push them to different computers to handle the job? Maybe they need a whole bank of a hundred thousand computers working together to do the job? This kind of architecture can be designed for optimum load balancing between servers. However this is entirely impossible with desktop applications. With centralized applications, it’s not difficult to construct and maintain such systems. In any case, whatever be the server architecture, the user doesn’t need to know or care.

Sure, web applications can never do some things that desktop applications can do – far from it. You will never be able to do a defrag through a browser. You can never run 3D modeling software through a browser. Browser based apps cannot replace system programs at all. Not for a long time to come, at least. However, for application programs, the desktop’s days are numbered.

Welcome to the show. Today’s act: The beginning of the end of the desktop.


Update: This post is now available in Russian. (Thanks, Alexander Kachanov)

Wednesday, January 05, 2005

Bad Forms

A site I frequent has a nice little local weather update shown on its sidebar. Now, I get my local weather forecasts delivered on my desktop through a Konfabulator widget, The Weather, and have been reasonably happy with it. Also, considering that in the web design circles, not too many bloggers are from Mumbai, I thought it'd be a nice touch to add to my site.

After some digging, I discovered that my weather feeds are coming from weather.com. Over at their site, they have tools to display the current local weather on my site, and was very pleased with it at first glance, until I discovered that I have to register to use it.

I have to say, I have issues with registering for services, especially free ones. I can cite various reasons why I do not and probably should not register. Most web designers must know that users do not like to register on a site. If they don't, they don't make for good web designers.

Aaagh! Let me get to my point.

Have a look at this form I had to fill to register. Done? Now, let me list my peeves out.

  • The form says that fields marked with the red asterisk are required fields. Is it just me, or do you find it funny too that every field has this red asterisk next to it?
  • Really, do they need my first name, last name, date of birth (what?), and gender (whaaaaat???) so that I can sign up for a weather service?
  • The address (and its various fields) are also marked with that asterisk. However, the state I belong to here in India is Maharashtra, which isn't listed there. In fact, none of the Indian states are listed there at all! Wait, it's only American states listed there? Maybe the developers forgot that The Internet is a worldwide network, and America is not the only place in the world? Wonder why they hired developers like that! Required field, you say? What do I select now?
  • Oh, hang on. They have a option where I can change the country from USA to India. However, I found that only after I found the 'State' dropdown box. Smart layout, I must say!
  • Oh, I am wrong again. Changing the country is of no consequence to the list of states. Even if I select "India", the states shown are all American! Smart!
  • Here in India, our pin codes are 6 digits long. However, I can only enter 5 digits in that box they have on their page. Let me guess, America has 5 digit pins?
  • Notice, I have not talked about concepts like accessibility yet. Obviously (or, the impression that I get without doing my right click > view source is that) the form is not the least bit accessible to other kinds of browsers.
I must say, it is really irritating when companies like this just assume that their audience is only American. The Internet is not just about America, you know. Don't make me fill forms which require my local information, without doing a study of what local information looks like outside your locality. In any case, when designing a form, please don't assume that America is the world. And please do not ask for stupid irrelevant information, like my gender. By the way, would you also mind giving a little thought to this little thing called 'Usability', while you are at it?

Sorry weather.com. I do not like you any more. I know you'll probably say "So what?", but that doesn't help improve your image. Quite the contrary, in fact.

May the web design community use that form as an example of badly designed forms. When you see forms like this, you can put one hand your stomach, point the index finger of your other hand to the screen, tilt your head backwards slightly, and laugh out loud with your stomach bobbing rhythmically up and down.

Tuesday, January 04, 2005

Link Bin

Sunday, January 02, 2005

Tsunami Links

Here are some links related to the Indian Ocean Tsunami.

Predictions for 2005

I am making this post for two reasons.

  1. Everyone is making similar posts.
  2. It’ll be fun to come back to this list at the end of the year to see how correct I was.
So, here are my predictions about the web for the coming year.

People will understand why IE sucks

We know why IE sucks, but the regular user doesn’t even know of his options. Alternative browsers that provide a better surfing environment will make users turn to them. Firefox will lead this bunch, probably breaking the 50% browser share barrier.

Developers will still not take to XHTML

Developers will realize that XHTML validation is a lot of work and not really worth the effort. Web pages will continue to use HTML. We will use the lessons we’ve learnt from XHTML, like semantics, separation of code and content, CSS based design and accessibility driven design, but the web pages will continue to be invalid XHTML, and people will discover that the validation doesn’t really matter at all. XHTML will be used only by purists. It will remain a great idea that we can’t use yet.

JavaScript will take the stage

2005 will probably be remembered most for the use of JavaScript and related innovations. Yes, that happened in 1999 too, but it will be different this time around. Developers will understand how to use JavaScript in a fashion that keeps the page accessible to even incapable user agents. XmlHTTPRequest will probably be the hero of the show through this year.

More Web Applications

There’ll be more applications running off a browser over the Internet. I can already feel this happening with me – I probably use fewer desktop applications than web applications. More and more system independent applications will run off the browser.

Brower independence will be in vogue

Sites that work only in one browser will be looked down upon. Most such sites will alter their code to accommodate multiple browsers or otherwise be totally browser independent.

Mobile browsing will be more important than ever

In the long term future, I don’t see people using a desktop computer just to check mail or send an IM. Instead, such things can be done faster and more efficiently on a mobile device, like a phone. Good browsing capabilities for such phones will be very important, and we’ll see crucial steps being taking in that direction this year.

Most of these are rather obvious. But then, not always is the obvious the necessary consequence. Let’s see what happens at the end of the year.

Happy new year to one and all. Hope the year is great for you.

ShareThis