The total number of widget platforms and deployment options intimidate many newcomers. Each platform offers a unique audience and features, but widget basics remain the same across Windows Vista, Nokia S60, Google, MySpace. and more. In this post I will outline the basic components of a widget including static assets, user preferences, processing remote data, and rendering your final widget.
Create a default view
Every widget has an at-rest state. Your widget might have a background image or color, static text, or other fixed pieces not dependent on external data updates. You will likely define areas of your widget that will later contain the result of dynamic data updates. This at-rest state, or default view, is the first step towards a complete widget and the first thing your users will see before retrieving their custom data.
Apple's Dashboard weather widget has a slim background with a simple layout showing the current temperature and weather condition. Today's temperature is displayed on the right, with a degree sign built-in for data context. The current weather condition (sunny, cloudy, raining, etc) will appear in the center.
Gather custom preferences
Every widget platform supports user customizations collected using a familiar user interface and stored on the parent platform along with other user data. In some cases you might be able to tap into preference data already stored on the platform such as a user's location, age, or preferred number of headlines per widget.
iGoogle's weather widget stores both a country and a city as your weather location. A weather widget might use different data APIs by country or region, or adjust its wording based on a user's location (i.e. Postal Code vs. ZIP Code).
Widget preference data is stored on the widget platform -- Windows Vista, iGoogle, etc. -- inside a user data store. Preferences can be structured as drop down lists, sliders, numbers, text, and much more depending on the data you would like to capture.
Retrieve dynamic data
Dynamic widgets receive regular data updates from a remote source and process the results. You will likely customize the data retrieved based on the user preferences defined above and create a targeted experience for each user. Data updates are often cached and processed by each widget platform to save development time and increase your widget's performance. The data formats below can be cached and processed by the parent widget platform to produce fast response times and allow same domain access to your data.
- Web feed
- RSS 2.0 or Atom Syndication Format 1.0. Your site might already produce these syndicated feeds popular for distributing the latest news headlines from your site to specialized feed readers. Widget platforms typically store a subset of all available feed elements (e.g. title, content, link, and author) which may or may not meet your needs.
- JSON
- JavaScript Object Notation, a lightweight data interchange format. JSON offers fast processing and manipulation of custom data. Your website may already produce JSON output to power asynchronous JavaScript requests that can be extended into your widgets. Most widget platforms will convert your JSON objects into their appropriate number, text, or list types for easy manipulation by your widget.
- XML
- XML is a popular data interchange format for custom-defined data sent between computers and their programs. XML snippets power Ajax (Asynchronous JavaScript and XML) functionality on many websites and can also provide your widgets with dynamic data updates.
- Plain text
- Plain text is the most lightweight data format and is swallowed whole by widget platforms. Plain text is a good data choice for small pieces of content (i.e. current temperature is 65) or complete HTML snippets you would like to insert directly into your widget. You could also process a list of comma-separated values or other forms of structured data as a plain text data source.
Creating dynamic data in an appropriate syndication format is often the first step widget publishers need to take before kicking off a broader widget program. You will need to expose your data in a syndicated format before distributing your widget.
Draw your widget
You have defined your blank widget, collected preferences and customizations from the user, and retrieved your widget's dynamic data. You now need to place your processed data into the locations you defined in your initial view.
Your widget code should construct the appropriate HTML or Flash markup describing your updated data. In the weather widget described above we need to update the temperature field with the current temperature and display a picture corresponding to current weather conditions if available. We have already assigned an identifier to our widget's temperature and weather condition areas, and update these elements with our latest data.
Pictured above is an example of a final widget view. The current weather in San Francisco is 58 degrees and cloudy.
The term "San Francisco" is a verified location based on the user's defined preferences (you were able to interpret the input and map it to a unique identifier compatible with your data provider). Our weather API returned two pieces of data: a condition of cloudy and temperature of 58. We displayed a pre-defined picture of the cloudy weather condition inside our widget's condition area and updated the temperature text to 58.
Summary
Every widget platform has a similar method of widget construction and processing. Available features, caching, proxies, and widget helpers vary by platform but the basic approach and mentality remains the same. You are creating a tiny application on the Web, mobile, or desktop that may respond to its environment and collect live updates from the Internet.
A provided a simplified view of a very broad development area. I'll dive a bit deeper into each platform type and the capabilities of major widget platforms in future blog posts. This post expands on my opening slide from my recent 8-minute "high order bit" presentation at the Web 2.0 Summit.
