What Software Development SHOULD Be Like – The User Interface Rules

I have already written about the whole business rules architecture (see previous blog posts about Object, Object Interaction and UI rules).

• Object

o   Structure

o   Process

o   Data Validation

• Object Interaction
• User Interface

Getting people to think in a “real” Object-Oriented (OO) fashion (describing the rules about their “stuff” that are UI-independent first) seems like a hard road.  There are many different technologies involved and the solution is not immediately available to development teams without a lot of work.

But User Interface rules are different.  Here, we can do this “right” no matter what stack we are using. It works just as well for all platforms… from mobile to desktop.

Solving the mobile problem is a big challenge for many teams since new platforms, technology stacks, resolutions, and devices appear every week.

The solution to this dilemma is to not worry about the technology at all.  Create a repository that describes what your application does and then write a generator to build the application.

To be fair, writing a code generator is quite challenging, but it is only a few weeks or months of work and then you have built not only the system you are working on but you have also created a very nice machine that will make your NEXT development project go production in days or weeks with no bugs.

Here are the steps:

1)       Build a prototype of your application with a few screens. Be sure to think through the entire user experience. Handling multi-record blocks of data nested inside multi-record blocks of data is particularly challenging.

2)       Build a repository that represents the logical design of your application and all its components that looks something like the following

• Application
  • Section
    • Page
      • Panel
        • Component

Then attribute the model.

3)      Create a simple IDE that will allow you to populate the model.

4)      Write a code generator to build the application you want from the repository. You will find that you forgot some things in the repository and will have to update it to describe any additional application elements.

The really cool thing about this approach is that you now have a description of your application that is totally tech stack independent.  You can write different generators to build applications for different platforms without having to touch the logical rules of the application.

At Dulcian, we are using this approach to take a gigantic desktop application (3000 data fields, 1500 data validation rules) and move it to a mobile device.