Tuesday, August 30, 2005

Loading Google Map's page with many markers slow in Explorer

As anybody that has visited Panoramio will say to you,
it may take an awful long time to load markers on a Google Maps page.

I didn't know what was going on. I mean, Firefox was much much faster on this page than Internet Explorer, on the same connection, same computer. Why?

A very long thread over this issue was running on the Google Maps API discussion group without any clear work-around or explanation. So I took the plunge.

I fired Fiddler, a wonderful little application done by Eric Lawrence, one Program Managers of Microsoft Internet Explorer 7. Fiddler spies the WinINET calls, and logs all the HTTP requests and responses done and received by your computer using the WinINET library.

The reason Internet Explorer was so much slower than Firefox was obvious, Internet Explorer was querying the browser for the marker image, but it was doing it once for each marker! That means the server was sending out the same image over and over again.

It turns out Explorer may cache the image, but it needs a bit of time to cache it. If you just ask for 500 markers directly, it will try to download 500 times the five images that compose a marker.

Depending on your IE options, and on the headers your server sends along with your images, you may find this bug only the first time you open the page, and then it may vanish, or not, or appear again when the cache expires, to vanish again after that, or remain there (again, in function of your exact headers).

So if you have to read multiple markers in google maps, before doing so make sure Internet Explorer has put the needed images in the cache:

<script type="text/javascript">function onLoad() { ... your code here ... }</script>
<body onload="setTimeout(onLoad, 100)">
<img href="http://www.google.com/mapfiles/marker.png" style="display:none">

<img href="http://www.google.com/mapfiles/shadow50.png" style="display:none">

<img href="http://www.google.com/mapfiles/markerTransparent.png" style="display:none">

<img href="http://www.google.com/mapfiles/markerie.gif" style="display:none">

<img href="http://www.google.com/mapfiles/dithshadow.gif" style="display:none">

Friday, August 26, 2005

First Mac Mini experience

Last week-end I bought a Mac Mini because

1. I wanted to test Panoramio on Safari
2. I want to start developping any new application also for Mac
3. It looks cute as hell!

So far the experience has been great. Most things just work, and the whole interface is very slick.

There vere however several dark spots.

First, I took the old version of Mac Mini, preloaded with MacOS X 10.3 (aka Panther). A few months ago Apple released MacOS X 10.4 (aka Tiger). If you want to upgrade you have to pay 129€. No discount for previous users.

I doubt that Microsoft will make you pay an upgrade of this size. MacOS X 10.4 have some nice improvements, but it looks like a big Service Pack to me. But that's debatable. Spotlight and the new 3D infrastructure certainly look like quite major changes.

The thing that let me puzzled is that some software already *required* MacOS X 10.4!

Point in case, I can't use Java 1.5 because it's only available for Tiger. As I understand it, they made some changes and Java now needs to use the new 3D stuff available only in Tiger, but com'on! was there really no way to port Java 1.5 to Panther? There is a lot of interesting things in "Java the language" that are new in Java 1.5, and they are completely unrelated to the base system.

Same problem with Dashboard or the new Safari. I'm sure it would be *hard* to port these things to Panther, and I can hardly remember a Microsoft product that obsoleted a previous Microsoft OS, except those that were truly *old*.

Remember that I just unpacked a shinny new computer, and its OS is already not supported! We are not speaking of a ten years compatibility here, just compatibility with products that are still selling!

I returned the MacMini and will bought instead the new MacMini that is already announced in Apple. It seems they will receive the first boxes next week.

The good news are that Panoramio was working well with Safari 1.2 (the Panther one), except for pictures not disappearing when the marker on the map disappears.

I quickly tested Panoramio with Safari 1.3 on an exposed Power Mac in the store, and the bad news is that it was not working so well. The first problem is that the default latitude and longitude was "NaN" and "NaN", instead of the position of Madrid. It seems to be a problem with my getCookie function. I worked around this problem hand crafting an url to center the map at Madrid, and things worked like in Safari 1.2, except that I managed to crash Safari. (So far, I've managed to crash Internet Explorer and Safari.)

I will keep you posted when I'll get my hands on a new Mac Mini and fix these Panoramio problems.

Friday, August 19, 2005

Why Panoramio is not XHTML/CSS valid?

In my previous post Fade in and out I said that I didn't care about Panoramio not being xhtml/css valid.

If that sounds weird, it's just because people have forgotten the real goal of validating a site. Validation is a mean, not an end.

The goal is to have a site as cross browser as possible, so that any potential user is able to enjoy it. Validation is a tool to use towards this goal, but it is not the only tool, and not even the most useful one.

Even if people where using fully compliant browsers to see your site (and we all know they are not), there are an awful lot of things that are just not in the specification and can ruin the look of a perfectly valid page. For instance, the standard is silent about the default margin, color and font that a browser should use for any element. There are very good reasons to not specify such things. Font names are not the same between different systems, for instance. But the point is that if you don't really test your page against different browsers, no matter how much does your page validate, it may still look awful for a lot of your visitors.

You can also experience the reverse. You can have a non valid page that is perfectly usable on a 100% standard browser. And I don't mean that “almost everything will work”, I really mean perfectly usable! The XHTML / CSS standards says how a XHTML / CSS document should look, and it also says how a compliant browser should behave in the presence of certain invalid documents. For instance, unknown attributes should be ignored.

It is thus perfectly legal to invent new attributes, and give them a particular meaning with javascript (just remember that your user may not have javascript activated). Any compliant browser will render your page without a glitch. The only downside is that your page will not be anymore XHTML valid. But if you concern is to have webpages that can be read and used with any browser, you will not have a single problem with this strategy.

This trick is used in our login and register forms in Panoramio, to explicit what test should be run by the client on each field before the form is submitted. E-mails should be real e-mails, some fields are mandatory, that kind of thing. The result is much cleaner than adding these tests ad-hoc in javascript. (Note that this framework is not yet finished, and thus the javascript code still does some tests in an ad-hocist manner.)

Thursday, August 18, 2005

Turquino trail in Cuba

It wasn't that easy, it was difficult to remember the right places after two years, but at the end I could submit the pics of Turquino trail, the highest peak in Cuba.

It takes you two days to walk 41 km up and down, a real rompepiernas trail. Sad it's forbidden to take photos in La Comandancia de la Plata, the main basecamp of the Cuban revolution that is included in the route. By the way, right at the top, there is absolutely no view, too many trees. Anyway you can enjoy wonderful views along the whole trail.

Differences between Mozilla and Internet Explorer

Some time ago I read an article pointing out how to migrate apps from Internet Explorer to Mozilla. The articule is well written and worth a read, but it falls short on explaining all the real problems you can find when making a webapplication that works on both browsers (let alone something that works on Opera, Safari and Konqueror).

So I decided to blog about some of the inconsistencies that I've run into.

For this first post, one of my favorites, innerHTML support depends on your browser.

innerHTML is not part of any blessed W3C standard, it was introduced a long time ago in Internet Explorer. It's so damn useful and so handy compared to using the DOM interfaces that this property was replicated by other browsers.

There is however a difference that you must be aware of, in Internet Explorer you can not change innerHTML on objects of type COL, COLGROUP, FRAMESET, HTML, STYLE, TABLE, TBODY, TFOOT, THEAD, TITLE or TR. You can do it in Firefox.

If you develop a site looking first how it works on Firefox and fixing it later in explorer, you may fall on this trap, thinking that everything is working ok, just to see that it's not working at all when you check it later in explorer.

If you want to support several browsers, better do it from the front up, or there may be some design decisions that may be hard to overcome when you discover that this or that trick doesn't work on one of your browsers.

Tuesday, August 16, 2005

Still very much work to be done

There is still very much work to be done in Panoramio; many bugs, usability problems and lack of features. The to-do list is very long. We are fixing them, but if you have any comment, suggestion, complaint or idea, just leave a comment here or at the forum. We would be happy to hear from you.

Fade in and out

Playing with the effects in script.aculo.us I added a new little effect to switch from an element to another one smoothly.

Better see it in action, go to Panoramio, register as a new user, and see the little fade out of “Login     Register” and the fade in of “Hi Foo Bar”.

Sure enough, it was not working on IE. It's a documented problem, the Opacity effect didn't work on elements without layout. The “layout” is some kind of karma that IE throws on certain elements, and you can activate it manually if you use the right CSS incantation.

So here we go, I apply height: 1px; to my two spans to no joy, it still didn't work. Let's try zoom: 1... on the money! zoom is not a valid css property, but my page didn't validate anyway (and no, I don't care) so I'm sell on zoom.

But now I have another problem. If you have cleartype activated the result is ugly beyond belief. Pssst. Well, nobody said that's going to be easy.

Another google search, and we see this lovely blogger giving us a work-around. Just put an explicit background color to this element. Luckly enough I'm using an uniform background for this part of the site, so I just added a background-color: white; and now I have something that works like a charm at the very least on IE6 and on Firefox.

I can now take my breakfast.