[rt-devel] Notes on canned responses

[Marc Hedlund]

About a year or so ago, I wrote a utility for RT-1.x called 'cannery',
which supported 'canned' or standard responses for RT tickets.  'cannery' 
was a hack.  It worked reasonably well, but had a number of serious
design limitations, and would never work for more than about 15-20 canned 
responses at most.  

I recently upgraded to RT-2.0, and started thinking about how canned
responses might be added in a more reasonable way.  I traded some notes
with Jesse about this and promised to write up a "lessons learned from the
prototype" report; which follows.

The Need
========

At my previous company, we used RT-1.0 to manage our 'feedback' queue,
which received messages from users of our software looking for technical
support.  Most users had very similar problems, but because tickets were
assigned to many members of the technical staff, answers to those
questions were uneven, repetitively produced, and generally inefficient.  
Other queues had similar needs -- for instance, the 'jobs' applicant queue
needed a standard reply for declining an application.

The idea of canned responses was to create a repository of standard
answers to requests, so that the technical staff would not need to rewrite
these answers, and also so that "canonical," well thought-out responses
would be available for any member of the queue to use.  

I started on the project looking for an easy way to put standard answers
at the fingertips of queue members, and for a way for members to update
the standard answer set when new common questions emerged.

The Hack
========

In order to address these needs, I wrote a Perl script called 'cannery.pl'
for use with an RT installation.  To use cannery, you would do the
following:

 1. Create a directory to hold canned responses.
 2. In that directory, create one file per canned response, where the
    first line of the file was a question to identify the response,
    and the rest of the file was the response itself.
 3. Run the 'cannery.pl' script, giving the cannery directory as an
    argument.  This script produced a Javascript file, 'cannery.js',
    as output.
 4. Modify the HTML of the ticket response form, so that the
    cannery.js file is included directly above the correspondence
    body textarea.

Following these steps would produce a pop-up selection menu in the ticket
response form.  The menu would contain the questions used to identify each
response; by selecting the question, the canned answer would be inserted
immediately into the beginning of the body textarea (using Javascript, not
a form submission).  The user could then make edits to the canned response
as needed, and send of the reply.

Observations
============

For what it was, cannery was successful in our company -- the use of
standard responses was pretty high (about 75% of the responses sent
were canned) and the number of tickets closed each day more than
doubled.  

That said, the design was limited in several ways.  First off, it was
very hard to add new canned responses to the system, and no one but
the RT administrator (me) ever did this.  To add a response, you had
to create a new text file containing the answer, and then re-run the
cannery.pl script.  Knowing how to do this and where to put the file
was pretty obscure, so no one bothered to learn it.  This meant that
the utility of cannery declined for our installation over time, as the
responses became stale and new canned responses were not added.

Second, the design required that the full body of every canned response be
loaded over the network every time a correspondence form was opened, so
that it would be available to the Javascript insert function.  Even with
network caching and LAN speeds, the page rendering time in the browser was
noticably degraded, and users were even more reluctant to add new canned
responses considering this.  For a site with a large number of canned
responses, this solution would be completely unworkable.

Finally, the choice of Javascript as a technology clashes with the rest of
RT.  You can run RT just fine with HTML and maybe cookies -- Javascript is
not required anywhere else.  While I sought to and succeeded in preventing
another page load from being required, this is not in line with the
general RT philosophy.  Javascript was also surprising limited in not
letting you insert text at the point (cursor) in the textarea -- just at
the front or the end of the existing text.

So, cannery seems to have a worthwhile niche, but its implementation was
not in any way worthy of being included in RT core.  (In addition, I never
rev'd it for RT-2.0, although one of its users did.)

Design Notes
============

Here are some things worth noting for any attempt to add canned
responses to RT properly.

1. Make it very easy to add new canned responses through the Web
   interface.  The way I would see this working well is to have a
   checkbox at the bottom of the response form, which reads "Make this
   a standard response."  If the box is checked before submission, the
   next form the user sees should contain a line for the standard
   question, and then the response given in a textarea so the user can
   edit out any response-specific information.  The user should then
   be able to submit that form and have the new canned response in the
   system with no further work.  The ACL system could add a
   "ModifyStandardResponse" permission to enable this.

2. Canned responses should be categorized, and categories should be
   selected for inclusion on a per-queue or global basis.  Maybe this
   could work like Keywords -- you go add a response in one form, and
   then enable that response or response set in the queue
   configuration.  This way you can have responses that are
   queue-specific without weighing down the interface of all queues.

3. Don't try to load every response on every page, but maybe do try to
   load standard questions.  So the usage steps might look like this:
     a) User opens a response form for a ticket.
     b) All of the standard questions (not responses) for the queue
        are loaded into a pop-up (size=1) select form field just above
	the response textarea.
     c) The user can select an appropriate question and hit the
        "Insert" button, which does a form submission.  Ideally, the
        user can first mark where the insert should occur in the
        response (using a special symbol like "{}" in find).
     d) The same form is loaded again, but the text of the standard
        response is now inserted in the textarea.

======

I hope this is helpful.  I'd be happy to hack on this if desired.  The
outline above is implementable pretty easily, though it requires a
database mod I'd be concerned about doing without help.  (I can do the
db schema, but I don't know how to work well with 'make upgrade'.)

Marc Hedlund 
e: marc at precipice dot org