Question

How would the following scenario best be implemented:

There is a standardized user interface for an application in version 1.0, e.g. an order form. This application gets customized to fit the needs of different customers. This could be an extra field "desired delivery time" for customer A, the omittance of the field "phone number" for customer B, an extra map plugin which shows storehouses nearby for customer C and a combination of these for customer D.

Now, the developer releases a new version of the standardized order form, version 2.0. What's the best way to design this to have minimum effort (if at all) to make sure all the customizations done for the customers can be kept alive?

I could imagine the following solutions:

  • Configuration: all the options are configurable. This actually cannot be a solution, as all possible customers' needs cannot be foreseen.
  • Inheritance: customizations are done by inheriting the standardized version. However, how can one make sure the new release doesn't result in an "crappy" looking customized version?
Was it helpful?

Solution

The immediate option that comes to mind is a UI specification that exists outside of the application. When the application is run, the UI is generated at run-time. While this is more work than a static, compiled UI, it is also a lot more flexible in the long run, given your specific software life cycle.

There are frameworks that exist solely for this purpose: XUL is one well-known example.

You could, however, hand-roll your own. Ultimately, this gives you the power to keep your customers' user interfaces separate.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top