Laserfiche WebLink
development of screens will be coordinated by the appropriate task leader for the <br />development effort. <br />Consult appropriate State personnel, in conjunction with RTi's oversight, to verify that the <br />? <br />displays are adequate. Efforts must be made to limit the amount of discussion that centers <br />on proposed GUI screens. Spending too much time on such tasks will take money away <br />from development and will result in too many fine details being added to GUI screens. The <br />consultant is using the Briefing Room machine as an evaluation tool for GUIs and this <br />evaluation mechanism should be fully used to provided feedback on GUIs. The <br />prototyping cycle proposed by the consultant will allow for changes in the GUIs throughout <br />the project. It is better to add enhancements later when budget is available than to add <br />unneeded features now. <br />Depending on the application (see below), develop the GUI using appropriate tools (as <br />? <br />discussed in Task Memoranda 1.05-16 to 1.05-18). The System Integration Team will <br />provide experience with developing GUIs. The team will communicate extensively using <br />E-mail, and the weekly System Integration Team meeting will serve as a forum for <br />discussing common development concerns. Development tools (e.g., libraries and public <br />domain software) will be archived at RTi and will be available for the developers. <br />GUIs will be evaluated by RTi, both by looking at screens and by looking at the source <br />? <br />code. RTi personnel will be able to easily do this because the system will be archived at <br />RTi. Preliminary changes will be made because of coding errors, duplicate efforts, and <br />noncompliance with standards. RTi will evaluate GUIs before allowing State personnel to <br />access the GUI software. <br />Initial GUIs will be evaluated by State and Technical Subcommittee members using the <br />? <br />Briefing Room prototype. Introductions to the software may be carried out at the prototype <br />machine at RTi (which is a copy of the Briefing Room machine). Feedback will be brought <br />to the attention of the consultant at which time an evaluation of the proposed GUI changes <br />will be made. The consultant again warns against putting too much effort GUI <br />development and enhancement during Year 1. Although the GUI is what the user sees, it is <br />very important that the proof of concept system for Year 1 consist of working parts, not a <br />completely full-featured GUI. The consultant will provide the State with software for <br />capturing screens so that they can be marked up for review. <br />The procedure outlined above will be applied to the applications listed below. <br />AOP Model <br />Develop the displays for the AOP model interface to mimic the functionality of the existing model <br />interface. The existing interface has components that do not work and has other features that are <br />infrequently used. Task Memorandum 1.13-1 describes the existing model interface. Some of the <br />existing displays are not functional, either because they were never completely implemented or <br />because the software has bugs. However, the appearance of the new AOP interface will mimic the <br />existing interface so that correspondence between the State and the USBR can discuss the interface <br />in the same light. Areas where the existing model does not function will be noted in the new <br />interface with shaded menu items and/or instructional dialog boxes. <br />3 <br />A275 07.28.94 1.05-31 Malers <br />