End of December is a time when I usually try to take stock of year behind and create semi-plausible goals for upcoming year. I didn’t used to do this until some day, a few years ago, I noticed that my twenties were gone. Since then it has become a habit that has served me well.

My biggest achievement this year is successfully suing myself. If this sounds ridiculous, it’s because it is. It would take too long to explain why I came to do this, but it goes to show how far you sometimes have to go to please some bureaucrat.

I worked a lot, to the point of postponing all my last years plans and didn’t get much in return. I honestly can’t say I learned a lot and I achieved even less of what I’m proud of. This year has simply been a professional disappointment that I have no intention of repeating again.

Of course I didn’t just wake up and discover my failures and failings. They’ve been apparent to me for a while and I spent a large part of last few months thinking about what interests me and what I want, can and will try to do. I tried to form my personal research agenda , but failing to get specific enough I have decided to spend next year learning about and exploring my areas of interest and see what I can come up with.

Creating content, while popular, still feels awkward and limited. As a LEGO fan since childhood I want to see if I can come up with a set of metaphors and building blocks that yield great power of expression. The point isn’t a tool for a perfect expression of an idea as much as it is an adequate expression of most ideas. Polishing can and should come later.

I got Beautiful Evidence by Edward Tufte a few days ago and it’s an astonishing book covering another topic I feel needs more (of my) attention. When we manage to create something, we often fail to present our ideas properly. Partly it’s our fault since we can’t help ourselves not to rely on forms and traditions that came before web. It’s also our tools fault. When all you have is a blog, everything has to be squeezed onto a timeline.

We’re over-focusing on primary creations. As a reader I’m usually quite limited in what I can do with a piece. These days I can make a vague statement with voting or less vague one with a comment. I may also forward a find, but that’s about it. My actions are by and large limited to statements about a piece instead of interacting directly with it.

I’m sure none of above mentioned problems is new or unexplored. Smart people out there have certainly done wonderful stuff I haven’t heard of yet. Any pointers are always welcome. So next year I’ll work less, learn more (about it) and spend time playing with ideas that might appear. Hopefully I’ll have something to show in year’s time. Who knows, with a bit of luck I might even have something useful.

But before I leave, let me wish everyone merry holidays and a happy new year.

I’ve been curious about interface possibilities and limitations of non-desktop environments like my Nokia tablet for a while, especially as they pertain to web. Pen on a touchscreen obviously doesn’t have to leave a “trail” of traversal like a mouse does. You also don’t have several mouse buttons at your disposal.

So I made a simple test page to see how some of more interesting events get caught.

The result on my 770 was quite disappointing while also expected. I’ll summarize it for those who don’t have a tablet. Touching a screen generates mousemove event and sometimes mouseover , but you never get a mouseout event. If touched briefly enough, it’ll also generate mousedown , mouseup and click event in this order.

You won’t get a mousedown and mouseup events until click . If you keep pressing the screen without moving, you’ll get a context menu, but I found no way to get to mousedown on its own. This means it’s impossible to create a “natural” drag and drop, which isn’t surprising, since same movement is already taken by browser for scrolling.

My test was limited to Nokia 770 tablet, but I doubt results would be much different elsewhere (Fry, can you check your tablet?). It would also be interesting to see what iPhone does, but since I don’t have it either, I can’t tell.

Still I’ll need to rethink a widget for website I’m working on and keep this in mind for my next year project.

It’s not a secret that Javascript is interpreted and not statically compiled. Personally I find this an advantage that is not used often enough. If you look around the Web you can find plenty of cases to prove this, but I’d like to add another example.

A few months ago I was developing a library which had a goal of providing an improved Javascript experience for standardized components without requiring any knowledge of the language to use. I also wanted to support different load scenarios so library could be smaller when needed.

Sadly I ran out of time before I ended my work to my satisfaction. Still, I’d like to discuss one approach that also demonstrates aspects that I’d like to see used more in the wild.

Let’s start with a demo. I created two almost identical pages. Can you spot the difference between first and second ?

First one simply toggles visibility of the text, while second one does the same with a bit more style. If you look at files, you’ll notice that the only difference is that first calls switch.js and second uses rswitch.js . Both files look the same because they are. In fact, it’s really just one file. Hard link to the rescue for us, Unixheads.

But first a small warning. This code is not production ready. I simplified it to keep example clear and concise. In that capacity I think it will do.

Javascript basically consists of two functions. A window.onload handler that’s triggered when page is loaded and an animation function attached to button. A window.onload handler is a one trick pony. Its main idea is to find Javascript file in DOM and based on the name with which it was loaded set up the execution environment. This is just a fancy name (to make me look smart) for setting a global variable that is private to this name space and possibly loading a few additional resources, like YUI animation support in our case. It is also the first case where not being static helps. We can decide at run time what’s necessary and load only what we need.

However, I find toggleVisible a tad bit more interesting and the reason is its if statement. What happens when we include switch.js in a page?

Well, variable rich remains set to false and YUI components don’t get loaded. This means YAHOO.util and its descendants aren’t defined. Yet as we’ve seen from first demo page script works just fine. Reason for this is that if statement in toggleVisible evaluates to false and those undefined statements never get reached. This wouldn’t work in a language like Java, which would notice a call to undefined methods at compile time and refuse to finish compile, but it works perfectly fine in Javascript.

Of course if rich was set true, then we load YUI files. It might happen with this code that we press button before they get loaded, which is one of the reasons why this isn’t a production quality code, but if we assume for a moment that they did, then those same lines in toggleVisible are perfectly fine and it works as hopefully seen on second page.

We therefore have a page where we control its behavior and size only by the way we call javascript file. There’s literally only one letter of difference. With dynamic loading of resources and cordoning potentially nonexistent methods we could fairly easily create a spectrum of possibilities where our users could choose their own compromise between functionality and its price in terms of page size and speed or better handle differences between mobile and desktop browsers.