Web Site Feedback Management

Discuss the feature articles on the Tech Home Page.
Locked

Do you agree or disagree with this article?

I have no opinion
4
100%
I have no opinion
0
No votes
I have no opinion
0
No votes
 
Total votes: 4

User avatar
McDanielCA
Member
Posts: 486
Joined: Wed Jul 18, 2007 4:38 pm
Location: Salt Lake City, Utah

Web Site Feedback Management

#1

Post by McDanielCA »

Web Site Feedback Management was originally posted on the main page of LDS Tech. It was written by Karl Naegle.

-------------------

“If you want to make a correct decision or solve a problem, large groups of people are smarter than a few experts.” —James Surowiecki

A Problem for Consideration


The goal of increased efficiency and lower costs is nothing new in the tech industry. At the Church, those pressures are acutely felt, along with the moral obligation to wisely spend the widow’s mite. I’d like your help and suggestions on the best approach to solving a problem.

The Church sponsors and supports multiple outward-facing Web sites, such as LDS.org, Mormon.org, Provident Living.org, and stake and ward Web sites, to name a few. Most of these sites provide a way for site visitors to offer feedback. We need the capability to uniformly and consistently track, route, and reply to feedback from member and nonmember visitors to the various LDS sites we now support.

The problem is this: the existing process for screening, routing, and responding to submitted feedback is slow and labor-intensive, will not scale to the future needs of the Church, and is incapable of supporting multiple languages.

Please consider the following questions:

  • What options should the technical staff here at the Church consider in the next version of this service?
  • Are there credible existing commercial solutions?
  • Is a custom application the best alternative?
  • Is a mix of custom code and existing commercial applications an appropriate approach?
  • How would you solve the problem?
User Stories


The Web Site Visitor User Story


A non-English-speaking visitor to a Church Web site notices content on one of the sites that is confusing or objectionable in his or her local dialect. The user clicks through the feedback link and is taken to a local page with the same look and feel and the same top-level URL. The user offers details regarding which phrase on the page is a problem, enters an e-mail address, and clicks Submit Feedback. Within a short time, the site visitor receives an e-mail thanking them for offering feedback and telling him or her in their native language that someone will be reviewing the feedback and may follow up if appropriate.
Of course, reply messages would be possible only for registered users having an e-mail address in their user profile, or those supplying an e-mail address with their feedback message.

The Content Owner User Story


The content owner for a given page receives an e-mail notification that there are one or more feedback messages requiring attention. The notification e-mail is based on the user’s subscription preferences maintained in the feedback management system. The content owner follows a link within the message and sees multiple messages, many in English, but at least one in another language. He navigates to the non-English feedback message and can see the original message text in one field, and the English translation in a separate window.

Note: The original message was also routed to a translator resource that the site owner identified when the page was released in that language. That translator resource has already processed the message, and that activity is recorded in a work log before the content owner receives the translation.

The content owner creates a change request to have the page modified (in a separate work request system) and creates a reply message that informs the feedback submitter that the page will be changed within a given time frame, and thanks the submitter for his or her assistance. This message is routed to the translation resource and then sent to the original site visitor. The content owner provides final resolution categorization and marks the feedback message closed.

Technical Requirements and Considerations


Requirements for a new system would include:
  1. Automatic routing of messages to the appropriate content owner of the page, channel, or site.
  2. Full control of the functionality and the look and feel of the feedback collection page.
  3. The ability to detect the language of the message and route to designated translation resources, if needed.
  4. The ability to reply to the submitting party, with translation, if needed.
  5. Reporting capabilities to track and age feedback messages
  6. Categorization of messages by type and site origin.
  7. User preference options to manage notification options (e-mail subscriptions).
  8. Tiered routing logic that will support up to three tiers of site organization.
The feedback management application should be Web-based. System pages created to manage the feedback can be in English, but the content of the feedback must support any language. To reduce complexity and provide loosely coupled integration between systems, feedback message submission should use a standard transport like Simple Object Access Protocol(SOAP). If the Web site feedback management system is unavailable, the site collection page should store the feedback message parameters locally until the service is restored.

A redirect to a common feedback collection page may be acceptable, but should maintain the look and feel of the originating page, along with the top-level URL. In addition, some sites like the maps.lds.org site wanted site-specific functionality, such as collecting corrections to the mapping data. A SOAP interface allows the site to create its own collection page tailored to the unique needs of the site or service. Any application capable of making a Web service call could leverage this feedback service – both outward-facing Web sites and inward-facing business applications, including heavy/rich client applications.

Once a message is received, the feedback management system should initiate a workflow to determine routing logic for content ownership and translation. The system should use a tiered approach, the lowest level of which is a page that can have a specific content owner. When a feedback message is received by the service, the routing engine checks for an entry associated with that page and places the message in the appropriate queue. If no content owner is found, the system will check the next tier for the owner of a group of pages that is called a channel. If a routing entry is found for the channel, the message is placed in that person’s message queue. If no channel entry is found, the system searches for a site owner and places the message in that person’s feedback message queue. The system should not allow a site to be defined without an owner. The defined routing logic and workflow is for page, channel, and then site. Translation resources can be defined and routed in the same way.

Reporting on system-wide metrics must be tracked for feedback resolution time frames and categories, and to provide escalation if messages are not processed within an appropriate time frame.

Summary

Creating component services like a Web site feedback system can increase functionality and shorten development times for Church sites and systems. Other functions could be packaged in a Web service model to similarly increase development productivity.

We appreciate your participation in our search for solutions. Again, please consider the questions posted at the top of this article and send feedback to Karl Naegle.
Locked

Return to “Featured Article Discussions”