🚀 go-pugleaf

Here are the consolidated answers for Pieter Groen's original question:

> Recent discussions on INSOFT-L have mainly focused on translations.
> I'm a user-interface designer and have another problem when designing
> (what we call within IBM) "common" i.e. international interfaces.
> How are your experiences with adapting interfaces to specific cultures?
>
> I'm not talking about "generic" interfaces like text editors, but more
> task oriented interfaces, products that help people do their job, for
> instance process an order.
>
> In France a person would be assigned to a specific customer (group)
> and this would be his or her little kingdom, while in Germany it would
> be structured horizontally. One person would be registering all invoices
> and another one would keep inventory, or be responsible for fulfilment
> etc. Both groups need a different interface, which support their way
> of working.
>
> This is just an imaginary example. But is anybody of you seeing any
> patterns, and how do you solve this problem of adaptive interfaces?
> Have an object-oriented design?


Jeff
INSOFT-L List Manager

*========================================================================*
 Jeff Bowyer                         EMail:
 Computing Center		     jbowyer@cis.vutbr.cz
 Technical University of Brno
 Udolni 19, 602 00 BRNO
 Czech Republic
*========================================================================*


Sender: Stanislav Fritz <stanf@microsoft.com>

Object orientated or even very modular helps.  The GUI (or front end in
general) should not be too dependent on the rest of the code.  Abstract
it.  In your example the main work is the database effort.  The
interface could be changed to suit the user.


Sender: Dick Schoeller <schoeller@gooey.enet.dec.com>

Pieter,

I would assert that this really has little to do with I18n.  Different
departments within a single company, different companies in the same location,
etc. may have widely varying views of the tasks and distribution of
responsibility involved in almost any process.  The inverse is also true.
You may find that completely unrelated companies in unrelated industries have
similar views of common processes.

This turns out to be the classical problem in system design.  Matching the
system to the needs and desires of a variety of pontential customers.  I am not
convinced that OO design would necessarily aid or hinder your attempts to make
your system flexible.  Modularization of the pieces of the application.  Making
operations atomic and easily arrangeable into any combination for varying
distribution of work or varying process needs.  OO is good at this but so
are other design methods.  Understanding what tasks might be prerequisits for
others is key to determining what flexibility there is in the system.  The