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.

Content and Design

August 19, 2007 – 12:36 am

It’s really interesting, design. I know very little about it, but I do know that print and web design are often compared to each other in all the wrong ways. Print design is static; web design is dynamic.

One of the really interesting misconceptions about web design is that the content doesn’t matter until later on. I’ve fallen into that trap, and it’s resulted in a superb number of stuff-ups. Entire designs with no insight as to what’s going to be squeezed into them are churned out all the time and they usually work okay, but the second you decide to do something outside of the box, you’ve got problems.

You can’t design a web site, based on assumptions on what’s going to be displayed on it.

Lorem Ipsum is a great tool for filling a space with words. If you’re interested in more than just that blob of text though, you’ll need to work with some actual prose; Work out the importance of sentences, paragraphs and words before coming up with styles.

It’s also a lot easier to experiment with typography if you’ve got something to go on. You can’t get a feel for what will work font-wise if you haven’t got some quality content to deal with. Additionally, “Lorem Ipsum dolor sit amet” might look great in 12pt Comic Sans, but not at the end of the development process when you finally change it to read “Foo Corporation Pty Ltd”.

Another thing to consider with web design is that it’s not just the design that counts. You’ve got multiple pages, and a whole suite of tools to mark up your content with meaning. Not only is it impossible to intelligently apply semantics to lipsum text, you’ll likely end up with a whole host of redundant styles when you finally convert your design to CSS.

The design phase is also a good time to lay out your navigation logically. There’s nothing more frustrating than coming up with a menu hierarchy that looks good on paper, only to find out later that there’s not enough content to fill it. We can work around these issues as web designers, but only if we know about them beforehand.

That said, coming up with content is a daunting task, that clients really don’t like doing. The way I see it, there’s three scenarios that can play out.

  1. The customer comes up with masses of quality content for us to work with, at the beginning of the process, with no problems.
  2. The customer comes up with minimal, low quality content, after being coerced into doing so upon pain of cattle prod.
  3. The customer hires a third party (such as us) to proof a minimal amount of quality content. After all, we’re the ones with the web experience, and know in most cases what the target audience is likely to want.

Either way, there’s absolutely no way a quality design can come out of thin air. We need to stand our ground and explain that content is an important part of the development process, and guide our clients along the way to good semantic design.

Writing A Project Proposal

July 25, 2007 – 9:32 pm

Today was good for me. I got a fair bit of work done, and managed to almost finish a fairly hefty document off for a client. That’s what’s bothering me; not the “document” bit, or the “almost finishing” bit… The “hefty” bit. Some of the paperwork we’re churning out for our customers at Bottlebrush is verging on ridiculous.

I think the problem is that we’re trying to be a little too transparent with what we do. We’re offering the client too many options in our solutions, when all they necessarily want is to just “get a web site running”. The competing company around the corner have the philosophy of making the process of getting a web site as easy as it can possibly be, and even though their product might stink, their process is fantastic.

I’ve been idly musing over how to make our “project proposal” — the document that we use to judge if we’re on the same track as the client — a little easier to digest. Currently our standard one is about thirteen pages, chock full of facts, ideology, options and a fair amount of page breaks. While it’s all really important information, surely there has to be a way to condense it into something that is easier on the client.

Some good techniques that we’re already including involve using bullet points, tables, and short paragraphs to get our points across. Another good idea is to have a summary of what the document is trying to say at the start, so that the reader can get the facts straight up and then read on if they like.

I’m thinking that it would probably even be possible to separate our “proposal” into two sections; The first with the price, goals, what’s expected from the client and other proejcty stuff. The second document can be for more generic things like our policies, and an explanation of how things work. But the problem of having an enormous document to wade through isn’t solved by breaking it in half; there’s some important design considerations that need to be made.

We’re in the business of creating semantically rich, well formed, and generally high quality web solutions that make life easier. We should be expected to apply the same principles to our administration work too. My next project is to crack this usability barrier, and I’ll report back here with my results.