This page introduces general principles and guidelines that should help you to design and develop high quality EASAPs.
The most important step in designing a good EASAP is to get input from the targeted users of that EASAP.
From the targeted users, you should attempt to find out:
With this information, you will be better equipped to design an EASAP that will meet the user’s needs.
Before deciding what an EASAP will look like, you should first determine what an EASAP will do. Developing a “Conceptual” model of the EASAP to review with the intended users may save rework time in creating the EASAP. Some items to think about in developing a Conceptual model during the planning and design of your EASAP are:
Tip: Do NOT let the order of use of inputs in the underlying software applications influence you. Remember to focus on the users and let them help determine a natural order.
Once you have a Conceptual model that appears to meet the needs of the users, a useful next step might be to quickly produce a prototype of the EASAP user interface in EASAP Builder. Focus solely on the User Interface Branch, you should do nothing in the Processes Branch and Output Branch. In the User Interface branch, get all of the Tabbed Panes and data entry boxes in place, but don’t worry too much about some details like defaults, bounds checking and units.
After completing a prototype, show it to users to get their feedback. Use this feedback to refine the design of your EASAP.
For the most part, speed or performance of your EASAPs will be out of your control. The responsiveness of the EASAP user interface is largely a function of the design of the EASA software and the speed of the user’s computer. After being submitted to run, the rate at which an EASAP responds with results is largely a function of the underlying software applications being driven. However, there are a few things under your control for making an EASAP be responsive to users.
A responsive solution to this problem is to provide estimates of run times either in messages on the user interface, or in the help files, or both. Here, the problem isn’t always that the EASAP will take too long to run. Instead, it is often that the user isn’t aware of the possible run time and can’t plan accordingly.
The Output branch of an EASAP provides you with an opportunity to present information and results generated by an EASAP in a form more in line with users’ needs.
Often software applications generate a wealth of data as results, so you should use the Extract capability to pull out the important pieces of information from a potentially huge amount of data. Although a few pretty color plots can be very informative qualitatively, you should not neglect providing useful quantitative information to users.
Where possible, you should strive to answer users’ real questions by capturing analysis of results and then providing conclusion statements based on actual results generated by the EASAP. Examples of questions that users are really trying to answer are as follows:
You should use report templates and formats in the Results pages that are commonly used in your organization. The goal would be to eliminate the need for users to reproduce or copy the results into a separate report. Hopefully, users can just print out the reports from their Results pages as stand alone reports, or at least as addenda to another report.
It may be a good idea to test your EASAP out with a couple of intended users before a complete release to all users. Even if an EASAP has been released to all users, you should still be prepared to accept user feedback and then improve the EASAP. In general, the development of an EASAP, like many products, can and should be an iterative process.