dShed Search

As part of the redevelopment of dShed we are looking at search techniques for the dShed site and now wondering what user features it should contain.

For content that has a pedigree a simple search text field will do the job. The iTunes Music Store has approximately three and a half million items available and locating an item is trouble free. Similarly, selecting products to purchase using Amazon's single text field isn't something that causes lots of issues.

Will this approach work for content that is unknown? Using a text field that searches enough attributes and anticipates the users intentions would be sufficient for most situations. An example/ prototype for a simple search is illustrated at www.dshed.net/benjamin/. This is not an interface demonstration, is not fully implemented and only works in recent versions of Safari and Firefox. This searches for Creations based on the following attributes:

• title
• series.title
• series.project.title
• creator.title

Using these four attributes users can find a wide variety of content:

• "6 g" will find the short film 6 Goats from Depict
• "architecture" will get the series of films made for Architecture Week as part of 90 Second Challenge
• "90 sec'' will get the content from 90 Second Challenge
• "colmar'' will find the content made by Ralph Juergen Colmar
• "bridge'' will find lots of photographs of bridges

Increasing the number of attributes, from the four listed above, would allow the user to find items based on abstract properties or human interpreted descriptions but will also return more false positives. Performance will also degrades as the number of attributes increases. Current metadata is sufficient to specify Creations with a fine granularity and also synthesise collections of creative content. In fact, we are looking to reduce the metadata overhead associated with each Creation.

At some point, as the number of attributes increases an attribute specific advanced search (such as Digitised’s Advanced Search) will return higher dividends to users.

The search mechanism is currently an engineering project to test performance and possible optimisations so the results from the demo simple search are simply returned in alphanumerical order and there is no ranking. One obvious performance optimisation would be to track searches progressively.

Currently, as a user types another character, a new search request is generated. Imagine the user is looking for the film 6 Goats. The user begins by typing "6" and the application searches the dShed archive. Next the user adds a space and the application searches the archive using the terms "6 ". Next the user adds a 'g' and the application searches the entire archive using the terms "6 g". At each stage, a new search is of the entire archive is initiated. Using some form of session identifier, we can track the progress of individual searches and, where appropriate, just search the results of the user's previous search.

Maybe search should be about trying to guess what the user wants rather than the act of simply matching search terms? If no results are found maybe we can try searching on a further set of different attributes or else try to return something similar or useful. The lowest point in a browsing session is when no results are returned from a search; this says 'this site has nothing for me and I am in the wrong place'.