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.

• For the targeted Users discover,
  1. What are their real problems?
  2. How do they solve these problems today?
  3. What information do they need to solve these problems?
  4. What information do they already have?

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.

• Use a flow chart to present the conceptual model to Users
• Determine the minimum number of inputs required from Users
• Look for natural order and groupings within these inputs

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.

In USER INTERFACE define each TABBED PANE and each data entry box type and location, but don’t worry too much about other details like defaults, bounds checking and units.

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.

1. Use of large image files in an EASAP can make downloading the EASAP from the EASA Server to the users computer take more time. Be mindful of users connections speeds and be sure to test out accessing the EASAP using the slowest anticipated connection speed of your users.
2. The frequency of events that cause actions, such as refreshing data from databases or submitting a processes to run, can drastically affect the responsiveness of an EASAP. Care should be taken to properly select events that launch time consuming actions, so that users can anticipate and therefore control the rate at which these events occur.
3. Run times for the underlying software applications being driven by an EASAP can vary from less than a minute to many hours, and even days. A problem arises when a user of a previous EASAP that ran quickly, i.e. less than a minute, decides to run a different EASAP that takes much longer to run, say several hours. Since all EASAPs will look similar, a possible perception of users may be that all EASAPs take a similar time to run.

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,

• Will this one work?
• Does this one perform better than the current one?
• How long will it last?
• How much money will this save?

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.