Begin with the end in mind

Planning the application begins with determining what the application will and will not be when it is done. What must the application be able to do to be successful, and how does that definition of success compare to average requirements? Questions to consider while answering this include the following:

Answers to these types of questions quickly start to drive some design considerations.

Let's consider a few examples. If the application needs to be used by modern devices with slow network connections, but possessing plenty of local resources, minimizing network usage is going to be critical to a good user experience. This is common with field service workers. We can equip the field staff with good devices, but we are likely to be dependent upon a cellular provider for connectivity that could be limited to 3G service in a service area. Here, we can look to cache as many of our resources as possible to minimize network utilization. We may have some larger sets of data that are beneficial to keep around in the client-side and we may use client-side querying to create local views on that dataset.

If, however, the application is to be used continuously on older desktops with adequate network connectivity but with little memory to spare, our focus changes. This was the situation for a mid-sized electronics retailer's return merchandise authorization (RMA) system. They needed to modernize their RMA application, but they were constrained in their ability to upgrade the hardware installed at each location. In this case, we need to keep the memory footprint consistently small. We are likely to favor fetching data in small distinct chunks instead of filtering views on locally cached datasets. As we have a strong network, we can afford to make more service calls that return smaller datasets in order to avoid overrunning available system memory.

Finally, if the application is to be used by a variety of devices with a variety of browsers and screen sizes, suitability to all these devices becomes a driving factor. Do we develop several versions of the application, one for each target device class, or do we have a single set of pages that provide a lowest common denominator approach?

These examples only scratch the surface of the considerations that may drive other considerations. WaveMaker applications have been deployed in an amazing range of configurations. Sometimes, a single requirement can dictate many aspects of the project. It is also important that the application performs well; users hate to wait.

With the application's driving design considerations determined, we can begin to design our application. Combined with some understanding of performance factors, we can be confident of successful results.