The 'Coltrane' release of Lotus Freelance Graphics, the 1998 version bundled with Lotus SmartSuite, was famously held up for a month when it was found out that one of the clip art images had a tiny 20-pixel image of Taiwanese currency (rather than mainland Chinese currency). Or was it the other way round? An eagle-eyed QA engineer had discerned the offending image. Needless to say, this was something that would cause offense and/or affect purchasing decisions in the involved markets.
I was a little canary in that Freelance mineshaft (or was it a minefield?) when a couple of months earlier in the project I had discovered a seriously outdated map of Africa when integrating new clip art into the product. I wrote one of the sprs of which I am most proud titled something like: "Upper Volta should be Burkina Faso". The spr also made a brief mention of the fact that as far as I could tell there were similar problems in our maps with the names of the states from the former Soviet Republic which had changed earlier in the decade. I believe that my spr was deferred to a later release; it was too late in the product cycle and we'd have had to go back to the company we licensed the art from and so forth. As it turned out however, with the advent of China/Taiwan flag issue, the entire suite was delayed as the test team had to painstakingly go over all the clip art and other areas of the product vetting for similar outrages that could endanger sales.
Incidentally the acronym, spr, stands for "Software Problem Report" in Lotus's parlance. After a decade of indoctrination, I still tend to use spr rather than the more clinical, "defect", which is the favoured term at IBM, or "bug" which is the more widely-used term generally. You can still tell whether someone has the "old Lotus" DNA rather than the "new Lotus/IBM" variety by the terminology they reflexively use. For a dissection of recent linguistic trends in technology see this earlier post.
As a further aside, the Lotus spr database is actually one of the most successful and useful applications of Lotus Notes technology ever and in a similar manner, the Bugzilla project is actually one of the best things to have sprung out of the Mozilla effort. Certainly it was more useful than the Mozilla Gecko browser suite (mother to the Firefox) until the M7 milestone was reached years ago. There must be some kind of software law at work here, something analogous to Zawinski's Law on "software expanding until it can support email" (and now feed technology) and so I'll coin it as Koranteng's First Law of Software Systems:
A software platform reaches its tipping point once it can serve as a bug reporting system.
Intuitively this makes sense, once developers can view, file and retrieve bug reports using their own products, they will be more likely to use them and their confidence in their mission will improve dramatically.
Back to my topic though... I'm sure that the artists who created the clip art in that design firm had no subversive intent; they probably used outdated stock art as their source material. Still, sometimes you wonder at these things and, in this vein, I'm reminded of the Nobel Prize-winning Portuguese author, Jose Saramago's wonderful novel,
The History of the Siege of Lisbon, in which a copy editor proof-reading a historical novel defiantly changes a crucial word in the text changing the outcome of a famous historical battle from a miserable defeat to victory. A masterful alternate history of Portugal then develops and its culture is fully re-imagined. I'm sure that bored developers sometimes slip similar things into their products, and not just serendipitous Easter Eggs.
More seriously though, the Freelance incident (or similar incidents relating to any new release of dictionaries or thesauruses from Microsoft) go beyond the cultural sensitivity of which this post is concerned into the rarefied realm of political sensitivity. The same thing goes when choosing product names: you don't want mere mention of your product to cause snickering or offense. A misconceived name or culturally-insensitive feature can be a black eye that will chasten even the highest-flying company. More worrying is that this can translate to a serious financial impact (well beyond a month's lost revenue for the suite) if proper attention isn't paid.
Forensic Investigations
Internationalization however is a mostly thankless, and oft-neglected, task even as I've outlined its importance. From a developer's standpoint, you first think about it mostly in terms of dealing with "resource bundles" and having to put all your resource strings into separate files for different languages. This is a pain because you probably started with a little prototype of a user interface and now you're being asked to find all those hard-coded strings in the user interface and to "do the right thing". Plus it typically becomes an issue only late in the game, when the really interesting work is over and you're ready to think about the next big thing. Instead, you're grudgingly forced to worry about handling different writing systems, dealing with bi-directional text, or that old favorite: the various "special characters" in the wide variety of programming languages, file formats, protocols or operating systems in your software. Those best at this task are akin to forensic investigators and must possess considerable patience and attention to detail.
If, for example, your software
mangles names with accents, you'd have real trouble selling in France. Similarly with ampersands and apostrophes - which have significance in SGML and its derivatives (HTML, XML etc). And don't get me started about wider character sets and
encoding issues... As an ironic case in point, while developing
Lotus K-station, one of our best business partners was somewhat stymied in his development and extraordinary evangelism of our product because, in its earliest release, it couldn't handle the ampersand in his company's name. Luckily for us, he temporarily renamed his organization in his corporate LDAP directory;
Sun & Son became Sun and Son until we worked out the quirks. To this day, I always make sure to test whatever product I work on with that organization name. It's surprising though, how often this kind of problem recurs.
The Scene at Home
In this internet era, most technology, and certainly all software development, has to have global concerns in mind. It is said that the sun doesn't set on an IBM project and I work with a very diverse set of colleagues the world over. Presumably the benefit of such a widely dispersed and diverse workforce should be to mitigate the likelihood of issues in this area. As my current project has been going through translation and localization testing of late, I've been thinking a lot about how we handle internationalization.
The old Lotus process was a more decentralized one, each product group had an internationalization team seconded to it. Members of such teams were domain experts and knew the product inside-out in addition to being localization gurus. This had many benefits, the team was involved from the very beginning in the product development cycle and could give crucial design feedback very early and iteratively. Your first prototype was immediately critiqued from their standpoint. The obvious downside of decentralization was the lack of uniform standards - chaos that our translation teams couldn't bear. Some products were very easy to localize, others were, to put it politely, far less so.
As we transitioned to the more centralized IBM globalization process, we got the benefits of uniform standards and greater resources. More languages could be supported in the initial release and you could at least point developers to documentation about the processes they should follow instead of the usual ad-hoc stumbling about. Still this was at the expense of domain expertise, sensitivity and a much slower feedback loop. Some of the test teams would be barely getting up to speed with the product by the end of the testing phase. Localization concerns would sometimes surface too late in the game and would cause much unnecessary reworking and product delays. These things are tweaked, as all processes are, and in recent years, I've seen a push towards re-enabling more domain expertise in the internationalization teams which has been very useful for our product development.
A Photography Case Study
I'll lay out a brief example then that I think is illustrative of the kinds of things we're dealing with here I hope it can tease out the technical, design and business issues that can arise...
I embarked over the past couple of weekends on a mass digitization project and scanned, retouched and uploaded 2,000 or so old photos from shoeboxes under my bed. The technology involved in this exercise was scanner hardware and image acquisition software, the bundled Adobe Photoshop Elements for color adjustment and red-eye correction and a couple of online photo-sharing services: Yahoo Photos and Flickr (coincidentally, I started the day Yahoo's acquisition of Flickr was announced).
The first thing I very quickly noticed: somehow all the photos that I uploaded to Yahoo Photos turned out darker than on Flickr. The services both resize uploaded photos; when you reduce the size of images, you have to select the pixels you are going to use and the photo-resizing algorithm used by Yahoo Photos was giving worse results. This was noticeable to me because a large number of photos featured darker-skinned people such as me. The originals looked fine on the screen and where there were lighter skin tones, everything looked good, but with darker skin tones, the resized photos were not so good. This meant that if I didn't believe in the virtues of Save Lots of Copies Everywhere (SLOCE), I would have leant towards Flickr and stopped using Yahoo Photos.
Secondly, I didn't have Flash installed on my Mozilla browsers hence my experience of the Flickr website was very different from that of my family and friends who started looking at the photos with Flash on Internet Explorer. By default Flickr used Flash to display images. There were immediate complaints about the first bunch of photos. It turns out that images that are rendered in the Flash plug-in have a slightly darker tinge than the images rendered directly by the browser itself. This is not normally noticeable but again this exacerbates contrast issues when darker skin tones are in evidence, as in this case. This was made worse when users tried the slideshow feature because the background of a Flickr screenshow (also implemented in Flash) is black worsening the contrast further.
Thirdly, when retouching photos, the Quick Fix or Auto Correct options in Photoshop seemed tailored for lighter skin tones so I was constantly having to do manual tweaking of my photos. Now this is not a big deal for a few photos and indeed it's fun to fiddle with photos but after a couple of hundred images, it gets tiresome. I found myself longing for "smarter" recognition by the software or for at least, a nice 'dark skin' option that I could set in a preferences dialog. In short I started considering using different software instead of Adobe's.
Now I mention these nitpicks on otherwise excellent and useful products because of the design issues they raise. Technology is simply a tool in aid of people and as human beings we live in different society and cultures. We find that different cultures adapt technologies in different ways to suit local preoccupations and concerns. And I certainly had my own localized concerns these past weeks.
Even when the technical "fixes" are easy, there are design issues and economic tradeoffs that also arise. True, Macromedia could implement better JPEG rendering in Flash but that comes at a certain expense - a good renderer is a hard thing to write (even if they could license the photo-rendering code from the Mozilla folks). Also what they have appears to be good enough for most people (except me obviously). When do you decide that your product is good enough and stop pandering to the
Long Tail? Can you afford to do that? Or are you missing out on a vast market opportunity?
Yahoo Photos could certainly implement a better photo-resizing algorithm although presumably there's a performance penalty to be paid if you use a more color-accurate algorithm (or perhaps a larger resultant image size). At the kind of internet scale that the Yahoo service operates on with tens of millions of users and photos, this could potentially seriously affect the scalability of their platform. Conversely, if all Yahoo users switched en-masse to Flickr, which uses the more expensive algorithms, would that platform be able to handle it? Or would it generate a case of teething problems and turn users off because of poor response times?
Flickr could very easily provide a Javascript and native html browser screenshow alternative to their Flash-driven version (as all the other photo services do). I wonder how many users they are turning away by not providing a native browser screenshow. But they use Flash extensively in the rest of their product and, in the case of the screenshow, its usage serves to more easily prevent people from downloading images. Is this pseudo-
DRM an essential feature in their service? An alternative they could consider is to keep Flash, but add the option to use a different coloured background for slideshows to de-emphasize the kinds of contrast issues I was encountering. Where would that option show up in the user interface?
Similarly Photoshop could implement a slight variant of their various Quick Fix and AutoCorrect features that were more attuned to my kind of skin colour (indeed I assume that photographers in Africa have written macros or filters that do such a thing). How best though, to phrase a global preference in an options dialog in Photoshop? "Adjust for darker skin tones"? Documentation writers would have a field day finding the right verbiage for such an option. Also what about usability? If you add all these preferences to your product what will your user interface look like? Try typing about:config in a Mozilla browser to get a sense of the kind of complexity that modern software developers have to cope with.
If there was a huge market for these products and services in Africa the issues I faced could be a real problem for the companies in question (although this is unlikely given the low internet penetration rates and the likely widespread software piracy). There would be demand not just for local language versions (say a Swahili language version in Kenya) but also for tweaks that would make these services more closely attuned to the prevailing culture and, in this case, ethnic backgrounds.
Thus photographers in Africa over the past 150 years have had to deal with brighter sunshine, higher contrast, as well as darker skin tones when processing their photos as photography has gone through its various evolutions and has now moved into the digital realm. The people who install photo laboratory hardware in Ghana, where I come from, always have to recalibrate their equipment to deal with the kind of skin tones that are present in the local market. The factory defaults simply won't do. I've had better results developing film in Ghana than in the US because I often forget to tell the labs here that they should "watch for skin tones".
I'd expect then that software that were truly local (and all web software should be local or adjustable to fit local concerns) might sometimes need not just run-of-the-mill language changes or even writing system changes but also, as seems needed here, algorithmic adaptations.
As software designers, we try to engineer simplicity and refrain from overwhelming users in their interaction with our services and products. Software is not the user's main focus, it's rather its use that is most important for the user, for the business and for society as a whole. Yet there are very real concerns in the application of technology in different cultures. So the next time you see a vaguely-worded so-called "Turkish option" somewhere in your application's configuration dialogs, know that someone somewhere was likely adapting their product for a local market. Join me though, in saluting the developers, testers, product managers and designers who collectively worked together to come to that solution. I'd hazard that the tweaking of the product was to fix a deal-breaker in some market.
Finally, for what it's worth, I find endlessly fascinating this notion that cultural sensitivity in technology sometimes necessitates algorithmic adaptation. Maybe though, iterative adaptation in response to local environments - evolution in short, is the name of the game. Perhaps that's simply the way things should be.
Crossposted at the
Inside Lotus weblog
Postscript (a year later)
I
reported my issues to Flickr and later prodded them with some
other folktales about their excessive use of Flash. I know I wasn't the only one with complaints but I'd like to think that my slightly different framing of the issue helped tip the balance: a month later, they stopped using Flash to display images and moved to a much lighter weight DHTML user interface. They continue to use Flash to drive screenshows and organize albums which is fair I suppose. To their credit, they expose enough of their internals to allow third parties to step into the breach to provide alternate interfaces if needed. There is still work to do to "fix" Flash rendering but that doesn't concern me much since I don't use it. Adobe Photoshop will be a challenge however. I'll simply note that about 5 to 10 searchers daily come across this article trying to figure out "
darker skin tones Adobe Photoshop" pointing to an unfulfilled need. If that number continues to rise, I'll hazard it won't be long before we see a "dark skin tone" option appearing in the Photoshop preferences.
A Footnote
An revised and expanded version of the essay appears in
The Best of Technology Writing 2006 published under the digitalculturebooks imprint of the University of Michigan Press. It can be
read online along with many excellent articles at
the book's website. It was very exciting to be a part of this and one hopes for some more
publications.
I was asked to come up with a tagline for the article, my take:
Everything is local
File under: technology, history, culture, Africa, race, Ghana, web, programming, design, i18n, localization, software, toli, Lotus, Freelance, K-station, Yahoo, Flickr, Photoshop, best practices, IBM
