Do people search?
In the era of viral content, RSS feeds and social bookmarking do people search any more?
Information and new content is so pervasive and is being created at an ever-increasing rate do peopIe have any time to search? In an environment where 'newer' is often seen as 'better' Users are enjoying the relative luxury of having targeted content, that they have chosen, delivered to their desktops through technologies such as RSS news feeds and podcasts.
Social bookmarking and selection sites present third party content arranged in a natural, almost evolutionary, way. Popular content bubbles up to the top of the pile and by being there is presented more often. This works in a similar way to the way your favourite mug is always at the front of the cub-hoard or shirt at the front of the wardrobe. Should content be displayed using a simple ranking mechanism to control positioning?
How many links to short pieces of video content are followed from email recommendations from trusted sources (although with the amount of money spent on 'viral marketing' through email and actors being paid to strike up conversations with strangers on the streets and trains about products these become less trusted)? The content has been selected and is in your in-box waiting for you to make the decision to view it.
Looking at the search statistics for some of Watershed previous and current projects would suggest that search is not a high priority for must users:
- 0.34% of requests were search requests for Electric December during December 2005
- 0.60% of requests to watershed.co.uk are search requests
- 0.21% of requests to dShed/Digitised are search requests
Pre-set searches, or showcases, may be useful to users and to us to promote old content from the archive alongside newer content, such as "recently added short films" or "gay and lesbian animation". These smart searches could be initiated by administrative staff or users of the site.
Does an archive have the values it once had? An archive's value may lie simply in it's URI: a location for trusted new content.
Lots of the structure to hold and display content has been over-specified for past projects and we want to make sure functionality will be used before devoting engineering resources to it.
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'.
Universal Binary Address Book Plug-ins
Streetmap.co.uk and Google Maps plug-ins for Address Book are now Universal Binaries.
Just a quick entry to note that I have uploaded Universal Binary versions of the two Address Book plug-ins. There are some additional small bug fixes in the Streetmap plug-in that are worth upgrading for.
The minimum requirements haven't changed: still MacOS 10.3 or later, Apple's Address Book application and an Internet connection.
Rapidweaver 3.5
I've decided to start using the public beta of RapidWeaver 3.5 to edit the site now. I mention this in case the site goes a 'bit funny' over the next few weeks. For a public beta it appears very stable and hopefully the site will still be online tomorrow. The interface changes are a refreshing change and the layout feels much more logical, especially splitting some of the inspectors into separate panels.
I need to make some small changes to the template (apart from finishing it) to allow it to work with RapidWeaver 3.5. Rich media content is now embedded using Javascript and the functions are missing from my JS file. I thought I read that a feature of the blog in 3.5 was the ability to make 'sub pages' use the main template with the sidebar menus. Just can't seem to get that to work.
The more I use Rapidweaver, the more I like it and recommend it to anybody with a Macintosh who asks how to create and maintain a web site quickly and easily. A demo can be downloaded from RealMac Software's site.