Developing user-friendly software and an amazing user experience requires listening to users. As a software developer, we rely on user feedback to continuously improve our data validation APIs. As a user, you may not feel compelled to provide feedback to software developers, but if you value a great experience, your role is an essential one.

Examples of user feedback collection mechanisms

You’ve likely encountered user feedback collection features in various forms. For example, Microsoft Office prompts you to click on a happy or sad face in order to express user suggestions. This simple menu is available from the File tab, allowing you to tell Microsoft what you like, what you dislike, and your suggestions.

You may also find that user feedback is naturally baked into installed software, accessible via the Help menu.

If you’re a .NET developer, you’re probably familiar with the Visual Studio Experience Improvement Program. The little helper icon in the top right of the program has become the ubiquitous symbol for feedback, client support, and general help desk tasks. With just a click of a button, users can instantly share their experiences with the software.

What about when an application crashes? You’ll often be prompted to send a crash/bug report to the developer. These reports may even contain hardware/software configurations, usage patterns, and diagnostic information helpful to developers — and all you need to do is click a button.

These are but a few of the many ways that modern applications send information back to the software company. Obtaining user feedback as well as any crash/bug report information is crucial to the development of a piece of software or service. This information helps software developers isolate where and why problems occurred, leading to product updates.

User feedback challenges: privacy concerns

But what about “Big Brother” or other potential snoops? With the various means of providing feedback and the different collection schemes (opt in / automatic), privacy concerns are valid. With these data collection tools baked into the software, it is hard to know how much information is actually being sent back to the company. It could range from the harmless crash/bug report from a software crash or diagnostic information to controversial GPS breadcrumb data.

However, many people don’t want other entities collecting data on them or analyzing their usage patterns. While not all software is intentionally spying on you, it would be nice to know what exactly is collected. More often than not, it’s unclear what’s collected and how it’s used. This lack of transparency concerning data collection inevitably leads to unease, which is why many users opt not to participate in “Experience Improvement Programs” and other data collection schemes.

Another challenge for developers is that not all companies have installed software on client’s devices, making data collection challenging, even when users are willing to opt in. For example, the normal avenues for collecting data, such as hardware/software configurations, from users are not seamlessly integrated with web-based technologies such as web services or certain SaaS. Many companies struggle with this and must use other means of getting user feedback.

Despite privacy concerns and a lack of openness, the bottom line is that user feedback is valuable. When utilized properly, the information can be used to fix existing problems in the software as well as lead to new features. The reason why subsequent versions of software are so much better than 1.0 is directly related to user feedback.

How Service Objects gathers user feedback

Service Objects does not collect data on clients, so the privacy concerns discussed above are irrelevant. Potentially sensitive data processed through our services is not monitored or collected. This is a highly sought after data validation “feature” for our clients, but at the same time, it presents a challenge for us to gather detailed user feedback.

We offer several ways for our customers to provide feedback: You can connect with us via phone (805-963-1700), email, and via support tickets.

Any user feedback we receive is taken very seriously and can lead to bug fixes, updates, and even new services/operations. A great example of this is the FindAddressLines operation in DOTS Address Validation 3. The operation was initially born to help a particular client and has been utilized to great effect to clean up messy address data.

If you have any feedback you would like to share to help us improve our data validation services, we encourage you to reach out to us at anytime.

In software development, there are two common approaches to architectural design. One school of thought, un-opinionated, is to make software agnostic and be as flexible as possible to allow the developer to make decisions on how to design and solve problems correctly. On the other hand, some believe the best software, opinionated, should only realize one true vision, the right way. This design paradigm suggests software should pick a side and stick to it. Following the opinionated approach, design decisions have been made already limiting the options available to the developer.

Opinionated Software

Some examples of highly opinionated software include Ruby on Rails, AngularJS and Ember. These software packages share the common characteristics of making certain tasks simple to the developer by following the already predesigned path, sometimes referred to as the “Golden Path”. Following this approach can be advantageous to a developer when a problem or task maps directly to one of these predesigned paths. This can, however, present challenges to the developer when functionality outside of a package’s design is desired, creating additional effort to solve.

Un-opinionated Software

In contrast, un-opinionated software such as the .NET technology stack offers the developer freedom in design choices. Some choices available to the developer include which language they prefer working in, be it C#, F#, VB.NET and virtually any language that is .NET compatible. Flexibility allows the developer to choose the right tool to accomplish a task. The potential downside of this is that with so much flexibility it may be difficult to develop a solution the framework does not provide assistance with, leaving less experienced developers with sub-par solutions.

Our Vision

Our vision is to offer developers the flexibility in the decisions they choose to make in integrating our services. Naturally, since our services are exposed over HTTP, they can be integrated with any language or platform that supports HTTP connections. The applications that are consumed by our clients follow best practices in architecture and input/output structures. This ensures flexibility in request/response formats as well as simplicity in obtaining results. As well, we are bound by the WSDL contracts we deliver to ensure consistency in response format.