Suggestions for MaNIS Classic Data Portal Interface


The following are suggestions from my experience with the MaNIS Interface Design project and the Query Log studies on ways to improve the current, "classic" MaNIS data portal search interface without the fundamental technology changes that would be required to support the design that resulted from the MaNIS Interface Design project. For example, in the networked query environment the preview numbers on the prototype interface design would require each data portal to periodically create and maintain indexes of the data available from each provider, a change which is not within the scope of the current MaNIS project.

Because we have these additional data sources, these suggestions go beyond the usual practice of heuristic evaluations, which note violations of heuristics, to proposing ways of resolving these violations, which I leave only implicit here.



Support common tasks first

First, from our interviews and the query logs, we learned what people wanted to search for most often: the existence of one taxon in one collection, or across the collections of all providers. The defaults and the structure of the query page should be organized to make those frequent searches require as little configuration as possible.

Search form

  • Upon entering the "Data Portal", the user should encounter the search form for "View specimen records". The other "View..." options available from the current first page, if they are still necessary, should be available by a second click from this search form, perhaps in a box in the upper left, labelled "Other searches available:". Currently, the user is faced with making an immediate choice but does not have enough information with which to make that choice.
  • Place the "Select Search Conditions" section at the top of the search form page.
  • Auto-enter "Genus" in the "Select a concept" pull-down, and auto-enter "equals" in the "Select a comparator" pull down. This is the most frequently used combination, and helps the user decode the functionality of the Boolean specification interface more readily. Those users who have a need to do a different type of query will explore and discover that other concepts or comparators are available. If "Add another condition" is clicked, auto-enter "and" in the "Select an operator" pull-down. In the other "View..." forms, provide similarly appropriate defaults.
  • Have the cursor auto-locate to the type-in term box on the first search condition.
  • Fix the bug that gives the Javascript error message "One or more value(s) has not been provided for a query condition" if you type into the query term box and click "Submit query" without having clicked elsewhere first. If for some technical reason this is not possible, then at a minimum, improve the error message to help the user who has typed something in to resolve the problem.
  • Remove or grey-out the "Remove last condition" button when only one condition is present.
  • Re-order the buttons "Add another condition", "Remove last condition" and "Clear all conditions" so that an innocuous one is located in the right-most position. It can be reflexive to press the lower-right button on a form - and quite frustrating if this clears your search conditions unintentionally.
  • Add a heading, Optional Parameters, indicating that all settings below this point on the page are fine if left as they are.
  • Default to search either a) all providers or b) the provider hosting the data portal. The current default with no providers selected acts as a trap for users.
  • Result set structure: The current default is good. Ideally, users should be able to change which fields they are viewing while looking at the results. Consider moving these options to the Results page.
  • Remove the timeout setting from the search form. If a data provider did not respond, offer a button or hyperlink on the results page that will re-submit the search with a longer timeout, in an attempt to include the slow provider. If a provider is consistently slow, then the data portal should automatically extend the timeout to include their response, warn the user that including this data provider will mean a longer wait, or otherwise help the user to assess if they wish to wait for results from that provider. The query logs suggest that the user does not have enough information to utilize the current timeout setting feature effectively themselves.
  • The inclusion of a "Submit query" button on the "Select search conditions" section of the page is a nice touch. Additionally, reverse the order of the buttons on the bottom of the form, so that "Clear form" is to the left, and "Submit query" is to the right. Users are more likely to click to the lower right, and accidentally erasing their just-entered configurations is more of a tragedy than accidentally submitting an incomplete search form.

Results display page

  • Provide a brief, user-friendly display of the current search conditions (find what, where) with a "Modify search" button at the top of the page.
  • The results display page should provide features to help people retrieve all of the records, if they want more than the default of ten per institution. A minimal change is to place an indication of the current limit (eg: "Record Limit = 10" or "Max = 10") below the title "Returned" on the "Data providers" display of the count of records returned, providing word recognition for the setting that needs to be changed. An additional step would be to provide a button below the total in the Matches column, "Retrieve all matches", which would re-submit the same query but remove the record limit. Additionally, each of the subtotals by instution within the "Matches" column could be hyperlinks which resubmit the query with just that institution, but no record limit. If these tools are developed, the "Specify record limit" section on the search form can be removed.
  • Provide feedback about what aspect of the record warrants its inclusion in the found set. For example, in a search that specifies "genus=x and locality includes y", highlight the genus column and locality text string in bold.
  • Set the "Download tabular results" button to trigger the download of a file, rather than showing it in the browser window.
  • Consider using smaller text for the record display. This allows users to see more information at once, and more readily access if the results are what they had in mind. By using a relative size, users will also be able to enlarge the text at any time.
  • A nice touch: The institution names can be hyperlinks to pull up the institution's metadata, like it is displayed in the page accessed by the circular "i" on the search form.


Use the user's language

Secondly, the classic MaNIS portal is an expresion of an impressive technical and social achievement, yet the terms used in the development of this project are not necessarily recognized by a larger community of users. For example, while ""querying" a "data provider" makes sense to those familiar with databases and DiGIR, those outside the project think of "searching" a "museum" or instution's collection. On the interface it is important to describe features from the perspective of the user's tasks and familiar concepts, rather than from the technology domain.

Additionally, while the current interface incorporates some nice help text, usability wisdom holds that users, even intellectual ones, seldom read such text. It is better to use a longer label that is self-explanatory rather than a short, cryptic label needing explanation. For example, "View XML" button on the providers' info page could be "View this data provider information in XML format" with no additional text.

What follows is a list of suggestions for wording updates and self-describing labels that may help the functionality of the MaNIS search interface be immediately intelligible to a wider audience. An important principle here is consistent use of terms throughout the interface, so if these suggestions introduce inconsistencies with other changes that have been made, they should be reconsidered.


  • Replace "data provider" with either institution, museum or collection.
  • Replace "query" with "search"

First page (current interface):

Note that ideally, the choice on this page will be eliminated, or at the least moved from being the first choice users must make (see above).

  • Replace "Select type of network query" with "Search MaNIS for:"
  • "View (specimen records/geographic index/taxonomic index)": "View" is confusing. Also, the "indexes" are not self-evident. The term "index" means the listing in the back of a book, or perhaps a numerical indicator, in common usage. Can the types of information returned by these options be clearly described with a few more words?
  • Replace "Build query" with "Start search"

Search form

  • Replace "Select data providers" with "Select institutions" or possibly it is a question -"Search where?"
  • Replace "Select query conditions" with "Specify search conditions" or "Search for what?"
  • Replace "Clear all selections" with "Unselect all institutions"
  • Replace "Clear all conditions" with "Reset all search conditions"
  • Replace "Submit query" with "Submit search" or "Search" or "Get specimen records" or "View results"
  • Replace "Specify result set structure" with "Specify which fields to view" or "Specify what information to retrieve" or "Specify what format to view the information". "Which fields do you want to see?" See comments below about the interaction design for this feature.
  • "result set" and "structure" are not familiar nor self-describing terms for most users. This leaves the terms "Mapping" and "Taxonomic" and so on to describe the type of information these various options propose to retrieve. I suggest developing longer, more descriptive labels for these pre-defined combinations of information.
  • Replace "Specify record limit" with "Specify maximum number of records to return" or "Get how many records from each institution?"

Results display page

  • In the "Data provider" section, some providers show "0", while others show a little red "x". The meaning of the "x" is unclear, and needs to be explained.
  • Button: "Map results" Help Text: Select "Map results" below to map your query results to an external web mapping application. Suggest: Button: "View records on a map" Help Text(located to the side, so as not to move the results display down any further) :Sends your search results to an external website that will generate a map.
  • Button: "Download tabular results" Help Text: Select "Download tabular results" below to dowload a tab delimited file that can be saved and/or loaded into an external application (such as Excel). Suggest: Button: "Download tab-delimited text file" Help Text (located to the side, so as not to move the results display down any further): Use these search results in another application, such as Excel.


Challenging Interactions

Thirdly, the classic MaNIS portal is obviously quite flexible in its ability to specify who to query and what the format of the results should be. However, both of these interactions involve long lists that challenge the limited space in a browser window.

List of data providers

The list of data providers is already long, and promises to grow. The current solution gives a generous-sized scroll window to this list, and supports the two most common scenarios we identified in our interviews - selecting all institutions, or selecting just one. However, selecting multiple providers in this situation requires that users know to hold down the control key while clicking on multiple institutions. Users should be able to find this stated on an Advanced Tips page. Additionally, those curators/collection managers at late-alphabet institutions will always have to scroll to select their own collections. Finally, those users without prior knowledge of the nature of the collections at the various institutions don't have the information with which to make a decision that limits the institutions searched, and so it seems a shame to take up so much of the search form with a feature that they don't need to change. Finally, the institution's name is a good location (the actual name as a link, or a link right next to it) for users to expect to access information about the institution's collection(s), like the metadata currently accessible behind the circled "i" in the "Select data provider" color bar.

The MaNIS Interface Design project prototype proposes an alternative interaction, where the default is to search all institutions. On a separate screen, each institution is listed and acts as a hyperlink - clicking the hyperlink to one institution selects that institution. Clicking additional institutions should add them, and buttons are provided for removing institutions from the list. Since the list is long, this interaction might be relgated to a different screen.

A suggestion might be to remove the data provider list from the search form and use the list of providers on the results display page as this interactive list. I have some concern about the extensibility of this layout into HerpNET, where a list of 37 providers will quickly run the results display off the bottom of the browser window. However, I think this approach would take the same number of clicks to specify a one-institution search; would simplify the search form; and would act on the principle from the MaNIS Interface Design project of supporting users to interact with their result set on the same page where it is displayed.

Note that while the institutions themselves may be aware of their individual collections, and may set up multiple DiGIR providers in order to serve them to MaNIS, the users other than curators from those particular institutions are less likely to be familiar with the nature of the boundaries between collections, and are more likely to be interested in searching what the institution as a whole contains. Moving between institutions may require an airplane ticket, while moving between collections once one is on site is much more readily accomplished. The displays of participating institutions should focus on the institutions rather than the particular catalog/gazetteer/index being queried.

Result set structure

The "Specify result set structure" part of the search form asks the user to specify two things: which fields do you want from these records, and how you want to see them - that is, in what order should these fields appear in the results. The current interaction is problematic because users cannot be assumed to know beforehand what fields the various pre-defined structures contain, nor to be comfortable with XML documents. If they define their own, they need to figure out how to use an uncommon, perhaps new, tool. Finally, they are asked to make this decision before they know what the information they have retrieved looks like.

Similar to the principle demonstrated in the MaNIS Interface Design project prototype, it would be ideal to provide users the tools for adjusting their result sets - which fields, in which order - while they are looking at the found records. Since the default is to retrieve the full record, I assume there is no substantial cost to doing so, and then presenting the fields as specified by the user.

Although not fully demonstrated in the prototype, the design for the "Show/hide columns" panel developed during the project would list out all of the fields, with checkboxes to the left. Each field also has a pull down menu with the current rank selected, but which automatically re-orders the list if a different rank is selected. At the top, the predefined structures would be listed. As the predefined structures are selected, the appropriate checkboxes and field order is displayed. If a checkbox is changed, the "Custom" radio button auto-selects, and the user can continue to customize the display.

Additionally, the columns in the results display allow for hiding (which also triggers the display of the show/hide panel) and for sorting the results. Any of these features which can be incorporated into the MaNIS results display will benefit the interaction of the classic interface.


Additional Comments

The current entry, where one must select a data portal, is confusing for those who aren't familiar with the MaNIS project. I assume that each institution hosting a data portal will take care of their own entry to it, and that the "MaNIS Home" link in the breadcrumb trail at the top of each page will be replaced with their appropriate navigation link.

Specifying Search Conditions:

  • The query's Boolean structure is ambiguous if more than two conditions are specified. Where are the parentheses in: "Genus x" and "State/province y" or "State/province z" ? A statement about how this system handles these query structures would be appropriate on an Advanced Tips page.
  • The circled "i" in the "Select query conditions" color bar accesses information about the concepts available in the "Select a concept" menu. It should be placed near to that menu. Its current location implies that it provides information about filling out that part of the form.
  • Consider placing "remove" button next to each condition, replacing the "remove last condition" button. The interface for building rules in is worth a look.

The record limit enforced by the institutions came up as an issue in one of our interviews. The MaNIS wish list might include providing a way to help people retrieve the next 1000 records that match, for example, when a match from one institution totals more than the single-query record limit from that institution.

Finally, I drew up these suggestions from the search form accessible by selecting "View specimen records" from the first page. If there are any questions about how to apply these comments to the other forms I will be happy to contribute what I can.

Based on the MaNIS interface as of June 25th, 2004