Agile Ajax

.Mac improvements: That's it?

Amidst all the hardware news at Apple's Mac-focused media event last week, it was easy to overlook the announcement of some tweaks to the widely reviled .Mac web-services suite. Easy to overlook not because the announcement got no play, but because the improvements were so underwhelming. Even with 10 times the online storage space (10 gigs, up from 1 gig) and a slick new Ajax-backed photo service, the upgraded .Mac suite still costs $100 a year. Meanwhile, most of its individual features continue to lag behind the functionality and performance of free services from a host of other providers.

Commentators here, there and everywhere have predicted - and in many cases advocated - the death of .Mac for a long time now. I wonder if Mac newbies' continuing propensity to pony up for the service has something to do with Google's inability to parse the period in ".Mac" and return some relevant search results for such phrases as ".Mac user reviews." [Here's a hint: search for "dot-mac sucks" instead.] There's no shortage of users who find the service disappointing, and the latest tweaks aren't likely to change that.

Based on the demo I've seen of the new .Mac Web Gallery, I can see why an iPhoto junkie might be persuaded to dump Flickr and give it a whirl. But why settle for syncing Safari bookmarks when you can use a social bookmarking service or a bookmark-syncing plug-in for your browser of choice? Why settle for viewing your Address Book entries from a primitive web interface when a service like Plaxo lets you edit them online, too? Why merely view iCal entries online when you can actually edit your Google or Yahoo calendar from any browser? Why use .Mac's painfully slow, frequently buggy online backup service when you can switch to Amazon's S3? Why use the old-school .Mac webmail client when all the major free webmail vendors offer snappy Ajax interfaces? Why host your personal site with iWeb when so many other free or low-cost solutions offer more flexibility and power?

No webapp is perfect, and no single provider offers the breadth of .Mac in a single suite. But cheap or free a la carte services from best-of-breed providers work better for all but the most dedicated (or lazy) Mac users.

Leander Kahney over at Wired stayed up late the night before Apple's presentation to say a prayer that Jobs & Co. would radically overhaul the service. But the best that can be said about the "new" .Mac is that its developers finally seem to be dimly aware that there's this whole Web 2.0 thing happening out there. The future promises some upcoming, though as-yet-undefined, .Mac webmail improvements that could help modernize the service. But the suite's most compelling features are the ones that link one Mac to another, such as Leopard's forthcoming Back to My Mac application. True Apple fanboys may get a lot from such utilities, but they're useless for people in the real world - the ones who log onto Windows boxes at work every day and still want access to the data from their personal MacBook Pros.

My real problem with .Mac isn't that its webapps are sub-par. It's that Apple's overall strategy in the PC marketplace is still so focused on a single, unified desktop experience geared toward the mythical "average user." (Thanks, Walt Mossberg, for making that the most overused phrase in technology writing.) It's such a Microsoftian strategy: continually cramming all the the things a typical customer might need into a suite of pretty-good apps and services whose only real advantage is their supposed integration.

Given that Safari is being positioned as the platform for iPhone software development, it seems likely that core pieces of the OS X desktop experience will eventually get better browser-based simulations. But as a Mac user, I want the data on my machine to play well with third-party webapps, too, in my user-agent of choice. The whole advantage of the web desktop model is that all of my data lives in the cloud and, thanks to public APIs, I can interact with it through a broad range of providers. I can use the out-of-the-box UI or create my own. I can aggregate Remember the Milk into my gCal with a widget instead of waiting for Google to come up with a first-rate to-do list manager. I'm not locked into a single piece of hardware, operating system or software vendor. But locking me into a monolithic suite seems to be the whole point of Apple's desktop strategy, .Mac included.

Right now, all .Mac does is sync data between Macs and allow me to access a subset of that data, in read-only mode, through the browser. That's simply not good enough, and it hasn't been for a couple of years now. Apple should be integrating each of its elegant, easy-to-use but fairly vanilla desktop apps into a web-services architecture. That way, I can use my Mac as an oasis of no-fuss desktop computing at home, but still have the power and the flexibility to do what I need to do from any other machine or physical location.

I get why Apple's user interfaces are geared toward somebody with my grandmother's level of technical proficiency. But why not set up .Mac so that third parties can create more powerful and varied UIs on top of the underlying services? That might actually be worth $100 a year. In the meantime, .Mac and the Macintosh platform are positioned as one-size-fits-all, all-or-nothing propositions. And there's nothing new about that, media event or no.

Web 2.0 and the Missing Business Model

Everyone has a Web 2.0 rant and I guess it's time for mine. Over at BloggingStocks, Tom Taulli in an article entitled eBay: The Web2.0 Killing Fields observes that ebay is seeing the liquidation of lots of Web 2.0 startups. He makes a valid point that Web 2.0, much like many of the dotcom startups, don't have a business reason for being:

But there's a problem: while these sites are definitely cool, the business model is often hazy. After all, when you give something away, you need either a premium product to upsell or a lot of users to monetize things with advertising.

How does this square with Tim O'Reilly's principles for Web 2.0? So far the only principles adopted by the Web 2.0 social bookmarking sites is "wisdom of crowds" (aka, let the users create the content for you) and "rich interaction" (aka, Ajax) to make their apps/site as usable and cool as possible, and counting on network effect to drive value for their users. Meanwhile all of the Web 2.0 "web is the platform" startups are either being acquired or driven out of business by Google. This far into the Web 2.0 hype cycle, from a business model perspective, the offerings out there are still very much of a yawn.

The social bookmarking sites, especially, are an inch deep when it comes to that user created content. Flickr and the user created Korean news site, Oh My News (english language site) are the exceptions here, with original content being contributed by its users.

We've all read the various models being bandied about, from micropayents, to advertising to selling offline copies of the agreggate. This may be the best one yet, through:

OK, so you buy a domain and web service hosting for one year ($200?). Then you quickly throw a webpage together that renders some XML as HTML. Put it on eBay and pocket $4,000? Repeat weekly and you are making $200,000 per year.

Fortunately for all of us Ajax developers, Web 2.0 isn't the only thing driving Ajax adoption.

Technorati : ajax, business model, web2.0

Business Reason #1 Revisited - ASP's with Existing Apps

OK, so it's not called Application Service Provider -- ASP -- anymore. Rather, it's SaaS, or Software as a Service. I suppose that's just as well, since ASP was often confused with the Microsoft's Active Server Pages.

Back in May, in my article 10 Business Reasons to Use AJAX, my number one reason to use Ajax had to do with SaaS's (or SaaS 2.0, as it's called now):

ASP's with existing applications. This ship has already sailed. The ASP's include GMail and Yahoo Mail, but extend to places like Salesforce.com, openair.com, and so on. The lower the switching costs, as in the case of email services, the more vulnerable you are to being overtaken by your slicker, more usable AJAX enabled competition. The argument for the consumers of ASP's is simple: reduced labor costs. If you can save 30 seconds on each operation, the ROI is easy to see.

I thought that it wasn't too early to check in on the progress here. Beyond the SaaS's mentioned above, Google has added the a spreadsheet and acquired Writely. Beyond Salesforce.com, other vendors are in the Ajax mix:

• NSite is building a portfolio of Ajax enabled SaaS tools, including quote and proposal management, channel management and purchase requisitions.
• Netsuite continues to invest in their Ajax based CRM and ERP dashboards.
• The Zoho suite of products now includes a CRM and online surveys.
• PushCRM is another Ajaxified SaaS CRM.
• 24SevenOffice is a European SaaS company offering CRM, ERP, Document Management, Calendering, etc.
• onProject is offering construction scheduling, project management and Sarbanes-Oxley compliance.
• I forgot 37signals and their suite of SaaS apps last time.

This is just the tip of the iceberg, I'm sure. Of course there are a ton of open source products that are incorporating Ajax but aren't technically SaaS, such as Sugar CRM and Zimbra (OK, had Ajax from the beginning), but these could be considered part of the trend.

One thing that hasn't really been considered here is that business has a tendency of getting impatient with IT. If you've ever consulted in the corporate world, you've come across the spreadsheet sneakernet, the MS Access CRM system, or the Visual Basic skunkworks in the marketing department. What happens when a business group decides to collaborate via Google Spreadsheet instead of waiting for IT? Given the hoops you have to jump through (two factor authentication, etc.) to log into a corporate Intranet these days, and the amount of time people spend working via broadband from home or the road, this sort of temptation may just be too great. Who is going to rope this mess in?

Technorati : CRM, ERP, SaaS, ajax, business reasons, trend

OpenLaszlo Developments Afoot

One way that AJAX frameworks are going to be embraced is by providing lots of widgets. Another is by signing up other companies to develop applications using their framework. Nothing spells credibility than working software. To that end Laszlo Systems has announced that someone's going to be adding more oomph to their email software product built using OpenLaszlo:

Laszlo Systems, developer of OpenLaszlo, the leading advanced open source platform for building and deploying Ajax applications, and Goodmail Systems, creator of the CertifiedEmail system for trusted email, today announced that Laszlo Mail will support the recognition and presentation of CertifiedEmail messages. Offered for license to businesses and communications service providers, Laszlo Mail delivers the functionality and responsiveness of desktop email without requiring any client software installation. Now with CertifiedEmail, Laszlo Mail will have the added benefit of protecting users from phishing and other forms of email-based fraud.

Hmm, the former Flash product is now "the leading advanced open source platform for building and deploying Ajax applications." Last time I looked at their source tree it didn't do DHTML yet.

Ajax Forms - Enhancing the user experience

The web is filling up quickly with examples of Ajax powered sites that allow us to do things we’ve never been able to do before on the web. From note taking apps, to spreadsheets, photo editors, and online games, Ajax apps like these are continually pushing the boundaries of what is possible, and in the process changing the way we work live and play on the internet.

However, we can also use Ajax to build better user experiences for the tasks we’ve already been performing on the web.  One kind of task crying out for Ajax attention is form submittal, in which a user fills in a set of fields and presses the submit button. 

Almost all forms today use the POST action in the SUBMIT button to upload data to the server, where processing gets done, and an entirely new page is sent back to the user.  Depending on the results, this might be a “Thank You” message, or it could specify an error in the form submission (more likely when the form is lengthy).  Either way, the experience is a poor one. 

First, the navigational requirements are increased, as at least two pages are required-one for form and one for result.  The result page usually contains no more that a couple of sentences displaying the results of the form submission, and possibly instructions on what next steps to take.

Second, the user has to wait until the end of the form submittal process to receive any error messaging.  This increases the likelihood that there will be unnecessary typing and mouse movement/clicking, since incorrectly entered information into one input field may require a user to reenter fields down the entire form. 

By using Ajax to asynchronously send the information to a server for processing, form entry and submission can be much more quick and painless. 

Information can be uploaded processed and returned as the user enters data into an input field.  Since not all the input needs to be sent at one time upon submit button on click, the user is told instantly, say, that the username he just entered is already taken.   

Once all the required form data is submitted, the result can be displayed on the same page, allowing the user to move on to other, more enjoyable, tasks more quickly.  If the form is small, and shares screen real estate with other content on one page, the user can continue on that page after the form is successfully submitted.  No need to hit the back button.

Here is an example of what can be done to build a better Newsletter Signup form.

Ajax continually provides us with new and exciting web based products and services.  But is also is a powerful tool for restructuring the way information is presented and manipulated on the web.

Smell the Hype - Gartner Analyst Puffs up AJAX

 

From a UPI article quoting the gartner analyst David Mitchell Smith at a conference in Tel Aviv.

 

By this time next year, Web sites not developed using the Ajax technique "will simply not be cool enough to use," an Internet analyst said Tuesday.

[...]

The research firm, noted for its predictions on technology and business, summed up by positing that there is an 80 percent chance that "By 2008, Ajax-style (sites) will be the dominant style for Rich Internet Application interfaces."

[...]

Gartner analysts expected most businesses to rush out and try Ajax without effectively utilizing Web 2.0's community, social and user-driven aspects. In this case, "the result (of adopting Ajax and other new technologies like Really Simple Syndication and Mashups) will have minimal business impact," Gartner research said.

His advice to businesses was to get on board -- "Management should lead cultural change by example ... by blogging to the staff. This sends the message that this is the way the company should think."

"Denial is pointless," Smith said to sum up. "Don't just roll your eyes -- this is going to be a really big thing when it all comes together."

And they get paid for this advice? Perhaps they need to switch to decaf and read 10 Business Reasons to Use AJAX.

Again - Advertising and AJAX

Eric Picard comments on the impact of AJAX on online advertising. He covers the basics as far as what the difficulties are:

AJAX stands for asynchronous JavaScript and XML, and it's the asynchronous part that causes the problems. In Web pages created using AJAX, content is loaded asynchronously with no browser refresh. This causes big problems with counting page views and impressions: if a page never reloads, it's difficult to define what a page view is. And if the page is never reloaded, deciding when it's appropriate to refresh or load new advertising is left to the developer's discretion. Similar issues exist around software applications that include advertising.

That doesn't seem all that problematic, right? We can use AJAX to asynchronously load new ads. Further, we can drive advertising content off of user activity. Well, there's more to it than that. According to Eric, if your applications don't comply with industry standards, you will fail your impression audit which will adversely affect your ability to charge for online ads.

His solution? Avoid time based ad refreshing:

I've talked a lot with people about time-based page refreshing and what's appropriate. This isn't a new issue and is why the language exists in the current IAB counting guidelines. But it's never been a simple one to deal with. My general guidance is to avoid any kind of time-based advertising refreshes if at all possible.

Event-based ad updating can be OK, it seems, if it corresponds to traditional webapp page loads. Should we root for a rapid update of the standards? Won't AJAX make the ads more intrusive, just like popups used to (and still do, in some cases)? Or can we hope that people will use the new technology to provide us with more pertinent offers?

10 Business Reasons to Use AJAX

I'm not sure where on the hype curve we are with AJAX, but one of the open question for businesses is: why and where should you consider using AJAX? I give ten places, in declining order of urgency, where the use of AJAX should be considered. Most of this innovation will be undertaken without all of the "it's the web!" hype of the dotcom boom. Don't expect to see "AJAX Inside" labels on product packaging. Expect businesses instead to emphasize the improved functionality, usability and solutions that their RIA software provides.

1. ASP's with existing applications. This ship has already sailed. The ASP's include GMail and Yahoo Mail, but extend to places like Salesforce.com, openair.com, and so on. The lower the switching costs, as in the case of email services, the more vulnerable you are to being overtaken by your slicker, more usable AJAX enabled competition. The argument for the consumers of ASP's is simple: reduced labor costs. If you can save 30 seconds on each operation, the ROI is easy to see.
2. ISV's that have products with web-based interfaces. AJAX has already disturbed the world of portals, with drag-and-drop portlets eliminating the need for clunky layout and content pages. But here the opportunities are vast, covering everything from dashboard and monitoring apps with async updates, OLAP tools with drill-down capabilities, Document Management apps with improved browsing, viewing and search, Workflow and BPM tools with improved diagramming, etc.
3. ISV's that have products without web-based interfaces. Some applications just didn't translate well to the web. They had rich, direct manipulation interfaces, or some other features that just couldn't be translated into a forms-and-reports webapp. On the development front, modeling tools, which hove lived on the desktop or in client/sever land, are a possible target, as are other products where collaboration may make up for the lack of convenience of an application that requires a network connection to work. Desktop productivity applications, e.g. spreadsheets, word processors, and so on, have been seeing a lot of activity in the development of AJAX, but there I think that the collaborative spreadsheet may be the way to go. Product managers need to analyze whether their previously protected apps now need to put a web face on. That and the next item...
4. ISV's whose products can now be ASP'd. We've already mentioned the desktop productivity apps as an area of AJAX activity. And anything that can be turned into an AJAX app can also be ASP'd. But the real question is, if you build it, will they come? Desktop productivity apps are not the best candidates for this opportunity if collaboration isn't involved. PowerPoint or other presentation apps that are typically used in environments where connectivity is uncertain will certainly not make the cut. But applications that are used occasionally -- some of Adobe's product line comes to mind: Photoshop, Illustrator, etc. -- and have a big price tag, may be a good fit.
   
5. E-commerce. There is the argument that AJAX can help your customers accomplish their tasks more quickly and result in less cart abandonment. The real reason may be credibility, however. This Stanford study back from 2002 shows that credibility is tied to visual design rather than content. If your web site looks like something from last year, you're likely to fall behind in consumer perception. Old Navy has already put some AJAX enable shopping enhancements in place, as have Gap and Banana Republic. Look for other e-tailers to follow their lead.
6. Financial services. Certainly some of the same credibility arguments apply to Financial Services as they do to E-Commerce, so does Jakob Nielsen's argument for the competitive advantage of usability. The financial services industry has long adopted rich interaction and async update in spots, like ETrade's flash stock information widget. But look for banking, insurance and other providers who offer complex products to adopt the RIA experience offered by AJAX.
    
7. Tool makers. Technically not a use of AJAX, but closely related. IDE's, frameworks. There's lots of activity on this front. TibCO has entered the the fray with it's GI product, and it does incorporate AJAX -- it runs in the browser. Expect all of the big IDE and tool makers to add support for AJAX if they haven't already. Expect all of the app server vendors to add AJAX support. Same for the web servers, messaging middleware, etc.
   
8. Infrastructure providers. Again not technically a use of AJAX, but closely related. Expect a big explosion of new AJAX supporting infrastructure software. Firewalls, load balancers and other network appliances will need to be retooled to meet the new performance needs and profiles of AJAX applications.
9. Community site providers. The line between forums and chat, bookmarks and collaboration is blurring. Usability, credibility are again part of competitive advantage in this space. Yes, the network effect is the strongest factor, and a nifty AJAX upstart isn't going to dislodge Myspace, but for smaller, less well established community categories, it still could be a factor.
   
10. Content providers/Media. This category includes newspapers, magazines, online news sites, etc. This category is a tough call, as it illustrates the conflict between the old web technology and ways of doing things and the new AJAX technology. On the one hand, news and media sites have a proven, bookmarkable, searchable page model that works well with their advertising-driven business model. The bell-weather of newspapers, the NYT, has limited their improvements to collaborative filtering and enhanced multimedia resources, while the WSJ has added some AJAX enabled selection-based search, so the movement here seems somewhat tepid at the moment. Look for improvements that enhance but don't fundamentally change the user experience.

Right now the hype of AJAX hasn't resulted in a whole lot of activity in the corporate ranks. Product managers are wisely keeping their powder dry and waiting for the technology to mature. But the pressure to respond to competition will ultimately drive a wave to retooling -- in the 10 places above and elsewhere.

AJAX: Only Large Corporations Can Play?

Over at Pligg Blog the question is does the new AJAX technology put cool appdev out of the reach of all but the deepest of pockets?

Do you think that the development of well written and web 2.0 software has changed to something that only corporate conglomerates have created?  Or are there open source scripts out there that offer creative uses of web 2.0 technology?

I've blogged on related topics, specifically that AJAX application developed int he old, multi-tiered forms-and-reports way are doomed to a hell of 10,000 lines of spaghetti code. If you instead write applications using the Component GUI approach, you can crank out sophisticated, desktop style apps with the big boys. Have a look at what 300 lines of Java code can do.

Webtop - I Already Hate It

A reader emailed me this old article from CNN Money discussing the concept of the webtop, i.e. that

A killer app no longer requires hundreds of drones slaving away on millions of lines of code. Three or four engineers and a steady supply of Red Bull is all it takes to rapidly turn a midnight brainstorm into a website so hot it melts the servers.

What has changed is the way today's Web-based apps can run almost as seamlessly as programs used on the desktop, with embedded audio, video, and drag-and-drop ease of use. Behind this Web-desktop fusion are technologies like Ajax (asynchronous JavaScript and XML), Macromedia's Flash, and Ruby on Rails. We'll spare you the technical details; suffice it to say that these technologies are giving rise to a new webtop that may one day replace your suite of desktop applications.

I already hate the term "webtop," though I've used it myself in the past. The article goes on to discuss the various webapps that are starting to move into areas once reserved for desktop applications, then lists of a few noteworthy apps, such as 37signals campfire chat client.

The conclusion? We'll all be doing our word processing over the web from now on.

Now I like a little bit of breathless hype as much as the next guy, but this is over the top. Yes, webapps are going to change, but there are certain limitations to the medium that will make the webtop a much tamer place:

• Reliability and performance - why aren't most desktop apps in corporate environments served up as client/server apps? The technology is there; the kinks of client/server have mostly been worked out. License sharing could save tons of money. The benefits of reliable, centralized storage and ease of collaboration seem pretty obvious. Yet the most we see is networked storage of documents. The reason? Even on a corporate network, performance and reliability are not high enough to make client/server computing for desktop apps attractive.
• It's more than just CRUD on speed - even after the widespread introduction of the WIMP (Windows, Icons, Menus, Pointing device) environments in the 80's, it took a while for programs to mature beyond GUI versions of Lotus 1-2-3. We didn't see precursors to Photoshop until a few years after the introduction of the Mac. Most webapps today are still glorified CRUD (Create, Read, Update, Delete) engines. Writing the more substantial applications will take a good bit of work, not just a few cans of Red Bull (or Jolt!, sniff).
• Writely ain't Word - more like Wordpad. If Writely was out as a desktop app, it wouldn't get a second look. Yes, there is a need for a Word-compatible, easier, less bloated, free word processor, but they never seem to make it. Yes, a web based word processor that saves your work more frequently than an occasional submit is kinda cool. But the truly cool part is the collaboration feature of Writely, and honestly, there are other, better solutions for that.
• Can I Use it Offline? - You're not going to be online all the time. The moment you have desktop versions that can function independent of the server, is it still Ajax or a Javascript/Browser app with save capability?

This hype around Ajax is really starting to remind me of the first dotcom boom (See FauxJAX for a good sendup of this). I had a few venture capitalists back then asking me to look at business plans that added "the web" to their business models. My rule for evaluating these was always the same: what does the web add? Most times it didn't change anything; it was just another marketing channel. For others, like online classifieds, it removed distribution costs. For the social networking type businesses, it made it easier and less costly to jumpstart the network effect.

So, for those going gaga over Ajax, ask yourself, what does Ajax add? If you can't come up with a good answer, odds are it doesn't add a thing.

Upcoming Talk - Back to the Future: Component GUI's and Ajax

I'll be giving a talk at the Chi2 monthly meeting on Wednesday, April 26, 2006. The highlights are:

• Why web applications are they way they are and how things are changing
• First attempts: frameworks and toolkits that extend current practice
• How Ajax has turned the browser into a desktop
• Component-based GUI's and how they cut down on Ajax Development time
• Which frameworks get it right

For more information see here. If there is a podcast, we'll try to make that available along with the presentation.

Ajax, PageViews and the Advertising Based Business Model

As far back as December of last year, Forbes was ringing the alarm bells about Ajax breaking the advertising business model:

While a popular approach to monetizing AJAX applications is advertising, there is a problem: There are no "page views." For example, suppose that on an AJAX Web page, you want to view the body of a news article, so you click a news headline link. Rather than refresh the entire page (a page view) as you would with a traditional web page, the AJAX technology downloads just the body of the news article and rearranges the Web page to present the article content.

They go on to correctly point out that Ajax presents a potential boon to advertisers, with Ajax powered ads allowing them much greater control. I would add that it could give them a much greater ability to measure who is exposed to their ads and for how long.

"Adviews," i.e. the number of ads viewed (changing every X seconds) may become the new measure, rather than pageviews. Perhaps this will drive a change in site, getting them to make the page -- rather than the site -- more sticky, and getting rid of such annoying things as article splitting.