Collections: Create branding metadata partial of the new/edit form

[elrayle]

Descriptive summary

Add code to implement the Branding tab partial for the new/edit form views for collections. This partial is shared by both the new and edit form views.

Rationale

See model issue for rationale.

Implementation

Files:

• Edit app/views/hyrax/collections/_form.html.erb
• Create app/views/hyrax/collections/_form_branding.html.erb

Expected user interactions

Add the tab to the form by editing _form.html.erb.

Create the UI view for uploading branding files for a collection by adding partial _branding.html.erb.

Able to upload files...

• [ ] Banner (one file)
  • [ ] ability to replace the banner file
  • [ ] ability to remove the banner file
• [ ] Logos (multiple files)
  • [ ] ability to remove each logo
  • [ ] ability to set link URL
  • [ ] ability to set alt text

Exact text for the page is in the mockup below.

NOTES:

• Need to verify that the files uploaded are JPG, GIF, or PNG.
• The mockup does not show using jquery uploader which allows for drag-n-drop. That might be a nice bit to add.

NOTE: This includes changes to the Collection controller to process the new landing page values. I'm not sure where the code is that actually does the processing for new/edit. There is some documentation in the wiki identifying code locations for Managing Collections. Also, there is additional information about Permission Templates in the wiki. I would expect the save process to be similar to that for What happens when I deposit a work?

QUESTION: Should the new landing page information go in Fedora or the database? If it becomes part of the collection object, then there are questions with regard to what predicates to use to associate the images with the collection object.

SPECIAL NOTE on Admin Sets:

For the initial implementaiton, the Admin Set underlying code will not change. But to a user, the Admin Set will appear to be a collection.

To make the illusion happen...

• for this sprint, there will be no branding of Admin Sets

Mockup

Related work

Collections feature	Issue
Routes	#1380
Controller	#
Model	#1383
View - Index	#1417
View - Show - Admin	#1427
View - Show - Landing	#1428
View - New/Edit	#1374
Partial - Description	#1375
Partial - Branding	(this issue)
Partial - Relationships	#1377
Partial - Sharing	#1378
Partial - Discovery	#1379

[mjgiarlo]

QUESTION: Should the new landing page information go in Fedora or the database? If it becomes part of the collection object, then there are questions with regard to what predicates to use to associate the images with the collection object.

Unclear to me based on the information in this issue. Should we discuss on Wednesday's tech call, where we have more time to dig in?

[newmanld]

Regardless of the whether the information re the landing page is in Fedora or the database, and described by the collection object and (PCDM?) predicates or not, I would want to be able to export this information (including banners and logos) in an object (a bag) that I was preserving in an external dark archive. Could this question about storage of the landing page impact that functionality? Do others have this use case?

[elrayle]

Samvera-tech call 08-09-2017

4 options:

• directly attach files to collection - This is possible and lightweight, but might require duplicating code from FileSets to make it happen.
• attach files to collection via FileSet - This is probably simplest approach. There may be issues to resolve since Collections do not currently have FileSets.
• attach files to collection via relationship to PCDM:RelatedObject and attach file as FileSet to related object - This may require significant implementation effort and it seems heavy handed. It was discussed previously, but was never implemented.
• put files in database - This keeps the files outside the archiving and preservation process, which may be undesirable.

Call participants were leaning toward either directly attaching to the collection or attaching to the collection via FileSets.

[elrayle]

From discussions in samvera-tech list, there were multiple opinions expressed about the direction to go, but none were expressed strongly. The general consensus is that the implementer can make a judgement call on the best way to proceed, with a sense that using FileSets and the code base associated with that would likely be the easiest and most consistent approach.

[jeremyf]

Questions that need answering. What is the default expectations of banners for Collections?

• I expect that the Banner File would be rendered in the UI.
• I don't believe it should be stored in Fedora as that is slow in performance. (_It feels as though the banner is analogue to the AvataraUploader that we use to associate Avatar images with users)_.
• The Collection needs a custom predicate (e.g. hasBanner) that points to a URI (e.g. the path to the binary image file that we will render in the UI).

I believe @jcoyne had some perspective on the invariance of Collections and FileSet relations.

[elrayle]

RE: Will banner file (and logos) to be rendering in UI? YES, they are displayed on the public landing page.

RE: Custom predicate in Fedora

• If the file is stored outside of Fedora, why do we need a URI? A database table can be used to hold the relationship between the collection id and the file path.
• Per discussions in samvera-tech list, some expressed a desire for the image...
  • have option to draw it from an existing work
  • have it uploaded (This is what we are using for the sprint.)
  • have it be part of the preservation process
  • have it NOT be part of the preservation process

Obviously, the last two are conflicting. But if the image was part of a work AND we have the option to use an image from a work, then it would be part of the preservation process.

[jeremyf]

@elrayle I think, if we have a URI as what is stored, the data model doesn't need to worry about where it is stored. The upload process will need to decide where to put the banner image and report the resulting URI to the collection.

[ggeisler]

Per conversation with @blancoj and @elrayle, here are some more detailed mockups for the add banner and add logo interactions. Based on our discussion, I suggest the "Save" button label be changed to "Save branding changes".

Initial state with no banner and no logos selected

User uploads banner image

The uploaded image is displayed, but not saved to the database until the save button is selected.

User saves banner

After selecting the save button, the banner is saved to database. The remove button is now shown. This button should remove the banner image from display, but still requires selecting the save button to actually remove banner from database.

Banner exists but no logos selected

Assume the user has previously saved a banner and now visits the page to upload a couple of logos.

User uploads logo image

Because there are more elements associated with a logo image than just the image, when the first logo image is uploaded, display the logo information table. The Link URL and Alt text fields would be blank when first shown; the mockup assumes the user has filled those in. However, nothing is saved until the save button is selected.

User saves logo and selects Upload to add a second logo

[blancoj]

What remains to be done:

1. The interface for picking logo could be cleaned up a bit more to put 3 headers on the table - Active image, Link and Alt text (optional), and Action; and, also to make them striped.
2. rspec test for the collection_controler.rb need to change to test for all the new functionality. rspec for the view also need to be updated, and for the model.

[ggeisler]

@blancoj I haven't looked at your code so ignore this if not applicable, but you should just be able to add table-striped to the classes on the <table> tag to get striped rows.

[elrayle]

@ggeisler The view uses divs instead of tables. See PR #1569.

Screen capture from that PR... NOTE: I added <hr> dividers in place of alternating background. This could still use more work, but it seemed acceptable for a first round.

[elrayle]

Also, I went with the remove button the style shown in screen shot because that is what is used on the Description tab.

[ggeisler]

I think leaving out the alternating background color is fine (at least for now) as is going with the existing style for the remove button (though this is another aspect of the UI that might be inconsistent in other places).

There should not, however, be a Alt Text input for the banner. I think the banner is purely decorative and adding alt text for it would be result in screen readers reading something that provides no value to the user.

[elrayle]

Remaining Work:

1679 Collections: Remove alt text for banner on edit form Branding tab

[elrayle]

All requirements are either met or represented in other issues. Closing.