Search User Interface design

As for the SUI design, Table 5.3 summarises the search operators and the way they have been used in the Simple Search Interface (SSI), the Advances Search Interface (ASI), the Refinement Interface (RI) and the Navigation Interface (NI).

Operator Description Interface

service

SSI–R The SSI only accepts this operator if its value is correct. ASI–R The search operator is associated with a controlled list

available via in the advanced search form.

RI–R The OWSTaxonomy is exposed as check–boxes in the refinement menu to manipulate the search results.

NI The browsing via type of related service is enabled. Users can browser through whole content using a link in the main menu (“Browse via service type”) and the service description form (“service type” field). The check–box links in the refinement menu permit to access to the subset of resources according to user search query.

resource

SSI–R The SSI only accepts this operator if its value is correct.

ASI–R The search operator is associated with a controlled list available via the advanced search interface, in the advanced search form. RI–R The OWSResource is exposed as check–boxes

in the refinement menu to manipulate the search results.

NI The browsing via OWS resource type is enabled. Users can browser through whole content using a link in the main menu (“Browse via resource type”) and the service description form (“resource type” field). The check–box links in the refinement menu permit to access to the subset of resources according to user search query.

domain

SSI–FT No restriction on value.

ASI The search field accepts free text.

RI–R The Domain is exposed as check–boxes in the refinement menu to manipulate the search results.

NI The browsing via OWS domain is enabled. Users can browser through whole content using a link in the main menu (“Browse via domain”) and the service description form (“domain” filed). The check–box links in the refinement menu permits to access to the subset of resources according to user search query.

provider

SSI–FT No restriction on value.

ASI The search field accepts free text.

RI–R The Provider is exposed as check–boxes in the refinement menu to manipulate the search results.

NI The browsing via OWS provider is enabled. Users can browser through whole content using a link in the main menu (“Browse via provider”) and the service description form (“provider” field). The check–box links in the refinement menu permit to access to the subset of resources according to user search query.

Table 5.3: Search operators and user interface design (SSI–FT – free–text operator of simple search interface; SSI–R – restricted operator of simple search interface; ASI–FT – free–text operator of advanced search interface; ASI–R – restricted operator of advanced search interface; RI–R – operator used in the refinement interface of search results; NI – operator used in navigation interface).

Figure 5.4: Prototyped GUI of the search result offered by the Geospatial Web Search Engine. usability (i.e. “users spend most of their time on other websites”; “Users have several thousand times

more experience with standard GUI controls than with any individual new design.”). Therefore its

GUI design is similar to the faceted search offered by the typical online e–commerce applications (e.g. Amazon) Figure 5.4 presents the pattern of representation of the search result implemented by the GWSE client. The result list is in the centre. Each resource is described via a summary description that contains snippets of information from a full description, and some examples of operations that might be used to the retrieve the descriptive information or an example of item. On the left, the refinement menu is shown. The check–boxes allow refinement of the results which is performed after pressing “Update”. In the case of the Domain and Provider facets, the number of possible values in the refinement menu might overwhelm a user. Therefore, only the first five values of the highest frequency are displayed and the sixth one (“Others”) gathers the remaining resources. The check–box terms are also links, that offer explanation of the applied classification and expose a list of navigable categories to browse the related OWS resources. On the right, there is the related resources’ menu to expose the related resources to users. They are the Web pages (“W”) or services (“S”) from which the resource might be accessed. Most of them are results of the crawling process

5.6. GEOSPATIAL WEB SEARCH ENGINE 119 (i.e. they have been used by a crawler in order to identify the OWS resource). The others are Web pages of the OWS publisher. These Web pages have been generated from the domain URL as described in Chapter 4. There is also a link to visualise the resource in a map.

The full description of a resource is accessible via the “title” link in the summary description. Each resource is described via information from the Capabilities document which has been extracted using a metadata crosswalk (Nogueras-Iso et al., 2004). In the case of a service, user has the ability to invoke the descriptive operations or to retrieve some items. The requestable elements are described via information from the Capabilities document and the result of descriptive operation is encoded in HTML. Also, some summaries of dataset are shown if it is possible to create them. The discriminative

elements are identified. The values from low variable fields are listed with quantitative attributes

(i.e. the number of items in a dataset which satisfy the restriction), and an appropriate request is generated and enabled via a link.

Theoretical evaluation

The design principles proposed in Kules (2006) help in development of systems that support non– expert users in exploring the search results. Table 5.4 describes the manner in which the design principles are accomplished by the GWSE.

Id Design Principle Application

1 Provide overviews of large sets of The first 50 results are available. The full number

results. of matching resources is showed also.

2 Organise overviews around meaningful Several stables classification schemes are used. categories.

3 Visualise and clarify category The check–box and browsing tabs are organised

structure. according to the schemes’ structure.

4 Tightly couple category labels to The check–boxes indicate which categories are

result list. currently applied.

5 Ensure that full category information Not applicable. is available.

6 Support multiple types of categories Not supported. and visual presentations.

7 Use separate facets for each type of Supported. category.

8 Arrange text for scanning/skimming. The result list contains descriptional snippets. 9 Visually encode quantitative attributes The refinement menu and browsing tabs

on a stable visual structure. provide quantitative attributes.

Seven of the nine principles are fully supported. The fifth design principle is not applicable in this work because no taxonomy of deep hierarchy has been used. In this context, the wide vocabularies can be the obstacle. Domain and Provider are horizontally extensive. Anyway, the browsing menu allows users to browse through them. The sixth design principle is not accomplished because the user cannot define their own categories and no only single presentation style of search results is enabled.

As for user search goals, faceted search interface, along with the information model, can support the informational goal especially well. The informational goal can be reached via the exploratory search, as it enables search and browsing collections of resources using multiple categories. Also, the association of non–OWS Web resources (e.g. provider Web site) extends the information scope that can be explored by users. The navigational goal can be achieved, for example, via the “site” operator or by the navigational interface (e.g. by navigating to the provider Web site). The enablement of interaction with OWS services offers extended assistance to the transactional goal. A test module has been created, similar to that one which is offered by seekda’ portal for invoking the operations declared within a WSDL document. It generates a set of modifiable requests in order to allow users to interact with the resource. In this work, the set of request–response fields are only generated for WFS, WCS and WMS services.