Facebook

October 9, 2007 – 12:41 pm

You all know I dislike it, but I just thought I’d reiterate my disdain for Facebook. It’s a ghetto of bad design choices with a pretty UI disguise slapped onto it.

Why would you lock a log-in button after it’s been clicked? Tell me that.

I just accidentally pressed enter while trying to log in, but cancelled the request before it could do anything. To actually log in, I had to reload the page, and enter all my details again because the form was disabled.

You can’t justify that kind of design choice. It just can’t be done. It’s mainstream implementation of stupid ideas like this place that makes stupid executive types want to copy all throughout the web.

Desktop Metaphors

August 31, 2007 – 8:14 am

I’m thinking of a desktop metaphor; See if you can guess it. I’ll bet you can’t, because it’s not the kind of thing you usually see or hear about. How about I just tell you anyway.

Hot folders. We see this kind of things on web siter and forums all the time: a “hot topic” usually turns red, or gets progressively redder the more popular it becomes. Why can’t we have this in the Gnome desktop?

Today I was having catastrophic troubles keeping track of the massive hierarchy of work and personal data on my laptop and the plethora of network servers. I was performing mostly the same tasks, but each time I’d have to navigate through up to seven levels of metaphors. Menu, server, location, location, location; over and over.

You’d think that someone would start to remember after a while, but the point of an interface isn’t to force an user to think harder; it’s to guide an user doing what they want to do. If every time I went into a folder it “heated up”, soon enough I’d have a clear path to the locations I most frequently used.

In today’s example, I’d have my project’s documents in my home directory, and the actual project on the server emblazoned in burning red; outfitted with a little flame icon. I’d also have burned a path to “corporate branding”, and “web site notes” that wouldn’t have warmed up so far, but still easy enough to recognize from the plethora of other folders in my browser.

The problem as it stands is that it’s really mind-intensive, performing some of these overly repetitive tasks. There’s no readily accessibly bookmarks or semantically rich history for recently visited folders. I’d personally love a “tag cloud” for recently accessed files on my desktop.

Is anyone working on this kind of accessibility?

Another UA Screws Up

August 29, 2007 – 7:16 pm

After the launch of one of our web sites, we had a number of clients complain that the contact form was difficult to read. That came as a bit of a shock, because we’d tested it in everything we could think of. I’d even installed a copy of Netscape 4 for the occasion. Nevertheless, whatever we did resulted in half of our “white on black” form elements having white text on a pale yellow background.

One of of the clients with the problem brought in their laptop to show us what was happening, and we spent a grand total of five minutes searching in vain for what was causing the problem. There was nothing hexadecimal, RGB or otherwise specifying that pale yellow background colour on our forms, so we took a different tact.

The conclusion was slightly anti-climatic and simple to fix, but the cause was the strange part: We isolated the problem to Google Toolbar and its form completion functionality. Whenever it offered to auto-complete a form for you, it would change the background colour of a form element to this sickly pale yellow colour, but leave the foreground colour whatever was specified in the style sheet. We’d found the source of our “white on yellow” forms.

After that, it was a simple matter of giving the background and foreground colours an !important declaration, which stopped the toolbar from changing the colours. Everything was fixed.

We would have been fine leaving the toolbar to change the colour scheme if it had done it properly. Nevertheless, this is an important lesson to everyone looking to dabble in accessibility: If you’re going to set one colour, set them all.

OpenDocument and OOXML

August 19, 2007 – 10:07 pm

If there’s one word that’s running through my head, it’s “sneaky”. I’m one of the most open-minded people I know, but arguing that the world needs two document standards that do exactly the same thing because they “can and do co-exist” is just moronic.

The standardisation format war between OpenDocument (sponsored by a consortium of people and businesses), and Office Open XML (Sponsored by Microsoft, for Microsoft) has just started to heat up. The Microsoft document format is undergoing a vote to fast-track it to ISO standardisation. This will benefit nobody, except nobody since there are already a number of formats that can be used to do what Microsoft is arguing OOXML is unique for. Still, the fact that the standard hasn’t been shot down from the start means that there’s trouble a-brewing.

Some preliminary points about Office Open XML:

  • What’s with the confusing name? OpenDocument used to be called “Open Office XML”. Now the Microsoft format is named “Office Open XML”. Is that deliberately confusing, or just a by-product of a confusing spec?
  • The OOXML format spec itself is lengthy, cryptic, contradictory, and contains numerous inadequately documented and Microsoft Office specific quirks that serve no real purpose other than to be backward compatible with older versions of non-standard file formats.
  • The format itself is tied in with Microsoft patents, and the disclaimer that Microsoft provided, doesn’t adequately protect end users and developers against patent litigation.

So now that we’ve got that out of the way, what exactly am I on about?

Recently a number of members of the ISO responded to the OOXML submission with the issues they found with the spec, and the EMCA (another standard body that Microsoft initially submitted the “standard” to) responded to that. A few of the responses were good, but a number of them amounted to nothing more than “we can work that out later”.

One of the biggest cop-outs I’ve heard for a long time is in response to the issue of “overlap in scope” between OpenDocument and OOXML. The ECMA argues that OOXML is significantly different from OpenDocument because instead of just being any old document format, it includes a way to preserve the formatting of legacy document formats.

Whoop-de-doo.

I don’t need to buy a three-hundred dollar application to convert my old documents into a new format. I especially don’t need a completely new and incompatible standard to do so. There’s absolutely nothing stopping someone writing an application clever enough to convert, for example, Word Perfect 6 documents losslessly to OpenDocument as the ECMA responses are implying can’t be done. The major selling factor for standardising OOXML is that it has a load of additional cruft to support upgrading from legacy document formats, and that makes it “practical” they both be standards.

It’s a very clever card, considering a big driving factor behind standardised document formats is that they guarantee archived data can be read in the future. Up-selling the “compatible with old document formats” aspect of the spec is bound to rouse the interest of many organisations looking to standardise and preserve their old documents. Even if it means a grubby, six-thousand page specification that nobody in their right mind would bother to implement.

So it will be interesting to see what happens. Either way, I can’t see Microsoft adopting OpenDocument. They’ve got way to much riding on the integrity of their office suite, especially considering the dismal adoption of Windows Vista. Microsoft Office is quickly becoming the flagship product from Microsoft, and implementing another new default document format will definitely be an expensive and embarrassing blow to their reputation.

I haven’t studied the specifications, so some of these conclusions have been drawn from extensive research. The ECMA responses are available as a 305kb PDF document.