 Hi, I'm Keith. I work at SimLab. We're a nonprofit and we help organizations use technology to build systems and services that are more accessible responsive and resilient and today I'm going to talk about Friendly, which is a tool that came out of our project that we worked on with the DC Public Library and so Friendly is a serverless lightweight form builder rules engine and document assembly tool there are a lot of words here and we'll get to them, I promise. But first I want to talk a little bit about how this project came to be. So DC Public Library received a prototype fund grant from the Knight Foundation so about $35,000 to build something over six months and they came to us looking to build a tool about how they can help library patrons find social services. And to give you a sense, the library has about 26 branches and only one social worker. And we say a thing that I end up saying kind of a lot which is that this isn't really a technology problem and it's not a technology problem in the sense that we need something that can process questions, deliver answers and build some document based on logic. It's already really been solved. And so what this is, is it's a different problem disguised as a technology problem and our job is to find it. And so we ended up sort of refactoring the challenge into something that looks like this which is how can librarians deliver and maintain good information on social services and while we're on the subject, what is good information anyway? And so the question like this isn't a technology problem. What it really is is a human problem or an information architecture problem. So how can we take the universe of social services that are available and categorize them and parse them and filter them into questions in order to enable somebody who's just being introduced to this universe to navigate the system from a point of zero knowledge? In addition to that, it's also really a process problem. So in the physical space of the library, which looks something like this, where is somebody going to go and talk to a librarian about sensitive information about social services? Are we going to do it in a back room? Are you going to do it at the reference desk? What can and can't we ask? And so these problems again are fundamentally not technology problems and so we spent most of our time not working on technology but talking to people. So we talked to social service organizations. We talked to governments. We talked to legal aid providers. We talked to librarians trying to get a sense of what the best practices were in intake and referral where the pain points are and how the library could introduce people to this really complicated world a bit more easily. And we came over with two lessons. And the first lesson is that people often need more than one service. So if you lose your job, you probably also need help with rent and food and so on. And people don't always know that. And so good information here isn't the simple answer of the perfect referral, but good information is a complex answer. It's a menu of services that people might need. And the trouble with complex answers is that they don't really grow on decision trees. And so these sort of flow charts that we build are really rudimentary information structures and they don't really reflect how interviews work. An interview is sort of a conversation trying to add attributes to a client's story so that you can deliver structured information that can help. So the second lesson that we learned is that librarians aren't social workers and they're never going to be social workers no matter how many times I ask them. And so what that means is that we're not going to be able to talk to somebody for 30 minutes in a back room and do a full service intake. It's going to be five minutes at a reference desk. And so what that means is that we need to deliver this complex set of answers in as few questions as possible. And so that leads us to maintenance or if software is eating the world, how to avoid being lunch. And so the problem that we said if this wasn't a technology problem, then why would we be creating a reliance on technical talent that the library doesn't have in order to maintain the system? So as the logic and the rules of the system change, librarians should be able to maintain it. And so friendly itself is built mostly on off-the-shelf components. So it's an off-the-shelf rules engine, off-the-shelf document offering, off-the-shelf data binding, off-the-shelf styling. All we really did was sort of wire this together in a way that librarians could use. And so there are three parts to it that really matter. The first part is a form builder. And so it's a way for people to put questions together that can be multiple choice or free form and use complex nested rules. So any of the following, all of the following, none of the following. So that way you don't have to write a question seven times to get it into seven different interviews. You can write it once and build rules and the questions will just continue to be asked as long as the rules are satisfied. And that same logical approach, any of the following, all of the following, none of the following are true, can be used for variable assignments. So we can build complicated answers based on the variations in somebody's story. And you can do that with text or math or objects or lists or even external database calls. And then the last piece of this is a document assembly tool. In other words, trying to build this content and putting it together less awful. And so in the library's case, we're building a document that's a menu of available services along with warnings and other advisories sorted by urgency based on someone's story. And all of that kind of exports into a downloadable JavaScript file. So you take the JavaScript, put it onto any website, and then there is no step three. As soon as the web page starts, the script will take over the page and that will be your intake form. So it doesn't need the internet to run and it doesn't need a server to run and it doesn't need anybody to know how to code in order to use it and to maintain it. And so I've spent a really long time going on about this without actually talking about Legal Aid. And my point here is that these types of tools are applicable to any domain and they're not specific to libraries or social services or Legal Aid because this is just information. And the approach that we've taken is to separate the basic information transformations from the business logic, which is our expertise that defines how and when that information will change. And law really at the end of the day is a system of processing information and our job as lawyers is to take the abstract narrative that somebody has and turn it into structured information. And so if you don't need to rely on a coder in order to update your personal expertise on the law, then we don't think that you should have to rely on a coder to update the business rules of your technology. And the goal of the technology here shouldn't necessarily be to simplify the world because we're lawyers. We know that the world is a complex place. But technology can capture and express complexity in ways that make it just a little bit more navigable, understandable, and friendly. Thanks very much.