Jason A. Guild CS 470 Presentation

1. Jason A. GuildCS 470 Presentation B.S. Computer Science Information Systems

2. Background • Hired by Dept. of Natural Resources • Lead permitting agency for the State • We manage all State-owned land, water, and natural resources, except fish and game, on behalf of the people of Alaska • My position is part of a team charged with making business with DNR easier for the public • Emphasis on streamlining permit application and adjudication processes

3. DNR Permitting • Process involves many phases • Starts with customer applying with a description of what they want to do • DNR adjudicates their request based on a number of factors • Request is put out for review by other agencies as well as the public • If request is deemed to be in the best interest of the State, a permit is issued

4. Applying for a permit is complex • Customers often do not know what type of permit is required • Paper forms we use are confusing and contain unfamiliar jargon • Permit applications we receive are often incomplete or filled out incorrectly • Adjudicators spend large amounts of time interviewing the applicant over the telephone to get the necessary information • The collected data then has to be entered into LAS

5. The Goal • An assisted environment that provides a step-by-step interactive approach to applying for permits • Make use of carefully constructed lines of questioning to: • Help applicant determine required permit type • Make complicated applications manageable by eliminating parts that are not applicable to customer’s intended activities • Increase the likelihood of getting accurate information the first time • Save adjudicator time by letting applicant do the bulk of data entry

6. Online Applications • DNR would like to allow electronic permit applications • Delivered via the Web as well as via kiosks located in DNR Public Information Centers • Collects all pertinent data that describes the customer’s intended activities • Integrated with our GIS applications • Allows attachment of supporting documentation (like maps, surveys, etc.) • Accepts payment of application fees by credit card

7. Desired Format • A “wizard-like” interface that operates like those seen in popular tax filing software would seem like a good solution • Use of contextual help and informational resources to educate applicant • Ability to “pause” an application and continue it at a later time • Review history of sections completed and ability to revise earlier answers

8. The Reality • DNR has several permit types • Many share commonalities in information requirements • Building a special-purpose system for each one is cost prohibitive • Interviews have to be easy to alter and expand as needed • It would be ideal if adjudicators could maintain interviews without aid of analyst programmers • A generalized system is needed

9. Options • Off-the-shelf solutions are practically non-existent • What I found were products that were too simplistic • Focused on creation of surveys and tests • I saw this as an opportunity • Satisfy my senior project requirement • Gain experience with the problem domain and allow me to make recommendations • Without committing State resources

10. Interview Model • Interviews are composed of one or more broad activities • Each activity is then composed of one or more data collection screens • One is designated as the starting point for the activity • Screens are arranged in a directed graph that comprise the flow through the activity

11. Interview Sessions • When user begins interview a session is established that retains all important information about their interaction with the interview • Interview sessions are composed of: • Timestamps that record when interview was begun and when it ended • A schedule of activities to complete • Data collected from encountered screens • A history of the user’s path through each completed activity

12. Interview Screens • Each data collection screen is composed of the usual user interface widgets • Data is entered into the screen and validated for syntactical correctness • Validation failures cause screen to be redisplayed with error messages • All validated data then becomes input to conditional branching logic which: • Determines next screen to display • Causes scheduled activities to be skipped or additional activities to be scheduled

13. Interview Flow • When user completes an activity, they proceed to the next scheduled activity • When no activities remain, user is done with interview • Session information is saved and processed at a later time • Currently, session information is simply dumped to an XML file and written to disk.

14. Environment & Platform • Interviewing system written in Java as a J2EE web application • Deployed on Apache Tomcat • Interviews are marked up in an XML-based language • Actual displayed content is combination of the interview markup, JSP pages, and client side scripts • Server-side validation and conditional branching logic can be native Java or any scripting language supported by the integrated IBM Bean Scripting Framework

15. The Result • A reusable object model that provides an abstraction for all key elements of an interview • A flexible rendering model based on XML stylesheets that supports Web forms as well as other potential delivery mediums • A runtime that can “play” interview descriptions • Without significant programming, reducing the effort and level of expertise required to get results • Allows interview authors to focus more on structure and content rather than technical details

16. Conclusion • Producing an interactive interviewing system was an ambitious senior project • All core functionality is present • Work to date is certainly classified as a prototype, and a number of rough edges and incomplete features remain • What I’ve done can serve as a useful vehicle for experimentation and discussion that I can take back to DNR