 All right, so here we will talk a little bit about what has happened in the last year or so, six months to a year, with the DHS2 application platform, particularly focusing on new features since we held the last workshop, academy and workshop in August of 2020. Obviously, a lot has happened in the world in the last year, but we'll talk specifically about what has happened in the world of DHS2 web application development. A little bit of a review for those of you that aren't familiar with the application platform. What it does is it takes away all of the hard stuff that you need to do to build a DHS2 application, but that isn't specific to the app that you are building, and it gives all of that to you for free. That's the idea. So it's a shared shell that includes a lot of things like the header bar and common UI components and the ability to fetch API and soon the ability to do offline capabilities for DHS2, how to do translations, how to set up alerts, things like that. And it does all of that for you, and it's the same tool that is used by the core applications and the DHS2 core team to develop those applications. So this makes it very robust and powerful for developing applications from third parties as well. There are three main components to this application platform, and again, I'm not going to go into too much detail about any of this in this webinar. This is just an overview of what's changed and what's coming soon. If you want to learn more, there's a lot of content already on developers.dhs2.org, including all of the recordings from last year's webinar or workshop as well as webinars. And then we also have the academy coming up for developers if you want to dive into how to actually use these tools to build DHS2 applications. There are three main components to the web application platform. The first is app scripts, which basically is a tool to develop, build, and publish an application. It does a lot of things like putting your application into the shell, packaging it up, writing out a manifest file, creating a zip file, publishing that application to the app hub or deploying it to a DHS2 instance, and has a lot of other features as well under the hood. The second component is what we call the app runtime. And this is basically a library that the application can use to talk to a DHS2 instance and to do some other things like interacting with the shell, to show alerts, to figure out what version of the server it's talking to, those types of things. And then the third component, major component, there are some other small ones as well, is the UI library. So we have a fairly complete React library for building applications. This involves a number of different components. And we're constantly expanding the set of components and also building more complex advanced components like organet tree, transfer component, things like that, that I will get into a little bit in a minute. But this allows you to very easily build an application that follows the DHS2 design system, which is a set of guidelines for how to build a professional and very usable application for on the DHS2 platform. So some of the new platform features in 2020, I just listed them out here. I'm not going to go into too much detail about what each of these are. There are a couple big ones that I'll get into in a minute as well. But these are some of those that have come up in the last year. One of the big ones is server version detection. So basically this means that a DHS2 app no longer needs to be tied to a specific version of the DHS2 API. It can be able to change its behavior based on which version of DHS2 it's talking to. This is a really big benefit because it means that you don't need to build one app for DHS2 230 and another app for DHS2 235. You can build one app that is able to talk to both of those servers and change its behavior based on the functionality of the server that it's talking to. This is just the first stepping stone in a feature we call feature toggling and this basically enables the on when the application starts, it figures out what version of the server it's talking to and then it tells the application code what version is was detected so that it can change its behavior accordingly. A second bigger feature that we introduced in the end of 2020 is the alert service. This basically is a standardized way for any component in an application to show an alert in the app shell. So there's no need to build your own mechanism for creating alerts, clearing them after a certain timeout for displaying them on the screen. That's all taken care of for you. All the application has to do is tell the platform what type of alert it wants to show and it will show up. The third major platform feature here that I wanted to highlight is a deploy script. So basically previously you had scripts that were built for developing your application locally for building it for production, maybe for testing and that was about it. But now we're starting to add some more scripts that help to streamline the life cycle of an application. And this script is a deploy script which basically means with one command on the command line, you can deploy your application to a particular DHS server without ever opening a browser, creating a zip file, anything like that. You run build on your command line and then you can run deploy, pass some credentials to that server and it will install the application on that server automatically. The next step of this is going to be to publish the app hub from the command line as well. We'll get into that in a minute. We also had a number of features of the UI library that came out in 2020. I talked a little bit about version five, which came out in August of last year. I believe I talked about it. Maybe it came out a little bit before August. I talked about it on the webinar in June of last year. And we also had version six, which came out towards the end of the year and that had one major feature, which was the introduction of standard DHS two icons. So now there is a whole set of DHS two icons, which are available in multiple sizes, multiple colors that are available in the UI library. That includes a standard set of interface components as well as some that are tailored specifically for use in DHS two. And we do have the ability to expand that set of icons if those are requested. But they follow the design guidelines. They're very easy to use and you can learn more about that on the documentation for the UI library, as well as the upcoming academy. We also introduced a number of features to the application runtime. These are a little bit more technical, but lazy queries is one of those. That basically means that you can define a query that will run at some time in the future rather than immediately when it's created. We also made some significant improvements to the query playground, which is a developer tool that allows a developer to test queries against any DHS two instance. We now have the ability to save or basically automatically saves those queries to your local storage in your browser. So you don't need to worry about refreshing the page and losing any work that you have there. You also have the ability to have multiple tabs with different queries and different mutations open. And those can be a very good tool for developing your queries and your DHS two web applications. And then finally, we added some support for non JSON API endpoints. From an application developer perspective, this doesn't change anything. It just adds yeah, some backwards compatibility and some support for different endpoints in the DHS to API that were not previously supported by the JSON only app runtime. A little bit technical won't get into too much of that. Some of the app hub improvements that we had in 2020 as well, we added support for first class organizations, which means that not only does an application on the app hub have a single developer user that created it and is responsible for it, but that user can now be a part of an organization that has multiple users, multiple developers and maintains multiple applications. If you're familiar with GitHub or other platforms, this is something you may be familiar with. We've added that now to the DHS two app hub so that you can have better control over who has access to particular applications that your organization might be responsible for. We also started a weekly submission review process. So every week, a group from the core team gets together to review any new app hub submissions that have come in in the past week. Previously, it was on an ad hoc basis and it was a little bit tough to guarantee that we were providing feedback to people that are submitting to the app hub in a short amount of time. We're now working on improving that process and making sure that we get back to everybody that submits an app hub application in a short amount of time. There's still some learnings and growing pains as we adopt that process, but it's starting to become much smoother. As part of that as well, we introduced a set of submission guidelines which give very clear direction as to what we expect from applications that are submitted to the app hub. You can find that on developers.djist2.org under the guides page. The link is also here. I can share it in the community of practice if people are interested, but this is not meant to dissuade anyone from submitting to the app hub. It's more to give very clear direction to developers as to what qualifies as a quality application that should be submitted to the app hub and to give some additional assurances to people that are downloading applications from the app hub as to the fact that that application should work when it is installed and that it won't be confusing for their users, things like that. The requirements are not very strict at the moment. There are a few very hard requirements and some more suggestions, but we're looking to develop this over time as well as to figure out how best to work with the community to figure out what submission guidelines requirements make the most sense and what should be more optional enhancements to those applications. We'll talk a little bit more about the app hub in a minute. Here's a few things that are coming soon in the DHS2 web application development world. We have native plugin builds which will allow applications to create in an automated way to create both an application as well as a dashboard plugin in the same build. This will have a number of advantages for application developers. You don't need to have a separate application for your dashboard widget that can be tied together and upgraded at the same time, for instance. I'll talk a little bit more in a minute about the major feature that enables this, which is called dynamic runtime modules. I mentioned also earlier server version support, which is added to the app runtime and the app platform. This is the first step in feature toggling, so we'll be adding some additional tools to support turning on and off different parts of your application depending on the server that you are talking to. The next two are somewhat related and they're coming soon. Pretty exciting. I think a number of people have been looking at this for a long time or have maybe done it themselves in certain applications, but this is support for progressive web apps which allows you to download a DHS2 application as if it were a native app on your mobile phone as well as on desktops. Then in combination with the next bullet point, which is data caching and offline data, will allow applications, if they're developed in the right way, to support going offline, continuing to work in the application, going back online, synchronizing all of that without needing to build all of that from scratch. There's a lot of very powerful use cases for offline data entry as well as offline dashboards, for instance, to coming soon. I mentioned also earlier the new deploy command which allows a developer to deploy a new application to a DHS2 instance. We're going to follow that with a publish command which allows for publishing to the app hub directly from the command line wherever the developer is working or more appropriately probably from GitHub when an application is committed. When you add a new commit to the master branch, you can automatically publish to the app hub, for instance, so that will make it much easier to release new versions of DHS2 applications. I won't get into too many of the UI updates that are coming soon, but there are quite a few of those, including introduction of a data table and an more advanced org unit tree as well as many others. I also won't get into too much of the details, but we'll be migrating from cookie authentication to token-based authentication which opens up a number of interesting use cases for DHS2 apps, including working potentially outside of DHS2 itself. So talking just quickly about, I know I'm running a little bit short on time here, but talking just quickly about a few of the platform-romad features that are a bit bigger that are coming soon. This is, I mentioned common shell and runtime dependencies. This is what enables plug-in builds to be built with an application, but this has some major ramifications for applications in general as well. Basically, this enables us to deploy the header bar and updates to DHS2 UI to a DHS2 instance and have it automatically be shared between all of the apps on that instance. This means you won't have, once this is fully rolled out, we won't have the situation where you have 10 different applications in your DHS2 with 10 different header bars and 10 different versions of the org unit tree. The idea is that all of those applications would share access to the same header bar and org unit tree, which could be updated independently. We could then publish a new version of the header bar that could be installed into the application and all of the apps that use a header bar would automatically pick that up. This is being done in a way that is safe, so it's backwards compatible. It won't break if the header bar is released with a breaking change. The application will then fall back to the header bar that it was originally built with. You'll end up with multiple versions of the header bar, but we have to be safe about whether that application can support the new version of the header bar that was released. This will also allow us, it's also being done in a way that allows us to deploy things independently, so we can deploy different components in different mechanisms, different ways. I can get into more details about this at a later time. It probably could be a webinar all to itself or at least a blog post, and I will share more about that. This is a very big benefit not only to application developers, but also to instance administrators, because it means that you don't have multiple versions of the header bar or bugs in certain header bars in certain applications until you upgrade all of them and you wait until the developers of each of those applications is able to upgrade each of them to the latest version of the header bar, for instance. I also mentioned that we are improving the app hub and the application management app. There are some pretty significant improvements coming soon. These are some of the mockups that our designer Joe has put together. They're subject to change, so this is, it's going to be even better than what you're seeing here, but you can see already how much more visual and more information you're able to detect or able to view about each of these applications in this interface. This is the app hub, so this is showing community developed applications as well as core applications will be here as well. A lot of these same interface components will end up being used by the app management app, which will allow you to also search and install applications that have been developed by the community from within your DHS2 instance. That is long overdue for an improvement there. You'll be seeing updates to both the app hub and the app management app coming out in the next weeks to months. I just wanted to share quickly. I'm not going to go into each of these points, but there's a vision for where the platform for or the development ecosystem for DHS2 is going. There's a lot of very exciting and cool functionalities and use cases that we want to enable in the longer term. This is looking at not just in the next six months, but in the next two years to be able to really be able to take advantage of, for instance, server side extensions to be able to run customs code on the server in addition to on the client when you install a DHS2 application to significantly reduce the amount of data that needs to go over a network in order to better support low latency networks like cell phones, like cell phone connections that would basically move the application platform layer onto the other side of the network so that it lives by the server as well and can streamline the amount of data or the types of data that are transmitted over that network. Some additional features that we want to enable longer term are built-in routing and configuration as well as analytics and error reporting. I have an extra and on this slide. I apologize for that. Granular permissions for applications as well. That's something that with token authentication will be able to enable, which basically allows when you install an application, you can basically specify what that application is allowed to do. Today, if you install an application, that application can do anything that the user, the logged in user can do, but in this case, even if a user has all authority, if they go to an application that is only allowed to view analytics, that application can't secretly be doing something else behind the scenes. That's a big security enhancement that will help to reduce the surface area of a lot of these applications on the app hub and community developed apps as well. The final one that I wanted to talk about here is the second bullet point and that is metadata and app packages. This is still in the very early stages, but figuring out how to make applications work together and work together with certain packages of metadata in order to deploy more of a full solution rather than a piece of the solution. Right now, you can install DHS to metadata packages that are basically imports and exports of certain sets of metadata, but it's very difficult for an application to be tied in closely with that set of metadata. Moving to deploying those together or at least being able to define the dependencies between them is something that we want to investigate.