The first step in developing any application is planning it. Without proper planning, you might dive too quickly into development, only to realize that you need more resources than you expected, or the application does not meet the requirements of your users. Planning an application begins with assessing why the application is needed. Figure out the business purpose of the application. This step sounds obvious, but it helps you focus your development efforts and define how complex or simple the application should be.
After deciding why to build the application, you need to answer the "who" question: Who are the users of this application? If the users are technically savvy, for example, you might want to include advanced functionality. If you are developing an expense report application that everyone in the organization will use, you will want to keep the design of the application simple to accommodate diverse users and technical skills.
In addition to considering the technical skills of your users, you have to think about the hardware on which the application will run. If laptop users need to use your application while traveling and will be disconnected from the network, you need to plan for offline support. If a remote user is the principal user of your application, you should make the application small and fast, since these users have low bandwidth connectivity.
To develop applications, you need software building blocks. In the same way that brick, wood, and concrete are the materials that carpenters need to build a house, software building blocks are the materials you need to build an application. Microsoft Outlook provides five key building blocks for developing collaborative applications: folders, fields, views, forms, and actions. This chapter is dedicated to showing you how to take advantage of the first three. (In the next chapter, you will learn how to use forms and actions.) Specifically, this chapter will cover how to do the following:
Outlook Development TipsHere are a few tips for developing applications with Outlook. As you read through this chapter and Chapters 5 and 6, keep these issues in mind:
- If possible, develop and test your application in a personal folder before deploying it in a public folder.
- If you have to develop your application in a public folder, restrict access. Personal folders do lack some public folder functionality such as permissions or rules, so if your application requires complex permissions or rules, you might want to build your application in a public folder. To limit access to this folder while constructing the application, set an option in the folder to restrict access to only owners of the folder. We'll talk more about this feature later in this chapter.
- Always save a backup copy of custom forms before testing them. Certain logic errors on your form can freeze Outlook and force you to kill the Outlook process. For example, a simple oversight in your VBScript code could cause an infinite loop in your application. The only way to end the loop would be to kill the Outlook process. If you did not save a backup copy of the form, you would lose all the changes since the last backup.
- As obvious as it sounds, you should test your application thoroughly before deploying it. This should involve trying all the permissions, views, rules, forms, actions, and custom code in the application. If you deploy an application and later realize you need to make changes, make a backup copy of the original application in your personal folders, modify the application backup in your personal folders, and retest and deploy the new application. This method provides the least disruption to current users of the application.