Last week was the 8^th annual BREWFEST in San Diego, sponsored by Qualcomm. BREW stands for Binary Runtime Environment for Wireless, and started life as a programming tool for the engineers working on Qualcomm's wireless chipsets. It was then turned into an operating environment and built into the chips Qualcomm sells to the handset and device vendors. However, unlike other programming environments, Qualcomm built a complete ecosystem for BREW. This ecosystem starts with the developers tools, includes certification by Qualcomm of BREW applications and then, depending on a network operator's preference, the applications are hosted on a BREW server at the network operator's location or hosted on Qualcomm's servers for distribution to other network operators.

Historically, BREW has been about CDMA phones and the largest BREW customer has been Verizon Wireless. However, over the course of the last few years, it has gained some traction on other networks including one in Italy, the UK and elsewhere. The user interface component of BREW has been embedded in a number of different types of phones in addition to CDMA devices and Qualcomm is looking to make BREW even more widely deployed in both the CDMA and GSM/UMTS worlds.

In that light, there were a number of announcements regarding BREW at this year's conference, which was attended by 2,500 developers from around the world. One was that BREW will start supporting widgets. What is a widget? In simple terms, it is a graphical representation that can be selected by a customer that will launch an application, go to the web and open a window to a specific page on a specific site, or retrieve information such as the latest weather report. Simple widgets are about not having to type a URL and more advanced widgets are about making the user experience easier, faster and better.

If you Google widgets, you will quickly find that BREW is not the first company to incorporate the concept-Apple has a full library of widgets for the iPhone, Yahoo has widgets by the thousands for free, and there are dozens of sites that offer widgets for all manner of things. However, for the most part, today's widgets appear to serve a single function or purpose. I can have a widget that will, for example, take me to my AA.com page and display my flights or the status of the flight I am taking tomorrow, another widget will get me to the weather report for my destination city and yet another widget can get me to turn-by-turn directions from the airport to my hotel if I enter the address.

In 1999, my business partner, Barney Dewey, wrote a piece for our newsletter about what he called active content. Since then, we have refined our vision and while widgets are a great step forward, they still need to evolve a few more times. For example, I don't want to have to launch a widget to check on my flight. I want to set up a widget that will monitor my flight in the background-did I get the upgrade I requested, what is my seat assignment, what gate is the flight leaving from, is it on time? That would be a very useful widget for me. I would set up the widget when I booked my trip and wouldn't have to invoke it to check the status of my flight because it would automatically provide updates when anything changed.

A couple other widgets that would be nice to have would be one that would give me a weather report for my destination city and another to give me turn-by-turn directions from the airport to the hotel. Another trip-specific widget would go to my corporate information and download the latest information for the company I will be seeing in the morning, checking the accounts receivables and the inventory and orders for that company so I am completely up to date before I arrive there, using my direction widget for turn-by-turn directions.

But now I have a screen full of widgets that will perform specific and perhaps one-time actions for me, and at some point I have to "tell" the widgets what I want them to do and build as many as I may need for this trip while keeping my other widgets active and available.

All of this is a good start, but I want more! I want a widget that will multitask. I want the widget that checks on my flight times and updates me automatically with changes to the flight to also deliver the weather information for my destination city to me, so that one widget will provide two functions. Another widget would be in charge of obtaining turn-by-turn directions and perhaps checking the traffic for the route and advising me if I need to leave a little earlier. Another widget would enable me obtain all the information I need for my next appointment and so on.

The problem with today's widgets as I see them, is that they are another name for a shortcut for me to invoke and PULL information I want and need to my device. Having used a BlackBerry since the very first models were available, I have learned that I would rather have information pushed to me when there is a change and not have to initiate any action. I would not mind being able to build a widget on the device or, preferably, the desktop, which would be a lot easier, and then ship it off to my phone where it would sit and watch what was going on with my trip, my meetings or a combination of things.

It is not surprising that widgets are pull devices, after all, the Internet is basically a pull system-you go get what you want when you want it, usually starting with a search engine. As you learn about valuable sites, you put them into your favorites and invoke them when you want to return to those sites. I want widgets that I don't have to invoke to get the information I want on a real-time basis. There are some sites which you can set-up to push you information but they are few and far between.

Paul Jacobs, CEO of Qualcomm and a man with a lot of vision, stood on the BREW stage the opening day and asked a question I have been asking for a long time: "Do we want the Internet delivered to our wireless devices wirelessly or do we want a smarter, easier to use wireless Internet?" I was pleased to hear him ask the question and then go on to talk about what BREW and the BREW community is doing to help develop a smarter wireless Internet, including widgets and opening up the BREW platform so content will also be available off-portal in the future.

Widgets are a good first step, but they need to become smarter and more automatic, and we need to be able to assemble them ourselves without having to wait for a programmer to come up with the one we want to the information we want. And they need to be on-the-fly configurable by mere mortals to provide the functions we want when we want them.

What Barney wrote about in 1999 has still not come to our wireless world. Widgets are a good start, but let's make them multitasking at our command. The networks are capable and the information for much of what we do is definable. The rest is not easy but it can be done. Network operators want to increase data usage across their subscriber base and widgets are a good start for achieving their goal. Now let's build on the concept and add PUSH capabilities as well.

Andrew M. Seybold.