| Issue 1, 2013 | Download pdf |
One of the most important concepts to grasp when developing mobile applications is that mobile user interfaces differ vastly from traditional desktop applications. We recently completed the first stage of a real-world project for expense tracking. This article illustrates some common challenges that developers might face and suggests how they should best surmount them based on this experience.
Our goal was to create a well-rounded app that featured as many of the Native UI components as possible, whilst also testing the robustness of Mobile Designer’s cross-platform capabilities.
We quickly decided that an expenses tracking application would be a great showcase for the product. We could immediately see that an application like this would feature many of the UI conventions that are common requirements of developers using Mobile Designer (list views, entry forms, options screens etc.). We could develop the basic app in a fairly simple way (using the record store for data storage) and keep the logic as concise as possible. Later we may add more complex features such as server synchronization or image capture, but for now the Expenses Tracker will exist as a self-contained app.
The Development Team
The team developing this app comprised three main roles: design, coding and art. This team spent less than one man-month developing the application. A month of development might seem reasonable for a project of this size until you factor in that this includes the earliest brainstorming stages, right through to full development (including graphical asset creation), testing, refinement and (most important) deployment to both phones and tablets across three different mobile operating systems. Without Mobile Designer this would have been impossible to achieve within this timeframe.
Design Stage
The designer started by sketching out the requirements on a white board. Once all the main parts of the app were defined, he went on to create a high level flow diagram as shown in Figure 1. With the flow diagram in place, he moved on to writing the design document. This document would be the main point of reference for everyone working on the application and as such would be kept up to date if refinements were made to the design or functionality of the app.
As with the flow diagram, the first draft of the design document uses the small screen implementation of the application as its starting point. The document details the layout and function of each of the screens within the application. Where necessary, the designer makes suggestions about how a page layout might be achieved (i.e. the potential use of a table to position the sub-navigation on the Expenses view).
There is little aesthetic guidance and certainly no description of how the app might appear differently on each platform in the design document. This is a very conscious choice. The designer is aware that the most efficient way to build a cross-platform app using mobile designer is to begin with a purely functional version. Each of the nUI components is carefully designed to look as natural as possible on the supported target platforms, so if a developer does little more than add them to the page in the correct order they should still get something that looks close to a native app.
Refining the Design
Once the application is functional, the team will return to the code to start tweaking the look and feel on a platform-by-platform basis. This will not only include adding the correct graphics (light icons for Android and Windows, as opposed to dark icons for iOS for example) but also adjusting any spacing and layout that doesn’t look quite right.
The design is also revisited to address any unforeseen pitfalls in the flow of the application that are encountered. For example, one refinement made to the Expenses Tracker was to address the flow when returning from editing an expense item. The developer spotted a situation not described in the design document. Normally, when navigating to the Expenses view the app would return to the same month that it was previously displaying. However, if the user has just edited the details of the only item in a month and changed the date of that item to a different month, the code will now need to switch to a new month on return otherwise the list would be empty. It seems like a very minor point, but nonetheless a solution must be decided upon before the code can be finalized. It is therefore important that the dialogue between the designers and coders continues beyond the hand-over of the document.
Tablet Version
The programmers realized that incorporating the tablet version of the app into the codebase should happen sooner rather than later. There would be many more flow issues as a result of the multi-pane nature of the tablet builds and the decision was made to start work on the tablet versions alongside the rest of development.
The designer returned to the document and added a ‘tablet version’ sub-section to each of the sections. The main task was to define into which of the app’s two panes each view would fall. There would also be some minor modifications needed to one or two of the views. For example, the custom control to select months is present on both the Expenses and Reports views on the phone version, whereas in the tablet version this UI component can be removed from one as both views are on display at the same time.
Mobile Designer eases the transition from single screen to multi-pane considerably, but it is still up to the developer to write any new logic needed to handle the updating of these multiple views. For example, after editing an expense item in the phone version of Expenses Tracker the user returns to the Expenses list view. In the tablet version, the same action requires the app to update two views on exit.
‘Prettifying’ the App
There were three main tasks involved with ‘prettifying’ the app. Adding relevant graphical resources (icons etc.), adjusting the layout, spacing and fonts and making any extra tweaks to the tablet version (where the extra screen real estate might allow for different screen layouts).
Icons were created in two different styles. A darker set (with a slight gradient and inner shadow) were created for the iOS builds, and the inverse, a lighter monochromatic set were needed for Android and Windows.
The first parts of the app that would need to be adjusted, in terms of layout and spacing, were the table buttons on the main list view (the Expenses screen). The innerX values for these views were zeroed, so that the buttons could extend right to the edge of the screen. Then, taking iOS as the starting platform, the text and icons were aligned properly within the cells that made up the table button, and the text was sized and colored (where necessary). The interElementSpacing was reduced to zero and the color of the separator was set to a mid grey. Also the background color of the container housing the table buttons was set to white. Once these tweaks were in place the table buttons were a great match for the type familiar to iOS users.
Surprisingly, after removing the change to the background color, they looked almost perfect on the dark themed Android and Windows RT platforms too. We did go in and tweak the blue color used for the date, along with the color of the separator. Mobile Designer handled the rest (inverting the font colors, highlighting the button when touched etc.).
On the tablet version most of the changes merely involved adding extra margins to some of the views appearing in the main pane. The Expense Item view, for example, uses a white box that is 70% as wide as the pane (as opposed to 90% on the phone version). One view that did receive special attention was the Reports screen. The extra screen space meant we were able to rearrange the charts and other information in a way that it would all be visible without any scrolling.
Finally, on Android we tinted the header and nav bar to introduce some color to the application and added small spacers as the first element on many of the views.
In Conclusion
By planning ahead and being clear about how the application would function we were able to quickly develop a cross-platform app that feels natural not only across three operating systems, but also on both phones and tablets. Designing and building mobile applications is always a tough challenge but Mobile Designer can help remove a lot of the hardest work.
Be sure to visit the Tech Community later this month for a more in-depth study of this project, including access to the design document and complete Mobile Designer codebase.