Child pages
  • List of required mockups for Collections
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Also known as Display Sets.

RequirementDescriptionMockupsMilestonesComments
Management of Collections
Collection  ConfigAbility to configure global characteristics of Collections
  • form for setting global configurations
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 CollectionsList all existing Collections.  Create and edit existing Collections and their metadata.
  • list all
  • show page
  • new form
  • edit form
  • 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 WorksSelect any work that is discoverable and accessible by (at least some) viewers of the repository can be selected to be part of a Collection 
  • select existing works starting from Collection show page
  • select existing works to add to a Collection starting from Dashboard → My Works
  • select Collections from Edit Work form → Relationships tab
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 CreationA single work can be created directly in a Collection.
  • initiate New Work process from Collection show page
  • select Collections from 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 UploadMultiple works can be created directly in a Collection via batch upload process.
  • allow users to select Collection(s) on Batch Create → Relationships tab
3Same notes as for Work Creation
Remove WorkRemove a work from a Collection.
  • remove work from the Collection while viewing the list of works in Collections management → Listing
  • remove work from Collection from Edit Work form → Relationships tab
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 WorkDelete 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 LocationsThe show page for a work links to any Collections in which it is a member
  • list Collection parents on Work's show page
2NOTE: 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.
NestableSelect any Collection that is discoverable and accessible by (at least some) viewers of the repository to be part of a Collection 
  • 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 CreationA single Collection can be created directly in a Collection.
  • initiate New Collection process from Collection show page
  • select parent Collections from New Collection form → Relationships tab
4

NOTE: 

  • When coming from Collection show page, automatically assign the Collection parent relationship on the Relationship tab.

Browsing and Discoverability 
Landing PageShow branded landing page for a Collection
  • when a public user, show the landing page instead of the basic show page used for Collection management
1Milestone 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 BrowseBrowse from top most Collections to member Collections and Works
  • from Homepage be able to browse Collections

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.
DiscoveryCollections and member works can be discovered through regular app wide search.
  • discovery results for works that are in a Collection
1

How would the results be displayed?

What facets would be needed?

Search within CollectionSearch results are limited to works in a Collection and any of its member Collections
  • discovery results for works that are in a Collection

1

2

Milestone 1: Limit results to the Collection

Milestone 2: Limit results to the Collection and all member Collections



  • No labels