| Requirement | Description | Mockups | Milestones | Comments |
|---|
| Management of Collections |
| Collection Config | Ability to configure global characteristics of Collections | - form for setting global configurations
- Mockups
| 1 | Configuration controls global characteristics about Collections including: - multiple membership: true | false
- nestable: true | false
- browsable: true | false
- branded landing page: true | false
- who can create Collections: role id
- include ability controls (e.g. setting users to be managers, depositors, viewers): true | false
- can set a workflow per Collection: true | false
- can set visibility of Collection (i.e. APO controls): true | false
QUESTION: Should the ability controls really be optional? What is the use case for not allowing ability controls? If they are optional, then the default value for managers, depositors, and visitors would be the user who created the Collection. QUESTION: Should there be types of Collections (e.g. User Collection, Curated Exhibit, etc.) that have different configurations? How would that look in the UI? NOTE: There are open design issues on the implementation of having workflows for Collections. There is still a need for understanding how that would look in the UI, so workflows may appear in this document in a number of places. |
| Manage Collections | List all existing Collections. Create and edit existing Collections and their metadata. | - Mockups
- list all
- new/edit form
- show page
- delete with confirmation
| 1 | Metadata: - basic - Title, Description (allow html with links)
- branding - Header Image, Logo (possibly multiple logos for joint ventures)
Show Notes: - It would be nice to have an option to preview the public Landing Page from the Show Page
New/Edit form: - Needs ability to specify a parent Collection and children Collections
- Needs ability to specify ability controls (e.g. managers, depositors, viewers)
- Needs ability to specify workflow to use for works created directly in this Collection
- Needs ability to set configurations that are Collection specific or can be overridden
- includes ability roles (e.g. managers, depositors, viewers)
- can make configs more restrictive, but not permissive
Delete: - Can a Collection be deleted if it has a primary relationship with works in the Collection?
- Can a Collection be deleted if it has an alias relationship with works in the Collection?
- What happens to works in the Collection if it is deleted?
- Maybe the Collection has to be empty.
- Ability to delete a bunch of works may need to be limited to Admin Sets.
NOTE: Management of Collections should have a UI that is consistent with management of Admin Sets. (See Administration → Administrative Sets in Sufia app)
|
| Works within a Collection |
| Add Existing Works | Select any work that is discoverable and accessible by (at least some) viewers of the repository can be selected to be part of a Collection | - Mockups
- select existing works from
| 1 | How to convey the concept of one Collection owning a work and all other Collections with the same work as member have an alias relationship (or mapped relationship) with the work? Do we want to use the term ownership, or should it be something like 'primary' Collection. I will use 'own' in this document, but recognize that terminology may change. For adding an existing work... - Is this work in another Collection?
- NO, does the work become owned by the Collection?
- YES, is the user prompted whether this is an alias or a move of the ownership?
Questions: - Can a user put a work in a Collection if they cannot edit the work?
- By adding a work to a Collection, could a user be granting themselves privileges for that work? (e.g. viewers can view all works in the Collection even if it would not normally be visible to them based on access)
- Limit the primary relationship between a work and Collection such that it can only be set by a user who has edit access to the work. Additionally, ability roles only apply to works that have the primary relationship. If a work does not have a primary relationship with the Collection, then the ability roles do not apply; only the access settings for the work apply.
- How do ability roles defined in Collection and roles defined in Admin Set effect each other, if at all?
- Does it make sense to recommend that an app only allow Collections or Admin Sets able to be discoverable?
|
| Direct Work Creation | A single work can be created directly in a Collection. | - Mockups
- initiate New Work process from
- Collection show page (auto fill in Relationships tab → in Collection)
- New Work form → Relationships tab
| 2 | NOTE: - When coming from Collection show page, automatically assign the Collection relationship on the Relationship tab. This Collection becomes the owner of the work.
Complexity: - When multiple Collections are selected on the Relationships tab of the New Work form, how to determine which Collection is the owner of the work?
|
| Batch Upload | Multiple works can be created directly in a Collection via batch upload process. | - allow users to select Collection(s) on Batch Create → Relationships tab
- LATER MILESTONE - Mockups TBA
| 3 | Same notes as for Work Creation |
| Remove Work | Remove a work from a Collection. | - remove work from Collection via
| 1 | This action requires the user to be an admin or depositor for the Collection.
Question: If the last work is removed, should the user be prompted to delete the Collection if they are a manager? Should managers be notified of empty Collections? |
| Delete Work | Delete a work from the repository. | - delete work from the Collection while viewing the list of works in Collections management → Listing
| 1 | This action requires the user to have edit access to the work. NOTE: Could be a prompt when selecting Remove Work that asks whether this is a remove from this Collection or a permanent delete? |
| Work - Link to All Locations | The show page for a work links to any Collections in which it is a member | - list Collection parents on Work's show page
| 2 | NOTE: On the show page for a work, it lists all Collections and other collectors (i.e. Admin Sets, User Collections) where the work also lives AND that the user has access to view. QUESTION: Is this functionality already in place and we just need to make sure the extended collections are showing up in it without change to the UI/UX? |
| Nestable | Select any Collection that is discoverable and accessible by (at least some) viewers of the repository to be part of a Collection | - NEEDS MOCKUPS!!!
- select existing Collection to be a member of another Collection starting from Collection show page
- select existing Collection to add to a Collection starting from Collection management → Listing
- select existing Collection to add to a Collection from the New/Edit Collection form → Relationships tab
| 1 | NOTE: - Will there be a Relationships tab for Collections? This is dependent on the design for Collections new/edit forms.
- A Collection cannot be an ancestor of itself. There needs to be an error message to display if a user tries to do this.
|
| Direct Collection Creation | A single Collection can be created directly in a Collection. | - initiate New Collection process from Collection show page
- LATER MILESTONE - Mockups TBA
- select parent Collections from New Collection form → Relationships tab
- LATER MILESTONE - Mockups TBA (see NOTE)
| 4 | NOTE: - When coming from Collection show page, automatically assign the Collection parent relationship on the Relationship tab.
Mockup NOTE: Probably same as for New/Edit Work form so likely low hanging fruit and possibly done when New/Edit Work form is changed if they share partials. |
| Browsing and Discoverability |
| Landing Page | Show branded landing page for a Collection | - Mockups
- show the landing page instead of the basic show page (public user)
- previewing landing page (manager/depositor/viewer users)
| 1 | Milestone 1: Make use of title, description, header image, and logo to make a public landing page.
Milestone 2: Show all collections in which this collection is a member. |
| Hierarchical Browse | Browse from top most Collections to member Collections and Works | - Mockups
- from Homepage be able to browse Collections
- Featured Collections
- Hierarchical Browse (from see all collections link in Featured Collections)
- LATER MILESTONE - Mockups TBA (see NOTE)
| 2 | This is how the public user will primarily interact with Collections. It would be nice to have several ideas of what the entry point into the Collections would look like. We need a good default browse implementation that sites can override depending on the focus of their app. Mockup NOTE: Hierarchical browse needs more information on how to identify the top most set of collections. |
| Discovery | Collections and member works can be discovered through regular app wide search. | - Mockups
- discovery results (works that are in a collection)
- discovery results (works that are NOT in a collection)
- discovery results (all collections)
- discovery results (mix collections and works)
| 1 | How would the results be displayed? What facets would be needed? |
| Search within Collection | Search results are limited to works in a Collection and any of its member Collections | - Mockups
- discovery results (limited to items in a collection)
- search box
- See mockups for landing pages.
- results
- NEEDS MOCKUP (showing any differences from system wide Discovery)
- discovery results (limited to items in a collection and its sub-collections)
- LATER MILESTONE - Mockups TBA
| 1 2 | Milestone 1: Limit results to the Collection Milestone 2: Limit results to the Collection and all member Collections |