Elana Levin Schtulberg, Datawrapper, on how we decide what features to add

Introduction

[00:00:04] Elana Levin Schtulberg: Hello. Oh, thank you for my slides. All right. Yeah, thank you, thank you very much for the introduction, very excited, a little nervous I will admit to speak to all of you, but it is 100 percent worth it to have this chance to have everyone brought together and to all get to learn from each other how we're using Datawrapper, and I feel like it's only fair to give you a little bit of insight into what's also going on behind the scenes at Datawrapper.

And data visualization development. So yeah, you got the intro, an extended intro, a bit more than I've written on this page. But yeah, I'm co CEO and leading the visualizations team, uh, development team at Datawrapper, which is one of the two development teams that we have. And it is specifically the development team that Um, focuses on the design and development of the visualizations and all the associated features.

Any long-time Datawrapper users will probably remember me from the support inbox. Um, so yeah, I have spent the majority of my time in Datawrapper, um, leading our support efforts. Um, which I think gives you like quite a particular perspective when it comes to thinking about the product and, you know, all of your needs.

So, the idea today is to give you a little bit of an insight into how visualization development goes down at Datawrapper and I wanted to look at it kind of from two angles. So on the one hand, looking at a bit more sort of from the theoretical or like conceptual side, like what actually goes into the decisions that we're making, and then taking a more practical look at how that kind of plays out in practice, using our recent multiple lines project as a bit of a case study there.

And then I'm very excited that I will at the end be joined by the rest of the viz team so that you can grill them with any questions if you want to know more. Anything more about any of the things that I mentioned or have any other burning questions? So yeah, let's let's get started. What lies behind our feature decisions?

You know, we have this product and it's always like the first step you got to decide what you want to build Um, well, actually I wouldn't say it's really the first step because to make a decision on or between something, you know First you need to have ideas. Uh, so I would like to just first take a bit of a step back and check, you know, where, where are the ideas actually coming from at Datawrapper?

Um, so yeah, for one, they come, they come from inside. Um, one thing that's quite particular and special about Datawrapper is that it really is built on top of this sort of industry experience and expertise. The founding story is very much rooted in data journalism and the understanding of sort of the needs there, the problems to solve.

Um, for example, Gregor, one of the co founders, previous Visualization team lead, and person who sort of almost single handedly built most of the initial Datawrapper offering. He also spent a long time working at the New York Times, um, in the graphics team there, and obviously brought that, that understanding of the needs into, into the product development at Datawrapper.

And that's been something that's been true throughout the years. Like, we've always had a good amount of representation of people on the team. Who do have that background as, as a practitioner and it can bring that sort of very hands on insight into, into the team and, and to the product decisions. Um, but of course, you know, the longer that you're a data wrapper, the less in touch you are with the kind of day to day of a practitioner, which is why we all actively seek to like cultivate this, this knowledge within the team and, you know, stay on top of the discourse, you know, attending conferences, watching talks, reading, you know, keeping on top of what people, what people are saying online.

Um, but we're also very, very grateful for many of the initiatives of the communications team, which really are like fostering a lot of knowledge and education within, within the whole team. Um, so for example, there's a database dispatch, which if anyone doesn't know, it's like a curated weekly digest of the week's best database, specifically construct storytelling, and this is just a fantastic resource for, for getting inspiration, for sort of staying in touch with what's being produced.

Um, and yeah, it's, it's really like, a really good idea generator. And there are many other things that the communications team are doing to kind of help foster this knowledge in the team. So the, the educational pieces by Lisa, which are always written off the back of loads of research that also sort of goes into the knowledge we have in the team, the book club, where we read a book, a database book and discuss it together with the community, together with, with the author, all of this kind of Helps grow all this knowledge within the team and generate ideas and inspiration.

And there's one more initiative of the comms team that also helps us with sort of ideas and inspiration on the product, but less sort of from like pulling it from outside and more like taking a very hard look at our own product, uh, which is weekly charts, which is, um, yeah, a blog post that goes out every week that will be written by somebody from the team, anybody from the Datawrapper team.

And it will always include. A chart created with Datawrapper. Um, and it doesn't matter, you know, what your job is at Datawrapper. If you're a systems administrator or office manager or database developer, everybody writes weekly charts, creates a weekly chart, and that, you know, really turns things on its head because you suddenly use your product like as our users are using it, and then suddenly you really get much more in touch.

Um, with the pain points there and, um, I will admit there have been a few features that were sort of long, long wished for that suddenly got extradited because somebody needed it for their weekly chart. Anyway, generally we just sort of, yeah, try to feed all that knowledge back in, share, share ideas and sources of inspiration with each other, um, online on Slack.

Uh, document it and just, yeah, keep the conversation always going. But yeah, the ideas definitely don't only come from inside from us. We also get so much really valuable, really interesting feedback and insight from all of you and from all of our users. So yeah, one of the main channels for that, which I'm very well acquainted with, is support where, you know, we have people asking, can you build this or is this and this possible?

Or we just kind of notice pain points and then recognize, okay, There's clearly a feature gap here, um, and that's something that we always keep our eye out and always document and keep track, you know. What are people asking for? What's missing? We also did a survey a while back of our users. Probably some of you took part in that where we asked you all which visualization types you'd like to see in Datawrapper and also asked for just sort of general open call to feedback.

Um, and that is also like a real treasure trove of like input inspiration and, and really, really useful feedback in there. So basically we're getting these ideas, sort of our own ideas, ideas from outside and we're sort of keeping cataloging them all, keeping track of them all. And yeah, at this point. Well, it's a very specific number, but I don't know if it's actually exact, but we have around like 812 individual unique feature ideas right now documented and also keep track of how many times each one has been requested for ones that are requested more than once, which is, of course, a lot, which brings you to the problem of, uh, Um, of, of how, how do you even make, make decisions there?

How do you prioritize even once you've decided, how do you then decide, like how it's going to be, be implemented specifically. And for that, we always orient ourselves on our North star. Which is Datawrapper's mission of helping the world create better charts and improving the world's data visualization.

So, yeah, we want to help the world create, help everyone create better charts, maps, and tables to tell their stories. Um, and we do that by offering a charting tool and what we kind of set as our internal, uh, Aim there is that we want to make basically the bottom 80 to 90 percent of data visualization possible for everybody with our tool.

Um, what I mean by that is basically we feel like the things that are simple, like are simple, look simple, simple line charts, bar charts, we want these to be possible with Datawrapper. We want sort of the bulk of your day to day database work to be possible with Datawrapper, and that will serve kind of two goals.

Like on the one hand, um, It will kind of, yeah, it opens up a world of opportunities for people who are kind of new to the field of database or for people who that isn't sort of their main focus, but it can compliment their work. And on the other hand, it also frees up a lot of time for database professionals to be able to focus on like more fancy custom projects.

So yeah, when we think about features, we're always thinking like, is it helping us on our goal to meet this 80 to 90%. Um, but of course it's not just about creating, you know, any old, any old visualizations. We really want these to be better, better than the visualizations that came before them. And that leads us to sort of another really, yeah, core tenet of our product philosophy, which is that the tool is supposed to support good database and good database design and best practices out of the box.

And I'm sure you, you probably, many of you probably know this, but it still helps to mention it. You know, we really don't want, or it's really important for us to the charts we've created with Datawrapper are good, or that it's as easy as possible to create good charts and hard to mess up. So we want the charts, you know, to be not misleading, to be truthful.

Uh, to be beautiful, to be easy to read and understand, and yeah, that is also something very, very core whenever we think about features that we're adding or how we're adding them. There's also this, the storytelling aspect, you know, you can use Dataviz, um, for many different purposes. Um, for example, you can also use it, you know, to sort of provide an explorable dashboard where readers can, you know, click around, figure out what they want to look at.

That's not our goal. Um, so we're really focusing on this explanatory side, which means, you know, we want to offer a tool that is a tool for communication. And so we will always think about that when we think about our features. Like, is it helping people with communication? So we will always prioritize, for example, an annotation feature over something that will hide, hide parts of the data behind, behind clicks.

And finally, there's this aspect of everyone. You know, we're not going to improve the world's database just by, you know, building a tool for a small subset of people. We really want this to be a tool that is useful and helpful for anyone who needs to create visualizations. Um, and that leads to, I guess, a pretty obvious, um, yeah, product philosophy point, which is we really want it to be easy to use, you know.

You should go in there and be able to make a nice chart easily. It should be friendly for, beginner friendly, uh, so that it can be maximally useful for as many people as possible. But yeah, I guess probably not nothing too new there and also sounds, you know, so far so good We've got our rule book that we want to follow Yes, but there is a little bit of a tricky thing that emerges out of here a little bit of a saboteur lurking in the shadows Which I will call the complexity creep Which is basically something that emerges from a bit of a core tension that we have between some of our goals So like on the one hand as I shared Uh, we really want this tool to be, you know, good for beginners, really beginner friendly, um, usable by a lot of people, at the same time we do want to be a tool for professionals and we do want to meet that 80 to 90 percent and allow you to really get like the finesse and the detail right where you need to.

And yeah, these things definitely stand in tension to each other and this is definitely, um, a challenge. You know, if you're, if you're a professional or you know the tool well, and then there's some sort of certain option that would just be the exact thing you need in some particular situation. And we agree, you know, we think it's a, it's a perfect use case.

It makes total sense. Regardless, we still have to think carefully about that decision, uh, because it does also come at a cost and that cost is all bared by, by the beginners. So yeah, this, this, this toggle that you add, like maybe it's exactly what you need in 1 percent of the situations, uh, but in the other 99%, it's just sort of an extra thing that is confusing in the UI that makes it harder to understand.

And in the worst case, even maybe sort of opens up a possibility for creating worse charts. This is a, yeah, Lisa spoke about this in a talk that is amazing with amazing illustrations. Um, and I think demonstrates it very well. Like the more powerful your tool is, The more flexibility you have to make exactly what you need, but of course the harder it becomes to do that and the easier it becomes to just mess up.

Um, and that's, that's not where we want to be. So what can we do about this? I, we definitely don't have, you know, all the answers. It's, it's a very, it's a tricky problem, but we do have some, um, tricks up our sleeve, tools in our tool belt, uh, to, to combat this. One of them is a very strong focus on defaults.

So, you know, even if there is some complexity, um, it's like the thing that is created when you don't do anything is already pretty good. And we just like, maybe, yeah, strongly encourage changing sort of the most important things, like the colors, where the default colors will likely never be perfect, but as long as we encourage those to be changed, and otherwise the defaults are generally following best practices, then we've already, Gone a long way, like even with Excel, you can create amazing charts, but you know, it takes a lot of work and we don't, we want to take away all that work and thereby take away that complexity of creating good charts.

Um, another thing is that I like to call magic, which is, Like when you think about what features you might want to offer, sometimes if you think about it again you realize actually this would just be offloading sort of complexity on the user, sort of decisions on the user, that would be better if we just handle it automatically.

So things like, I don't know, what might the format of the labels be, or how much space should there be, or Which ones can we show depending on the available space? These could theoretically all be options and we could sort of offload all of that onto you. Like, okay, you figure it out, make it work. Um, but yeah, another option is to really work on it and think like, how can we solve this automatically algorithmically?

Um, and yeah, it's definitely not something we've employed everywhere, but it's definitely a goal that we always have and something that we also turn to where we're possible and we'd love to do even more of. Another thing that we do is we try to, yeah, we have followed this sort of paradigm of the tool as a teacher.

You know, it's not just about. The tool that just gets you from A to B. It's also, we want to explain why you're going from A to B and, you know, help, help our users not navigate this sort of inherent complexity that, that might be there, um, help them make informed decisions, explain why things are the way they are and sort of, yeah, gently ease them in, um, to help combat that complexity.

And finally, a big part of it is also the design of the interface. You know, if, uh, if we find a way to make sort of the most important things very visible and then keep the, the sort of more pro features a little bit Uh, in the background, then it is possible to kind of, or we try to strike that balance that makes the tool still then approachable for beginners while, while offering the flexibility that you need in special cases.

Yeah, so as a bit of a recap, we get ideas from all over, from you, from us. Um, it's a lot to decide between. We always, you know, turn to our, our guiding principles and trying to avoid that complexity. And yeah, our decisions are always made. Revolving around all of this and there is one more boring thing that does factor into our decisions Which is very very boring, but resources, you know, we'd love to build everything but we we only have so many people so many people that we can Uh, yeah so much that we can do in a certain amount of time So that is also something that we always have to consider and yeah on on that very Pragmatic note.

I will take now a look with you at how this plays out in practice in particular for one project that we recently did You So yeah, rewinding, uh, step one was deciding what we want to build. In this case, the decision that was, was that we want to build multiple lines, which was a bit of a no-brainer decision.

It had been quite a while since we'd added a new chart type. Um, it was number one, like by all ways of cutting the data, um, in the Viz survey that we did, and it's definitely, we're not hitting that 80 to 90 percent of database, um, if we, if we don't have this chart type in our selection. Uh, for anyone who's not familiar, what a multiple-line chart is, it's similar to a line chart.

So a line chart, you've got all your lines stacked up, like on top of, on one grid. And with a multiple-line chart, um, yeah, you, you split them out so that each line has its own panel. And, uh, this helps make it much easier to sort of compare the individual lines and especially to compare the trends.

So that was it. We figured out what we want to build, check. Well, not, not quite, you know, we decided on the chart type, but there was obviously Many, many, many open questions after that. You know, what form is this going to take? What options are there going to be, et cetera. So that's always the first part of any project.

Also, it doesn't, I mean, even very small projects, the first part is always going to be, uh, to sort of start researching, brainstorming, collecting ideas. And, yeah, that we draw on the internal expertise that we have, but also take a lot of inspiration from outside. The dispatch that I mentioned earlier, it's very, very important.

Yeah, very helpful resource for this because you believe like reminds you of like options that are maybe this is something that we could offer as an option. And, um, yeah, that's been incredibly valuable. And then of course, all of this has to be considered within the Datawrapper context, you know, we are not building in a vacuum, there is sort of a certain way that things are, we have to fit into that.

And so we normally do this type of research, like, asynchronously on a, on a usually using Notion. Um, and the goal of the research is to kind of formulate some questions, the answers to which will then determine what we want to build. So in this case, we, um, for each question that we had, we've created an issue in our project management tool, and then all got together and discussed, um, in person, partly online, uh, these different questions that we had.

And then once we had an answer to all of those questions, like each question, we would mark that as completed. And I would just take a little moment to look at one of the, one of the things that we discussed there to give you a bit of feeling of how that goes and also relates to the things I shared earlier.

Um, so that was this question of if the vertical axis of the panel should all have the same range, which is basically, you know, if you have a line chart, they're all stacked on one grid, they obviously all share the same like grid space. Uh, if you pull them out into their individual panels. And then you'll have something that looks a bit like this and you can see that in some cases Maybe the line is not taking up all that much space, but the good thing is you're comparing very accurately between the panels However, another possibility that you have there is to like let each line take the full available space And then you have grids with like a different range in each case, and you can much more easily compare the trends.

Um, but the comparison between the individual lines is much harder, or not as meaningful. And if you look up the definition of a small multiple chart, it will generally say that, uh, they use the same scale and axis. Well, this is, this is Wikipedia, but also if you read, uh, general literature on the topic, you will find there is a general tendency, like it is important that For properly, to probably be able to make comparisons, it is generally important that, that the lines in the panel share the same scale.

So yeah, we could keep it so that the panels all share the same scale. And that would be good from sort of database design perspective in that it would, you know, mean that you can more easily and accurately compare between the panels. Um, it would be really great in terms of like ease of use, because you've just got one sort of way, you know, you only need to configure one scale, basically one grid.

Um, But of course there is a downside that then you're, you're limited, you know, in cases where you do have data with very different ranges, you can't show it as clearly. So yeah, another option would be to allow people to customize the ranges of every single panel independently. And that would be useful for cases where especially you want to compare trends at different magnitudes.

Um, But it could, on the other hand, lead to, you know, more misleading comparisons or at least comparisons that are, you know, require more cognitive load to meaningfully make them. Um, you know, suddenly you had something that was just like one nice global option. Suddenly you've got it multiplied for every single panel.

And like, what if you want them all synced? Then it's so easy to get out of that state, even though that's like the ideal state. Um, and so we made things a lot harder to support. Support just this one particular use case. Um, and once you can configure different ranges for different panels, that does also then, yeah, encourage you to start comparing like completely different things in different panels, which there's nothing inherently wrong with that.

Uh, but it kind of diverges away from the original purpose of the multiple line chart and also like, as soon as you want to do that, then there's so many more things that you want to be able to customize per panel. You know, you're not going to be happy just to customize the range. You want to also customize the.

The formats and all sorts of other things and then you just kind of Yeah, it becomes difficult to discern what is a line setting What is a panel setting and you just have this explosion of complexity Um all because you wanted to sort of support one use case And again, none of this is to say that there aren't valid use cases for it.

Um, but you know, we had to consider That it would be very difficult to come up with a, with an easy to use solution that sort of supports these different cases in a, in a logical way. So we decided in the end was we will have the ranges synced. So there's just one configuration for the ranges. Uh, we would still allow the independent ranges, but in a sort of automatic way where you can't like configure the individual ranges just automatically applies.

based on the data. So yeah, we would support it, but not sort of specifically build for it. And that helps us reduce the complexity in the tool while still supporting a lot of the use cases that there are. So yeah, that's one, uh, example of, of, of one of the things that we discussed and how those kinds of conversations can go down.

Um, and yeah, the goal of answering those questions that we define based on the research is to then determine what is the initial thing that we want to build the MVP, the minimum viable product. Like, what is good enough to deliver to you guys and not be embarrassed. Um, and yeah there we also have to factor in the resources stuff and how long it's going to take and we do have to make some compromises.

Um, and in this case actually we did decide, uh, actually annotations did not make it into our original plan for what we wanted to offer as well as some other options that we believe are good options. It was just a matter of resources that we made that decision,

but that was, yeah, that's how we determined what we wanted to build at least initially. And so then we got to building and to just take a brief segue to share for anyone who's interested a little bit about the tools and the processes that we use there, so in terms of for any developers listening, we have built them and built multiple lines and look to build future visualizations using Svelte for the markup and also with TypeScript, which helps us make less bugs, basically.

For collaborating on code, we use GitHub, and we also do use, we do do pull requests, so every code change done by a developer will always be reviewed by another developer. And for the project management, we use Linear. And the way that we set up projects is that each project will have a project lead, and that can be anybody from the visualizations team.

Um, and so that the project lead will also be an active developer on the team. And that is the project leads responsibility to basically break the project down also into, into milestones and then tasks, subtasks sort of more manageable bite sized pieces of work and to keep things moving along.

And yeah, for the multiple lines project, the team lead was Ivan who did an amazing, amazing job. So big shout-out to Ivan. Um, while building, it's also not as straightforward as just kind of. Yeah, make the chart. There's a lot, a lot of things that we have to juggle and keep in mind. So, for example, um, you know, we want, uh, the charts to look good in the branding, the custom designs that we apply for our customers of the custom plan.

Um, so that means it needs to look good out of the box, A. And B, we also need to include sort of customization options that we expect would be needed. Um, the charts, we want them to be accessible, so we do these automatically generated alt texts. Um, And, sorry, and, uh, for example, we also support, uh, different language outputs of charts.

So we also want, we also support right to left languages, and that also requires inverting aspects of the chart. So there's really, uh, a lot of stuff that needs to be considered when we're building the visualizations. And all of that has to be, uh, While we don't break something. So, you know, we've got a lot of things in the air, even a lot of parts of our, um, software are interconnected.

I didn't mention it before, but we also sort of build components. So shared components, like if we build the grid, we want to be able to use it in many different chart types or the legend, which means that if we change it in one place, maybe it will accidentally break in another place. So there's a lot in the air.

And we really don't want you to have bugs. So we have to do something to make sure that you hopefully don't have bugs. And what we do there is, is, is a thing from software development that is, yeah, we call tests, basically software testing. And, uh, for visualization code, um, we do two different types of testing.

So one is called, we call snapshot tests. Um, which is basically, we have like a repository of charts where we have a bunch of screenshots basically of them. And then every time that we make a change and every night we automatically create new screenshots and then compare them to the ones that we have, like.

on file as I like the one that is on record as the correct way. And if there's a change, like in this example here, where you can see on the right that things are highlighted in red, um, then we're like, oops, something changed and we didn't expect it. And, uh, that indicates that that was probably a bug.

This was a case of trying to unify interpolation logic across line charts and multiple lines. And accidentally we, we changed the, we broke the interpolation. But thankfully, because of this test, that was, Something that we caught before that ever saw the light of day. Uh, there's also another type of test that we do, which are, um, we call render tests, which is basically when you write code that checks that the code that you wrote does the thing that you told it to do.

So you basically check like based on this input, like say the input is five annotations in these positions. Are there five annotations in these positions when it's done processing that? And we have like a whole suite of these to check, like, is the legend there with the items that we expect in it and all of these, um, which is very useful because it means that whenever we make changes, we can feel relatively secure that we're not accidentally breaking something somewhere else.

So that's how it goes. We're building and then we, as sooner rather than later, also want to get into a review process and make sure that, you know, someone else takes a look and we figure out, are we, are we even going in the right direction here? So what we did relatively early on with this project was that we actually, in the team, wrote a draft announcement blog post just to kind of get like this.

This different outside perspective, um, on what we've been building and then shared that with the communications team to test and, and let us know what they think. And there was a whole bunch of feedback that we got from them. Um, and then we basically got back together and talked it all through. Like there was a lot of positive feedback, but then there were also a whole bunch of questions that were thrown up and things that they found hard to understand.

And we just had to sort of talk it through and figure out how we want to proceed. So I just want to share a few short case studies from that round of feedback. One relating to this independent range feature that I spoke about before. So we had this problem, it was noticed, um, that when you have the independent ranges option enabled, um, sometimes some panels would not have a second grid line, so you'd have zero context on like the actual magnitude of that.

And that's obviously a big problem. And another problem is that we didn't offer, and we didn't want to offer customization for this panel. So, this was the output, like the automatic output, and it was suboptimal. Uh, so we kind of had to, yeah, revisit this question, like how, how do we want to fix this? Um, and always when we encounter something that we're not really sure what the solution is or how we want to solve it, we kind of go back to this, this brainstorm phase and this research phase.

And we don't know even if we're going to be able to solve it always, but, or how long it would take, but we always just do it. Start with that research. Um, yeah. So in this particular case, uh, Elliot from the Viz team sat down and took a look and just tried to analyze what is the situation here, um, and identified that, you know, it's not only an issue that sometimes there's not a top tick that you can't tell what the data is, but also a number of other issues in this independent range scenario that just like, aren't really ideal, like in the second example, that the ranges are quite similar, but there's just slightly different, which means that everything's just like a little bit offset, which makes it hard to compare with no real meaningful, like, advantage.

Um, he also felt that it's quite sort of chaotic when you have different numbers of grid lines, um, at completely different positions. It doesn't feel very tidy and it also does not really facilitate comparisons in cases where it would be better to just sort of align them potentially. But yeah, we had already decided, you know, we don't want to add grid options and people, if we added options, then people could individually like choose good ticks and fix the ranges, but we didn't want to do that.

Um, so that's where we solved that problem with a little bit of magic. Uh, Elliot again, sat down and thought through, like, how would this ID behave? What are the rules? What do we, what do we want to see happening? And yeah, came up with the rules for an algorithm and then wrote that algorithm. And now we have this really awesome range rounding feature, which, yeah, basically aligns the number of, uh, ticks and, um, and yeah, gets them all in the same position, but it's an optional feature because it can maybe be a bit misleading and give you the sense that you're sort of comparing the same thing.

So it's a choice that you have, but it was a very cool thing and very cool use of magic to get around not having UI options. Another little case study is annotations. I mentioned that, uh, we decided against them for the original, like MVP, the original thing that we wanted to go live with that was tentatively re raised in that round of feedback.

Um, rightfully so, as I mentioned, you know, the storytelling aspect, uh, is so important in Datawrapper. Um, but we had been a bit, yeah, careful to include it in the main, in the original project because we felt it would take quite a while and we wanted to deliver something kind of sooner rather than later.

Um, so in the, in the sort of timeline of the project, this was the, the first review and then that was, which were, which we did actually at a point where we were like, oh, we have most of the functionality there. Um, turned out to be like one third of the way through and definitely not insignificant part of that can be attributed to the time spent on the annotation feature, but I think that was so absolutely very, very much worth it and very cool to have it in.

Um, yeah, there were some challenges to solve there that were tackled by Ivan, which is really cool. Um, so for example, you know, dragging annotations between panels, the situation of having panels with different ranges, the situation of, of Yeah, potentially needing to repeat an annotation. Um, also not being able, not allowing an annotation to be positioned somewhere outside, yeah, somewhere that's not in a panel.

All of these were sort of extra complexity that our annotation component basically didn't support already and it had to be

And yeah, but in the end, it meant that people could create charts like these and really use the tool for storytelling. So absolutely essential, I would say. And that's kind of how it goes. We sort of also then go a bit through the cycle. You know, we build, we get feedback, we build, we get feedback. Um, at the very end, we open the project up for wider team testing.

And even at the very, very end, that was actually quite, we made, we decided to make a reasonably significant change. Um, uh, the feedback was basically that we did not offer an outside labels option. So in Datawrapper, usually you have the option, um, to put your labels sort of outside of the chart or inside of the chart, these are inside labels and they are also inside labels where there's no padding.

So you can see it sort of overlaps with the chart elements. Um, yeah, by comparison with line charts, you have this outside label option. The good thing about the inside label options, the way that we'd implemented them, was we completely didn't make space for them, which means we didn't need to worry about how they would interfere with the available space, with the size of the panels, with the scales.

Um, so it was pretty convenient, but yeah, not too bad. Probably not quite up to scratch. So, but we weren't sure if it might be quite complicated to solve it, especially with the feature to only show them in the first panel. Um, but yeah, we set out to do it anyway. Uh, in the initial iteration, there was still like the amount of space between each panel that would be there if the labels were there, which we also felt was not quite good enough, and then with a bit more work, uh, we eventually got that done and got the inside labels as well with padding.

So with the exact amount of padding based on the label width. And I think that looks really nice. And even though this was a bit of a stressful last-minute addition, based on the feedback, um, it, yeah, it was a really, really nice outcome and worth it. I think. So yeah, that was a few cycles of build and review.

And then, and then we launched the feature and got a lot of really amazing feedback and also feature requests. Um, and then the question is, you know, where, where do we go from there? Well, yeah, these ideas all have to go now into our big, big box of ideas between which we are prioritizing based on, you know, the things that I shared before.

Of course, I would say that the multiple lines ideas that we left out of the initial project have a higher priority, but in general, back in the box and we're back to step one, figuring out what the next project is.

To conclude, I would just like to give a few shout outs, firstly, to Gregor for, um, yes, Everything that has been done until now and for getting to continue from from where you left off is a really amazing honor So thank you to the visualization team for being awesome Um, Ivan and Elliot for the multiple lines project and Luke who did not get a mention so far But thank you so much for all the less less glamorous more behind the scenes, but absolutely necessary work that you did Uh, in the meantime, since you, since you joined while that project was sort of in the middle and also to Lisa for all her amazing talks and presentations that, um, distill some of the, the concepts that I talked about in the beginning really nicely and helped make these things clear for me.

And of course, to all of you, to all of our users, uh, for being here at this, at this conference, for sharing your ideas and yes, please keep them coming. I know there's a lot of them, but we care about them and we would like to do something with them. So

Yeah, don't stop. And finally, if any of this sounds interesting for you, I will just mention that we are, uh, currently looking for somebody to join the Visualization team and also for someone to join the support team who has a bit of a bit of tech know-how as well. So, in case that sounds interesting for anyone, those, uh, those positions are open.

Yeah, and that wraps it up from my side. Um, I think we will now be joined by the rest of this team to answer questions.

[00:56:06] Elliot: Hi there,

[00:56:08] Luc: Hello,

[00:56:09] Elana Levin Schtulberg: Hello. Is someone going to host our questions? Oh, who wants to answer that?

[00:56:28] Ivan: I could give a quick go, uh, yeah, uh, so probably the feature that I'm most proud of, uh, implementing was when we did a big, uh, update to our annotations. Uh, I think this was in two thousand, uh, twenty. Also, so we previously had annotations in, uh, line charts, uh, I believe that were quite basic and then we decided to do like a big, uh, update to them and to make it possible to drag them around in the, in the preview and to basically expand a lot on what kinds of options that we offer.

And, uh, yeah, so I worked on that project and I think it was a pretty good result. Big, uh, success. And we also expanded it to other chart types, for example, also added it to the maps, which was not possible previously. Uh, yeah, it was a really, really cool project to work on and to, um, yeah, it was very nice to kind of add this interactivity as well in the chart preview.

So I'd say I'm quite proud of that. And yeah, so now we're also using it in new chart types that we're also adding, like the small multiple lines, for example.

[00:57:36] Elana Levin Schtulberg: So, uh,

[00:57:39] Luc: that I worked on recently. It's a very small feature, a small addition to the line charts, but I think makes it cool that previously in the line chart, you could add a label next to the line and it was a category label and you could show either like this category label or the final value.

And it was like in the controls, you could only choose either or, and we made a small change that then we can show both, which is a very small thing, but I think it's like the kind of small improvement that we make all the time to the product that makes, I don't know, chat a bit better every time.

[00:58:17] Elana Levin Schtulberg: Um, Um, Um, I don't know if we actually have a moderator choosing our questions.

[00:58:30] Luc: We have a lot of questions.

[00:58:34] Elana Levin Schtulberg: I guess I can pick one. Does anyone want to? Oh, that's a bit technical. Oh, hello gave me that. So we just answered this one. Sorry. Who wants to take…

[00:59:10] Elliot: I mean it seems like, uh, like I don't, I can't claim I fully understand all of the benefits of the new rune syntax, uh, but I trust Rich. Um, and, uh, the team behind Svelte, I, perhaps I should give a bit more context to those, uh, non-Svelte developers watching actually. Uh, so we write, uh, a lot of our code, uh, particularly the app, uh, front end, um, you know, where you log in.

Um, the dashboard and sort of things in a language called Svelte, uh, which is developed by a guy called Rich Harris, um, I believe while he was working at the New York Times, although he's no longer there, uh, and we're starting to write some of our visualization code in Svelte as well, uh, including the multiple line charts, uh, we wrote in Svelte, um, and the team behind Svelte, uh, recently announced that they are making some big changes to the language, uh, introducing something called Runes, uh, that changes the way, uh, you write Svelte.

[01:00:09] Elana Levin Schtulberg: very

[01:00:12] Elliot: I said, I think I sort of understand the reasons why they're doing it. I think it's, I'm sure there are benefits. I will miss some of the magic of the existing Svelte syntax, but it does seem more compatible potentially with TypeScript, which we're adopting more and more.

[01:00:38] Elana Levin Schtulberg: Yeah, I think also, so I would just add one small thing, I think, or two small things. I think one thing that's good about it. I mean, again, I have not looked super deeply into it yet. But the fact that you can kind of implement it incrementally, so it doesn't have to be like this binary switch. So we can sort of slowly work our way into that.

And I do think that, as fun as the self magic is, like, it's better in sort of a very small, constrained context. Like if you're, this magic, yeah, it makes things very hard to follow when you're dealing with very complicated stuff. And when, in the Datawrapper codebase, because we are considering so many different things, um, it might be helpful to have a bit more of a structure there.

[01:01:42] Ivan: Maybe I can, I can try to answer that. I don't think we have any public, uh, write ups on how we deal with that, but we have, like our internal documentation on how we deal with it. Maybe I can very quickly, uh, talk about it. So, uh, when we, uh, write unit tests for visualization components, I think we, uh, we have roughly two separate types.

So one, uh, it's kind of like the smaller type is just, uh, essentially including small unit tests for very particular functions, like the JavaScript functions, for example. That's probably like the minority of the tests that we write for our visualizations. But the most tests that we write are based on essentially rendering, um, the visualization in, um, basically using the, uh, uh, like a Chromium, uh, setup.

So we basically, for each functionality, several functionalities, of the visualization that we want to test, we, uh, we run the test and it actually renders, um, in a, like a fake browser environment essentially. And then we measure things like, for example, if elements are in the right place, or if the correct colors are rendered, um, and compare it to the expected, uh, outcomes, basically.

And those we have like for each visualization type, we have many, many tests that kind of run through all the different functionality that we want to test, and yeah, compare it to the expected, uh, outcome. Yeah, but we, we have not, uh, publicly, I think written up anything, anything about it. It's just for our internal use.

[01:03:48] Elana Levin Schtulberg: Yep, sorry. Our support address, support@datawrapper.de is definitely the best way, and in terms of sort of, it also comes down in part to how you explain it. So our support team will generally ask for a follow-up to really understand the use case and the context, but like, without the use case and the context, it can be hard to really reason, how important is this or what problem is this, is this really solving.

So I would say if you ever are missing a feature, it's really helpful if you're able to also share the situation in which that would be useful and explain sort of, yeah, how it would help there. But yeah, at the end of the day, as you saw, we do have a lot of, you know, competing priorities and um, there's no way to sort of magically fast-track one, one option, but we try to make as good decisions as we can there based on, based on the product priorities and the resources

[01:04:35] Luc: add to that that also there is very good communication I find between the support team that receives the feature requests and the dev team. For instance, we have a channel on Slack where every time there is a feature request incoming, we get a notification and the number of times this feature has been requested.

So we have a constant stream of what our users are looking for, which is pretty cool.

[01:05:20] Elana Levin Schtulberg: Um, I mean, there are a number of things that we could measure there. I would say we don't currently have a very, I have to admit, we don't have a currently a very systematic approach. We definitely like performance is very important to us. It's also why we built the web component feature, which is like a massive, like huge percentage improvement in performance that we also did.

We set up like a test page where you can compare iframe loading with web component loading. When it comes to rendering, um, we are keeping an eye, for example, on the bundle size and always like we actually get, whenever we make changes, um, we get alerted if like there's a bunch of extra bundle, but if the file got way bigger, um, that is like bringing alarm bells for us.

This is an unexpected change and we should address that. Um, but we don't have like, the file can only be this big, or the load time has to be this amount of time. Um, and we are generally only monitoring that sort of internally. Um, and yeah, that is probably something that we could double down on more so, but I would also say if there is a case where you feel like the performance is just really not what you would want, where you'd want to see it, then it would be good if you share this example with us, because there might be something very particular about that case, and it would be really helpful then to have that example to be able to like look into it and narrow that down. Yeah, I mean, it's definitely sort of an idea that has vaguely floated around a lot of times, but also opens up a whole lot of questions like if you're kind of maintaining two parallel systems that are linked at the core, it will get very complicated. So for now, I think we're trying to find a way to sort of keep both modes in one.

Um, but I wouldn't rule out that we wouldn't explore something like that at some point in future. Um, cause yeah, it is, it is difficult to strike that balance for sure. Um, but I wouldn't say we have any super concrete ideas there at this point. Um, not specifically new. I mean, we are just sort of trying to maintain, so far, a specific level with every edition. You know, we make sure that there are automatic alt text, and you also have this option to choose your own alt text, which will generally be sort of the best thing. Like, a chart, you're using it to tell a story visually.

If you want to tell that story to somebody who's not able to see it in the same way, you should probably write it. Um, one thing that would be interesting to explore, but we haven't fully reached that is sort of more keyboard operability of the chart elements themselves. So if any interactive elements, which there are some like search and tables, you can, or the buttons, pagination tables, like for the zoom and maps, you can get to those with the keyboard, but you can't really sort of navigate the individual items in, in the visualizations themselves, which probably in a, in a chart with like loads and loads of data points, that doesn't necessarily make sense.

But maybe in smaller ones it could, um, and that could be something to explore. Although we do also offer the CSV download function, which does enable somebody who's using assistive technology to navigate that data and sort of the software of their own choosing. Um, so, you know, it's always, it's a tricky balance to strike about, you know, what's going to bring a meaningful improvement, um, but yeah, definitely something that we, we would like to look more into. Am I on? But where did the question go? I need to reread it. I would say we are, because we are, uh, yeah, quite, quite focused on getting details right, I would say we are on the side of caution. Uh, we release a little bit rather, like, at least when it comes specifically to visual, especially to visualization functionality, we release maybe a little bit more on the later side and want to be sure that we got it right.

Also, because It can be tricky to like, go back on yourself then when something's out there. Um, so yeah, I would, I would say we're, we're a little bit on the cautious side there. Um, and yeah, maybe we will explore like releasing more rough MVPs or, or maybe like beta releases to sort of select user groups or option opt in.

Um, but that hasn't been something that we've done so far, but could definitely be a way to sort of explore releasing earlier stage stuff and getting feedback earlier. You have to choose who answers first, not me.

[01:11:45] Elliot: Sure, I mean, I've got to say there's nothing, uh, for me nothing compares to when you, when you've locked down the spec and you know what you're building and, uh, you start with a blank slate and just start creating something from nothing. Um, I always find that incredibly exciting and rewarding. It's always the best part of the project for me.

[01:12:07] Ivan: I think for me, it's different from project to project, but, uh, for example, when working on the small multiple lines, I feel like I particularly enjoyed. Sitting down and thinking through the annotations feature and kind of thinking how exactly it could work in the context of multiple lines. So sort of really brainstorming and coming up with ideas of how it could be implemented and fit into that new, uh, chart type, and then also kind of look at the technically how it could be possible.

So kind of this. exploratory work before the sort of coding begins. I found that very exciting in this project, but I think it will be different depending on the project, I would say.

[01:13:03] Elana Levin Schtulberg: It's a difficult question. I feel like they're all good. I like launching. It's very nice. Uh, no, I, I do. I think, I think the exploration phase, especially from a technical perspective, where you're like, I have this idea, but I don't know if or how it could work. And yeah, as Ivan said, sort of exploring how it could fit.

Also, maybe even prototyping a bit. Um, it delivers rewards very quickly, and it's like exploratory. It's creative. So that's nice. And I would also agree with Elliot that like once you kind of know mostly what you want to do and you can just like go and do it and see quick results and are not yet busy caught up in the details that always come at the end and make things a bit more of a slog.

Um, that part is also definitely very satisfying as well.

[01:13:44] Luc: I think I also really enjoy the prototyping phase, and I especially like the problems that are properly related to visualization. Like, for instance, we always make sure that labels don't overlap in our visualizations. I'm prototyping the kind of algorithm that create this, um, that prevent labels from overlapping.

This is the kind of thing that I like and that are really specific to visualizations. So this is cool. Bye bye.

[01:14:51] Elana Levin Schtulberg: Thank you. See you tomorrow. Looking forward.