Bret Victor offers the above design suggestions (from 2006) to Amazon in the book search results display (he’s comparing to this). I didn’t discover them at the time, but many of them are still relevant now. Bret notes that Amazon’s display doesn’t do a good job of answering the questions a person has when searching for books: “What is the book about?” and “is it any good?”

Unfortunately, these questions are completely unaddressed by the information provided. To see relevant information, the user must click on each listing individually. That is, she must navigate by hand instead of by eye, and must use her memory to compare information across time instead of space.

The problem is that this graphic was designed as an index into a set of webpages, but is used as a catalog for comparing a set of books. The purpose of this graphic should not be to return a list of query matches, but to help the user learn about books related to her topic of interest.

Amazon calls it CloudFront, and it costs $0.17 – $0.22 per GB at the lowest usage tiers. It seems that you simply put your files in an S3 container, make an API call to share them, then let your users enjoy the lower-latency, higher performance service.

Their domestic locations include sites in Virginia, Texas, California, Florida, New Jersey, Washington, and Missouri. Internationally, they’ve got Amsterdam, Dublin, Frankfurt, London, Hong Kong, and Tokyo covered.

Via an email from the Amazon Web Services group today:

…we are excited to share some early details with you about a new offering we have under development here at AWS — a content delivery service.

This new service will provide you a high performance method of distributing content to end users, giving your customers low latency and high data transfer rates when they access your objects. The initial release will help developers and businesses who need to deliver popular, publicly readable content over HTTP connections. Our goal is to create a content delivery service that:

• Lets developers and businesses get started easily – there are no minimum fees and no commitments. You will only pay for what you actually use.
• Is simple and easy to use – a single, simple API call is all that is needed to get started delivering your content.
• Works seamlessly with Amazon S3 – this gives you durable storage for the original, definitive versions of your files while making the content delivery service easier to use.
• Has a global presence – we use a global network of edge locations on three continents to deliver your content from the most appropriate location.

You’ll start by storing the original version of your objects in Amazon S3, making sure they are publicly readable. Then, you’ll make a simple API call to register your bucket with the new content delivery service. This API call will return a new domain name for you to include in your web pages or application. When clients request an object using this domain name, they will be automatically routed to the nearest edge location for high performance delivery of your content. It’s that simple.

We’re currently working with a small group of private beta customers, and expect to have this service widely available before the end of the year.

Ryan Eby got me excited about S3 a while ago when he pointed out this post on the Amazon web services blog and started talking up the notion of building library-style digital repositories.

I’m interested in the notion that storage is being offered as a commodity service, where it used to be closely connected to servers and bought (and wasted) in chunks. With S3, you can build a simple application that runs anywhere, store your big data in S3, pay for what you use, and expand (or contract) as you need to.

It’ll take a while but this could really change our application and system design. I’m just interested in seeing what comes of it.

amazon, amazon web services, aws, commodity service, internet applications, ryan eby, s3, simple storage service

Paul Bausch has concerns about Amazon’s Mechanical Turk:

I can imagine a world where my computer can organize my time in front of the screen better than I can. In fact, I bet [Amazon's Mechanical Turk] will eventually gather data about how many [Human Intelligence Tasks] someone can perform at peak accuracy in a 10 hour period. Once my HIT-level is known, the computer could divide all of my work into a series of decisions. Instead of lunging about from task to task, getting distracted by blogs, following paths that end up leading nowhere, the computer could have everything planned out for me. (It could even throw in a distraction or two if that actually increased my HIT performance.) If I could be more efficient and get more accomplished by turning decisions about how I work over to my computer, I’d be foolish not to.

Foolish not to, but who wants to work at the behest of a computer? And that’s Paul’s complaint.

amazon, amazon mechanical turk, amazon’s mechanical turk, amazon’s mturk, efficiency, hits, human intelligence, human intelligence tasks, management, mechanical turk, mturk, scary future, tasks, time, work, work units, amazon’s mechanical turk, amazon’s mturk

It’s good to know Hard to Find 800 Numbers.com is there when you need it. Here are the top five:

800 numbers, hard to find 800 numbers, customers service, customer support, support line, amazon, microsoft, yahoo!, ebay, paypal, contacting amazon, contacting microsoft, contacting yahoo!, contacting ebay, contacting paypal

I just received this email from the A9 OpenSearch team:

We have just released OpenSearch 1.1 Draft 2. We hope to declare it the final version shortly, and it is already supported by A9.com. Uprading from a previous version should only take a few minutes…

OpenSearch 1.1 allows you to specify search results in HTML, Atom, or any other format (or multiple formats) in addition to just RSS. In addition, OpenSearch 1.1 will be supported by Internet Explorer 7, among other software, so we strongly recommend that you upgrade. Also new is the ability to specify suggested searches, such as spelling suggestions and related queries. (link and emphasis addded)

Woot! I’ll be doing something with this soon.

a9, opensearch, open search, amazon, search, libraries, library, opac, library catalog, library catalogs, a9.com, metasearch, aggregated search, search, federated search

No, I’m not talking about the interface our users see in the web browser — there’s enough argument about that — I’m talking about web services, the technologies that form much of the infrastructure for Web 2.0.

Once upon a time, the technology that displayed a set of data, let’s say catalog records, was inextricably linked to the technology that stored that set of data. As we started to fill our data repositories, we found it usefull to import (and export) the data so that we could benefit from the work others had done and share our contributions with others. These processes were manual, or at least actively managed, and they depended on the notion that we had to have that information in our servers to be used by and displayed for our users.

Then technology evolved. Many applications now separate the components that store and manage the information from the components that display and manipulate it, and a few applications open up their data stores to the public via web services-based APIs. This is the concept that makes HousingMaps, ChicagoCrime, and Flickr Colr Pickr, among so many others, work.

Think about this for a moment: Our ILSs are inventory management systems, but our OPACs are (supposed to be) search and retrieval systems. The difference is obvious from here, but our vendors continue to operate as though you can’t have one without the other.

It might be easier to illustrate this point with an example or two.

Amazon Light is one of hundreds of applications based on Amazon’s web services. It connects Amazon’s inventory system with a custom built search and retrieval system, and it works. The Amazon Lite developers at Kokogiak didn’t need to build the inventory system, they only needed to think about ways to make the Amazon inventory more useful to you. Try it out, you might like the ability to search your local library (via some real hacks) or bookmark things via del.icio.us.

Or, you might not. Because Amazon allows anybody to access their catalog data, everybody has the opportunity to build a better, more usable catalog — or any other application that can benefit from the bibliographic details in it.

Take LibraryThing for example. It’s hard to explain what it is about people who read books that makes them want to list the books they own or have read or are interested in reading, but LibraryThing doesn’t worry about the why. It just answers the need. And because listing books, at least making a detailed list of books, can be time consuming, LibraryThing makes it easier by fetching the full details and book jacket from Amazon’s catalog. LibraryThing doesn’t need to “own” that info, it just needs access to it.

And what’s interesting is that LibraryThing is only one of a number of similar applications. Take a look at AllConsuming, Technorati’s popular books, and listal. These services connect Amazon’s catalog data with other data gathered from users or from web crawls, then they share the results. Here’s Ryan Eby’s lists of owned and wanted books, and here they are in RSS. Why RSS? Take a look at how he’s using the listal feed for his current reading list in his blog (lower-right column).

These are not technology demos. These are real applications. They are examples of how the world changes when you open up access to your catalog data. It’s what happens when we realize that the tools that store and manage our information are separate from the tools that display and manipulate that information.

Obviously, I’m about to make the (now-old) argument that we need to open our OPACs like this, but we also need take the lesson that easy and loose is winning over detailed and difficult — even in XML representations of our catalog data. And after looking at all that’s been done so far, I want to ask: why not adopt Amazon’s web services XML schema?

Is it so bad that it was invented elsewhere? Is it a bad thing that there are perhaps hundreds of applications that are already using data in that format?

Maybe the answer to those questions is yes, but here’s where technology can serve us again: we don’t have to choose. We don’t need to bet on one technology while we watch others progress faster. Our systems can output the same catalog data in any number of different ways. RSS, OpenSearch, MARC-XML, ATOM, EAD, or DC are all possible, easy in fact — if the inventory server architecture is open enough to allow it.

What do I really mean when I say library web services should be like Amazon web services? I mean they should be that accessible, that usable, that hackable. I mean libraries will benefit when people we’ve never met are spending their evenings building new applications to use our data. People are wondering how to get more programmers in libraries (example one, two), but I’m wondering how to make library systems more programmer friendly.

Fired up? Read more with my library catalogs should be like WordPress post, John Blyberg’s ILS customer bill of rights, and Ryan Eby’s open vs. turnkey discussion.

tags: amazon, amazon api, amazon web services, api, dublin core, ead, libraries, library, library catalog, marc, marc-xml, opac data, opensearch, web 2.0, web service, web services, web20, webservice, webservices, xml, xml server

Search Engine Watch did a story about how to use Google and Amazon’s tools to search full-text content inside books.

The gist? when you can get to the tools and where they’ve got content, it does a lot to make books as accessible and open as electronic content.

Sort of related: I’ve spoken of Google Print before and there’s more in the Libraries and Networked Information category.

tags: amazon, book search, electronic content, full text content, google, google print, inside books, search engine, search engine watch, search full text, search inside the book