I suspect that most software products have their origins as a project. We are seeing the birth of such a product so I thought I would blog about it.
Earlier I wrote a couple of posts about our next generation web user interface (UI) generator. Obviously there is something there worth trying to reuse in a different context. It turns out that the idea we came up with was to marry the generator with an older product idea that never really took off. A number of years back we built a survey generator that would support very complex surveys with branching and recursive multi-record groups and generated a complex medical survey for the Preeclampsia Foundation. We won Oracle’s JDev Challenge award for that project as we generated to the technology that would come to be known as ADF.
This new generator we wrote had an even cooler UI than the old survey generator but:
1) Did not use a generic data structure so had to be based on a real database
2) Did not have sophisticated branching
3) Was based on a go to any page you wanted in any order model rather than a guided survey.
We are building a next generation healthcare software product so we wondered if maybe we could enhance that product easily with this new idea.
It turns out that doctors want to know loads of things about their patients and the logic that determines what they want to know is very sophisticated. Obviously, there are lots of simple branching issues like: “If you are female, I am going to ask you about pregnancies.” But there are also lots of things like: “If, based on answers to lots of your questions, I determine that you are at risk for XXX, then I am going to ask you a bunch more questions to assess that risk.”
The problem with our survey generator was that it was too sophisticated. Most survey builders are happy with the limited capabilities of something like Survey Monkey. We needed to problem space where standard products did not meet the need. Since we have a lovely engine that builds a complex data entry screen as fast as you can list the fields and object types, this seemed like a perfect use case for our new toy.
We extended the UI repository to support a generic data model and event driven branching.
For the generic data model, we had a big debate as to whether we should jump on the NoSQL band wagon and implement using Hadoop. After much deliberation, we elected to not implement using Hadoop. We determined that we could implement easier and faster using a simple relational generic stricture. And, if we ever need to convert to Hadoop because we were running into thousands of simultaneous users that it would be pretty easy to refactor.
The structure we ended up using was a simple recursive RECORD table that is associated with a particular survey and a child VALUES table to store the answers. The rest of the meta data gave us all the information we needed to have the semantics and datatypes.
For the logic, we thought about using our existing state engine and declaring that each page is a state. But we really liked the idea that users could fill things out in any order and come back to any page easily. So we opted for an event model that would add pages in real time.
The model was to have a table called PAGE_RULE. A PAGE_RULE can be triggered by any one of a number of “EVENTS” (for example, I finished a specific page), which sits as a child table to PAGE_RULE. which then spawns any number of new pages(implemented as the table SPAWNED_PAGE which is also a child of PAGE_RULE) . The rule only conditionally fires which is implemented by a Boolean expression in PAGE_RULE table.
It was hard to figure out the perfect UI that is easy to use, requires no training and is easy on the eyes. The technical part was less of a challenge than you might think. The hardest part is getting the rules out of a doctor. If anyone knows how to do THAT, let me know.
Leave a Reply