A Comparison

Firstly, I’ll show a short comparison between some Java code and some code from a language that doesn’t have NullPointerExceptions, but does have something that allows you to accomplish anything you might want to do with null pointers.

This Java code:

AnObject thing = someMethod();

is equivalent to the following Haskell:

let thing = Maybe AnObject

That is, every Java object reference is possibly null. What this means is that (using the type notation mentioned in earlier posts) every Java reference has the type:

(Every object reference for an object is either to ‘null’ (AKA ‘unit’ or ‘singleton’, or the object itself.)

… and when you’re dealing with so many objects—Java is, after all, an object-oriented language, so (almost) everything is an object—this simple little “+1″ gets lost easily.

Why so bad?

This wouldn’t seem to be such a big deal, but when contrasted against Java’s penchant for making things (sometimes painfully) explicit—think public static void main (string argh!)—a small, implicit item like this is easily overlooked. Conversely, one might say that the verbosity of Java increases the cognitive load of understanding its code; thus helping the chances of a small mistake like this sneaking through.

Either way, I think I can say that this is objectively A Bad Thing. C# has gone some of the way to a ‘correct’ solution in its introduction of possibly-null primitives, which are explicitly marked with a ? (such as int?), but unfortunately this hasn’t been ‘back-ported’ to the rest of the language. If one were able to force between possibly-null and definitely-not-null references in C#—perhaps by the analogous object? vs. object, this would help to reduce the number of errors ‘hidden’ by the syntax.

Intrigued at what I first thought was a joke, I downloaded one of the proudly-presented documents on the front page: Understanding the BPMN-XPDL-BPEL value chain. I chose it because of the three as-yet-unknown acronyms in the title… and I wasn’t disappointed.

I present you with the following gem, lifted from one paragraph of the article:

Several BPM engines are able to run XPDL natively, which allows run-time modification and process migration to be readily supported. Where these processes focus on broader-scope collaboration among people, they can remain within XPDL/BPMN. Where pieces are decomposed into system-to-system interactions, these can be translated to BPEL for transmission to an EAI-oriented BPM engine. These are three very different and very compatible roles. But that’s the nature of the value chain—BPEL and XPDL are entirely different things for entirely different purposes.

I suppose the warning sign should have been their slogan:

Process Thought Leadership™

Not only does Google search fail to recognize that “it’s” is a word, it also ignores the quote marks, searching for the phrase as individual words.

Ctrl+Shift+W

Firefox

Gnome-Terminal

Ctrl+W

Nautilus

Ctrl+Q

Seahorse

Firestarter

Liferea

Gedit

Synaptic

Gnome-System-Monitor

It seems Nautilus is the odd one out; Firefox and Gnome-Terminal use Ctrl-W to close a single tab and Ctrl-Shift-W to close the whole window. Nautilus uses Ctrl-W to close a single window and Ctrl-Shift-W to close all windows.

On the other hand, you could use Alt-F4, which works on all of these (at least under Compiz)—although the behaviour is a little different. In Liferea Ctrl+Q exits the entire program while Alt-F4 only closes the window (sending it to the tray), and likewise with Firestarter.

Cowbell is an music tag editor for Gnome that boasts two things: a simple, clean interface, and a cunningly-named website. The first thing that struck me upon opening it was that it did, in fact, have an interface that was both simple and efficient. All too many Gnome programs seem to have given up good interfaces for something that is apparently ‘simple’, but ends up being more infuriating to use. Cowbell’s Amazon lookup service is usable, but I would have preferred something extra—MusicBrainz integration perhaps; Amazon doesn’t seem to pick up ‘obscure’ music very well.

However, my main gripe with the program is that while it boasts that it is a ‘music organizer’, the program lacks the facilities to deal with large numbers of songs. The input is limited to selection of files, and has no support for directories either recursive or otherwise. In this aspect it falls behind other music-tagging programs, or even some music players like amaroK.

In other aspects, Cowbell shines. Its simple abstraction-away of the various tagging formats makes it much easier to manage than the plethora of options that EasyTag and its ilk present you with. I also like the simple format for the track-renaming feature, although again this is lacking features geared towards large collections of songs. For example, attempting to set the format for track-renaming to include folder information, such as ~/Music/Artist/Album/Track.Artist - Track results in files with that as their title!

Overall, Cowbell is good at what it does. The interface is the best I’ve ever used amongst the various music-taggers I’ve tried. However, it needs more work in order to be able to deal with large collections of songs. As it is still early days for this project, it is definitely one I’ll be keeping my eyes on.

Any more questions?

Size

The first thing I noticed upon visiting the page was the incredible time it took to load. The HTML itself weighs in at about 130 KiB, and since it is sent with (as is often the case with PHP) no-cache headers, you will need to re-get the page each time you load it. Further exploration shows the CSS to be around 26 KiB, which again is huge. The various media on the page add up to somewhere over 220 KiB. All in all, visiting the page the first time will result in a download of more than 450 KiB, as shown by Opera.

Source code

This is where things start to get strange. Viewing the source of the page, the first thing that stands out is the lack of a DOCTYPE declaration. This is a big no-no. It would seem that the page designers have no care for standards. However, I then moved on to read the next line; an HTML element which has an XML namespace set on it! xmlns="http://www.w3.org/1999/xhtml" It would appear that this page wants to be in the XHTML namespace–although it doesn’t even have a DOCTYPE.

On the third line we come across <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />. Several things to note here: first of all the XML-style empty-element slash, />. Perhaps the designers have written the page in XHTML but have “merely” forgotten to include the DOCTYPE. Secondly, the element is telling us that the page is text/html. I went to check the headers to verify this, and it matches what the server has told us about the page–and they even sent Content-Type: text/html; charset=utf-8 twice! You know, just in case you missed the first one… there’s no harm in redundancy.

Continuing down the page there is a smattering of meta elements giving more information on the page. Good to see a title element included, and the CSS is included in the correct manner. Even the Javascript has a type attribute on its style element. (Although it is commented out, so if this was XHTML it wouldn’t work, and it should really be in a seperate file, considering its length. But let’s try and be nice.) However, it is once we reach the body element that things well… the nicest way to put it is “turn to shit”.

The first sign of trouble ahead is the appearance of an onload attribute on the body element. Tsk-tsk. But I’ll overlook that for the time being. What’s coming up is far, far worse.

Accessibility

Make way, make way! Here comes our old friend, the presentational table element. And what would it be bringing with it? Our old chums, the proprietary attributes cellspacing and cellpadding. This is beginning to feel like a time warp, but prepare yourselves for what comes next.

An object element. To be more precise, a Flash movie which contains all that is needed for proper functioning of the site. Without a fall-back. That’s right, without Flash installed and running, you cannot access any of the following:

• The navigational menu.
• The search box.
• The country selection menu.
• The login form.
• The “register” or “help” buttons.

What drove them to do such a thing? Is no one but those who have installed Flash worthy of viewing and partaking in their site?

Ok, I lied a bit. You can register without being Flash-enabled. But you better have Javascript enabled, or you can’t click the “submit” button. In fact, this “functionality” extends to the rest of the site. All those juicy links on the middle of the page look tempting, don’t they? Unfortunately, they don’t work–at all–if you have Javascript disabled.

But who has Javascript disabled anyway? To see what it would look like in a realistic situation, I loaded up Lynx. To my surprise, Lynx claimed I had 10 pages of information to go through. Surprised, I looked at what was on offer… a list. A list, 7 pages long, of games. Where’s the content? Finally, on the eighth page I got to what looked like the first bit of content. “Latest news and information.” I pushed the down cursor, expecting the link to highlight so I could hit enter and proceed to the page which would supply me with EA’s latest news. Unfortunately this did not happen. The cursor skipped happily over the link, ending up on the next page. Bemused, I tried this with the rest of the interesting-looking links on the page. Not a single one worked. Every single one of the links to important content was powered by the greatness of Javascript. I was reduced to following links from adverts and to information about other games.

This, however, didn’t seem to make much difference. No matter where I clicked, I couldn’t tell the difference between the pages. Every single page started with the same 7-page list of games before I could proceed to the content, upon which I was not deemed worthy to click.

I quickly escaped from the hell-hole Lynx had led me into and decided to turn to automation for an evaluation of the site.

Validation

First of all, I submitted the site to the trusty old W3C validator. Due to it not having a DOCTYPE, the validator fell back on HTML 4.01; which the page failed with flying colours. 79 errors, some very non-trivial.

You may be thinking “hold on a second, the page was obviously trying to be XHTML, what with the namespace and the closing slash, the designers have just forgotten to insert the DOCTYPE!”. Following these lines of reasoning, I forced it to validate as XHTML 1.0 Transitional, just to be nice. No improvement… rather the converse. 138 errors, many of which are caused by the unescaped ampersands.

Well, it didn’t fare too well on that test, but perhaps it will do better on the CSS, after all, that’s something that’s fairly hard to get wrong. Submitting the site to the W3C’s CSS validator came up with 3 errors and a warning. Not bad for six-hundred and thirty-four lines of CSS.

After these sorts of results, and the sheer lack of markup that actually describes the content in a sensible way, I didn’t even bother running it through an accessibility checker or semantics extractor.

Conclusion

The design is hideously inaccessible, and I’m suprised that EA even went ahead with a site launch of such a shoddy product. It doesn’t suprise me that as of writing, only 8 people are chatting on their boards. It seems that someone has started with an old-style, table-based design and added nothing more than empty-element closing-slashes in order to join in with the “standards-compliant” buzzword. Does this herald the coming of a new age, an age in which sites claim to be standards-compliant but are doing the minimum required (or less) in order to jump on the bandwagon? Let us hope that an era of abominations–mishmashes of old-style attitudes towards web design, mixed in with some misguided splashes of “standards”–does not manifest itself.