Opportunity to make CMSLite not so Lite

[Vivek Singh]

In BBC we are building  FLW  Job aid and certification course. I have attached the flow chart which explains more.

A large part implementation involves serving the content to the user, gathering statistics about the usage of this content and creating reports on this. While other things are specific to BBC but this parts feels very generic. Hence we should consider moving some of this into the platform. My proposal is to move it to CMSLite which would additionally be responsible for:

1.   ...content tree with its data (name, content) and any meta-data implementation would want (e.g. in BBC, levelNumber, expiryInterval). A tree kind of structure would be flexible enough to use.

2.   ...usage data for each content (contentId, percentageHeard, dateTimeOfListening) and meta-data (HashMap).

I have left out reporting as I am not sure whether we want to always report using motech db or want to create data ware house and do report from there.

--
Vivek Singh | +91 98452 32929 | http://sites.google.com/site/petmongrels | petmongrels@twitter

[David Hutchful]

Thanks Vivek. Do you envision this being different from e.g. the call log we have in Motech Ghana? That is, this would only contain usage data for the content and it will not be linked to the particular recipient?

[Vivek Singh]

It is a good question.

IVR Call Detail Records are managed by IVR module in the platform. They are at the call flow level and also capture user actions. So, yes arguably, content usage can be moved to IVR module, but not the content tree.

We don't have recipient/caller/subscriber as a concept in the platform. As all we can think of is phone number (and may be password). They are referred using externalId all over in the platform, not something I like but don't have much better idea as well.

[Rob LaRubbio]

I need to read this over some more, but my first thought is how is this different from using the decision tree module?  It was meant as a way to build VXML trees and the idea was that you could associate events with nodes or transitions.  So to get the reporting we'd just have to define some of those events and then develop a module that could aggregate and do the reporting.

-Rob

[Vivek Singh]

It is n-level of content but we won't have to build a decision tree object, use the tree to generate VXML. The VXML is completely hand coded instead of one VXML for every content.

Decision tree is for expressing/defining your call flow. Using its semantics to define content would be awkward and indirect.

This should be soon developed under BBC code, so I can point out the location when its ready.

[Rob LaRubbio]

I think I'm still not following.  With the decision tree module we should be able to generate VXML that encompasses more than a single node in the tree. It was done that way as a first pass but expanding it to dynamically generate the entire tree before sending it to the IVR system should be possible.

We are also going to be working with INSTEDD to have them port their VXML authoring UI to sit ontop of the decision tree json format.  So the end user shouldn't have to touch VXML at all.

I guess I'm a little confused since you mention a content tree.  Are we really just talking about creating a new content type within CMS Lite that can be referenced from a node within the existing decision tree?  That way you use the existing tree structure to define the call flow and within that flow you reference the appropiate content within CMS lite.

-Rob

[Vivek Singh]

In case of BBC the call flow is complex to be generated using a decision tree structure and a template. The content tree (which is n-level) is handled using Java script function instead.  https://github.com/motech/ananya/blob/master/ananya-web/src/main/webapp/vxml/jobaid.xml , which is much simpler and straightforward to develop.

Based on my interaction with people who develop VXML applications (spoken to some people in onmobile), they also prefer this style of development. But I think, there is a place for decision tree as well, as we are using TAMA and probably in Ghana, for simple call markups, with no much logic on the client side. But when one need to handle multiple variables, collect data during the call in VXML data containers, I would prefer to use VXML directly.

Given that I feel we should not couple content and decision tree with each other.

[Rob LaRubbio]

Can you send around a copy of the generated json data that the vxml
consumes?

-Rob

On Fri 06 Jan 2012 01:23:28 AM PST, Vivek Singh wrote:
>
> In case of BBC the call flow is complex to be generated using a
> decision tree structure and a template. The content tree (which is
> n-level) is handled using Java script function instead.
> https://github.com/motech/ananya/blob/master/ananya-web/src/main/webapp/vxml/jobaid.xml
> ,
> which is much simpler and straightforward to develop.
>
> Based on my interaction with people who develop VXML applications
> (spoken to some people in onmobile), they also prefer this style of
> development. But I think, there is a place for decision tree as well,
> as we are using TAMA and probably in Ghana, for simple call markups,
> with no much logic on the client side. But when one need to handle
> multiple variables, collect data during the call in VXML data
> containers, I would prefer to use VXML directly.
>
> Given that I feel we should not couple content and decision tree with
> each other.
>
> On 4 January 2012 02:16, Rob LaRubbio <rlar...@grameenfoundation.org

>> <mailto:rlar...@grameenfoundation.org>> wrote:
>>
>> I need to read this over some more, but my first thought is
>> how is this different from using the decision tree module?
>> It was meant as a way to build VXML trees and the idea was
>> that you could associate events with nodes or transitions.
>> So to get the reporting we'd just have to define some of
>> those events and then develop a module that could aggregate
>> and do the reporting.
>>
>> -Rob
>>
>> On Tuesday, December 27, 2011 at 4:50 AM, Vivek Singh wrote:
>>
>>>
>>> It is a good question.
>>>
>>> IVR Call Detail Records are managed by IVR module in the
>>> platform. They are at the call flow level and also capture
>>> user actions. So, yes arguably, content usage can be moved
>>> to IVR module, but not the content tree.
>>>
>>> We don't have recipient/caller/subscriber as a concept in
>>> the platform. As all we can think of is phone number (and
>>> may be password). They are referred using externalId all
>>> over in the platform, not something I like but don't have
>>> much better idea as well.
>>>
>>> On 27 December 2011 17:53, David Hutchful
>>> <dhut...@grameenfoundation.org

>>> <mailto:dhut...@grameenfoundation.org>> wrote:
>>>>
>>>>
>>>> Thanks Vivek. Do you envision this being different from
>>>> e.g. the call log we have in Motech Ghana? That is, this
>>>> would only contain usage data for the content and it will
>>>> not be linked to the particular recipient?
>>>>

>>>> *From:*motech-ar...@googlegroups.com
>>>> <mailto:motech-ar...@googlegroups.com>
>>>> [mailto:motech-ar...@googlegroups.com
>>>> <mailto:motech-ar...@googlegroups.com>] *On Behalf
>>>> Of *Vivek Singh
>>>> *Sent:* Tuesday, December 27, 2011 11:55 AM
>>>> *To:* motech-ar...@googlegroups.com
>>>> <mailto:motech-ar...@googlegroups.com>; Sanchit Bahal
>>>> *Subject:* Opportunity to make CMSLite not so Lite

>>>>
>>>> In BBC we are building FLW Job aid and certification
>>>> course. I have attached the flow chart which explains more.
>>>>
>>>> A large part implementation involves serving the content to
>>>> the user, gathering statistics about the usage of this
>>>> content and creating reports on this. While other things
>>>> are specific to BBC but this parts feels very generic.
>>>> Hence we should consider moving some of this into the
>>>> platform. My proposal is to move it to CMSLite which would
>>>> additionally be responsible for:
>>>>
>>>> 1. ...content tree

>>>> <https://github.com/motech/ananya/blob/master/ananya-web/src/main/java/org/motechproject/bbcwt/domain/tree/Node.java>
>>>> with its data (name, content
>>>> <https://github.com/motech/MOTECH/blob/master/motech-cmslite-api/src/main/java/org/motechproject/cmslite/api/model/StreamContent.java>)

[Vivek Singh]

attached

On 10 January 2012 00:40, Rob LaRubbio <rlar...@grameenfoundation.org> wrote:

Can you send around a copy of the generated json data that the vxml consumes?

-Rob

On Fri 06 Jan 2012 01:23:28 AM PST, Vivek Singh wrote:

In case of BBC the call flow is complex to be generated using a
decision tree structure and a template. The content tree (which is
n-level) is handled using Java script function instead.
https://github.com/motech/ananya/blob/master/ananya-web/src/main/webapp/vxml/jobaid.xml ,
which is much simpler and straightforward to develop.

Based on my interaction with people who develop VXML applications
(spoken to some people in onmobile), they also prefer this style of
development. But I think, there is a place for decision tree as well,
as we are using TAMA and probably in Ghana, for simple call markups,
with no much logic on the client side. But when one need to handle
multiple variables, collect data during the call in VXML data
containers, I would prefer to use VXML directly.

Given that I feel we should not couple content and decision tree with
each other.

On 4 January 2012 02:16, Rob LaRubbio <rlarubbio@grameenfoundation.org

<rlarubbio@grameenfoundation.org

<mailto:rlarubbio@grameenfoundation.org>> wrote:

I need to read this over some more, but my first thought is
how is this different from using the decision tree module?
It was meant as a way to build VXML trees and the idea was
that you could associate events with nodes or transitions.
So to get the reporting we'd just have to define some of
those events and then develop a module that could aggregate
and do the reporting.

-Rob

On Tuesday, December 27, 2011 at 4:50 AM, Vivek Singh wrote:

It is a good question.

IVR Call Detail Records are managed by IVR module in the
platform. They are at the call flow level and also capture
user actions. So, yes arguably, content usage can be moved
to IVR module, but not the content tree.

We don't have recipient/caller/subscriber as a concept in
the platform. As all we can think of is phone number (and
may be password). They are referred using externalId all
over in the platform, not something I like but don't have
much better idea as well.

On 27 December 2011 17:53, David Hutchful

<dhutchful@grameenfoundation.org

<mailto:dhutchful@grameenfoundation.org>> wrote:

Thanks Vivek. Do you envision this being different from
e.g. the call log we have in Motech Ghana? That is, this
would only contain usage data for the content and it will
not be linked to the particular recipient?

*From:*motech-architecture@googlegroups.com
<mailto:motech-architecture@googlegroups.com>
[mailto:motech-architecture@googlegroups.com
<mailto:motech-architecture@googlegroups.com>] *On Behalf

Of *Vivek Singh
*Sent:* Tuesday, December 27, 2011 11:55 AM

*To:* motech-architecture@googlegroups.com
<mailto:motech-architecture@googlegroups.com>; Sanchit Bahal

[Rob LaRubbio]

Do you have docs/implementation that shows how users will define this in CMS lite?  Is it correct to say that the difference between this and the decision tree is where the tree is executed?  Currently decision tree is defined in JSON and executes on the server while this is defined in JSON and executes on the client.

Also looking at the BBC call flow, I wouldn't say it's complex, just large.  It still looks like a normal tree.  I don't see any cycles (well there is the auto return back to the chapter menu) or branches that are different depending on earlier choices the user has made (i.e. no state). 

-Rob

On 01/09/2012 10:08 PM, Vivek Singh wrote:

attached

On 10 January 2012 00:40, Rob LaRubbio <rlar...@grameenfoundation.org> wrote:

Can you send around a copy of the generated json data that the vxml consumes?

-Rob

On Fri 06 Jan 2012 01:23:28 AM PST, Vivek Singh wrote:

In case of BBC the call flow is complex to be generated using a
decision tree structure and a template. The content tree (which is
n-level) is handled using Java script function instead.
https://github.com/motech/ananya/blob/master/ananya-web/src/main/webapp/vxml/jobaid.xml ,
which is much simpler and straightforward to develop.

Based on my interaction with people who develop VXML applications
(spoken to some people in onmobile), they also prefer this style of
development. But I think, there is a place for decision tree as well,
as we are using TAMA and probably in Ghana, for simple call markups,
with no much logic on the client side. But when one need to handle
multiple variables, collect data during the call in VXML data
containers, I would prefer to use VXML directly.

Given that I feel we should not couple content and decision tree with
each other.

On 4 January 2012 02:16, Rob LaRubbio <rlar...@grameenfoundation.org

<rlar...@grameenfoundation.org

<mailto:rlar...@grameenfoundation.org>> wrote:

I need to read this over some more, but my first thought is
how is this different from using the decision tree module?
It was meant as a way to build VXML trees and the idea was
that you could associate events with nodes or transitions.
So to get the reporting we'd just have to define some of
those events and then develop a module that could aggregate
and do the reporting.

-Rob

On Tuesday, December 27, 2011 at 4:50 AM, Vivek Singh wrote:

It is a good question.

IVR Call Detail Records are managed by IVR module in the
platform. They are at the call flow level and also capture
user actions. So, yes arguably, content usage can be moved
to IVR module, but not the content tree.

We don't have recipient/caller/subscriber as a concept in
the platform. As all we can think of is phone number (and
may be password). They are referred using externalId all
over in the platform, not something I like but don't have
much better idea as well.

On 27 December 2011 17:53, David Hutchful

<dhut...@grameenfoundation.org

<mailto:dhut...@grameenfoundation.org>> wrote:

Thanks Vivek. Do you envision this being different from
e.g. the call log we have in Motech Ghana? That is, this
would only contain usage data for the content and it will
not be linked to the particular recipient?

*From:*motech-ar...@googlegroups.com
<mailto:motech-ar...@googlegroups.com>
[mailto:motech-ar...@googlegroups.com

<mailto:motech-ar...@googlegroups.com>] *On Behalf

Of *Vivek Singh
*Sent:* Tuesday, December 27, 2011 11:55 AM

*To:* motech-ar...@googlegroups.com
<mailto:motech-ar...@googlegroups.com>; Sanchit Bahal

[Vivek Singh]

>> Do you have docs/implementation that shows how users will define this in CMS lite?

Not yet. We are working on a JSON based approach to configure the content tree for Job aid and certificate course. I can send you when done but I guess you can imagine.

>> Is it correct to say that the difference between this and the decision tree is where the tree is executed?  Currently decision tree is defined in JSON and executes on the server while this is defined in JSON and executes on the client. 

Yes.

>> Also looking at the BBC call flow, I wouldn't say it's complex, just large.  It still looks like a normal tree.  I don't see any cycles (well there is the auto return back to the chapter menu) or branches that are different depending on earlier choices the user has made (i.e. no state).

So in job aid

- from leaf node you transition to parent playing the menu.

- from leaf node you transition to parent's sibling if it is the last leaf in its parent. This time the introduction and menu is played.

- when in last leaf of last parent, you go to the parent.

This would be different for certificate course, which we haven't started implementing yet.

[Rob LaRubbio]

Does it make sense to look into consolidating the json formats between this and the decision tree?  If instedd is going to work on an editor for us leveraging that work across both systems seems like a win.

-Rob

[Vivek Singh]

Yes that would be useful. We should look at when moving this into platform.

@Sanchit, can we add this as a story in platform then. I would leave it to you and Rob prioritize this.