Screen-sizing strategies

If all users are using an application from the same device, the task is simple: provide an application that works great on that device. However, this is not common with web applications. Business applications might only concern themselves with desktop users, but even here it is likely that there is some range in screen resolutions and browsers being used. This is hardly new to web development, and the task is well understood. A single layout can be used without too much trouble.

Increasingly however, we need to also consider tablet and phone users. In the case of CRM Simple, we used a single page for all screens. The layout is simple and condensed enough to remain usable on a 7-inch tablet. If the screen gets much smaller than that, it becomes unusable. At the same time, while it may look overly simplistic, it's still usable on a desktop. Although phone screen sizes continue to drift upwards, they're still small enough to require significant simplification of the interface. You simply cannot present as much information at once on a phone. A well-designed mobile application does less, but does it well. This leaves us with a few options to consider when targeting multiple devices:

  • Multiple versions of the application
  • One page for all devices
  • A page per device
  • Some combination of the above

Multiple versions of an application or all in one?

Creating a new project for each device is an obvious solution, but it does incur the cost of having multiple versions to maintain. On the other hand, building a separate version for PhoneGap enables it to be optimized for mobile. For example, the installed version could be designed for offline operation, utilizing local storage, indexedDB, and so on. This can be a logical addition to a successful web application with a growing phone user base. New applications needing mobile support but with no immediate desktop support needs are also good candidates for PhoneGap-optimized application.

One screen for all devices

A single set of pages for all devices can work well as long as you do not try to support both phones and desktops from the single page. A page can be designed for the smallest target device screen size and allowed to scale up in size, but only to an extent. For example, on a phone, a task menu where the user picks from a short task list is a common model. However, as a full-screen window on a high resolution desktop, a six-button home page would be odd, impractical, and ugly. This means that we are most likely to be able to use some set of pages for both larger tablets and desktops and laptops. It is also likely that some phone pages are usable on tablets.

A screen for each screen size

As we saw earlier, by selecting the project in the Services tab, Studio allows us to specify a different page for phones, tablets, and desktops in the Projects Properties under Mobile. This feature allows us to have a single application with pages optimized for each device class.

This is a good strategy; using the same services for all client views means there is only one server to maintain. The potential trap when using this approach is the logic being repeated on each page. To minimize page code duplication, create a shared JavaScript file under Resources. These can be easily imported using the Import button in the Source tab. By putting as much logic as possible in the shared resource script file, you can reduce the amount of page code duplicated in each page. The shared JavaScript functions would be a good place to put management information of any global objects our application is using, as a simple example.

The very bottom of the main script page of WaveyWeb has an import of waveytools.js:

eval(wm.load("resources/javascript/waveytools.js"));

Waveytools.js defines a namespace called waveytools. Using namespaces is a good thing; it keeps its functions out of the global namespace and avoids potential collisions with other functions. This is why all functions in WaveMaker start with a prefix such as app, main, wm, and this.

In the waveytools namespace, we've defined a logMessage function. An example of calling this function is shown in the layer1 onShow event function:

   layer1Show: function(inSender) {
       //this is using the log function defined in waveytools.js
       waveytools.logMessage("Now showing layer 1");
   },

The hybrid approach

Often the most practical approach is a combination of these approaches. If the application is large, maybe the tasks should be divided into multiple applications. In the version for bigger screens, you can have more complete applications with one page for all screens. Meanwhile, for the smaller screens, use a smaller, task-focused, specialized application.

If a single page in the desktop version of an application performs some complex task, most probably it will be necessary to divide that task into multiple pages for the tablet version. A single page of the desktop may require multiple pages in the tablet version to accomplish the same task.

Now that we have planned our layouts, let's consider how we'll keep things moving along smoothly.