Building the Bing apps for Windows 8 - Windows 8 app developer blog - Site Home

Overview

For Windows 8, the Bing team built News, Weather, Finance, Sports, Travel and Maps apps. This technical overview provides insight on the architecture of these apps, key Windows 8 features and the contracts they use, common controls they employ, and world readiness more generally.

Several members of the Bing team formed an apps team approximately one year ago to deliver a set of apps powered by Bing for Windows 8. The focus of these apps is to keep users informed by delivering fast and fluid experiences, with content from multiple sources. All the apps are optimized for touch and tablet devices, but also work great with a keyboard and mouse. We have spent the last several months making these apps world-ready.

When developing the apps, we had two objectives: to build a set of great apps to make Windows 8 even more compelling and to serve as a model for app developers. With this post, we provide you with a technical overview of the apps and offer insight/resources you can use to develop your own apps. Through the process, we learned a lot – even a few things we’d do differently next time. Keep reading for the full story.

Weather app: Find the weather conditions for your places of interest.

Architecture overview

Platform services

All our apps are written in HTML/Java Script, except the Maps app, which is built in XAML/C#. All the apps share a common client platform that provides several essential services, such as instrumentation, caching, query services, settings, roaming, profile management, market customizations, and speech fundamentals. We deliberately chose to have client side caching, to invest in prefetching and for the client to set the time to live of various pieces of data for a couple reasons.

Our apps are designed for all PC devices, many of which we expect to be tablet devices. Windows 8 tablets can be used to consume content as well as create content by consumers and businesses alike. In many situations, we know users go through various states of connectivity (fully connected on fast networks, weak connectivity over WiFi or cellular, flaky networks, and even no connectivity). Our goal was to build a rich client app that’s different from a webpage. We used IE concepts of caching all network data to the file system and re-using cached data while waiting for fresh data to arrive. We also designed experiences for when cached data wasn’t available and network requests failed. For these scenarios, we, provide graceful error messages, retry mechanisms and listen for network connectivity changes from the OS to automatically trigger a retry.

Query services

Our apps use several services that are built on the Bing stack and/or in Windows Azure. The Bing services and data are served via dedicated application servers built on the Bing platform. For example, the Finance app heavily uses data and services from Azure, whereas data and services for the Maps app are provided via the Maps control, which is built by the Bing Maps team. Our apps also have other articles, images and videos that are hosted in our Content Management System. If you want to create apps that take advantage of the Bing web index or industry leading publisher data, check out the Windows Azure Marketplace, where you can access the Bing Search API and info from leading publishers like STATS Sports or agencies like the United Nations.

Caching

Supporting hundreds of millions of users interacting with rich apps that are powered by lots of data and content requires a lot of server computing. To scale the hardware needs along with the number of users, we have invested heavily in caching at different tiers. Our content management system rendering server, services in Azure, as well as the local client platform itself cache data to reduce the server load. If you’re anticipating several thousand users, consider local caching as a means to limit server computing and to improve the user experience – you can find out more about app caching (AppCache) on the Dev Center.

Some of the ways our apps make use of caching on the client involve:

Managing low and high res versions of the same image – choosing what to display based on what’s in the cache or not.
Client-side caching that override server-set content ages. Oftentimes the services we use aren’t owned by us and we can’t control those lifetimes, in which case our client decides on the caching.
Being careful to at least display stale cached data instead of downloading new data that may be invalid.

Custom controls

Design is a fundamental differentiator for our apps and plays a key role in building visually organized and intuitive to use apps. To achieve a consistent look and feel and a visually immersive experience across our apps, we built custom controls on top of the compelling UI controls that Windows provides. If you want a consistent look and feel across your apps or want to deliver against a signature user interface, we encourage you to take advantage of the flexibility of Windows and build your own UX framework or custom controls on top of Windows 8. There are ample resources available on MSDN to help you create your own UX framework and custom controls.

Failsafe

If your app relies upon data from a 3^rd party, plan on full outages as well as partial outages from your data providers from time to time. We strive to make our apps avoid single points of failure and we build in several failsafe mechanisms. We invested in various failsafe practices on both the server and client side primarily for the benefit of our users. Across all our apps, we have data and services from many parts of Microsoft as well as industry partners. All these external sources have varying degrees of uptime SLAs and TTM (time to mitigate) service level outages. Any given panorama on any application could rely on data and services from multiple sources. To provide a good end user experience, we use failsafe techniques both on the server and client side, including caching, backup providers, graceful degradation of features or falling back on acceptably stale data in some cases (for example, destination information). Think about these failsafe measures and take steps to create adaptive UI and error messaging when design and develop your app, not during or after a data failure.

Client framework – language choices

One question developers frequently ask is why we implement using client-side HTML, rather than server-based HTML5. The short answer is that apps on Windows 8 are not websites. Creating a great Windows Store app requires a deep level of integration with the platform that we simply cannot achieve with standard web code. If we had delivered features purely via the same HTML5 normally viewed in the browser, the pages would not have had access to the features of Windows 8 that really make the user experience great.

Building an app gave us several advantages, including:

Using the built-in controls of the Windows JavaScript Library (WinJS), which allowed us to leverage the power of Windows 8 and build on top of the experiences that the Windows team has built. We think we’ve delivered a great user experience (UX) provided by WinJS.
Native app platform features not accessible via HTML5 in a browser:

Device features such as access to the microphone, webcam, or network
Shared file locations such as My Documents, Music, Pictures or Videos
Participate in contracts, including those for searching, sharing, settings, contacts etc.
In addition certain libraries are better in WinRT compared to HTML5. For example, the WinRT geolocation APIs are richer than those found in HTML5.

Supplementing the JavaScript code with performant, statically-typed, code in C#. We used language constructs that don’t exist in JavaScript – for example, LINQ as well as the .Net4.5 Asynchronous framework. The latter is very important because it helps ensure correctness in asynchronous operations, which can get quite complex.

Be aware that if you write a WinMD to host business logic (whether in C# or C++), there’s a cost to marshaling lots of data between languages. It’s better to have one call that marshals a lot of data, rather than many calls that marshal little data. Additionally, C# and JavaScript have separate, independent garbage collectors. Because they’re not in sync, it’s possible that your memory usage will be larger than if you were to write an app wholly using JavaScript or C#.

When we developed our apps we decided that the benefits of a JavaScript and C# mixed language app were worth the extra costs of working around these complexities. We made sure that our apps still performed great. If you’re considering combining JavaScript and C# in your app, keep the extra cost and complexity in mind. This way you can choose the architecture that best fits the requirements of your app.
Building our Maps application on top of XAML to access the native DirectX Map control. This approach gave us even more control and greater performance of our rendering (critical with a map!).

Developing for Windows offers a standard set of experiences (screen size, touch targets, view states, orientation dimensions, among others). We wanted to tailor our code to offer the best user experience, given the user’s device. A one size fits all HTML5 experience doesn’t let us deliver a consistent and optimized user experience.

Key Windows 8 features & contracts

As I mentioned earlier, one of our objectives was to serve as a role model for 3^rd party app developers. We wanted to call out several key Windows 8 features and contracts that we’ve implemented in an effort to make our apps more compelling for consumers as well as highlight what’s possible for you in Windows 8:

App bar

All apps offer navigation in the top app bar and contextually-relevant command buttons in the bottom app bar. These are accessed via a gesture (swiping down from the top of the screen or up from the bottom).

Maps app – app bar

Snap mode

Every app features a carefully designed snap mode. We didn’t just replicate all the features of the app in a narrower view. Instead, we thought about how the app might be used when snapped. In News for example we provide quick access to the list of stories, but don’t have a mini reading mode. We expect users to go back to full screen when they want to read. In Finance, the snapped view focuses on the main indices and your stock watchlist. In Weather, the snapped view provides a summarized description of the weather in the upcoming days.

Weather app & Finance app – Snap mode

All of our apps supports the share source contract. This contract allows us to send data to share targets like the Mail or People application.

News app – Share

Print

The Maps app supports the print contract to print maps, details, directions, and search results.

Lock Screen

The Weather app uses the lock screen to inform the user of current weather conditions, without having to unlock and run the app, or even go to the Start menu.

Live Tiles

Except Maps, all our apps have Live Tiles and offer consumers useful notifications such as the latest news headlines, weather conditions and sports scores or other interesting information. So even on the Start screen, these apps are alive with activity, encouraging users to launch the app to find out more.

Search

Every application supports the search contract, via the search charm. The search charm continues to be the place consumers can find local files, apps, and other information in Windows 8.

Travel App - Search

Settings

Every application supports the settings charm. The settings charm provides users a consistent way to access settings across all apps.

Semantic Zoom

Our panoramas and list views support semantic zoom, a touch-optimized technique for presenting and navigating large sets of content within a single view. Because our apps are content-heavy with many groups of information, semantic zoom allows a user to get an overview of all that content, and jump directly to a group of interest.

Globalization

Each app makes use of the new Windows 8 language manager and home location settings to optimize for the best experience for the user. As users start learning about these settings and see that apps respect them, all apps will get better as a result.

Accessibility

One of our goals in developing our apps was to offer all users the great level of accessibility and productivity provided by the news Windows 8 UI. Below are some highlights of the accessibility work we did for our apps.

Keyboard - Our goal was to maintain the fast & fluid keyboard behavior found in the Windows 8 Start Screen and across Windows apps. Users can navigate across grids of tiles and headers, using arrow keys, and invoke them with the ENTER or SPACEBAR keys. The biggest challenge for us was the dynamic nature of some of our tile layouts (e.g. the News app). Based on Windows guidelines, we adopted some conventions that are different from the typical webpage in browser model. In our apps, you can use the BACKSPACE key to 'go back', instead of using the ALT+LEFT, or a 'browser back' button if your keyboard has one.
Screen Reader – We took advantage of HTML4 (h1-h6, ol, li, etc.), the increased semantic tag support in HTML5 (header, hgroup, section, etc.), and the exciting world of ARIA roles, states and properties to aid screen reader AT (assistive technology) as a means to improve the user experience for all users. In addition to actively testing and debugging with Narrator, we found Inspect, a helpful tool that gives a live view of the programmatic access tree used by Narrator.
Narrator Touch – The good foundations we laid for keyboard accessibility and screen reader accessibility (DOM hierarchy, semantic HTML, ARIA roles/states/properties, etc.) paved the way to make sure our apps supported all the cool Narrator Touch features, such as double-tap invoke, 2-finger swipe and flicking between items. With Narrator Touch enabled, blind customers can use Windows 8 on touch screens.

Custom controls

While each of our apps provides unique info and functionalities, they all share the same general UI design that visually ties them together. For example, the navigation buttons in the top app bar look and work the same way in all our apps. And the news articles in the Sports app share the same visual elements as those in the Finance app.

It was a critical goal for us was to make our apps look and feel the same. Sticking to basic Windows guidelines and principles, we wanted all our apps to have a common workflow for accomplishing basic tasks, such as adding a stock ticker in the Finance app or adding a location in the Weather app. A common interface makes it more intuitive for users to interact with multiple apps. From an engineering standpoint, it enabled us to share a larger code base between our different apps and freed our engineers to focus on building differentiating app-specific features. To achieve this goal, we built several custom UX controls (details below) specific to our apps that are used by the Finance, Weather, Sports, Travel, and News apps.

There are many basic intrinsic controls available in HTML for developers to leverage, such as buttons and text boxes. On top of these, WinJS provides richer controls that have more complex UI and business logic, such as list view and app bar. When identifying which controls to use for the visual elements in our apps, we made sure to reuse intrinsic or WinJS controls as much as possible. In cases where we needed more sophisticated UI or business logic, we built custom controls that follow the WinJS guidelines. Some of our custom controls are composite controls made up of base WinJS and HTML controls, while some are derived from WinJS controls, and others are written from the ground up.

Integrating with WinJS

By building custom controls using the same principles as WinJS controls, we made it easy for our engineers to seamlessly develop and debug apps that use both WinJS and custom controls. More importantly, by building for WinJS templates, the presentation layer of our controls (HTML/CSS) is isolated from the business logic (Javascript). Here are a few key principles that we followed:

Each control has a WinJS-friendly constructor that accepts two arguments: the top-level DOM element, and the control options for that instance.
In order to work with WinJS template bindings, we define public getters and setters on each control that reflects the observable data model behind that control.
We avoid creating behaviors that require handling the control instance directly. Every interaction is facilitated through public properties and methods.
We leverage the WinJS.Namespace and WinJS.Class APIs to define our controls in a syntax that is intuitive and familiar to developers.
To add custom events to a control, we mix our control classes with WinJS.Utilities.eventMixin or WinJS.UI.DOMEventMixin. This augments our controls with methods for dispatching events, and adding or removing events listeners. The interface to these methods is addEventListener, removeEventListener, and dispatchEvent, which is very familiar to HTML and Javascript developers. To find more information on creating custom WinJS controls, click here.

Using CSS3 for layout

We took advantage of the hardware accelerated performance and many great new features of CSS3 to build the layout of our controls.

We used grids, flexbox, regions, exclusions, pan and zoom, animations, and transforms to produce rich layouts that are less intuitive, if not impossible, to build in CSS2 and below. We used CSS media queries to handle the layout for different screen resolutions and orientations. This is the best way to handle rotation and snap, because it pushes off the heavy lifting to the GPU and frees up CPU cycles.

In general, we made sure to push as much of our layout logic to CSS as possible in order to maintain a high frame rate and UI fluidity.

Notable custom controls

There are over a dozen custom controls that our apps use to enhance the experience for users. Here’s are 2 controls that take advantage of the infrastructure described above:

Ads - Display ads can appear in our apps in the panoramas and in articles viewed within articles (the “article reader”). Our team uses the ads control from the Microsoft Advertising SDK to render ads. Articles have a property that specifies whether the article qualifies for an ad or not. The article reader currently uses some simple counting logic to display a full page ad on the second page of an article, or a single column tower ad at the end of the article, or both.
Article Reader - Every application has access to the Article Reader control. Our apps can pass a number of HTML fragments, images, and videos, along with layout information, and the article reader will automatically lay out the content in columnar form. The control is implemented using the new HTML regions mechanism in HTML5. It can parse the appropriate data from our CMS system automatically, without requiring the app to manually parse data.

News app – Article Reader control

World readiness

Given the global reach of the Windows Store, we anticipate you might want to make your apps extensible to different markets and languages. As mentioned previously, all our apps are available in all supported Windows markets. We elected to build for all supported Windows market as a means to get our apps to as many Windows customers as possible. This section highlights the key components of work we did to get all our apps world-ready.

Localization - The first and likely most obvious task you must undertake is translation. We localized the set of apps in 106 languages. To do so, we set up a process to turn around translations of the chrome of the apps as well as server-side translation for various middle tiers. Additionally, there’s a helpful toolkit for Visual Studio that includes localization support – you can find out more about this toolkit here. Depending on how deep you want to go in each market, you might need to translate the chrome as well as the content within your app(s).
Market Customization - As part of our configuration system, it’s possible for apps to enable or disable features, based on the market where the app is running. In general, we define a market as the combination of the user’s language preference (Under Control Panel -> Clock, Language, and Region -> Language) and user’s home location setting in Windows (Under Region -> Location). The APIs we use to deliver market customization include:

Some market-specific features in our apps:

Travel app - Flight search for specific markets (e.g. EN-US, FR-FR)
Weather app - Utilization of different weather sources by market
Sports app - Region specific sports leagues available by default to the user

Physical Location-Specific Mechanisms - There are two mechanisms where the actual physical location of the user is used:

Startup app-blocking - If the app is in an area where we are not allowed to serve content (embargoed region), the app displays a message to the user indicating that it cannot be run in this region, and shuts down.

Physical Location Marketization – If the user is in a country where certain features should or should not be enabled or certain servers must be used (as might be the case for you as you develop apps for some markets), the app can configure this requirement. This necessitates a modification of the Market Customization feature noted above.

App-Specific World Ready Features – We created a number of features in our apps that have international appeal. For example, we opted to build and emphasize flight schedules and flight status in our Travel app, rather than focus on just flight booking, because we’re not currently able to offer flight booking in many international markets. If you’re developing for international markets, we’d encourage you to think in advance about markets where you might not be able to deploy specific features and focus your time on developing and enhancing those features that you know can and will be used more broadly.

Performance and responsiveness

Between RTM and GA for Windows 8, the teams went through a milestone of performance improvements. Some of the areas that were worked on include:

Tuning the startup path in order to optimize CPU usage and I/O calls. Some of the tasks included:

Making independent tasks run in parallel so that they can run on different cores.
Ensuring that CPU-bound tasks are not blocked on I/O bound tasks

Ensuring that prefetching occurs wisely so that data will be available for a user before the user views it. For example, we may prefetch the first article of a panorama because users may tend to click on those often.
Adding business logic to our image control so that it will display lo-res and hi-res images optimally – i.e. read from cache or read from network depending on what already is in the cache.
Minimize the number of function calls that marshal across the JS/C#/C++ boundary.
Ensure that long-processing tasks on the UI thread were broken up into smaller discrete tasks. This minimizes UI freezes.
Pass around references to image files on disk instead of blobbifying them and passing blobs around. Blobs are good for certain types of operations, but when we needed to pass around large numbers of images, the performance dropped off.

We’d like to hear from you!

In addition to encouraging you to try out our apps and send us your feedback, we’d like to hear from you! Please leave us a comment and tell us more about your experiences building apps for Windows 8. Let us know if you have questions, and we’ll be happy to provide more detail. We’d also appreciate you letting us know what we could provide you to help you develop apps for Windows 8.

--Jigar Thakkar, Partner Development Manager, Application Experiences Team