Get friendly with the data source

Before you begin, it's also wise to review the data source with your development team. The goal is simply to understand what type of data you will be styling and how it will be structured. Try to determine the following:

• What default elements (text, images, etc.) are visible when the widget is 'empty'?

• What dynamic data will the widget download, and in what views will it be displayed?

• Does the widget have several states? For example, if your widget is tied to a subscription service, do paid subscribers see different data than free users?

• What will be the structure of the generated HTML? What classes and IDs will be assigned?

Don't forget you're dealing with a mobile context. Many APIs are huge, and it can be tempting to display as much data as the view can handle. But is all this information useful (let alone essential) for users on the go? Can anything be removed to simplify the experience and emphasise the elements of the design that can lead to a mobile-actionable event (for example, Click a telephone number to prompt a call)?

The COLOURlovers API provides lots of data, including member ratings, groups, blog posts, and badges, but we have decided to limit the data we deliver to colour swatches, patterns, palettes, and their respective title and author. Finally, to encourage use of the widget on the go, we will provide a prompt that enables users to share their chosen colour references via email.

Figure: Data structure

See Getting Started with Mobile Design on Forum Nokia for more information about designing for the mobile context.