[sf-perl] [sfpug] Practical theory: graphs

elein elein at varlena.com
Mon Dec 19 11:16:17 PST 2005


Hmm.  Some mails did not make it through on this thread.
The menu tree structure is the one that I describe in
the example in my article.  It was created with the concept
of nodes and leaves.  It also shows the data storage
that Josh was trying to put together.  And provides functions
for traversing up and down as well as adding and deleting
nodes.  I would be interested to hear how this is different
from your phone tree model needs.

elein
elein at varlena.com

On Fri, Dec 16, 2005 at 11:43:03PM -0800, Quinn Weaver wrote:
> On Fri, Dec 16, 2005 at 10:36:34PM -0800, Rich Morin wrote:
> 
> > I like edge lists, because they are a very general representation,
> > but they may be overkill for this problem.  That said, some graph
> > libraries (e.g., Boost Graph Library, Ruby Graph Library) support
> > a variety of representations "under the covers".
> 
> > [or Ruby Graph Library, RGL]
> 
> Hmmnn.  Hmmmn!  Interesting.  The more I hear about Boost, the more
> impressed I am.  But I don't really want to create the bindings, as
> you point out.
> 
> Anyway, thanks for the concrete recommendations; this is exactly
> what I need.
> 
> > Getting back to your problem description, it sounds like the log
> > doesn't really care about the graph at all.  It merely needs to
> > know which nodes got visited in what order.  That is, a simple
> > list of node names would suit your purpose.  However, the code
> > that migrates nodes up to the "front" of the graph might need to
> > pay attention to the graph structure.
> 
> This is probably true.  In a sense, the system of record is the actual
> running "dialplan" (my preferred term for the "voice maze" or set of
> menus).  Maybe I shouldn't be duplicating the dialplan in an RDBMS.
> It's already read in from an XML file (usually dynamically generated),
> so why complicate things?
> 
> > The notion of automagically migrating nodes is intriguing, but I
> > worry that resulting menus may not fit any reasonable model that
> > the user might have.  Also, messages which work well in one menu
> > may not have sufficient context to be understandable in another.
> 
> Good point.  This is an acknowledged risk of that feature.  The only
> way to avoid it is to design your system properly, or hire me to do it
> ;) .  Actually, you can turn of the reordering feature if you want,
> but I think it's useful.
> 
> The XML encourages good design to some extent, but it can't absolutely
> enforce it.  For instance, each node in the graph must have a globally
> unique name.  This name get mapped to a sound file, or, if no sound
> file is not found, run through text-to-speech.  So a node named
> billing would correspond to a sound file with someone saying
> "billing".  You couldn't have two billing nodes, but you could have a
> billing_for_consulting node and a billing_for_hardware mode.
> 
> BTW, high-quality recorded voice prompts, done by good voice actors,
> are always better than text-to-speech.  I can provide these as
> part of my consulting package. :)
> 
> Overall my hope is that people will be willing to put in the time or money
> to design their systems carefully.  An IVR is a pretty important window to
> your customers, so it's worth getting right at the outset.
> 
> Anyway, you remind me that I need to write some style guidelines for
> proper IVR design.  Hmmnn, article material...
> 
> > Finally, I wonder whether it might not make sense to assume that
> > the person managing the menus is not a programmer at all.  If so,
> > you might want to consider using a GUI-based interface, based on
> > dot, dia, SVG, or ???.  Your code could present the current graph
> > (something like a state-transition diagram) and offer the manager
> > the ability to select from suggested re-connections, define new
> > connections, etc.
> 
> Ho-ho!  Very interesting.  In fact I have some plans for this,
> but they're not ready for prime time yet.
> 
> --
> qw (Quinn Weaver); #President, San Francisco Perl Mongers
> =for information, visit http://sf.pm.org/weblog =cut
> 


More information about the SanFrancisco-pm mailing list