Table of contents for the Transcript
General introduction [0:00-01:07], Jury Group - introduction [01:08-10:09], Certain aspects of developer portals that have changed over the time [10:10-15:20], Inspiring solutions and seamless developer journey [15:21-21:57], Things that would be better if they changed [21:58-25:40], Solutions that would be great to see more often [25:46-31:46], Closing thoughts [31:47-32:22], General closure [32:23-32:46]
Back to the DevPortal Awards 2022 Jury Interview page »
Transcript
Jury Group - introduction
Laura Vass: Welcome everyone to the interview with our juror group of the DevPortal Awards in 2022. My name is Laura Vass, and today, I'm interviewing Leah R. Tucker, Alex Akimov, Anthony Sansone, and Professor Michael Meng. Our four jurors have looked at 43 nominees across 13 categories. Well, altogether 11 jurors, and the four of you are one of the working groups among these 11 jurors. So let's start with introductions. Leah, you have been for more than 15 years in the industry, where you've held various positions in product management, engineering, and technical writing. And today you help companies launch their next generation platforms to the world. What prior experiences possibly gave you a pause, now as a juror or, well, I guess it's no secret that you've also been representing a former nominee.
Leah R. Tucker: So I, having been as a web developer documenting user experience standards and a technical writer, product management both for Sabre and now as a software integration engineer, applying all of those practices to next generation portals and platforms, it's hard not to notice each of those components, you know, and how the whole developer experience plays out. So I would say I'm looking at docs and the developer experience and how that comes across to an end user, to simply say. So I would say in terms of what gives me pause, those would be the primary components.
Laura Vass: Alex also used to represent a former nominee. You also have two decades of experience in the tech industry. And everyone who knows you, knows that you're very passionate about a great developer experience and everything that comes to it. Intuitive API design, versatile developer tools, simple and comprehensive technical documentation, and you work on empowering the developer community and to create authentic developer relations. Most people know you as the former head of API at Adyen. And now you're building the API platform at Monite, where the integration and the great documentation is the key for the companies who connect with the Monite APIs. Welcome, and the same question. How is it to now be a judge?
Alex Akimov: Hello everyone. I am super excited to be a jury member this year, and as you mentioned yeah, I've been working on developer portals for a long time myself. And since the start of this award, I was of course following everything what was happening. Every year we were submitting our applications, to follow the best practices and everything. And also we are super lucky one year that the Adyen developer portal won two awards. So it was really exciting to see and that this work was recognized. But now, when I'm also on the other side of this process, it's so amazing to see how much work it is actually behind all these nominees, how much work every jury member does, how many nominees we have, how many different great ideas every company puts into their developer portal. So it's an amazing hard work to pick some winners from that amount of great developer portals that you currently see in the industry. So really, my hat's off down to Pronovix, to all the jury members of the DevPortal Awards this year and then previous years, because this is impressive.
Laura Vass: Thank you. Anthony, you also spent more than two decades, about 25 years documenting and supporting computer hardware, software services, and you specialize in data protection and user security. Probably many people in the audience also know you as patron saint of the API The Docs and recurring speaker and educator. You have a very broad experience in developing and maturing people and processes in engineering teams. You've worked for startups and you've worked for large multinational companies, and now you're leading the technical writing team for Dart and Flutter for Google. Now, how is it to sitting in the jurors chair?
Anthony Sansone: I always find juries fascinating because you have to really dig into the specifics, the minutia, and do so in a timely fashion. So it's that flickering back and forth saying, 'am I taking too much time? Am I taking enough time?' So you wanna respect the work that people put in, which I was just blown away by all of the various various portals we saw and how much depth and interest and care went into everything. And I wanna respect that. I wanna say, 'Okay, look, I see what you've done. I'm not just blowing past it in two minutes to say let's get out to the next piece. But really trying to understand what's going on there.' And a lot of what I see is informed by, I'm not a developer by nature, my current job excluded, and I'm more somebody who works on the back-end of making sure things can run. So I always approach from that angle, saying, 'Okay, if I was to get this, and if I was trying to make this happen, could I? And that informed every decision I made as I went through saying, 'Okay, does this make sense? Is this something I can support? Is this something I could explain to somebody else?' Being a documentarian, you pay attention to what you could explain to somebody else and say, did somebody leave me with the "and then...?" or "why?" questions, and if they didn't, I knew that things were on a right path.
Laura Vass: Our fourth interviewee today, professor Michael Meng is our recurring juror. Welcome back and thank you again. You are a professor at the Applied Linguistics at Merseburg University of Applied Science in Germany. And you're now teaching courses on text analysis, text production, research methods, and cognitive psychology, both in the bachelor engineering and in the master of arts program in the technical communications. You regularly present at conferences such as the European Academic Colloquium on technical communication, at Write The Docs, or the annual tcworld/tekom conferences. How is it different from last year? Do you see any difference, and is that prior experience as a juror making you act differently this year?
Michael Meng: Well, hello everyone. It's great to be in the jury again. And for me, first and foremost, it's a great learning experience to see what the current trends are, the directions that different companies take, what emphasis they place on certain features and so on. And for me as a professor in working at a university, it's very important just to keep track of developments. I'm not a practitioner,so I'm not, as most of the other jurors, working every day on specific issues and problems. So it's even important for me to see what a state of the art and being part of the jury is, of course, an excellent opportunity to see what is currently being discussed and what is yeah, at the forefront of the discussion. Comparing to last year, I think there's not a big difference. I mean, we again have a very large number of companies that applied and that was also the case last year. But looking back, say five years, right? What you see is the interest has grown continuously. The overall quality I think has grown impressively. So a couple years ago we had some portals that really stood out. But it's different this year, and it has been different last year already. So we have many, many excellent portals. And as I already mentioned, it's very difficult to really pick a winner. And but of causes also a challenge because you really have to make up your mind and reflect on what real innovation is today and what could be the standard of tomorrow.
Laura Vass: It comes up at every choice that, 'Yes, we call it an Award for the Best, but in the end, it's ultimately a celebration, right?'
Michael Meng: Yes.
Certain aspects of developer portals that have changed over the time
Laura Vass: And do you see, and I'll ask Michael first, do you see a certain aspect or aspects of developer portals coming more into focus as opposed to how they were a couple of years ago, maybe abandoned or not really thought of?
Michael Meng: Yeah, I think some of the topics that we addressed in our jury do receive more attention today than perhaps a couple years ago, because portals now really address the entire developer journey. Things like findability, for example, are I think getting more important. API programs get more mature and grow and offerings grow. So companies spend more thought on how to make their offerings visible, how to lead potential users, customers to the offer that fits their needs best, right? Addressing the needs of different stakeholders and so on. So that is one issue. Then onboarding is also an issue. I mean, it has been an issue and regarded as important couple years ago, but reducing the friction, providing opportunities to test APIs immediately without deep technical knowledge. Providing stakeholders that are involved in the selection process, for example with appropriate offerings like business analysts or consultants. I see that the offerings that portals provide are getting more sophisticated, more mature, and more comprehensive.
Laura Vass: Do you see this similarly? I'm asking everybody else now.
Anthony Sansone: I would argue yes. The biggest difference I'm seeing now is a lot more channel-specific views. Like saying, 'Okay, hi, here's how you would apply this API in this industry, or in this manner,' rather than just saying, 'Here's the spec, go suffer.' They kind of walk you through what you need to understand for your specific use case for your specific company and industry, which I think is a nice touch. You can see the more mature portals get farther, much farther into that. The maturity seems to be specification, examples, self-testing example, then more into channel industry application. And that maturity is, and I'm not saying that's the end of the journey, but I know that that's on its way. And I'm very curious to see what it's gonna look like when we're past that, at this point.
Alex Akimov: I can totally subscribe to this point of view. I think there is a common trend because many companies now see more and more value of having great documentation. And it's not only the documentation team that is struggling with making it great, right? So usually there is also marketing department, now sales, developers, everybody in the organization, they come, they contribute and they want to see how this all is streamlined with the main website, with the main journey, how to make the user journey consistent throughout all the stages, and documentation is a super important part of it. And it's impressive to see, especially in some cases when the product is super complex and it's impressive to see how people manage to make a great documentation out of that, handholding basically a user through all the stages, through the first onboarding step to the moment they go live.
Leah R. Tucker: Yeah, I'd agree with that. Along the lines of what everyone else mentioned, it takes a village to create a world class developer portal. From technical writing to product management. You have to bring together the perfect developer experience for your target, target audience. So I saw more refined and clear entry points with solution finders, product catalogs to findability. And that becoming more of the standard over inside search, which I saw more in the past. Second dashboard-only versus technical integration audiences, and offering clear entry points at the very beginning of the user journey. Also, interactive portals I noticed more on cloning a sample, running a request, even deploy capabilities within the portal. So built-in tools that keep the user engaged is really exciting to see.
Inspiring solutions and seamless developer journey
Laura Vass: So my next question would be, what were the approaches that you really liked from the nominees, but you kind of went into that, this interactivity that you find interesting.
Leah R. Tucker: Yeah. The number of portals that continue to raise the bar on built-in tools was inspiring building developer experience into a portal. Also I saw much cleaner user friendly documentation, super short focus guides specific to one key user task or one programming language. So not the kitchen sink of tabs or options. Very clear paths and all of those different portal capabilities that allow you to accomplish what you're doing within the page.
Anthony Sansone: What a lot of it seems to be towards what Leah was talking about, this a more funneled approach now, where it's not, as you say "kitchen sink", it's not, "here's every possible piece of every possible component". A mature company, a mature developer relations team, developer experience team would say, 'Look, not everybody needs to know everything and they don't need to sift out themselves. Let me take the little extra bit of time of sifting this down for you so you can get down to the thing you need to work with, so you use our products, you use our APIs more and to greater depth, and you can try it out without having to actually commit much in terms of resource on your, on the customer side.' It builds that trust to say, 'Okay, look, not only are they trustworthy in terms of how they're protecting data, but they're also being trustworthy and how they're protecting our time, protecting our interest, keeping us engaged.' That's a change I'm seeing that I'm really enjoying I guess.
Laura Vass: Do you see this as a standard expectation by now from a software or business developer coming to a portal wanting to integrate? To be handheld on their journey or not yet, is this a novelty?
Anthony Sansone: I'd argue right now is kind of a novelty, but they should. The amount of developer to API work is decreasing in my mind that you're start seeing hand built prebuilt components that people just say, 'Give me the pieces I need to attach to, let me understand how that works and let me get on my way.' So it's become more... "commoditized" might be too sterile a word, but it's kind of coming to that point. And people who are ahead of the curve are making that more possible. People who have their APIs being used more as we see a lot of things, a lot of financial companies and so on and so forth, and their stuff is used, their APIs are used constantly. And that you can see that in the maturity of how they're documenting, the maturity in how they're putting things out, maturity of how things are used and testable and usable. That's where you can start seeing that maturity happen. And that's where I find it being interesting. Cause I also know how much efforts it takes to do something like this. And you can tell who put the time in, who put the money in, who put the resources against it, saying, 'This is a prime mover to our company. We need to make this more, more easily engaged, more easily usable.'
Alex Akimov: Yeah, I totally agree with that. And it's not easy to build an experience that hand-holds a user through the whole journey and provides all the necessary components of great developer experience, but there is more and more knowledge in the industry how to properly build that. There are more and more examples how to build that. And there is of course, certain expectations now within developers who will be using your developer portal that things should work in a certain way. And it's also in everybody's best interest to save time on how quickly developers can integrate with your product. And that's why I think more and more owners and creators of developer portals we'll try to implement this element into their portal, be it information architecture, content strategy, filtering mechanism, product catalogs, or maybe some wizards and other types of experience that helps people get to the point. Yeah, it's impressive to see how, how it's improving nowadays. And for example, if we take a look at API reference, it used to be just a big, long table or field names and some descriptions. And now what we can see in almost every developer portal is a pre-column layout. So basically it's easy to navigate, easy to find, and you also see the code examples in multiple languages automatically generated for you. And in many cases you can already try these examples, which really simplifies your experience as a developer. And this is just one of the examples that used to be a novelty, might be five years ago, but now it's more of an expectation and more and more developer portals demonstrate this in one way or another.
Michael Meng: I think this is a trend, and I think this definitely meets expectations of developers. So we've been doing some research on developer expectations and how they try to get into an API and which strategies they follow. And one of the results that stood out was this, different strategies. Those who need code examples and want to start with examples right away and don't want to read a lot, and others who try to understand the concepts first and then go onto the specifics of their problem. But you need to support all those different strategies, right? And using, for example, the three column layout is one of the obvious solutions to the problem. So I think we see things are moving in that direction and it's definitely a good move. And we also saw that, of course, developers, they do have a goal, they have problems they have to solve, they don't want to understand everything. So all features of a portal that kind of show the different paths you can take and show the way to a solution without having to get into every detail of the API program will definitely help.
Things that would be better if they changed
Laura Vass: Let me turn this question around: is there something you wish that would disappear?
Alex Akimov: "Disappear," you mean as a common practice, that is a common practice right now. Okay. Yeah. I can go first. I really want all documentation to be easily accessible for everyone. I think it's a great way to go in most of the cases, unless it's really, really private product that you don't want to expose to the public audience. But I want all yeah, basically, documentation behind login shouldn't be the norm in the industry. It's my belief.
Michael Meng: Definitely, so it should be public and you should get... this is also a matter of trust, of course. I mean, you really have to see what's there evaluated and if you need to provide a lot of data beforehand, I think that's not a good move. So I think many, many portals already do that. There were a few that... where there's room for improvement, so to say. But that's definitely very important point.
Anthony Sansone: I'm gonna be more basic and say that I would like to see more more atomic API resources. Not trying to do everything in one massive resource with multiple discrimination points and things like that, because those are just impossible to document and impossible to work with. And having field descriptions that are not just identifiers or circular reference where you say it's like, you know, "last name", "you know, last name of the person." No. Like, actually define it with some context as to why it matters in this particular thing. Give each field a full definition. Spend the time, respect the user, give them information, not just like, 'Oh, I have this field, but I have no idea what it does.' That's gotta stop.
Leah R. Tucker: I hope to see monolithic left navigation menus with every single product accessible in the cyclopedia to be a thing in the past. I have noticed a lot of the world class developer portals or the portals that we were looking at having those clear entry points from the very beginning: product catalog with filtering, having documentation at your fingertips without a whole lot of distractions in between, like, you know, the infinite number of things that you can do in the left nav. I hope to see navigation become cleaner and just a, 'I'm here to accomplish this, with breadcrumbs to help me get back to a central landing page where I can do something else.' Because I think I've seen that when developers are looking to accomplish a task, they're looking to accomplish a task at a time, you know, they're building out an integration, they might come back and forth. So monolithic navigation menus, I hope to see that go away.
Solutions that would be great to see more often
Laura Vass: It seems that you agree. So then turning around once more... In our prior discussions, looking at portals such things as localization, search, more powerful search and samples that you can totally download. These came up as "we wish" or "we applaud". What do you think about these aspects or other solutions that would be lovely to see more of, but maybe... Let's say the times are not ready for it, culture, legislation, technology, that it's at this point bordering sci-fi, but you wish it would be possible?
Michael Meng: What I would love to see is deeper integration of say, information resources and the actual development environment. I think something like context sensitivity, more sophisticated ways to get to the information that you need to solve a specific problem at the time when you need it, right? I mean, portals improved tremendously with respect to kind of search offerings and consistency of navigation and how they structure their overall offering, which of course also helps to kind of get to the content that you want. But yeah, a more intelligent and more automatic support, suggestion of topics, an easier way for the information, that would be cool. But I guess this will take a little more effort and time until we are there.
Leah R. Tucker: I would totally agree with that. I think the ability to create resources and manage my integration from the portal, you know, if you're telling me to create some resource before I can use a product, can you just let me do it where I am, you know, from within the portal, not direct me to some other surface. So I'd love to see a more integrated developer experience built into the portal.
Anthony Sansone: If you wanna talk about sci-fi, I would kind of say that let's talk about well... No one uses an API or a single resource in a bubble. They use it to call another API, to gather information for another endpoint, which calls information from another endpoint... I'd like to be able to see you take for lack of a better word, like a GUI and just say, patch in this resource, which then passes information to this resource, which I pass it... just literally do it like building blocks and then say, 'Here's what I wanna start with. Here's what I wanna end with. Suggest some ideas as to how I would get there.' Help me put together and then show me how they call together and then generate the code to have it call those things in sequence so that I don't have to think through, 'Oh, this one calls, then this one calls...' Example being if I wanna create 700 users at a shot under one organization that has to have these other roles and parameters, then I don't need to think about each one of those calls. I just have to go back and say, 'I have this, I want to end with this. Let's building block this out.' And then I run one generated code, I run one thing and does the whole thing all at once and I'm done. But my solution I can build, not work with the individual API endpoints.
Alex Akimov: And I think what you are saying is, yeah, sounds very effective and it's a dream for many people in industry, but is it more like no-code and low-code solution, or is it still an integration-builder? You know, like from this component, I build an application and I can download and it works for me with my problem one, with my version and my environment.
Anthony Sansone: Well, like I said, I probably threw out three different ideas there. But like one might be, for example, I want to end up with this information or this result, okay? And then say, 'Okay, what APIs do I need to call in what order to get that result?' That's one path. Another path might be, 'I know roughly what I wanna do, but I wanna have it be low-code to map out, not necessarily that it doesn't generate code or I don't need code at the end, but that it does give me the code at the end.' So rather than saying, 'I know I need to call "create organization" and then I need to call based on that. I need to call "create user" 500, 700 times, and then it generates these things and I store them in this area. Okay, fine, let me see how this one does then, oh, I need this role to create the user. So go back, here's the API piece to create that role. Done, hooked, then go back and say, oh, to create these roles, I need to have this other one here. Call this one next and then just chain them together.' So I go, okay, here's how I need to call them in order and have that little help saying, 'Oh, you wanted to do that? You need to call this one next.' Or even something like a suggestion saying, 'You did this one. What do you wanna do next? This, this, or this?' 'Oh, I wanted to do this operation next.' Click. 'Here's the code for it.' 'I'm gonna call this piece next.' 'What you wanna do next? I wanted to create user, I wanted to create email, I wanted to create user?' Click, and it generates the code for that. And then you kinda string it together. It doesn't have to be no-code, because again, integrating with your code is always gonna be part of it. You know, it's like that's the one piece you don't have. It's like I said, you have a starting point and an ending point, but you don't have that piece in the middle and you wanna fix that piece in the middle.
Alex Akimov: Yeah, I agree with that. I think in general, things like wizards they can give you a great idea how the integration can work and with like combining all the blocks together. But also when I was observing developers behavior, I realize many times that people prefer to write code themselves because they still want to be creators. They like to be guided, but they don't like this code to be generated from somewhere. So ideally, if we think about sci-fi, my scenario would be something like from the Matrix, when, you know, you can just upload information. 'Okay, now I know kung-fu, now I know how to write this .' But it's pretty far away from where we are.
Closing thoughts
Laura Vass: Okay. so ending on the sci-fi note. Thank you very much for the crystal-balling and for the very immediate suggestions also to the teams who are building developer portals. And I thank you again for the incredible amount of effort and very actual hours that went into it daytime, nighttime, weekends, and the attention that you spent on these portals. I thank you very much for that. And yeah, we're gonna hear who won?
Alex Akimov: Thank you very much for having us.
Anthony Sansone: Thank you.
Michael Meng: Thank you very much.
