I’ve been discussing the issue of front ends with Omer, who is an MD who happens to work in Healthcare IT. He is a doctor, and he knows what doctors demand: everything!
After a while the discussion came to a point where we both agreed that the usual way developers produce user interfaces is not simply good enough. I guess we are still making the mistake of accepting medical software as another form of “business software”. It is not accounting, it is not some sort of bookkeeping. Doctors and nurses need to benefit from every piece of technology in user interfaces to make their work faster.
This is not about eyecandy, it is about providing and collecting information as efficiently as possible, using the minimum amount of key presses and mouse clicks. I’ve been writing about MS CUI every now and then, and MS is pushing its GUI related technology into this work now. Both WPF and Silverlight are being used as the implementation technologies for CUI components. This is not the most compatible approach, even javascript has a wider base, but it is a smart one on behalf of Microsoft.
I’ve seen some very impressive implementations of CUI by MS, and I know that medical staff would like those implementations.
This is the exact point where trouble begins. We’ve been working die hard on model driven development, object models derived from domain models etc.. There is a great deal of effort for making things more streamlined, more product line like (if this is a valid description). Generic approaches decrease flexibility. Now, using domain models is good for representing the domain and related logic in a consistent and more important than that, in an interoperable manner. Software developers love to generalize things, that’s why we have all these frameworks, and the benefits of this approach is a whole other story, to which I can no doubt add a few chapters. When software people try to connect the domain models to user interfaces they naturally want to be able to decrease the amount of work necessary to create user interfaces. For a modern developer with an object oriented approach (no offense old school ER diagram people, I love you too 🙂 ) a domain model is the actual representation of the domain and the solution to the problem in that domain. User interface is just a layer that connects users to representation of their domain. So why not get rid of UI blues as much as possible, when you understand and represent the domain? In other words, developers are mostly done with the problem when they create a domain model and necessary business logic. The intellectual challenge is usually tougher in that part. UI is just something to be done to connect the users to this solution. So most of the time, being able to generate GUI is a blessing for a domain oriented developer. I’ve seen some guys obsessed with UI polishing and optimization, but they are few in number compared to the first type I’ve just described.
What happens when connecting rich domain models to persistence is basically trouble. As domain model gets more and more complicated, the persistence layer, which is usually a relational db, becomes more seperated due to lack of inheritence, types etc. These are the things that allow us to build a rich domain model in the first place. Fowler offers a few remedies for this kind of situation in his book “Patterns of Enterprise Applications”. The same thing happens when connecting domain models to user interfaces. If you want a capable user interface which is optimized to the max considering user’s experience, you’ll have a hard time connecting the two layers “automatically”. Forms generated from domain models just does not feel right for having the most capable GUI possible.
Maybe if we can find a consistent way to connect MS CUI to domain models, we may have the best of both worlds. I’ll be working on this for a while, and I think everyone in the domain can benefit from it quite a lot.
