Support/Live Chat/Web Client PRD

< Support‎ | Live Chat
Revision as of 08:00, 26 March 2009 by Zzxc (talk | contribs) (Add more mockups)

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.


Ideas

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.

  • Upgrade DWR to latest version (Bug ??????, Matthew, 3-4 hours)
  • 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)