I’ve been usign AJAX for a while, but it’s always a hassle to have to set up the Ajax module initially before you can start calling the data in. I remember I’ve tried about 3 different Ajax modules in total, and the 3rd one I found was the one I thought to be the best, with the most flexibility.

(if you don’t know what AJAX is, read up on this AJAX tutorial)

It’s the prototype.js framework, and I’m sure a lot of you savvy users know about it already. AJAX is only one of the MANY MANY components of this javascript framework which can expand your horizons significantly without the huge amount of time spent on it. You can get the prototype.js framework and the documentations at the official website, www.prototypejs.org.

The prototype.js framework is used on my own site as well as some other sites I’m working on, and it basically sets up an ajax calling function, as well as query creating methods so you don’t have to, and the functionalities are more robust than something I could come up with unless I had dozens of hours to kill. And I don’t.

The prototype.js framework also includes many other functionalities in regards to object control, string modification, along with the AJAX framework. It’s something any web developer (whether for hobby or professional) should look at. It saves you time and effort, while providing you with a very robust platform on which to code on.

Most websites we see that have maps embedded use Google maps (and some unfortunate ones still use MapQuest), and it works pretty darn well. However, I recently started working with Microsoft Live maps(also called Microsoft MapPoint) again, and I must say I prefer developing in Microsoft Maps way better than on Google maps.

Before I go further into the explanations, I need to note that I love the color configuration on the Microsoft live maps better. I often like to have subtle designs for the non-design elements in my sites. For example, I’ll have a strong header with colors, but the rest of the items have not too many dramatic colors. Google maps uses very vivid and thick colors, whereas Microsoft Live Maps uses thinner, more neutral colors, which is more adaptable to many different designs of websites.

From a developer’s perspective, here are a few reasons why I prefer Microsoft Live Maps over Google Maps.

• Microsoft Maps do not require an API key, whereas Google Maps requires you to sign up for an API key. While this may seem like a very little step, it’s another few clicks I have to make, and another line of code to insert. If it’s offered freely anyways, why not just open it up? I’m one of those business geeks who are incredibly obsessed with efficiency, so I prefer to avoid these steps.
• The API documentation and the SDK (Software Development Kit) provided by Microsoft is SUPERIOR to that of Google’s. Much superior without a doubt. The Google one is more like a freakin textbook, while the Microsoft SDK is much more well-organized and user friendly, to help initial understanding of the system. It comes in a hybrid format that combines visual example, code example, and the reference in 3 different tabs. It’s the easiest API documentation I’ve seen thus far (and I’ve studied Paypal, Google Maps, Shopping.com etc.).

I have a small example of an easy implementation of Microsoft Live Maps that my clients loved. It allows you to instantly type in any location/address/landmark into a field within my client’s website, and it generates directions and routes on the map instantly, without leaving the page.

Calcon Construction 

While I was re-designing my whole site (which I am still working on in many other sections), I ran into several CSS issues where things just did NOT look the same on Internet Explorer and Firefox. And of course it has been, and will be, a never-ending struggle as long as all these browsers are slightly different from each other, and over all this time I came to come up with some general rules of thumb in order to ensure cross-browser compatibility. So I’ll list a few of them here.

1. When positioning DIVs within DIVs to structure elements, use margins on the inner-nested DIV instead of using padding on the surrounding DIV.

   <div id=”header”>
   <div id=”menubar”>menu menu menu</div>
   </div>

   When you want to put some indentation of the #menubar so that it does not touch the edge of the #header DIV, avoid putting padding-left:20p; on the #header - instead use margin-left:20px; on #menubar.

   The reason being is that Firefox will often add the padding value to the width. So even if the #header is set to width:800px;, with the padding it will stretch to 820 px. But if you use a margin on the #menubar, it will not do that. Also a great alternative is to use position:relative;, and then put left:20px; on #menubar.

2. Remember that on IE6, the > constructor in CSS does not work. I see a lot of people using it (even the default Wordpress theme had it) but if often does not work. Maybe it might work under different CSS mode settings (transitional, strict etc) but to avoid trouble, you may as well avoid it. When you want to designate style to all the A tags within the #menubar DIV, do this :

   #menubar a {color:#cccccc;}

   instead of

   #menubar>a {color:#cccccc;}

3. And the Vancouver Canucks JUST won the hockey game against the Dallas Stars, in Overtime, thanks to a 1-timer shot by Taylor Pyatt, who, by the way, is my favorite person tonight. And I lost my train of thought so you guys only get the above 2 pointers.. I’ll add more when I can think of some! Good night!

Right now, as you can see in the other sections of my website, I’m re-designing everything on my site. It will be a much cooler site that is easier for me to update later. I will reveal and explain the CSS code and what not later as a tutorial.

This new website incorporates a lot of CSS tricks I learned through Wordpress, and will be a hell of a lot better than the last design which took me very short time.

” . . . if it works on FF, the chances of it working well on IE7 is very high. It’s a math’s game - it’s my method to reduce the amount of failed products.”

I reverted back to Internet Explorer 6 today after upgrading to 7 for a while. If I weren’t a web developer I wouldn’t have done this, but I am. And I need to make sure my projects will work in FF, IE6 and IE7. And here’s what I felt and found over the last few weeks of living with IE7.

If my stuff works well on FF, it generally works well in IE7. IE7 offers full PNG support, they corrected the faulty box/padding/margin module problems since the IE6 days, so overall, the failure rate on IE7 is less than 5% I’d say. There are some differences in the way it handles Javascript and what not (for example, when parsing through XML, textContent is the Mozilla standard, while text is the Microsoft standard, so that was a bit tricky.. especially when the nodeValues doesn’t work for some mysterious reason…), but that’s manageable.

But what I did find is that, the failure rate on IE6 after testing properly on FF, was around 30%. This is just a gut estimate so don’t try to quote me on these figures, but I’d rather make sure it works on FF and IE6, because if it works on FF, the chances of it working well on IE7 is very high. It’s a math’s game - it’s my method to reduce the amount of failed products.

I still haven’t figured out how to run both IE6 and IE7 without having to hack through the registry or run some sketchy script, so I’m not going to go there yet. I am debating, however, getting a cheap cheap computer from my dad (he has them lying around) so I can run IE 6 on that one as the testing unit and a storage unit perhaps.

And of course, today I realized that I still have the sidebar of my blog showing up way down below on IE6 (no wonder my ad click rates were so low) and I fixed it once and for all. Last time I was trying to fix it for a few days, I think I got distracted somehow and then installed IE7 so it slipped away from me.