Autocomplete was one of the first Ajax patterns to come about. We often talk about how it looks, but the how it works part is what really matters. How smart is the algorithm to work out what you are completing against? How long do you go before you kick in to see a result? Does it narrow enough?

László Kozma wrote up his thoughts on Reverse Autocomplete which talks about helping the user as they change their mind during autocomplete, and being away of what they are doing, instead of just using field.value as an absolute. He acknowledges that he isn’t the first to think about this, but there are some good ideas.

First, he shares a couple of use cases of the problem, such as:

I enter “German football team” in Google Suggest, then I change my mind and go back to change the query to “Italian football team”. Autocomplete doesn’t help me with this. Even when I entered “Italia| football team”, (the | sign shows the cursor location), autocomplete doesn’t do anything, as it doesn’t look to the right from the cursor. For the record, “Italian football team” is a frequent query, if I type it normally from the beginning, as soon as I get to “f”, Google Suggest knows what I want. Google Suggest seems to look at the text as a whole, trying to autocomplete to the right, ignoring the cursor.

In the browser I typed “mail.yahoo.com”. Then I want to go to “mail.google.com” next. Even though “mail.google.com” appears in the history, when I correct the middle part, such as to “mail.g|.com” or even “mail.googl|.com”, the autocomplete is clueless. Again, the same behaviour as before.

I typed “jenny@fictivecompany.com” in the e-mail To: field. Now I go back to change it to “jennifer@fictivecompany.com”. Even though this address is in the address book, “jen|@fictivecompany.com” does not activate the autocomplete. This problem is similar to the previous one, but in this case space and the comma can both be considered a separator, as the boundary for autocompletions.

And his solution:

The solution is to simply take whatever method there was to search for the text before the cursor, and use it to match the text after the cursor as well. If a prefix tree is used, it is convenient to store the text to the right in reversed form for easier search. Most of the time the text after the cursor will be empty, so there won’t be much overhead. When the cursor moves back, simply match the text both before and after the cursor, and only do autocomplete if something matches with both sides.

This example implementation in javascript is based on AutoSuggest v1.0.
I modified the code to perform the reverse search as well. Both the original and the modified version are under LGPL. For the cursor location code I modified this script. As this is just a user interface proof-of-concept, I don’t recommend using the javascript code as such, as it is not more than a quick hack.

Text left and right of the cursor is shown for more clarity. Note that I didn’t use any of the complex data structures mentioned, all we have is a simple array, as can be seen from the source.

Remy added live searching and direct linking.

For example, if you type in “c” it gives you all the HTML entities
that look a bit like a letter “c”. These include: ¢, ©, ç,
⊆, ς

Imagine that. Something that actually tries to help.

The article talks about his reasoning behind filtering vs. alternatives like Live Search, and ends with a Live Filter demo.

Implementation

Many of the concepts in this article would be very difficult to implement without Ruby on Rails. Rails introduces the concept of Partials. Partials are nothing more than snippets of fully formed XHTML which get inserted into the innerHTML of objects in a browser’s DOM by JavaScript. The specifics of this process are outside of the scope of this article. While you can update the innerHTML of a DIV or SPAN using any Ajax-capable scripting language such as PHP, there is an architectural elegance that enables this filtering system that we believe would be difficult to replicate.

Implementing a filter system that works across all common browsers is a real challenge, full of gotchas and necessary hacks. While nothing here is offensive, you might be surprised at how involved it can get. The reason being that it is of paramount importance to maintain the function and behaviour of the browser’s built-in Back button.

There are two main issues to solve. First off, if you modify the contents of your DOM with Ajax and JavaScript, move to another page, and then return to the form submit page, each major browser seems to corrupt the state of elements on the page in subtle and different ways. For example, Firefox will corrupt the selection state of checkboxes generated at run-time! The second problem is that if a user returns to the search interface with the Back button… what is the user going back to? Suddenly our flow diagram just got a lot more complicated!

The first revelation is that you should be prepared to write client-side functions to persist, restore, and clear the visual state of your filter. When you render the interface, all of your elements will be in their default state. During your document’s onload event you will want to execute an initialize function that can then “hydrate” the state of your elements from a hidden form. Likewise when submitting a query, you will not want to process the data associated with the form elements you see. Instead, “de-hydrate” the state of your interface into data on a hidden form that can be easily passed on.

During the initialization process, you will need to generate a new key value that could be assigned to a query request should one be submitted. You will use this value to build the action attribute of the hidden form that they might submit! This does need to be performed dynamically, in case the user has returned to a previously rendered page with their back button. Browsers can simply not be trusted to clear their page caches, no matter how many META directives you push down in your HTTP header.

One behaviour we’ve evolved while iterating this filter pattern is to remember the state of the last search when returning to the search page via navigation — unless the user specifically clicks on a major site navigation link to go to the search page. We interpret this behaviour as expressing a desire to start a new search from scratch. You’ll want to experiment and see what feels right for your project. These sorts of decisions are subjective and might change with feedback.

The Logahead blogging engine offers many of the regular features that blogging software provides, but has been reworked to make it simpler – ease-of-use is key. To achieve this level of simplicity, the entire blog can be maintained directly from the homepage, logins/protected content and all. They support tagging for each entry, draggable/sortable widgets for the sidebar, an “admin toolbar” that loads when an authorized user logs in, inline post adding and editing, livesearch, RSS feeds, easy text formating, and much more.

Most importantly, you can check out a demo of the app here.

You can get all of the deatils on the software at their site, including support and a forum to interact with other Logahead users. Currently, the download is a beta version (version 1.0), and requires PHP and MySQL to get up and running.

Note that there is a referral code for MyBigRiver appended to the links provided, which you may want to strip out to append your own if you are in the Amazon associates program. I think Jeff could provide more value if he allowed users to append their own referral id, but he is the creator so he can certainly monetize it how he likes. I’ll stick with wp-amazon until there is a nice option to store my own referral id so I don’t have to edit the generated urls by hand.

It does a nice job of running searches in the background, and constantly letting you know where you stand, and the progress.

At the end of the job, it even comes up with Flash dials to give you a context to your “ego points” which don’t mean much as a number.

This community surrounds Alcohol, and shows you why Web 2.0 is here. We need to make things easier for alcoholics to use the web!

There is definitely room for more Ajax on this site, especially around the collaboration features.

You can see live information about all flights that are going on, narrowing in on particular flights, or airports.

There are numerous ajax features, including a lot of live search features.

One interesting UI choice is telling the user “keep typing, I need more information” on the live search side. This is in comparison to doing a live search with one letter (too many results), and not showing anything until the magic number of letters is typed (e.g. three).

Oh, and it’s kinda fun to just click around and see what is going on up there :)

Then we saw Yahoo! Instant Search, which was ok….

But now we have the best of both worlds, with a sleek Son of Search: Inquistor Instant Search.

It gives you both “are you looking for” info a la Google, and search results a la Yahoo…. but for each search!

It looks like Apple designed this puppy doesn’t it? :)

It differs from Google Suggest in that it isn’t queries that are shown, but actual search results.

When I played with it, it was a little hard to know when it was going off and doing things, and the results were average and too few.

Why feel lucky when you can be right? With Instant Search, find the information you want — without even hitting the search button. Results instantly appear for Yahoo! Shortcuts and common searches.

Full Feature List

• We can still produce any HTML, in stead of fixed table-rows
• We now have XSLT support!!! I’m really happy with this one. It allows to have
  any xml source as dataset for the grid. Just before it gets placed into the grid for viewing, you can do some xslt magic on it. Just have a look at the source of the yahoo demo to see how it works. This demo will take the literal html of the yahoo-api and gets parsed by our own xslt.
• Auto-size. the livegrid can automatically do calculations and resizing if the grid is empty on forehand. This way your HTML page doesn’t need to know the exact row-size that will be returned by the
• Instead of keeping a set of rows in the buffer, we keep the xml-source in the buffer, and any newly loaded source is merged with the first one. For merging that is not-standard, you can specify an xpath to select the rows that should be buffered & used for display.
• And ofcourse, last but not least, the reason why I started the fork in the first place: the scrollwheel support!

Source and Downloads

• The grid’s javascript
• The most basic demo, loads html through ajax
• The serverside script that delivers the HTML for the simple demo
• The yahoo demo!
• The yahoo xslt
• the prototype script that is required

It is very easy to use:

You only have to use a simple JSP tag:

<layout:suggest suggestAction=”/getCountrySuggestions” key=”Country”
styleId=”countryField” value=”" />

where “/getCountrySuggestions” is a Struts action in which you instantiate a collection containing the results matching the typed word.

You can easily custom it:

You can use different skins, set the maximum number of returned results, set the timeout or the minimum number of typed characters before getting results…

How to use Suggest field:

Read the tutorial: http://struts.application-servers.com/suggest/index.html

More about Struts-Layout:

Struts-Layout is a tag library for struts which provides easy and fast interface
creation. This is achieved by powerful tags which display panels, input fields,
tables, treeviews, sortable lists, datagrids, popups, calendars, etc. With those
tags, the developer have neither need to write nor even know HTML.

Struts-Layout website: http://struts.application-servers.com/

You can find an online demo

( via François Goldgewicht )

It will be interesting to see their next components are.

If you’re doing Ajax on PHP, you can learn how to implement Google Suggest by reading Quentin Zervaas’ article:

I’ve just published an article on my PHP article site about
developing a clone of Google Suggest using my AjaxAC framework…

The article is at:
http://www.phpriot.com/d/articles/php/application-design/google-suggest-ajaxac/index.html

They have added some nice ajaxian components to help you select tags for content. It is nice for them to show you what others have tagged, as it will probably help the community from using different names for everything, which makes it harder to grab info. Ignoring plurals and the like would be nice too :)

Post something to your del.ico.us account to see it in action.