Setting up @ Demo 08

January 30, 2008

Yesterday was setup day at Demo 08.

Demo 08

While setting up the Cozimo station, I had the chance to meet Ben and Fred from, a great startup from Montreal. These guys really know how to generate buzz, and their product looks really promising. Congrats and best of lucks, StandoutJobs! folks rock da house

And here’s Cozimo’s station.. number 69. That should be easy to remember πŸ˜‰

Cozimo station #69

Kudos to the Demo 08 technical team: they are competent, friendly and get things done in no time. Setting up our pavilion station and the main stage was really easy. If they only allowed for more than one video feed to be projected on the big screens, it would make our collaborative life much easier… πŸ˜‰

Demos, demos, demos.

January 11, 2008


Cozimo already enjoys a nice group of customers, but we haven’t really demoed it much yet. It’s time to go out, see the light, take a deep breath and start making noise.

So here we go! After a first presence in Toronto, we’ll be presenting our work at DemoCampCUSEC2 and at StartupCampMontreal, before flying to Palm Desert for DEMO 08.

So don’t be shy, drop by and say hi. We may even have goodies for conference paraphernalia collectors… πŸ˜‰

Γ€ la prochaine!

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.