Support/Live Chat/Web Client PRD

OBSOLETE PAGE

use Support/Live Chat

Introduction

A web-based Live Chat web client for contributors, tightly integrated with other areas of sumo, will help us solve some of the challenges we are facing in Live Chat. Goals should be to make 'casual' helping easier, while allowing core helpers to participate more effectively.

A major problem with casual helping in Live Chat is that community members pressure themselves to show up and be helpful. While this self-motivation has caused many dedicated, core community members to join our project, people without enough time to commit or who spend too much time have been driven away. Since there exist pressures to show up regularly, and since helping can take a long time, some community members help more than they can before leaving in frustration. Hence, we want to limit pressures that community members place on themselves, without placing limits on our core community.

Live Chat functions best as a community rather than as individual helpers answering questions by themselves. When community members are actively communicating and sharing information, problems tend to be solved quickly and helpers have more fun. One or two core community members can assist several newer members solve questions quickly, maximizing user satisfaction and gratifing new community members who successfully help people.

So, some high level goals for our web client project are:

• Integrate with SUMO
• Features to encourage operating as a community
• Reduce time pressure and implied committments
• Features to make helping more effective and to eliminate frustration

Current issues and how we might fix them

Some observations about the current experience with Spark

• We average between 10-15 helpers per week, with relatively high rates of both new helper signups and helper drop-offs from week to week
• Each shift is anchored by at least one core community member or team member. Impromptu shifts by room monitors are encouraged when people want to help outside of official hours.
• Transfering a chat requires finding a willing helper, then waiting for the helper to accept. Transferring a question to the forum is not as discoverable as it could be. Finishing a single chat can take up to an hour, depending on the speed of the user and the contributor.
• All helpers must install the Spark client, which some potential helpers have problems with or don't want to do. It requires a rather large download, which may put off some volunteers. Less than one half of new chat accounts sign into Spark.
• Helpers tend to make implicit commitments to show up on a regular basis, mainly caused by a desire to not leave others alone with the queue. Since helping for a single shift often ends up taking over an hour, the time committment can easily become too much.

How the web client should help with some of these challenges

• Participation: More chat helpers will likely help in the forum each week, and more forum helpers will likely help in chat. The result will be higher unique contributors in both.
• Chats take a lot of time: Transferring a question will become as easy as possible. Prominant buttons allow transferring a question back to the queue (with pre-defined reasons) or to the forum. If someone has to leave, it should be quick to transfer all questions away and leave in < 2 minutes.
• Barriers to entry: Prospective helpers can read the instructions page, fill out the registration form, and sign into the client within 5 minutes. The "How to Contribute" page mentions the current status of live chat, so that people know when to come back to find us open.
• Integration with SUMO: We can do a lot more to integrate with SUMO. Useful SUMO features should be shared in live chat so that chat helpers can easily work in the forums or KB.
• Pressure to help: By allowing chats to end quicker and by reducing the barriers to enter, we can reduce the pressure to stay. Higher numbers of unique helpers reduce the pressure on individual helpers, and allowing contributors to help for any length of time - from 10 minutes to 2 hours - will reduce the pressure to block out time to help.
• Frustration with Spark: Helpers can accidentally close tabs before they are done, forget to respond to chats, or not realize that a chat is still going. We need more effective notifications and confirmations before a chat is closed, both to increase user satisfaction and decrease helper frustration.

Requirements, proof-of-concept

• Beginnings of new framework, refactoring functionality into discrete components
• Simple client consisting of a web page that can:
  • Join a Fastpath workgroup
  • Join the Contributors conference
  • Receive/accept chat offers
  • All chats displayed in a single tabbed interface, animated via jquery, with basic notification of active tabs.

Requirements, milestone 1 (Quarter 3, 2009)

• Should use the existing Fastpath Webchat framework to save time and make use of existing Fastpath functionality.
  • This client is currently structured as a Java Servlet which uses Smack to make connections to an Openfire XMPP server. All interaction with the web client is currently through simple JSP pages that use DWR for communication with the servlet.
  • Needed structural changes: Add unit testing, separate Fastpath functionality into discrete components, abstract ajax client interaction into widgets, add internationalization support.
• User connections to the client must be persistent.
  • Replace current JSP pages for each feature with abstract 'widget' code, as multiple features need to be displayed at once without iframes.
  • The internal state of each feature must be stored in the servlet, so that session restore can be implemented in milestone 2.
• Support for notifications.
  • Notification bar should pop up on invitations, chat offers, and other important events.
  • Audible notifications on invitations, chat offers, new messages
• Support for multiple chatrooms in tabbed interface
• Support for most important Fastpath agent functionality
  • Receiving chat offers
  • Automatically joining Contributors conference
  • Canned responses
  • Display chat metadata. (Question data, plugins, etc)
  • Personal status. (Away, available, etc)

Requirements, milestone 2

• Existing webchat code (for users seeking help) should be adjusted for the new framework, with no regressions from production.
  • Other items from the live chat roadmap should be fixed simultaneously.
• Basic session restore support. (An agent must be able to close the window, log in again, and be rejoined to all chat rooms)
• Switch to XML configuration files for all SUMO and Mozilla-specific text and functionality.
• Support for chat roster (contact list)
  • Show helpers currently online, as well as the status for each helper. Double clicking on a user should open a private message.
• Implement status widgets
  • Metrics page showing current number of chats in queue, etc. (In screenshot below)
  • Chat status widget showing all chats currently active.
• Additional Fastpath functionality
  • Room monitoring
  • UI for chat tags. (Currently used via bot commands)
• Fastpath improvements for helper retention
  • "Cold transfers" back to queue
  • Integrate KB search into client.
  • "Transfer to forum" button. (Should automatically add helper to the new thread's watch list, as well as alert Contributors when the user posts)
  • UI for setting maxchats.

Requirements, milestone 3

• Should be stable and comfortable to use on a daily basis
• Color coded chat tabs to allow agents to reply to older messages first.
• All milestone 1-2 features should be functional and QA tested, with no regressions from Spark.
• Integration with modules from Contributor Home Page. (Show modules in web client when live chat is closed, and show chat status on contributor home page)

Requirements, future

• Integration with either SUMO (tiki) login or with LDAP login, depending on webdev plan.
• Improve helper experience
  • Auto-complete tags and KB article names
  • Integrate with scheduling solution (see live chat roadmap)

Mock-ups, milestones 1+2

Log-in screen

Mock-up of client for contributors

Initial pen drawing mockup of concepts

Asking a new question

Waiting in queue

Talking to agent

Transferred back to queue

Chat ended

Continue chat

Time requirements and technical details

The Live Chat web client will need to be based off of the current Fastpath Webchat codebase, written in Java. Most of the coding will be in Java or in Javascript using the DWR framework. The estimated time requirement is at least 60 hours, with several tasks that will likely need to be done by me.

• (Done) Upgrade DWR to latest version (Bug ??????, Matthew, 3-4 hours)
• (In progress) Code refactoring to support expanded functionality (Matthew, 10-20 hours)
  • Session restore
  • Implement modes for client. (User, helper, monitor, admin, etc)
• Implement basic jabber conference features into Fastpath web client (20 hours)
  • Main roster pane, roster for groupchats
  • Private messages
  • Tabbed interface for multiple conferences
  • Invitations and notifications, prism support
• Core Fastpath functionality (~5 hours)
  • Canned responses via dropdown menus
  • Chat 'offer' notifications
  • Room monitoring
  • Joining a workgroup
  • Viewing queue statistics and questions in queue
• Improving chat experience for helpers (4 hours, Matthew)
  • Color-coded chat tabs
  • Easy functionality for "Follow up in forum" and "Transfer chat"
  • Sound notifications on new messages, when message has been waiting on a reply for X minutes
  • Display live chat status and/or the next time it will open
• Integrated SUMO functionality (3 hours)
  • Integrated KB search
  • Dropdown of weekly common issues
  • Embed a rotation of objects from Contributor Home Page (eg. forum posts) when chat is closed.
• Testing, bug fixing, polish, UI (at least 10 hours)