Case Study: A Facebook Application for Windows Mobile 6

4/7/2010

Matchbox Mobile

2009

Summary

This document describes making a Facebook client application for a Windows® phone, concentrating on design choices and working with the Windows Mobile platform.

Applies To

Windows Mobile 6

Windows Mobile 6.5

The Story of a Windows Mobile Application

Challenges and How We Met Them

Designing the Experience

Evolution of a Screen Shot

The Phonebook Tab

Common vs. Custom Controls and the Windows Template Library

Installing Across Many Platforms

Run-Time Checking, Platform-Specific Behavior, and Rotation

Using What Windows Mobile Gives You

Limitations of Windows Mobile, and Things to Look for in the Future

Introduction

This case study looks at a Windows Mobile 6 software client for Facebook, developed by Matchbox Mobile. We explore the problem to solve, the challenges to overcome, and the Windows phone features to maximize. We describe useful strategies for Windows Mobile development based upon our experiences developing the Facebook client. If you are a developer or product manager, this document should offer useful insights into creating a high-quality client application for Windows phones.

This document discusses how and why we did the following:

• Created a single installer to target all of our chosen Windows phone platforms.
• Used native C++ development and the Windows Template Library for a faster and more flexible application.
• Developed a completely new type of list control to address the specific needs of a Facebook application.

The Story of a Windows Mobile Application

Two notable trends in technology made the appearance of Facebook on Windows Mobile inevitable: the mass take-up of social networking, and the increasing power of mobile phones.

The appeal and growth of social networking in general, and Facebook in particular, have been remarkable. Millions of users around the world input information and share their lives with friends and acquaintances through social networking sites. The practice has passed into the mainstream as personal e-mail did a decade ago.

In parallel, we have seen the increased use of powerful phones with operating systems that can run custom software applications. So-called “smartphones” are becoming more popular as prices drop and the technology matures. A wide range of manufacturers offers Windows phones with a variety of form factors. Common to most modern Windows phones is a set of multimedia and connectivity features that allow the capture, transmission, and sharing of pictures, videos, and messages beyond the traditional medium of Short Message Service (SMS) texting or Multimedia Message Service (MMS) messaging. Wireless Internet connectivity, through Wi-Fi, is becoming a standard feature; video cameras are well established; higher resolution devices are gaining in popularity.

As phones became more powerful, and Facebook more popular, catalysts appeared in the form of “all you can eat” data packages and the proliferation of Wi-Fi networks in homes, offices, and urban spaces. These factors have converged toward a powerful and appealing idea: to enable social networking software on a phone, and specifically Facebook on Windows phones.

Facebook’s earlier forays onto smartphones met with good success. The RIM BlackBerry was the first platform to gain a dedicated application, but the biggest splash was made by the free Facebook application for iPhone (which even featured Facebook access as a selling point for the phone itself). Facebook also offered a mobile version of its Web site (https://m.facebook.com) that addressed the specific needs of small-screen devices (the theme of adapting the Facebook experience to mobile devices will recur throughout this article).

The mobile Facebook Web site had several limitations, mostly tied to the capabilities of the browser on the device (for example, users could not upload photos directly using the Web site but could send photos by e-mail or MMS) but primarily because it could not match the user experience of a dedicated application. The need for a stand-alone application on Windows phones spawned several third-party offerings with varying degrees of functionality.

Given the popularity of the BlackBerry and iPhone Facebook applications, and the limitations of the mobile site, there was no doubt at Matchbox Mobile that an official Facebook application for Windows phones was required. Matchbox Mobile’s challenge was to understand the use cases and the unique features of Windows phones, and to deliver a user experience that combines the best of Facebook with a compelling user interface that compares favorably to other platforms. Success lay in capturing what made Facebook so “sticky” and in presenting it the best possible way, while making best use of the strengths of the Windows Mobile platform.

Our research began with extensive use of the Facebook Web site and informal surveys of the popular aspects of Facebook use. It continued with a close study of the iPhone application, the Facebook mobile Web site, and third-party offerings on Android, Windows phones, and BlackBerry. The aim of this research was to identify which features must be present to be competitive, what worked well in existing mobile implementations, and what we could do better in a Windows Mobile Facebook application.

A major factor that we considered was the sheer number of Windows phones on the market. For the iPhone’s handful of variants, all of which share the same resolution and input methods, Windows phones presented dazzling combinations of high-resolution and low-resolution, keyboard and touch, QWERTY and phone pad, and portrait, landscape, and square-screen phones. Added to this variety is the split within the operating system itself between Professional and Standard editions. Our Facebook application needed to look just as good and be as easy and fun to use on all of those devices.

The many potential deployment targets for our application meant that we had to plan for design, development, and testing to cover all possible scenarios. We put in extensive planning to anticipate potential problems and to identify common elements across all platforms. After we mapped the critical aspects of Facebook use and isolated the variables for implementation, we set about creating the software with confidence and with clear goals.

The result of our research, design, and development is a free application that has exceeded one million downloads and gained positive reviews. The development team gained valuable experience developing for Windows phones. The following section shares those lessons.

Challenges and How We Met Them

The first challenge was determining how to design and develop a good-looking application on Windows phones that preserves the Facebook experience. We asked ourselves what the state of the art was in terms of a mobile device user interface, and what users of other phone platforms thought was an expected minimum standard. We saw transitions, transparencies, and finger-friendly user interfaces. We knew that other phone platforms provided much of the engineering required for those features as standard. What about Windows phones?

When this project began, Windows Mobile 6.5 was still in beta; it promised an exciting “refresh” of the user experience in terms of graphics and its general look, but also with a gesture engine that allowed new modes of interaction. We wanted to take advantage of the new Windows Mobile 6.5 features without demoting the experience for Windows Mobile 6 users.

Designing the Experience

With Windows Mobile 6 and 6.1 as our baseline, we examined the available tools and began to design the user experience on paper. Special enhancements for Windows Mobile 6.5 would come later, mostly through implementing the touch interface. The goal of this process was to clearly set out what the experience should be like; discovering what we could translate into actual code on Windows phones would come later.

The paper design exercise proved critical to success: it allowed us to implement quick early reviews and to involve all stakeholders from day one. “Paper design” in this context meant pencil drawings on paper, which set out basic flows and screen layouts. We discussed and analyzed scanned copies of the drawings; after dealing with any issues, we updated the drawings and sent out a new set for review. And so on.

After we had agreed on a rough shape for the application, we moved on to making wireframes. These designs took into consideration aspect ratios, typical screen space, and modes of interaction. We used the wireframes to isolate more fine-grained issues, refining the design sufficiently to create screen mock-ups.

This design-driven development approach afforded two advantages:

• We could focus on getting the experience right.
• We got a clear picture of the business logic we would have to support and how that drove our data and back-end requirements.

While our designers carried out the user-interface research and design, our engineering team began working on the data access layer to hook into the Facebook API over the Web. It was imperative for our tight deadlines, and later, for testing, that the Facebook access engine be cleanly isolated from the UI. We developed both in parallel, so that when we integrated the UI and the backend, we had a functional, well-tested data layer.

After creating, reviewing, and finalizing the screen mock-ups in Adobe Photoshop, we dug into how to implement them on a Windows phone. The engineer and design teams worked together to isolate behaviors that might be costly to implement and to assess if they were critical, or simply nice to have. We found that some transitions would be time-consuming to implement. Also, some areas of transparency combined with animations might be trickier than we had hoped. For example, we wanted the screen to fade slowly to a semi-opaque black when a message alert popped up—it turned out that this had to go.

Evolution of a Screen Shot

The following sequence shows snapshots of the visual and user experience design process, from pencil sketch to finished product. At each stage, we revisited the requirements and reassessed the reality of the experience against what was possible and what was desirable.

Figure 1 – Pencil sketch of inbox screen

The pencil and paper sketch aims to capture key concepts like layout, logic, content density, and navigation options.

The engineering and marketing teams review and assess the sketch to ensure it meets requirements and can be implemented within the schedule.

Figure 2 – Pencil sketch, landscape

Figure 2 adds information to address landscape orientation and layout changes.

Figure 3 – Wireframe of inbox screen

The wireframe in Figure 3 is a refinement of the layout that shows additional content details. It proposes menu items and orders, and highlights functionality that isn’t obvious. It should be possible for the engineer to take this wireframe and, consulting with the designer, create the working screen.

Figure 4 – Inbox screen, actual screen shot

In Figure 4 we see the finished product. Using graphical resources applied to the information in the wireframe and design documentation, we have a custom list control, top-level tabs, secondary-level tabs, and soft key menus. This includes final details about font weights, text color, highlighting, and touch-related color changes as the screen shot demonstrates.

The Phonebook Tab

The screen shot in Figure 4 shows the Phonebook tab, a UI feature that sets this Windows phone implementation apart from other Facebook clients and the Web site itself:

Figure 5 – Phonebook tab art

The Phonebook tab is an example of our drive to differentiate the Windows phone while using the strengths of the operating system (see the section “Using What Windows Mobile Gives You” for more details). The phonebook collects all the contact information for all Facebook friends and places it in a single, easy-to-use collection, just like a physical phonebook. It offers a quick way to find contact information without navigating through a variety of sub tabs within each Facebook friend page.

The Phonebook Contact feature relies heavily on Windows Mobile APIs for phone dialling, SMS texting, MMS messaging, and composing e-mails.

Figure 6 – Phonebook contact page

Common vs. Custom Controls and the Windows Template Library

Preserving the Facebook user experience and proposed screen flows were top design priorities. Our engineers identified common Windows Mobile UI controls to use, and made a list of custom controls that we would have to create. The most important of these custom controls was the special list control.

One of the key elements of Facebook is the concept of the list: news feeds, wall posts, and status updates all rely on a single-column list. A Facebook list is easy to spot: it tends to contain a mixture of formatted text and images, and list items can have different heights. The requirement for variable height items drove us to create an entirely new UI control that did not derive from a standard Windows control. We referred to this special list control as the “Facebook list control.”

The need for a special list control affirmed the value of our general policy of using native code for our applications. Not only did we find that Win32 development gave us more fine-grained control of every element of the software, but we also used a favorite development tool, the Windows Template Library (WTL). Microsoft provides (but does not officially support) WTL as an open source project. WTL has proved its worth over many software projects that required user interfaces that pushed beyond the norms established by other Windows phone applications. Using WTL we were able to create user interfaces quickly and manage them easily, but also dig into specific areas at the native code level and have complete control over the tiniest aspect of functionality. We used Win32 native code to craft a Facebook list control, which we then used throughout the application, along with standard WTL controls.

Developer Tip: Windows Template Library and Visual Studio 2008

To build projects that reference WTL, you need to do two things: Get the Windows Template Library. The current version at time of writing is WTL 8.0 and is available from this Microsoft download page. Unzip the package and make a note of the unzip folder path (C:\WTL80 by default). Include WTL headers in your Visual Studio environment. In Visual Studio 2008, go to Tools > Options and under Projects and Solutions, choose VC++ Directories. For each platform you are targeting add the WTL include path (for example, C:\WTL80\include) to the list of include folders.

The preceding developer tip is an example of how we used our many years of Windows programming experience to extend what is normally possible with Windows phones so that we could support the design vision set out in the wireframes and mock-ups. After we had created this critical component, we were well on our way to delivering a genuine Facebook experience on the Windows Mobile platform.

Installing Across Many Platforms

The wide choice of form factors and screen resolutions of Windows phones and the difference between a touch-based and directional pad (D-pad)–driven interface affected our design. Windows phones are either Professional or Standard editions. Windows Mobile Professional will have a touch screen, in addition to a possible five-way navigation pad (the D-pad) or hardware scrolling and buttons. Windows Mobile Standard phones do not have a touch screen. Because of the common API set that Microsoft provides for Windows phone development, you can largely run the same code on both operating system variants. We had to ensure, therefore, that the same user interface worked with or without a touch screen.

We took Windows Mobile Standard as our base build target, because this would cover the intersecting capabilities of both Standard and Professional. This meant we could ensure that every screen worked well using only the D-pad. During a second pass, we added touch capabilities to screen controls like buttons and lists. Windows Mobile provides an API to detect, at run time, on what kind of platform you are running. Windows phones also offer the ability to restrict your installation to specific platforms if you want to target only a subset of operating system variants. With these two choices, we took the decision to make all platform-specific choices at run time rather than at installation.

The Windows phone setup process allows heavy customization of installation using cabinet (CAB) files and optional setup dynamic-link libraries (DLLs). For example, we could have transferred all the platform-specific logic into the Windows CE setup DLL along the following lines:

1. Break up the application into platform-specific assemblies and a common stub.
2. Prepare the CAB file to include all platform-variant files.
3. At installation, copy out all files and then, using the setup DLL, delete the irrelevant files.

The net result would have been a platform-specific installation, and one that would require no run-time checking of platform properties like screen resolution and touch capabilities. We rejected this approach for two reasons:

• Using this approach would have increased the complexity of the solution and made the code harder to maintain. UI logic would split up into many components.
• This approach would have made the installation unwieldy and increased the burden of testing. Because the setup DLL is a simple set of functions, it is not ideally suited to structured, object-oriented programming. Convoluted custom install behavior can grow within the DLL in a way that is difficult to manage. Overuse of the setup DLL can lead to spaghetti code.

A second approach we dismissed was to create platform-specific CABs, each containing only the code and resources specific to that platform; for example, two CAB files for Professional (high and low resolution) and two for Standard (high and low resolution). We chose not to do this because having a single installation CAB was a high-priority requirement for distribution. A single CAB file meant a simple deployment scenario, and meant we could maintain and upgrade the software easily, with fewer variants to track.

We decided to implement a universal installer in a single CAB file that covered all operating system variants, from 6.0 to 6.5, including Professional, Standard, and high- and low-resolution Windows phones. This meant we could put all the platform-specific behavior in the main application, where it was easy to design, manage, and debug. As we will demonstrate, the planning we put into the UI design, plus the resources made available by the Windows Mobile SDK meant that we had to do very little to adapt to specific platforms at run time.

Run-Time Checking, Platform-Specific Behavior, and Rotation

To keep a common set of binaries for installation, we had to adjust our UI after performing an initial system query (using the SystemParametersInfo call) and in response to Windows messages when the screen size changed (screen rotation events).

The following code example demonstrates determining platform type.

//When our application starts, we query the platform type and set a 
//global variable to indicate whether the Windows Mobile edition is 
//Professional or Standard. This tells us whether we are going to need 
//touch elements in our UI.

TCHAR szPlatform[256];

if (SystemParametersInfo(
  SPI_GETPLATFORMTYPE,
  sizeof(szPlatform),
  szPlatform,
  0
  ) != 0)
{
  bool isWMProfessional = (CompareString(
    LOCALE_INVARIANT,
    NORM_IGNORECASE,
    szPlatform,
    -1,
    TEXT("PocketPC"),
    -1
    ) == CSTR_EQUAL);
}   

When the application starts, we query all relevant system parameters to get the screen resolution and to determine whether the Windows phone has a touch screen and whether it has a physical keyboard. We then set a global variable for later reference. All UI code can use this variable to determine, for example, whether to place a button in a dialog box or to add a menu item to a soft key menu. The differences between Professional and Standard are surprisingly few, and Windows Mobile is evolving such that Professional and Standard are converging, making it easier to target both with a single executable. The nature of the Facebook UI also helped us use large amounts of common code, because it is primarily list-based. We found we could use the same layout for Professional and Standard. We were also able to take advantage of the extensive planning and paper design stage to factor this commonality into our implementation.

Developer Tip: Detecting a Physical Keyboard

Windows phones provide a software-based input panel (SIP) to allow text entry into edit boxes and forms. Many modern mobile devices, particularly those running Windows Mobile Professional, come with a QWERTY keyboard that negates the need for a SIP. By checking for the presence of a physical keyboard, we can make decisions about layout and screen behavior to ensure our design fits the device form factor. To check if the Windows phone your application is running on has a physical keyboard, query the registry value HasKeyboard under: HKEY_CURRENT_USER\Software\Microsoft\Shell The value of HasKeyboard will be set to 1 if there is a physical keyboard present on the device.

By adopting Windows Mobile 6.1 Standard as our core target platform, we could add on components for specific platform variants. Touch behavior, as mentioned earlier, was one of these components. The biggest task here was to enable gesture support for Windows Mobile 6.5. This required registering for flick events using custom Windows messages, which we used for smooth scrolling of the list views in the application and for switching between tabs. If we had used an owner-drawn list control—that is, one derived from a Win32 list control—we would have had gesture support at no additional cost; the base Windows control in Windows Mobile 6.5 includes the gesture logic. However, because we were using our own completely custom control, we had to take this extra step and register to receive flick events from the system. Windows Mobile makes this quite simple (using RegisterWindowMessage): after we received the message, we queried its parameters to determine how far and how fast to scroll our list before animating the list ourselves.

Windows phones typically allow the user to change screen orientation, or will rotate the screen to support sliding out a physical keyboard. Windows phones broadcast a WM_SIZE message to all applications when the screen size changes, including when a screen rotation event occurs. By listening for this message, we could apply a suitable layout, and then update graphic resources and layout accordingly. Again, thanks to the pains taken at the design phase, and to the closeness with which we adhered to the Facebook look, we were able to handle rotation with minimal effort.

Using What Windows Mobile Gives You

The preceding example is one of many instances in which the operating system helped us use well-documented APIs to achieve our aims cleanly. There are a few more examples where Windows Mobile provided the tools to solve common problems neatly and with relatively low effort (and lower risk).

One sensitive feature of our application is storing user credentials on the Windows phone. Programming history is rife with examples of “home-baked” methods of encrypting and protecting data. This approach is both dangerous and unnecessary, especially when the tools to do the job safely are already available. Microsoft provides the CryptoAPIfor just this purpose. The CryptoAPI on Windows phones is a subset of the desktop Windows version of the API. Using CryptoAPI, we let the system do the heavy lifting.

A good primer on CryptoAPI on Windows Mobile is available in this MSDN blog post.

When we developed Facebook for Windows Mobile, no other mobile Facebook client supported video uploading. We felt this was a good opportunity for us to differentiate the Windows Mobile application. Using Windows Mobile shell commands we were quickly able to capture video and configure the required quality settings. Using the SHCameraCapture API, we could create our own video capture form and grab the resulting video for uploading to the Facebook servers.

The following code example demonstrates creating a camera capture dialog box using SHCameraCapture.

//The following code shows a utility function to invoke the camera 
//capture dialog box for both photo and video capture. The code late-
//binds to the SHCameraCapture API to support phones without a camera.

HRESULT SHCameraCapture(PSHCAMERACAPTURE pshcc)
{
  typedef HRESULT (*fnSHCameraCapture)(PSHCAMERACAPTURE pshcc);

  HRESULT hr = S_OK;
  HINSTANCE hAygShell = LoadLibrary(TEXT("aygshell.dll"));
  fnSHCameraCapture funcSHCameraCapture = NULL;

  if (!hAygShell)
  {
    hr = HRESULT_FROM_WIN32(GetLastError());
    goto FuncExit;
  }
  
  funcSHCameraCapture = (fnSHCameraCapture)GetProcAddress(
    hAygShell,
    TEXT("SHCameraCapture")
    );

  if (!funcSHCameraCapture)
  {
    hr = HRESULT_FROM_WIN32(GetLastError());
    goto FuncExit;
  }

  // call the API now
  hr = funcSHCameraCapture(pshcc);

FuncExit:
  if (hAygShell)
  {
    FreeLibrary(hAygShell);
    hAygShell = NULL;
  }

  return hr;
}

void CapturePhoto()
{
  SHCAMERACAPTURE sh = {0};

sh.cbSize = sizeof(SHCAMERACAPTURE);
  sh.hwndOwner = m_hWnd;
  sh.Mode = CAMERACAPTURE_MODE_STILL;
  sh.StillQuality = CAMERACAPTURE_STILLQUALITY_DEFAULT; 
  if (S_OK == UTILS::SHCameraCapture(&sh))
  {
    // sh.szFile has the file name of the photo
  }
}

void CaptureVideo()
{
  SHCAMERACAPTURE sh = {0};
  sh.cbSize = sizeof(SHCAMERACAPTURE);
  sh.hwndOwner = m_hWnd;
  sh.Mode = CAMERACAPTURE_MODE_VIDEOWITHAUDIO;    
  sh.VideoTypes = CAMERACAPTURE_VIDEOTYPE_ALL;    
  if (S_OK == UTILS::SHCameraCapture(&sh))
  {
    // sh.szFile has the file name of the video
  }
}

Photos are a big part of what makes Facebook fun. Viewing, sharing, uploading, and tagging are all necessary operations, but they also require additional bandwidth. Because a mobile device in fluctuating network conditions (that is, switching from GPRS data to Wi-Fi to zero Internet access) must be conservative with network resources, we wanted to find a prudent way of downloading only what was necessary, and caching as much as possible. Windows Mobile provides a useful mechanism for caching downloaded images in the Internet Explorer Mobile cache. A trio of API calls makes it easy to download only items not already in the local cache. This is a good practice especially for high-frequency items, like Facebook friend profile photos.

Developer Tip: Caching Images
These three WinInet functions help reduce bandwidth use in a mobile application: GetURLCacheEntryInfo tells you if an item you are about to download already exists locally. If it does, you can conserve battery power and data bandwidth by reading the local copy. InternetOpenURL opens an online resource. InternetReadFile reads the data for the resource.

Limitations of Windows Mobile, and Things to Look for in the Future

Our design-driven development process and experience across mobile platforms meant that we could fine-tune the user interface to the strengths of Windows Mobile. Although we could have used DirectX to create some of the visual effects users of other device types have come to expect, we chose to instead focus on the integrity of the Facebook experience, and to make good use of Windows Mobile features. DirectX would have imposed an additional cost in recreating standard Windows controls like edit boxes and buttons, and added a completely new layer of management to our application. It was too onerous for what we wanted. We created custom controls where necessary alongside graphics device interface (GDI) graphics and standard controls like the standard scroll bar where the alternative would have meant a large effort or the possibility of breaking the standard Windows Mobile UI conventions.

Despite the absence of certain UI-focused features that the Android OS or iPhone OS provide, we were able to use our many years of Windows Mobile experience to deliver a good-looking and exciting Facebook application using Windows Mobile 6.5.

Conclusion

In this case study we have looked at how Matchbox Mobile approached the task of creating a Windows Mobile 6 software client for Facebook. We described some of the challenges we overcame, as well as ways we maximized features of the Windows phone. The strategies we used in this project should prove useful to developers and product managers in creating high-quality client applications for Windows phones.

Matchbox Mobile is a software developer and consultancy that specializes in mobile and embedded devices. Founded in 2005, and with over ten years’ experience in the industry, Matchbox Mobile has helped mobile operators, device makers, independent software vendors (ISVs), and platform developers at all levels of consultancy, software development, and research on a wide range of platforms.