Evil Whiteboard

April 30, 2008

Who said that remote white boarding had to be sexy and virtual?


March 21, 2008

I have always admired Trent Reznor‘s artwork. I have also admired Marcel Achard‘s creations since I met him many years ago here in MontrĂ©al. While very different in style, they both produce multi-sensorial, viscerally emotional and personal content.

Tonight the moon is full, and my inbox is calming down — Easter weekend started. Yet, I just got a surprise: Marcel sent me a short video he’s producing in the context of the GHOSTS collaborative project. Get your hypothalamus ready, dim the lights down, raise the volume, then click play:

Arrivederci Eolas!

February 9, 2008

In 2006, the folks at Micro$haft changed the way Internet Explorer embedded control objects, affecting in particular how web developers deal with Flash objects. The reason: the Eolas patent dispute. The outcome: web developers started growing considerably more gray hair than before. Yet, it contributed to the flourishing of Flash embedding Javascript libraries, and to endless discussions on how can you best embed flash content.

These discussions were not only about circumventing the side effects of the Eolas patent dispute. They were about providing alternative content, about simplicity of use, about standard compliance, about cross-browser support, and about graceful degradation and progressive enhancement. Still, now that Microsoft announced that an IE update scheduled for April, 2008 will remove the click to activate functionality, reverting the software to its original design, I am trying to figure out what it means in practical terms. After all, the click to activate message is probably the main reason why many web developers adopted embedding libraries in the past years.

From an embedding point of view, not much changes really. Web developers still have to embed the beast and provide graceful degradation. Apple’s iPhone still doesn’t support Flash, as far as I know. Plus, accessibility is being enforced by laws in many countries. There are no two sides to this story; we still cannot rely on markup-only methods.

From the simplicity of use side of things, using a Javascript library is IMO the best way of embedding an interactive beast in your web pages. Decoupling is good, we were told in school, remember? A clean, well tested Javascript library takes you right there in no time.

From a standards compliance point of view, Micro$haft is pushing very hard for people to upgrade their browser to IE7 while working on IE8. This means that web developers may finally start worrying much less about IE6, and start worrying more about IE8. Is that good news? I’m not sure about that yet. I am happy to see that IE8 passes the Acid2 test. I am even happier to hear that HasLayout is as good as gone in IE8. Yet, while I do agree that the DOCTYPE switch is broken, I still can’t manage to get my head around Micro$haft’s version targeting mechanism proposed for IE8. It seems to me that every time Micro$haft proposes a new way of solving a problem, web developers have to expect a new avalanche of issues to be on top of. I sincerely hope I’m wrong this time.

While EOLAS falls into history, object-embedding Javascript libraries are here to stay. Today, the authors of the two most compelling Flash embedding libraries have joined efforts into the SWFFix SWFObject project. In practical terms, adopting this library is probably the most forward-compatible action item in my list. For the rest, it seems to me that regardless of headaches and hours of suffering caused by IE6 and the EOLAS dispute, it will all fade into nostalgia like Polaroid’s film.


Arch-Image‘s Laurent Brixius recently posted a very good review of Cozimo. Laurent is Belgian and decided to write this review in French. If you read French or would like to practice it a bit, go get a good bottle of French wine and then read the review, here. Some cheese and a baguette might be a good idea as well.

In his review, Laurent points out that digital content creators are often fluent in English but their clients aren’t necessarily comfortable with it. Cozimo lets professionals such as Laurent collaborate with partners and clients in their native language.

Internationalizing online applications is increasingly important, yet it is a significant effort even when you are fluent in many languages, happen to know somebody that is, or are lucky enough to afford a team of professional translators. There are a few points worth taking into account when internationalizing a web application.

Internationalizing the user interface is integral to the user interface design

Labels, menus and links often require more space in French than in English, and probably less in Japanese. UI designers don’t know exactly how much space a user interface control will occupy once it’s rendered. If you care about your design, you can’t rely on fixed layouts for international user interfaces.

User interface designers need to answer the same questions they ask themselves when designing a fluid content layout: which constraints are rigid? what/where are the degrees of freedom? what happens to our latest snazzy fluid UI layout when (translated) properly-aligned controls don’t fit in one line anymore?

And what about all that time and effort invested in finding the perfect hotkeys? Bad news! It’s probably worth very little in other languages. Are you relying on icons to stay out of trouble? Icons probably make things worse in an international context.

A bit of abstraction may help here. Designers use and abuse of Lorem Ipsum for content areas. Following a similar approach for user interface controls can also be a good exercise.

And all of this, of course, affects important implementation details: does our CSS enforce a white-space: no-wrap style so that translated UI elements don’t break when the window is resized or the user increases the font size? are we floating or positioning the UI controls? Designers need to communicate these dynamic aspects to the developer taking on the implementation task. Which takes me to the next point…

The internationalization effort needs to be backed up with serious code and serious coders

Internationalization isn’t just a feature that you add on top of the product. It’s a core property of the system and one that needs lots of engineering attention and love. Do your engineers know The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)? Is your application framework i18n-friendly? Are you adding internationalization in a rush? You better not! Internationalization affects every single line of code that deals with text, both as content and user interface components, in both server- and client-side code. If text translation is done on server-side code, client-side code can no longer dynamically manipulate UI text elements based on hardcoded content; it must always rely on content generated by the server. And on the server side, most layers are affected by or involved with internationalization. Text content has to make it to the functional (non presentation) layers to be sent in an email or to be sanitized for cross-site scripting, for example.

Designers, developers and translators must work together in this effort

In an ideal world, translators work with translation files and don’t even see the page templates nor source code in the presentation layers. But they do rely on developers properly building translation messages and being aware of localization issues. Developers who care rely on designers providing i18n-friendly designs. Designers who care expect a few collaborative iterations with developers, ensuring that the dynamic aspects of the design layout are properly dealt with (traditional design tools won’t capture those aspects).

Sound like lots of trouble? Resistance is futile. You will be internationalized! Internationalizing online applications is no longer a luxury. It’s a necessity. It’s a trend and a business enabler that serious online companies cannot afford to ignore anymore.

If internationalizing online applications seems difficult, it’s probably a good time to realize that internationalizing real collaborative online systems is even more complicated. Multilingual content is shared among many clients with different default languages, and the server has to deal with synchronous and asynchronous content delivery in this context. Luckily, getting it almost right usually boils down to remembering that the online application (or more precisely, the multilingual server) shouldn’t bake messages, notifications and information at the time they are triggered. Instead, it has to marshal the information in a dynamic context (view or script) that gets executed, translated and presented, in the recipient’s preferred language, when it’s received.

But then it gets hairy. Groupware invitation workflows generally include e-mail or chat notification messages. In this context, there isn’t much the application developers can do to automatically present information in the recipient’s language. One could attempt using Multipurpose Internet Mail Extensions’ language type parameter in a multipart e-mail, but I’m not aware of ways of telling e-mail clients that they should choose among the available parts based on the user’s preferred language. Unfortunately, in the years of spam, e-mail clients aren’t very hackable (client-side code is simply blocked!). Plus, significantly different email parts means higher spam scores! If you can assume that the people involved in the invitation process know each other, using the sender’s preferred language is probably the safest approach when rendering outbound text.

Now here are the good news: if your team cares, the internationalization effort will be mostly an initial investment. It then becomes a bit like writing exception-safe code and it goes pretty fast. And then you reach a point in which translators can work almost on their own, at least to add support for new languages. Google has pushed this a bit further and taken a smart approach letting users translate the user interface for them (after taking care of the most popular languages, I believe).

I’m getting hungry now. Il piatto del giorno is a creamy asparagus risotto. Given the abundance of white wine, I’ll probably get that Italian translation going…


First Cozimo Review

August 21, 2007

This morning, while executing the mandatory first e-mail cleaning pass, I was surprised by a message directing my attention to an entry on David Strom’s Web Informant blog on Video production collaboration.

It really caught me by surprise. Cozimo hasn’t been announced yet and here it is: the first review. And a positive one.

While I’m not a big fan of David Strom (I often find David’s articles a bit too light for my taste), I believe David has a few good points in this brief review. In particular, he states that a recipe for a good collaborative solution should contain:

  • enough content management,
  • enough workflow,
  • simple, powerful, well integrated messaging.

But most of all: it should all be very close to the content. In the Land of the Second Web, YOUR Content Is King.

I also believe that the UI plays a first role in this context. The average Web 2.0 application is just distracting and IMO plain ugly. Shaded round buttons, reflective logos, gigantic fonts, distracting gradients, none of that leaves room for what really matters: directing the attention to the content.

Cozimo’s UI appeals to its target crowd: designers, creative minds and media professionals. Have 5 minutes? Read this. Then read this for a hint on how we are dealing with UI design. On the usability side, we are working on a few well known quirks, and clients react positively.

Only time will tell whether these human-to-group interfaces are here to stay. In the meantime, Emacs awaits.