Programming versus configuration and D2


Deze klanten gingen je al voor

It seems a simple question. Do I code something or do I configure it. A normal no-brainer.
Configuration always wins.

Or is there a reason why configuration might be wrong?

Let me make myself very clear. When you can avoid programming it is always and will always be the best way. But it does not mean that configuration is always the answer to solve the problem.

This is probably something I have to explain and that is what this blog is about.

First I will try to explain the basics:

  • support for configuration is to create an interface that is very easy to use, so that users without any technical experience, but who know what the end-users need, can use their knowledge to make customizations in the application to make it fit the demands.
  • as a configuration demands a standard way to deploy the customization, the configuration approach will help define a controlled change process that makes making changes or even upgrades a less riskfull process.
  • last but not least, configuration gives you the ability to see real time what the customizations in the system are. Behind the scene there might be a lot of code, but the configuration-set should be a non technical representation of all of these lines of code and thereby give that easy overview of the way the system actually works.

Now I come to the new EMC Documentum D2.
First I want to make clear that I love the end result. The end-user interface is flexible and gives a lot of options to fulfill the end-users demands. Having played with the new configuration interface and tried to create two property screens for two object types I’m strugling with the points above.

  • Easy to use interface: a basic config screen in D2 has at least 3 rows of buttons in different locations, that you might use to make a customization. Every screen has at least 4 area’s where you might see or change something in the property-screen. Beside these items on one page there are multiple tabs for this one property page. Sure I understand that D2 wants to deliver a lot of options to customize a property-screen as clients are demanding this flexibility, but where do you stop with adding options in one screen?  Did someone with real user experience (so don’t let someone like me design it…) look at how you should position the different options ?
  • Deployment. As the basic concept is based on the context (or roles) and the functions they can perform and this is managed in one or more matrix table(s), which do not dynamically highlight the row and column your working on, it is really a gamble to know if you selected the correct cell (especially for an almost blind man like me). Even worse, when a role change is mandatory this will mean a full change of the whole configuration
  • And last but not least, an overview of the customizations done. You are able to export the matrices but getting and overview of what will happen with a property-screen based on a set of property values, will force you to open the configuration-page for the property-screen and look in a number of tabs and different regions within the pages and try to understand the impact of all changes.

So configuration versus programming: always configuration, but configuration can also be way to much. I think that it is mandatory to redesign the user-interface of D2 config and create a more wizard like approach that structures and maybe limits to possibilities of configuration. The current solution will probably lead to the same chaos that to much programming will do.

Lees onze andere blogs