 I'm going to go ahead and get started. Welcome everyone to the first session of the tech track at the DHS2 annual conference in 2020, digital online this year, obviously. I hope you are enjoying the other sessions. I think there's been some really great ones. Maybe some of you saw the innovation session at the COVID-19 day yesterday, which featured a number of custom applications that people had built on top of DHS2. That's generally what we're going to be talking about over the next two days in the tech track. There are a few other technical sessions as well that aren't directly related to that, but that isn't specifically web applications either. We're also going to talk about Android applications as well as the feedback loop between local innovation and the global platform that is DHS2. I'm going to start off our session here today. Looks like we have a number of people coming in. First, I'm going to talk a little bit about DHS2 as a platform in general, and then I'll talk about specifically how we enable web applications in what we call the web app platform. There's a little bit of an overlap in naming there, but I'll talk a little bit about it generally, and then specifically what we're doing for the web application enablement. Then I'll turn it over to my colleague Jose, who will introduce the Android SDK, which is the equivalent of the web app platform for mobile applications specifically on Android. Then I will turn it over to another colleague, Magnus from the University of Oslo, who will talk about the design lab that he leads there, which is specifically working with implementers in the field to feedback innovation from the field to the innovation enablement that we work on here at the DHS2 core team. Finally, I'll wrap it up by talking a little bit about our work with developer advocacy and the feedback loop that Magnus will introduce, and then we'll move on to a couple other sessions. Immediately following this session will be a more in-depth dive that I will lead on the web application platform. We'll have similar one sessions, one hour each tomorrow at both one o'clock for Android SDK, and I believe, oh sorry, it's two o'clock for Android SDK and three o'clock for the design lab. I'll have the times at the end, but those will be tomorrow. If you want to learn more about those, you can follow up with Jose or Magnus tomorrow as well. If you have any questions, please go to the community of practice. There's a specific topic under the annual conference category for questions regarding this session, and we'll try to address some of those at the end if we have some time, otherwise we'll address them asynchronously. First to talk a little bit about some of the developer training and outreach that we've done this summer. I should have mentioned also that back in December there was an in-person Android SDK workshop or academy that took place in Sri Lanka, and this summer we were able to, we had to go online, unfortunately, but we were able to still host a good amount of training for developers building on top of DHIS2. We'll talk a little bit about some of the additional training and resources that we're developing, but we had a pretty successful training summer here in University of Oslo with these online trainings. We had two open webinars in June with more than 120 participants, each followed by a workshop at the end of June, and then a four-day workshop which were together made up a developer academy in August, and those had about 30 participants each, so we thought that was very successful. Look for any feedback from the participants and got some very good feedback from the people who were there, and look forward to doing more of that. We also have a central repository for resources for developers specifically building extensions to DHIS2. This is mostly focused on web application extensions, but it also links to some of the Android resources, and we're looking to expand the resources that we have about the Android SDK there as well. This is developers at djs2.org, so that should always be the place to go for any resources that you want to learn about how to build applications on top of the djs2 platform. I wanted to make a mention of that. What is the platform that we're talking about here? The platform is DHIS2. That's not always obvious, but DHIS2 is not a kind of out-of-the-box software. It's a platform that you can build on top of to customize to fit the needs of your particular use case, your particular locality, and lots of other things. It's a toolkit that lets you build what you want on top of it or what you need for your use case. This is a diagram that was developed by Scott Russ Patrick, my colleague who's the analytics product manager, and he uses this. It came from an earlier publication as well in some research by the University of Oslo, but there's a number of different layers that make up djs2. You have the djs2 core at the center, which has the API and the data model, the metadata. Around that, you have some bundle applications that we develop here at the University of Oslo. Around that, you have some additional applications that are developed by third parties. Maybe they're developed and shared through the app hub that we make available, or they are developed and just installed locally to a particular instance. And then finally, you have some interoperability with different software on the periphery. Not going to get into too much about this here today, but I wanted to start with this as kind of a framing. The piece we're going to focus on is the bundle applications and the periphery applications. This works both for web apps and for Android applications, but basically we have some applications that we develop as the djs2 core team that are built into djs2. And then there are a lot of applications that are built by other people or by djs2 or djs2 with or UIO with some collaborators that are not bundled with the war file that you install when you start to work on djs2. But this sort of concentric circles diagram doesn't fully cover what we're actually doing here. So I wanted to take a step back and sort of change that up because what we're actually doing is more like this. So we have djs2, which is the, again, the APIs, the metadata model, all of that. And then we have a layer which is the platform layer. So that actually enables web applications to run on djs2. It provides a lot of things out of the box that are just provided by that platform that make it robust and secure and performant and modern applications, enables those to run on the djs2 platform. But the important thing here is that we don't have bundled web apps on the inside and then installed external web apps on the outside. They're the same thing. So we're actually using the same tools that we're building and making available for these installed web applications for building our own core applications that are provided out of the box in djs2. And it's exactly the same for Android as well. So you just replace the web app platform with Android SDK, you have the djs2 Android application, and then you also have custom Android applications that are on the same level as the official djs2 Android app, and can use a lot of the same functionality that's built into the SDK that enables those robust, modern, and powerful features of building on top of djs2. So if we were to rethink that concentric circle diagram a little bit, we would think about it this way. We have djs2 at the center, then we have the Android SDK, the application platform, and around the outside on an equal playing field, you have the core applications and the Android application that are provided by djs2 and UIO. And then you also have custom web applications and custom Android applications that are on an equal playing field with those applications. This is where we want to go. So historically, the core applications have been kind of a privileged group, and then we have created a separate platform for applications to be installed, in addition, as kind of perforated or external type services. But we're moving towards a world where everything is the same, and everything that you can do, everything that we can do, you can do better. We'll talk about that in a minute as well. To kind of hammer this home in 235, which will be released in a couple of weeks, we have introduced a very cool new feature called continuous application integration or continuous app delivery. And what that means is that your bundled applications that come in your war file, like the app management app or the dashboards app or the maintenance app, can all be updated from the app hub. So if you go to your app management application right now in 235, and the version on that we've published as UIO to the app hub, apps.dhs2.org, is a higher version than the one that is bundled in 235, you'll see this dialogue here, which allows you to update and reload your application. So that's actually checking with apps.dhs2.org to see if there's a new version available. And then you can update just this one application in your particular dhs2 instance. So once you've done that, you'll see that it's installed, you have an app management app that looks just like an installed app that you would build and deploy yourself. But this is built by UIO, it's deployed through the app hub, and it's actually overriding the one that you have installed bundled with your war file when you install dhs2 out of the box. So this means that we can move much quicker to fix bugs and introduce new features. We can also start to produce applications that work for multiple versions of dhs2. And implementers can start to pick and choose the applications that they want to update, the pieces that they're ready to implement in their system. And they can install just those without waiting for six months for the next release or waiting two years for until they have the funds and the technical availability to upgrade their entire database and do a migration that way. So this way applications can be installed independently of the core, the dhs2 server. It's important to note this process is exactly the same as when you build and install a third-party application from the app hub. So here we have the app manager and app, which is a core app bundled app that's overridden by an app installed from the app hub. And we also have a custom application that's also installed in this instance from the app hub. So they're, again, on an equal playing field and can do a lot of the same things. This is coming out, as I mentioned, in 235. And we think it's going to enable a lot of really cool innovation on the core team as well as in the platform as a whole. So I'll talk about the platform now quickly before I turn it over to my colleague Jose. Again, there'll be a session after this that'll be one hour that we'll dive into more detail about what the web application platform does and how you can use it to build applications and how we use it at dhs2 to build applications as well. But first I'll talk about what are the goals of that web application platform. The goal is to make it cheap, easy, and fast to build custom web applications, which customize dhs2. So again, we have a number of applications like maintenance app, dashboards app, data visualizer, maps, tracker, tracker capture, capture application. All of these applications that are built into dhs2 and are very powerful but are generic. So they're not custom tailored for a specific use case. And that's by design. We're not able to customize those generic applications in a thousand different ways for all the different use cases that are out there. We try to make them as applicable to all of those applications or those use cases as possible. But it's never going to be perfect for every single use case. So in some cases, you're going to want to build custom applications to enable custom workflows or to extend the capabilities of dhs2 in some way. And the goal is to make it as cheap, easy, and fast to build those customizations as possible. That's both for us as the University of Oslo and dhs2 who also use that same platform, that same system to to make maintenance of all of the applications that we maintain much easier and much more cost effective as well. Much less, takes a lot of less effort from our developers to maintain applications on the platform than it did previously. And that's what we're enabling not only for our own applications but for third party applications as well. One way to I want to kind of say that or one way you could say that is that everything we can do as the University of Oslo, you can do better. So we want everything that a core application at some point, everything that a core application can do should be accessible by in a custom application in an easy and maintainable way. And that'll allow really allow us to build the building blocks for customization and really tailored use cases for those applications in local contexts. I'll get into more about this in the next session. So I'm not going to spend too much time on it, but there's a lot that goes on in a dhs2 application when you build one from scratch. So there's a lot of pieces that you have to kind of put together to make that possible. And it gets even more complicated when you have to maintain a lot of those applications. So for instance, the University of Oslo has 34 core applications that we maintain that are bundled into your dhs2 instance or installable from the app hub. We also have a number of libraries that are used by those different applications that make it a little easier to kind of reuse components within those applications. But we still have to build and maintain 34 different apps. And that takes a lot of time and it's a lot of code. And it gets even more crazy when you think about the number of versions of dhs2 that we support. So before we had continuous application delivery, we have three versions, supportive versions of dhs2 that are released and out and being used by people in the wild. And we also have one version that we're developing that's the next version that's coming out. So that's four versions of every single one of these code bases that we have to maintain and develop on is more than 160 or roughly 160 maintained code bases, which is pretty huge. So there's a lot, again, a lot of pieces in each one of those applications when you multiply that by 160, that's pretty huge. So what the goal of the web app platform has been, and I introduced it a year ago at the conference in Oslo, the annual conference for dhs2. But it's come a long way since then. So at that point, it had not been fully developed. The version one was released in August of 2019. And the goal has been to simplify all of our applications so that we can maintain them more easily and make it possible for external developers to maintain their applications in the same way, develop and maintain. How do we do that? We split up our application into the pieces that are common to all apps on dhs2 and the pieces that are specific to what that app does. So this section in the middle is a much smaller piece of code that is specific to this application. And all the rest is common and can come from the platform. So this is the app shell or the platform that provides all of those common things. And then you can swap out the smaller piece that is the application whenever you need to switch applications. So what does this actually look like? For our core applications, we have 30-something apps that are kind of hot swapped into this app shell. This is coming down the line in the future. Right now we have about 10 applications that are on this platform and we're hoping to make that nearly the full list by 236, which comes out in beginning of 2021. So there's all of these applications, but each one is much smaller and all of the common pieces are extracted into a common runtime or a common shell. It becomes even more convincing when you have third-party applications as well that swap into that slot in the same way as core applications. So they can take advantage of all of those services that the platform provides. Through this platform we provide a common or a standardized application life cycle, which allows you to develop and build your application in a consistent way locally on your developer machine and then publish it to the app hub very easily so that it can be consumed and installed into DHS2 instances. So we've standardized that workflow and provided tools that make it much easier to adopt that workflow for your applications. And this gets even more complicated but more interesting when we talk about testing and working with multiple versions of the DHS2 instance to do that testing as well as to deploy directly your application to instances to do manual testing before publishing to the app hub. I'll talk more about that in the next session. So with that, that was a quick introduction to the DHS2 web application platform. I'll turn it over to Jose, my colleague, from the Android team who will talk about the Android SDK and how that enables the Android team to build their Android app as well as the third-party developers to build custom Android applications. Jose, are you there? Yes. Hi, Austin. Thank you very much. Can you hear me and see me? I can, yes. Okay, so now I need to share my screen then. I think not someone needs to allow me to share my screen. How is this able to participate? Sure, I will share it. Simone, are you able to add Jose here? You should be able to share your screen, Jose, now. Okay, perfect, yes. Okay, let me see. Okay, can everyone see my screen now? I can see it, yeah. Okay, so Austin, if you please come pick me when I only have five minutes left. Sure. Okay, so, yeah, I'm going to introduce the DHS2 Android SDK and as Austin was mentioning, tomorrow there's going to be a session, a full session of one hour going to the a full description of the functionality. But today we have 15 minutes for an introduction, but I'm trying to convince you for Android developers why you should use the SDK if you plan to develop a custom Android application. And first, some basic definitions. I'm going to try to move, okay. Okay, so a definition of what the Android SDK is is a common good that allows work offline. It has an internal database where we store all the metadata and data that is needed in order for the application to function, communicate with different DHS2 instances to the API, and then facilitate the development of Android apps. Okay, this would say that these are the main thing goals of the Android SDK. As Austin was mentioning, DHS2 is a platform that contains an API which is a common good. And also, the Android application itself is not reaching directly the API, but is using our mobile platform that in this case is the DHS2 Android SDK. Okay, so all the communication between the mobile, the Android mobile, and the UIO Android mobile application and the DHS2 API is going through the DHS2 Android SDK. And of course, it's also published, so there are developers, Android developers out there, they can build their own Android applications on top of the DHS2 Android SDK as well. The same as Austin was mentioning with the app platform. So this chart represents the SDK releases that we have so far, so it is pretty new. I would say the first release was in the 1.0 in December 2019. And then since then, we have further release in at the end of April or in August. And then we are going to publish the last one in early October. Well, we have, sorry, we have in between like of course, different patch versions as well, of course. And then we are going to publish the last one in 1.3 in early October. And then also in early October, we are going to publish as well the 2.3 Android application. But this SDK makes possible to be compatible with the 2.35 DHS2 version that is also coming up in early October. So we see that the chart that the SDK and the Android application are aligned, but this doesn't mean that this to be always the case. Obviously, they're going to be aligned, but they are different products. So we may have like different releases when there is no, for example, an Android application release. But certainly, you can spend the newest Android SDK version coming up in early October. You have here the link to the code that is available in it half and as well as the Gira. And what the SDK does, well, since the very beginnings is the version 1.0, so it's the metadata thing, right? So it replicates all the necessary parts of the DHS2 model and store that in the DHS2, sorry, in the Android local database. This means like we have tables in our local database that represents the aggregated domain, represents the event domain, and represents the tracker domain. So all the domains are embedded in the Android SDK. As well, the data sync, we synchronize the data as well. So it's in charge of the data synchronization with different parameters. So we can specify the number of TI's or events to be synchronized with the DHS2 instance, but also we can play with some parameters like we can specify the number of TI's or the number of units, sorry, the number of TI's and events per unit, the number of TI's or events per program, or a combination of both. Whenever we are like doing the synchronization, we are always synchronizing the ones that are in the data captor unit tree of the user. We are prioritizing the TI's in terms of TI's, the TI's which enrollment status is open, and also those TI's that has been last updated recently. And then since what we are going to see this in one of the next slides, now we have more possibilities regarding defining more and more options here for granular data sync. But we are going to see that in five minutes. Of course, if we have a local database that I think that right now it contains like 100 or 110 tables, so it's quite a lot. We don't want for the Android SDK users to perfectly know the number of tables and also to run like a very complicated SQL sentences, right? So also since one zero, we have a date, what we call the data access layer that is kind of similar to Ivernet that basically allows you to using like a data test to naming conventions to retrieve information that is coming or from the local database or from the API. Okay, this was a huge effort from the data made by the Android SDK developers and we are going to explore more of these functionality tomorrow, okay? For example, also since the very beginning, we have what we call also an expression evaluation engine. So that is, I think, quite nice because here we can make all the calculations of inline program indicators, okay? We don't have indicators yet, we have program indicators in the context of a TI. This has been like, this is an ongoing work that is on progress, so we started in the version one zero, but then through one one and through the version one two, we have now like basically mapped into Android SDK, like I would say that the 98% of the variables of the expressions and all the formulas that are presented in the server side. So I think that if you would like to do this from the scratch, it is quite complex. So I would say like this expression engine is one of the main goals that we have in order to share what an SDK can do for the developers, okay? And it supports last data test versions, okay? At the very least, we are ensuring the compatibility with the data test to current and to previous versions. This means three data test two versions a total, but you see what is the reality? The reality is like when we published the version one zero, we were compatible from 229 to 233. This is five versions. With one one, we were compatible with six versions, and with one three, we're going to be compatible from 230 to 235. So this means that any app that is using SDK can have like, let's say like log life expectations. If you are like, you know, you have all this number of the access to version that can run on top. This is basically, I would say, two years and a half of the access to server versions, okay? And what else? So error management, this is also really important. If you are a developer, you have been like playing and using the API for many times, you see that the number of errors that the the API can can deliver is huge. So we are like simplifying a lot for the for the Android apps, the management of errors. Basically, we have like, we are having a granularity at different levels. So in mind that you have a conflict, you have an error. And in the SDK, you have, when you are syncing with the, I mean, your data, your new TI is when you're syncing with a server, you may have some conflicts or errors. And then with SDK is going to have the information about what is a TI, inside of TI, what is enrollment, what is the event, what is the attitude and the timing that is producing that conflict or that error. And also not only this, but also the errors that are like related to the bandwidth to internet or the connection with a separate timeouts, but get ways, or at least it's being managed by the SDK as well. Interity check also very important for when we have like dependencies that, you know, that sometimes there are, I mean, we have seen this many times in the past, when there are like configurations in the access to server side that are not properly done, or like, I can think, for example, on like program rules with, sorry, program rules with no program variables, program variables with no data elements or attributes, or even you are trying to synchronize and you are downloading target entity data values, but someone just removed the data element of a particular program stage. So, you know, these kind of dependencies that normally are like a headache for the developers, we have like now a defensive layer against these kind of errors in 30 years, and we are like in the local database, removing all these mis-independencies that we may find. Okay. And I think that this was a huge effort as well, and it has been reduced and another number of errors and bugs that we were having in the Android application. And online search, so it allows also easily to do online search, so now it's also possible using like a similar naming convention to search TI that has been stored in the local database, but also not all, if you have internet connection also you can interrogate, you can query the TI's that are in the server, in your search or you need three, okay, whenever there is an internet connection, again using kind of the same naming convention from the SDK. Reserved TI unique attributes also, you know, that can be auto-generated and the SDK also reserves, we have, we are storing also the unique attributes, so if you are, values for unique attributes, so if you are going to be, if the user is going to be offline for, I don't know, for one week, so it's going to just get the values that has been previously stored in the, in the, in the local database. Okay, so we also have this disfunctionality, and also I think that this one is really, really important, database migration, so in the past with experience with the previous Android applications, sometimes when there was a new Android application, sometimes you have to, the user needs to uninstall, uninstall the new Android application, and then this means that you can, maybe if you have data that hasn't been synchronized with the server yet, so you may lose your data, and here with database migration, we, it doesn't matter if you are like upgrading your app from the, the one that is used in the first SDK version, the one zero to the newest one, it doesn't matter, if you don't have to go version by version, you can go from the, from the very, very, from the very first version to the last version, and no SDK is in, in charge of doing this in a, in a transparent way, so it will create like the different, it will just change the, the, create the different tables in the database schema that's needed, transform the data in a way that then the, the version that you are upgrading to can use, okay, so it's also like a, it took us a while, but we are very proud of this feature. Two minutes, just so you know. Two minutes, only? Yep. Okay, so, sorry, then, so from, from the latest versions, what we have is SMS synchronization, we have also, now it's, it's Android, it's compatible with the Android-shaped SAP, so you may, this means that with this app you can configure your, your synchronization mechanism, like a frequency of all the apps that are like, you know, like a, getting data from the server, so like you want the apps to synchronize every 24 hours, every hour, so you can like define this through our, through Android Settings app, and, and then the SDK is consuming this, all this information. It has an encryption, this is really important for, for example, for HIV implementation, when you would like to have the database encrypted, so also from one to, we have the database, the local database can be encrypted. We have a validation rule engine at the dataset level, only for data elements, that is using the same engine, that program indicators, and it will show you like how, what are the data elements and the data values that are like, we are writing the, the validation rule and utility classes. So we are like a, some of the VHS2 logic now is embedded into the SDK, for example, for enrollments and even the status, and whenever you have read, write that data access logic to a, to an object or opening, closing date, for example, in, in those units and, and category options, so this logic is also embedded into, into the SDK. And if I have just 30 more seconds hosting, I can say like, this is just for Android developers, it's written in Java and Kotlin, this is the database that is being used, and it's a group effort between the SDK developers and the, and the people that are working in the backend in order to, to, to use the most efficient calls. So in a nutshell, if you want to build an app that works offline, that needs to be compatible with the VHS2 versions, because you don't want to build an app that then when there is a new VHS2 version, that app doesn't work anymore. If you need to operate it up, if you, the Android app, if you want to have an automatically upgrade immigration control, or if you would like to have the best performance when syncing with the VHS2 server, or if you would like to just build an app on top of a, of an SDK that simplifies error management returned by the API. If you have at least one of these topics, when you're building your, your, your app, please use SDK, okay, because it's going to a text time, maybe a little bit in order to understand what is the, the different functionality, how to use it. But at the end, you're going to gain a lot of free time and it's going to make your life much easier in the future. Okay, and sorry if I am leaving some time. No problem. Thanks, Jose. Yeah, appreciate it. So with that, I will quickly turn it over to Magnus, who will introduce the design lab. And, and again, if you have more questions or want to hear more about the Android SDK, there is a session tomorrow. And I'll, I'll put that on the screen at the end of the session as well. Magnus, are you there? Yes. Can you hear me? Yes. And see me, my man. I will try to share my screen. See, see if this is, now this is the wrong one. Let's see. Sorry for the, it's always a bit hard to find the right Chrome window. Let's see. Yeah. Got it. I think so. Let's see if now you see at least a Google presentation, I hope. Yes. And if I click like this, yes, perfect. Nice. All right. So I will talk a bit about a bit of a broader perspective maybe on design innovation and less kind of technical feature oriented and more about methods and processes and so on. So, but still it's very much related to these app development resources, both for the web and for Android. Since this provides a very nice environment and arena to address user specific needs and to design and innovate tools based on user needs. So in this very short introduction, I will just say a little bit about this design lab thing. And then, as Austin mentioned, there is a one hour session tomorrow where I will dive more into some of these issues. So the DHS2 design lab is a project or a group of students and researchers at the University of Oslo where we collaborate with DHS2 developers both in the core team and out there in the community and implementers where we specifically try to understand how we can strengthen and promote the user oriented focus in our design innovation. So meaning, how can we develop capacity and focus on catering more for the diverse end user needs that is increasing around DHS2 as it's being taken to new and different contexts. And since this, you know, what is a usable and relevant feature as Austin touched upon, typically varies a lot between different implementations. There are different requirements, different needs, different practices. We are particularly interested in the design processes that are going on on the level of implementation. So when DHS2 is taken into specific organizations, what kind of design processes and what kind of user oriented focus is going on there and what can we learn from, for example, projects that are doing this in a very good way or so on so forth to strengthen this focus. So this means that it both our work kind of both revolves around exploring and developing methods and approaches to design for example for identifying users, user needs, working with users, ideation and prototyping and evaluation of solutions and so on and so forth. And of course, apps make, as I mentioned, a very critical part of this since apps provide this flexibility that you need to when you identify needs that are beyond the generic capabilities of the DHS2. Apps provides this arena where you can develop new and custom tools catering for user needs. And then part of our work is also then all these app resources specifically for the web mainly as of now, which I think is kind of instrumental in making custom app development a viable approach to addressing needs. Prior to this app development platform, it was quite costly both to develop apps and maintain them. And I think many of these resources that Austin talked about and also for the Android are making app development a much more viable option, which I think is a very interesting development both for us as developers and implementers and also for the, it's good news for the end users because then we can really address more of these very different types of end user needs that we see out there in the community. So this design lab has been going on for about two years and until now we have been collaborating quite strongly with his India in working with them on how the implementation practices and how users are involved in design and how we address these issues through apps or customization. This has also then fed back to the development of these web app development resources like that development platform. We have worked a bit Mozambique and were supposed to work much more extensively until Corona came along on exploring design methods and approaches. And then we have also visited several other of these his groups in Tanzania and Malawi talking with Uganda and Rwanda to look at what practices currently work related to this user focus and what can be strengthened and what are the challenges. In addition we have a quite big course here at University of Oslo where we have over 100 students that actually as a part of the course develop design and develop apps for DHS2. And we also use that course as an arena to explore user oriented innovations, building apps that provides valuable features for different user groups and so on and so forth. And we also use it as an arena to test these web app development resources. And I will in my session tomorrow give some examples of these projects from that course also just as a way of looking at what do we mean by usable and relevant innovations. Yes so in the session tomorrow we will hear more about what we do in the design lab and what you have found out during our engagement with with implementers and developers around the world. And we will try to orient these experiences and kind of ideas for the future around what we mean by user oriented and what we mean by usable and relevant software. For example the difference between digitization and digital innovation so meaning the difference between just providing a kind of copy of an analog system in a digital format versus actually developing things that provide new value to users. Again app is one way of doing that and also reflecting a bit on who are we building the software for and who are the tools we're building relevant for. Is it well mainly relevant for top level managers or low level users and so on and so forth. And then we will move on to some of the prominent challenges that we have identified with catering for and designing with users during the HSS implementation. So we reflect a bit on the pros and cons of developing apps and the remaining challenges there. Issues around finding suitable methods to engage with users and kind of working in an agile manner to build the right thing for different user groups. And then another issue that we will discuss is the problem of house projects are structured and the mandates and the scopes of projects which might in some cases hinder the ability to actually innovate and in other cases it might promote innovation so we'll look a bit at that. And then finally we'll look a bit at the plans we have for the future amongst other things to develop a design and innovation toolkit around methods and approaches and capacity building in that manner. And also some kind of ideas for collaboration and kind of calls for collaboration with the community. Yes so that's it for me for today and I hope I see you tomorrow at one. Great thanks a lot Magnus. That was a great session and again yeah there will be another session tomorrow for more information about that and I'll share that in just a moment. So I'm going to share my screen now. Okay so you should be able to see my screen now as well. Thank you again Magnus for that session and I just wanted to echo what Magnus was getting at and what the design lab focuses on which is the enablement of local innovation with this global platform. I don't want to touch on one more thing before we wrap up for today which is the inverse of this actually. So not only do we enable local innovation with our global platform but we also feedback those local innovations and the learnings from those projects and applications to that global platform to make it a more robust general purpose tool as well as to more effectively serve the needs of local customization and use case customization for DHIs too. Just as an example of that I mentioned this very very briefly yesterday in the session on COVID-19 innovations but I'm going to bring it up again today because I had two minutes yesterday and now I have maybe more like five. This is a relationship mapping application that was initially developed by His Sri Lanka early on in the COVID-19 response on DHIs too and basically what this enables you to do is to visualize the relationships between cases and suspects or contacts in the outbreak of COVID-19 in this particular case and what we did with this application is we took the the initial concept and the initial hackathon developed application and we took the learnings from that in order to develop some general purpose tools that would enable not only this application to be more effective and more useful in other contexts but also for other applications to develop using those same common tools. So some of those common tools that came out of this application were the ability to save and load settings and saved objects from the data store or the user data store in an easy and accessible way from a web application. So many web applications use the data store in different ways but this library that we developed and then are using in this relationship tracing application allows us to in a standardized way save things like visualizations to the data store similar to the way that you would save and load an application or a visualization in the data visualizer app or in the maps app. This allows you to do the same thing but with something that isn't doesn't fit the model of a out-of-the-box visualization or a map. So in this case we don't have a concept of a relationship map at this point in DHS2 in the data visualizer application. So this allows you to save and load different configurations of another type of visualization for this custom application. In the near future it will also allow the sharing of those saved objects and we're now using this library that was initially developed co-developed with HIST Prulanka for I think three other applications now as well. So this is fed back into the ecosystem and really allowed us to make it possible and easier to develop these types of applications across the board. Another piece that was reused or extracted from this project was layout components, general layout components that we initially helped HIST Prulanka to develop to have a top bar and a side bar in a standard configuration and now have exposed those in the UI library and those will be coming soon to the production version of that UI library and being used in other applications as well so that it isn't necessary to reinvent the wheel and create your own top bars and side bars in your custom applications. Additionally we took some of the learnings from this relationship analytics application, not the app specifically or the development of the app specifically but the concepts of relationship analytics and how you analyze the network of relationships in the DHS2 metadata model and are applying those learnings as well as the learnings of other partners and local instances of DHS2 to enable more robust and performant relationship analytics through the API and in the analytics engine of DHS2 itself as well as to integrate some of those functionalities into the core DHS2 applications such as tracker capture application and the analytics applications like data visualizer and maps so those you'll see coming into the DHS2 core in one of the next few releases but this is kind of was inspired by the local adaptation of the DHS2 data model to analyze relationships in a way that hadn't been natively possible before. You can learn more about everything that you've heard about in this session so we talked a little bit about building custom web applications on the app platform as well as the design lab and building custom applications on the Android SDK. Each of those has its own hour-long session. The first one is starting in about 10 minutes here on this same channel so you can stay on the line if you want to learn more about the web application platform and how that's used at the University of Oslo to build the core applications as well as how third-party developers can leverage that application platform to build their own local customizations or to share their applications with other DHS2 implementers and users through the app hub. Then tomorrow at 1 o'clock Central European Time 1300 we have a session with Magnus on the DHS2 design lab, the course at the University of Oslo, and the participatory design and approach to working with local DHS2 implementers to feedback into the core development as well as at 1500 so 3pm Central European Time we have a session on the Android SDK and building custom mobile applications with Jose and some of his colleagues from the Android team as well. Again, I wanted to mention the main resource for developers and people wanting to customize DHS2 or extend it. Developers at DHS2.org is where all of that information will live. We're continually updating the resources that live on that developer-focused site so we have announcements of new libraries and new tools that we're making available as well as announcement of events like this conference or like the academy that we hosted in June and August of this past summer. We also have developer documentation and guides that we're continually improving and building out there and we very much welcome feedback and contributions to that documentation and learning material as well. You can find all of it on GitHub and you can also find the community of practice topic for development and there are two subcategories within that for application development and Android development on the community of practice where you can ask any questions that you might have and we will monitor that pretty frequently. I'm going to check for questions here now but then I'll wrap it up because we have about five minutes before the next session so people will want to go on to their other sessions here in just a couple minutes. It looks like we did have a couple quick questions. Maybe I can pass this one on to Magnus if you're available there. It says so maybe we can respond to this in on the community of practice because it looks like a little bit more involved question than we have time for today and I saw that Theo had a number of questions. I answered those on the community practice as well so go on to the community practice link that Simona had shared and you can see the questions and the answers that we will post there as well. With that I think I'll wrap it up for this session and look forward to seeing some of you in four minutes back on this same Zoom channel for the next session which will be about the DHS2 web application platform. Thank you all very much for joining us today.