Page MenuHomePhabricator

Nuance
Updated 3,092 Days AgoPublic

Version 5 of 7: You are viewing an older version of this document, as it appeared on Nov 1 2015, 2:19 PM.

Overview

Nuance (previously Pebkac) is the codename for the human work item application (e.g. customer support tickets, machine failure remediation) within Phabricator, with the initial feature set focused around customer support. Its name is an acronym which stands for "problem exists between keyboard and chair." Despite this goofy name, nuance takes customer support very seriously, enabling users to track customer issues all over the Internet and respond as closely to the source of the complaint as possible.

And of course, we'll pick a better actual product name that doesn't imply the problem is with the requestor.

Object Overview

  • Source
    • User-defined "source" of items
      • Example 1 (pull) - Twitter posts with Phabricator in them
      • Example 2 (push) - Emails to 'helpme@example.com'
    • Daemons periodically do pulls for Source objects that need them
  • Item
    • Identified by a Source.
    • Further communication resides within Phabricator *and* medium defined by Source
    • Daemons periodically do pulls for Item objects that need them.
    • Content is also pulled at view time for Item objects that need updates
  • Queue
    • Grouping of Item objects.
      • Source objects can specify which queues to put Item objects in
      • 1:1 or based on additional conditionals, Herald-style
    • Each Queue specifies the Actions that are appropriate to take against any Item in the Queue
    • Workers pull items from these queues to work
  • Requestor
    • Actor - typically a person - that was picked up by a Source to make an Item
    • Requestor may not exist
  • ItemSource
    • Mapping object of Items and Sources
  • ItemQueue
    • Mapping object of Items and Queues
  • RequestorSource
    • Mapping object of Requestors and Sources
  • Action
    • A given Source has a set of Actions that can be taken against any Item from that source.
    • A given Queue has a set of Actions that can be taken against any Item in the queue.
    • A given Action has permissions associated with it; not all workers will be able to take all Actions.
    • These are all "hard coded" - for example, the code to reply with a tweet - with configuration such as what Twitter account to use to reply to a tweet.
    • An Action is always displayed, and if it cannot be taken explains why. For example, "Requestor twitter handle is unknown."

Product Overview

Nuance has

  • worker home page
    • shows Item the worker owns that are "open"
    • shows recent Items from Queues the worker cares about
    • shows stats on all Queues worker can see
    • shows stats on worker's throughput
  • Requestor home page
    • shows Items the Requestor created that are "open"
    • shows Items the Requestor created that are "closed"
  • Item view for worker
    • 3 columns
      • left column for transactions and writing
        • most recent transactions first
        • composer text area appears above most recent transaction
      • mid column for actions
      • right column for requestor data / other data.
  • Item view for Requestor
    • 3 columns
      • left column as for worker
      • mid column has less actions
      • right column
        • statistics about turn around time, etc for Queues this Item is in
        • list of any other Items for the Requestor
  • Queue view
    • shows recent Items that are open
    • shows list of automation rules that run on this Queue
  • Queue create / edit / delete
    • metadata
    • automation rules
  • Source view
    • shows recent Items that are open
    • shows list of creation rules that run as part of this Source
    • shows list of queue routing rules that run on Items made via this Source
  • Source create / edit / delete
    • metadata
      • silly data and creation rules
      • UI will differ based on Source type (e.g. twitter vs email)
    • queue routing rules
      • default to 1:1

Workers operate on the Item object primarily. When workers interact, communication "automagically" happens as close to the Source as possible -- e.g. twitter complaints get tweet backs or whatever the kids call those things these days.

The Item view should

  • surface all known communication for the Item
  • surface pertinent information about the Requestor(s) facing the problem
  • be designed for both throughput and accuracy

The Item view should also be viewable by the Requestor(s) though with pertinent information and abilities stripped out and new ones added. Requestors should also have a list of their other Items handy on any Item view page.

If a Requestor contacts again on the same via the same Source, if there is any open Item the communication is added there. This serves to aggregate Items from zealous customers.

Items benefit from an organization mechanism known as Queues. These can represent problems or types of problems, or otherwise be used as an arbitrary mechanism to group Items for processing based on the Source and other criteria. The worker home page should show the various Queues and the status they have.

New User Experience

  • Administrator can configure who can create Queues and Sources.
    • Defaults to Administrator only on basic install
  • If no Queues or Sources and no permission to create them, standard permission error.
  • If no Queues or Sources and permission to create them...
    • Explanatory "workflow"
      • Page 1 - explain product in brief
      • Page 2 - create Queue IFF none exists
      • Page 3 - create Source IFF none exists
        • Suggest email by default
      • Page 4 - instructions on how to generate an Item using Source
  • If Queues and Sources, standard home page.

Desired Source Types

  • twitter
  • facebook
  • quora
  • stack overflow
  • email
  • web form on Phabricator
  • Phabricator applications (Maniphest, Ponder, etc)
  • IRC

Desired Actions

  • Phabricator support
    • password reset
    • username change
    • name change
  • foreach Source type, ability to reply directly to Source

Corner Cases

  • N Sources could create N Items for the same actual communication (example - user tweets "I hate Phabricator btrahan!" and there are two sources for twitter - one for Phabricator and one for btrahan)
    • Only one Item is created...
    • ...but it is in multiple queues...
    • ...and has multiple sources...
Tags
None
Referenced Files
None
Tokens
"Like" token, awarded by michiel3."Love" token, awarded by flavio.santos."Like" token, awarded by vkcr."Like" token, awarded by Luke081515.2."Like" token, awarded by supervacuo."Like" token, awarded by hwinkel.
Last Author
tycho.tatitscheff
Last Edited
Nov 1 2015, 2:19 PM