Archive for May 22nd, 2008

Defining a vision

May. 22nd 2008

Software needs to have a vision. A software program can’t be everything to everyone; you’ve got to decide who your users are and what you want to do for them.

I had a very clear vision for Felix (then TransAssist, then “Translation Assistant”): it would be powerful, simple, and get out of your way when you weren’t using it. It wouldn’t force its users to adapt to it; it would adapt to its users.

After all, that’s why I created Felix in the first place. I had been working with a couple of the major translation memory systems out there, and I was appalled at how hard to use and buggy they were, but most of all at how arrogant they were. They treated the translator like some trained monkey who had to jump through their hoops, rather than a professional knowledge worker who had just shelled out $1,000+ to use their crappy program.

Going Astray

Somewhere along the way, however, that vision started to get clouded. It was my fault for not stepping up and handling the marketing of Felix myself. Instead I left that to a company that understood the art of selling, but not of making software. In sales meetings where I wasn’t present, they were promising this feature or that feature; then they’d come back to me and say we had to hold up the next release yet again in order to implement feature X that Big Company Y said they absolutely required. Not quite coincidentally, that feature was usually on some checklist put out by one of the big players in the market.

Fire and Motion

Joel Spolsky describes this kind of feature war very aptly as Fire and Motion. Your competitors put out a slew of features that are useless for 99% of users, much like how an octopus sprays out an ink cloud. By the time you catch up the octopus is long gone, far ahead of you.

Implicit in my desire to finally take over the marketing of Felix was a determination to get back to my vision: simple, easy-to-use software. When you talk to users of translation memory, a lot of them will tell you that they bought their translation-memory program in order to get more work, or because their clients told them to. The classic captive user base. A captive user base is why most enterprise software sucks.

Select and Concentrate

I don’t want Felix to suck. I don’t want people to use Felix because somebody makes them. I want people to use Felix because it helps them work better, faster, and smarter. Sure, not implementing the feature smorgasbord will lose me some users, for whom feature X is a deal maker and deal breaker. On the other hand, keeping a well defined vision should make the software better for my target users.

That’s not to say that I’m not going to add features. In fact I have a big list of features that I’m working on right now. However, my focus is on features that reduce complexity from the user’s point of view, ideally making the program more powerful in the bargain.

Japanese has a handy expression, 選択と集中 – select and concentrate. The idea is that you pick your spots, and focus your efforts there. Rather than trying to be everything to everyone, you become indispensable to a niche that you select. That’s the direction I plan to take Felix.

Posted by Ryan Ginstrom | in Felix | 1 Comment »

Charge for 100% matches

May. 22nd 2008

Translation memory can certainly improve productivity. Many purchasers of translation are of course aware of this, and want some of these productivity benefits passed on to them. This usually takes the form of offering discounts for sentences/segments already in the translation memory, and sometimes for fuzzy matches.

But this can be taken too far. Some clients will ask not to pay for 100% matches or repetitions at all.

On the face of it, it sounds reasonable — it’s already in the translation memory, so why should they pay for it twice? But there are two problems with this. First, it assumes that inserting the 100% matches/repetitions into the translation involves no work by the translator. This isn’t true; even 100% matches need to be checked for context in each situation.

To give a very simple example, Japanese doesn’t have a capital/lower case distinction. So if the same Japanese sentence is used in a title and the body of a section, you need two different English translations for it. One will be in Title Caps and follow English conventions for titles (e.g. leaving out articles), and one will be in sentence caps and follow normal English grammar conventions.

Also, Japanese very frequently elides the subject and/or object of the sentence, and verbs lack conjugation for person and number. On this basis alone, the same sentence can have many different translations depending on the context. He/she/it/they/we [will] put/puts it/them/him/her/us/the widgets on the list/in the box/over there…

The other problem stems from this dependence on context. Because context is so important to a translation, especially between languages like Japanese and English that are very different syntactically, you’ve got to pay a lot of attention to those 100% matches just to keep up with the context. Furthermore, if you’re using a translation memory created by someone else you have to pay even more attention in order to conform your translation style to the memory; otherwise, you’re liable to end up with some unreadable Frankensteinian hodgepodge of different styles and terminology.

It also follows from the above that simply leaving out the 100% matches, and sending you only the “new” parts, is even worse. You’re then left with a disjointed list of sentences and no idea of how the sentences fit together.

So sure, offer a discount for 100% matches. But think very carefully before offering to insert those 10,000 words of perfect matches for no charge.

Posted by Ryan Ginstrom | in translation memory | 1 Comment »
  • Search

  • Categories

  • Calendar

    May 2008
    M T W T F S S
        Jun »
  • Pages

  • Meta