'To use this product, just move to the USA'

We are always hearing of the Internet bringing with it a global culture where national boundaries are becoming less significant. However there are still companies out on the web who preport to be international and yet are still discriminating against non-American users. One of the most blatant cases of this that Mark came across recently was AOL and CompuServe. Mark was in Bermuda at the Orbis World Bridge Championships, doing his usual once a year setting up and maintaining the computer network and Internet connections for the event. The internal network was connected via a 128K frame relay circuit. One of the secretaries there who was not on the network wanted to set her computer up to use AOL as she is often in different countries and this seemed a good choice of ISP to use. After the install, the software asks you to sign up. It asked which country you are calling from and as Bermuda was not there we chose America as the country code is the same. The free phone number that AOL provide would not allow us to connect from Bermuda. So undaunted and only muttering a little, we used the local ISP Northrock to connect to the internet and then tried to carry on the sign up procedure from there. So far so good. This then presented you with a form to fill in your details, which insists on a state code, which as the lady in question lived in France, she did not have. Nor did it like her French telephone number. We tried everything to get this form to change to something a little more European, even changing the regional settings on the computer to French. Nothing made any difference. Perhaps if it was a French version of the OS then all may have been OK, but there are a lot of people out there who use their laptop set to a different language to the country they are living in. We then tried CompuServe and this came up with very similar software with the same problems. How can these companies can market themselves as truly global when it seems that by their definition, global means USA AND Canada?

A few days later another example of this blinkered view of the world from our American cousins. This time it was Microsoft's Hotmail system. For those of you not familiar with this, it is a completely free email account which is accessible from a web browser. The system also allows you to pick up mail from any other POP3 mail account that you have. Such a system is very useful at a World Championships, where there are some forty computers available for anyone to pick up their email and to allow members of the world press to get their stories out. Using such a system saves the hassle of setting up email clients and roaming profiles so that anyone can sit at any machine and get their email rather that someone elses. To use this email system the user simply needs to fill in a form with his or her details on it. Everything worked fine until a gentleman from the Netherlands needed to sign up. His name was Lex De Groot, the form asked him what country he was from, and he fairly obviously replied 'The Netherlands', when he finally finished filling out the form and hit submit, an error page was displayed saying that 'Last Name contains reserved or ineligible word. Please select another'. Please select another! How many last names does anyone have! This is carrying form validation to ridiculous extremes, who is to say what is a valid last name? Perhaps this is a word of caution to any one about to decide on a name for their new baby, get it checked out by Microsoft to see if it is a 'valid' name. Otherwise the child may be excluded from all sorts of things later in life! How did we get round this problem, quite simply, we re-christened Lex De Groot as Lex De Sex and all was fine!

[graphic: hotmail.gif caption: "You do not have a Microsoft approved name"]

For the tournament, the main web server (www.bermudabowl.com) for the event was sitting on the end of a 40M line and the network of computers was connected via a 128K frame relay circuit to the internet. One day we lost Internet connectivity on the frame relay circuit. After a few quick checks, a frantic phone call was made to the ISP. Tom Coelho of North Rock (www.northrock.bm) was as helpful as ever, and whilst talking to him, we discovered that they could see our router but no machines on the network, and we could see the machines on the network and the router but nothing on the Internet. This was most puzzling and the usual technique of rebooting the router did not help. In the end rebooting one of the hubs on the network fixed the problem, quite how we are still not sure. No matter how much you think you understand networks they still are capable of the odd surprise or two.

 

You have been Framed !

Any of you that have tried designing a web site with frames that requires accurate sizing of the frames will no doubt have pulled your collective ponytails out (Mark has ! ) when viewing the site in Netscape, to say that the results are curious is about as polite as we can be. This was always an accepted problem and something that we lived with for years (ever since frames were 'invented' in Netscape 2 ). Now however some light has been shed on the problem by Paul Anderson who is technical editor for the excellent resource www.builder.com.

www.builder.com - an excellent resource for the web builder

In an article (http://www.builder.com/Authoring/Tagmania/120699/index.html) he describes how by looking at the public domain source code for Netscape, he was able to find out what was happening. First let us describe the problem in detail. If you set a frame to a specific pixel height or width it will not display the frames at these sizes, but at some close approximation to the pixel values you have defined in the HTML . What is in fact happening is that Netscape is storing all frame sizes as percentages even if they are defined in the HTML as pixels. These percentages are stored as integers (no decimal places) and so some precision is lost. To use the example that Paul Anderson gives:

Take the HTML <FRAMESET cols="250,*">

This should produce two frames, one 250 pixels wide and the other taking up the rest of the browser window.

If we take a browser maximized on an 800x600 screen, this will give us a maximum display width of 796 pixels because of the borders around the browser window. What Netscape does is to now covert the 250 pixels to a percentage { (250/796)*100 = 31.40703517588 } this is rounded down to 31 percent as it is taken as an integer. Now to display the frame in the browser window, Navigator takes this percentage value and works out the size of the frame { (31*796) / 100 = 246.76 } which comes out at 246 pixels and not the 250 pixels that you originally specified. The error will depend on the browser window size. The problem gets more confusing if you have borders on the frames, to quote if you have "borders remove another 2 pixels off each frame dimension, plus the border value--plus one, divided by two, and rounded down--per attached border. Got that? ". The only way to get around this problem is to open your browser window with JavaScript and fix the size of this window. Now you know what effect the errors will have on your design and you can make the necessary corrections. Just bear in mind that although the final size of your frame will be reduced by no more that one percent of the total screen size, this can still mean a difference of 10 pixels on a 1024 screen, enough to mess up most designs. The reason for this curious browser behavior, is simply that the original code from Navigator 2.0 has never changed since the idea of frames was first implemented. A bit like the millennium problem that we pointed out in Netscape last issue. It seems that this browser code needs serious study, lets hope their server side programs are maintained with a little more care.