The First Real Feedback on API Canvas
First beta feedback is in. Some quick wins, one big defer, and a small change I’m genuinely proud of.
API Canvas cleared TestFlight review last week and went live for beta testing. This is worth celebrating — but a beta brings something else with it: feedback from living, breathing users. Here’s what my first real user found.
What Shipping to TestFlight Means
Whether you’re a solo developer, a small team, or a large enterprise, one thing is true of shipping: Before real customers download your app, everyone who’s used it has some stake in it. While this has value — building passion and investment in its success — it also carries the unfortunate drawback that everyone working on the product is biased.
As we build products, we get used to their limitations. After you’ve opened the request history sheet a thousand times, you don’t wonder why it’s a sheet anymore. It just is. But to a user who is running the app for the very first time, their outlook on that UI pattern is completely different.
Shipping to TestFlight means that you get access to those unbiased, fresh eyes. This gives you feedback you’d never otherwise get — and getting it before your app goes live means that you’re getting it from people who actually care about wanting the product to get better.
The Feedback
A lot of the feedback was small. One of the most fundamental ones was very simple: when duplicating a request, the only visual feedback is that the request name has “- Copy” appended to it — and that’s not enough if you’re not actively looking for it. This is the kind of feature request that made me nod my head in agreement — I’ve felt what it’s like to use interfaces that don’t provide enough visual feedback, and I don’t want my users to feel that way.
Get Eric Kumlin’s stories in your inbox
Join Medium for free to get updates from this writer.
But there were big asks, too — like making the request body editor into a much fuller experience. What’s there now works — you can definitely type JSON and XML into it, and the simple things like turning off autocorrect and capitalization are already taken care of. But what about auto-formatting, or even just auto-indentation on newline? From a user perspective, this is a valuable feature — but it’s one with a very high development cost. I want to do it, but it will take a lot of investment regardless of whether I use an existing library or roll my own implementation. Either way, the current plan is to defer it to v1.1 or perhaps v1.2 — as much as it pains me to do so.
I think my favorite feature ask so far has been improvements to the request history. This is one of the most fundamental features of an API client — it’s in every single one I’ve used, and it’s used to replay previous requests or grab something you’ve used before and modify it for a new purpose. But what if you’re working with 2–3 requests at a time and just want to quick-swap between them? It’s at that point that a user asks, “Why do I have to open this sheet every time I want to quick-swap requests?” And they’re right — they shouldn’t have to.
For this ask in particular, I weighed a couple solutions in particular. One possibility was to go all-in on a tab interface, like Safari; another was to allow users to swipe back and forth between open requests, like the app-switching gesture on the bottom bar of the phone. However, both of these options came with high implementation cost: a full-tab interface would require rethinking the entire layout in a mobile-first experience, while a swipe mechanism would be very difficult to work in while avoiding conflicts with system gestures.
I started thinking smaller, and had an idea to turn the request history button into a “tab switcher”, for lack of a better term. Instead of opening up the history sheet, it would instead give you a list of up to five of your most recent requests, with an option to go back and dig into more. It was a quick, surgical change — sometimes the right solution isn’t the most ambitious one.
Where Things Go from Here
The feedback so far has been invaluable, and the fact that the rollout of API Canvas has been gradual is an intentional move: it’s much harder to triage a deluge of hundreds of feature asks and bug reports than it is to work through five or so at a time. But a gradual rollout continues to progress, and so as more and more beta users climb on to test things out, then it will be time to open the floodgates.
Currently, API Canvas is still looking for testers; most of the 250 seats for the round-one beta are still available, so I’d love to have you on board. You can find the app through TestFlight by following this link or scanning the QR code below.
This article was originally published on erickumlin.com.
