The script, which uses jQuery and is currently only usable for one field at a time, takes the select element (via its id) and loops through its option elements. For each option, its backend (the value=”" part) and visible (between the option tags) values are read into an array, and the select element is replaced with a hidden field and a text field. Entering text into the text field triggers the suggestion script, which matches the entry against the list of options (using both backend and visible options), and builds a list of the matches, with most likely matches at the top. Once the suggestions list is built, the script displays the top options in a google-suggest-style box directly beneath the text input. The number of suggestions shown is customizable, with values between one and unlimited (value of 0). Once suggestions are shown, they can be navigated using the up and down arrow keys, and selected using the enter key. Unfortunately, I haven’t been able to capture the enter key for this action, to prevent the form from submitting. As such, using “enter” to select the highlighted option will submit the form. Suggestions can also be selected using the mouse, complete with hover effects.

If the field is blurred (that is, the cursor leaves the field, such as with the tab key), then the script tries to choose the most likely option. If the field is blank on blur, nothing is set. If a suggestion was selected with the arrow keys or mouse before the blur, then that option is set as the value. Otherwise, the top suggestion in the list is selected (in the case of tabbing through the form: tab in, type two-letter state abbreviation, tab out).

When an option is selected, the input field’s value is set to the option’s visible value, and the previously mentioned hidden field is set to the option’s backend value. This method is used to retain the aspects of dropdowns: present the user with human-readable data, but use computer-readable data in back. That, and it makes it so you can use the same server-side processing script (and/or client-side validation script) for both JS and non-JS users, since the hidden field inherits the select’s “name” field (the text input doesn’t have a “name” field).

Like I mentioned before, this script is not limited to State dropdowns. Any dropdown list will work, but I would suggest you only use it in cases where the field’s values are already known to the users (”Select package” is not a good place for this!). Just provide the script with an ID, and off it goes.

Oh, and each line of suggestion is customizable via a simple template parsing bit .

Anyway, check the example out: replacing a State dropdown and replacing a Country dropdown. All the code (other than the jQuery include) is on that page; the javascript at the top is pretty well documented. Feedback and suggestions are most welcome.

Now. Taking a step back, let me ask a question. What is the purpose of ads (AdSense ads in particular)? For most legitimate cases, the purpose is to enhance a page’s content with topic-relevant alternative links, with the main incentive of earning a few cents per click. Note the word enhance, meaning “to add value to”. You put ads on your site in the hopes that the links provided will provide enough potential quality that the user will click through. Now, another question: what do videos, the marketing tool of the Information Age, do by their very nature? They grab your attention, and they grab it hard! Have you ever found one specific video on YouTube, watched it, and immediately been pulled in to the “related videos” journey? Mm-hm. Guilty as charged . The “traditional” (if I may use the word here) ad system is to place a text block (which is easily skimmable, by the way!) within our content, where it sits quietly by in the hopes that some user may grace it with a mouse click. This new version? GRAB the user’s attention away from the main content, and perhaps they might click the overlay ads in the process. These video ads, as big as they are, will steal the limelight from your content, if not placed appropriately. Really, I don’t think the current sizes have an “appropriate” placement. You can either place them intrusively up front where they steal from your content, or you can place them out-of-the-way (long after your content) where they’ll hardly be noticed.

Now, you’d think that’s great, right? Grab their attention straight to the ad unit itself, no trouble? Well, it might be, if the overlay ads themselves were noticeable. I just added the mini player to my blog and played the first video on it, and the overlay ad was so annoying and detracting from my video experience so badly that I quickly hid it. That’s right, there’s a “close overlay ad” button. It reduces the entire money-making mechanism to a little “show ad” button in the bottom-right corner of the player. Now, how many people do you think, after having hidden the ad that was so darned annoying, will re-open that same ad to see if they want to click it? Certainly not me. I have more content to look through, and better things to do with my time.

Come to think of it, I might not even press the play button.

Circular menus are superior in usability to the typical rectangular slide-out menu. Why? Because, ideally, each menu item is the same distance from the initial pointer position as each other item. Look at the iPod buttons, for example. Play/Pause, the most common function, is in the middle, and the other functions are equal distances from there.

Also check out the SecondLife context “spin menu”. The pie pops up surrounding the cursor, and all the available options are an equal twitch away from the center.

Submenus? Just expand the circle. For example, here’s a quick mockup I made converting much of my current FireFox context menu into a pie menu:

But how feasible would such menus be inside a website? WebToolkit.info has a mostly-working demo that uses images exclusively. I tried substituting text for the images, but the menu simply disappeared.

Credit for image: iPod image and SecondLife image

The last two times I’ve seen it used were in articles about creating a tableless photo gallery and making a CSS block nav menu. In both instances, the br was used to drop down the descriptive text to the next line. In both instances, a span surrounding the descriptive text, and with its display set to block, does the exact same thing.

I suppose an argument could be made about users with CSS turned off. In my opinion, though, if you have CSS turned off, you’re willing to deal with a few minor inconveniences. If you’re that worried about them, throw in a space before the span for readability. And if you really insist on giving them the extra lines of text — there’s always the naturally-block-level <div>.

And what about screenreaders? I doubt they’d be affected either way (it is whitespace, after all — right?), but I really have no clue. Perhaps someone who uses a screenreader could tell me, after chewing me out about my own blog’s (actually Blogger’s) screenreader-friendliness.

Since its inception, the web has been evolving.

In the beginning, there were marked-up files, with the sole purpose of spreading information. Files linked to each other using hyperlinks. Pages were made up of static HTML — with a strong emphasis on “static“. Websites were merely a collection of rarely-changing information. Rarely-changing because…well…because, put simply, they were static.

Enter Server-Side Scripting. Wonder of wonders! Intelligent pages, able to adapt, to learn, to store and retrieve information! Pages could be made easier to update, easier to maintain, and easier to modify. Website owners and visitors alike could create accounts, and later log back in to those accounts to retrieve information they had saved on previous visits.

The world of static pages, difficult maintenance, and ad-hoc special effects has been dubbed the “Web 1.0 era”. The focus of the web was information, and information was served.

As dynamic server-side languages gained popularity, people created websites that slowly evolved into communities. Web 2.0, we called it. The focus shifted to the people, and the people were served.

And now where are we? “Well, nothing revolutionary has come along, so we must still be in Web 2.0″. I would disagree. In a recent article on IndustryInteractive.net entitled “Facebook has failed us“, the author states:

1. Facebook is great at connecting people. [...] I was able to find people I went to elementary school with, identify them, and connect.
2. Facebook sucks at playing well with others. There are Facebook Apps to integrate things like Flickr and del.icio.us, but they really blow, and why isn’t Facebook building that functionality right in anyways? [...]

While I won’t say how great or how horrible Facebook is, it seems the focus of the web is shifting — or already has shifted — away from people, and more towards services. With “web applications” like Google Docs, Flickr, Netvouz, GMail, and Google Reader, web-based computing may not be that far off. Already, most of the functions we perform on our computers can already be done through our favorite web browsers — even BitTorrent downloading!

People don’t expect information or community anymore — those are a given for any good website. What people expect in this new day and age is integration of services. Can I inject my Del.icio.us bookmarks into my blog feed? Can Google Docs post this document to my Blogger blog? Can I integrate my Flickr pics into my Facebook profile?

With the shift of focus to services, it’s possible we may already be in a kind of Web 3.0. Or perhaps not — perhaps we are only in Web 2.5, the middle grounds between people-focus and service-focus. After all, there was a Web 1.5: the middle grounds between information-focus and people-focus, when those good ol’ dynamic web languages were still picking up support.

What the heck, I can still come up with ideas, right? Google didn’t turn up much inspiration, so I started thinking on my own. Here’s what I came up with.

QuickMail, a lightweight mail app, designed for those who don’t have time to deal with bulky webmail interfaces (am I right, AOL users??). It should support as many mainstream mail services as possible. It should have a clean, simple interface, with little or no bells or whistles. It should be built for speed (both runtime and download time).

Upon entering the site, the user is presented with a login panel, which contains a dropdown with available services, username and password fields, and out-of-the-way links to an about page and other pages that might be accessed before “logging in” (perhaps a “donate” page to pay for hosting, maintenance, etc). Ideally, this panel will be presented as a blackbox-style overlay, to prevent the need to wait for an extra page refresh after logging in.

Once “logged in”, mail will be fetched from the user’s account (probably through AJAX) and displayed (unread mail only? both read/unread? will there be options?). No registration is required for QuickMail, only the login credentials for the specific service are needed. The user should be able to choose whether or not the app autochecks for new mail (for slower computers, to avoid the constant background JS that would be required), and there should be a button for checking for new mail, regardless of whether autocheck is on or off.

Credentials should be kept only on a per-session basis; the user should be able to simply exit their browser without fear of being “hacked”. Most likely, this will involve avoiding cookies, probably keeping the credentials as JS variables.

A mail search function would be nice, though it would be an extra feature, to be implemented after the core functionality is stable.

With this kind of setup, you could type “qm.com” or similar in your url, choose your service, enter your credentials, and read your email, all in the 15min between classes ok, maybe not that snappy, but close enough. Once you’re done, just exit the browser (or tab) and don’t worry about logging out (since you were never really “logged in” to begin with).

So, what do you think? Would you use this? Is it feasible? Anything I missed?

If you think you can implement it, fine, but I’d love to be in on it. If not, feel free to leave suggestions in the comments