Loclville Case Study

By John Tyrrell

Download Article

Introduction

Loclville is a free Windows* 8 app that provides an easy-to-use virtual community notice board. Developed by amateur app developer Zubair Lawrence, a Sr. Production Services Technician at Sony Pictures Imageworks, the app began life as a web site and was subsequently redesigned for the Intel-sponsored App Innovation Contest hosted by CodeProject in fall 2012.

Visually inspired by classic cork pin boards, Loclville lets anyone post notices without the need to register, with users moderating the posts through a voting system. Central to the app’s functionality is the ability to set the geographical size of the community users want to interact with. The accessible design lets even the most reticent computer users easily engage with their local community online.

Loclville running on Microsoft Surface*.

The Loclville app is now available on the Intel AppUp® center and the Windows* Store, optimized for Ultrabook™ devices running Windows 8, and is also available for the Google Android* and BlackBerry* mobile devices.

During development of Loclville, Lawrence collaborated with the originator of the idea for the concept and execution of the app, and with a graphic designer for the visual assets. Lawrence experienced numerous development challenges, many of which he encountered for the first time, from how to accurately manage the geo-localization inherent to the app’s core functionality, to programming for a touch UI on Ultrabook and handheld devices.

Approach

Lawrence approached the development of the app in two separate parts: the app side, which is the program that users download and interact with, and the server side. Each part had its own distinct development process.

JavaScript* and HTML5

Lawrence initially decided to use JavaScript as the main programming language for the app as one of the core technologies (the other being CSS3) for interactivity and animation in the HTML5 development environment. Based on this decision, he was ultimately able to reuse significantly more of the code and functionality from the web site than he originally thought possible, in addition to being able to keep the server-side calls.

Though Lawrence had reservations about using JavaScript and HTML5 after hearing other developers’ concerns about speed, he found that JavaScript was able to deliver fast performance depending on how the code was written. Lawrence’s early decision to use JavaScript as the main language for the app was ultimately justified, and he described it as one of the best choices he made.

AJAX

During the coding of the original web site, Lawrence relied heavily on AJAX, the collection of client-side web technologies—including JavaScript and XML—that facilitates asynchronous web applications. For app creation, AJAX delivered a number of efficiencies, including the ability to reuse the web site code, particularly on the server side.

The app was designed with API calls for the different features; for example, receiving posts or retrieving them from the drag-and-drop pocket feature. With one call, the app serves up all the posts for the area specified. The AJAX JavaScript-coded procedures from the site were reused for the app, which meant the app could more easily be completed within the project deadline.

Server

Lawrence first considered building the app using PHP on a Linux* server. However, concerns about scalability led him to experiment with, and eventually choose, the Azure* platform from Microsoft. Azure provides a virtual machine for each server, hence delivering a much more scalable server configuration with as many virtual servers as needed spread out globally through the platform’s distributed cloud solution. Windows Azure Mobile Services was employed for the push notifications, with all the images stored on the Windows Azure Content Delivery Network (CDN).

HTML5 Encapsulator

To create the desktop app, Lawrence Initially experimented with AppJS, the Intel AppUp encapsulator, and TideSDK, finding the latter a bit too complex and offering features he didn’t need. After these initial road tests, Lawrence decided to use the Intel AppUp encapsulator to build the HTML5 app, finding it to be an invaluable tool to quickly bring the app to the desktop.

Once the basic app was up and running, Lawrence discovered that he required greater location support. To achieve this, Lawrence switched to the AppJS solution, which offered the HTML5 geo-location features and the Mac* and Linux support he needed.

Store and Desktop

Lawrence also made an early decision to develop simultaneously for the Windows Store and for the desktop in order to maximize the audience potential. Because of its association with Intel, Lawrence thinks the Intel AppUp center gives consumers a higher degree of confidence in the apps, with the extra testing helping to ensure the safety and security of content. In addition, the fact that the Intel AppUp center is not restricted to only the Windows 8 platform helped the app reach a much larger audience than it would otherwise.

Development Challenges

Location

One of the most significant development challenges Lawrence faced was ensuring the integrity of the individual user location data, which is critical to the proper functioning of the app. Drawbacks with the Global Positioning System (GPS) data alone include uncertainty over the age of the data—there is always a possibility that the user is many miles from the location where the last reading was taken—and whether the GPS was actually correctly locked on when the data was read.

Loclville screen layout on mobile.

During the early stages of development, Lawrence noticed inaccuracies in the location data, with data that were either imprecise or showed multiple locations. To remedy this, Lawrence implemented a hybrid process with which the app collects both GPS data from the devices itself and IP address data. These readings automatically update throughout the user session to ensure that positioning information is as accurate as possible and to guarantee the useful functioning of the app’s key distance radius features.

When serving up posts based on a user’s specific location, the server first receives a request for a post, and then compares the latitude and longitude coordinates of the requester with the latitude and longitude of the posts in the database. The posts within the defined radius are returned (Figure 1).

Figure 1.Sample code used by the Loclville app that establishes the distance between sets of latitude and longitude coordinates.

Touch and UI

Because Lawrence had no prior experience implementing a touch UI, understanding the different requirements related to menus, screen size, button size, and positioning on-screen was challenging. Lawrence used a responsive design approach, designing in such a way that the app or web site provided an optimized viewing experience across a wide range of different devices and screen sizes. Using this approach, Lawrence was able to ensure that the app serves up the appropriate UI for the device it’s running on, delivering a high level of legibility and straightforward navigation, with a minimum amount of resizing, panning, and scrolling required from the user.

Loclville running responsively on a variety of different screen configurations.

To determine how the UI should respond, the app queries the pixel size of the screen and the device itself, then uses those conditions to decide how to draw the UI and adapt to any changes. If the user rotates the screen of the device—for a tablet or smartphone, for example—or if the web browser window is resized, the app responds and adjusts the UI accordingly.

The original Loclville web site featured bold and simple buttons and menus that helped facilitate a relatively straightforward transition to smaller screens and touch controls. Tweaks were made to the drop-down menus and some of the links in order to optimize them for touch. These modifications included making buttons more finger-friendly by ensuring enough separation between them to help prevent accidental presses.

Adapting to smaller screens also involved repositioning some of the menus to make better use of the limited space available. The Distance, Categories, and Post buttons were moved to a footer menu, and posts were changed to be shown in a list view, making it possible to show more in a smaller space. Because of the overall simplicity of the layout, Lawrence decided against implementing any specific changes related to flipping between portrait and landscape views on a phone or tablet. The overall result of the optimizations is an app that is well adapted to multiple devices and screen sizes.

jQuery

Another challenge that Lawrence faced was that he needed to make jQuery work in a Windows 8 JavaScript app. Unlike the desktop version of the app, the Windows Store app had to meet code compliance requirements, which meant porting the jQuery library to allow it to work with the Windows Store version.

Figure 2 below shows the code implemented in the app for porting jQuery to work in the Windows 8 JavaScript app.

Figure 2.Sample code from the Loclville app for porting jQuery.

Testing

Beta testing the app was an informal process, conducted primarily by collaborators, their friends, and by the users themselves. After each set of changes, Lawrence released a new version of the code, and then proactively gathered feedback from users regarding its functionality, usability, and bugs. Lawrence said the testing was the most difficult part of the development process, noting that users often behaved unpredictably when using the app, making the testing both very important and challenging.

An example of unexpected behavior occurred when users were asked to input their address, a vital piece of data for the proper functioning of the app. Lawrence repeatedly saw an error stating that the app was unable to find the address. He eventually realized that the input question was ambiguous, causing users to enter their e-mail address, which naturally would not permit the app to pinpoint their physical location. The implementation of automatic geo-localization of the users using GPS and IP address data provided the solution.

Lawrence used a touch screen Ultrabook device for testing to ensure the integrity and proper functioning of the touch interface alongside the traditional mouse and keyboard controls.

Feedback from reviews has also proved useful on at least one occasion for identifying and fixing a bug, although Lawrence has been frustrated by the one-way nature of the communication with reviewers. The lack of ability to reply means there is no way to respond directly to let a reviewer know that a bug he or she discovered has since been fixed.

Metrics

To gather Loclville user behavior metrics, Lawrence implemented the open-source analytics tool Piwik*, which gathers data including the app version (for example, browser, Android, iOS*, or Windows 8), the user’s city, whether the user clicks a post, the link clicked to leave the site, and the session length. Lawrence also gathers his own data from the app, including number of posts, user location, and growth and usage patterns.

Lawrence analyzes the data to determine where users are coming from and then offers direct support to those within that locality by creating specific posts, with the goal of helping users grow the community.

Next Steps

Some of the features that Lawrence is considering implementing in the future include:

Localization. Making the site available in languages other than English, although which languages and when this feature will be available have yet to be defined.
Monetization. The ability to pay to post commercial offers and information. This feature will be based on the same rules of user voting, thus encouraging only content with real value to users.

Promotional offers in the Loclville mobile app.

Family filter. Placing more power in the hands of the individual user, as opposed to the community, regarding what content a user sees; for example, providing the ability to filter profanity. This feature would also potentially include the ability to prevent unregistered users from posting pictures. One related challenge is finding a way to filter in multiple languages, a problem that Lawrence is still working to solve.
Social media integration. On-screen buttons that allow users to directly share Loclville content through a chosen social network such as Facebook*.
Near Field Communication (NFC). Functionality to allow users to share posts by touching two devices together using NFC technology.

The next major planned update for Loclville is version 3.0, which is currently scheduled for release in September 2013.

Conclusion

Outside of the core coding process, Lawrence cited the following points as important to consider when creating apps:

Touch is important, but developers shouldn’t ignore the mouse and keyboard. Apps need to be user friendly for both types of user interface.
Awareness of screen sizes and orientation is crucial. Apps are now expected to run on more devices than ever, from the 10-inch screen of a Microsoft Surface* and 13- or 14-inch Ultrabook device screens to even a 30-inch desktop screen. With tablets and Ultrabook convertibles, developers also need to be aware of the different design demands of landscape and portrait layouts, and develop accordingly.
Take the time and effort to submit apps to both the Windows Store and the Intel AppUp center because the potential audience is huge.

Despite the concerns he heard regarding the use of HTML5 and JavaScript as an app development platform, Lawrence firmly believes that the combination of HTML5 and AJAX technologies was the right choice, and he plans to continue using a similar workflow for subsequent apps.

About the developer

A 2009 Masters graduate of the Savannah College of Art and Design in Georgia, Zubair Lawrence started programming as part of his Visual Effects degree course and rapidly developed both a strong affection and a clear affinity for it. He has since developed his coding knowledge and abilities beyond the Python* programming that was part of his course, becoming a competent self-taught application programmer.

In June 2011, Lawrence joined the CodeProject independent developer community (http://www.codeproject.com) using the moniker Helix Ten and continued to code avidly in his spare time even after joining California-based Sony Pictures Imageworks* in January 2012. In December 2012, Lawrence successfully entered the Loclville app into the Intel-sponsored App Innovation contest hosted on the CodeProject web site. Lawrence complements his professional work at Sony Pictures Imageworks with coding in his spare time, including ongoing support and updates to the Loclville app and web site.

Helpful resources

One of the most valuable resources for Lawrence during the development of the Loclville app was the development community on CodeProject, the site that hosted the Windows* 8 & Ultrabook™ App Innovation Contest. During development of the app, Lawrence interacted frequently with the community members, and he still visits the site frequently. The Intel HTML5 Encapsulator was invaluable in allowing Lawrence to bring the app to the desktop quickly, with a great deal of documentation and videos available to support the development process. Lawrence cited the documentation available on the Intel AppUp center as a vital resource during the app submission process, describing it as being very clear and thorough.

Portions of this document are used with permission and copyright 2012 by CodeProject. Intel does not make any representations or warranties whatsoever regarding quality, reliability, functionality, or compatibility of third-party vendors and their devices. For optimization information, see software.Intel.com/en-us/articles/optimization-notice/. All products, dates, and plans are based on current expectations and subject to change without notice. Intel, the Intel logo, Intel AppUp, Intel Atom, the Intel Inside logo, and Ultrabook, are trademarks of Intel Corporation in the U.S. and/or other countries. *Other names and brands may be claimed as the property of others. Copyright © 2013. Intel Corporation. All rights reserved