October 6 Panel Follow-up

For those of you who attended the Business First Power Breakfast: Online Networks this past Tuesday, October 6 and have reached out to me to offer feedback and ask questions, thanks for your interest and thanks for coming. I was thrilled to see a room full of keenly interested attendees.

Based on some of the questions I have received since then I'd like to make a few comments.

First, the Social Media Revolution video I posted Tuesday afternoon is not mine. I had nothing to do with it, it was playing when I got there. It's a great overview of the growth of social media and other online technologies, but it isn't mine, I just embedded it so you could view it here in case you forgot the title.

Second, some of you realized, in retrospect, that the guy you saw taking photos of the food with his cell phone camera was me. I am surprised how many people caught on to my comments about food photos and I know some of you went looking for the photos on my Twitter feed. Unfortunately, because I use Brightkite for my photos (which posts to Twitter) and because Brightkite went down that morning for a massive upgrade (and still hasn't come back up), those photos never made it out. So I've dropped smaller versions of them below.

Social Media Revolution Video

If you attended the Business First Power Breakfast: Online Networks event this morning where I was a panelist, then you saw the Social Media Revolution video at the beginning and end of the panel. In case you didn't catch the address or title, here's the video.

If you were at the event this morning and came here as a result of hearing me speak, thanks for coming. If you weren't at the event this morning then you had better get me in to speak to your organization already.

List of URL Shorteners Grows Shortener

One of the many URL shorteners has announced that it is shutting down in just under three weeks. Cli.gs has announced, via its blog, that it will no longer accept new URLs to be shortened as of October 25. It will also stop logging analytics. Cli.gs will still forward URLs at through November, but no guarantees have been made beyond that. Since Cli.gs has been a one-man show serving tens of millions of forwards a month and the site owner is funding it from his own pocket, it's not too much of a surprise

Back in early August another URL shortener called it quits, Tr.im. The argument Tr.im posted on its page was essentially that there is no way to monetize URL shortening and without money to be made, it's hard to justify further development. Tr.im committed to supporting their Tr.im links through December 31, 2009. However, shortly after that post, Tr.im claimed to be resurrected. Since that announcement, Tr.im has started its progression into an open-source community owned endeavor. Its success is now at the mercy of how much time developers are willing to donate.

Both URL shorteners have, either directly or indirectly, referenced the lack of revenue from their business model, the number of competitors, and the fact that Twitter has standardized on Bit.ly, making it the de facto leader in the Twitterverse, and by extension, much of social media.

URL shorteners work by taking any URL that a user provides and returning a much shorter address that users can paste into a tweet (renowned for the 140 character limit), email messages, or other places where a terribly long link might be cumbersome. Some of them just redirect users right to the target page while some, like the not-so-short Linky.com.au, load the target page into a frame with their brand (and statistics and other link information) sitting at the top of the viewport. In the future, this brand area could be used to serve ads, possibly generating revenue.

The major complaint with URL shorteners is the fact that users cannot always see where the link will take them, which can be a boon for all those fake Twitter accounts trying to link users to porn (sorry, pr0n). This has led to browser add-ons or Twitter applications that can extend the URL as a tool-tip before clicking and being surprised by a screen (and speakers) full of NSFW content.

My additional complaint is that URL shorteners, and specifically their demise, leads to link rot on the web. If any of these services were to shut its doors tomorrow and stop all redirections, the links using those services all become dead-ends. In the case of tweets, we're talking about millions and millions of tweets that will become nonsense (moreso than many of them are now). For emails, articles, or anything else that relies on these URL shorteners, they also become orphaned references without context. If the Mayans had it right, that could be the End of Days we're all expecting in 2012.

Even if you don't believe in the great Linkpocalypse, you should take a few moments to read up on link rot at Wikipedia (an article which is sadly devoid of any mention of URL shorteners).

Facebook and Google Want to Translate Your Site

Translations for Facebook Connect

Earlier this week Facebook announced a new service built on the Facebook Connect API called Translations for Facebook Connect. In general, the idea behind this tool is to allow developers the ability to translate a web site (into a language currently supported by Facebook, 65+ right now,) by crowdsourcing the translation itself. Leaning on their own experience letting users translate the Facebook user interface, Facebook is essentially opening its translation workflow process to the world.

From the How It Works portion of the announcement:

After you choose what languages you want your site or application to support, you can get help from the Facebook community to translate your site, as we did, or you can do the translation yourself, or make a specific person the administrator of the process. [...] Once you register content for translation, your connected Facebook users can start translating your sites' content just as users helped translate Facebook.

Facebook has also created a new client-side featureset, using their XFBML framework, to allow developers to automatically submit content wrapped in a fb:intl tag for translation and to allow translators to translate the content inline. Facebook has put together a simple demo to show this in action.

The Facebook Developer Wiki article on internationalization outlines the process from start to finish. Here you can see that the process isn't just one of machine translation, but that a site owner must designate content strings (pages, words, phrases, UI elements, images, etc.) that are to be translated into a language selected by the site owner. The article also provides samples of how a translator might perform bulk translation or inline translation with screenshots showing orange underlines and menus that appear on a right-click to perform the translations.

The most important part of this tool, however, isn't the technology but instead a fundamental understanding of the process of translation. Facebook has a pretty good article on Internationalization Best Practices that at least presents a primer to those who have never been through this process, gleaned from Facebook's own experience translating its site. This addresses, albeit without a lot of detail, some of the pitfalls those of us in the world of localization have experienced, such as the tendency for translated phrases to contain more characters than the original phrase (which can mess with a pixel-precise layout), or choosing general phrases to leverage throughout the site instead of translating similar but different bits of words over and over.

Caveats

Unlike machine translation, humans are performing the translations, greatly increasing the likelihood that they will understand context. However, there are many conditions that must be satisfied or assumptions that must be made to implement this set of tools...

Does the web site attract users who are fluent in another language (the desired language)? If the site isn't already in the native tongue of a user, why would he/she be there?

Are these users willing to help translate your site for free? Given the concept of "you get what you pay for," there has to be a consideration for the quality and skill of the translators who take it upon themselves to do this work.

Is the translator a subject matter expert? You may not want to have just anyone translate your site about widgets. Widgets may require some very technical language that a casual reader may not grasp and may not understand in context. Words that are mundane in daily use may have a very specific meaning in the world of widgets and might not suffer a loose translation well (or perhaps aren't even supposed to be translated).

Is the translator part of your target audience? It's one thing to understand Portugese because your are from Portugal. It's another thing entirely to translate into Portuguese for use by Brazilians. Understanding the region, dialect, and local idioms can be very important for a proper translation (which is why we call it localization).

Are the site owners comfortable letting unknown third parties translate their message? Tag lines, marketing lingo and other carefully crafted content usually doesn't translate easily. Even with an approval process in place, it may take many passes to get site owners confident with a brands translation in language they do not speak.

Does the site already have Facebook Connect enabled? If not, then time must be taken to add the appropriate code to each page of the site to be translated.

Is time budgeted to identify content for translation? Somebody has to walk through the entire site (or at least any pages to be translated) and mark up the content for translation using what may be arcane XFBML tags.

Does the user even allow Facebook Connect? If your ideal translator doesn't want to log in to Facebook Connect on your site, then all this is moot. The user/translator has to trust both Facebook and your site, and feel altruistic enough to want to help.

Google Web Site Translator Gadget

The day after Facebook announced its new translation tool, Google reminded us that it has been doing this for a while by announcing its Web Site Translator Gadget. The Google widget works by providing a web site developer with a block of HTML and JavaScript to drop on the page of an existing site. This code draws the menu that allows the site to be translated. You can grab the code at the Google Translate Tools page. It currently supports 51 languages.

The Google Translator Toolkit powers this machine translation tool, and while Google states that the toolkit learns from corrections to translations provided by users, it's still just machine translation without human intervention. It's also far easier to implement on a site and doesn't require much overhead. As an aid to the user, when the mouse hovers over the translated content, the block of copy is highlighted and the original content is displayed using a "tooltip" (or the title attribute of the element).

The Google Translate human intervention cycle

Because Google Translate has been around for so long, many users are accustomed to the quirks and know better than to rely on it to translate marketing content or poetic prose. Where it excels is in quickly allowing a site visitor to get the gist of a page, understand an address, or otherwise grab content that isn't so intertwined with a need for context that a user can glean some use.

Please understand that I am not referring to the "Translate" feature that was added to the Google Toolbar for Firefox as of yesterday (October 1). That is a client-side function that operates independently of the web site owner and I am only addressing translation features that a web site owner might want to implement to translate his/her site.

Caveats

Machine translation is a risky endeavor. Even the most robust natural language processors have trouble with elements of language that humans understand naturally, such as context, ambiguity, syntactic irregularity, multiple meanings of words, etc. An example often used in this discussion is evident in these sentences:

Time flies like an arrow.
Fruit flies like an apple.

The words "flies" and "like" have completely different meaning between sentences. Only our knowledge of the metaphor and the bug allow us to understand the differences without further context. As my brand manager for me, I took the introductory paragraph from my web site (excuse my ego, in case you hadn't noticed it already):

I am a founder, partner, and Senior Usability Engineer at Algonquin Studios, responsible for bridging the gap between the worlds of design and technology. With experience in both, I bring a unique perspective to projects, allowing both design and implementation to merge seamlessly.

I translated it into German and then back to English:

I am a founder, partner and senior usability engineer at AlgonquinStudios, responsible for bridging the gap between the world of design and technology. With experience in both, I bring a unique perspective on projects, up so that both design and implementation to proceed smoothly integrated.

We can see it does pretty well for the first half of the paragraph and then it falls apart. This experiment is inherently unfair, of course, but it does demonstrate some of the risks with machine translation. It becomes particularly problematic when proper names that correspond to common words are translated.

Which to Use?

Machine translation is a risky proposition at best. You have no control over what content will come back to your end user. Adding a Google Translate feature to your site can give the appearance to some users that you have effectively signed off on the content. If that's not a concern, perhaps because of the nature of your site (fan site, personal site, etc.) then it's certainly your cheapest option. If you have a business site then this may not be the right path for you. You may still want to link to the Google Translate page to let end users perform translations on their own. At that point you have set an expectation that this is not a serice you provide and you are not responsible for how bizarrely an idiom may be translated.

Crowdsourcing your translation may sound like a better idea simply because you now have humans making decisions about what makes sense in the translation, but you have to take into account the caveats above. Are you prepared to pay for (or spend) the time preparing a site for translation and then babysitting the process, hoping the entire time someone with enough linguistic skill will come along and translate it?

This is where I would lean on a third option. Hire professionals who have done this before. If you are talking about translating your corporate brand and message, then you shouldn't leave it to machines or the waiting game of altruism. If you just want to translate a personal site, a fan site, or perhaps a strong community site (like Facebook), then either other option may work well for you depending on what you can commit. It may even be worth considering Google for the short term option while waiting for the Facebook option to pay off.

Come See Me: October 6

I will be one of the panelists at the Business First Power Breakfast: Online Networks, this coming Tuesday, October 6, 2009 at 7:30am at Salvatore's Italian Gardens, 6461 Transit Rd., Depew, NY 14043 (map below).

From Business First:

ONLINE NETWORKS - Facebook * Twitter * LinkedIn * YouTube - MAKE THEM WORK FOR YOU!

Are you the social type? Are you networked? Join us for breakfast to learn how to advance your career, products and services through online social networks.

Our panel of experts will help you learn:

• the distinct differences between the top online social networks
• to strategically build your brand
• how to grab people's attention and creat buzz online
• potential pitfalls- and how to avoid them

The Power Breakfast panel of experts will first answer questions posed to them by Business First. This will be followed by questions submitted by members of the audience.

Panelists:

• Brett Burnsworth; Zoodle Marketing
• Brad London; RescuedSites.com
• Mary Beth Popp; Eric Mower and Associates
• Adrian Roselli; Algonquin Studios

Read up on it and register at the Business First site.

View Larger Map

Microsoft Doesn't Like Chrome Frame

As if anybody is surprised, Ars Technica reports that Microsoft recommends against Internet Explorer users installing Google Chrome Frame citing security concerns.

As I blug (I like that better than "blogged," for now) on Tuesday, Google Chrome Frame is a plug-in for Microsoft Internet Explorer that essentially instantiates the Chrome browser inside Internet Explorer.

Microsoft was quick to get the following statement to Ars Technica:

With Internet Explorer 8, we made significant advancements and updates to make the browser safer for our customers. Given the security issues with plugins in general and Google Chrome in particular, Google Chrome Frame running as a plugin has doubled the attach area for malware and malicious scripts. This is not a risk we would recommend our friends and families take.

While a piece of malware may have two things to attack now, it would have to circumvent both Internet Explorer's security measures and Chrome's security measures in an attack. Given that Chrome was the only browser to make it through day one of the Pwn2Own hackfest in March, and given feedback from one participant stating its sandboxing feature posed a formidable challenge, it seems that it might be a while before someone even tries again. There is some debate about whether people didn't try as hard given its small market share. Nobody has said yet whether the Chrome Frame implementation differs enough from Chrome that an exploit could affect both in the same way. If users upgrade to IE8, considered very secure by many, then the issue may be moot. At that point, however, users on IE8 who install Chrome Frame are more likely to be trying new features instead of using it as a workaround to outdated browser features and support.

The big question is, how long before Microsoft changes its plug-in architecture in an IE update (for security reasons, I'm sure) that essentially disables Chrome?

Google Chrome for Internet Explorer

A Brief History of Time Spent on IE

For years web developers have struggled with browsers that don't support standards or the latest innovations and that just won't go away. Internet Explorer 6 falls into this category and is the bane of many a web developer's existence. Internet Explorer 6 rolled out in late 2001 and stuck around, essentially unchallenged, until late 2006. Since then we've seen Internet Explorer 7 come and most recently Internet Explorer 8 in late 2008.

Unfortunately Internet Explorer 6 is so firmly entrenched that as of August 2009, it has more market share (13.6%) than Internet Explorer 8 (10.6%) according to W3Schools (other browser tracking sites verify this). Internet Explorer 6 beats out Chrome (7.0%), Safari (3.3%) and Opera (2.1%) combined and is right behind Internet Explorer 7 (15.1%). Reasons for this seemingly intractable position range from IT department policies against upgrades by users, to applications built exclusively for Internet Explorer 6 (precluding an upgrade without a rebuilt), to users on older systems who don't know how, or don't care, to upgrade.

So for nearly 8 years we've struggled with an outdated browser, only being replaced by updated versions of Internet Explorer that take moderate steps toward enhanced standards support, such as CSS level 2, HTML5, enhanced JavaScript support, and just better stability overall.

Some sites have taken matters into their own hands. YouTube prompts IE6 users to upgrade to Chrome, IE8 or Firefox. Digg ran a survey of its users to plot out a strategy to deal with IE6. Brighkite tells visitors using IE6 that the site will look terrible and to upgrade. Just search for "IE6 must die" and start to peruse the 1.8 million hits.

Google Chrome Frame

Google has taken an ingenious approach to deal with Internet Explorer 6, 7 and 8 and their general lack of standards support. It has found a way to embed Chrome right into IE.

Google Chrome Frame is an open-source plug-in for Internet Explorer versions 6, 7 and 8 that essentially embeds an instance of Google Chrome into Internet Explorer. Doing this will allow users surfing in IE with this plug-in to take advantage of HTML5 elements not yet supported in IE and also leverage Chrome's faster JavaScript engine. This is currently an "early-stage" release and intended for developers and testing, so there is no guessing how well it might work on your platform.

Google has a vested interest in getting this to work — Google would love to get Google Wave and other Google applications up and running on a stable platform, and since Chrome won't have the market share immediately, IE is a reasonable platform to target. The Chromium Blog entry for today explains a bit more:

With Google Chrome Frame, developers can now take advantage of the latest open web technologies, even in Internet Explorer. From a faster Javascript engine, to support for current web technologies like HTML5's offline capabilities and canvas, to modern CSS/Layout handling, Google Chrome Frame enables these features within IE with no additional coding or testing for different browser versions.

The Google Blog entry for Chrome Frame has the following video embedded with a Google employee (wearing a Threadless t-shirt, I sense a trend) walking viewers through the basics:

Making It Go...

To initialize the Webkit-based rendering engine users will need to embed the following meta tag on a page (Google links to the Microsoft article addressing how to use a variation of this tag that tells IE8 to emulate IE7):

meta equiv="X-UA-Compatible" content="chrome=1"

For pages/sites where you cannot modify the meta tags, Chrome Frame allows you to initialize it by pre-pending a URL with cf:. If you want to visit my site in Chrome Frame, you'd go to cf:http://adrianroselli.com/. Google provides more information for developers, as well as a client-side detection script for Chrome Frame, at its Developer's Guide.

Testing Chrome Frame on my own site from Internet Explorer 7, I can see that it changed the user agent string by adding "chromeframe." The new user agent string from my IE7 install reads (emphasis added):

Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; chromeframe; .NET CLR 1.1.4322; InfoPath.1; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; MS-RTC LM 8).

So What Now?

Will this truly usher in new life for IE users? If a user cannot install a new version of IE on his/her system, will he/she be allowed to install the plug-in? Will the average user even care? What logic can be written to prompt a user to download this plug-in (outside of the examples they provide)? These and many other questions are still to be answered, but since Chrome Frame was just announced today, it's not unexpected.

Even if a user does go through the trouble of downloading and installing Chrome Frame, developers will need to come up with metrics to determine the market share of this browser-within-a-browser. It may be hard to evaluate whether or not users are taking advantage of its functionality by reviewing your site statistics, at least not without spending time parsing out the "chromeframe" string. Instead developers may be stuck relying on other developers actually implementing the features to see if anyone is using it, and we all know that site statistics from one site aren't necessarily a good indicator of how those numbers will play out on your own site.