Excel

So I already noted my frustration with OpenOffice yesterday but today I’m definitely reaching my limit. And I’m going to rant, yes, it’s going to be pure rant about OpenOffice, encompassing some of the most annoying problems I had with it in the past years. So if you’re one of those people who can’t stand when other Free Software developers complain about projects that are not perfect, please move along. I’m not just going to bless OpenOffice as perfection just because it’s Free, it’ll have to improve for that. Oh, and yes I know that version 3.2 was just released, and I’ll test that one, but then again I’m not sure that there is any improvement about this, I’ll have to see it by myself, and right now it’s not available in Gentoo for me to try.

So let’s begin with one of the most hyped and, apparently, still incomplete feature: interoperability thanks to the OASIS OpenDocument Format. With OpenOffice 2, there should have been total interoperability between Free Software aiming at managing documents, presentations, spreadsheets and so on so forth. Unfortunately, just after the release of the first two suites using that format, I came across a difference in implementation that caused the two of them to export the same content (lists) in different way, both available in the specification for the format, and yet not equally implemented. So long for the interoperability. At the time, I even considered Microsoft’s much more complex solution more feasible — two years after my first rant, the bug was still open; it was only fixed an year later with OpenOffice 3.1.

Interestingly enough, yesterday Morten Welinder, of Gnumeric fame, posted an unrelated rant that finds its root in the same problem: OpenDocument wasn’t specified nearly as deeply as it should have been to begin with. In this particular case, the problem is even worse, as the lack of a standardised interface for formulae makes it almost useless as a format for complex spreadsheets. On a more related note, I also complained about the formula support especially related to the fact that formulas in OpenOffice change function names depending on the used language, and the comma/dot change as decimal separator makes it almost impossible to use it properly in Italian.

To defend OASIS here, ODT is definitely not the only format designed for interoperability that is not interoperable by a long measure. For instance, SVG caused me headaches also including OpenOffice in the mix.

Other problems are intrinsic in the way OpenOffice is developed, I guess, and the priority that they have. I already complained about the tentative imitation of Word regarding their work toward adding “HTML editor” to the list of features Writer has. Not sure how to read the fact that they moved the MediaWiki editor support to an extension… I didn’t even know it had such feature… wasn’t the point of Wikis to not have to use a full-fledged editor to begin with?

There is definitely a number of minor annoyances with OpenOffice as it is. The fact that to set a colour, anywhere, I need first to get to the options and define it as a custom entry in a palette, rather than having a simple colour picker like any other software (Inkscape, Gimp, …) is just the start. You also need to install extensions to have any kind of document template available, and quite a few of them look also totally broken.

Most annoyances seem indeed to come near the areas of drawing and spreadsheet handling (especially charting). You might have noticed my Ruby-related charts and graphs but you might not have noticed one bad things with them. Beside the minor annoyance that I have to copy the graph from Calc to Draw (and thus lose the correlation with the data I’m charting) to be able to export it properly, if I copy the legend out and add text boxes… OpenOffice Draw exports the spell-checker warnings! Look at the images, and notice that the text is zigzag-underlined in red. I couldn’t believe it the first few times.

And today’s problem, is due once again to Calc, and to the charts provided above: I have a spreadsheet file where I keep the scores for the various implementations, to see the trend in porting (for instance I know that nobody else beside me is handling JRuby support nowadays, as it’s stuck when I don’t touch it).

One of the problems I had before is the area and line charts have different ideas on how to handle empty values. If I chart a 30-lines spreadsheet area with a line chart, which is only half-filled in, the graph stops at mid-air, and that’s it (works out fine since it gets automatically extended when I add more lines); on the other hand, if I do the same with an area chart, then it assumes that the empty results have zero as value, and will draw a line falling down to the X-axis at the first empty position. Annoying, but at least acceptable.

On the other hand, what is definitely not acceptable to my way of using this is the way it handles the X-axis values! I was away for FOSDEM, and then had a bit of personal trouble, so I stopped gathering data on February 3rd and I resumed yesterday, February 10th. I added the data to the spreadsheet and… the graph didn’t jump, the same distance that applies between February 2nd and 3rd is applied between 3rd and 10th. This is not right. Indeed, Microsoft Excel gets it perfectly right in this case, and this is exactly what I was expecting: keeping proportions. And before you suggest I keep the same value as 3rd for all the missing days, that’s not how it was, and it’s not what I’m interested in charting. I’ll have to see if I can get some other software to deal with that kind of data (interestingly enough, Gnumeric does not seem to have that feature either, but it might be I just don’t know how to use the charting tool there).

So, should I accept the compromises just because this is Free Software? I don’t know what you think but I don’t think so, I’ll look for a better software, if it’s Free it’ll have extra points, but since there is a boolean gate to the “better” definition (either it does what I need or it does not), right now OpenOffice is definitely not better than anything else for this task (it does not do what I need). It’d be definitely absurd if I’ll end up relying on Microsoft Excel to provide the graphs for Gentoo’s Ruby porting trends, but right now, that does pass the boolean gate. Please, do provide suggestions! I do want to find a better software, a Free Software doing this.

And to keep on the ranting note, do you remember the “OpenOffice Mouse”? That abomination of design that was announced around the time of the past OpenOffice Conference in Italy? The one that a lot of people – me included – thought and hoped was just a joke, playing on Apple’s then just-unveiled Magic Mouse? Well I haven’t heard anything about that for a while, beside being confirmed by Luca that it had been actually developed, and even produced. I went to look it up today, as I wanted to add to the rant the fact that instead of getting a better quality product, time was wasted on products like that… and the results are even funnier. The link above, while having ”OpenOfficeMouse” in the domain, talks about “OOMouse” (trademark, anybody?) and if you drop the actual page, you end up finding that it’s now the “WarMouse Meta” which, and I quote, “compares to the Magic Mouse, the G9, the Naga, and other multi-button and multi-touch mice”… oh, the irony.

While I’m a fervid proposer of native language support in all kind of software, which includes not only being able to display and make use of native characters (like the ò character in my surname) but also user interface translation and adaptation for the user’s language, I have a huge beef with what I’ll call “natural language interfaces” in this post.

The most widely known natural language interface is the formula language used by spreadsheet software, like OpenOffice Calc and Microsoft Excel. Since both applications are designed to be used by accountants for the most part, they try not to require of them any kind of generic programming skill. Which seem to still include “no knowledge of English”, even though nowadays I’d expect all of them to know it at the tip of their fingers anyway.

At any rate, the language used for the formula is not independent from the language: it changes both function’s names and data formats depending on the selected language. So not only the SUM() function becomes SOMMA() in Italian, the decimal separator character changes from . to , with the obvious problems tied to that (if they are not obvious to you, comma is still the parameters’ separator as well!). I’m not sincerely sure whether internally the two spreadsheets save a generic ID of the function or the name in the local language; I sincerely hope the former, but either way the thing is already quite brain-damaged for me.

But you don’t have to go down the drain to the programming languages to find of places where natural language interfaces do suck. One other example is something so widespread one would probably not think of it: GMail, or Google Mail (and this will come obvious in a moment, why I do precise both names). I guess this also counts like a further example of Google’s mediocrity but I’m not stressing that out; it’s one (somewhat smaller) fault in a product that is, otherwise, great, especially for Google.

Now, you might not know – I didn’t either till a few months back – that GMail is not called GMail in Germany; Jürgen explained this to me when he wrote gmaillabelpurger (one heck of a magic tool for me; it saved me already so much time; especially load time for IMAP access): because of trademark issues they had to fold back to call it “Google Mail” there, thus creating one further domain (even though users are mapped 1:1 on both, which makes most of the point moot I guess). When the user has registered in Germany, it’s not only the web interface to change, but also the IMAP folder hierarchy: the [Gmail] prefix in the service folders’ names changes to [Google Mail].

This would only have mattered for the small error I got when I first tried Jürgen’s script (as he wrote it with the German interface in mind) if not for another issue. Using GMail with the default English language selects the “American” variant. And such variant also affects the dates shown in the web inteface; and since I don’t usually like dealing with stupid date formats (don’t try to say that mm/dd/yyyy is not stupid!) the other day, when I needed to use it to look up a timeline for work mail messages, I switched the interface to “English UK”, which solved the problem at the time for me.

Fast forward a couple of days and I notice that the script is not behaving as it should as messages are not deleted; a quick look has shown me the problem: Gmail’s IMAP interface is affected by the language settings in the web interface! What that comes down to be at that point is that the old Trash folder gets renamed into Bin; d’uh! And even worse, setting the UK variant for the language causes some quite large confusion with the trademarked names: the web interface still reports GMail, but on the other hand, [Google Mail] is used in the IMAP interface. And that’s with me still connecting from an Italian IP address.

Now, thanks to Jürgen the script works again and thus my problem is solved. But it really should show that writing interfaces that depend on the language of the user isn’t really an excessively smart move.

I also start to wonder how soon I’ll get used to move my mail to the bin, rather than trash it.

OpenOffice trouble, again, again, again

Why natural language interfaces suck