Global Beach » Project Management

Babel, 2010

Anna — Thu, 11 Nov 2010 14:32:22 +0000

I am a Hungarian living in London, so not only do I get to be the subject of the “hungry Hungarian” jokes (yes, very funny), but I also get to witness a lot of use and misuse of localization.
On Facebook my News feed comes in a whole variety of languages. I am fluent in some, in others I piece the puzzle together. Then there are languages I don’t understand at all. Variety delights me, but I must admit I do feel a bit left out. Should I copy-paste it all and see how Google translator deals with it?
Sometimes I get strange characters or even little squares instead of a few or all of the foreign characters. Sometimes that frustrates me.
Even switching from language to language on a site can be awkward, it’s unclear why some pages are translated and others aren’t. As I continue to work on localization I realize how difficult it is to get it right. So what to do when asked to publish pages that are only half translated? Should the Terms & Conditions be in the given language or remain in English? And how about ‘Unsubscribe’?
There are website translations that are plain awful, and a general understanding seems to be missing: it’s not enough to get the translation of the content right, you need to localize for the web. Perhaps the point is to get people to learn languages properly – is this why seemingly so little effort is made to facilitate a more comfortable journey for foreign users?
Some sites offer a whole variety of products and services, but only at check-out, after they’ve got all your details do they actually tell you that you, poor bastard, cannot access the services from where you live and sorry, shipping is restricted to only a few privileged countries (not yours!).
I wonder why the owners of half-way localized websites sit back and relax, but as I said before, I like variety. Although, a trifle of professionalism would not hurt either – the aim should not only be to have a quality translation of the content, but to get developers, designers and project managers involved in the whole localization process and to thoroughly consider usability questions as well. Oh, and feel free to share your experiences about the above – I am always happy to expand my little collection of nuisances.

Could it be Magic?

Stuart — Mon, 11 Oct 2010 08:50:37 +0000

As well as liking it ‘not a lot’, the mini-magician Paul Daniels used to end his magic shows with the phrase ‘that’s magic!’. I tend to use a similar expression these days when asked how a proposed solution is going to work. The conversations tend to go something like this:

Client: So how’s the reverse ratchet flux capacitor engagement system actually going to work?
Me: Magic
Client: Great, let’s build it.

I could substitute the word Magic with a details of how the flux capacitor engagement system will use a quantum tri-state to maintain a parallax field while pushing phased particles through a cloud substrate but the client really doesn’t care. That’s the wonderful thing about technology and perception of technology these days. People’s expectations are higher, yes, but people generally have much more trust in technology’s ability to perform.

One of my first commercial web applications was on online jobs site for a national newspaper that allowed recruiters to upload job postings and users to search and view them. Back in 2001 this required what seemed like endless meetings to discuss and document the technical platform. Everything from network redundancy and fault tolerance to the architecture of the COM components that would be written was documented and had to be reviewed and signed-off by the client. We probably spent as much time writing technical documentation as we did writing code – and the client was happy to pay for it to get the reassurance they required and the belief that should something go wrong, they had their arse covered!

Fast forward to 2010 and although now longer involved with the same national newspaper, similar scale projects for similar clients no longer require anything like that level of technical documentation. That’s not to say that similar planning exercises do not happen behind the scenes, they do, it’s just that clients tend not to want to spend their money on reams of documentation that will never get read, and, more importantly, have much more confidence in technology’s ability to deliver. They no longer have the need to understand (or even try to understand) the ‘how’, and are happy to concentrate on the ‘why’ and the ‘when’. Any reassurance or due-diligence required is (and should be) focused on usability and design rather than technical ability.

Very few people try and understand how iPlayer works, or how Facebook uses memcached to achieve such a high level of performance, they are happy to accept that they ‘just work’, or are, as I like to put it, ‘Magic’!

Here we go gathering requirements in… October

Stuart — Fri, 24 Oct 2008 15:57:35 +0000

I managed to get sight of a proposal from a competitor last week for a piece of development work that we eventually won and was suprised that they were advocating a waterfall style approach with a pretty comprehensive up-front requirements gathering and specification writing stage. Now whatever you may feel about the pros and cons of Agile, surely nobody really still believes that months of requirements gathering and specification writing is the most cost-effective way to build a web site?

The process of gathering requirements and system design is always thought of as a pretty linear process. The theory goes that as you gather more and more requirements you are better equipped to organise them and create the perfect system. Basically the relationship between understanding and time is one-to-one. A bit like the graph below.

Linear requirements process

If this was the case then it would make sense to spend the necessary time gaining a complete understanding of the system. Not only is each quanta of time (let’s say a day) worth the same, if you spend enough of them you will eventually get to a state of perfect understanding which will allow you to go off and employ a team of developers to build the perfect system without any further thought.

Now everybody knows that this doesn’t actually work in practice and however much effort you spend designing a system there will always be things that for whatever reason don’t quite work in the real world. Not everyone is quite so keen to admit that the theory is flawed so normally the blame is put on the implementation of the process:

“We really must make sure our design is more comprehensive next time.”

In reality the process of gathering requirements and system design is not linear. There’s normally a pretty steep curve at the beginning of the process as you get an idea of the core requirements and this tends to level off the more time that is spent. Arguably you never really get complete understanding and you can certainly never design the perfect system.

I think the curve looks a bit like this one:

Actual requirements process

So, there comes a point where it’s not really worth gathering any more requirements or spending any more effort designing the system as each day that is spent brings less and less extra knowledge.

Common sense tells you that you should stop trying to increase understanding at a point when the curve starts to level off and start building something.

When to start building

The trick is knowing how long it’s going to take to reach that point, recognising that you’ve got there and knowing what to do next…