Request for Feedback on Omeka S 3.0.0-alpha

For the past six months, the Omeka Team has been hard at work on a new version of Omeka S that is designed specifically to enable users to search contents of an entire install, rather than being limited to a search that only applies within an individual site. We think this will be a major improvement for administrators who take advantage of Omeka S’s multi-site capabilities.

We invite you to install the 3.0.0-alpha and take it for a spin, and at the same time, we welcome your feedback. This is definitely a testing version, and not ready for production sites. Please note that because this version of the software includes changes to the Omeka S database, it is difficult to revert to an earlier version. As a result, you will want to use a separate installation for any testing.

Additionally, as this is a new major version of Omeka S (3 instead of 2), old versions of modules and themes will not be compatible. The S download zip will, as usual, come bundled with a compatible version of the “default” theme, and all modules and themes written by the Omeka team have 3.0-compatible branches you can check out from GitHub. Version 3.0.0 includes a change from Zend Framework to its new name of Laminas, which means essentially all modules have at least some minor changes that need to be made.

The addition of the “All Sites” search feature has required a good bit of reengineering the way that items are associated with sites. As a result, we need your thoughts on all of the key new processes in the Site Resource selection, Site Settings, Item creation/edit, and on Public Views.

Sites: Resources

In creating or updating the resources attached to a site, Administrators now have an array of new options. Using an advanced search interface, they may:

  • Add - keep existing items and assign items from a new search
  • Replace - unassign all items and assign items from a new search
  • Remove - unassign selected items from a new search
  • Remove all - unassign all items

The advanced search interface includes a preview option so that users can view the resultant items as a browse list in a new browser tab. The search interface also includes an option for users to save a set of search criteria, so that they can reuse it in future item-to-site attachment work.

Feedback Requested: Do these options and processes make sense working with the items that are attached to a site? Is the preview and saved-search process clear?

Sites: Settings: General

  • Once Administrators have gone through the initial set-up process, they now have the option to attach all newly created items to the site in question. This option is selected by default. However, when users are creating new items, they do have the option to unselect a site so that the new item is not attached.

Feedback Requested: Should the default here be selected or not selected?

Sites: Settings: Search

  • Administrators can select the type of search that is available to their public visitors
    • This Site: restricting results to site within which the visitor is encountering the search interface
    • All Sites: allowing returns from every site in the installation
  • Administrators can select what kinds of resources are made available to the search engine from this site: Site Pages, Items, or Item Sets.

Feedback Requested: Do these settings seem logical? Are there other options that you would like to see included?

Items: New or Edit

  • Now that Items are affirmatively attached to sites, content creators have the ability to assign an item to a site or many sites in the creation workflow. There is a new “Sites” tab for this selection.

Feedback Requested: Is this new addition to the workflow clear? Are there additional features in the Item assignment process that would be useful?

Public Views: Installation Base

  • At the base of an installation, the software now not only includes a list of the sites in the installation, but also keyword search that produces results from the contents of the entire installation.

Feedback Requested: Are these views sufficiently clear for users so that they can interpret their results?

Public Views: Individual Sites

  • When Administrators provide an “All Sites” search, visitors who use the site’s keyword search will see not only a list of Items in their results with a set of links to the those items within the site that reside.
  • Browse pages for Items and Sets continue to contain a link to an Advanced Search interface.

Feedback Requested: Are these views sufficiently clear for users so that they can interpret their results?

Public Views: Search Results

  • For both the installation and the individual sites’ keyword searches, results are sorted into the resource types that have been made accessible to the search mechanism (e.g. Site Page, Items, Item Sets).
  • Search results are displayed as a browse preview. Following the “View all results” link provides access to an Advanced Search mechanism for both Items and Item Sets.

Feedback Requested: Is the workflow to the Advanced Search reasonable?

As always, we appreciate your time and willingness to support the ongoing improvement of all of the Omeka platforms, and we look forward to your thoughts.

The Omeka Team

1 Like

Thanks for the public alpha release. I’ve been looking at the new site attachments features that introduces a lot of new workflow possibilities. Below are immediate questions that I had while trying these out, and more specifically the search capabilities.

I have a problem with the results from the search form on installation base: a user performing a search from there gets a results page that does not seem to give a way to go back to the home page/site list. You can only browse to an advanced search form, itself not giving a way back to the simple search nor the home page. This, I think, lacks a bit of navigation.

As an additional suggestion, the results displayed could benefit from a media thumbnail, but I understand if the objective is to keep things minimal here.

With multiple resource types enabled for search (site pages, items and/or item sets), the type heading is always displayed in the result view even when there is no result to be shown, only with the “No result found” string. This often pushes down relevant results found within other resource types.

In the example search result below, there are 3 headings, 7 lines of text, and only one of them containing the relevant result.

Show capture

I would suggest that if there is no result to be shown for a specific type, the type heading and “No result found” string should be pushed down the actual results, if displayed at all.

Thanks in advance for your own feedback on these suggestions. I’ll post new suggestions if any come to mind when I get a deeper look in these new features.

1 Like