HTML Logo by World Wide Web Consortium ( Click to learn more about our commitment to accessibility and standards.

Moving forward with Composr

ocPortal has been relaunched as Composr CMS. ocPortal 9 is superseded by Composr 10.

Head over to for our new site, and to our migration roadmap. Existing ocPortal member accounts have been mirrored.

New v10 feature for programmers -- decision trees

New v10 feature for programmers -- decision trees Did anyone used to read "Choose your own adventure" books? I read a few dozen as a kid.

I have just taken a little break from wrestling my inbox to write a little thing we will need for the new Composr homesite: decision trees.

Decision trees allow a programmer to quickly build up a flow between any number of screens with text and questions. Depending on the answers given, it flows through differently, until you get to a terminal screen. i.e. just like a Choose your own adventure book.

In our case, it is to replace the contact us system we have.

We currently have a few different contact methods strewn across our site. We have contacting for agency projects, we have different ticket priorities to open, we have a project briefing survey and we have some front ends to free support tickets. We also have the forum and the tracker. Over the years I've thought about how we can better route people's requests, and gather more information up-front, and provide instant information where possible. As a rule generally people will use whatever contact link they find first, and type up minimal information. We have also found that our company processes have severely degraded in effectiveness over the last year, because people are more squeezed for cash, and generally try and push all projects through as support tickets (even complex multi-stage multi-month projects), and tickets really don't serve that well. From a business perspective it is also a problem because we get these monster tickets that only I have the expertise to answer because they span a dozen technologies – while they really need to go via a project manager and then structured out according to a project plan. When we started out there were far fewer web/mobile technologies a support operator had to have an awareness of – nowadays, no support operator we could hire could even have enough awareness of the different things a customer may bring into a conversation.

So, with our v10 site we'll be chucking out all the support options we currently have and feeding people into a single decision tree system that will take all their information and provide all the guidance they need based on their answers.

We're not going to be having any difference between our agency rates and support ticket rates, and we're also vastly simplifying things down (I think there'll just be two ticket priorities). So instead of trying to shoehorn things into a number of service categories, through a number of different service front-ends, we will have custom solutions based on whatever input our customers give us, and customers will be able to very efficiently give us a big amount of information to help us quickly decide that. We're also planning to work with local service providers too, rather than assuming any project that comes in should be done by ocProducts.

Here's how a decision tree implementation works:
This code will morph into the actual code we end up using for our own site. To start with I just made a very simple implementation to test the new features.

One nice feature of it is you can always go back, and it still remembers your answers. You can also bookmark screens so that you can keep going back (e.g. keep putting through the same ticket priority in our case).

I'm quite excited about this feature because it's not something I ever thought about until I considered our own needs. But as I think more, I realise it is generally applicable to many scenarios, including allowing a programmer to quickly build out very sophisticated surveys (much more sophisticated than our quizzes module could handle).

View all


There have been no trackbacks yet