Mary Panttaja

One of the blogs I read is Ryan Stewart’s Digital Backcountry where he covers rich internet applications. (He recently went to work for Adobe and covers Flex/Apollo extensively.)

There is a useful post on some new features coming out in Flex 3 that concern “deep linking” in Flash/Flex/Apollo applications. This has been an issue for web developers who come from the world where linking out of the application is possible and/or the user employing the “back” button is an inherent part of the application behavioral syntax. Flash/Flex applications, as “contained” application environments don’t inherently have a back button or a back button syntax and, up till now, the user couldn’t link out of the application.

Ryan writes correctly:

This also meant the back button wouldn’t work, so Flex/Flash felt very different from the browser experience and it was something that’s been criticized in parts of the community. There are some significant theoretical arguments about what the back button should actually do in the context of an application, and that has also been part of the problem.

In some ways I see this as an artifact resulting from trying to use one functional model to replace all other models whether or not it fit. The basic web technology (with its links and page sequencing (including back and forward)) was designed to present stand-alone objects (pages with text or whatever) in a sequential (or multi-linked-sequential) flow, originally without context or much control. Building functioning applications in this environment has always seemed like a bit of a kludgy hack to those of us who have designed contained and controlled application architectures. Of course, “web application” technology has evolved its capabilities to maintain application context and control behavior, but it has always suffered from a lack of true context control oftentimes because of behaviors like the back button.

So it is a “new” solution to a “new” problem: before the advent of the internet, application architecture enabled us exert control over content, context, and user behavior. Of course, they weren’t universally available over a ubiquitous universal network, so these days are better days in many ways. Adobe has published some really good talks and white papers on how application architecture took a large set of backwards steps, which are now getting addressed with several new offerings from many vendors.

Stewart reports that behavior that doesn’t reflect “browser” behavior is seen to be a deficient architecture. The reality is that every application needs to be able to control context and behavior as necessary within the requirements of the application, the user, and the proper control of the dataspace and context. Something as innocuous as the “back” button can’t be a sacred cow—elegance, usability, correctness, and common sense need to lead the day in building future applications.

The new application platforms that will allow applications to work on the internet and on the desktop (so far we’ve looked a bit at Adobe Apollo and Google Gears, though there are others) are exciting, but we have to get passed a need to hold them to a standard that only came to exist in the last decade and is a short term artifact of the current evolution of development capabilities.

And then there is the data management issue that Jim has discussed here, and which we will be exploring further. The models for managing the distributed dataspace of distributed applications (online and offline) are complicated and challenging.

So here we are. The second “developer day” in two weeks. Today we’re learning everything there is to know about the new Google developer tools and APIs. We did this two weeks ago at Salesforce.

It’s all fascinating and the technologies look like fun—though complex. One key element that I didn’t really appreciate until spending some time here is that these “development platforms” are significantly different from what we used to consider a development platform. Adobe Flex 2.0, for example, is a general development platform with which you can build any application for any purpose. This is traditionally what we thought of as a development platform.

These platforms (Google and Salesforce) are decidedly different. When you build with these platforms you are not only getting a platform with sophisticated tools. They are aimed at very particular types of applications designed around the core capabilities of the base platform—-search, maps, contact data.

The other element that is even more radical is that you are buying into an already existing audience. An application built on the Salesforce platform is intended only for Salesforce customers. Every user has to pay a monthly fee to Salesforce, a per person tax, if you will. Very few applications would be able to support that tax, but if they are already a Salesforce customer, the platform support is virtually free, Salesforce markets your application to them, it is trivial for them to subscribe, and you only need to charge a reasonable delta subscription. In fact, Salesforce will collect it for you.

What does Salesforce get? More sticky applications to attract and serve their customers without having to build or maintain them. So if you have some particularly valuable IP that serves this community you can dive in with a minimum of infrastructure and overhead. (One partner brought in $2-3 million in the first year with 6 company members—they have very widely useful IP—most Salesforce customers decide to buy it.)

Google has a whole suite of developer platforms that do maps, gadgets, mashups, etc. These are also targeted to Google users—a larger audience than almost anyone else has. Google provides the platform, the tools, the audience, the “marketing” (they list your app in the list of available components). The sofware is relatively easy to build—still takes wizards, but they can do things in record time.

Google, of course, gets more pages served. They hope that the gadget maker’s revenue model is to serve Google ads which bring Google revenue which they share with the maker. This seems to be the primary revenue model for these applications—ad serving, and perhaps some extended services or products served from the gadget maker’s base website.

And Jim points out that Google views the consumer as their primary customer. So you need to be interested in fulfilling a need in the consumer marketplace. That’s the target market. (It is interesting to me that it’s never been a market I really considered.) This has help me get a handle on what the “new 2.0″ world (”wisdom of the crowds”) is really about—meeting the needs and interests of the general public (consumer as a label is harsh, many of the services/features used are not just about consuming.)

All educational. Not sure where it leads yet.