Hypothetica

You’ve probably seen this popular feature on various search engines: As you enter your search criteria a drop-down list of suggestions appears. The way this works is that the page has a bit of javascript in it that makes AJAX calls back to the search server every time the text in the search box changes.

Now what about applying that to textarea fields such as those used to enter the body of your message on a forum? Only there’s no user-feedback. The characters you type are simply stored into the database along with your post. An admin could then replay your message entry, including the bits where you went back and deleted or corrected bits of your post before finally submitting it. Let’s say you make some comments or share some feelings that, before you hit the submit button, you think better of and delete. But they’re not deleted. Not anymore. They’ve been saved. Content you never intended to share is now in the wild.

What if we take this to its logical conclusion: a keylogger embedded in your web site. Maybe you start typing in the credentials for your e-mail account by accident, delete them, and type in your forum credentials before finally hitting submit. Or maybe you lose track of which window on your desktop has focus and you start to type your password for your e-mail account into a web page that doesn’t even have a single text input field?

And all of this would be sent in plaintext from your computer to the web server, allowing anyone inbetween to see this as well.

Is there a line here? Is it being crossed? Do you think it’d be okay to grab the data from, say, a person as they were creating their forum post, but maybe the wholesale keylogger is wrong? I wonder what the legal implications are here. Can you really have a reasonable expectation of privacy if you’re creating content that would be publicly available on the internet?

I would suspect infrequently visited sites wouldn’t get much out of such a system to begin with. But imagine a forum that might have 1,000+ users hitting the site weekly. I bet they’d get some “interesting” stuff every so often.

Which is why the paranoid among us will want to at least find a plug-in for their web browser to disable javascript on untrusted web sites, if not disabling it entirely.

Just about moved in.

There was a hiccup during the first attempt at importing my old WP blog into this one. An admin reset the import and I gave it another go and things seem to be going much better.

A couple of things worth noting. First and foremost is to be sure that you delete all the spam comments from your WP blog before exporting it. Eight of the nine megabytes of XML data in my WP export file were spam. This, I’m sure, greatly increased my chances at a successful import.

The other thing I found is that the wordpress.com admins seems to be responsive and willing to help. That’s pretty cool.

I started looking through the available templates for blogs on wordpress.com, but was only given about 70 choices and none of them appealed to me. I then, by chance, found one I did like in the section that displays a group of random templates under the page where you pick a template for your blog. It appears that the templates listed and searchable are not representative of the full library available. So if you’re on wordpress.com or thinking about moving to it, try that random feature a few times. You might find something you like that isn’t in the regular list of templates.

One thing I’m annoyed with is you have to purchase the option to alter the CSS of your blog. The lack of <code>overlfow: auto;</code> on <code>PRE</code> elements is annoying me at the moment. It seems like such an obvious and simple tweak to this template. But if I want to do that I have to pay $15.

Moving In Progress

Just uploaded a 10mb export from the old blog site to here. WordPress tells me that it’s still processing the import and it’ll take up to 24 hours for it to complete. In the meantime I have posts from 2004 and 2005 in here… somehow.

So please be patient. Once this is over I’ll probably talk a little about what it’s like moving to wordpress.com and what, if any, problems I encountered.

Moving?

I will probably be moving this blog soon to ruthsarian.blogspot.com ruthsarian.wordpress.com. This blog server was always a test server of sorts and it appears a decision is finally being made that the college should not support the blogging activities of its faculty or staff. Therefore I’m going to make the move to a different blogging service. Why Blogspot? No reason in particular; just that it’s tied into Google and I already have a Google account. Although Google gets more evil by the day.

EDIT: Trying to convert from WordPress to Blogger, even using Google’s own Python-based utility, was too much of a headache. Converting from WordPress to WordPress seems a far simpler solution. Plus I prefer WordPress’ administrative interface.

Search Interface

Several site operators, especially those I’ve talked to who also work in Higher Ed, have found that users (typically students) use their search function a majority of the time over drilling down into the web site to find the information they want. This is true of both first-time and veteran users.

This begs the question that if users are ignoring your navigation and opting for the search engine,  should web sites just have a search box on their front page (think Google). A single text input and a search button and that’s it.

Sub-page navigation would be similar; a text input bar along the top that, as you typed in your search string, would display suggestions. This is not unlike Google or the search box in Firefox 3.

It’s an interesting idea. You save a ton of page real-estate. You cater to the individual’s needs rather than trying to guess what they need or how they will perceive the structure of your web site. As long as the user perceives entering text and clicking on the links that appear as more efficient than trying to drill through your navigation scheme this sort of thing would work rather well.

There are, of course, a few drawbacks.

The first is that the traditional search engine would not be able to crawl your web site to index it. You could perhaps add some code that detects search engine bots and produces a site-map (maybe dynamically created).

Users with disabilities may have problems. I’m not certain a blind user would find it convenient. And users that have problems typing would find the interface very difficult.

You could perhaps address both issues by including in your web page a static navigation element that is hidden in such a way that screen readers and search engines will catch it, but regular users will not. Or you could allow users to make the menu appear by mousing-over or clicking a button.

Users who have Javascript disabled may not get the suggestion list, but they could still type in what they want and hit search like a traditional search engine. It just adds an extra step for them, but does not break the functionality of the web site.

The usefulness of such an interface on mobile devices is debatable. While the interface itself would be very small and fit nicely on a mobile device, the user will be forced to type the word or phrase they are searching on. This may be a bigger burden than simply scrolling and clicking on a navigation link or two, but on very deep sites this would probably be an easier interface.

I think the idea is deserving of at least a test implementation.

But perhaps I’m missing some key idea or concept that makes the whole idea break down. Please share any ideas or thoughts you might have.