K-State Libraries: Digital Initiatives

Docs to Blogs

There's a new, simple way to get documents created by a word processing application (like Microsoft Word) posted to one of our blogs on TypePad, without the usual formatting nightmares or cut and paste headaches.  All you need is a Google account and access to Google Docs, and the steps outlined below.

1. Login to Google Docs
2. If your document is saved elsewhere, upload it using the "Upload" button near the top left of the Docs screen, just under the Google logo.   You can upload documents in .txt, .doc, .html, .rtf, .odt and .sxw formats.  It will open for editing after it is uploaded.
3. If your document is already in Docs, just open it for editing.
4. Find the "Publish" tab in the upper right corner and click it.
5. On this screen, you have two publishing options.  You are interested in the 2nd choice - publishing to a blog. You'll need to set up options the first time you do this, so click the setup link ("set your blog site settings")
6. On this page, you'll pick some non-intuitive things, so follow along (click the tiny thumbnail for a screenshot):
   1. Click the radio button for "My own server/Custom"
   2. Select "Blogger API" from the API dropdown
   3. Copy and paste this URL: http://www.typepad.com/t/api/xmlrpc.php  into the URL box
   4. Enter your TypePad userid and password in the boxes, and the name of the blog to which you're posting your document.  Make sure you enter the full name exactly as it appears on the blog, for example, "K-State Libraries: Talking in the Library", not just "Talking".
      
   5. Click OK.
7. The settings box will disappear, click Post to Blog to post your document.
8. Click OK in the confirmation box that appears.
9. Go look at your blog and see how cool it is!

If you're a multiple-blog author, just edit the settings to change to a different blog before you publish.  Another neat thing you can do is edit a document you've already posted to blog from inside Google Docs. Then, when you go to the Publish tab, one of your options will be to re-publish the previous post with the new document - handy for fixing typos or updating information!  The only flaw I've found so far is that it seems reluctant to assign a title to your post based on your document's name - you may need to login to Typepad and assign a title to your post, but that's a small price to pay for the convenience of directly publishing documents you've already created.

E-Journals key matches removed

I removed the key matches (about ten) from the Libraries' interface for the search appliance today that pointed to the e-journals page. There were about a dozen or so of these, which would toss up a link to a category on the e-journals site when a given subject word matched, e.g.- literature or accounting. They ceased working properly a while back when we went to the new version of the A-Z list, which I just noticed and no one had reported. I don't think these links will be all that missed, and I'm convinced there's a better way to do this which I'll explore if demand for the links ever resurfaces.

In their place, I added two key matches (for journal and journals) that link to the main page of the A-Z list.

Who or what is big oscar, and should I be afraid?

Big oscar is a subdomain at AOL, specifically:

http://big.oscar.aol.com/

We make use of a small service offered by AOL, namely, the ability to toggle images for our chat application based on the status of our AOL login. When a page loads that uses this functionality, such as:

http://www.lib.k-state.edu/reference/vref/

or any of our catalog search pages where one finds a Meebo chat widget (or, more accurately, a picture of one), before the image of the chat widget loads, a little query goes out to big oscar, who either says, yes, the library account is logged in, in which case the "click to chat with a librarian" image loads, or no, which loads the "no one available" image. This is completely benign, and in no way poses a security risk.

Why bring this up? If a person uses Internet Explorer and cranks their security settings way up high, IE will flash a warning when this query gets sent to big oscar. Personally, I don't want to use a browser that's such a namby pamby about this kind of stuff (which is why I use Firefox, which applies a lot of common sense security fixes without being so annoying), but some people have been burned or otherwise convinced they need ultra-high security on their machine. Not much we can do there other than tell them to allow it.

Bored in an airport, no wireless

Back in October, I was headed to Victoria, BC for Access 2007 and had a layover in Seattle. Alas, as with most major airports, they wanted some heinous sum for wireless access. While killing time, and somehow not in the mood to read anymore, I thought, hey, let's see what ports and protocols they block. Turns out that as a commercial service, anything fun was blocked, but I was able to use boring command line commands like ping and tracert.

I sat there for the better part of an hour firing off tracert commands, and found some interesting stuff, well, not really interesting, that's an overstatement. The question on my mind was whether A Small Orange's slow response times (from the K-State campus) are their fault, or the grid's fault. Well, as you can see in this  oh-so-cryptic document , it's a function of hops that lie beyond their control. From Seattle, A Small Orange was 'closer' (i.e.- faster) than K-State's network. It's likely because the airport uses AT&T's services, as does small orange, so there's not much buck passing between Seattle and Atlanta. With K-State, you see it smack up against Cox and kanren routers that play a little tennis with the packet before sending it on to its destination.

We're talking milliseconds here, of course, and I'm the furthest thing from an expert on WANs. I understand tracert to some degree, however, and the number of hops, and the lag time at a hop, means any data going back and forth is subjected to the tennis games that go on.

Yes, I'm a dork.