Closed Bug 465518 Opened 16 years ago Closed 16 years ago

TikiWiki support for Live Chat CSAT

Categories

(support.mozilla.org :: Knowledge Base Software, task)

task
Not set
blocker

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: zzxc, Assigned: ecooper)

References

Details

(Whiteboard: tiki_feature)

Attachments

(6 files, 3 obsolete files)

A new script in Tikiwiki will be needed to collect poll results and assign karma after a user leaves live chat.  Users will be directed to a page such as /tiki-csat_poll?type=livechat&chatId=wxnk528132&helper=accountname&question=Firefox+always+crashes&time=1227021622&nickname=Joe.  This page will initially need to:

1) Ask whether the problem was solved, yes or no.

2a) If the problem was solved, two polls are presented with a 1-5 scale:
*"Rate the effectiveness of using Live Chat to solve your problem"
*"How effective was the helper in understanding your issue and providing answers?"

2b) If the problem was not solved, two polls are presented:
*Radio question: "I will follow up later to continue solving this issue", "My chat ended before it was finished", "The helper didn't know the answer to my question", "The helper didn't understand my issue", "I never got a response from the helper", "I gave up on solving my problem through live chat"
*"How effective (1-5) was the helper in understanding your issue and providing answers?"

3) A link is provided to post in the forum, with the helper name and question from live chat entered as the post title by default.  Additionally, a link to the chat log (eg. https://chat-support.mozilla.com:9091/plugins/fastpath/chat-conversation.jsp?sessionID=wxnk528132) should be provided at the top of the forum post by default.
Blocks: 458713
This implementation will probably use user polls, to match the forum CSAT implementation in bug 452830.  There are a total of 4 polls of which the user answers three per above.  (One poll is hidden, based on the answer to the first question)

In addition to the polls, a new database table will be needed to store the other information associated with the chat session - the chat ID, question title, time, nickname, nickname(s) of helper(s), and any automatically gathered information such as plugins or user-agent.  This information is useful to gather, so we can make more specific queries.

The ability to post in the forum in step #3 above should ideally be on this same page; pressing "follow up with this question in the forum" should immediately open a partially filled out 'new post' form.  The link back to the Openfire log is important, as that will let us find both the chat log and the CSAT responses for the user's chat.  We can also use this in more advanced queries, to see how many chat followups in the forum are being successfully solved.
After discussing this further, we decided that the polls should be simplified further to match the forum/KB poll question.  So, they should now be as follows:

1) Ask whether the problem was solved, yes or no.

2a) If the problem was solved, the standard csat poll is displayed with a 1-5 rating:
*"Please rate your experience with solving your problem on support.mozilla.com from 1 (very unsatisfied) to 5 (very satisfied)."

2b) If the problem was not solved, a radio poll is presented:
*Radio question: "I will follow up later to continue solving this issue", "My
chat ended before it was finished", "The helper didn't know the answer to my
question", "The helper didn't understand my issue", "I never got a response
from the helper", "I gave up on solving my problem through live chat"
While the params for tiki-feedback.php are pretty flexible, a few are required to keep consistency. 

These are type, hash (
...sigh.

Anyway, they are hash, type, and feedback. Hash and type ('livechat') are self explanatory. feedback is the feedback poll name (feedback polls are many votes over many objects), which will probably be something like "Live Chat Support" or just "Live Chat". The title is a bit arbitrary, but serves as the best way to return feedback polls since they aren't tied to objects.
Assignee: nobody → smirkingsisyphus
This is the first thing you see when you follow the link given at the end of the chat session.

Notice the two links below. One goes to the chat log. The other points to a partially filled "ask a question"/new topic form on tiki-view_forum.php.
This is what you get after clicking, "Yes" on the did this solve your problem poll.
If you click "No" on the first poll, you get this. It sort of looks clunky to me. Maybe a drop-down?
Example link of current implementation: /tiki-feedback.php?type=livechat&feedback=Live+Chat+Support&chatId=1234567&nickname=Joe&helper=john&question=Firefox+crashes+when+working+on+sumo&hash=19e9fa5525bd2d1baa53c8de8a90ffd2e3f20247

feedback and type are static and are required by tiki-feedback.php. 

The voting process can only happen one time per chatId. This holds even if the user completes the feedback process partially(e.g., user clicks yes/no on the first poll, then leaves the page).

If everything is okay aesthetically, Matthew and I can finalize the hashing method and I'll post the patch for this side of the Live Chat CSAT.
(In reply to comment #2)
>
> 2b) If the problem was not solved, a radio poll is presented:
> *Radio question: "I will follow up later to continue solving this issue", "My
> chat ended before it was finished", "The helper didn't know the answer to my
> question", "The helper didn't understand my issue", "I never got a response
> from the helper", "I gave up on solving my problem through live chat"

These options can probably be improved, some of them are fairly redundant (could be combined or need to be clarified) and the last option really doesn't tell us anything, and can be the same as pretty much all the rest (besides the first one). If possible we want to know why they're giving up.

Maybe what we want to do is add another question "Are you going to continue using support.mozilla.com to solve our problem?" and if the answer is no leave a comment box to let the user tell us in their own words.
^ solve *your* problem (saw the typo right after I'd hit submit :-\ )
A free response question would be nice to have, but we can't currently do this using user polls.  We are essentially limited to multiple-choice answers.

Final wording should be decided on for the radio question; I think the options I listed cover the scenarios we want to track.  The more specific we are here, the better we can track why a problem is not solved.
To follow up on Matthew, the sooner the final wording for the radio question is agreed upon the better.

Check https://bugzilla.mozilla.org/attachment.cgi?id=350505 for the current wording in action.
Here's my suggestion:

- I will follow up later to continue solving this issue
- The helper was unable to solve my problem
- I never got a response from the helper
- My chat ended before it was finished

Some rationale for the ones I removed:

I agree that the last option ("I gave up on solving my problem through live chat") is not really saying anything, and it also sounds a little miserable that we'd even offer such a reason. We could might as well include "I'll uninstall Firefox and never look back" too, if you know what I mean. :)

Also, the difference between "helper didn't understand" and "helper didn't know the answer" is minor to say the least; hence the merging of the two.

Rationale for the kept options:

The first one is a distinct reason -- I am still working on fixing the problem.

The second one is another distinct reason -- The helper couldn't solve the problem.

I'm assuming that we're trying to track known technical problems with the two last options. Correct?
I agree that the simplified options are better.  In addition to those, we might also want to offer:

*I never got a response from a helper
*The chat was taking too much time

The first option is needed to track chats that drop before a helper ever answers.  There are quite a few of these in the logs, due to users being disconnected early or an agent not joining the chat.  In the future, it would be good to allow users to type a short explanation so we can track down any bugs here.

The second option is needed because many users leave after a chat has been continuing too long.  This also covers most of the people who would answer that they "gave up", without being so negative.
(In reply to comment #13)
> Here's my suggestion:
> 
> - I will follow up later to continue solving this issue
> - The helper was unable to solve my problem
> - I never got a response from the helper
> - My chat ended before it was finished
> 

I would change "I never got a response from the helper" to "I ended the chat because the helper wasn't responding"

I know the first one probably covers it, but I think there's also the issue of time. It could really fit in the second one as well or be its own option "I've run out of time to continue trying to solve this issue" (sorta the same as the first, but the user may not come back, which makes the first option different).  Or change the second to "The helper was unable to solve my problem in a timely manner." which can cover both the case of the helper giving up and also the user ending the chat because they gave up.
(In reply to comment #15)
> (In reply to comment #13)
> > - I will follow up later to continue solving this issue
> > - The helper was unable to solve my problem
> > - I never got a response from the helper
> > - My chat ended before it was finished
> 
> I would change "I never got a response from the helper" to "I ended the chat
> because the helper wasn't responding"
> 


Why the "I ended the chat because" part? We don't use that for the other options and the main question is "Why were you unable to resolve your problem?"

So, how about this, then:

- I will follow up later to continue solving this issue
- The helper was unable to solve my problem
- The helper wasn't responding
- the chat ended before it was finished
- The chat was taking too much time
Attachment #352146 - Flags: review?(nelson)
Attachment #352146 - Attachment is patch: false
Attachment #352148 - Flags: review?(nelson)
Attachment #352148 - Flags: review?(bugs)
Key file location is arbitrary, and it can be changed to whatever on line 95 of tiki-feedback.php.
Comment on attachment 352148 [details] [diff] [review]
Adds live chat CSAT features to tiki-feedback.php

The patch looks good, I still need to test it with a salt file and a link generated by the fastpath code.  There are a couple issues with the links:

>+	$returnLinks[] = array( 'text' => tra("View this session's chat log"), 'url' => "https://chat-support.mozilla.com:9091/plugins/fastpath/chat-conversation.jsp?sessionID=" . htmlspecialchars($_REQUEST["chatId"]) );

This link depends on chat logs being public, bug 456843, which isn't being fixed for 0.8.  So, this needs to be removed for now, but inserted once that bug is fixed.  Depending on how access is allowed with that bug, a hash value may be needed in that link.


>+  	$returnLinks[] = array( 'text' => tra("Ask your question in the forums"), 'url' => "/tiki-view_forum.php?forumId=1&openpost=1&comments_title=" . urlencode(htmlspecialchars($_REQUEST["question"])) . "#new_question");	

This link needs to include the helpers' nicknames in the question title.  The format should be "Helper nickname: question".  (So $_REQUEST['helper'] . ': ' . $_REQUEST['question'])

(The potential security issue of having variables passed into a url parameter like this is mitigated by checking the passed hash.)
Comment on attachment 352148 [details] [diff] [review]
Adds live chat CSAT features to tiki-feedback.php

I'm concerned about:

$salt_f = "/var/www/livechatcsat.txt";
 
It may have dependency on file system permissions. Can you detect and use the TikiWiki temp directory instead?

zzxc: have you tested this and does it work for you?
Attachment #352148 - Flags: review?(nelson) → review-
BTW, does this patch (In reply to comment #21)
> (From update of attachment 352148 [details] [diff] [review])
> I'm concerned about:
> 
> $salt_f = "/var/www/livechatcsat.txt";
> 
> It may have dependency on file system permissions. Can you detect and use the
> TikiWiki temp directory instead?

Or should this go in the db as a tikiwiki pref? I don't know. But use something that works on all systems.
OK, checked with zzxc. This file needs to be somewhere on the server that is not generally exposed to the public, as that would allow anyone to fill out fake feedback polls.

IT will need to manually put a file onto the server. Eric, I think we will need a configurable Tikiwiki pref to specify this path in an admin screen, once it has been decided.
After a brief chat with Nelson, it was decided that the key file location will be a preference defined in tiki-admin_system.php. I'll post a new patch for this and the revised exit links shortly.
Pref added for file location in tiki-admin_system.php. No default is assigned, so tiki-feedback.php will not work for livechat until one is assigned.
Attachment #352148 - Attachment is obsolete: true
Attachment #352329 - Flags: review?(nelson)
Attachment #352148 - Flags: review?(bugs)
Attachment #352329 - Flags: review?(bugs)
Comment on attachment 352329 [details] [diff] [review]
Revised links and key file pref added

QA should double check CSAT functionality for wiki/forum
Attachment #352329 - Flags: review?(nelson) → review+
Comment on attachment 352146 [details]
CLI PHP script to add new poll options and questions for live chat

Laura, remember to include this in push bug. 

Also, do we need separate bug to get IT to run this on support stage?
Attachment #352146 - Flags: review?(nelson)
Attachment #352146 - Flags: review?(laura)
Attachment #352146 - Flags: review+
Yes, please file a  bug re:support-stage.
Comment on attachment 352146 [details]
CLI PHP script to add new poll options and questions for live chat

The multiple run detection doesn't work right:
$result = mysql_query('
        select count(*) as legacy from `tiki_polls` where title="Live Chat Support"');
if ($result["legacy"])...
You need to convert the resource to something you can use via mysql_fetch_assoc or similar.  (Please test)

It would be nice to have a cleanup option/script as well.
Attachment #352146 - Flags: review?(laura) → review-
Eric, can you please review and test with Matthew's sample URLs?  (Supplied here: https://bugzilla.mozilla.org/show_bug.cgi?id=458713
) 

Then check in your code, and the two of you need to co-ordinate testing on support-stage.

Please do this as a matter of urgency, we need to get this release finalized.
Severity: normal → blocker
bug 458713 made a few changes to the intended link structure (i.e., the question is now supplied by the feedback param instead of the question param, type is now "chat" instead of "livechat"), so I made a few changes to reflect that.

The test links in bug 458713 work with this patch on my local dev instance.
Attachment #352329 - Attachment is obsolete: true
Attachment #352531 - Flags: review?(nelson)
Attachment #352329 - Flags: review?(bugs)
Attachment #352531 - Flags: review?(bugs)
Ran and tested against my local dev instance.

Laura, I'm not sure what you mean by cleanup. Removal?
Attachment #352146 - Attachment is obsolete: true
Attachment #352533 - Flags: review?(laura)
Attachment #352533 - Flags: review?(nelson)
Just as a note:

We'll need the db script (it just adds the new poll options and questions) run on support-stage and the key file made and defined in tiki-admin_system.php before we can test this.
Attachment #352533 - Attachment mime type: application/x-php → text/plain
Depends on: 469129
Comment on attachment 352533 [details]
CLI PHP script to add poll questions and options with functioning check this time

IT run this script request at bug 469129
Attachment #352533 - Flags: review?(nelson) → review+
Comment on attachment 352531 [details] [diff] [review]
A couple changes to reflect changes in the URL structure

in r20740/r20742.

zzxc, this bug is fixed now, right?
Attachment #352531 - Flags: review?(nelson) → review+
Attachment #352531 - Flags: review?(bugs) → review+
Comment on attachment 352531 [details] [diff] [review]
A couple changes to reflect changes in the URL structure

Looks good to me.  Feedback polls are working properly with the links generated by bug 458713.
I've mentioned it a few times, but now that the db script has been ran, this key file needs to be placed on the system in a directory that PHP has read rights to and then the location needs to be defined in tiki-admin_system.php.

This is what will be preventing folks from falsifying csat information and is currently neccessary for the live chat csat (but not forum csat).
Key file is on support-stage. Someone just needs to put the file location in tiki-admin_system.php.

https://bugzilla.mozilla.org/show_bug.cgi?id=469335#c1

(In reply to comment #37)
> Created an attachment (id=352652) [details]
> Key File that needs accessible by PHP and whose location needs to be defined in
> tiki-admin_system.php
> 
> I've mentioned it a few times, but now that the db script has been ran, this
> key file needs to be placed on the system in a directory that PHP has read
> rights to and then the location needs to be defined in tiki-admin_system.php.
> 
> This is what will be preventing folks from falsifying csat information and is
> currently neccessary for the live chat csat (but not forum csat).
Can we mark this as fixed. The redirects/links coming from the latest patch from bug 458713 are working great.

http://support-stage.mozilla.org/tiki-feedback.php?hash=5e3da909f541e9e5fca973c65f02b32cbed70124&chatId=8qM8RV80Ti&feedback=This%20is%20a%20question%3F&helper=zzxc&nickname=%E5%87%BA%E5%85%B8%3A%20%E3%83%95%E3%83%AA%E3%83%BC%E7%99%BE%E7%A7%91%E4%BA%8B%E5%85%B8%E3%80%8E%E3%82%A6%E3%82%A3%E3%82%AD%E3%83%9A%E3%83%87%E3%82%A3%E3%82%A2&type=chat

http://support-stage.mozilla.org/tiki-feedback.php?hash=9c4836330d34cd6fe64450fe85a8bc8221ada576&chatId=gsVQs38BHA&feedback=12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234&helper=zzxc&nickname=Name%20Name%20Name%20Name%2012345678902384092834093820982347812end&type=chat

And this one I already did the poll for, so we get the "You already left feedback error":

http://support-stage.mozilla.org/tiki-feedback.php?hash=3e5d7afdfeb473231917b2b1bca44f4b9f80b57a&chatId=8qM8RV80Ti&feedback=eeqqqq&helper=zzxc&nickname=test&type=chat
Eric, as assignee, it's your call when it's fixed :-)
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Verified FIXED; I took the polls in comment 39 just fine.
Status: RESOLVED → VERIFIED
Attachment #352533 - Flags: review?(laura)
(In reply to comment #16)
> (In reply to comment #15)
> > (In reply to comment #13)
> > > - I will follow up later to continue solving this issue
> > > - The helper was unable to solve my problem
> > > - I never got a response from the helper
> > > - My chat ended before it was finished
> > 
> > I would change "I never got a response from the helper" to "I ended the chat
> > because the helper wasn't responding"
> > 
> 
> 
> Why the "I ended the chat because" part? We don't use that for the other
> options and the main question is "Why were you unable to resolve your problem?"
> 

Wanted to answer this question in case this survey is ever retooled.

The reason is sometimes the user actually ends the chat themselves, and sometimes they get dropped. So when a chat ends it happens because:
- user and helper agree (follow up later would fit here)
- user chooses (ran out of time, helper never responded)
- helper chooses (should only happen in terms of abuse, but it's possible helper had to leave and no one could take the chat)
- software fail

From the user's perspective though it's basically these 3:
- we agreed to end the chat
- I ended the chat
- The chat ended without me

So as the question is currently worded we could get people choosing this because they gave up or because the chat dropped.
Whiteboard: tiki_feature
What functionality has to be upstreamed? Live chat is not part of tiki.

There is something about tiki-feedback. What is the general purpose of it?
Whiteboard: tiki_feature → tiki_feature, tiki_discuss
Matthew, could you possibly clarify what should be upstreamed?
The purpose of this is to allow feedback polls to be generated by external Live Chat software.  This should be upstreamed along with the rest of tiki-feedback.php, as one acceptable type of feedback.

This functionality relies on a forum metadata feature in commentslib.php from bug 495740, which will need to be upstreamed as well.
Louis-Philippe: Is comment 45 enough information?
tiki-feedback.php will not be upstreamed.

As for the metadata, I find it hard to upstream code that does nothing on its own. There is also an issue with it being specific to forums. I don't see exactly why it could not apply to anything.

The library part of the code is not significant. A few functions at most. All of the calls to them are sumo_only. It might be better if the functions were moved to a different library (metadatalib?) and be kept sumo_only for now. They could be moved to trunk when the rework on forums/csat/feedback happens.
Whiteboard: tiki_feature, tiki_discuss → tiki_feature
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: