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:
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.
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 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.
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.)