1 / 16

Jason A. Guild CS 470 Presentation

Jason A. Guild CS 470 Presentation. B.S. Computer Science Information Systems. 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

dgrande
Download Presentation

Jason A. Guild CS 470 Presentation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related