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:

1. What are the real problems they face
2. How do they solve these problems today
3. What information do they need to solve these problems
4. What information regarding these problems do they already have

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:

• Use of a flow chart may be useful in presenting the Conceptual model to users
• Determine the minimum number of inputs required from users
• Look for natural order and groupings within these inputs

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.

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 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:

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

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.