DIRECTIVE	:	UNEMPLOYMENT INSURANCE PROGRAM LETTER NO. 02-95
TO	:	ALL STATE EMPLOYMENT SECURITY AGENCIES
FROM	:	MARY ANN WYRSCH Director Unemployment Insurance Service
SUBJECT	:	Comments on Suggestions from States on the Design of the Unemployment Insurance Required Reports (UIRR) Electronic Data Entry System Rewrite

1. Purpose. To inform States of what comments were received concerning their suggestions for the rewrite of the UIRR electronic entry system and, to the extent possible, inform them of what decisions have been made concerning these suggestions.

2. Reference. UIPL 29-94

3. Background. The UIRR electronic data entry system will be rewritten to take advantage of a windows environment which should make the operation of the system easier for users. Bearing that in mind, UIPL 29-94 requested States to submit suggestions and comments on how to improve the UIRR system. This directive reports back to States what was received and how these ideas will be handled.

4. Suggestions and Resolutions. The following summarizes the suggestions and issues raised by States as a result of UIPL 24-94 and the proposed solutions.

   1. Users should be able to move from module to module without having to back out through multiple menus and go back in through several more menus.

      The rewritten system will allow for displaying multiple windows at the same time. In most cases, users will be able to call one module directly from another module without having to navigate all the intervening menus.

   2. Forms should have a better "look and feel".

      Plans for the new system include having the input screens better resemble the hard copies. We will be able to do this in the rewrite because different, smaller fonts will be available. While not entered by the user, commas in numerical fields and dollar signs for money fields can be displayed for both inputs and outputs. However, use of smaller fonts and the inclusion of symbols will have to be balanced with readability.

      Another way the new system should improve the feel of input screens will be to use scroll bars to move within the form. The mouse may also be used to position the cursor at any field. The arrow keys, restricted in the current system to right and left, will allow for up and down movement as well.

   3. More area is needed for comments.

      More space will be provided for comments. We anticipate allowing for 1600 characters or twenty lines of 80 characters. We are investigating what editing system can be used within the comments area. We hope to support: the insertion of a line, and cut, copy, paste, word wrap, and insert/overwrite modes.

   4. Provide facility to download data to other software packages.

      As a minimum, a generic report writer would be provided to facilitate download of data to ASCII files which can be uploaded to other software packages like Excel, Lotus, etc. Users would identify the data-elements that will be included in the output and a file would be written containing those data elements for the time period requested. If appropriate "off-the-shelf" software can be located that would do much the same thing, it might be used instead.

   5. More security is needed for State systems.

      Security for all UI applications is being reviewed. The intent is to have one security system for all applications. It is too early to report on how this might function.

   6. Users should not need to enter the day number when entering the report date but only the month and year.

      We are exploring several ways to address this issue. The problem should not exist for adding new reports since the full date of the next report is defaulted. One way of handling this, for all but weekly reports, is to choose a date from a list displayed in a window. This would be available when only the last day of a period is the< appropriate entry, such as in data entry screens. For entries which allow any date, such as a range for queries, the user would still have to enter the month, day and year. Other possible options will be explored.

   7. Would like to see the date and time that the report was spooled to the National Office displayed on the report.

      This could be accomplished on the data entry screen. While this information is stored with every record, it has only been available to users by writing Standard Query Language script. We would not put it on hard copy output as many people use the output for official in-house reports and wish it to look as much like the paper form as >possible.

   8. Menu option titles are sometimes cryptic. Display what underlies an option without having to choose it.

      For most menus, current plans call for a window to be displayed with sub-menu items when the cursor is positioned at a particular menu option. This will allow the user to see what choices are available if that menu option is chosen without actually having to choose it.

   9. Date and time of output generation should be included in all outputs.

      This will be done.

   10. Would like to have access to the most current specifications fo ASCII-load available on-line.

       The ASCII-load requirement for each table will be available as a help screen which can also be printed.

   11. The warning and error messages are not clear.

       More informative and clearer error and warning messages will be provided.

   12. Would like to have pre-formatted outputs available at the State level.

       We will investigate providing some basic analysis output reports such as Desired Level of Achievement measures. However, the Standard Query Language is already provided so that States can retrieve data for >themselves.

   13. More and better documentation should be provided.

       As stated in item j, we intend to provide ASCII-load specifications on-line. We will also explore having on-line access to the list of report edits and printing out current data maps and blank forms. The newly released ET Handbook 402, UIRR User's Manual, 3rd Edition, should have improved the written documentation considerably.

   14. Do not use E-mail to confirm the National Office receipt of reports.

       It is highly desirable to have the confirmation targeted to one person. Since the user ID of the person who entered the report is a part of the stored record, this is the likely candidate. This is the person to whom we now send the message through E-mail. The other possibility would be to put a receipt confirmation code in each record BUT to do this would mean that the National Office system would be writing on the State's files all the time. This is not only complex programming but raises real security issues for the State. At this point, we plan to continue the practice of sending confirmations through E-mail to the person who entered the report.

       Design work has begun. While it would be difficult to incorporate any major changes after this point, suggestions will be accepted at any time. When the basic design has been accomplished and a prototype system developed, we will be asking some States to review the system.

5. Questions. Any question or further comments should bedirected to your Regional Office.