Mobile Apps Incubation + Strategy

We live in the natural world, but we have filled it with myriad man-made things, creating new environments into which we introduce myriad processes governed, or not, by rules. It seldom occurs to us that all this stuff - everything man-made - is subject to design. We fail to recognise the design element of what we do, or what we use, because we take it for granted, or simply follow a template. In the latter case, what we are doing is copying the previous design, hence we skip the design step. This happens often in much of what we create and use - we fail to recognise the opportunity for design because it's already been done for us, or we just level it out by following convention.

Or, we just don't think about design at all. We create something to fulfill a purpose, which might be just to tick a task off on a long list of tasks in our lives. So, if we need to log patients into a hospital department, we list out all the steps - fill a form, log the form, notify someone etc, and then cobble them together without thinking consciously about design.

Design clearly matters. And what better example than the iPhone, especially with its brilliant 3.0 software upgrade. At last, we have some of the features that we felt were missing, including MMS. Now, this is something I thought that I wasn't going to miss, yet within days of getting my upgrade, I've used it several times already - and received MMS from friends with iPhones. Why? We didn't send each other MMS before (iPhone). It's because it's so damn easy and such a compelling user experience. Why? Because of the beautiful interface design.

And for heaven's sake, weren't some of us banging this message (forgive the pun) many years ago? How mobile phones could be so much better if someone actually took the time to design them properly. And this is my point, coming back to those who claim to understand design, which I think I do - although I'm not necessarily a good designer (except several patents in chip design I guess might count).

I've met countless companies who will tell me that they don't need help with design. "We've got designers," they say, or "We've got our own usability experts," blah, blah, blah - and then they release a crappy product that has some nice design features perhaps, but overall isn't up to the job. It's usually because they too are simply following templates, albeit based on "modern" approaches.

What's missing from the equation is something about quality and insights. And I can't believe how often this issue crops up in life. It's a bit like saying "Oh yeah - we know how to cook," as if merely mixing ingredients and putting them through various cooking processes is what makes a good cook. Clearly, when I do all that stuff, it isn't the same as Gordon Ramsey or Raymond Blanc doing it, is it?

"Oh, we have UI designers," they say, and, as Motorola did for years, give us the worse user experience possible, bordering on offensive.

Design, like innovation and all its components (of which design is one of them) needs to be taught in schools from the earliest age possible, yet I think (in the UK) we would struggle to figure out how to teach it, assuming the education departments think its useful, which I very much doubt.

When I recently met some kids and reminded them that alphabets are human inventions, they were surprised. And when I asked how they might better design alphabets, there were clearly confused by the proposition. "What the hell do you mean?" was the common response.

If we now live in the era of right-brain thinking, we better get real about teaching it.

To coincide with an essay that I wrote for Vodafone's Receiver ("Riding the timeline with widgets") about widgets from a user perspective, I thought to post a few thoughts about widgets from the tech perspective. 

Widgets are not new, but they are rapidly evolving to offer an attractive user experience and a convenient means for developers to reach users in ways not entirely available via the native or web route.

There is no universal definition of a widget, but most widget technology sponsors tend to refer to them as "mini standalone web applications," or words to that effect. By 'mini,' proponents often mean single function. Even this is problematic. After all, most web apps and native apps really only perform one function, it just depends on the scope of your definition (e.g. "Word-processing" versus "Spell checker")

From a user perspective - not forgetting that the mobile masses don't really know a widget from a wingbat - this "web heritage" tends to set the expectation that widgets, like most web sites, are probably going to be free. Indeed, in all of the various widget vending sites out there, they are free.

Technically, there is no reason why a widget has to be confined to a "mini web app" but part of the problem here is that by calling something a 'widget,' as opposed to an 'application,' we are left with trying to explain, or categorize, what they are. And so, rather unimaginatively, we end up with the stock favourite demos of clocks and weather forecasts. Users will eventually catch-on to the wider potential of widgets, simply by visiting a widget store and seeing the hundreds and eventually thousands of widgets on offer. It will be interesting to see if Apple introduces widgets for the iPhone and supports their distribution via the app store. Technically, there is no reason why a widget can't be signed and DRM-protected. This is just packaging.

The technology underlying widgets is not universal either. So, we have the proprietary widget scripting languages, as offered by Nokia Widsets and Yahoo Blueprint. We have web standards approaches, like Nokia WRT Widgets and Access Netfront Widgets. And we have the Java-bound approach of the new Sun Java ODP.

The overwhelming advantage of the web standards approach is that all those millions of web developers can produce apps for mobiles that load faster than websites because the widget is stored locally. Of course, it has to go fetch data and be quite carefully designed to run efficiently. In fact, there are lots of 'tricks' to designing efficient widgets, but nothing that seasoned mobile web developers wouldn't know. Moreover, the great advantage of the web standards approach, apart from familiarity, is the possibility of sticking with current web-design tools. Apart from the issue of emulation on a mobile device, there isn't really the need for an SDK, as such - just stick to the tools you already know and love. There's some widget packaging to take care of, but this is mostly just zipping of files anyway.

Overall, the web standards approach supports a richer UI with fine control over the look and feel supported by CSS and various Javascript libraries. In theory, there's no limit to the use of existing libraries, such as Prototype and so on, notwithstanding all kinds of very real performance constraints. This is where some skill is required in efficient coding and design. Some vendors, such as Opera, provide 'widget friendly' libraries, such as an animation API.

There are two significant advances that increase the usefulness of widgets. Firstly, on some platforms, widgets can run standalone without requiring the user to first invoke a container application. These standalone solutions mostly involve the widget invoking the web browser 'inside' the widget as a means to display web-standards content. This is the web runtime (WRT) approach, an idea introduced by Microsoft long ago. The key here is that on many new mobile platforms, such as S60 5th Edition, Android and others, the web runtime approach is available without needing to download a 'widgets' upgrade to support running widgets. In other words, many new phones are widget-ready.

What is still missing from the current WRT approach is the ability to support persistence in terms of allowing widgets to consume data whilst 'running' in the background. This is the obvious next step and we keenly await more details of the Palm WebOS to see how they solve this problem. I believe that it is essential to the longer term success of widgets. I recently discussed persistence methods in a previous posting.

With persistent widgets - always active - we can support new modes of ambient communications, such as Twitter or many others that I'm sure will emerge. I recently wrote an essay about 'riding the timeline of moments' via widgets, to be published soon by Vodafone, who are promoting widgets heavily via their Betavine Widget Zone.

The second important evolution is the ability for 2nd generation widgets to access platform services via device APIs that are exposed as Javascript APIs. These give widgets access to underlying phone functions and data, such as the contact book, messaging features, location and so on. 

The use cases for widgets are propelled by the possibilities of mixing web-bound services with local phone services. Moreover, unlike standard web-browser models, the AJAX capabilities of widgets permit interacting with websites outside of the origin server(s) for the widget (which is a misnomer anyway because the widget exists as a local XHTML page, not served by an origin server). This enables mash-ups at the client (as opposed to server-side) although operators seem to want to restrict this (e.g. Vodafone Widgets are confined to one host that is pre-defined in the config file) for security reasons.

With device APIs and the increasingly rich capabilities of widget containers (including embedded Flash Lite), the main limitation on use cases is the imagination and having to code within the performance confines of the widget container (e.g. keeping XHTML and libraries local as much as possible, judicious use of CSS techniques and so on). As I hinted above, I foresee that the best and most compelling user experiences will arise from ambient applications that provide the user with a constant drip-feed of data and almost visceral connection with their digital web-bound lives. This is what widgets will be good for. But, there are other opportunities....

There are also potentially new ways for operators to expose their services "over the top" of the underlying handset UI capabilities, which are difficult to update. For example, one can imagine better ways of packaging videophony or self-help. That said, there is no reason stopping operators doing this today and it is surprising how O2 has not offered their own set of iPhone apps to improve the iPhone user's O2 experience, as opposed to Apple experience. The only O2 app that I saw was something to do with Christmas. 

This is not a new idea either. Indeed, when I was Chief Architect at Motorola, I tried to get Opera interested in this idea within their browser platform, mostly to expose IMS capabilities to local web apps. These weren't called widgets back then, but Opera had launched something called Opera Platform (discontinued) which essentially did the same thing ahead of the recent advances in browser and underlying platform technologies. Despite being suspended, I still wrote about Opera Platform in my book.

Clearly, WebOS from Palm has taken a similar technological approach, but baked right into the OS, which Opera might have considered (and perhaps still could).

Of course, I'm not sure I would be that keen anymore to support SIP/SIMPLE and its cohorts within the web/widget runtime, but the idea is still interesting nonetheless and could be extended to other use cases. I only suggested it back then (and see it again as a possibility in my slides about real-time mobile web) because it seemed that we would have to wait forever for "IMS phones" and then be stuck with devising an easily accessible and universal programming model to speed up the proliferation of IMS apps. I thought that just as the browser was the universal client for HTTP/Web, why not make it the universal client for SIP/IMS and all the network services behind it. Just another pipe dream! Smart pipe? No. Smart client? Yes.

For the next few weeks, I intend to make only one or two longer posts on my blog, rather than the almost daily updates that I've been posting recently (except last week). This is because I'm finding that there is a lot more attention being given to Twitter within the mobile community, not to blogs. That said, Twitter has a lot of issues in terms of attention, fettered as it is by a poor signal-to-noise ratio and too many meta posts. But, that's where the action is, so let's ride with it, for now.

Nowhere is the tradition-versus-modern debate more provocative than within the realms of education and learning. At some point in history it was decided that we should all go to school to get an education. Mass schooling in the US was set up by industrialists who needed useful factory workers. Meanwhile, the very idea of "worker" and "citizen" has undergone and is still undergoing transformation in this apparently pivotal age that we live in.

Not surprisingly, the current education methods and choices are quite possibly at odds with current, never mind future, societal needs. Let's face it, we all struggle to predict what things will be like five years from now, so how do we intend to educate ourselves for so uncertain a future? This has caused various thinkers in education to coin the unoriginal phrase Classroom 2.0 (see one example here) as yet another coverall phrase to capture key paradigm shifts that, unlike the web 2.0 memes, are still ideas rather than actual trends in the way things are done. 

At the recent OpenMIC barcamp, I pitched in one of the sessions about m-learning, trying to figure out how the mobile might allow new modes of education that extend existing school structures. This is perhaps more Mobile 2.0 than Classroom 2.0 - the idea that our mobiles can move beyond their origins to become something else. Just like with the pencil, thou shalt make calls and send texts was not a commandment that came with the mobile, just a big design and commercial incentive. Interestingly, I know of various iPhone users who simply don't make mobile calls - they email, surf and use apps. They might average about one call per day, if that. That's hardly a mobile phone, is it.

We are missing a huge opportunity with mobile technology. It is m-Learning - the use of mobiles to learn new and interesting things. Not only that, but the use of mobiles to augment our thinking processes. This is a future of mobile. Some say that this is the future of mobile. Call it m-Thinking perhaps.

The current obession with mobile is still with the mundane. It is with communication. No doubt, the future of mobile has a lot to do with communication - one of the five Cs that I wrote about in a thought piece for the future of mobile, as printed in Stefan Bertschi's interesting anthology - Thumb Culture.

But communication is the mere transfer of ideas, thoughts and stuff. It says nothing about what we are trying to achieve. And, it is in thinking about the objectives of communication that we shall uncover the next set of advances, innovations and services in mobile.

At the same time, we are only beginning as a species to understand ourselves. In particular, with the help of various techniques, we are beginning to understand better how we think, although the brain is still very much a mystery and one of the great unconquered frontiers of science. Recent experiments show that when thinking to perform an action (throw a switch), our subconcious appears to prompt the concious mind into doing it. Go figure that one!

What we do know is that by various measures, that we won't discuss here, many of us are poor thinkers much of the time (although there is a well known principle - see Lake Wobegon anecdote - that most of us assume we are good, or above average, thinkers). We might apply faulty logic and reasoning or, more likely, be overly influenced by underlying emotional currents. Goleman was on to something with Emotional Intelligence as a more revealing, or perhaps useful, measure of intelligence, debates about defining intelligence aside (and there are many).

It is clear that it ought to be possible to augment our thinking processes with the use of computer power. Put crudely, we can think of computers as an extension of our brain's computing power, but one that can be entirely controlled, structured and driven in a direction that we can control. That is, by running an explicit program, unencumbered by faulty logic and emotional influence. At least that's the theory, although we should always remember that old computer aphorism - "garbage in, garbage out."

Clearly, augmented thinking is still very much in its infancy. After all, how many of our current uses of computer would you categorise as aids to thinking. I don't mean the event of thinking. Of course, reading a blog - perhaps this one - will fuel your thinking. What I mean is the process of thinking. The use of technology to assist in how we think about a blog post, a project, an opportunity, a risk, even a piece of art. Can you name any thinking tools at all?

Take email, for example. It is still an incredibly crude tool. Having used all our big brains to invent it, all we really have is a faster version of letter writing. Yes, habits have changed and formed around email, but let's not pretend that it's anything that stupendous in terms of augmenting human communication. How many of us struggle to find an appropriate subject for the message? (Why do we need a subject?)

Indeed, how many man-years are wasted in corporations by inappropriate messages, inappropriate emails and other inefficiencies of email. We can send letters faster, but we have multiplied the number we receive by an order of magnitude. If there's one thing you get from this blog post, it should be to go read Merlin Mann's Inbox Zero collection of writings. If I can point you to something that might save you at least the time reading this blog post (times one hundred), then I'll feel less guilty than I do already.

Where is the intelligent email program? Where are the education programs to teach us how to use these tools better - to understand their essential characteristics, pros, cons, limitations and so on? Never mind that. We are told by endless numbers of university teachers that many of our school leavers are unable to write. Add that to the email magnifier effect!

Now imagine taking that mass of communications confusion and squeezing it into the mobile? No wonder that mobile email has had such a slow adoption rate. Let's hope that the chasm is never crossed, that we invent a better means of communication for mobiles before it's too late. And by better, I don't mean more popular and pithy, like text . Of course it's far more successful than email in terms of number of users globally. But trying reading those Novels written by texting on Mobiage. (Hint: don't try! DOUBLE HINT: especially don't try writing one!)

The march of the Internet towards the so-called Semantic Web, or the more marketeer friendly Web 3.0, is clearly a move in the right direction, although to be clear, the semantics we are talking about with Web 3.0 are all about ways of enabling computers to label context and, by implication, derive meaning. We are not talking about a Web connected with the mind, although that is possibly the next step. The Europeans talk of Web 3.0 as the internet of things. Why shouldn't our brain be one of them?

If we can use computers to augment our thinking in some favourable direction, then what better opportunity than to use the mobile. It's a tiny computer that we always have on our person. It could easily become a surrogate brain. Most likely, the 'real' surrogate brain will be in the Cloud somewhere and the mobile will provide the interface, or be the brain's proxy - what we might called an agent in old-school artificial intelligence lingo.

Putting mobile brains aside for a moment, I'd like to turn our attention to a related mystery and controversy, which is education. The thing about education is that everyone has an opinion, everyone has a theory. This is good for education and that is good for education. Fads galore!

Whatever the flavour of the month in education, there is a growing consensus that our current ideas of education are not equipped to deal with various global trends, including the dramatic shift of knowledge working to an artisan activity easily outsourced to low cost brains or scalable IT systems. Many of our educational systems are basically funnels into the world of knowledge-based industry. What's the use of a funnel when the thing we're funneling into is no longer relevant.

As I mentioned earlier, this has led various educationalists, both professional and amateur, to posit the idea of Classroom 2.0. It is another 2.0 smorgasbord of ideas, but not surprisingly characterised by common 2.0 attributes: accessible technology, open systems, social-power, asynchronicity, relevancy. A kind of Darwinian education system.

It is scary stuff of course. Education, no matter its flavour, has been underpinned since the Industrial age by the idea of measurement and grading. In a world where the education system becomes organic and more real-time in terms of achieving contextually relevant results, the idea of abstract measurement and grading begins to break down. No sooner have we defined the metrics of measurement than the thing we're trying measure becomes irrelevant.

Somewhere in all this mix of ideas about thinking and education, there is undoubtedly a role for technology and, possibly more significantly, mobile technology. Classroom 2.0 and Mobile 2.0 seem on paths destined to intersect at some point in the very near future. There are many challenges ahead of us, but also many opportunities. Ironically, it is the next generation - the ones that we struggle to educate - that are going to have to figure this all out. 

Good luck children!

There was a good mix of topics and levels of interest. Continuing with a recent theme on this blog, I ran a session about Ambient Communications, which is another way of saying "always on" applications. Where possible, we also tried to incorporate the theme of widgets because of the attention they received in the earlier session by Dan, and because I have recently conducted an analysis of the major competing mobile widget systems (from a developer perspective). 

I captured some of the ideas in order to post them here. So here goes (in loosely structured note-form):

We discussed how frustrating it can be to share photos among friends and family in a "it just works" fashion that is "mum proof" (i.e. mostly disconnected from Internet and probably still a regular TV viewer).

1. Ambient photo-streaming widget on the homescreen of "mum's" mobile

2. Family and friends join into a photo timeline (stream) via the widget on their mobiles

3. Photos taken on camera phones are automatically store in the cloud (e.g. flickr)

4. Widget can be displayed as "TV widget" on the TV display, including ambient (picture-in-picture) mode - also known as "stackable" media

5. Remote control for TV widget (expand, collapse, advance etc.) all via the mobile widget

6. Possible use of Femtocells to accelerate the photo uploading process when in the home cell

7. Stream also displayed on widget in kitchen - fridge magnet, O2 Joggler or Chumby

8. Geo-tagging of pictures - mash-up with maps and Google street-view for animated "timeline" slide show

9. "Follow Me" geo-tagging for live update of friend and family locations - merged somehow into the timeline

1. Twitter for ideas - constant ambient stream of ideas, thoughts, "notes to self" had in the past

2. Notes to self and Getting Things Done (someday, somehow)

3. Notes via mobile - SMS, widget, voice

4. Voice memos converted to text in the cloud - "Google Voice API?"

5. Ability to merge thought streams with friends, family, followers

6. Voice notes can also be distributed to groups as means of "outloud thinking" and instant crowd-sourcing

7. Voice input is instant - no dialling

8. Could also display stream on TV and fridge magnet widgets - also stream to in-car widgets

2. Enable many-to-many voice channels ("conference calls") to form around trending topics and tweets

3. INSTANT voice connectivity - no dialing and no answering (optional)

4. Voice streams are public - "public by default"

5. Multiple streams of voice are audible to listener as ambient "murmur"

6. Keywords/tag cloud sensor "highlights" key words in the murmur

7. Listeners can tune/de-tune from the murmur by use of keywords

8. Instant "barge-in" to any stream

9. Re-packaged push-to-talk on handsets

Thanks to fellow collaborators who came up with the ideas while I drank (crap) coffee - @andresteder @mjbdreamer @spugamola 

Thanks to all those who attended openMIC and to Chris for organizing - great job!

Been there, done that - GOT THE T-SHIRT......

I'm currently planning a book about mobile web technologies and have been doing some historical research. I really enjoyed watching this YUI video of a presentation by Lars Knoll and George Staikos about the origins of KHTML, which became Webkit. I'm sure that most of my readers will know that Webkit is the browser core engine that sits beneath Safari on the iPhone and beneath the S60 browser, among many other mobile browsers.

There are many interesting technical aspects to the KHTML/Webkit story, but what caught my attention in the presentation was Lars justification for coding the KHTML engine from scratch in the first place instead of using Mozilla. He said that it would be more fun to do it themselves - a more interesting project.

This is the fun factor of developing software. There is another version called the fame factor, which I heard discussed by the Oracle rep during the OneAPI seminar at MWC 09.

Sometimes the fun factor is in opposition to the commercial interests, or at least the perceived commercial interests of an organization. I recently worked for someone who warned staff not to engage in 'science projects,' which was another way of saying fun projects that don't have commercial value.

Of course, I totally agree that in industry we are here to make a profit, but the path to profit isn't always obvious and needn't preclude having fun. However, there are still a good number of commercial managers who don't yet seem to understand how innovation, particularly in technology and software, sometimes (often?) works. Essentially, the fun factor has to be embraced as a genuine and valid part of the commercial process. Google allows employees one day a week to work on their own ideas, which seems a smart move. Do you want thousands of people coming up with the ideas, or just a few high priests in marketing?

In my experience, the source of the problem is usually related to control. Managers want to do what they do best, which is to manage. This includes controlling the business processes under their care. Things can only be controlled, at least in one way of thinking, by definition and measurement. Doing something 'for the hell of it,' or because it's fun, can't be defined or measured, so it is often resisted.

In all the chatter recently about app stores, it is always assumed that the developers want to make money. This certainly attracts developers to the iPhone app store - including the gold rush effect. However, the fun factor is still very much present. Many of the apps are free and many brands and sites have produced an iPhone app when they don't really need one - just for 'the fun of it' (translated into other feelings, like 'coolness'). Interestingly, some of the underlying technology - e.g. Webkit - we now know was developed just for the fun of it.

What's your fun strategy? (Sounds like a book title.)

Many of us are getting accustomed to riding the timeline of Twitter, a form of ambient communication. Other ambient experiences will soon emerge on the mobile, courtesy of widgets. Vodafone (Receiver) are due to publish my essay about ‘seizing the moment’ with widgets, which is an examination of the user experience and the potential impact upon our daily mobile habits, and, by implication, our digital lives. I thought that I would briefly mention some of the technical aspects related to the piece, focussing on the key technical challenges, as I see them.

In order to share Twitter IDs between members, we created a Twitter account @i_am_a_mobilist which members can follow and thereby allow others to follow them. It's a way of grouping together Twitter IDs for members of the mobilists group, but any other mobilist is free to follow of course - no one will use the account to spam followers.

See you on Twitter (@pgolding)

Continuing with the theme of ambient communications and ambient products, I'd like to compare two ambient products on the market - the O2 Joggler and the Chumby.

The fridge wasn't really important, but the concept of interacting with the "home hub" was. The ability to send messages in and out of the home from various mobile family members seemed useful and an obvious thing to do. 

Roll on a few years - about 10 - and digital picture frames have become prevalent. I suggested in an old blog entry back in 2006 that it would be useful to pop a calendar into the frame, especially one used to keep track of family events. My family, for example, have a shared calendar on Google Calendar, but there are about 1001 calendar services out there, perhaps more popular than GC.

In my household, we have a plethora of computers that alway seem switched on, so it's easy to access shared calendars, except ... we don't. I even mounted a laptop right in the heart of the kitchen. It still didn't work. 

As those of us well versed in mobile product design know, there's often a HUGE gulf between the ability to run an application and actually running the application. That's what early detractors of the Blackberry didn't understand. Truly always-on email - ie push - is a very different experience to on-demand email - ie pull. That is, when the app is always running, it gets used by virtue of the "bumped-into effect," which I have blogged about many times. 

When the app needs to be invoked, it often doesn't get used. Obvious, yes, but subtly important.

There is a common objection here, which is to do with the notion of need. Many will say that if you don't have a "i need to access my email every second" problem, then you don't need always-on email. That's not the point. Once exposed to an always-on experience, it can easily become imbibed into the user's daily habits - new habits are formed. Twitter users will have experience this. Migrating from the web presentation to a Twitter client creates a much greater attachment to Twitter. Soon, the Twitter habit is formed and one can't imagine daily digital life without it.

Now the question is whether or not the same experience could occur with an ambient device in the kitchen. Is there a device, that once connected, once fired up, once used by its family owners, will become incorporated into the daily habits of digital home living?

I believe that there is, although the exact formula has yet to be uncovered. Amstrad tried it not so long ago with their Internet phone. I even tried one of those in an attempt to get my wife more habitually plumbed into email - she had a tendency not to check email for long periods of time, which caused various problems (at least in my view). It didn't solve the problem for a number of reasons. Upping the budget a bit, I eventually got her a Blackberry. Problem solved. (And now she has an iPhone.)

BUT! Family calendaring still remains an issue.

Enter the O2 Joggler and the Chumby. They are both ambient devices intended to be switch on and accessible all of the time, which, we can imagine, means somewhere in the kitchen if it is to be a family-centric experience. This is certainly O2's positioning for the product, which is advertised under the rubric of "O2 Family."

The devices are similar in concept. Notionally, one could describe them as digital picture frames with the addition of a calendar. HOWEVER, that is where the similarity ends. And, I believe, there is an important lesson here in what we have been talking and blogging about for some time in the mobile 2.0 world, which is the difference between a product and a platform.

As far as can be gleaned from the O2 website, the Joggler's main feature is its shared calendar function, which has various bells and whistles, such as text message reminders and text-message submission of new entries. There are features to import photos, get traffic info, weather etc, as described on the media release for the device.

On the other hand, the Chumby offers something that the Joggler doesn't, which is support for a developer community via its widgets technology (based on Flash Lite). There are already some 1000 widgets in the catalogue, including 17 (when I checked) calendar widgets and 32 photo widgets (including Flickr and all the popular gallery sites). I can certainly use it to access our shared family Google calendar, which already has text or email alerts built in.

In other words, the Chumby guys have created a content platform, not just a device. In the words of Stephen Tomlin, their CEO: "Chumby brings new capabilities to connected devices by streaming always-on, always-fresh personalized Internet content to consumers."

They have created a developer commnuity by leveraging a well-known development environment - Flash Lite - and an emergent delivery mechanism - i.e. widgets. You can even create virtual Chumbys just for fun (because Flash widgets will play in the browser). Here's mine, showing real-time search of "mobile" in the Twitter timeline, upcoming events from Yahoo Upcoming, and random pictures from Flickr public RSS, but these could obviously be from my pics.