Google Base = Flickr + Odeo + Typepad + …

Google Base: It goes beyond classifieds. The popular view today seems to be that Google Base is all about classifieds, but as mentioned earlier, it’s much more than that. (Incidentally, still smarting I missed the “All Your Bases” happy fun humorous moment opportunity.)

If Google Base lets you tag entries, you could easily create a podcast feed by just uploading MP3s and giving each the same tag. Likewise, you could create a blog by uploading text entries with the same tag, and a vodcast with videos. Google could easily offer a wiki interface to let you manage all your content, and a feed to go with it.

From a programming perspective, what’s nice about all this is the prospect of a common API for all sorts of content.

So while Craigslist ought to be watching closely, so should many others. This is Google’s answer to Flickr and just about everyone else who’s hosting microcontent.

Blummy: The Mother of All Bookmarklets

Check out Alexander Kirk’s new website: Blummy. A blummy is a kind of bookmarklet that opens up a kind of pop-up portal, giving you access to various web services. Just like a portal is made up of Portlets, a Blummy is made of Blummlets, which essentially do the kind of things bookmarklets do. e.g. A blummlet can let you subscribe to this page with Bloglines, change the browser location, or show an image. Where the blummlet is interactive, the action takes place within the popup as a Live Form.

Here’s a few interesting things about the site:

  • Because the Blummlet lives in a bookmarklet, XMLHttpRequest can access any domain. Scott Isaacs recently suggested it would be worth the risk for browsers to drop the same-domain policy, though it’s unlikely to happen anytime soon. A bookmarklet, I’m guessing, gets around that constraint.
  • The site lets users share Blummlets, which might lead to Cross-Site Scripting (XSS) attacks like the now-famous myspace effort. Alexander’s well aware of this risk, which is why there’s a “Report Concern” checkbutton. It will be interesting to see how this kind of moderation works out. I still think users might need something stricter, like a whitelist approach, where Blummlets have to be explicitly approved by “the community”, i.e. guilty until proven innocent. (This is still vulnerable, but I think it’s a better trade-off overall.)
  • There are shades of yubnub here, as well as the widget/gadget/startlet idea seen on start.com. Leading to a repository of Blummlets. I mentioned to Alexander it would be nice to see an RSS feed, where users could somehow drag or a Blummlet into their existing Blummy.
  • Speaking of gadgets/widgets, the popup feels something like Dashboard and Konfabulator. Another example of tha Ajax Desktop, and a pretty useful one in this case. There are various popup bookmarklets like JSCalc, which offer one particular function. They are convenient , but there’s no central management point, and a lot of duplication and inconsistency in how the manage the popup experience. So Blummy does to the browser what Dashboard does the windows system: provide a common structure for individual applets. I haven’t looked into the programming model, but there’s probably good scope for a JS util library to further facilitate Blummlet development.

Ajax Myths (Podcast and Text)

It’s that time in a technology’s lifecycle when myths abound and someone wheels out a collection of “myths” and retorts. Here’s my contribution to that time-honoured genre. Nine myths in 37 minutes.

Click to download the Podcast. You can also subscribe to the
feed if you want future podcasts automatically downloaded - check out the
podcast FAQ at http://podca.st.

Myth: “AJAX”
Reality: Ajax

Myth: Ajax is rocket science
Reality: It’s an incremental progression

Myth: Javascript sucks
Reality: It doesn’t

Myth: The URL’s always the same
Reality: Unique URLs are possible

Myth: Ajax==XMLHttpRequest
Reality: There are other remoting technologies, and some Ajax apps don’t need any at all

Myth: The server must output XML
Reality: Server can output plain-text or specialised formats like JSON

Myth: Ajax lets websites spy on users.
Reality: The same “spying” techniques have already been possible using images and form submissions.

Myth: Ajax will crush Flash.
Reality: Flash can augment Ajax.

Myth: Ajax will rule the world!
Reality: Ajax still has many challenges ahead: usability, accessibility, portability, scaleabiity …

Ajax, not “AJAX”: A User-Centered Definition

Many equate Ajax to “Is it using XMLHttpRequest?”, which I think is taking the acronym too literally. There’s a reason why I’ve learned to say “Ajax” rather than “AJAX”: the term is user-centric, not techno-centric, and best defined in terms of what it gives users rather than how you deliver it. And what it gives users is a rich, continuous, experience to rival the desktop, with standards-based technologies.

Jesse James-Garret, who coined the term, doesn’t define Ajax in terms of specific technologies. Here’s what he said in the recent Ajaxian.com podcast interview: “In my opinion, Ajax refers simply to using browser-native technologies, open standard technologies, in ways that depart from the traditional interaction model of the web – the kind of call-and-response interaction model where every user action is tied to some kind of server communication, and while that server communication is going on, no user actions can take place. Any time you’re decoupling the flow of user interaction with the application from the flow of server communication, and you’re doing that with browser-native standard technologies, I think that’s Ajax.”

If you can pull off a rich browser client using HTML 1.0, you got Ajax! In reality, you’ll end up using a mix of technologies suggested by the acronym (“Asynchronous Javascript and XML”) and some other things too (“DOM/DHTML/CSS”), but not necessarily all of those things. Having peeked under the covers of various high-profile Ajax sites, it’s clear that many are using custom-format messages, rather than XML for transfer. Similarly, XMLHttpRequest is not the only valid means of transfer. Google Maps uses IFrames, I’ve come across various enterprise systems that do the same, and I expect other Ajax apps do it too (and still on the lookout for examples BTW).

Flock: A Tribute to Unusability of Firefox Extensions?

You’ve probably noticed the buzz around Flock, a browser built on Firefox. Information’s limited, but it seems to pick up on the “social” buzzword – tagging, annotations, RSS etc. Thing is, all of these things are possible in Firefox too via extensions. But extensions haven’t really taken off, and the reason is, quite frankly, poor usability. Firefox is a great browser with a plugin architecture that’s pretty good too. The problem is at the last mile: helping users install and manage their extensions.

Sure, developers will install programming extensions and uber-geeks will set up mouse gestures, but it won’t get beyond that in its current state.

So here’s how a plugin architecture should work:

  • Installing plugins should be dead simple. Pull up a list of plugins and click to install … that’s it! Come on, you own the whole browser and the server too! Make them work together. The current task is something like “visit extensionroom, search for extension, jump into extension page, click Install, Notice security dialog box about this subdomain if you’re lucky, Allow the subdomain, Click Install again if you’re savvy enough to realise what just happened, Watch it download, Click Install, Restart the browser if you’re still interested”. If the version’s incompatible, you’ll only find out at the end of all that (except the restart). True, the version number’s shown when you install it, but that’s really making the user do something the computer should do immediately. Also, most users don’t remember what version they’re running, and I’ve even seen extensions with the version labeled as “Deer Park”.
  • The standard distribution should have a set of extensions pre-installed. Just because you’re using a plugin architecture doesn’t mean you have to ship with a bare-bones distribution. I know there are potentially licensing issues, but shipping with plugins seems to work OK for Eclipse and similarly for the Linux distributions. Satisfy the slashdot crowd with a minimal distribution too, by all means, but mainstream users would rather not spend three hours working out how to install extensions, finding out which are popular/useful, discovering incompatibilities between different extensions, etc. There are plenty of extensions that enhance basic functionality – e.g. All-In-One Sidebar, Adblock, the improved search bars, the improved RSS aggregators – why not take advantage of them? In addition, there’s great scope for specialised distributions, e.g. Developer, Socialite. I know anyone could probably make them and distribute them, my main point here is that Firefox itself should at least distribute a more powerful default distro.
  • Don’t rely on third-party extensions for fundamental functionality. Tabbed browsing works OK in the basic distribution, but the Tabbrowser extension gives it much more power – certainly it brings it up to Opera standard. Yet, it’s been unsupported for over a year, confusing, and buggy at times. Something like this is too important to leave to a third-party. Develop it as an extension if it’s architecturally convenient to do so, but make it mandatory, so that other extensions play nice with it.
  • Provide update notifications. Indicate when updates are present and offer to do the update automatically.

Greasemonkey took off so quickly because it’s so easy to develop, modify, and install GM scripts. Hopefully, the lessons of Greasemonkey and the imminent release of Flock will offer some lessons, and help make Firefox an even greater browser.

Chat: The “Hello World” of Ajax?

Day Barr:

Chat is not quite the Hello World of Ajax, but it’s one of the simplest yet useful things I could do. I didn’t learn very much by writing an Ajax Hello World example and it’s completely pointless :-)

As many are learning, an Ajax “Hello World” is pretty easy, provided you’ve already got a grounding in web/JS programming. So beyond that, what’s the quintessential Ajax tutorial app? Some of the Ajax texts are beginning to pour out, so maybe a pattern will emerge. But, for now, the learning apps of choice seem to be:

I’m surprised we haven’t seen more people playing with Ajax wikis and RSS aggregators, but I’m sure they’re coming.

BTW, a basic “Hello World” might be easy, but it’s also a useful springboard for some important variants. e.g. Add a long delay in your server and see how the browser script handles a timeout (or simulate a delay with Julien’s GM script. e.g. Host the service on another domain and have the server act as a proxy. e.g. Apply a visual effect like the famous Yellow Fade Technique when the message comes in. These variants aren’t just interesting exercises – all are important for real-world Ajax development.

Rolled My Own Ajax Search

I just added an Ajax Searchroll with Rollyo, the new search engine that lets you “roll your own” (get it?) search. For example, click on the following link to search for “xmlhttprequest” on my selection of Ajax sites:

[http://rollyo.com/search.html?q=xmlhttprequest&sid=2220](http://rollyo.com/search.html?q=xmlhttprequest&sid=2220 )

(The 2220 ID corresponds to “Michael Mahemoff’s Ajax Search”.)

Rollyo lets anyone add up to 25 sites, and then constrains search results to those sites. Best thing is the site contains a link that lets you easily add a particular search to the Firefox search bar.

The Ajax search consists of links from the publicly-editable (nudge nudge) Ajax Links page as well as a few others worth searching. Please add any further suggestions here or on the links page. Given the constraint of 25 or under, I’ve limited it to Ajax content sites and very-Ajax blogs. Due to rollyo restrictions, the site must also have its own (sub-)domain rather than being qualified by a pathname (so I couldn’t, for example, add Scott Isaacs at http://spaces.msn.com/members/siteexperts/).

Rollyo wishlist:

  • Combine SearchRolls – e.g. there’s already a couple of other Ajax searches on there, it would be nice to search all at once. You could even give more relevance to sites listed in both. Maybe exclude a searchroll as well.
  • More than 25 URLs! Fair go, ref!
  • Sync URLs to some other source, e.g. a delicious tag, or in my case, the AjaxPatterns Links page.
  • Integrate as A9 columns, start.com gadgets, etc. They already have plans for Dashboard widgets, so they’re probably on to it.

It will also be interesting to see how Yubnub integrates with it. Also of note is the number of “high rollers” high-profile bloggers and celebs who’ve established their own Searchrolls (given that, based on my uid of 1882, there are under 2000 users). Looks like a nice example of guerilla marketing.

Cross-Domain Portlets with Start.com Gadgets/Widgets/Startlets

Scott Isaacs on a new Start.com feature (quoted on Ajaxian):

DHTML-based Gadgets: Start.com consumes DHTML-based components called Gadgets. These Gadgets can be created by any developer, hosted on any site, and consumed into the Start.com experience. The model is completely distributed. You can develop components derived from other components on the web.

Remote portlets take the Ajax portals to another level. In fact, the whole concept is one of the biggest developments in the history of the web. A9 pre-empted it with their “Open Search” capability, which allows developers to hook into the A9 interface with live search results. Now MS is going a step further, with Konfabulator-style interaction directly on the web. It’s likely Yahoo has similar plans, given that it’s now the owner of Konfabulator. What Google does is anyone’s guess. Strategically, MS has a big edge here because of its experience working with Developers, Developers, Developers! (YES!)

The idea combines [Cross-Domain Mediator](http://ajaxpatterns.org/Cross-Domain Mediator) with Portlet. Those patterns have subsumed a now-deleted pattern that previous covered this kind of thing:

Cross-Domain Portlet: Introduce Interactive Portlets to facilitate a conversation between the user and a third-party, e.g. for services or “advertising as conversation” (http://radar.oreilly.com/archives/2005/05/remaking_advert.html)

Ajax makes it possible because there’s no page refresh. Conceptually, each portlet is autonomous and capable of conducting a conversation with another domain in parallel with other portlets. When a result comes back to one portal, the other portlets are unaffected. (You can obviously yoke portals together if you want to.) In practice, there are a couple of finer implementation points:

  • You can’t make an XMLHttpRequest Call to an external domain. Hence, the portal server must mediate.
  • Conducting parallel conversations, you’ll need some form of Call Tracking. Hopefully, you’re using a library that abstracts those details from you.

Now that a happening, here are a few things I’d like to see:

  • An open standard for conducting cross-domain conversations, one that protects the end-user and the portal host, but provides sufficient functionality to the
  • Useful ads (the advertising as conversation) concept. There’s definitely a business model here for opt-in advertising. That is, users would be willing to add advertising portlets that offer genuinely useful information. e.g. a travel portlet that lets you check flight availability.
  • RSS aggregator integration The nature of a portal can change, right? So RSS aggregators should be able to include remote portlets.
  • End-user-created portlets. Make it easy for end-users to construct their own gadgets. This idea is inspired by Charlene Li’s comments on Konfabulator: “The problem is I already know what the ultimate widget would be me … There’s only one small problem — I don’t know JavaScript! So I am at the mercy of app developers …”

Sometimes the world is ready …

Researching JSON-RPC for the “JSON Message” pattern, I came across this interesting slashdot posting from January 24, 2005, a few weeks before “Ajax” was coined

Seen those funky remote scripting techniques employed by Orkut, Gmail and Google Suggests that avoid that oh so 80’s page reloading (think IBM 3270 only slower) … Now is the turning point. Forget that horid wait while 100K of HTML downloads when the application just wanted to update one field on the page. The XMLHttpRequest object has made it’s way into all the main browsers with it’s recent introduction into Opera and Konqueror (sans the Konqueror bug). This new form of web development now works on Internet Explorer 5, 5.5, 6, Mozilla, Firefox, Safari 1.2, Opera 8 Beta and Konqueror 3.3 (with a much needed patch). (Emphasis Mine.)

Ben and Dion @ Ajaxian also mentioned in their recent podcast they had to stay up late in Las Vegas reworking their TSS presentation because Ajax had just been coined and matched their content.

Sometimes the world is just ready for something.

A recent podtech podcast had a VC mentioning how he’ll often hear a great proposal for the first time, then hear the same idea from five different startups within two weeks. It reminded me of this ridiclous-but-true dotcom-days story from 2000, where a journalist wrote an April Fool’s story about a startup offering free cars with advertising on them. Several real companies meanwhile were planning to do just that, and legend has it that they sweated upon encountering the article. But here’s the punchline:

FreeCar’s Mr. Butler purchased the FreeWheelz joke Web site for $25,000 from Esquire and Mr. Fishman, who split the proceeds. “They got a lot of hits to their Web site,” Mr. Butler reasons. “I have access to their database and prevented anyone else from buying it.”