Request for Feedback on Omeka S 3.0.0-alpha

[SharonLeon]

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

[ManOnDaMoon]

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.

@SharonLeon

Public Views: Installation Base

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.

@SharonLeon

Public Views: Search Results

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.

[giocomai]

Having tried this out, here is my feedback (besides sharing much of what @ManOnDaMoon suggested above, in particular in reference to public views).

Sites: Resources

The ability to explicitly associate an item with a site solves a number of issues, but by making the process more deliberate it demands a bit more attention from users who create new items.

The preview option is nice and helpful, also because at first I did not realise that by default the search looks for results only within the item sets already associated with the site (I wonder if there is any way to make this more visibile… if not, anyway people will figure this out).

However, I have an issue: if I actually try to do any operation here (say, add the results of a search), I get the “success” message, but on my install actually nothing happens. If I go into the jobs logs it shows an error. Here’s the log for reference, I remain available to provide additional details if useful. I’ve been trying this on a test version on a local Docker install equivalent to the one online, updating from a previous Omeka 2 installation, so perhaps this may be related to the update process.

Sites: Settings: General

I feel quite strongly here that the default should be “not selected”. Especially as the number of site increases, some of them will be of past exhibitions, and new items should not end up there by default. Others will be unrelated to each other…say, a site on botanic prints and one on ornithology prints. In brief, if the process of adding items to sites must be more deliberate, then so be it, but I would think that “not selected” is a much safer approach, otherwise people may realise only months after the update that an unspecified number of unrelated items has crept into old sites.

Sites: Settings: Search

The settings seem logical and clear.

Items: New or Edit

I think this is clear, even if in some cases this may be somewhat cumbersome. If there are multiple sites, people may then decide to leave this out at the time of item creation, and then update sites via searches later.

An alternative solution that I think may be helpful in a number of circumstances would be to make some sort of optional binding between item sets and sites, e.g. “all items that are part of item set x, will automatically be added to sites 1, 4, 5, 7, and 10”. This should probably be set from the item set page. I see it goes somewhat against the base logic that being available to a site is a property of individual items, but otherwise for people who add items this ends up being just more work. With this setup, they’d just need to think carefully about item sets, and then the connection between item and sites will update automagically (for collaborators who only insert items, this is how they perceived things worked until now).

I have not much to add on the other points, so I’ll leave it at that.

If I may, I take this as an occasion for a feature request: provide a visually more enticing way to list sites. Allowing to set a “featured image” for sites would probably make it much easier to deal with it in themes. As things stand now, I don’t feel there is an obvious/non-custom way to show all (or a selection of) sites/exhibition from the main site of the Omeka S installation.

[jflatnes]

@giocomai

On the error you’re seeing when doing updates: I don’t think we’ve seen that before… I’m wondering if this might be something that a module is causing. What modules do you have active in this site?

On the “selected” default: to clarify, this setting is set by default for newly-created sites, but not existing sites on an upgrade. Do you still have the same concerns about the setting?

[giocomai]

As for the error, I have a bunch of modules, partly because this is a test install (some of them are not used in production).

These are the ones that are in the database, and missing in the new install:

AdvancedSearchPlus, BlocksDisposition, BulkEdit, CSVImport, CustomOntology, Export, IiifSearch, IiifServer, ItemCopy, jQueryUI, Mirador, PdfEmbed, RdfDatatype, UniversalViewer.

The following are installed and enabled:
Mapping, Numeric Data Types, and Custom Vocab

I am running this with Docker. It’s basically this Dockerfile, with the only difference that it installs alpha 3. The docker image for the alpha version is also on Docker Hub, with the relevant tag docker push giocomai/omeka-s-docker:v3.0.0-alpha (it’s a basic docker adapted from other versions that were around, but not including in the image either module or configuration, which are manged directly in volumes).

If you have specific suggestions about modules to be uninstalled before update, or other ideas, I’m happy to troubleshoot this further.

As for the “selected” default… well, it is much less of an issue, but I’d still think that “not selected” is a safer default. This is probably related to my use case: an Omeka S install with a dozen sites… only one of them would probably have enabled the “selected” option by default. Basically most new items would go to the main site, and to one other site, and it would be strange (basically, just wrong) if they ended up in the others.

Ultimately, this is not a major issue, as this needs to be set up only once when a new site is created, but in my case 100% of new sites would have this set to “not selected”.

Also, if I look at this conceptually, to me it makes more sense for this to be “not selected” by default: if I understand this right, belonging to a site is now a property of each item… and to me, each item is born empty, and anything that overrides this state of nature should occur by a deliberate action.

But again, this is just my take, and as long as this is explained clearly in the documentation and in posts communicating the update, it’s ultimately fine either way.

[jflatnes]

I believe we’ve figured out the issue with your update jobs: it doesn’t have anything to do with your installation being an upgrade or with Docker, it’s instead just an issue with doing a fulltext search as the query for selecting the items. I believe if you tried a query that didn’t use the fulltext option things would be working fine for you.

We’ve also fixed the fulltext issue, so on the latest “develop” branch this issue should be resolved.

[giocomai]

Indeed, I can confirm that looking for something in a specific field works on the version I had installed.

In the process, I also found out that finding field names is currently not really user-friendly, since at least in the translated version I am using they are not listed in alphabetical order. If I start typing, e.g. “Title” (“titolo” in Italian), it goes to the correspondent of “Alternative title” (“titolo alternativo”), so I have to browse all Dublin Core fields which do not seem to be in any particular order before reaching the actual “titolo” I was looking for (at the bottom of the list).

“Search as you type” would be best, but at least alphabetical order would already be a big step forward.

Thanks again!

[Daniel_KM]

Some feedbacks:

• site settings general: it should be a user option.
• site search: yes it is important to choose what the main search searches.
• items: new or edit: in many omeka installations, there is only one site (and translations), so in that case, this tab is useless, all the items should go inside all sites. In the cases where Omeka is used in a consortium way, with one site by institution, the choice is the same : the librarians belong to an institution and always fill the same site. So it should be a user setting.
• installation base: I don’t know a lot of installations that keep the default view; they have all a default site.
• individual sites: generally, the sites are clearly separated, so i don’t have this issue.
• search results: maybe a option to mix all the resources types in the search results, as in well-known search engines.

Of course, all modules I manage will be updated for Omeka 3 soon!