(Jan '08) This is a basic character table which shows you the 8-bit ASCII characters, plus all the other little-known characters that have HTML entity names (305 characters in all). But it also has a twist: When you copy a character to the clipboard, your choice is recorded on the server in your personal history list; plus it tallies statistics on the most popular characters overall, recent characters overall, and—if a character's been chosen before—"people who chose X also chose Y".

Limitations
In Firefox, we run up against a Mozilla security feature. It doesn't let you programmatically copy text to the clipboard - so when running under Firefox we don't show the user a button to copy it; the best we can do is to show them the entity name and explain how to copy it over manually. This also means we cannot gather statistical information from Firefox users when they use a character. (We could gather statistics when they click on a character to see its entity name, but I figure people are likely to click on a lot of characters they really have no use for. It's only meaningful when they go to use a character.)

About this Firefox security feature: Firefox doesn't allow a script to copy text to or from the clipboard. Now, I can understand why reading the clipboard's contents should be forbidden. That would be a huge security hole - who knows what the user has put there recently? But Firefox goes one further: They don't let a script put anything into the clibpoard either! This makes no sense to me. Where's the risk there?

"People who chose this character also chose..."
Perhaps this feature should be called "click similarities". Or not.

I have no idea what the best-practice algorithm is for implementing this feature, so I came up with a quick & dirty method. When a user copies a character to the clipboard, I search their history for the last 10 characters they copied before (that are different than this new one). For each previous character, I increment a hit counter in two records in a "chars_x_chars" table: One that says the current character is related to the previous character, and the other says that the previous char is related to the new char. (NOTE: I later realized this is redundant. The Unicode character table only writes out one record for the relationship.) Think of a 305x305 matrix - the rows represent each possible "this" char, the columns each possible "previous" char. For this project, this means a 93,025 element matrix.

Theoretically this algorithm uses memory at a rate of O(n²). But since we're storing this information in a database, we only save the character combinations that have occurred at least once - making it effectively a sparse array. So if most of the possible combinations of characters never get chosen by people, its impact on the table size should depend more on the total number of choices made instead of the universe of all possible character combinations. But as more people use the character table, more & more combinations will end up occurring at least once, and if the page becomes popular the total size of the chars_x_chars table would indeed approach 93,025. This approach is fine for small datasets, but would it also work with large datasets - like an online catalog, or even my Unicode character table? (55,633 x 55,633 Unicode chars ≈ 3 billion records in the table. An online catalog of 100,000 SKUs = 10 billion records. Whee!)

There is one possible saving grace with this algorithm: With a huge dataset (of characters, SKUs, etc.), it's much less likely that all the possible combinations will actually get chosen by people. Perhaps the larger the dataset, the less likely you're going to hit the wall at O(n²) performance in the first place. I'm not a mathematician, so I'll have to wait for the site to get widely used and see how real-world performance gets impacted.

The Combobox
I created the combobox class to let the user pick a font from a dropdown listbox, but also to be able to enter in any other font name they wanted to see as well. This has proven to be a very useful standard control in the world of Windows apps. I assume Mac users have something similar. Every web developer should have one in their toolbox.

AJAX
This was my first AJAX project. I wrote a simple BasicAJAX class to handle the conversation w/the server. (There are lots of good AJAX libraries out there by now, and I'm sure it would make more sense to just use a mature AJAX library in a more critical environment than this site. But I did give this class a nice, simple API, and it works well.)