Authoring of EASAPs can be broken down into six main steps.

First of all, EASAPs should be planned carefully. In creating an EASAP, you are given the opportunity to design the user interface specifically around problems users want to solve on a regular basis. This opportunity may be new for many authors, who are accustomed to conforming to the requirements of the various software applications they use. Below you will find some suggestions for planning your EASAPs:

• Get targeted users involved in an EASAP’s design early to better understand how they would like to use it and what results they would expect to get from it.

• Consider functionality first by determining the minimum number of inputs required from the user and then order them in a way that is most natural for the user.

• Determine the procedure for running software applications such that the needed results are computed.

• Plan to iterate. Try the EASAP out on users, and then expect to modify and improve it.

In general, you should use good GUI design principles as you plan your EASAP, and the GUI of EASAPs page is dedicated to providing you further guidelines and suggestions.

Since EASAPs drive software applications in batch mode, the main task here is to create all the files required to run the underlying software applications in an automated fashion in batch mode. Your knowledge of running this software in batch mode will be vitally important. This knowledge often includes being proficient with the software application’s command, scripting or macro language. However, knowing a software application’s language for running in batch mode does not mean that you will be typing this language into files manually. In most cases, the files can be generated directly from the software application’s interactive interface or they can be created by modifying existing templates.

In most cases, it will be important for you to make batch files that are parametric in nature. Basically, this means that you should define and use variables as inputs instead of constants. Making files parametric will greatly simplify the task of coupling the software application to your EASAP. The parametric concept is especially useful when dealing with geometry, whereby you set up important dimensions as variables as opposed to keying in absolute values.

Before starting to create the EASAP, you should test running your batch files manually first. This means you need to type in the necessary commands at a command prompt to run the software applications in a step-by-step manner as will be done in the EASAP. It does not make sense to start working on the EASAP until you are able to run all of the required software applications from start to finish by hand.

The generation of an EASAP and its user interface basically involves two activities:

1. Using the EASAP Builder
2. Managing files i.e. uploading and editing them

The following pages provide additional detailed information on performing these two activities:

• Using The EASAP Builder
• GUI of EASAPs
• Expressions and Units
• Event Processing
• Data Processing
• Excel Spreadsheets
• Diagramming
• Coupling to Software Applications
• Generating Reports and Output

When building an EASAP, an important decision that you will need to make is to choose the client used when a user opens the EASAP. Currently, there are the following two choices:

• Web Browser
• EASA Client

The main advantages for using the Web Browser client approach are as follows:

1. No client software needs to be installed on the user’s computer
2. Start up times for EASAPs will generally be shorter

It is therefore recommended that EASAPs are developed for the Web Browser client. However, for security reasons, web browsers do not allow manipulation of local files and execution of code on the client computer. Since the EASA Client is an installed software application, it is not subject to same restrictions. Therefore, features such as data extraction from local files and execution of custom code actions are only available in the EASA Client. To see the differences between the clients while building your EASAP, you can change a setting on the Options tab in the EASAP Builder tool.

Tip: The recommended approach to choosing the client for an EASAP is to start with Web Browser and switch to EASA Client when the EASAP requires a feature not available in the Web Browser client.

Some Suggestions When you are ready to generate your EASAP, making use of the following suggestions may improve the generation process:

• Do not start with the User Interface. First, connect the EASAP up to the underlying software applications and then test submitting and running the EASAP without modifying any input data. Effectively, this procedure is repeating the manual tests done to automate the software applications, except now the tests are not manual, the EASAP is performing the tests.

• Build the User Interface in steps. Add data entry objects to the user interface in reasonable size groups, say 5 to 10 at a time, and then run some tests of the EASAP to ensure proper data transfer to the underlying software applications. Once one group of data entry objects is working properly, add the next group and test again. Repeat this process until the User Interface is complete.

• Save the diagramming work until last. Test out your EASAP on users without diagrams, and see if they find it easy enough to use. If they do, you may be able to skip adding diagrams altogether and save yourself some work.

Before releasing an EASAP to the user community, it will be important to test it thoroughly. Testing of an EASAP will be a two step process:

1. Check proper functioning of the EASAP using reliable inputs
2. Perform robustness testing by varying input values

EASA provides an area specifically for authors to perform their testing (see the page “Testing”), to which Users do not have access. For more details on testing EASAPs, see the Testing EASAPs page.

All EASAPs support the use of a Help file, and it is the responsibility of the author to document their EASAP in this Help file. While producing well-designed and easy-to-use EASAPs may minimize the work required to properly document your EASAPs, the need to have a Help file that provides useful information to users will remain. Additional detailed information on the content and creation of EASAP Help files is provided at the Producing EASAP Documentation page.

At this point, you will have properly planned, generated, tested and documented your EASAP, and you are now ready to publish your EASAP for use by others. This final step of publishing your EASAP is actually quite trivial, as it involves just a couple of button clicks (see Publish under the Authoring menu). However, you should be aware of some important issues regarding version control and the publishing of subsequent releases of an EASAP. For more details on this topic, see the Publishing EASAPs page.