We recently completed a project for a new client, Vizzitt. The project had a short duration, a mere four weeks. And the budget was fixed. And the client needed an entirely new site up and running, with a significant number of features. How to do it?
The answers we came up with:
Firstly, a note of thanks to colleague Hal Reed for introducing me (and now you?) to the term deprovement. Hal defines deprovement as “a change that is intended to improve something, but in actual practice makes it worse, e.g., harder to adopt, harder to use, or less reliable.”
In the world of software or Web applications, deprovement is all too often what occurs when a company enthusiastically announces their next release. Today, I was inspired to learn that Mozilla added an honest to goodness improvement in their 3.0 release of the fast growing (and excellent) browser Firefox. Their secret: Version 3.0 is reported to run “more than twice as fast as the previous version while using less memory!”
How many times have you opened the newest release of a software application only to find that the latest improvements and new features have substantially deproved your system performance? This is even more serious for a large scale Web site or Web application. As an industry, let’s try to remember that speed is one of the most important elements of software and Web site usability!
I’m down at the Endeca Discover 08 conference and now I’m all fired up about what’s coming in Endeca. Some very groovy things on the way:
If you’re not an Endeca user, this may not mean anything to you, but it’s pretty exciting stuff. I’ll write a follow up explaining what I’ve learned this week in more detail.
Incidentally, Bit Group has been partnered with Endeca for a while now. And if I have may way, we’re going to be doing more with this stuff. Index everything!
For applications that have not been well structured for internationalization (I18N), the prospect of extracting and then replacing localized strings is a little like removing 30% of the strands of spaghetti in a bowl of pasta and then putting them back where they belong. If that’s not tough enough, each new strand may have to change color at a moments notice depending on who’s eating the pasta.
Even for other applications that have relatively well externalized strings, there still remains a daunting challenge of managing the text extraction, delivery to the translation partner, then reinsertion of translated code. As it turns out, the using the XML Localization Interchange File Format (XLIFF) is a great way to simplify and scale this process while making it much more efficient.
The underlying issue that led to the creation of XLIFF is the problem of format. A translator frequently receives source documents for translation that may be in diverse formats such as Microsoft Word, Txt, HTML, RTF, and XML (with an unlimited variation of DTDs). Translators first have to deal with the challenge of simply reading the source file. This requires identifying and potentially obtaining and installing the right software package. It’s not enough to have Microsoft Word or Adobe Framemaker, but also each translator needs to have the right version of that software. We can only picture the late nights and multi-hour support phone calls required by the IT staff charged with the impossible task of setting up and maintaining these workstations.
“Hello, this is IT helpdesk, how can I help you?”
– “Would you please install Framemaker 6.0 on my workstation?”
“ Pardon me, but didn’t I just install version 7 for you yesterday?”
– “Yes, but that was for a different job, and this file doesn’t open in the new version.”
“So would you like me to uninstall version 7?”
– “I am still working on the prior job, I need both version 6 and 7!”
The problem of format is not just confined to the translator. Publishers and software developers have the challenge of extracting and sending text (strings) from documents or applications for translation. How can you be sure that the sentence or string that you extracted from your source can be reinserted in exactly the same place? In other words, each strand of spaghetti must be uniquely identifiable. The easiest way to do this is to attach little tags on the ends of each strand of spaghetti with some additional information about that strand (like attributes).
Fortunately, there is an organization that is dedicated to solving these kinds of standardization problems. The Organization for the Advancement of Structured Information Standards (“OASIS”) is a not-for-profit consortium that drives the development, convergence and adoption of open standards for the global information society. In February of 2008, OASIS members approved the XML Localisation Interchange File Format (XLIFF) version 1.2 as an OASIS Standard, a
status that signifies the highest level of ratification.
The Bryan Schnabel, the co-chairs of the OASIS XLIFF Technical Committee describes XLIFF very simply as follows:
– XLIFF is “[a] powerful and concise format for content that needs to be translated. ”
For a company seeking to build or better manage a global Web site, XLIFF provides far greater efficiency in the setup and maintenance of content for translation. The XLIFF schema remains stable even if document format changes or software code features change over time. For the translation service provider, XLIFF greatly reduces the complexity of managing source file formats and technologies and allows translation service providers to focus more of their time and resources on the work of translation itself. For both localization customers and service providers, XLIFF also provides workflow metadata providing better communication between both parties throughout a translation lifecycle. In sum, XLIFF greatly simplifies the challenge of selectively removing and replacing multicolored spaghetti from your bowl of pasta.
Recommended Reading
Adobe has released version 1.0 of Adobe AIR as well as the Flex 3.0 platform. I got a chance to work with betas pf AIR and Flex 3.0 on an engagement at MatchMine, and I’ve been looking forward to the final releases for a while.
AIR is a new runtime for building cross-platform desktop applications, based on the excellent WebKit browser engine (which also powers Apple’s Safari browser and the was derived from the open source KHTML engine). AIR allows development of desktop applications using the similar tools and techniques to Web application development: Flash, Flex, and HTML + AJAX. This means that Web developers can transition their existing skills to the world of desktop applications.
Flex is (or rather was, with the release of AIR) a Web application platform based on the browser-based Flash VM. It’s still based on Flash, but the 3.0 release can deploy applications to the AIR runtime as well, meaning that Flex plays in both the Web and desktop domains. 3.0 is an evolution of the 2.0 platform, rather than the huge server seen going for 1.x to 2.0, but the latest release is more mature and capable than it’s predecessor.
Adobe has also taken steps to move the Flex SDK, then free version of the Flex development to tools, to an open source model. Most of the core components are open source now, but there’s still a pretty hefty package of Adobe “add-ons” which are still closed (including the sources for the AIR SDK components). Still, this is a nice first step towards a more open set of tools for the Flash family. More info can be found at the Adobe Open Source site.
Beyond open source, Adobe is providing a wide range of tools for building AIR apps. You can use Flash, Flex Builder, or Dreamweaver to produce AIR applications. There also support for HTML +AJAX development in Aptana Studio. Or you can forgo the Adobe GUI tools and break out your favorite text editor to build apps with the Flex SDK or AIR SDK. The latter is included in the former. These freeware command-line based toolsets provide the bare bones tools needed to build, test and package AIR apps using whichever of the technologies it supports. The AIR SDK is focused on HTML+AJAX apps and the Flex SDK does it all. There’s support for ant as a build tool, which is a nice touch.
One of the most interesting things about AIR and other platforms like it is the explicit support for desktop applications. A couple of years ago, the question seemed to be when the Web would kill the desktop and the traditional OSes. A more rational pattern seems to be returning to the fore and folks are starting to realize that it’s not a question of Web apps OR Desktop apps, but rather an exciting melange of both. There’s a place for both and each type of application fits a certain domain of problems better than the other. And the place where things get really exciting is that area where they meet. Adobe AIR is an interesting take on building desktop apps that can easily leverage the power of the Web, too.