5

One part of a project I'm working on is interactive scripts for call centre staff. Pretty much every possibility I can think of in this case can be represented on paper as a flowchart, which is why I'll be making an interactive "script builder" that is essentially a flowchart builder in HTML5/JS. This will let me add conditional logic to the scripts, so the agent could be prompted to say something specific based on the reply from the person being called.

Currently I'm stuck in the planning phase: how do I represent each script/flowchart in my system? I need something that can be completely represented using either JSON or XML, as the system is web based.

7

Effectively, a flow chart is just a fancy graph. So, you will have nodes and edges. Nodes will have text, (optionally) position/size, and unique ids. Edges will have a pair of nodes and a name.

So, suppose we have, "Ask user their name. If their name is Bob, compliment them. Otherwise, hang up on them."

Something like this:

var JsonGraph = {
    Root: 1,
    Nodes: {
        1: {Text: "Ask user their name.  Is their name Bob?"},
        2: {Text: "Compliment the user."},
        3: {Text: "Hang up on the user."}
    },
    Edges: [
        {Source:1,Destination:2,Text:"yes"},
        {Source:1,Destination:3,Text:"no"}
    ]
}

The Edge text turns into a button within the wizard. The node text turns into the text within the wizard.

  • I was contemplating if it would make more sense to change the Source->Destination edge mappings from a key-value list to key-values dictionary. However, I realized after the fact that this makes the code slightly more confusing, since edges tend to be first-class objects. So, I rolled it back. View the edit history if you're curious about this variation. – Brian Oct 22 '15 at 18:06
2

When writing GoJS we solved this by having the following rules for data:

  • Every node has a key, which must be unique
  • Links can be represented one of two ways: In a Tree-like fashion (TreeModel), or as separate JSON object entities (GraphLinksModel)

If the flowchart or diagram is created in a Tree-like fashion, with only one parent per Node, then you don't need separate JSON data for links. Instead, each node can specify its own key but also its parent key (as parent or some other identifier), and this gives you enough information to make every link in the graph.

Some simplified sample JSON for a TreeModel (from Org Chart Editor). The JSON for nodes describes each with a key, and describes the parent relationship with another key:

{"key":"1", "name":"Stella" },
{"key":"2", "name":"Luke", "parent":"1"},
{"key":"3", "name":"Meg", "parent":"2"},

The other way is to have every link represented by its own JSON object, but unlike nodes, links don't actually need to have their own key values, they only need to have a to and from value specifying the two Node keys that the link connects to.

The State Chart sample uses a GraphLinksModel, so one JSON object per each node and each link:

"nodeDataArray": [
  { "id": 0, "text": "Initial" },
  { "id": 1, "text": "First down" },
  { "id": 2, "text": "First up" }
],
"linkDataArray": [
  { "from": 0, "to": 0, "text": "up or timer" },
  { "from": 0, "to": 1, "text": "down" },
  { "from": 1, "to": 0, "text": "up (moved)" },
  ...

This allows for multiple parents, multiple links between nodes, two-way connections, etc.

0

JSON documents consist of: Dictionaries (aka key-value pairs), Arrays, Strings, Numbers, Boolean values, and Null values, where the values in the dictionaries and items in the arrays are the same objects again.

Once you organise your data that way, translating into JSON is trivial (usually you have a library that makes it a single call).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.