 Hi everyone, my name is Chris Alfano from Illinois Legal Aid Online. So Miranda invited me here to talk to you briefly about A to J and hot docs, development and project management as well as the maintenance of those projects once they're complete. So I'm going to do this assuming little to no knowledge of A to J and hot docs. I know some of you are very adept and probably experts at A to J and hot docs. So some of this might be information that you already know, so bear with me during those sections, please. So a brief overview of what I'm planning to cover, I'm going to talk about choosing between A to J author and hot docs for the interview component of a project as well as some development tips including how we structure our interviews at LAO as well as our development process and some of the pros and cons of in-house development versus working with a project consultant hot docs developer as well as project maintenance and working with students, interns and volunteers. So when you start on a new automated document project, the first question that you're going to ask yourself is do I want to use A to J or do I want to use hot docs for the interview component and both have their strengths and weaknesses. Of course, you're going to be using hot docs for the document portion. I know the A to J folks are working on some basic document automation to build into the next version of A to J, but for now hot docs is the only option that we have. But for the interview, you have A to J and you've got hot docs. A to J is currently flash based. The new version that's coming out, I'm told by the end of the year, is going to what's not flash, so it'll run in anything. Some of the factors that favor using an A to J interview for us is if the interview takes less than 30 minutes to complete and that is because we want that A to J interview to be able to be completed in one session. It does have a save and exit feature. I feel that hot docs has a more robust save and exit component than A to J. So in hot docs, you can save your answers and you can jump back in. You can go to the dialogue and question that you left off on and A to J author, you're going to have to click through to get back to where you left off on unless you build something more advanced into the interview, but you do have to build that yourself. So for the longer interviews, we do prefer hot docs. If the interview is targeted at users with limited reading comprehension ability, A to J is a great tool because you have very little text on screen, but you can include more information in the Learn More boxes, in the pop-ups, and it's not overwhelming for users who are not comfortable reading a huge amount of text at once. And it's also great for explaining the legal process to a prosa user. So for example, expungement, it's extremely complicated and not everyone knows what it means. In Illinois, we have expungement which erases criminal records. We have sealing which hides the criminal records. We have all these certificates and all sorts of other relief that's available. So we can use that A to J interview to educate the user about the process as they're answering questions and filling out their form. And then some factors that would favor using hot docs instead. I already covered it. If it's going to take more than 30 minutes, then there's a good chance that users are going to want to save and come back to it later. So I do think hot docs is better in that circumstance. And if the interview is targeted at more advanced users like advocates or more adept prosa users, even hot docs allows them to get through more questions more quickly. You can have help docs. You can have the resource text. But I do feel that A to J does that better. So if you just want to have a bunch of questions that they can get through quickly, hot docs is great. And if the interview is going to collect a lot of information like financial information, stuff like that, hot docs, again, is what I prefer. So I do have a sample of a hot box interview here. You can see for those of you who have not used it before, it's got the dialogues on the left-hand side. And each dialogue contains a set of questions. So they're going through multiple questions in each dialogue. Whereas A to J author, they're seeing one question at a time. There's the learn more windows. You can have pop-ups, all sorts of help text. So it does help break things out more for the less sophisticated users. I did want to talk also about the interview structure that we used at LAO. This is something that we've sort of developed over the past few years. Before, I think a lot of the interviews were all over the place. So we do try to standardize the way that we're collecting information and interviews. And this is applicable for A to J and hot docs. It's going to be a little bit different in hot docs because these are going to be spread out not in a single step like they would be in A to J author. A step contains multiple questions in A to J, but in multiple dialogues in hot docs. So we start with the introduction. And that includes a legal advice disclaimer that the user has to agree to that says we're not providing them with legal advice. We're not forming an attorney-client relationship and all that good stuff. They have to agree to that before they can get started in the interview at all. And we can tell them what information they're going to need to complete the interview. And in A to J, we can collect the name and gender in this step as well so that we can generate that avatar. Next, we have the qualification section. And this is because we want to exclude users who are not going to qualify as early as possible. I have seen interviews where they collect all the information to fill in on the form and then it says, do you live in the jurisdiction? And if they click no, then they're out. It doesn't make any sense to me. You should be kicking out people as early as possible. It wastes their time to be entering information if they're not going to qualify and it's a frustrating experience for the user to do it that way. So collect that information early on. Next, you can get into the case information, the substantive information that's going to be filled on the form and that's fairly straightforward. Then you can do notice information. So a lot of documents will require notice be sent to the other party. So you can collect the method of service, whether the other party is represented by an attorney. You can collect their address here if you like. You can also, for documents that need to be signed and notarized in front of a notary public, you can collect witness information here. And then in the conclusion step, you just briefly tell them how to save and print, what to do next, things like that. It also is helpful to include an instruction sheet that prints with the documents that has instructions on how to file for those who are completing these forms at self-help centers, may not have access to a computer later, might not be comfortable searching on their phone for more information. Just give them a simple one-page sheet that tells them what to do next. So our development process has also become standardized over the past few years. And for us, it starts with the scope document. This is just a word file that explains the goal of the project, the scenarios covered. You can have a list of the forms that are going to be automated and the order that you want them to print. And you can include an interview outline, even specific question text if you know what you want to say in each question and want to provide that to the developer. And then step two, you are going to work with the developer. If you're doing it in-house, then that's going to be a little bit different. But if you're working with a developer, you want to be communicating with them throughout the entire process. Always make yourself available, phone email. And one tool that I feel is just great is web conferencing. I think I saw Bob Lobin on the call and we've used this pretty effectively, I think, to demo features, to walk through sections of the interview that the developer is working on. It saves us a ton of time and it's a really effective tool. We use go-to meetings, but there are tons of free versions available. You can use Skype, Google Hangouts, anything that allows you to share your screen. And then next, you are going to be testing the work of the developer or your in-house person. So you should test locally on your machine as well as on LHI. And you can get help from interns, other staff members, ideally people who do not know A to J and hot docs as well as you and maybe even people who are not lawyers who can approach it from a similar perspective as your users. And then when you're ready to publish, you should communicate with partner organizations, let them know the interview is available and it's ready for use. Of course, you're going to want to check periodically for updates to the law and you're going to be improving it continually based on user feedback. So development does not end with publishing. It's only the beginning. And also briefly, I wanted to talk about the advantages and disadvantages of doing A to J and hot docs projects in-house as opposed to working with a development consultant. So some of the advantages of doing it in-house are that you have direct control over the development of the project. And this may or may not be feasible for you depending on whether you have someone on staff with A to J and hot docs knowledge. It's not extremely difficult software to pick up, but if you were just starting out, I would say that you should stick to fairly straightforward projects. But at the same time, you can improve your A to J and hot docs skills by taking on a few projects yourself in-house. And also legal aid salaries being what they are, it is usually cheaper than working with a hot docs consultant. On the other hand, the advantages of working with the development consultant are the professional A to J and hot docs expertise that they bring to the table. And it takes a lot less of your time. You're just going to have to do the scope document and review their work later on, all the development work they're doing, and it's going to save you a lot of time. And you could be working on other things. And also the consultant brings an outside point of view. You've got your organizational way of doing things. The consultant may be able to offer advice based on work that they've done in the past, based on their general knowledge of A to J and hot docs, and you might find that they come up with a better way of doing certain things than you had maybe originally thought of. And of course, once the project is complete, you are going to have to constantly be thinking about maintenance. So for us, we have about 75 A to J and hot docs interviews, and it has been a bit of a struggle to keep them all up to date. So on that hand, I think you want to make sure that you're not doing too many interviews and you have an amount that you can manage and keep maintained throughout the years. So what I try to do is at least every few years go through those older interviews, even if it's just once or twice, just to make sure that everything still looks good, that it's up to your organizational standards, that it's still compliant with the law. And to help with that, you can subscribe to Bar Association emails in relevant practice areas, and that can keep you up to date on changes in the law. And we do try at LAO to update the interviews ahead of the law change, and then when that law change goes into effect, we can update the interview on LHI. And so it's seamless for the user, ideally. And in addition to updating the project per changes in the law, you also want to think about user experience. You and your hot docs developer might approach it differently than some of your end users, so you do want to be testing the new interviews with users, if possible. If not possible, at least find some non-lawyers to run through them and give you their feedback. You can also do more formal testing where you ask the testers to fill out a short survey with ideas for improvement, almost do a focus group on your automated document. And so I think a natural transition is to working with students and volunteers. There are several A to J and hot docs courses throughout the country. The most prominent one is probably Professor Stout's A to J and hot docs practicum at Chicago Count. And we have worked with those students many times in the past. And I think there are a few pointers I can give you to get effective projects out of those students. It's great for organizations that are just starting out using A to J and hot docs because you can get a little bit of a taste in A to J and hot docs without spending a bunch of money because, of course, the student is going to work for you. But at the same time, they're learning the software while they're taking this course, so it helps to provide them with as much help as possible. So I like to choose forms that the student can easily complete in one semester, and that's usually a one or two page form. That is just about the most that I expect. It can be a longer form if you get a few of them to double up, but don't want to give them. It's better to err on the side of them having something they can complete than giving them something too long and you get an incomplete project at the end of the semester. And I find that it helps to provide that student with sample interviews. So if you do have them, if you have interviews at your organization, you can give them a few samples and show them how you do your interview structure, how you do plain language, all that sort of stuff. And if you have one, you can give them a standard variable set. So one thing that I have is just a hot docs component file that has a lot of the common variables that we use at Aleo. So like defendant and plaintiff names, landlord tenant and stuff like that and maybe a few computations that put them together. And that's extremely helpful for the students and it also keeps things consistent with the way that the rest of your organization's interviews are. And of course you need to be prepared to spend a pretty significant amount of time testing and reviewing that project. It's not going to be the same quality of work that you get from a professional developer. Of course, I mean, you know that going into it. So you're going to need to spend time testing, making sure everything works the way you want, reviewing the language. You might need to make your own revisions to that at the end of the semester. But it does save you some time and you're helping a student to learn this software. So I do think they're advantage to doing it. In addition to law students, you can leverage volunteer resources by asking interns if you have them to help with testing and research. They have, the law school interns will have access to Westlaw and Lexis and they probably have better research tools than you do in legal aid. So it's great to take advantage of that. Non-law school interns are great to get to help with testing because they are not coming from a legal perspective. And you can ask for feedback from members of the public. You can include a survey on your website. You can do focus groups, anything to get feedback because that is extremely valuable to know how people are actually using these programs. And we do like to take advantage of undergraduate volunteer programs. We've done testing of our interviews with them in the past and I do find that they are better for testing our Prose interviews than law students because they don't have any legal knowledge at all. They are obviously more educated and more sophisticated than a lot of our Prose users but still much more of a similar perspective than law students would have. So that's all I have for you. If you have any questions, please contact me at the email address or phone number below. I would be happy to provide any sort of sample documents if you'd like to see any of those.