Thick As A Brick

My first patch for OpenJDK has been accepted. Yay! So maybe I should start submitting the whole bunch of them 😉

I found a marvellous site with annotated lyrics of Jethro Tull songs. Especially the lengthy interpretation of Thick As A Brick has caught me.

Also, I’d like to point out the Denkportal blog of a friend of mine (german only), for everybody who prefers to think for herself.

Advertisements

Usability of desktop apps, or why file menus are not needed

Usability of desktop applications has been a concern for me for quite a long time. I’ve been thinking about it lately and came to some conclusions that I’d like to share. I have the feeling that modern desktops are mostly stuck in a dead end with usability, and M$ takes credit for most of it.

I’d like to explain one aspect of usability with an example, that is creating, editing and handling a text document. I’d like to start with how this is usually done on all desktops I know (Windows, KDE and GNOME) (sorry if I include details that seem obvious to anybody but the completely computer illiterate, I have my reasons):

1. Start the text application (for example OpenOffice Writer). That includes knowledge of the existence of such an application and that this app is needed to edit texts, navigating something like a start menu to find the application.
2. The application comes up with an ‘unnamed file’ and an empty edit area.
3. You start to write something. At some point you need to save it (hmm. this includes you have to know that there are two states of your data, the copy in RAM and the copy on your harddisk.) So you navigate the thing that is called ‘file menu’ and choose the save option (urgs, there’s also ‘save as’). Now you’re presented with a dialog that is similar but not exactly the file manager you know from the desktop and are prompted to enter a filename, because so far the file has been ‘unnamed’.
4. At some point you’re done and want to close the application. Navigate file menu to the exit menu entry (what’s this to do in the file menu anyway?). You’re prompted with the question if you want to save the file etc blah blah.

In an ideal word, the above steps are full of usability problems. At least from my point of view, things would be much more intuitive the following way (if people weren’t so much used to the above way that is):

1. Navigate from the desktop to a folder where you want to create the file (maybe including creating new folders on the way).
2. Choose option ‘New File’ in the file manager. This will ask you which type of file you want to create. You select ‘Text File’ from a list and enter a file name.
3. The file is opened and you find yourself in an empty editor area. Note that there’s no need to distinct between the file you have open and the application that actually does all this. This is a detail that the user should not need to know about. The user should care about his files, not about applications.
4. Edit away with the file. Actually, there’s no need to save the file, because the data in RAM is kept in sync with the data on the HD quite cleverly. And of course, the undo buffer is saved along with the actual file.
5. If you’re done, choose the standard close option for each window (like the small cross in the upper right corner). The ‘application’ has no need to ask questions at this point because all the data is already in sync with the HD, see point #4.

Now, if you think this further, you will find that many concepts in the so called modern desktops are actually not needed and only hinder usability and simplicity of the desktop. There’s no need to have a start menu, there’s no need to have a distinction of (data) files and the application that are used to edit them, there’s no need for a file menu, etc etc.

So why was all this invented in the first place? Most of these concepts date back to the good (ok, they were actually pretty bad) DOS days, when there was no such thing like a graphical desktop, but applications like MS Word were already good enough to have menus and mouse support. At that time it made sense to have a distinction between apps and data files (because there was no file manager), it made sense to have a file menu (because there was no file manager and the computers at that time didn’t have enough resources to keep RAM data and HD data in sync in a useful way). That was actually pretty sophisticated at that time.

So, why do modern desktops still stick to these old concepts, which actually seem to be in the way of reasonable usability? Well, the answer is simple. One big rule in usability engineering is to take care of the user’s expectations and habits. People got used to these concepts so much that at one point it actually became impossible to change these concepts. I mean, imagine a desktop without a start menu, without the concept of applications even. Imagine applications without file menu, etc. Kindof hard, right? If M$ decided today to revamp Windows in such a radical way, they would probably loose millions of users. The same is true for KDE and GNOME. Remember the big debate about the spatial nautilus? A pretty radical change in a good direction, not perfectly implemented maybe (it’s much better now, because users can change it to their needs). But it certainly turned away many ‘power’ users (which infact only had pretty strong habits and didn’t want to let loose). This is why we will most likely see file menus in 10 or 20 years still, although they are not strictly necessary.

OpenBayes

While evaluating some possibilities for a new (top secret still 😉 ) project in which I’ll participate, I came over OpenBayes. This is a free implementation of Bayesian Decision Networks in Python. (BTW the bayesian spam filters are only slightly related to that, the filters are much simpler). This is a little like a closing circle for me. I was working with bayesian networks back in the beginning of my study, and even started an implementation in Java (but haven’t come that far with it). Later I leant the Python programming language in which I implemented a Knowledge Tracking application, which I even implemented in J2EE before. Re-implementing this in Python was so much easier I can tell you.

Anyway, I came back to Java programming soon, now hacking in J2SE library and Java VMs for some years already. I’m looking forward to this new project, which basically pulls together most of my past experiences. And I will hack in Python again, yay! This is going to be an interesting challenge…

A hard day’s work

Today I managed to write only one line of code

value |= 0xFF000000;

This solved a whole couple of problems. Anybody who can guess what this does gets bonus points! (ok, it’s not that difficult..) Thank god I’m not payed by lines of code 😉 OTOH, my average loc count per day is much higher than this. Some time ago I read that the average lines of code written for extremely safety critical applications is around 1 line / day. So do I qualify for safety critical apps now? 😉

Ok, jokes aside. I upgrade my server on kennke.org today to Debian Etch, and am pleased that it had absolutely no problems, despite the fact that it went from Linux 2.4->2.6, Apache 1.x->2.x, MySQL4.x->5.x, etc. Awesome. Mind you, I did all this over an SSH connection to the server that is located some hundred kilometers from here, and to which I have no serial terminal connection. This is what I love about Debian on servers. I wonder why Fedora and other distros can’t do this. RPM isn’t really worse than DEB technically, but the quality of the packages seems to be a little lower generally.

New JCK license

Yesterday Sun announced a new license for the Java Compatibility Kit. I’m looking at this with a happy and a sad eye. At first sight this looks like a good move: It will allow OpenJDK derivatives (like IcedTea) and distributors of OpenJDK (i.e. Linux distros) to test for compatibility and to obtain the ‘Java compatible’ sticker. Furthermore, it seemingly encourages free software implementations of Java. Only VMs that are distributable under the GPL can obtain this license. Commercial vendors still have to pay for the commercial JCK license. So far so good.

The license comes with two major conditions: It can only be applied to VMs that are GPL-distributable and it has to be substantially derived from OpenJDK. This excludes all non-GPL or non-OpenJDK-derived VMs, for example Kaffe (=not (yet) OpenJDK derived) or Apache Harmony (neither OpenJDK derived nor GPL). I think that this is a bad decision by Sun. It makes Sun’s moves look as if the liberation of the JDK was basically a reaction to the Apache Harmony project (read: Intel and IBM). I understand that Sun has business interests like every other company, but I don’t think it’s a good idea to split the free Java community in 1st and 2nd class citizens. And I don’t think that this is in the spirit of the JCP. And btw, I don’t even think it is in Sun’s business interest to slap Harmony in the face. A free Java ecosystem that includes everybody would be so much more powerful than a fragmented one.

FreeType fonts in OpenJDK

Hurray! One of the major encumbrances in OpenJDK have been resolved and OpenJDK can now be built and run with FreeType:

Good work Igor (and who else was involveld)!

What’s left is the rasterizer (anti-aliasing rasterizer and path widening) and the color management library. Unfortunately, I don’t have much free time right now to help out. The baby and my job are eating up 150% (ahem) of my time…

Xebece

Yesterday I received a 20$ donation for my old program Xebece, a nice little tool for visualizing large sets of information. That is really nice. It made me hack on it again immediately (you see, I’m completely reward-driven 😉 ).

I was really shocked when I looked at all this code. It’s only 3 or 4 years ago when I wrote this, but man, did I write crappy code back than. And I remember I did it with the best effort to actually produce good code. Duh. On the other hand, it’s really amazing what I learned in all this time. Most of this can be credited to my work on GNU Classpath (which I actually started because I wanted Xebece to run on a free Java platform).

There’s still many ideas floating in my head for Xebece, when I find some free time *cough* I gotta implement:

• An abstraction for the tree view, to allow alternative renderers. More specifically, I’d like to re-introduce the hypertree library. The first versions of Xebece (actually, Ontographics back then) where written against this library, but removed in favor of Prefuse because the hyperbolic tree rendering is patented in the US. However, I think it is the superior renderer, it is GPL just like Xebece and I’m a co-maintainer of this project too, so I have more control over the code (yeah yeah). OTOH, Prefuse is some BSD license (the version in Xebece is actually the dreaded 4 clause license with advertising clause which actually makes it non-free, but it seems like they changed it to a free 3-clause BSD lately, together with reworking all of the API to be completely incompatible with my code, hrmpf).
• Throw out the weird text/image blocks on the right pane, and replace it with a simple HTML editor. Same practical purpose, but much more straightforward to use (I hope).
• Allow interconnecting links from one tree node to another (which effectively makes the tree a graph), possibly augmented by special URLs in the HTML pane.
• Speaking of URLs, using a HTML editor would also allow external web URLs in the information panel on the right.
• Easy to use Applet export which would create an applet bundle out of the current project for simple uploading on a webserver.

Phew, quite a lot of ideas. And most of them were floating around for 2 years already and I never got around to implement them. Let’s see how far I get now.