Saturday, February 27, 2021

Feedback example

 Writing an application with Vue: 

 

Introduction: Vue.js is a progressive framework for building user interfaces. It is one of the most popular JavaScript frameworks to make it easy to build user interfaces from the grounds up in incremental manner. The core library is a view only framework and as such can be linked into web pages directly from a content data network. For example, if we want to build a feedback or survey solicitation system, the following article will help get started. 

 

Description:  A sample web page to be written in Vue could start with just the template, style and script as shown in reference 1. All of this can be in the same web page but Vue provides excellent integration with many other frameworks so it easy to package code in single file components that end with .vue extension. These can then be combined into the main page with the help of component declaration and use. Each view file allows specifying a template, script and style snippet. 

 

vue instance consists of a root Vue instance and includes a tree of nested, reusable components when the application is well-organized. The instance created with a dictionary for data and methods which tells the Vue’s reactivity system how to respond when the data changes from the user interface. There is a freeze method available which can prevent the existing properties from being changed but for the most part, a vue instance responds to the user’s directives. 

 

As with all user interface, the vue instance goes through a lifecycle and there are hooks available such as mounted, updated and destroyed so that the stages can be switched. All lifecycle hooks are called with their ‘this’ context pointing to the Vue instance invoking it. 

 

The syntax used to describe the template, style and scripts do not change from what the HTML expects them to be. The data binding happens with the “Mustache” syntax and can include raw HTML with the v-html directive. List rendering occurs with an iteration over an array specified with the v-for directive. Filtering happens with the v-if directive. 

 

State can be maintained to avoid re-rendering. This requires the use of keep-alive directive surrounding the component Together with data, methods and state, the vue instance can be successfully tested in all three forms: unit-testing, component testing and end-to-end testing.  

 

When we build a feedback or survey system, we simply define the template to comprise of the component items we want to show. For example, a five-star feedback rating system will comprise of those five stars as radio controls that can be turned on in sequence on mouse hover and all of them can be specified together in a single floating action button also called a ‘vue-fab’. This  vue-fab can then specify methods that can be as simple as logging the rating given by the user or making API calls for sophisticated actions.  

  

Conclusion: The framework provides incrementally adoptable components that can be mixed and matched to create a view and complex controls, logic and workflow can be broken down and packaged into granular and reusable components. 

 

Reference: 

  1.  The index.html for a rudimentary Vue.js application: 

<!DOCTYPE html> 

<html> 

<head> 

  <title>Sample application </title> 

  <script src="https://unpkg.com/vue"></script> 

</head> 

<body> 

  <div id="app"> 

    {{ message }} 

  </div> 

 

  <script> 

    var app = new Vue({ 

      el: '#app', 

      data: { 

        message: 'Hello Vue!' 

      } 

    }) 

  </script> 

</body> 

</html> 

  1. The sample application  

 

Friday, February 26, 2021

Feedback mechanism as an independent application:

 Requirements for feedback collection system as a stored application: 

Problem statement: Feedback is not the onus of component owners. It is a utility that spans components and features.  While they may choose to collect feedback at specific scopes, a utility can bring drag and drop ease of use while permitting those features to view the reports only later. How do we write an application for feedback collection? 

Solution: Since the feedback system does not take away any of the functionality of the underlying system and merely adds an option to the user, it can be packaged as an application that gives this option to the user. If it is part of the toolbar or available as a floating action button, it will be tiny as well as ubiquitous. All components expect a like or a quantitative rating or a qualitative input or a file attachment as convenient forms of user feedback. The scoped application merely collects them in a table that is unobtrusive to others in terms of functionality, performance, and security. Let us take a closer look at this feedback design system from the collection point of view. 

When the feedback collection is consistent across all components, it tends to have a schema. This data can be collected in a table and the size of the table can grow arbitrarily. Creating instances of the table scoped to the component, feature, or product for which the feedback is provided allows the number of such feedback tables to be finite and each allowed to grow as much as their usages. But when it is part of a scoped application, the size can grow considerably.  

The table itself must be generic to hold the most frequent forms of input. Extensions can allow customizations to be stored. The source information such as a Uniform Resource Locator of the page on which the control was displayed along with the query parameters become useful to track. A binary outcome might be sufficient for machine learning-based analysis later. 

The data from the transactional database can be rolled from the database to a data warehouse for periodic rollover of transactional tables. The feedback service would be rolling up the feedback and inserting it as a new record while deleting the archived ones. The historical information on the feedback is also useful for analytics which can independently be implemented with read-only reporting stacks.  This calls for a warehouse that can support a variety of reporting stacks. Archival of transactional records to keep the size limitation for the online transactional feedback system is sufficient even if the warehouse does not exist. The warehouse merely helps with the reporting stack to be read-only and independent from the online transactional tables. 

The front-end can be a JavaScript floating action button or a toolbar button. It can be written with Vue as JavaScript reactive framework. It could adopt the same theme as the overall theme of the application where the control is displayed.  

Conclusion: Separating the functionality of a feedback loop into an application and deploying it with other components and features of a web application is possible and beneficial to their focus. 

 

Thursday, February 25, 2021

Feedback Mechanisms continued...

 Telemetry and its storage: 

Problem statement: We discussed a mechanism to collect feedback from the users of a software application. This article follows up with the storage for the feedback. 

Description: When the feedback collection is consistent across all components, it tends to have a schema. This data can be collected in a table and the size of the table can grow arbitrarily. Creating instances of the table scoped to the component, feature or product for which the feedback is provided allows the number of such feedback tables to be finite and each allowed to grow as much as their usages.  

Some feedback could be quantitative, others could be qualitative or both. They can even become full-fledged surveys that can be customized. Others can be as short as a specially crafted Uniform Resource Locator that provides all the relevant information via previously crafted query parameters. A binary value might be sufficient in such a feedback. If only metrics were collected, it could be saved in Telegraf, InfluxDB and Grafana stack.

If the content varies a lot, it can be saved in key-value stores or non-relational data with as much convenience as that of a database. When this is collected from a multi-tenant's software, even the databases are separate for each customer. A collection service along with a load-balancer or a high-availability cluster mode storage nicely enables the scale out for an increase in traffic. The use of a service is favored even by platforms like Kubernetes that bring the best practice for hosting infrastructure. 

The data from the transactional database can be rolled from the database to a data warehouse for accumulation. In the absence of a warehouse, the services would be rolling up the feedback and inserting it as a new record while deleting the archived ones. The historical information on the feedback is also useful for analytics which can independently be implemented with read-only reporting stacks.  This calls for a warehouse that can support of a variety of reporting stacks. Using a warehouse also supports replacing the database with a data pipeline involving event processors. The use of event processors and the standard stream querying libraries is well-known for pipeline operations. These libraries support both querying and extract-transform-load operations because they deal with one event at a time.  

A data warehouse can be supported in the cloud with the help of virtual data centers. One such popular warehouse supports data ingestion in the form of JSON from data pipelines. The ability to perform queries over this warehouse follows the conventional Online Analytical Processing model and serves the feedback mechanism very well. Data virtualization libraries that make querying simpler, like Presto, is not needed because the data warehouse supports both querying and storage with a traditional query language. The data is also expected to be consistent between the tenants so there is no need for alternative solutions for any custom processing.    

Conclusion: The information from feedback can seamlessly make its way through collection services, storage tiers and reporting stacks for an end-to-end completion of a feedback cycle to improve the software offering. 

 

Wednesday, February 24, 2021

Feedback Mechanisms

 

Introduction: The User Interface for software applications is designed for human interaction, ease of use and convenience. One aspect of building this engagement is the collection of feedback from the user on the relevancy, timeliness and appropriateness of content. Most users will not hesitate to provide a feedback when they have genuinely come across a satisfying experience. The software maker has the options to provide some utilities to collect this feedback at those anticipated moments during the engagement process. For example, when a work note appears on a service request and it has mitigated a concern for the user, a feedback link will be appropriate to be positioned next to the work note such that user can enter her feedback. This article delves into the considerations surrounding feedbacks, their number, format, content and their tradeoffs.

Description: The most common form of feedback is a rating mechanism. A simple count of one to five stars is sufficient to capture the sentiment of the user if a particular interaction was satisfactory.  This is a quantitative assessment which can be followed up with a textbox for qualitative feedback. Together, they capture just enough information to help the maker improve or deprecate certain features and workflows. Such feedback mechanism finds great appeal at customer touchpoints that are mission critical and with high business value. It could be used at the end of a training or it could be requested at the end of a job submission. Long forms are sometimes a necessary evil in some workflows and the feedback mechanism is not only cathartic to the user but also ways for the maker to learn how to evolve the workflow in subsequent versions.

Not every feedback mechanism can include a survey or a form by itself. Some may simply be a yes or no answer. Others may involve a link to the user where the action of clicking the link alone is sufficient because it has been constructed with query parameters that convey all the relevant information to the maker. Feedback also can be solicited from devices other than the desktop by means of one-time messages to the user's personal handheld mobile devices. 

The opportunity to provide feedback is appealing to many feature teams but they are pigeon-holed in delivering what is required from their component. The customer, on the other hand, may find such request one too many especially if they are forced to become selective because it taxes them when the overall engagement could be considered laborious. Usability often finds feedback mechanism as conflicting with its goals. The right number of feedback requests at the right touchpoints in the customer engagement is undeniably beneficial but the process of making it just right is fraught with many players, processes and prone to negligence from periodic reviews. Most feedback mechanisms and the policies associated with them do not even appear in the functional design or the architecture of a component or feature. Developers arguably ask why the feedback cannot be a floating control that can latch on to any page shown from the web-application rather than the component having to provide or implement a suitable tactical utility. Test teams may even deprioritize it from their test plan because telemetry cannot be forced on the user. Finally, the collection of feedback is significantly dependent on participation which may vary from audience to audience if not for the vagaries of the components in the overall product. 

Indeed, interceptor mechanisms and floating controls are an incredible strategy for feedback collection because they remain perpetually available and bring consistency across the use of the product while relieving the feature teams from re-inventing the wheels. Where then can we find such examples of feedback collection if it weren't overloaded with other telemetry requirements. The commercial software products customer designed for consumer space is a great arena to find such examples.

Software such as MOpinion, InMoment, Clarabridge, Qualtrics, Feedbackify, Verint Foresee, OpinionLab, HubSpot, Survicate, and SurveyMonkey provide a breath-taking diversity in such techniques. Their offerings can be categorized as Voice of the customer tools, survey tools, Online Review tools, User testing tools, Visual feedback tools and community feedback tools. The right tool for the right feedback gathering requirement makes the process effective and efficient. At the same time, if there were no necessity to collect user feedback and if it could be learned by some other technique, that would not only relax the requirements but also enable the system to come up with an authoritative metric that would not be susceptible to user participation. One must however be careful to not relate cause and effect with this kind of a strategy since that will lead to errors which may skew the metric.

Conclusion: From the simple to the elaborate, feedback mechanisms provide various enhancements to a customer’s experience. Some of these are referred to in this article but the must all be enticing to the customer.