Imagine this: it’s your first day at a new job. You walk the halls of the engineering department and can’t help but be mesmerized by the brilliant people you are about to work with. Competent, brilliant engineers building a product they love. A product I already loved. This was me back in 2012, when I set a personal goal: one day I will be able to add at least one line of code to this beauty.

Fast forward to three years later. Three years of intense hard work and immense fun delivering projects and teaching about this cool technology around the world had brought me the opportunity to contribute directly to the product. My very first hands-on task was set: modernize the ECT Provider!

“But what on earth is the ECT Provider?” you ask. The ECT (Embedded Change Technology) equips applications built using our technology with feedback mechanisms that allow the users to submit feedback where and when it’s most significant: inside applications.

OK, so maybe the name needed a little work. But so did the UI and UX! Don’t just take my word for it:

The good ol’ ECT. Kind of bland.

This was quite the challenge. So, of course we accepted it.

What’s in a Name? Its Look and Feel

The first task was coming up with a name that people could understand. ECT was not easy to understand and couldn’t really translate what that functionality was all about. As we dug deeper into how people talked about the feature, we heard that “ECT is a tool to collect feedback from apps.” That’s a nice explanation. So, what if we name it “App Feedback?” Short and sweet! First task done: our baby is named and we can now help it grow.

Now, before you start panicking over the thought of having engineers deciding the look and feel of the app, let me assure you we didn’t. We handed that over to the very qualified and awesome product design team. You know, the people who can tell the difference between red and blue. (Engineers are brilliant developers, but you wouldn’t believe the color combinations we wear every day. While our tech abilities grow by the day, our fashion sense seems to decrease by the hour.)

With the right skills and the right people, the new App Feedback dress code was decided. Based on some of our assets, App Feedback was given a grey stylish suit, with hints of red.

Some color and personality.

Are You User Experienced?

With the name and UI decided, it was time to work on the experience. App Feedback had many use cases. They were all laid out on the screens with the same priority and no real differentiation between them. Deciding which use cases to keep, to highlight, and to drop was not easy. But, with a couple of user tests and the right UX experts on it, we were able to understand that some of the use cases weren’t needed any more. For example, the old ECT allowed you to change the theme — something no one had done in 10 years!

It was obvious that the first thing people accessing App Feedback wanted to see was… the feedback. So, we made another change: we grouped the feedback by application, instead of by module as it used to be. Then, we brought the most significant information to the first screen: the device, the screen resolution and the browser in use.

The most relevant info right from the start.

The second most significant UX change we made was the screen where the actual feedback is seen.

Of course how things look and how they are used matters a lot. That’s why we invested so much in it. But, besides the beautiful layout and smart UX decisions, we also had a lot of technical fun with it. Yes, technical can be fun.

Collecting Feedback: A Journey for the Senses

Gathering feedback is boring only if you let it be. We didn’t want that. We wanted users to provide as much detail as they wanted. A screenshot wouldn’t quite cut it, so we worked on incorporating other ways to make feedback accessible for web applications and mobile.

Web: What You See is What You Get

For web applications, showing an image with a box and an arrow on top of it sounds easy enough, right? But it’s not really an image; there’s no technical way to capture a user’s screen content in a web page. It’s actually HTML that is collected by the server when the user clicks to send feedback. The coordinates that the feedback points to when the user clicked on it are also collected. All of this comes together to show an apparently simple page. Making the complex look simple goes a long way.

But you could ask, “What’s so hard about collecting HTML from a page and rendering it on a frame? And the answer is simple: pages are no longer just HTML (remember those days?). There are JavaScript, images, CSS referencing other CSS and images, and a whole number of things that developers come up with to make their pages look like they need to. And App Feedback needs to collect all of that. We don’t want people to wait while it’s all being collected. And, we want to show it to the developers as the rest of the world sees it. This makes the feedback real and meaningful.

Still, a number of questions remain unanswered:

How is page content collected?

What if I change my page? Will the feedback change also?

What happens to all URLs for images or CSS in the collected pages?

What about frames?

So Let’s Clear It Up

To collect page content, App Feedback has a process that makes an HTTP request to the page where the feedback was provided, so that all HTML is collected. That HTML is then processed to understand, for example, where images are used. With the URL of those images, a new HTTP request is made to get the original image and save it to the database. The image URL is then replaced in the collected HTML with an URL to App Feedback that will render that image or CSS whenever a browser is used for feedback.

The same happens to CSS, frames, and any other artifact that you include in your pages. When this process ends, App Feedback has a local copy of all artifacts that make up your web page and is able to render it, even if you change or even delete any of its contents.

Here’s a little snippet of what it looks like:

Mobile: Draw Me a Picture and Talk to Me

Because we think of mobile as the ruler of the world, shortly after we launched App Feedback, we had this idea to integrate it with one of our native apps. Of course, you could already provide feedback on a responsive app running on mobile. We could use the same method as in web, but it was not ideal. On a desktop, a little yellow ball doesn’t take up too much space; in a world before iPhone 7, having a little ball hovering over your mobile app was a big no-no. So we decided to integrate our app directly with App Feedback. Then, we could take advantage of the native capabilities and have an even better way for users to provide feedback.

It was the birth of a true screenshot, the ability to doodle directly on-screen and even provide sound messages to App Feedback. All this was made possible because we were running in a native application that had, at the time, a lot more capabilities than a browser-based application. (Note: this gap is narrowing as you read this. Check whatwebcando.today to get a glimpse of what a browser can do nowadays.)

App feedback, doodles and all.

But, while it’s simple to get a screenshot and a voice recording, we still needed to send it to App Feedback, which then had to show it by some means yet to be developed.

To have the feedback flowing from the app to App Feedback, we developed a JavaScript API so the app can submit all the details it needs, including an image, sound, and text. Then we developed the actual showing part. Showing an image is pretty simple, as you can imagine. But, sound? That was totally new for us.

Of course, we didn’t shy away from yet another challenge. We didn’t want to simply add a way for people to listen to the voice memo; we wanted them to have a player they could interact with directly on the browser. By using the tag and its properties, we were able to design and deliver a control that allows users to play, stop, and control volume directly on the feedback preview page.

Here’s a snippet to satisfy your curiosity:

A look behind the screen.

Connecting App Feedback to the World

So at this point, you might think we already had everything we needed to make App Feedback available in all mobile apps. However, having all that is needed available does not guarantee that developers would have a great experience integrating it with their apps. We wanted to take it one step further, and we did!

How? We made a new REST API available that enables you to provide feedback from any app you want. On top of this API, our UI Framework incorporated an easy-to-use block that you can use in your mobile apps and that will immediately enable your users to provide feedback in your apps by pressing the screen twice.

So Easy A… Patent Was Issued

So yes, from a user point-of-view it looks easy and simple, which is exactly how we intended it to look. But, don’t forget that underneath this simple facade, we have a complex and complete function that covers all of your needs. There’s really nothing like our groundbreaking App Feedback, so we got a patent for it.

Did You Know?

App Feedback integrates with several popular project management tools so that addressing user issues and comments when you update your app is easy. Check out our two blog posts that explain how you can integrate it with Asana and JIRA using OutSystems Forge components.