views:

132

answers:

1

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?
+1  A: 

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.

Charlie Salts
Charlie, thanks for your answer. If I understand you correctly, you would create a template-XUL-file for the order form, and then modify it to meet each customer's need. But how would you change the XUL-template so that these changes apply to all modified versions?
Bob
You need to figure out what your default is "everything shown" and the custom XUL hides fields or "everything hidden" and the XUL enables only what's needed.The base XUL would define all of the available fields.
Todd Smith
So this would actually result in the XUL file being a configuration file enabling or disabling fields?
Bob