One of the biggest advantages of developing web applications as opposed to desktop applications is their often short development cycle. Lightweight development methodologies with short iterations (development cycles) allow for the developers to react more rapidly on feedback from the customer and the product’s users. There is a relatively short path from when a feature is suggested until it can possibly be implemented.
As both desktop applications and web applications grow in size, it gets increasingly harder to react rapidly towards customer feedback in order to point the developer’s attention in the right direction. As applications grow bigger, a small change to the software can possibly effect many parts of the whole application, why each new feature gets increasingly cumbersome to release as the product grows in size.
To be able to react to changes in its environment, the application should always be the simplest possible implementation possible.
At times, the fundamental requirements of the application go against the goal of always having the simplest possible implementation. To stay agile, this dilemma needs clever and flexible attention.
At motigo, we have services that originate from multiple countries. Motigo Webstats was originally nedstat – a Dutch website, and Motigo Forums, Motigo Guestbooks and Motigo Shorturls were originally webtropia products – a German website. This means that our primary users are from the Nederlands and Germany – thus we have a need for more than just one language.
We currently have everything in 5 languages. This has put a serious barrier for us to be able to make rapid changes and react rapidly upon feedback. Every time we want to make a new screen, or just make changes in the existing practice, we need translations in all of the 5 languages that we currently support. This means that many changes that has been thoroughly tested and are ready to go public have to wait several days for our translators to finish their job.
A clever and flexible solution to cope with this problem in all contexts is still something we aim to find. If any of you have any experience with this, we would love to hear from you. However, for changes that have to do with presentation, we already found an approach that works fine.
As an example, in our process of redesigning the front page, we started out making the changes visible only when you had chosen English as a language.
This proved effective, as we had made several changes based on user feedback even before the first translations rolled in. If you’re quick, you can even see that at the moment, it is only for English, German, and Dutch, that we have the new frontpage banner implemented. For French and Spanish, the old flashy banner is still showing.
When starting out by only implementing changes in English, which we (the developers) are all fluent in, we can again start to react rapidly on feedback instead of having to wait 4-5 days for all translations in all 5 languages.
As our plan is to implement 7 more languages (12 in total) in the new future, the dilemma will become increasingly more important to cope with in a clever way as we move along.
Again – if any of you guys have any input about our dilemma with wanting to push the features out to you as soon as possible and still having 12 languages to cope with, then please comment this thread and let us know.