We tend to move around a little at the office mainly to achieve what is summarized in the popular buzz word knowledge sharing. A few weeks ago my turn was up and I was asked if I wanted to transfer to another team working on our future frontend interface, centralized around the Journal. The main objective is speed, performance and usability experience. And the Journal input experience will be very similar to what you see in most spreadsheet applications. This was too exciting, as a backend developer I had to give it a go and this is now my primary concern for the time to come.

The obstacle

One of the huge differences between web applications and conventional desktop applications, is the transfer of information from the underlying servers to the application, e.g. Information presented to the user on a webpage can only happen if the user asked for it, such as entering the address of the webpage or clicking a button. In other words what you see is a static presentation of the webpage with no real physical contact to the web server.

I’m sure most of you by now would burst out: Isn’t that’s obvious?!? And I couldn’t agree more from your point of view. But consider the fact that any computer operating system, such as Windows Vista, XP or Linux, executes applications in its own environment leaving the operating system in more or less complete control of the application; on a webpage it’s the other way around. The web browser creates its own environment from where you can interact with its presentation of the webpage and not really considering anything else.

To overcome this obstacle you give the webpage some functionality by attaching scripts that can be executed by the browser on user interaction, that way you let the browser handle most of the work and the server handles incoming calls only. But how do you execute these scripts and why even bother, the webpage is right there? Let me explain this with an issue we are still working on and has surfaced on most of our status meetings lately.

In most spreadsheet applications a user can at any given point in time hit keydown on the keyboard and the cursor moves to the next row. Initially a browser has a lot of functionality implemented in its own environment, such as hitting F5 on most browsers will refresh the webpage or pressing Ctrl+T creates a new tab; all these functions are there to make sure it’s a smooth ride while you roam the internet.

As you have properly realized by now this means that half the keys you press down on your keyboard has a good chance of being in use by the browser, which brings me back to the keydown problem. It’s already assigned to move the page down, present a list of inputs from earlier or just move about inside a textbox. We have to catch this keydown press and make sure the browser ignores the it.

Fortunately this is something you solve by creating even more scripts.