[sf-perl] Practical theory: graphs

[Quinn Weaver]

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