Worst UI ever

For a life demo of user interface which fails so terribly that users are known to either swear or fall to their knees and weep silently I would like to invite everyone to AMC (formerly Loews) movie theatre on Boston Commons. This is a one beautiful movie theater and absolutely the only place on Earth where you should see Departed. I did it one night and after we left the theater it felt like the movie never ended: you see a golden globe of Massachusetts state capitol and when walking through Chinatown I half expected Leonardo Di Caprio pop from around the corner.

ATM like machines or rather the reaction that they elicit might actually sell tickets as a major tourist attraction on its own. The theater going public in Boston downtown consist mostly of college kids. They were born after the PC. They never knew the world without a personal computer and it takes a lot to make them give up and get the ticket in a normal way but those ATM do achieve that feat.

You may think that it would take about 3 clicks to buy the tickets. Select the show, select the number of tickets, swipe the card and you are done. Apparently, it would be too simple. First you are presented with the list of movie titles. The screen is  small, but not that small that it would not fit 30 titles. However UI designer – if there was a designer – chose the font size that allows only 15 movies to show up. It’s a big movie theater and the movie that you want to see is always on the second or third screen. You get to the next screen by clicking something that looks suspiciously as yet another movie title. One day someone is going to release the movie More and make the whole exercise even more interesting. It’s not easy to find the movie you are going to see because the titles are displayed in a random order. I am not kidding here. It is a random list. One would have thought that at any given moment there are no more than 3 or 4 movie starting, and since I am here at 5 I do not want to see the movie that starts at 10. But no: in spite of the fact that ATM knows the current time, there is no attempt to present movies that are just starting at the beginning of the list.

I do not know about you but I rarely go to see the movie alone. Even less commonly I buy 0 tickets. But that’s exactly the default: 0 tickets. Being in love with 0 is a dead giveaway for mediocre computer geeks. You know – the type that would never go to actually see the movie. By my completely unscientific study 75% of the public on any given night is there in tandems. We might as well make life easier for them, since simple math shows they would need 2 tickets.Once you manage to select the movie and select number of tickets and go through several ‘are you sure’ screens you need to swipe your credit card. It’s not simple since you have to do it exactly the right way – not too slow, not too fast, proper side up. And then the machine starts whirling and ask the pivotal question “Are you an AMC movie watcher”. Since you’re buying tickets to watch the movie at an AMC theatre you are tempted to say “yes”. Big mistake. Movie watcher is a loyalty program. Saying yes requires that you enter your movie watcher id. If you do not have your ID your entire transaction will be canceled and you’ll have to spend another 5 minutes in front of the spiteful ATM. Because this slows everything down and apparently no-one actually is “AMC movie watcher” the person behind you usually yells “Press NO” when the dreaded question appears. I have been a witness to ATM range when quite an attractive girl was close to knocking down a scary looking guy who pressed yes twice in the row and was heading for a hat-trick.

After you safely navigated the screens, machine attempts to print your tickets. At this point it might determine that there is no paper. It was just playing with you, but it is really sorry it cannot print your tickets and – I am not kidding – offers to sell you tickets to some other show. Because apparently the out of paper state is somehow transient and can fix itself. Or maybe this time you’ll be a good pal and actually buy 0 tickets. No need to prevent 0 ticket buying public to enjoy their 5 minutes of pain just because there is no paper I guess.

On this rare occasion when the machine does have paper it starts throwing tickets at you. First you get a receipt from previous transaction. Since no-one really needs or expects it, no-one waits for it either. Then there is a curve ball of tickets. The people in line are friendly: if you do not intercept them properly, they will be willing to catch them for you. Make sure not to knock them down going for a catch. But I am being unfair to UI designers here: the throwing ticket problem is entirely mechanical. Can be probably fixed by installing ticket guard of some kind.

The UI on the other hand is beyond help.

Things people are eager to tell you…

Damian: I noticed that if one writes on the list “I am going to do this and this”
Damian: it’s better than “what should I do?”
Kevin: ok
Kevin: people are always eager to tell someone they are a moron, but not as eager to answer questions

Powered by ScribeFire.

Sketches of Frank Ghery

Coding is not like building houses. The two are often compared. However, this comparison usually results in all kinds of design recommendation that effectively prohibit producing any usable software.

If you want to see that metaphor reversed make sure to watch Sketches of Frank Ghery movie. It shows the architect who design buildings the way that software should be written. There are of course beautiful buildings to watch: Disney Concert hall, Bilbao Guggenheim.

It’s a movie about architecture, but more than that it’s a movie about design process: iterative modeling, refactoring, debugging – it is all there. Gehry is definitely into refactoring. And into small iterations. It’s fun to watch when Gehry and his team apply programming terminology to the models they create. Sidney Pollack could not possibly make a movie about a coders, but only because bunch of geeks arguing on the list or looking into Eclipse IDE is not as photogenic. But in our day to day job I find myself arguing about the same things as people in this movie.

There is a question of recognizing good and bad design: knowing that you got it right, Admitting that you got it wrong. I do not care what people say but we all go by some sense of internal beauty here. You say that code is elegant or (more often) messy. You say that something feels right. That’s exactly how people in the movie talk about their experience.

In some way we – coders – have it easy: we work in a medium that translates directly into the resulting product. Software compilation is handled by computers; your design is expressed in code. You work in a strictly defined – and some say limited – vocabulary, but if you follow syntax rules you do not have to worry that someone misinterprets your vision. Not so much for architects, if they do not find a proper way to express themselves through drawings, models and design documents the resulting building might not be what they imagined. They show one of such buildings in the movie: it still looks great to me (but I did not “code” it).

Architectures – like programmers – are hired help. The interesting thing is that in both cases frequent interactions with customers actually result in a better end product. It’s not a one way street, but a learning process were vision shapes the expectations and expectations shape the vision. There is even a similar feeling of an establishment pressure. It’s not easy to propose and build something different. Gehry’s buildings are like Linux in Windows world. (And yes I have to say it: some of those buildings do not have windows – at least not in a traditional sense)

Similarly to coding, in architecture one can do very little alone. You have to have a team of people. Organizing such team, making sure that people are motivated and happy to work on the same project is an art in itself. And in architecture – as in coding – you need to have proper tools. It’s kind of sad that probably architects are better than us at using computers to develop their ideas. The stuff that they do with computers is amazing. We live in the world of primitive editors, outdated version control system and sink under the code that has not been automatically tested.

If you code for living this is a film for you. Even if you do not care for this obvious ‘architecture is like coding analogy’, even if you will not like the amazing buildings that it shows, you will appreciate the live demo of what computers can be used for. And you will feel proud that you are in this business.

may be it is rocket science after all

It’s 2005 and you still cannot spend weekends on the Asteroid Belt. Every geek I know is seriously depressed by that. Instead, bunch of smart people is spending weekend debugging stupid fuel indicator on Discovery.

That made me think about unit testing. Pretty much eveything does these days. Some time ago I have read Columbia Last Flight. By now everyone knows about that fatal piece of foam that smashed into Columbia’s wing during lift off. Apparently for a long time, despite of increasing evidence, some NASA engineers could not accept that. They decided to test the “foam did it” hypothesis. They were actually shooting foam pieces into shuttle panels and monitoring the damage. William Langewiesche in his Atlantic Monthly article describes the critical test: The gun fired, and the foam hit the panel at a 25-degree relative angle at about 500 mph. Immediately afterward an audible gasp went through the crowd. The foam had knocked a hole in the RCC large enough to allow people to put their heads through.

I like to think that this is what happens when you type “ant test-all”. A gun is fired, big piece of foam hits sipXconfig code, damage is assesed. There are no gasps, just test report. And if there is a hole, no-one’s life depends on it. (Well, there is this e-mail from lazyboy with your morning coffee.)

Now the sick part: it almost makes the lack of Asteroid Belt vacation package bearable.

resonance

Contributing to sipXconfig is one of the most exciting things in my career as a software developer. I blame “open source resonance” for that. We programmers are a lazy bunch. It’s a good thing too. I did work in the past with coders that were not lazy and could write code faster than I could delete it – what a pain!

And, since we are lazy, we hate doing stuff over and over again. This is what computers are for. People are for pressing buttons and enjoying a nice glass of their favorite non-alcoholic beverage on quiet evenings on the shore of Lake Geneva (not that I ever enjoyed a quiet evening there, but I suppose every lake deserves a mention in our blog from time to time).

Here’s the impressive list of libraries and tools that sipXconfig is benefiting from. I cannot possibly enumerate all, but I’ll try:

The “big three”:
- Spring – a new plumbing of sipXconfig – declarative dependency manager that behind the scenes performs a magical incantations on our humble Java objects
- Hibernate – crosses the digital divide between object universe of Java and table universe of databases
- Tapestry – encapsulates weird WEB protocols and technologies into cute reusable components meaning there is a chance we will finally have a consistent UI and will be able to forget about copy and paste option in our text editors

Silent friend:
Eclipse – our development environment with refactoring support, amazing code browsing capabilities, supernatural auto-completion, and last but not least a satisfied green bar of all test passed. Everyday is discovery, every versions brings a new set of goodies meaning that more can be done in less keystrokes. Suddenly your typing skills are less important than the problem you are attempting to solve.

The risk enablers:
JUnit and family – DBUnit, XMLUnit, WebUnit, HTTPUnit etc. – these guys are responsible for the fact that we can add features and fix bugs till the very late in the release cycle, they ensure that 95% of our nightly builds are actually quite usable, they empower bold architecture changes, they ban code areas that no-one wants to touch because the last person who understood how they worked died in the Great Fire of London; they improve our design, and – if we do stupid things – they leave light out there so that we know how to safely back off

Also all jakarta libraries, checkstyle, dom4j, xerces, digester, postgres, jetty, tomcat, cglib, ognl, subversion: none posible without open source. Open source friendly bug track and test coverage tool (JIRA and clover) deserve an honorable mention too.

So we are indebted: and that’s why we post from time on Tapestry or Spring list showing others how we solved some problems. (Well that, and the fact that we are terrible show-offs and attention seekers.)

And that’s why we hope that more and more people will want to contribute to sipXconfig – filing bugs, implementing new phones or gateways, writing wiki notes. We want to get to the point the resonance works for us too. And when we get there, you’ll be able to manage your toaster with sipXconfig. That reminds me of something. I wonder what is this strange smell from the kitchen….

reasons not to overuse XSLT

I fixed a bug.

This is why I dislike overusing XSLT. We take the data from couple of different sources, cram it into XML document and generate HTML page through XSLT transformation. There are at least two really bad things here:

1. We are passing data between different application components as XLOBs (XML Large Objects ™ ). I do not care about how ineffective it is, I do care about how non-transparent it is. You never know what someone decided to put into that XML and you never know who and what depends on its content.
2. We are using XSLT to apply bussines logic. In this case to decide which components are editable and which are read only. Aa a result our UI code is hopelessly hidden in the ocean of bussiness logic writen in poorly designed and not especially convenient programming language (XSLT).

The bottom line is template based approach (JSP, Velocity, XSLT) quite often degenerates in the heavy proprietary scripring, where template stops resembling your destination document (which is the main reason to use the template after all). I think I prefer Tapestry to JSP, DOM4J/JDOM/Xstream to Velocity, Java/Python/Groovy to XSLT. Also I prefer cats.