Entries from May 2008 ↓

This has to be the coolest implementation of Pong ever: load the iPong application in two or three iPods touch units or iPhones, and start playing between them using your finger, with the ball actually passing from one screen to the other depending on the ball angle.

The software was made by Mr. Kondo—a colleague of Ryo Shimizu, CEO of Ubiquitous Entertainment—in an hour. We don't know if it will make its way to the iTunes store as a commercial product, but I hope it inspires other developers to use this kind of competitive—or collaborative—gameplay. [Asiajin via [Technabob]

One of the examples that Ben and I give in our State of Ajax talk at Google I/O today revolves around form history.

We were thinking about the case for Undo on the Web that Aza Raskin is proposing and it got us thinking about the usage patterns of form data.

An example that got me was the Address Book application on the Mac. I find myself storing past addresses in the general “Notes” section at the bottom, but what if history was built into the system so I could go back in time? This could be a nice metaphor in general that goes beyond undo.

I took this use case and put together a working example that uses Gears to store the history locally so it can be speedy through the history.

The slider component comes from Script.aculo.us, and you can check out all of the code.

In the video below I show the application in action and then do a quick code walk through:

This is just the beginning of course. A slider if fun, but it would probably be more usable if it was simply left and right arrows that click through the versions, or at least putting tacks onto the slider.

It has long been known that savvy restaurants use a bag of tricks to build buzz and interest. One trick is to seat early customers near windows so that people passing by will think the place is full. This has the effect of making the place seem popular as people usually can’t see the empty seats that are further inside the restaurant.

A second trick restaurants use is to create a line out the door so that people think there is strong demand. This is also often artificial, making us think that many people are waiting to get in. Sometimes they merely create lines by not letting people sit down, making an excuse that the empty seats are “reserved”. Other times they simply don’t let people in. This is often practiced by nightclubs, who rely even more on mystique and exclusivity than restaurants do.

These techniques leverage powerful social behavior. When people are searching for a place to eat, they rely on the behavior of others to help them make their decision. They seek out signs of life…signs that other people are present and already doing something. If they are doing it, it must be worth it, we think. Given the choice between something that nobody has chosen to do and something that many people are doing, it is human nature to gravitate to what others are doing.

On the web, signs of life are extremely important, for several reasons.

• Too much choice
  One reason is the sheer amount of choice we face. As the web continues its torrid growth, we simply have too many web sites to sort through, too many places to buy products from, too many software providers to pick from.
• Black box of use
  Another reason signs of life are important is that web applications are like black boxes. Many applications, like Google Docs, for example, require a login to use. Because of this we simply can’t see what others are doing with the software. We can’t see if they’re using it well or not using it at all.

When sites leverage signs of life well, it provides welcome direction for folks trying to make a decision. A great example of signs of life is the Freshbooks home page, which contains an interface element called “Some of our happy users…”.

The happy users element does many things well. Most importantly, it is authentic. You immediately get the sense that these are real people who actually do like the product. The pictures are decent, but not airbrushed or overly produced. The quotes sound like real people, not infomercial-like. Subtle touches like using people from all over the world and including team size add to the sense that these people are just like you: the intended audience.

In addition to these testimonials, there are many other ways to leverage signs of life. I describe several more in Designing for the Social Web. But though leveraging signs of life in your design is powerful, it must be authentic. You can’t use stock photography and made-up quotes and expect people to react positively to them…people can smell fake a mile away.

While the Freshbooks people aren’t actually standing in line outside the door of a restaurant, they might as well be. They’re having the same effect: showing others there are people here using this software…acting as signs of life on what could otherwise be a desolate home page.

Erick Schonfeld / TechCrunch:
Mobaganda: A Dead-Simple Invite Site Built On Google’s App Engine  —  If you like your invite apps dead-simple, check out Mobaganda.  You don't even have to log in.  Just click on start, add the name, date & time, and location, and create an event.  The site, which is built on the Google App Engine …

The idea behind AppleCore LLCs aTV Flash Drive is that users can reflash their Apple TV and add all sorts of cool and useful functionality without having to waste time scrounging around the internet looking for hacks. According to the product website, all you need to do is install the drive and it will do the rest—without voiding your warranty. But what sort of features will it add?

Key Features: – Play most video formats (DivX, Xvid, AVI, WMV, RMVB + more) – Play DVD files WITHOUT converting them – Sync, organize and watch non-iTunes video files – Browse the web with a Safari based web browser – Rent & watch Hi-Def movies from Jaman.com – Stream media from UPnP(v1) media servers – View local weather forecasts – View RSS Feeds – Enable SSH access – All original Apple TV features remain intact – And much, much more…

The drive will run you $59.95, which is a small price to pay in proportion to the enhanced functionality you will receive. This is in addition to the fact that it can save you a ton of time—not to mention one big headache. [AppleCore LLC via Palluxo via Crunchgear]

I just got to announce the Google AJAX Libraries API which exists to make Ajax applications that use popular frameworks such as Prototype, Script.aculo.us, jQuery, Dojo, and MooTools faster and easier for developers.

Whenever I wrote an application that uses one of these frameworks, I would picture a user accessing my application, having 33 copies of prototype.js, and yet downloading yet another one from my site. It would make me squirm. What a waste!

At the same time, I was reading research from Steve Souders and others in the performance space that showed just how badly we are doing at providing these libraries. As developers we should setup the caching correctly so we only send that file down when absolutely necessary. We should also gzip the files to browsers that accept them. Oh, and we should probably use a minified version to get that little bit more out of the system. We should also follow the practice of versioning the files nicely. Instead, we find a lot of jquery.js files with no version, that often have little tweaks added to the end of the fils, and caching is not setup well at all so the file keeps getting sent down for no reason.

When I joined Google I realised that we could help out here. What if we hosted these files? Everyone would see some instant benefits:

• Caching can be done correctly, and once, by us… and developers have to do nothing
• Gzip works
• We can serve minified versions
• The files are hosted by Google which has a distributed CDN at various points around the world, so the files are “close” to the user
• The servers are fast
• By using the same URLs, if a critical mass of applications use the Google infrastructure, when someone comes to your application the file may already be loaded!
• A subtle performance (and security) issue revolves around the headers that you send up and down. Since you are using a special domain (NOTE: not google.com!), no cookies or other verbose headers will be sent up, saving precious bytes.

This is why we have released the AJAX Libraries API. We sat down with a few of the popular open source frameworks and they were all excited about the idea, so we got to work with them, and now you have access to their great work from our servers.

Details of what we are launching

You can access the libraries in two ways, and either way we take the pain out of hosting the libraries, correctly setting cache headers, staying up to date with the most recent bug fixes, etc.

The first way to access the scripts is simply be using a standard <script src=".."> tag that points to the correct place.

For example, to load Prototype version 1.6.0.2 you would place the following in your HTML:

The second way to access the scripts is via the Google AJAX API Loader’s google.load() method.

Here is an example using that technique to load and use jQuery for a simple search mashup:

You will notice that the version used was just “1″. This is a smart versioning feature that allows your application to specify a desired version with as much precision as it needs. By dropping version fields, you end up wild carding a field. For instance, consider a set of versions: 1.9.1, 1.8.4, 1.8.2.

Specifying a version of “1.8.2″ will select the obvious version. This is because a fully specified version was used. Specifying a version of “1.8″ would select version 1.8.4 since this is the highest versioned release in the 1.8 branch. For much the same reason, a request for “1″ will end up loading version 1.9.1.

Note, these versioning semantics work the same way when using google.load and when using direct script urls.

By default, the JavaScript that gets sent back by the loader will be minified, if there is a version supported. Thus, for the example above we would return the minified version of jQuery. If you specifically want the raw JavaScript itself, you can add the “uncompressed” parameter like so:

Today we are starting with the current versions of the library, but moving forward we will be archiving all versions from now onwards so you can be sure they are available.

For a full listing of the currently supported libraries, see the documentation.

Here I am, talking about what we are doing in two short slides:

The Future

This is just the beginning. We obviously want to add more libraries as you find them useful. Also, if you squint a little you can see how this can extend even further.

If we see good usage, we can work with browser vendors to automatically ship these libraries. Then, if they see the URLs that we use, they could auto load the libraries, even special JIT’d ones, from their local system. Thus, no network hit at all! Also, the browser could have the IP addresses for this service available, so they don’t have the hit of a DNS lookup. Longer lived special browser caches for JavaScript libraries could also use these URLs.

The bottom line, and what I am really excited about, is what this could all mean for Web developers if this happens. We could be removed of the constant burden of having to re-download our standard libraries all the time. What other platform makes you do this?! Imagine if you had to download the JRE everytime you ran a Java app! If we can remove this burden, we can spend more time flushing out functionality that we need, and less time worrying about the actual download bits. I am all for lean, but there is more to life.

Acknowledgements

I want to acknowledge the other work that has been done here. Some libraries such as jQuery and Dean Edwards Base were already kind of doing this by hot linking to their Google Code project hosting repository. We thought this was great, but we wanted to make it more official, and open it up to libraries that don’t use our project hosting facilities.

Also, AOL does a great job of hosting Dojo already. We recommend using them for your Dojo needs, but are proud to also offer the library. Choice is good. Finally, Yahoo! placed the YUI files on their own CDN for all to use.

A couple of weeks ago we ran an interactive game on the topic of Data Portability. We had a great response, with 680 people playing the game.

Here now are the results, showing how RWW readers think 5 of the major players – Google, Microsoft, MySpace, Facebook, and the non-profit Data Portability Project – will play out the future of Data Portability.

To remind you of the background to the game. Recently three major players in the social networking space each announced independent competing approaches to making profile and friend data portable. MySpace Data Availability was followed by Facebook Connect and then Google Friend Connect after that. With all of these competing APIs, how this will play out is anyone’s guess. So we created an interactive app from Impact Games that lets you model how each of the major players will impact the data portability movement, as well as share your opinions about what they should do.

The Results

A reminder that the ‘opinion’ category is what you hope will happen and ‘prediction’ is what you think will happen.

Two points were consistent with our expectations:

• The majority hoped Facebook will merge, yet predicted that they won’t.
• The majority hoped Microsoft will advocate open standards, yet most expected them to launch a competing platform.

One result that surprised us was that many people didn’t expect the Data Portability Project to endorse a specific platform. Given their roadmap, this would not have been our guess.

For more on the topic of the future of Data Portability, see Chris Messina’s post today on the battle for the future of the social web and Dave McClure’s response.

What do you think of the results? Do you think Facebook and Microsoft will listen to what early adopters think they should do?