Keeping the user experience in the browser

A few days back, news that Barrack Obama is using Scribd prompted me to take another look at this document sharing site. I'm interested in user interfaces at the moment because developing interfaces for curators and researchers wanting to use hybrid archives will be an important part of futureArch's work.

iPaper
I'm quite taken with iPaper's features. I should explain that iPaper is the flash technology developed by Scribd to display documents published to the sites by its users. Documents load quickly within the browser and the functionality is similar to that of Adobe Acrobat. You can search text, there's a thumbnail view, you can zoom, launch the document to display at full screen, turn the pages, etc. It also has some 'social' features (which may or may not be useful in this context), and it claims to be a more secure document format than PDF.

iPaper can display files encoded in a number of formats, a feature that may well prove useful for developing a browser-based interface to your typical born-digital archive. Imagine wanting to view a handful of items in a collection, each of which is in a different format. Rather than launching a different application to render each format (even if these are available as browser plug-ins), the user could access all the items using a single lightweight viewer that can be embedded in the web page itself. This normalisation for presentation simplifies access for repositories and users, and for those users interested primarily in content, a single viewer would provide a convenient and predictable experience that requires no software installations.

So far iPaper supports these formats:

* Adobe PDF (.pdf)
* Adobe PostScript (.ps)
* Microsoft Word (.doc/ .docx)
* Microsoft PowerPoint (.ppt/.pps/.pptx)
* Microsoft Excel (.xls/.xlsx)
* OpenOffice Text Document (.odt, .sxw)
* OpenOffice Presentation Document (.odp, .sxi)
* OpenOffice Spreadsheet (.ods, .sxc)
* All OpenDocument formats
* Plain text (.txt)
* Rich text format (.rtf)

For users interested in qualities beyond content, technologies such as iPaper may be less useful. On example is users who require an experience that reflects the context of creation; use of the iPaper format and viewer requires the transformation of the original item into iPaper format and its rendering in an environment quite different to that of its creation. Another example is users wishing to use specialist analytical tools, which might be domain- or format-specific.

Scribd
There are some aspects of Scribd itself that appeal to me too. A collection overview pane sits next to a list of child items in the collection, each of which have a thumbnail, page-count, format indicator and brief abstract. I'm sure we could do something similar in a view for archival collections, though an archive repository would more likely point to series descriptions from the collection level, and to items at lower levels of the archive's hierarchy. Scribd's item-level view works well too: the document is displayed in the page (using the iPaper viewer) and a little metadata is available on the right - some tags, rights information (creative commons), relevant categories, etc., and since this is web 2.0, users are able to add their comments.

Other possibilities?
I've also been investigating another means of enabling browser-based delivery for the kinds of file formats found in a born-digital archive. More and more of us want to create and view data at the network level and we want to be able to do it with a variety of devices. This can only mean that more options are going to be available, but, as ever, the creative direction is unlikely to correlate exactly with our requirements.

One possibility is javascript lightboxes, so long as the usual accessibility issues are addressed. Many of these tools are designed for image galleries, but there are some with other functionality too. Highslide is one I've spent some time looking at, and now version 4 is just out (five days old) it might be time to take another look. Perhaps the subject of a future post.