257 – Behind the Open App Builder

[00:00:00] Michele: Hello everybody. Welcome to the IDEMS podcast. I’m Michele Pancera and I’m here today with David Stern, one of the founding directors of IDEMS.

How are you, David?

[00:00:10] David: I’m doing very well and looking forward to carrying on a previous discussion about the open app builder.

[00:00:19] Michele: That’s exactly where most of my time is dedicated. That’s why I started working with IDEMS, so hopefully I have something to say.

[00:00:29] David: Well, we came to this from our work with PLH (Parenting for Lifelong Health), that is the big suite of apps that we’ve been building, which have many variants already in different contexts. And at the heart of this, we’ve been aiming to build a reusable system in ways that are unusual. And I think it’s fair to say that, when you started on this, it is an unusual system, it is not like something you had seen before. Is that a fair assessment?

[00:01:06] Michele: It is a fair assessment. At the beginning, I didn’t know if what I was looking at was code or not. Doesn’t feel like code, but it’s kind of similar to coding. It is different. 

[00:01:22] David: Yeah, it’s somewhere. We think of it as a data format, but it is on that boundary because actually in some sense, code is just data, semi-structured data anyway, so that boundary between code and data is always a bit fluid. But we’ve pushed very much on the data side and there’s good reasons behind that, but it’s not obvious and I think it’s not even been obvious for you jumping in and trying to learn how to author in these systems. At the moment, it’s hard work.

[00:01:54] Michele: Oh, it is hard work. I promise you, I’m earning my salary. It is hard work. The idea is for the interface to be readable and simple. For example, we are using spreadsheets, which is not common in coding, and every column has a meaning, every row has a meaning, and the main idea or objective is that it should become pretty clear what the meaning of each row and what the role of each row is, so that the more unreadable part is not visible to the author of the app.

But then the open app builder system translates these spreadsheets into actual code, with all of the strange words that are contained in a code that a non-technical person would not be able to read, and then becomes an app.

[00:03:01] David: Well, I would frame that slightly differently, ’cause first they’re translated into a JSON format, a semi-structured format, which isn’t yet code, it’s still data. And then that JSON format is actually used to populate, if you want, or to instantiate the actual code, which is the component it’s built up. But that intermediary layer is still not code. It’s a JSON format. Is it the JSON format that you were referring to as code?

[00:03:32] Michele: No, no, no. You’re right, there’s the intermediate step, but what I was thinking about is from an author perspective, someone who doesn’t know how to code, from their perspective, they’re interacting with a spreadsheet and somehow it becomes, it will eventually become code of an app that, to someone who doesn’t know what’s happening behind the hood, that’s the only thing they need to know.

[00:03:56] David: Exactly. And even within those spreadsheets, there’s layers to this. There’s sort of very low level spreadsheets which interact with components directly and which can have quite a lot of complexity, but give you the broad structures of the app. And then the simplest is what we call “data lists”, which is literally just text or data that is used to fill in content within templates.

And so there’s a whole templating system within the data authoring part, the spreadsheet part as you put it. This is inspired, or the fact to use spreadsheets as an authoring tool, is inspired by ODK, Open Data Kit, and the success they had at this.

And I still remember the point at which I suddenly understood why this was so valuable, because I’m somebody who’s grown up programming since I was age five. I wrote my own games at age 10. Programming isn’t something which was ever a barrier for me.

But watching people collaborate on ODK spreadsheets where even people who are definitely not coders, who aren’t comfortable programming, are able to contribute in, let’s say, do the translations, understand the nature of the survey in an ODK format – that’s what it’s doing, it’s a format to be able to author surveys – and watching people collaborate on that made me realise we don’t do this with code in the same way. People are used to collaborating on spreadsheets, or on Google Docs, or just documents if you want, in a way that they don’t tend to collaborate in the same way on code.

Code is often seen as being more rigorous. You get feedback loops, but this is a review process. Co-coding is actually, it does happen, but it’s surprisingly rare. So I find it very interesting that the data structures do enable a form of collaboration, which is difficult on code itself.

[00:06:10] Michele: And maybe to connect the dots, you mentioned the JSON format while I was talking about the spreadsheets. Maybe it’s worth mentioning that our idea is that the source of truth for our app building system should be the JSONs, and then the spreadsheets are going to become just one possible visual of the JSONs. And it doesn’t have to be the only one, it doesn’t have to be the only option.

So that if we are starting with the JSONs, we can have different ways to interact with the JSONs, which means different ways to interact with how the app is built. And this will have the potential to, as you’re saying, facilitate the collaboration between different authors in different ways.

[00:07:03] David: Absolutely. And what you are articulating there is a really good part of the vision that we have for the future, where we would certainly envisage a click and drag, you know, click and drop, that sort of interface where you can have a very visual way of building up the apps and the source of the truth would remain the JSONs.

You could still have your spreadsheet authoring, and we’ve already got a Google Docs authoring for certain parts of the content. And so actually having all of these different ways, the key is that different people can engage in the authoring and this is what’s so important. It’s not that we have one way we want people to engage in the authoring, we want people to be able to engage in the way that they are comfortable with because of the baggage that they’re bringing with them.

And I don’t mean baggage in a negative way here, I mean it in a positive way. If somebody’s coming in and they’re used to working collaboratively on documents, great, that baggage that they’re bringing with them, we can turn it around and make it positive, they can use those skills. If they’re used to working in spreadsheets, they can stay in spreadsheets, if they’re used to working on something which is just a click and drop interface, these are all possibilities. And having that suite of tools is definitely what we want to be heading towards.

[00:08:35] Michele: Yeah. This layered collaboration that you’re talking about is already similar to what we’re doing, for example, with PLH, where we do have our backend people, like Johnny, who creates the components… 

[00:08:52] David: You have four layers, don’t you? Let’s talk through the four layers. Johnny is the backend components. You would be part of the intermediaries who are building the templates themselves. Then we’d have people like Deepali in PLH who are actually managing a product almost, a particular type of app, they do a lot of the design work, they figure out what’s needed, they understand it and they would actually interact with the spreadsheets in ways which are quite detailed. And then we would have the local implementation partners who would quite often get a set of Google Docs that they would then be editing, which would then be feeding back in.

And so we’d already naturally have those four layers of people interacting. Does that resonate that almost every app you’ve worked on, you’ve probably had at least three and normally four layers, is that right?

[00:09:45] Michele: That’s exactly right. You mentioned Deepali. For sure Deepali works on the content and she may interact with a Google document, but also sometimes she interacts with the data list that you mentioned before in the spreadsheets. And depending on who you are and what your role is and what you’re competent at, you may interact with one or more of the many layers.

[00:10:11] David: Exactly. And the point is, if we think about where we’ll be eventually, this is, I think, still an underestimation of the number of layers that I think a fully mature system will have. And I think it’s important to say that this is not yet a mature system.

And we’re very grateful for PLH being on this journey with us co-developing the system. We are building the system to meet their needs. But we are building a more general system that is reusable across different contexts. And I guess we’re really interested in that deeper system. But where I’d like to stay at the moment is the level within a single context, that of PLH for example, recognising that this multi-layered approach is essential and is critical to what differentiates, I think, the approach we are taking to other approaches.

And maybe one of the things that I think is so interesting about that approach is that normally us, as the technical partners, would also hold the design work. Whereas I find it very interesting that this is something which the PLH team themselves have taken on. We do bits of design, but most of that role is owned and taken on by the PLH team because they’re the ones who are interacting on the ground. They go in and they do the workshop with the facilitators and they get those insights in a way which enables them to better take ownership of that design process.

And why do I bring that out? I bring it out because I could easily imagine another collaboration where that’s not the case, where the design process lives more with us and the development piece, and it doesn’t matter. This is what’s so powerful about the system. Okay, the system is not working anywhere near how I would like it to be working at the moment, but it is certainly getting there and it’s making progress.

[00:12:21] Michele: Yeah, the system has the capability of allowing for different contexts, which is similar to one of our principles, options by context.

[00:12:34] David: Absolutely. This is a design principle we’ve used to think about how to serve PLH with the development of these technologies.

[00:12:45] Michele: You mentioned that the system is not mature yet. I can confirm it isn’t. We are working so hard every day to develop new components, we find bugs, we have interactions with PLH telling us what new kind of features they would desire. And we are also trying to just philosophically review what the meaning of what we’re doing is, and how things should work. So it’s very much a work in progress, but in an exciting way. We do see a future where the app builder could become actually usable by non-experts.

[00:13:31] David: Yeah, and that is the exciting future that we’re really working towards. I have to confess, I underestimated it when we went down this path. It’s over five years ago now, I pushed people down this path, “push” is maybe too strong, but certainly it was a heavy nudge that gave the direction on this.

And I think, of course, we’ve been resource constrained and we’ve gone through our own challenges in different ways, and we’ve had to focus on deliverables over structure. But we have made immense progress. And looking at where we are now, it’s really exciting to think that, ooh, it might not be that long before we have a mature framework on our hands here that could really be of value across contexts.

[00:14:28] Michele: We already have someone outside of IDEMS who is using our system. 

[00:14:34] David: He has been since 2020 or 2021, so he has been for almost five years now, I think, or maybe even over five years .

[00:14:44] Michele: Chris Wright, a very courageous person.

[00:14:48] David: And very patient. You know, we have had moments at which, because this wasn’t funded, we couldn’t support him as much as he needed because it’s such a system in conscious flux. This didn’t give him a stable product. And so he did at one point investigate, well, what would it take if he were to try and just build the app himself not using our systems?

And actually, before he did that investigation, he was struggling a bit with the fact that we weren’t able to provide the stability that a mature system would provide. And after he did that investigation, and also after you intervened and started interacting with him really well, he did come to me and he said: “I looked into it and it made me appreciate just what we are doing.”

Because the cost it would’ve taken for him to get similar apps in a standard way, it would’ve been unimaginable. He could never have done it. Whereas yes, there’s been pain because he’s been on a system which hasn’t been fully mature, but it has enabled him to build these apps, which would’ve been impossible in other contexts.

I’m so grateful for him to actually have stuck through with this, and also recognise that we haven’t had funding on that. But the fact that it hasn’t needed funding, it’s just needed a very committed and very strong person in the form of Chris Wright plus a bit of our support (but that’s been minimal support to actually achieve this), this gives me so much hope for the future where I really believe that once the system is a little bit more mature, once we’ve actually got the framework so that we can provide stability, I think it’s going to be reusable in so many contexts and I’m excited to see how people just pick it up and use it for themselves. It’s all open and so it will be something which others can pick up and use.

We did have other people look at it and they said, ah, we wouldn’t know where to start. So we do have some work to do to get it so that others can pick it up and use it. And full credit to Chris Wright for what he’s been able to do.

[00:16:58] Michele: Maybe since we are talking about people external to IDEMS using the open up builder, maybe we could also mention that we have now a group in Mali using the open app builder, being trained on how to use it and they’re doing it successfully. We also have a group in Kenya, so things are happening.

[00:17:26] David: Yeah, and that’s very recent. I think we had another episode where we talked a bit more about them, but it’s only in the last few months that the Malian Group has emerged. And I think they’ve surpassed all of our expectations, and it’ll be really interesting to see how we can continue to support that group to grow and to gain the skills, and maybe to even expand out what they’re actually working on and how they’re using these technologies.

I would love, for example, for them to possibly get involved with Chris Wright on having francophone versions of EFM tailored to the West African context, the Sahelian context in particular. So that would be amazing. So yeah, watch this space, this is the first steps, baby steps, but the MSc is about to be launched in Kenya as well, and that has elements of these systems which can be provided as part of that training, so we could get a whole other set of people trained to use this for educational purposes. So yeah, it’s exciting, there’s lots, lots of movement.

[00:18:40] Michele: Yeah, I can’t wait to see what’s gonna happen with the open app builder.

David, is there something we didn’t mention that we should be mentioning?

[00:18:50] David: I know Santiago will be telling us we’re at time, he much prefers shorter episodes, so I think that if there is something which we find we really needed to mention, we should then have it as another episode. And I can think of other episodes I’d like in this direction. In particular, I’d love to actually dig into the parenting programmes themselves.

But that’s not gonna be for now. We’ll do that maybe in a few months time. So I look forward to the next sort of discussions around this, maybe in a couple of months.

[00:19:23] Michele: Thank you so much, David. See you in the next one.

[00:19:25] David: Thank you.