Interface Design
(PAS)
One of the challenges in a project such as this is designing an effective interface. There are several concerns that must be considered, including:
- Clearly signalling to the user which search criteria are applied to which project. This is important for the user to understand the possibilities and limitations of the searches, and thereby to make effective use of the resource. See further Searching the Cluster and Invalid Searches.
- Clearly signalling to the user which content is provided by which project. This is important both for the user to understand the value and purpose of the data, and also to fairly credit the projects and their teams for the data which is provided.
- Allowing complex searches across a range of criteria to be expressed as easily as possible.
- Conveying to the user the appropriate spelling and form of the search criteria. As discussed in Integrating Historical Data, the same information can be represented in different ways by different projects, one obvious example being the spelling of Anglo-Saxon names. It is therefore important for the user to understand which conventions apply. Normally this is explained in the 'Help' or 'About' section of a project website, but for the Cluster there is no single explanation since it depends entirely on the constituent projects.
- Whether searches should be 'deep' or 'broad': in other words, whether searches should include very detailed criteria which can be applied very precisely, or whether they should be broad 'Google-style' searches where keywords are applied across the whole system without discrimination.
- Ideally, allowing a range of visualisations for the complex data to be displayed as clearly as possible for the user. This also includes the question how much information the Cluster should provide: should it try to present as much data as possible from the constituent projects, or is it more useful to give minimal data and direct the user to the relevant pages of the constituent projects. During discussions and workshops with historians and specialist scholars, a strong preference emerged for the latter.
- Accounting for the difficulties and inevitable inconsistencies that will result from searches (for which see further
Integrating Historical Data), and conveying these to the user. This also includes the
question whether to err more on the side of inclusiveness or exclusiveness in search results: should the Cluster aim to
return as many results as possible, even if some of those results may not be what the user intended, or should it try to
be as focussed as possible, even if this means omitting some valid results. During discussions and workshops with
historians and specialist scholars, a strong preference emerged for the former: they preferred to have many results and
to sift through these themselves.
Several different designs were proposed and discussed during specialist workshops. In the end, due to a combination of scholars' requests and the scope of the project, the Search Form was developed that you see today. However, the other models are also presented below.
Browsing
|
This is a conventional 'browse' page based on names of locations. It raises several questions, however, including what 'Location' means. Is it the location of a granted estate? Of the bounds of the estate? An institution, such as a cathedral or abbey, which received the grant or issued the lease? The institutional archive in which the charter was preserved? All of the above? The answers depend on the research questions both of the person browsing and of the constituent projects. |
|
This is a conventional 'browse' page based on personal names. Once again there are questions about the type of personal name (issuer, grantor, beneficiary, witness), and of different spellings across projects, as well as distinguishing between many different individuals who shared the same name. This is particuarly complex since PASE has a very nuanced model for personal names, one that is not shared by any of the other projects, and so integrated browsing by name is very complex in practice, particularly if these categories are to be preserved. |
|
A much more sophisticated approach is possible using faceted browsing. In principle this allows one to browse by several criteria simultaneously, with the display dynamically updating as it goes (see, for example, the Centre for Recorded Music Sound File Search page). |
Viewing
As discussed above, once the content is found the question remains how best to display the relevant information to the user. Several more complex displays were drawn up and are shown below. The technical challenges of implementing these displays are significant, since the data from each project has very complex displays itself, and the Cluster must somehow 'know' how to display the data properly. Perhaps fortunately, the historians and other scholars felt that such complex displays were not useful anyway, since they would simply visit the relevant project if they wanted the complete information.
|
This view is an attempt to show the full information from all four projects on a single screen. The different sections could be expanded and collapsed by clicking on the '+' symbols at the header of each box. The principle here is to clearly distinguish the source of each piece of data, preserving the formatting of the original projects as well. This would then allow one to get a complete picture of all the projects' information about a single charter. Although this could be useful, there are many problems (as well as the techical ones). In particular, it is not scalable at all: what if five new projects were added to the Cluster? Ten? What about other types of data besides charters? What if projects have more than one set of data for a given charter (e.g. LangScape having more than one set of bounds)? Which view of a charter should be used? Ultimately this approach was considered not useful and so abandoned. |
|
These two mockups were developed by Arianna Ciula and Elena Pierazzo for their poster presented to the TEI in 2007 (see abstract). They considered just two projects in the first instance: ASChart and LangScape. The approach was similar to that in the previous 'Full Charter View', but at this early stage there was no centralised Cluster envisaged: instead it was thought that the two projects, LangScape and ASChart, would each 'know' about and include data from the other. |
