To Suggest or Not To Suggest

Ajax has been one of the most hyped technologies in recent memory. However, much of the hype is deserved. It really has changed the way we (web developers) build applications and the expectation of users. One of the archetypes of Ajax is the auto-suggest text box. I don't know who first came up with, but I first remember seeing it on Google. I think it was once a "special" version of the Google home page (Google Suggest?), but not it is standard:

It makes for a natural option on search text boxes. Here it is on some of the other search engines out there. Yahoo:

And on the search hotness, Bing:

Of course pure search engines are hardly the only sites that have search and thus have auto-suggest text boxes. It's pretty useful for ecommerce sites too...

As you can see, some sites have gotten creative with their suggestions. Here is another great example of that from Apple:

All of these examples are for search text boxes. If what you want is not suggested, you can still type it and the application will perform a search on it. A little more interesting example is on Facebook:

Here there is a "closed list" behind the suggest box: your friends. However, it is still a search box. If you type something that is not in the list, it will still perform a search that will return results. Of course, really all of the suggest boxes have a closed list behind them as well, but that list is probably much bigger than your list of friends on Facebook (unless you are Robert Scoble.) So the theme continues: there is a finite set of predetermined suggestions, but if you type in something not in that set, the application can still process your input.
Recently, I saw a different use for auto-suggest boxes: as a drop-in replacement for select/option boxes (a.k.a. drop-down box or combo box). This is fundamentally different than any of the examples above. It would be like the Facebook example, but with the limitation that your friends were the only valid input into the search box. In fact, Facebook has a scenario that is similar to this: tagging people in photos/videos:

However, even in this case, you can type the name of somebody who is not one of your friends. This is valid input. After all, maybe not everybody that you take pictures of has an account on Facebook. My kids are growing up fast, but my five year old son is not yet on Facebook...
I imagine that this pattern -- using auto-suggest box to replace a select/option box -- is used on websites out there. It seems like a reasonable thing to do to avoid a drop-down with a large number of choices, or a drop-down that is expensive to calculate and is often not used. However, it seems awkward, too. What do you do when a user types in something that is not in the box? I like to type, and I'm both reasonably fast at it and make enough spelling mistakes that this could be a common scenario from me.
Now I am no user experience expert. In fact, as a web developer, I would say that I am perhaps the least qualified person when it comes to judging user experience on the web. My knowledge makes me very forgiving of things that might be confusing to others, while it also makes me critical of things that others would not notice. So I am curious about other's people's experiences and opinions. Are there sites out there that use this pattern? Is it useful or awkward?

Slides from AjaxWorld

Posted by somebody else! Thanks!

Netapp Michael Galpin

View SlideShare presentation or Upload your own. (tags: ajaxworld-2008)

AjaxWorld 2008

AjaxWorld was this week, and it was interesting. I think the down economy is having an affect on everyone, but there were still a lot of interesting things to learn about. On Monday, I did a talk on a favorite topic of mine, networked applications. The talk was a lot of fun, hopefully the audience would agree with that assessment. Overall though, I would say there were a couple of major themes at AjaxWorld this year.

1.) Comet. There were a lot of talks about some form of data push from the server to the browser. Kevin Nilson did a nice job of differentiating Ajax (infinite loop of XHR polls) vs. Comet (long poll.) The folks at ICEFaces have built some nice abstractions on top of Comet. There was also a lot of interest around WebSockets, especially the work by the folks at Kaazing. A duplexed socket connection to the server sounds great on paper. I think there will be some very interesting technologies that grow around that.

2.) Don't make me learn JavaScript! There seemed to be a lot of folks advocating the "only know one language" approach to the web. In most cases that language was NOT JavaScript (even though the Jaxer guys say it can be.) Vendors liked Oracle and ICEFaces preached abstractions that shielded the developer from JavaScript. Of course the GWT folks say do everything in Java. Microsoft says use Silverlight so you can do everything in C#. Of course one of the best sessions was by Doug Crockford who told everyone to man up and learn JavaScript. I tend to agree with Crockford, even though I prefer ActionScript...

October Talks

October is going to be a busy month for me. Next weekend I will be at Adobe's FlashCamp. I will be there Friday night and Saturday, and I may do a short session on TwitterScript, the ActionScript API that I maintain. In particular I want to talk about some of the authentication wrinkles present in TwitterScript and its forked brothers.

On October 20, I am speaking at AjaxWorld. I am going to be talking about a subject near and dear to me, Networked Applications. I'll be talking about why you shouldn't waste the power of your servers building HTML strings but why you should instead start using things like jQuery, GWT, or Flex to cash in on the power of your user's computers.

The week after that, I will be on the east coast speaking at EclipseWorld. On Day One, I am doing a day long, introductory workshop on Ruby on Rails. Of course I'll also talk about how Eclipse can help you out. On Day Two, I am doing two talks. One ties in to the previous day's workshop and is about RadRails. The other session is on ... iPhone development. Kind of a strange topic for me. Chris Williams from Aptana was supposed to do both sessions, but couldn't make it. So Aptana asked me to fill in for him. Hopefully they won't wind up regretting that decision!

JavaScript Benchmarks, now with Chrome

As promised yesterday, I did the JS benchmarks again on a Windows machine so I could include Google Chrome. I tried to be pretty inclusive, adding in IE7, IE8 beta 2, Firefox 3.0.1 (current release), Firefox 3.1 with and without JIT, Safari 3.1 (current release), Safari 4 beta, Opera 9.5 and Chrome. This was all run on my workstation, a 4-core, 3.2 GHz box with 8 GB of RAM. Any add-ons, extensions were disabled. Here is the pretty picture.


Once again Safari is the kind. Safari 3.1 beats everything except for Safari 4 beta, which crushes even Safari 3.1. Opera was a little slower than Safari. Chrome was generally comparable to the various Firefox browsers, but overall slightly slower. Like Firefox 3.1+JIT, it was very on error handling! Of course IE was the slowest by far, but at least IE8 is faster than IE7. Maybe IE8 is shipping with debug symbols included (as Microsoft has often done in the past) and the release candidates will be much faster than the betas. Or not.

Anyways, Chrome, and its V8 engine, does well, but does not seem to be ahead of Firefox and is certainly behind Safari and Opera. Maybe they can do better on the Mac!

Parsing XML on the Client: JavaScrpt vs. ActionScript

Developer: Wow the JavaScript interpreter on Firefox 3 is awesome, but the one on the new Safari is even better. It is a great time to be a JavaScript developer!

Me: It is still a lot slower than ActionScript.

Developer: Oh don't quote me old numbers, the new browsers are so much faster.

Me: Still slower than ActionScript.

Developer: Maybe slower at doing useless things like calculating prime numbers. Who would do that in a browser anyways? The new browsers are fast at doing realistic things.

Me: But still slower than ActionScript.

Developer: Show me some proof on something realistic, like parsing XML coming back from an Ajax call.

Me: [Whips together a servlet for producing huge chunks of XML and some JS and a SWF for calling it and doing a DOM parse.] Alright let's see the results of these tests...

Everything is O(N), as you would expect, and can verify by doing a linear regression of XML document size vs. parse time. Safari 4 is much faster than Firefox 3, the ratio of their slopes (FF3/S4) = 2.95. But they both lose badly to ActionScript 3 (running Flash Player 10, RC2), (FF3/AS3) = 6.36 and (S4/AS3) = 2.16. Maybe IE can do better, should we give it a try?

Developer: Now you are being a jerk.

New developerWorks Articles: DWR and Google App Engine

This week, IBM developerWorks published two new articles that I wrote. The first article, is the third of the three part series I did on Ajax toolkits. This one is on Direct Web Remoting or DWR as it is commonly known. I had always been skeptical of DWR because of its RPC nature. However, after doing the article, I have to admit it is a pleasure to use. In the article I used the Java Persistence API (JPA) in combination with DWR. I was very pleased with being able to simply annotate some very simple, vanilla code and create an Ajax service that talked to a database. Ruby on Rails often seems magical to people in its ability to very easily work with databases and simplify Ajax development. DWR shows that you can do some pretty magical things in Java, too. DWR also makes Google Web Toolkit’s RPC code look ridiculous.

Speaking of Google (that is called a segue, if you are keeping score at home) the second article is the first of a three part series on the Google App Engine. I had mentioned some of the work on this here, and now you can read all about it on developerWorks. Of course you can also check out the application developed in the series, i.e. the aggroGator and you can get its source code here.

It's Called Script-A-Cu-Lus

Not script-a-licious! I wrote an article on script.acu.lous and it is now online at developerWorks.

ACM Ajax Seminar

Today I taught a seminar on Ajax to the Bay Area chapter of the ACM. It was a lot of fun. The audience was great, asking lots and lots of excellent questions. The level of enthusiasm was very rewarding. I promised the folks there that I would provide download links. So here they are:

The Slides (OpenOffice format)
The Slides (One big PDF)
All Demo Code

The demo code also includes a Scriptaculous demo that I did not have time for. It uses Ruby on Rails. The Prototype demo uses PHP, and the other ones all use Java. A couple of the demos uses a database, and for those I used MySQL.

Finally I wanted to also thank Sang Shin and Doug Crockford for allowing me to use their material for the seminar.

JavaOne 2008

I've been at JavaOne all week, but not blogging. That is partially because of the horrible Wi-Fi at JavaOne this year. Luckily it is good today, so I am blogging before Josh Bloch's Effective Java talk. I also just picked up the new edition of Effective Java, as if I could somehow read the whole thing before the talk ... Probably should have waited to buy it at the end of the day since I won't be reading it until the train ride home. Anyways...

So what's been good at JavaOne this year? Well ... no big news, really. We see more meat on JavaFX and I guess that was the lead story at the opening keynote. It seems like JFX is about where Silverlight was a year ago. The JVM 6, update 10 does rock. You can do so much more with Java than with Flash or Silverlight, regardless of JFX, so it will be interesting to see if people leverage that.

Along those lines, the most interesting session I saw this week was by the guys from Ajaxian, Dion Almaer and Ben Galbraith. Their talk was titled "What's new in Ajax." The subject matter was interesting, but that's not what made their talk so awesome. They are outstanding speakers, and they seem to have a great rapport between them. Their talk seemed very conversational. It also definitely stood out for NOT having to follow the Sun presentation template. It was a Keynote presentation full of cool graphics, animations, and even some short video interviews with some of the top dogs in the world of Ajax frameworks. 

They also did two cool demos, one with Fluid. I fee like such a nov for not having seen this before. It is awesome. They also did an awesome demo where they "threw" a dart at a dart board. The dart board was an Ajax app running the in the browser. The dart was a Wiimote! They used the Bluetooth connection of the Wiimote to send to the PC, and then bridged the Bluetooth stack on the PC to the browser using (drum roll please) a Java applet. The applet was just for communicating with the OS, all of the graphics were in HTML and the interactivity was JavaScript. Very freakin' cool. 

The other good session I went to was Alex Miller's talk on design patterns. Most of this was stuff I was familiar with, like problems with the Singleton and Visitor patterns. What was interesting to me was that Alex showed how closures could dramatically change the implementation of some of these patterns. He showed this for a template pattern. Both template and strategy patterns are kind of obvious targets for refactoring with closures. What surprised me was how a visitor pattern could be refactored using closures. I was inspired to start playing with design patterns in Scala, since that is the future of Java (in my opinion.) I tweeted this to Alex, and he pointed me to some writings on that exact topic. I still plan on doing my own exposition, as I think it will be fun.

AJAX, the REST Killer

I was at a demo today that was showing off an application that was designed to be a reference implementation / blueprint app. Of course it had some AJAX based features in it. One of the AJAX calls allowed an existing object to be edited, and another would delete said object. I noticed that the AJAX was using HTTP GET. I pointed out to the developers that since this was supposed to be a blueprint app, it should get everything right and use POST for both of these. Of course it should really use a PUT for the update and DELETE for the delete, but browsers just don't support that.

After the presentation, one of my colleagues pointed out that a lot of times we are forced into GETs because of cross-domain calls. He was right, and made me realize how the hack-that-is-AJAX is always rearing its ugly head. Cross domain calls are part of life for any large, distributed site. In an AJAX world you either have to use JSONP style calls, i.e. using a Script tag to make your call, or you have to use a server proxy. Of course going directly to the appropriate domain is much more efficient, so JSONP is going to usually win. There's no way to do an HTTP POST on a Script tag, so there you go. Forget all about respecting the REST protocol.

Of course Flash and Silverlight (gotta include it now!) both allow for declarative cross domain security. No need for JSONP hacks. Now if only they both supported HTTP PUT and DELETE...

TDD Gone Wrong

Last time I wrote about TDD. I read this article from some guy at Spring about doing TDD with the Google Web Toolkit. I have to say this is a good example of how TDD zeal can lead to some twisted thinking.

The article starts by point out how GWT enables RIA development in pure Java. That's a good thing. He then talks about some of the difficulties he's experienced trying to write unit tests for GWT widgets and concludes:

views are usually very hard to test, therefore they should know and do as little as possible ... Most of the GWT code has pretty much all the logic in widgets, so most developers using GWT extend a widget and just add some more logic. My advice is simple: don't go there.

RIAs are all about putting lots of logic in your view. Now it's not just any logic, but view logic. You see there is logic involved in creating a rich user interface and the place for that logic is the user interface. So this guy's obsession with testing has led him to the conclusion that you should dumb down your view code so you can test it. This completely defeats the purpose of using GWT. Very sad.

I think the author does bring up some valid points on unit testing GWT. If you place a huge importance on unit test coverage, then the more logical conclusion is that you should not use GWT. Don't try to dumb down the technology so that you can sleep better at night. Just pick a different technology.

IE Flash Bug

Take a look at this page, and view its source. The key is this little bit o' JavaScript:

function loadSwf(){
 window.location.hash ="mark";
 var str="<embed src='http://gglabs.com/~clg/flash/YouTube.swf'
type='application/x-shockwave-flash' wmode='transparent' height='800'
width='800'></embed>";
 document.getElementById("container").innerHTML = str;
}

What does this do? If you are on IE, then it changes your URL to http://whatever#mark, if http://whatever was your original URL. It then drops a chunk of HTML into the page that embeds a Flash movie. What makes this interesting is if you look at the title. It is not "Test Page" as it should be. Instead it is "Test Page#mark".

This only happens on IE, but on both IE6 and IE7. I'm certain this must be documented somewhere...

Why does this matter? Well it is very common to use hashes to keep track of page history in Ajax apps. For example, in the above app let's say that I write some page initialization code that looks for #mark in the URL. If it finds it, then it goes ahead and loads the SWF. This allows the page to bookmarked and enables browser history (there's actually more you have to do for browser history on IE, but that is another topic.) In this example, we are just loading a page element dynamically, but you can imagine how useful this is for Ajax apps.

So if you are using this technique for managing history/bookmarks and happen to have a SWF on the page, you get crazy page titles. If you think this is a cooked up example, there is actually an example of this "bug" right now on a beta version of a certain high traffic page on the web...

FUD by Doug Crockford

I like some of Yahoo's Doug Crockford's ideas on JavaScript. So I watched this talk by him on the State of Ajax. It has a great buildup on the history of computing and comparing pre-Ajax web apps to the IBM 3270. He's also a clearly opinionated guy, but he really lets this influence his statements. Examples...

He claims that Java applets failed primarily because of "write once, run anywhere" was a broken promise. That's ridiculous. First off Java applets only needed to succeed on Windows, so write once, run anywhere was irrelevant for a desktop technology. He does correctly state that Java UI (AWT) was no good. He commits a lie of omission, by failing to mention Microsoft's JVM infringements. He then says that Java succeeded on the server because (wait for it) write once, run anywhere is not an issue on the server. Not only is this wrong, it's the opposite of the truth. When I first started writing Java server apps in 2000, I was writing it on Windows and deploying it to Solaris.

Next he heaps praise on JScript and says that its "bugs" were just reproductions of Netscape's bugs. There is some truth in this, but it certainly shows his bias. He states that JScript inveted XMLHttpRequest and that there no innovations for five years after that until Jesse James Garret "discovered" Ajax.

He completely ignores Flash. Earlier he states that write once, run anywhere is really difficult and anybody that can pull it off deserves credit. Well Flash pulls it off. He claims that JavaScript pulls it off, but that's just plain wrong. I don't know how somebody who knows JavaScript so well can state this. He's smart enough to know all about doing browser sniffing and conditional logic based on the results of that sniff.

GWT and XForms Series, Parts 3 and 4

The last two parts of the GWT and XForms series I wrote for IBM are up now: Part 3 and Part 4. Part 4 is fun since it is more "icing on the cake" kind of stuff as opposed to the core integration of the two technologies. I really wanted to work in some info GWT's ImageBundles. It's a slick implementation of the CSS sprite pattern.

Continuing down that tangent... I'd like to see an ActionScript implementation of that pattern. It would be cool to take a dozen images in Flex Builder, have it create a composite, and then use that for any references to those images in your Flex application. Of course maybe it's not needed. If you knew you needed those dozen images for your app, you could just embed them all in your SWF. That's going to be even more efficient since you won't have to make the HTTP request for the composite image. Obviously there are advantages to externalizing, since you could change the composite image without recompiling your SWF and without having to worry about referencing a new version of your SWF that's not being cached by users. It also allows for localization of the images. Enough rambling on that topic for now.

New GWT + XForms Series

I wrote a four-part series for IBM on using Google Web Toolkit and XForms together. Somehow IBM snuck part 1 and part 2 by me on their site. The tutorial uses JSNI a lot and touches on some of the latest features in GWT.

GWT 1.4

I recently finished writing a series of four articles for IBM on GWT. You might recall that earlier this year I wrote a two-part tutorial on GWT. The new articles for IBM aren't as introductory, though they don't require a lot of prior GWT knowledge. They're definitely more advanced though. I wrote the articles using the 1.4 release candidates, and then last week 1.4 went final. So I figured it was time to look at how GWT has progressed since the last time I wrote about it.

• Cross Platform Problems -- Hard for me to say how much things progressed. I did almost everything on my MacBook, and things had always worked well on OSX. I did do a little on Windows. I had to do a little more configuration to get it to correctly run in hosted mode than I did on OSX.
• Obfuscation -- Still a problem. Of course you can turn it off, which is good. Still, I pity the fool trying to debug GWT JS in Firebug.
• No Java 5 -- Still a problem. GWT will choke on a List, but String[] is ok. Also, any annotations will choke it as well. So no returning @Entity classes from your RPC services.
• Lots of boilerplate code to write -- Still a problem. You still have to write two interfaces and one class to create an RPC service. Inserting GWT into an existing page is easier, with just a single JS file to include.
• Better build support needed -- This has a improved a little. The ant script that is generated is slightly more useful than the previous version. Still frustrating that there's no build script generated for creating a WAR file. You don't have to use GWT with a Java application server, but obviously a lot of people are. The RPC services require it as well.
• RPC is bad -- Of course that can't change! RPC is still bad. I like how in the documentation, the GWT team mentions two different design philosophies for RPC services. One is to create RPC's specifically for the web application. The other is to have general purpose ones that can be re-used by many clients. Good luck on that last one. That would mean your general purpose services can only accept and return classes from the subset of Java 1.4 that GWT supports.

So that addresses my old pain points. Not much progress has been made. There are some new good points.

• Performance improvements -- Ok, they've really done a good job here. Things are snappy even on a page where you use lots of generated JS to create your UI.
• More Widgets -- Steady progress has been made here. You can get pretty far just using their widgets. I haven't tried out any of the commercial WYSIWYGs built for GWT, but these seem more viable and useful with more widgets. Of course, their widgets are very limited. They definitely aren't components. Compare a GWT widget to a Flex component, for example, and it's not even funny. GWT's widgets are pretty lightweight, but are low in functionality compared to similar abstractions found in similar frameworks.
• Image Bundles -- Very cool new feature. I like how they use CSS to get nice layout of the images from the bundle. It seems like a great way to optimize the static assets in your app. Seems like it might play tricks with a user who wants to right-click on one of your images and do save-as, but oh well.
• Localization -- This has always been there, but it seems better documented and exposed now. Plus there is a command line tool for it. It's pretty nice, though I question the logic behind doing your localization in code that is going to be converted to JavaScript and executed on the client.
  

So all in all, GWT has made some nice improvements and added some new features. They have not addressed the things that are their most blaring weaknesses (IMO), but then again those are probably the hardest things to address. I was surprised though. From my last big write up, I got a lot of feedback from people talking about how these exact issues were being addressed, i.e. that the work was already in progress. Was that really the case?

Let Them Eat Safari

I can't complain about Apple's WWDC being too disappointing, not with it coming fresh on the heels of true disappointment the night before. Still, there wasn't much there. In fact there was only thing of note:

Apple doesn't want to open the iPhone up as an application development platform. Instead they want everyone to build AJAXed web apps (oh by they way, screw Flash, Silverlight, and JavaFX.) To help developers with this, they are pushing out Safari for Windows, so you can easily test your web app against the "same" rendering engine that will be used on the iPhone. In essence, they are trying to push Safari as the standard for HTML/CSS/JavaScript rendering ... Which isn't so bad, since Safari passes the Acid2 test, but I digress.

I know we all keep hearing about how Apple doesn't third party apps causing the iPhone to crash or whatever, but that is just lame and obviously far from honest. I think it is more likely that they have some technical limitations that are preventing them from supporting JavaME or some other standardized runtime, and they are not ready to roll out their own.

So I guess if I want to do map search on the iPhone, I better like using Google Maps. If I want push email to it, I better be using Yahoo Mail. I don't guess I'll be pulling down videos from YouTube or ESPN to watch on the phone.

Of course having a "full" browser on the phone is huge. Apple has to be totally committed to this at this point. Theoretically I can go to GMail directly on the iPhone and get the full AJAX interface we all know and love. Maybe there is some way to have it run in the background so I can get the email pushed to me. Of course I still can't go to Yahoo Maps, since it uses Flash ... Ditto with YouTube... Also, Outlook Web Access works ok on Safari, though it's not going to provide push email like the IE version would (or like you would get with a Blackberry.)

So does any of this matter? The most significant thing is that one can expect that support for Safari just became more important web developers everywhere. Not a lot more important, but at least a little. I don't think Microsoft or Mozilla have to worry too much about IE/Firefox users switching to Safari. It's big draw is speed, and Opera was already way faster than IE or Firefox. Plus it's got a lot of issues...

Flex Stocks Updated

I tweaked the Flex version of the Stocks app. I cleaned up the UI to make it just plain ol' white. I also integrated the HTML "host" page for the SWF file with the WAR and the source. So here it all is:

• Deployable WAR -- Drop it into to your web container and go to http://localhost:8080/Stocks
• WAR Source Code -- Unzip it and import into Eclipse
• Flex Source Code -- Unzip it and (hopefully) import into Flex Builder.

Enjoy!

I'm thinking of refactoring the original GWT app to use the exact same code as the code used here. More on that later.

Flex Stocks

As planned, I re-implemented the Stocks application from the first GWT tutorial using Adobe Flex. Here is a link to a short document I put together outlining the code and the interesting parts. It also has links for downloading the code I wrote.

It was really pretty easy to do this. Of course this was a pretty simple application. I might try to re-implement the advanced version of the Stocks application from part of the GWT tutorial. First, I'll do the easy one in Silverlight.