Table of contents
3 October 2011
Over the last several months we have been working on an application called Conqu, a task management tool that targets multiple platforms, screen sizes, and resolutions. This article goes over some of the things we learned while we were building the application to target multiple devices.
Our team consisted of three people: one designer and two developers (the authors of this article). We started with the tablet version, spending three full months on the design alone using Adobe Photoshop CS5.5. While we started development for the tablet in Flex, the designer continued working on the phone and desktop versions. Using this staggered design/development workflow, we could work on two or more device targets at a time. In the end, the desktop version was released second, followed by the smartphone.
It was very important for us to complete our designs before starting any development. The designer also produced all assets necessary for skinning, so that we could directly code following the detailed mockups using images already cut to the correct size and format.
Conqu targets three main form factors:
- Desktop: Assumes the user has a larger screen, a mouse and a keyboard.
- Tablets: Small or large tablets such as the Samsung Galaxy Tab, Apple iPad, or BlackBerry PlayBook. These devices have a touch-screen and the device's keyboard usually covers part of the screen when it is displayed. Their screens vary widely in physical size and resolution.
- Phones: Small devices that can usually only display one screen at a time due to the limited screen real estate. These are also touch-screen devices and the keyboard covers part of the screen, which requires the designer to really think about how and where to show text inputs and text areas. In addition, phone screens can vary greatly in resolution.
Because each of these targets has different input methods (mouse vs. finger) and different screen sizes (small vs. large), you have to design your application with all of those considerations in mind. Touch-screen interfaces, in particular, require larger button targets, and users also expect certain gestures such as swiping up and down to scroll a list. To accomplish the same goal, a given action may require just one screen on the desktop, two on a tablet, or many on a phone.
Let us show you what we mean with the Conqu application by showing it in its three versions.
This desktop screen has three columns (see Figure 1):
- The left column is the main menu
- The center contains the task detail, where the user can read all of the information related to a task
- The right column contains controls to edit any of the attributes of a task, such as project, due date, time to complete, or any other details
Figure 1. The Task View/Edit screen in the desktop version of Conqu provides all key functionality in a single view (click to enlarge).
As you can see, there is a lot of information in just one screen. This is possible not only because desktop screens are usually larger, but also because people use a mouse to navigate and edit the task; buttons and other pieces of the UI can therefore be small.
The same functionality we provide in the desktop with just one screen requires a total of five screens in the tablet version (see Figure 2): a detail view (a) and four individual editing screens displayed as tabs: Info (b), Filters (c), Tags (d) and Dates (e). It also limits the user to seeing only a couple of things at a time instead of everything at once, such as the controls to edit the Title, Notes, and Projects in one tab, Due Date and Schedule Date in another tab.
Figure 2. The tablet version of Conqu: note the five areas required to duplicate the functionality of the desktop version.
In the phone version, the user needs to drill down a lot more to access each piece of editable information (see Figure 3). We removed the "detail view" to make the drill-down process a little bit shorter. That screen was replaced by a menu that also shows the current task information (a). Instead of having just one screen with all the edit options (as in the desktop version) or a set of four tabs to edit any of the task attributes (as in the tablet version), we now have one screen per attribute: one to edit the project (b), one to edit the due date (c), one for flags (d), and so on.
Figure 3. The phone version of Conqu breaks down task details into individual screens for editing.
In addition, there is one more drill-down step if the user wants to edit a project or context name, remove projects or contexts, or make any other change in the related items such as tags or custom time (see Figure 4).
Figure 4. Some tasks such as editing or deleting a project version require additional drill-down steps in the phone version.
In the other two devices, we could accomplish that without the need for additional screens (see Figure 5).
Figure 5. Additional drill-down steps are avoided in the tablet version; also in the desktop version (not shown).
When designing for phones, you can either remove functionality or separate the content into several pieces, as demonstrated in Figure 3. You also need to account for the virtual keyboard, which could potentially cover as much as half of the screen, possibly covering the text field itself, buttons, or other important parts of the UI.
We obviously wanted to reuse as much code as possible to be able to deploy quickly to our intended platforms. However, once we started targeting multiple devices, it became obvious that we were not going to be able to reuse much of the UI code, except for some building blocks such as specific components.
Our approach was to use the Presentation Model pattern (part of MVP: Model-View-Presenter architectural design) to encapsulate the view logic in one place that is reusable and create a set of completely different MXML views for each device (see Paul Williams' article, Presentation Patterns — Presentation Model). While some of our presentation models had different functionality (such as the edit view on the desktop), we were able to reuse most of them.
To achieve reuse of view logic, we made sure that our code had no dependency on the views themselves, since the views were going to change greatly across devices. The functionality, on the other hand, did not change that much. The Presentation Model pattern is perfect for this because it doesn't manipulate view elements directly. Instead, it only exposes data for the view and public functions that the view calls. That way, any view that requires the functionality can use that presentation model. A good example of this is the main task list (see Figures 6 and 7). All three versions show the list of tasks for a given category, but the views themselves are slightly different since they use different item renderers. The presentation model exposes the task data as an array and gives the view a function to call when the user clicks a task. That functionality and data is the same, so the presentation model can be reused. The views, which use different layouts and item renderers, cannot be reused.
Figure 6. The phone version's task list takes the task array provided by the presentation model and presents just the tasks themselves to save screen space.
We are also reusing 100 percent of the business logic, which is encapsulated in "managers" that are common to all versions. The whole application is built on top of the Mate Framework. Mate has also allowed us to further reuse services, database calls, and business logic by having a set of Event maps that all the versions use. We are very happy with the architecture and the ability to have a lot of common classes across all of the different versions.
If you are thinking of deploying to various screen targets, you would be well advised to plan your software architecture ahead of time to avoid having to rewrite your app each time you want to deploy to a new platform. It is also worth it to design the UI for the different targets as much in parallel as possible so that you can see what's common among them and what is not.
Developing for different devices is a rewarding experience when you take time to design specifically for each because it makes the application feel much more intuitive and well thought out. Your users will thank you for that.
Check out the follwing resources to learn more about the topics discussed in this article: