Recently I was asked to put a webpage online which contained some navigation and some content. There was more content than could fit the browser on an average screen. So the content looked basically like this:

But then I was sent a new version which was cleverer,

• The content was stored in an iframe
• There was Javascript which dynamically altered the size of the iframe to be the size of the monitor resolution (i.e. independent of current browser size)

The result of this complexity was that the iframe nearly—but not quite—fitted into the browser’s content area (assuming you had your browser maximised).

Because the iframe didn’t sit quite at the top of the window, this meant:

• The bottom “scroll down” arrow button of the inner iframe (the one you need to actually see more content) was, by default, off the bottom of the screen
• As there was content beyond the bottom of the screen (the “scroll down” button of the iframe) the main browser window also displayed a scroll bar
• To scroll to see more data, you need the inner iframe. But instinctively one reaches for the right-most scrollbar, as that’s normally what you need to see more data, e.g. in a browser, Word document, etc.
• It only got worse if you don’t use the browser maximised.

I mean I don’t know what aspect of “the browser will display a scroll bar if there’s more data than will fit in the window, without needing Javascript and iframes” they didn’t understand.

I suppose the navigation will always be shown, but I think people are used to navigation scrolling with the content these days. And if the objective was to keep the navigation on the screen, one could have used a normal frame, which would have required no Javascript, and still resulted in only one scrollbar, in the place where the user expects it.

Really the whole “scrollbar within a scrollbar” concept (which unfortunately is pretty much mandatory if you have a text area within a webpage) is really so nasty.

I was reading this article about how certain data gets messed up when one imports it into Excel (certain data looks like a date and thus gets converted into one), and it reminded me of a problem I had when transferring data over an XML protocol from Perl (the SOAP library was inspecting the hex data I was transferring, but a small percentage of hex numbers look like “123e123″, which looked like a floating point number to the library)

I think both problems are actually the same problem. It can be traced back to the necessity to make exactly one of the following two decisions when creating data-processing systems:

1. Either you try and work out what the datatype of a piece of data is by looking at e.g. the data’s string representation. E.g. this data is “abcd” so it’s a string, this data is “123″ so it’s a number.
2. Or you explicitly store and state, external to the data, its data type. E.g. store not only that the data is “123″, but that it’s a number.

Option 1 seems attractive as it’s simpler as you only need to store one piece of data. It also feels more normalized, as one piece of data is generally better than two (e.g. what if they are inconsistent, e.g. data is “abcjzh” and type is “number”?)

But the trouble is you option 1 doesn’t work (see above.)

But it gets worse. Option 1 seems to work, yet does not actually work in all case (and you want your software to work in all cases). That’s more dangerous that if it simply and clearly didn’t work.

The authors of the SOAP library in my example presumably believed their software worked. And I believed my software, built on top of the SOAP library, worked. It worked in my unit tests and when I tested it by clicking-through the front-end. Only 0.6% of users had a code with a hex string that looked like an exponent, so it’s understandable that I just didn’t hit it when testing. But with e.g. 2M users in the database, some of my users will hit it. And that means that the software I released didn’t work (working meaning working 100% for everyone.)

But I like my software to work. The way I achieve that is to avoid errors which are difficult to detect. Making errors is human; if they are easy to catch, one can spot them and then correct them.

On Monday we went over to Hong Kong to make the application for the Fiancee Visa, for Christina to enter the UK to get married. She is allowed to enter the UK anyway for tourism, but to get married the visa is required. The visa lasts 6 months, does not entitle Christina to work in the UK, and after marriage the next visa (Spouse Visa) has to be applied for (although we will do this for Austria instead of the UK).

I had prepared lots of documents for the application process; however by the time we went over there this set of documents had grown to at least twice or three-times this amount.

Ironically there was some repeating-DVD on the TV screens in the waiting room, where some applicant actress says “wow, I didn’t know it would be that fast and easy!”. I thought this was extremely ironic.

But in fact, contrary to our expectations, it was indeed both fast and easy (not including preparation of the documents). They called us 45 minutes after we left the building to tell us Christina’s passport containing the visa could be picked up.

We had prepared all the documents with the originals and copies collated (as they said they needed to take both away, and would give us the copies back). I had thus prepared a large spreadsheet listing all the documents that I wanted back (e.g. original bank statements). I thought merely sorting all this stuff out to give back to us would take half a day! But when we got the documents back they were all collated just as we’d given them to them, i.e. they hadn’t even taken the copies out. I suppose they didn’t look at the documents that much, or even at all?

The only things they took out were the copy of the passports (incl. stamps of our entry/exit to/from Macau/Europe) and my covering letter explaining my financial and employment situation, our plan to live with my parents initially when in the UK etc.

So maybe we could have spared most of the effort of the preparation of the documents? (Or maybe not, maybe a precondition of granting the visa was a certain mandatory documentary weight?)

Anyway, it’s good news. We have to make an application in the UK to “give notice”. But I’ve had chats with the office that do that, they imply it’s easy, and that the Fiancée Visa is the difficult one. So let’s hope that’s true.