Please note that as of October 24, 2014, the Nokia Developer Wiki will no longer be accepting user contributions, including new entries, edits and comments, as we begin transitioning to our new home, in the Windows Phone Development Wiki. We plan to move over the majority of the existing entries. Thanks for all your past and future contributions.

Mobilising websites: building a Web Runtime widget for Bing

From Wiki
Jump to: navigation, search
Article Metadata
Created: jappit (25 Jun 2009)
Last edited: hamishwillee (09 May 2012)
Featured Article
18 Oct

This article shows the design and development process of the Bing Web Runtime widget.


Step 1. Choosing functionalities

Bing is a search engine, developed by Microsoft, that allow users to search for different types of content: web pages, news, images, videos and much more. Also, the Bing website offers additional services, as Maps, Translations, Travel Planning and Shopping sections.

The first version of the Bing WRT widget will exclusively focus on the search functionality, and on these types of content:

  • Web Pages
  • Mobile Web Pages
  • News
  • Images
  • Videos

Step 2. Defining the layout

Generally speaking, clear and polite layout is a must when developing a mobile application, due to the physical and environmental constraints of mobile devices and of their usage.

Since the main focus of this widget is on search, these points are also to be considered when thinking about the widget's layout:

  • immediateness of use: most users are already familiar with search engines and with their interfaces. So, respecting common search-related layouts surely brings benefits to usability of the widget.
  • clarity of information: when searching something, the only important thing is to quickly find what looked for. Fancy graphics, a cluttered interface or cool animations could cause, especially on mobile devices' displays, confusion and poor readability.

First layout draft

Based on these requirements, the first layout draft will contain these main elements:

  • a header, containing the Bing logo
  • a big text input field, just below the header
  • a button to submit the typed query
  • all the remaining space will be used to show the search results

Wrt bing layout draft.png

In order to maximize the space available to search results, all the extra controls will be placed in different views, and standard softkey items will be used to access these views.

Managing the search types

The user has to be able to view the different types of searched media (news, images, and so on) with very quick interactions. Possible solutions are:

  • use radio buttons / checkboxes to specify which media type(s) to search: this solution is the most fine-grained, since allows to specify which media types to search for each query. However, having 5 checkboxes or radio buttons on the main interface, on small devices, is not great from a design and usability point of view.
  • use a separate view to filter the searched media types, storing the filter settings for all subsequent user searches (also, in subsequent usage sessions). This approach has the advantage of leaving the main search interface more polite, but requires an additional indication to let the user know which media types he's currently searching. The next section will show a solution to this problem.

Tabbed search

The widget allows the user to filter searched media types. In order to give him clear indication of the current filters, and also to allow him to easily switch from a media type to another, a possible solution is represented by a tabbed menu.

The tab menu will show only the current active media types, so allowing the user to know which media he's currently searching. In order to customize the media filters, and so to change the visible tabs, a separate settings screen is used.

Final layout

The final layout structure is visible in the following picture:
Wrt bing layout final.png

Step 3. Designing the widget

Now that layout has been defined, the actual widget graphics has to be designed.

The widget will try to use the same style and color scheme of the Bing website, in order to give a familiar look-and-feel to Bing users. The home design is visible in the following screenshot, in both portrait and landscape mode on a 240x320 display:

Wrt bing home small.png

Step 4. Performing searches

Bing offers a complete REST API that allows to easily perform searches from any mobile applications. In order to use the Bing API, it is necessary to request an API KEY, and this can be done from this page:

Full reference of the Bing API is available on Microsoft developer's website:

Request format

Search can be performed with simple HTTP requests, whose basic syntax is the following<format>.aspx?AppId=<api_key>&Query=<term>&Sources=<source_type>


  • format must be one of xml, soap or json
  • api_key is the Bing API KEY obtained from the Bing developer's website
  • term is the search term
  • source_type is the type of media(s) to search for

For a full list of allowed parameters and options, check the Bing API reference.

Response format

Bing offers 3 types of response formats, in order to suit all applications' needs. These are: XML, JSON and SOAP. Since JavaScript natively supports the JSON format, this will be the format used by the Bing widget.

Full details about the three formats are available on the following pages:

Step 5. Pagination

Since searches can return big sets of results, these have to be necessarily paginated. In this case, there are 2 basic options:

  • Pagination, described here: [Mobile Design Pattern: Paging]
  • Live Scrolling, described here: [Mobile Design Pattern: Live Scrolling]

Since the first option is more user-friendly, and optimized the memory usage with large sets of items, standard pagination will be used. Instead of giving a long list of available pages, that could be hardly usable on mobile displays, only "NEXT" and "PREVIOUS" buttons will be used, in order to allow easy navigation toward next and previous result pages.
Wrt bing videoresults.jpg

Step 6. Filtering media types

Users may want to be able to search for specific media types, and could be not interested in others. So, a view is created to allow users to select the preferred media types. Settings are automatically stored as soon as the user leaves the Settings screen, without the need to any extra user interaction, and are persisted through different widget's usage session, by using widget setPreferenceForKey() and preferenceForKey() methods.
Wrt bing settings.jpg

Step 7. Updating the widget

Update of the widget will be performed used two different techniques, as for the Nokia Developer widget (described here: Mobilising websites: building a WRT widget for the Nokia Developer website).

A dedicated view will be used for the widget update functionality:
Wrt bing about2.jpg

Step 8. The touch-enabled version

The touch enabled version will use the same layout and design of the standard version of the widget. However, some adjustments and refinements are necessary:

  • font size should be increased, in order to allow better readability
  • clickable elements must be resized in order to allow users to clearly touch and click them with thumbs. These include: tabs, input fields and buttons.
  • while on the non-touch version the user scrolls tabs by using the LEFT and RIGHT keys of the navigation pad, the touch version should allow users to select a tab by clicking on it, and to scroll the tabs, if they don't fit within the available space, with a simple scroll movement. The tabs scrollbar will also be hidden with the approach described here: Hiding default scrollbars in Web Runtime widgets

The touch-enabled version screenshots are visible below:
Wrt bing large.png

Step 9. Icon and deployment

The widget icon will reproduce the Bing logo, in order to make the widget easily recognizable:
Wrt bing icon.png
Now, the widget is ready to be deployed and tested!


The Bing widget, described in this article, is available for download here: Bing download page.

This page was last modified on 9 May 2012, at 03:42.
75 page views in the last 30 days.