Archive for October, 2007

The lack of luggage

Sunday, October 28th, 2007

I had a feeling things would not be OK, when I had to check myself in. The machine gave me three leaves of paper, which did not resemble a boarding pass at all. Then I presented my luggage to a not-so-nice-lady at the counter. I showed her the sheets, and she never mentioned they would not do. But it got me through security. So everything appeared to be ok. Until I arrived at the boarding point, and I clogged the line because I could not board using the semi-boarding pass I was issued. No really. I showed the guy the itenary ticket I had received the week before when leaving Brussels. After some debate, it seemed I would be allowed to board.

I still have no idea where I should have obtained a real boarding pass. I encountered no other counters where I could have received something. My ticket was checked three four times: once when checking in my luggage, when entering the security checkpoint, when leaving it and when entering the section leading to the gate where I needed to board. So why nobody told me I could not board using it – and why they issue it in the first place – I remain clueless.

Same story at Frankfurt. Apparently, there is no money associated with such a boarding pass, and the lady flat out refused to let me board. I showed her my itenary ticket, which seemed to soothe her some. In the end, she wrote down my reservation number, and said she’d get her money that way.

Final smack was dealt in Brussels Airport. After waiting until the luggage line stopped, I lined up with some other people who were going to complain. When it finally was my turn, the lady was flabbergasted at the luggage coupon I showed her. I needed a tag from the label that was attached to my bag. Duh. No, sorry, can’t give you that, I only have this piece of paper. After some fiddling, she located some clues, and found out my bag was still waiting in Montreal. Now, I hope she was right, and my bag is not kind of lost. After all, it’s filled to the brim with presents for my kids and for Veerle.

Bottom line, I should have refused when Lufthansa changed my return itenary from the LH flight leaving at 17:10 to the one operated by Air Canada leaving at 19:40.

Update: I have received my luggage on Monday evening, when a friendly French-speaking guy rang my bell and required me to sign off on the bag he dropped on my porch.

Kathy Sierra on creating passionate users

Thursday, October 25th, 2007

One of the keynote speakers at this years OOPSLA was the normal-from-afar-but-impressive-from-closeup-especially-when-speaking Kathy Sierra. She talked to us about how to create a host of passionate users. I’ll try and give an impression of the key points she touched upon.

First of all, it is important to recognize, people still want to meet in person, despite all the technological advances made during the last years that really means we can talk to one another without leaving our home, or the comfort of our couch. So to create a bunch of passionate users, you should build on this desire and get them together, where they can talk, discuss, learn and teach. A good example she gave was that of a barcamp. Basically, the roadmap to instilling passion in your users is discovering the characteristics these people have in common.

Essentially, where there is passion, there is a user kicking ass. So, you want people to get good at things, because if you suck at something, there is no way you will be passionate about it. Counterexample 1: I still suck at Haskell, but I’m quite passionate about it. Counterexample 2: the same goes for me and Drupal. But that may just be me. Most likely it is. On the other hand, there are people encouraging me to be passionate about this. With this observation, she encouraged the audience to give users a hi-res experience, such that they could understand that if they passed the suckiness threshold, they could really rock. This means showing things to people as you see them, and transferring your passion. For example, a mountain climber will certainly look differently at a rock wall than Joe average, e.g., me.

The main issue is that often people are encouraged to be passionate about a tool, rather than at what the tool can help them accomplish. Nice example is the camera. What you want to do is to make kick-ass pictures. So get people to be better at using the tool, helps them reach this goal. But don’t mention this, just show them the cool stuff they can do, without emphasising the tool itself.

Kathy claimed that the first roadblock to get things rolling is the brain of the users. People operate at a subconsious level, not at a logical level, despite the fact that – so she said – many men like to believe otherwise. Furthermore, brain have built-in crap filters, meaning it’s important to get the things you want users to retain pass those filters. The mind however operates at a higher level, but people are rarely actually guided by their mind. For example, when they really want something, they will seek arguments why they should be allowed to get what they want, rather than listening to their (correct) mind that tries to tell them not to for some good reason (e.g., no money). Her reasoning was that the brain cares about either life-sustaining of life-threatening things, about joy, sadness, anger, love, scary things, new things, intruiging things, etc. However, the brain cares not one whit about code. The brain also cares about faces, so it is more desirable to people to talk in person to somebody, instead of having them interact with a machine. The bottom line is that use have to use every trick at your disposal to capture the attention of the user. For example, conversational language captures people attention better than formal language. I guess that’s one to keep in mind for my PhD dissertation.

Well, everybody think he’s above average, even when it is not true. So the path to succes is constructed by dangling the carrot in front of the users: allow them to have the idea how cool they will be when they grow above the sucking threshold. So, users need a clear path to get to the good stuff, see a compelling picture down the end of the road, and a relatively easy first step onto the path. So, users must not be dumbed down. Additionally, the path must be open ended. Every time there must be a step users can take to keep increasing their competence.

Because all computer applications are somehow agnostic at some level to what users think, it is important that users can knock on the door when they get confused. Kathy called this adding a WTF? button to an application. One of the problem is that users guides and FAQs are written for happy people, not for somebody about to smack the hardware (after all, hardware is the part you kick). So FAQs are written for users on the other side of the canyon of pain.

I really like her metaphores.

Getting users on the path to world domination is but the first step, you also have to keep them going. The best way to do this is to get them in the flow state, which is the state where people just need to do this one extra thing, one more compile, and it will work, etc. They are not aware of time passing, and face it, you probably also accomplished most when you’re there. There seems to be a precarious balance between knowledge, skill and challenge. To avoid slamming users back to reality, you should make the good things easy, and the wrong things hard to do.

I think that she illustrated her point quite good by using the game example. In a good game, there is a payoff when a player attains certain experience, e.g., a faster car, better weaponry, etc., but there are also tougher challanges to be faced to get even further.

She made me grin when she asked how we feel about users. RTFM? That’s usually how I think most of the time, after having things explained time and again. But obviously it is the wrong approach, and deep down, we all know it. This is why some online communities are much more succesful than others. Those that don’t bark nor bite but care about newbies can get them up to speed easiest and create a following that will (hopefully) repond the same way later on when they passed the suck threshold. I think a good example of this is #haskell on irc.freenode.net, where people have always been helpful for as long as I’ve known. This is one of the key issues Kathy touched upon: get the community to help out. People should be encouraged to answer politely, and answer instead of just asking questions. Even when something is answered wrongl, the community can pitch in and correct things. And because newbies recall their pain best, it is important they actively contribute.

Moreover, when a community can be converted into a tribe, passion may be ignited sooner. A tribe has special little things only the members are in on, and they notice each other. Tribe members id themselves with a special thing, and they’re proud to be part of it. Provide people with the means to show they are part of the tribe, e.g., bumper stickers, t-shirts etc. I guess I should be taking my Drupal t-shirt out to the dry-cleaner so I dare wear it again. As Kathy nicely puts it: insider information is trading currency, so give your users something to talk about. Apple users should know what she means, given the huge number of rumour sites.

Finally, appreciate the intelligence of your users. A crowd can reach concensus, but that’s probably not what you’re interested in. Individuals can contribute better if they get the chance. So make them think they rule individually.

I really liked her talk, it was well paced, and had very well thought-out illustrations on the slides. She gave quite a lot of things to talk and think about. Which I what I intend to do.

Statistically Rigorous Java Performance Evaluation: presentation

Tuesday, October 23rd, 2007

If you are interested in the presentation I gave at OOPSLA, you can get a Keynote exported pdf.

Montreal Hyatt WiFi

Monday, October 22nd, 2007

To put it briefly: it sucks. We have little or no connection in our room, even when using a hotel provided WiFi connection device. We can get access in the hotel lobby, but uploading anything larger than a few KB does not work. Opening a secure shell to a machine outside the hotel, e.g., at work, is not possible. Thus, SVN access is simply fubar, as is pushing patches to a darcs repository. Uploading to flickr … no way. Not even through the HTTP interface.

And to think the hotel is hosting a few hundred geeks attending OOPSLA.

A tutorial on user-interface design

Monday, October 22nd, 2007

I attended the ‘From use to user interface’ tutorial at OOPSLA, which was presented by Jeff Patton. The approach outlined was the following. First, start by writing a scenario, with a specific user (and his associated persona) in mind. Go down to the nitty gritty details (fish and clam-level), as well as the broad scope (sea-level and above). In reality, you might have to create a few dozen scenario’s to cover the entire use-space for your particular problem.

From the scenario, identify user interface elements that help the user execute the tasks required to reach his goal. For this, Jeff advocated using post-it notes, as they can be reordered on a board, and teared up when wrong.

Given the post-it notes create paper UI building blocks, such as labels, input fields, buttons, tables, etc. these should be sticked onto paper sheets, which represent the screens a user sees as he proceeds through his stack of tasks.

Final phase is the testing. Get a person to play the computer, a person to explain the scenario, and a few people choosing to pick the UI-elements. Finally, somebody should observe and jot down everything the testers have trouble with.

The next step is to repeat the above phases as much as needed until you are confident the user interface you designed meets its requirements.

In all, I think this can be a good approach, especially when a complicated user interface needs to be designed. However, I’m still partial to the paper cutting and sticking the components onto paper. It seems to me that this might be a little time-consuming. This is especially true when you need a lot of screens, and the problem you’re dealing with is fairly complex. Basically, I think an electronical counterpart to the paper based cut-and-stick idea might work faster. Additionally, it seems as if the proposed approach is very hungry on people resources, so it might cost quite a lot to have a user interface designed in this way. And the testing phase seems to be quite awkward. But I’m no expert whatsoever. And a well-designed interface can of course rapidly earn its development price back because it can appeal to people, causing them to buy/use your application.

Belgian Food

Sunday, October 21st, 2007

Last night, Dries, Webchick and I went out to grab some food. Travelling with somebody (read: Dries), who knows people all over the place (thank you, drupal), has its obvious advantages.

We ended up at a place where they serve semi-Belgian food. I chose a croque-monsieur, which was adapted to North-American standars, as they dropped the tomatoes and the salad inside the bread leaves, bu otherwise it was excellent. Kind of weird, they served it with fries, and they were superb! And they sell Duvel – which I did not have, but now I know at least of one place here where good beer is to be had.

And, Angie … thanks for dinner :-)

Travelling to Montreal

Sunday, October 21st, 2007

The flight was very uneventful. Luckily. Unlike the last flight I took with British Airways, Lufthansa managed to get us flying on schedule. The food on board was quite good, actually. I took the chicken, which seemed to have been killed prematurely, because apparently, there was very little meat available. The only drawback was the lack of sufficient drinks. Refusing one kind of juice results in the stewardess passing us by on the second round, rather than offering us water.

From the air, Montreal looks spectacular. There are trees lined up on each sidewalk, wich gives a superb effect as the leaves are coloured in various shades of green, yellow and brown.

Spinning lesson two and beyond

Wednesday, October 17th, 2007

No, I did not quit (yet).

I got tortured twice more this week. On Monday, I took an easy session. I managed to do everything at a pretty high resistance setting. The last race was too much though. My brain seems to want to think too much, and there’s no other way but increasing the resistance to slow down fast. So, once I started thinking, my feet stopped rotating at the high speed they had attained and I was on for a momentarily bumpy ride, until I raised gears. The key problem is that you cannot hold your feet still while the wheel keeps spinning, as you can on a normal bike. But heck, I was glad I managed to put in the required effort.

The session on Tuesday was far harder. I could not get my wheels to spin round with gears set to 4 (there are 8 settings, 1 is easiest), unless I pushed really hard. So there was no way to make speed beyond gear 3. Afterward, I asked the tutor to take a peek, and he told me somebody had messed with it. Sucks, but by then it was too late. I was also told to keep my heels down (I had no idea biking resembled horseback riding), especially when going fast, otherwise the leg muscles tend to tensen up and start to hurt.

This morning when I rode Elias to school, I really felt like I had excercised, which, I think is a good thing. Seemingly, spinning helps to build up condition quickly, so if I can make it past the initial few months of training … I’ll be fine. The good news is that my scale is showing about 1.2 kg less (on average) than before I started. Less candy helps too :-)

Adding Rigorous Statistics to the Java Benchmarker's Toolbox

Tuesday, October 16th, 2007

You can find the pdf of the poster I will be presenting together with Dries at OOPSLA this year. If all went well, there should be a two-page poster abstract printed in the OOPSLA Companion (preprint). So feel free to drop by on Monday evening and have a chat.

The abstract to this abstract reads as follows.

Java performance is far from trivial to benchmark because it is affected by various factors such as the Java application, its input, the virtual machine, the garbage collector, the heap size, etc. In addition, non-determinism due to Just-in-Time compilation/optimization, thread scheduling, etc., causes the execution time of a Java program to differ from run to run.

This poster advocates statistically rigorous data analysis when reporting Java performance. We advise to model non-determinism by computing confidence intervals. In addition, we show that prevalent data analysis approaches may lead to misleading or even incorrect conclusions. Although we focus on Java performance, the techniques can be readily applied to any managed runtime system.

Year Zero

Friday, October 12th, 2007

It has been three weeks, I think, since I bought Nine Inch Nails latest album, Year Zero. I steadily grew to like it more and more, and it has not been off my iPod playlist the last week. If not Trent’s best album to date, it certainly is a good match for The Downward Spiral.

I hope that Y34RZ3R0R3M1X3D is able to match it even halfway.