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.
With this information, we are better equipped to design an EASAP that will meet a User’s exact needs.
Before we decide what an EASAP will look like, we need to determine what the EASAP will do. Develop a conceptual model of the EASAP to review with Users before any Authoring work begins.
Do not let the order of use of inputs in the underlying software applications influence the design, focus on the User's and let them help determine a natural order.
Once we have a conceptual model, we quickly produce a prototype of the EASAP user interface with the EASAP Builder. We focus solely on the USER INTERFACE branch, leave the PROCESSES branch and OUTPUT branch for later.
After completing a prototype, go back to the group of Users to get their feedback. Incorporate the feedback to refine the design of the EASAP.
For the most part, speed or performance of an EASAPs will be out of an Author's direct 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 captures and formats the results generated by an EASAP, again the User defines this deliverable data.
Often software applications generate a wealth of data as results, use an EXTRACT to pull out the important metrics. Attractive color plots are informative way to present data, raw data should also be preserved for future analysis.
A User's real questions should be completely answered. Some example questions,
Use report templates in the Results pages which adhere to an organization's existing practices. Eliminate the need for a User to reproduce or copy the results into a separate report. Hopefully, users can just print out the reports from the Results pages.
Test the EASAP out with a group of Users before a complete release. 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.