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.


I’m back in Montreal recovering from DEMO 08, where I had the chance to meet super interesting people and to show Cozimo to the press, entrepreneurs and VCs. Now that Cozimo is officially out the door, I’m busier than ever. Luckily enough, it’s not just about answering I forgot my password support e-mails… some interesting developments are forming and there’s still energy left for midnight hacking, so I can’t complain.

Still, I can’t wipe out from my brain the vision of Monique Savoie menacing me: “Don’t you dare hiding for a year ever again, or else!“, so I decided to go to the very first Montreal Python event. And it was fun!

David Goodger, architect of DocUtils and renowned Python activist, entertained us with one of his old-time passions: polyform puzzles.

Dominoes, Pentominoes, Polyominoes, oh my!

David briefly described algorithms involved in solving these puzzles…


… but I wished he focused a bit more on stuff like this:

Python! Python! Python!

It was an interesting presentation, and a good way to start Montreal Python’s series of events. Montreal is buzzing more than ever, and it feels really good to be part of such a vibrant community. Kudos to the organizers for a well organized event.

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…


Here’s another proof that contemporary groupware is as socially inept as their authors. It’s also a personal reminder not to accept invitations to social networks before knowing what I’m getting into. Yes, my mom taught me well.

I just got two consecutive invitations to join Quechup, Yet Another Social Network™. My first reaction: “DO… NOT… CLICK!”. Even though the two invitations originate from people I respect, I decided to take a look at this social marvel before accepting the invitation. Oh boy… this is the ugliest social network I’ve seen in a long time. It almost beats a very ugly and disfunctional web page I recently stumbled upon.

My brain shouts: “WAIT A SEC, THIS IS AN UGLY DATING SITE. GET THE HELL OUT OF HERE!”. Now why would my friends invite me to an ugly dating site? Something is not right. Quick! Alt-tab-tab-tab and I land on iChat where I read “IGNORE THOSE INVITES!” and “KILL QUECHUP!”.

It turns out that the geniuses behind this new brilliant online software decided that it was a good idea to send invitations to everyone in the new member’s address book, without asking for permission nor informing them. I guess they probably figured out that getting hundreds of “out of the office” e-mail bounces is enough notification…

BRAVO! Marketing geniuses these folks are. I hope their lawyers are also geniuses, because they will probably get sued and bomb.

You see, mom was right! Now do yourself (and a few tomatoes) a big favor, stay away from Quechup.

Matrix meets Teletubbies

August 26, 2007

ITube! YouTube! We All Tube @ YouTube!

What a waste of time. YouTube is the Nu TV. How can we be so socially inept in an online world full of opportunities? Can’t these kids learn python instead of spending countless hours on YouTube? The promise of sharing has turned into a promise of “check this out, dude!”. In just one click! Somebody must have a patent on “an apparatus for one-click check-this-out-dude”. I am surprised nobody has invented the YouTube Remote yet…

Online time-wasting has expanded from its traditional form to its latest incarnation: moving pictures. The transition went unnoticed: the contemporary brain handles moving pictures well. Its primary goal: escapism. Netizen’s neuron topologies trigger signals promoting new and improved flavors of escapism. Online drooling. Online giggling. It is Matrix meets Teletubbies.

Video content makes the reader stop and pay attention. Web browsing isn’t like antiquing: you are one click away from another location and there’s so much online junk that netizens move fast. Yet, we tend to stop when we see moving pictures. Video content provides a multisensory experience that we enjoy. Moving pictures are still a new ingredient in the web browsing experience. Yes, we are still far from a fully interactive online experience, probably because we are as socially inept online as we are in real-life. This clearly isn’t only a technical issue: humane user interfaces were born almost 10 years ago. It’s mainly a social issue.

So instead of making this a better world by writing python code (shame on you!), here you are “surfin’ the web”. You land on a Killer Tart-Up home page. Instead of the usual “Welcome to Easy Product 2.0! My Mom can use Easy Product 2.0! Everybody at the beauty parlor is talking about Easy Product 2.0!” schpiel, you get a video. The video kicks in, without asking your permission. Your brain goes “whoa, something to chew on!” and you let your index finger be for a few seconds. The mouse button cools down a bit. Then, it suddenly happens. Enter “Easy Mascot 2.0” telling you everything you wanted to know about Easy Product 2.0 but never dared to ask. That’s when you start drooling 2.0 and giggling 2.0.

As much as I find these techniques almost insulting, they are not necessarily evil nor stupid. They are interesting because (when properly implemented) they manage to tell you the essence of Easy Product 2.0 in less than a minute. You end up knowing enough about the product before you even get to actually see the real thing. You even learn how to use it! From the content producer’s perspective, producing this content is a valuable exercise: you have to prove how easy Easy Product 2.0 actually is. In one minute. If you have a hard time producing such content, you have a serious problem. It means that you have to go back to a pub and start doodling ideas on napkins, because Easy Product 2.0 actually isn’t.

An example of a job well done is Google Map’s Street View video. Street View is one of Google’s most technologically advanced online products. It probably scares the average netizen. Google Fights The Future(tm) by adopting the Matrix Meets Teletubbies recipe, producing an impressive minute-and-a-half video that you can share with your Net Dudes™ (infringing that hopefully-fictitious one-click check-this-out-dude patent). Google does a particularly good job at delivering a humane interface on top of its amazing technology, and this video works. Chapeau!

While sentient 2.0 agents drool on YouTube videos, what’s a blind agent or user supposed to do with moving pictures? How do you make the content accessible? Are we going to start a new Video Embed Cage Match ensuring that embedded videos degrade gracefully? Are we going to hear conversations on Unobtrusive Videos at Starbucks©®™? A <vid> tag anyone? If video was a first-citizen in HTML… if Google Image Labeler was extended to video… in a frame-by-frame basis… if YouTube maintained all the metadata found in movies (IPTC, custom metadata, Cozimo annotations, etc.)… maybe our socially inept moving-pictures environment would become a bit less inept. Maybe it’s already the case and I’m not aware of it, probably because it’s all explained somewhere in a video hosted in YouTube… 😉

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.

Web fast-forward

August 8, 2007

Here is Vint Cerf’s refreshing look at how the internet came to be and a glimpse at what lies ahead.