Intro to Collection Types and Collection Extensions

Welcome.  This is an introduction to extensions being made to expand the functionality and configurability of collections in Hyrax.  There were two working groups that identified requirements and designed layout mockups.  An implementation sprint is currently underway and nearing completion.  This video will give you a look at the collections extensions functionality that is coming soon.

I'm logged in as an admin user at this point so that I can see the full set of admin menu options.  Down in settings you will see Collection Types.  I'm going to click this to see a list of collection types.

A major challenge that was identified by the working group is that not all applications think of collections the same way.  Just adding new functionality that would be available to all collections would not work. This led us to the concept of a collection type that allows you to configure how collections behave.  Additionally, within one application, there can be multiple types of collections.

The system architect for an application can decide how many collection types are needed and the characteristics a collection type should have.  Since this is a new concept, there are examples given in the descriptive text of the screen.  You can see that it lists User Collections that any user can create to organize their work, Exhibits which can only be created by curation staff for the purpose of public consumption, Controlled Collections which correspond to organizational units like university level, school level, department level, and Community Collections which can be used to create DSpace type communities and collections.  The types listed here provide examples of what you might want to do.  The actual names and characteristics of the collection types for a given site are designed by you to meet the needs of your application.

So let's take a look.  There are two collection types that are pre-defined for you.  User Collections are defined to bring in the functionality of the pre-extensions collection behaviors.  When you migrate to Hyrax with Collection Extensions, all existing collections are assigned the type User Collection.  You won't have to take any action for this to happen.  It is the default behavior of collection extensions to make this assignment.  To see how the User Collections type is configured, we will click Edit.

You have the ability to rename the User Collection type.  And you can update the description.  The end user will see a list of collection types in a modal when creating a new collection if they have permissions to create collections of more than one type.  If they can only create one type of collection they will go straight to the new collection form.

On the settings tab, you will begin to get a feel for the enhancements that were made to collections.  There are a number of checkboxes that define the behaviors of a collection type. 

Let's take a quick look at each of the settings.

• Nestable - This allows collections of the same type to be nested within each other.
• Discovery - Can a user set this collection to Public allowing it to show up in search results?
• Sharing - Can users identify other users who can help maintain and manage collections?
• Multiple Membership - Can a work be in more than one collection of this type.

You'll note that these basic settings are all on for User Collections.  This matches the existing functionality of collections in Hyrax, except that it adds the ability to nest which is new with the collection extensions.  These settings are not editable to maintain backward compatibility.

The last 3 are not allowed for general collections at this time.  They are specific to Admin Sets.  More design work is required to determine if and how these 3 settings would work for collections other than admin sets.  I'll talk more about those when we look at the Admin Set configuration.

• Require Membership
• Workflow
• Visibility

The final configuration you can make is in the Participants tab.  Here you can identify individuals or groups that can manage collections of this type.  And which users can create collections of this type.

Managers of a collection type are given edit access to all collections of that type at the point when the collection is created. For User Collections, you will likely set the manager to be the admin group.  If you have a type Library Exhibits, you might want to have one or two library staff users who can manage these collections.  This can reduce the burden on the IT staff to handle basic management of collections.

Creators will have edit access to collections they create, but otherwise have no special permissions to other collections of this type.  Again you can set up creators to match the needs of a particular collection type.  For User Collections, all registered users can create these.  But for the Library Exhibits example, there may be a group of librarians who can create these.

And you can see here that for the predefined User Collections type, managers are set to admins only and creators are set to all registered users.

It is important to note that access related to participants is granted at the time the collection is created.  If you later remove an individual and add another one, this will impact future collections when they are created, but will not change permissions on existing collections.  It is recommended that you grant participant permissions to a group instead of an individual.  For example, you can create a group 'library exhibit managers'.  Then if a person changes jobs or responsibilities, it is a matter of removing the user from the group and adding their replacement to the group.  The new user will get appropriate edit access to the collections as a collection type manager through their group affiliation.

Now let's take a quick look at Admin Set types.  This type, like User Collections, is predefined.

On the descriptions tab, you can change the description.  You cannot change the Type Name.  During this initial implementation, Admin Sets are not implemented as collections.  They are exposed through the UI as though they are collections to create a consistent UI for users.  The reason they are not implemented as collections is that they have additional functionality that was not brought into collections with this first implementation sprint for collection extensions.  We have set the stage for admin sets to become regular collections in the future.

So what might those settings look like?  By the current definition of admin sets, they are...

• NOT nestable
• NOT discoverable
• CAN be shared
• can NOT have multiple membership
• DO require membership - enforces that a work must belong to at least one admin set; when combined with multi-membership off, this becomes one and only one
• CAN define workflow - allows the admin set to specify the workflow to use for works created in the admin set
• CAN define visibility - allows the admin set to specify default visibility settings for works created in the admin set

It is the last 3 settings that are currently unique to admin sets.  They are consistent with the pre-extensions behaviors of admin sets.  Those settings are disabled for regular collections types.  This is were additional design would be needed to resolve how workflows and visibility settings would interact if they are defined on collections of various types and a work can belong to multiple of those collections.

There is a rake task that you run to create the User Collection and Admin set collection types.  All other types are defined through the UI.

I have defined one other collection type call Exhibit with settings...

• NOT nestable
• IS discoverable
• CAN be shared
• can have multiple membership

So now let's take a look at the collections...

For the purpose of the demo, I have pre-created a number of collections by various users.  I am currently logged in as an admin.  When I click Dashboard → Collections, I see a list of collections I created.  Because I am an admin, I also have an All Collections tab which will let me see all collections defined by any user in the repository.  This index has had a UI refactor to where the list provides additional information like the collection type, number of items, and shows last modified instead of create date to give a sense of whether the collection is stagnant or actively changing.  Not shown yet, but coming soon, this will also include filters that allow you to limit the set of collections by collection type and visibility.  The refactor also added the ability to bulk delete collections.

In general, the UI/UX enhancements take an educational approach to the UI.  For example, if you click Delete collections button without selecting anything first, you will get a dialog telling you to select something first.

Let's create a new collection.  The process is the same for an admin user and a regular user. 

When you are first creating a new collection, the only visible tab is the Description tab.  From there you can set the required metadata, which by default is the title.  To encourage the setting of the description, it was made a primary term, but not a required term.  So it shows up without having to expand with the additional fields button, but you can save without setting it.  The full range of attributes are available under Additional fields, but are hidden by default.  Once you click Save, additional tabs appear based on the collection type settings. I chose a type that has all settings turned on so we can explore all the tabs.

Branding allows the user to specify a header image that is displayed at the top of the collection landing page.  Additionally multiple logos can be uploaded.  The landing page work is still in progress.  But you can get a sense of where we are going from the mockup.