Fwd: Customising verbage (& interfaces)

9 Sep 2004 - 10:17pm
5893 reads
Peter Merholz

oops... meant to send this to the list...

Begin forwarded message:

> From: Peter Merholz <peterme at adaptivepath.com>
> Date: September 9, 2004 2:25:39 PM EDT
> To: Michael Bartlett <michael.bartlett at workshare.com>
> Subject: Re: [ID Discuss] Customising verbage (& interfaces)
> I'm surprised no one took this up. I'll give it a whack.
> Let me preface by saying that the quality of the language is probably
> the most overlooked aspect of interface design (and why I disagree
> with Andrei that "visual, interaction, and information design" skills
> are sufficient).
> In observing countless numbers of people using countless numbers of
> sites, the single thing that trips people up more than any other are
> the words.
>> They asked if they could perhaps have some sort of label editor to
>> change
>> the verbage on the dialogs to suit their requirements. This is
>> obviously
>> quite a large engineering overhead to have to externalise all language
>> resources into some sort of XML language library.
> >snip<
>> One thing we do often find
>> is terminology we use on our English clients is not always well
>> understood
>> by our friends on the other side of the Atlantic. What are your
>> thoughts on
>> allowing such customisation of labels and descriptions? Is it worth
>> the
>> investment of having to maintain a more demanding engineering
>> overhead?
> I think their request is *brilliant*.
> I think it's short-sighted to have locked your labels into code --
> they should be part of an externalized
> dictionary/repository/whathaveyou, just for this reason.
> I also think that if you did this, you'd have a remarkable competitive
> advantage in selling your software. No longer would customers need to
> learn your terminology -- they could instead utilize their existing
> language. And, as I'm sure you know, every company has a particular
> way of referring to its things (is it "vacation" or "paid time off"?)
> I would also think that, in the long run, this would reduce
> engineering overhead... When separating code, content, and style, you
> then allow yourselves to focus only on the matter at hand, and not
> needlessly conflate elements, which can lead to some bizarre problems.
> We had a client that, because of the way their web site was served,
> *any* content that needed changing had to be considered a "defect" and
> had to be tracked like a bug, and couldn't be changed until the next
> release was pushed.
> --peter

Syndicate content Get the feed