Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

include archive logo, address and contact link in finding aid viewer and archive browse #56

Closed
MomoMoses opened this issue Oct 21, 2021 · 19 comments
Assignees
Labels

Comments

@MomoMoses
Copy link
Collaborator

MomoMoses commented Oct 21, 2021

To demonstrate, choose Browse Archives from the home page. Select an archives, for example, the Harsh. The selected facet appears at the top of a results list for all collections from that archives.

Here is the mockup version of the page: https://uchicago.box.com/s/1laay3kuo5q9vdo6olbyid0991hyahea

At the top of the results list is a banner or content box going across with information about the repository -- this is a nice feature! the information and design appear in a smaller version in the sidebar of a finding aid.
image

@johnjung
Copy link
Owner

Could you add a link to the data I should use to populate this? Do we have a list of addresses, a link, and link text for each archive?

@MomoMoses
Copy link
Collaborator Author

Just sent the sheet to you -- also on Box -- with repo name and link. Need to copy over the addresses and supply link text for you. Wait on this -- I'll let you know when it's complete.

@johnjung johnjung added data and removed backend labels Oct 26, 2021
@johnjung
Copy link
Owner

Ok. I'm going to tag this as "data" for the time being- please let me know when it's ready.

@MomoMoses MomoMoses changed the title view all collections from one archives - is this mockup obsolete? view all collections from one archives - use mockup Oct 26, 2021
@johnjung
Copy link
Owner

Please confirm if this is https://uchicago.box.com/s/m26ngaznoxkl9skcfl6b45uz940x8rtx. (And please still let me know when it's ready for me to ingest.)

@MomoMoses
Copy link
Collaborator Author

MomoMoses commented Oct 27, 2021 via email

@johnjung johnjung self-assigned this Oct 27, 2021
@johnjung
Copy link
Owner

Based on the data, there are two different ways we can proceed here.

Option A is to allow site editors to be able to put whatever HTML they'd like into the archive info box. They will be able to enter information into the olive-colored rectangle in a free-form way, and that information doesn't necessarily have to include a mailing address and a link to the archive.

The advantage of option A is that it will allow people to easily include things like email addresses, or link text that is part of a larger paragraph about research at that archive, or anything else they can think of.

Option B is to put restrictions on the data, so a mailing address must look like a mailing address, and an email address must look like an email address. Links to each archive could become more regular too. Rather than specifying custom text for links in each case, each archive's link text will be produced automatically- but it would be a more generic message, like "Visit ."

I tend to like option B because it makes the interface nice and clean, however, the data currently includes idiosyncrasies that would be lost of we did this. If we go with option A, then editors can (and probably will) put all kinds of information into that box.

Which option do you prefer?

@MomoMoses
Copy link
Collaborator Author

I vote for Option A, with a caveat that I will produce content guidelines for the site. The flexibility is important. AND--generic links like "Visit" have known accessibility issues.

To explain my idiosyncratic link text approach:
https://www.nngroup.com/articles/writing-links/
https://www.nngroup.com/articles/learn-more-links/

@johnjung
Copy link
Owner

Ok, that's great. And agreed about generic links like "Visit."

Next, I see that there are some differences between the names of archives that we're currently using on the site, and the way those archive names appear in the spec. Here are a few examples, spec first, current site second:

Spertus Institute, Library and Collections
vs:
Spertus Institute, Library & Collections

Chicago Youth Centers
vs:
Chicago Youth Centers (CYC)

CPL-Vivian G. Harsh Research Collection, Woodson Regional
vs:
CPL-Vivian G. Harsh Research Collection

Which set of archive names should I use? Should I use the set in repoLinks.xlsx, or the ones that are currently on bmrcportal-test?

@MomoMoses
Copy link
Collaborator Author

MomoMoses commented Oct 28, 2021 via email

@johnjung
Copy link
Owner

Also, please provide a link to a folder containing the logos for each repository when you can.

@MomoMoses
Copy link
Collaborator Author

@MomoMoses
Copy link
Collaborator Author

some may be missing; I'll have the student worker take a look next week.

@MomoMoses
Copy link
Collaborator Author

Spertus uses the ampersand.
Leave off the (CYC).
Vivian G. Harsh Research Collection, Woodson Regional

@johnjung
Copy link
Owner

johnjung commented Nov 4, 2021

This information should also appear in the sidebar of the finding aid viewer- see this mockup.

@johnjung johnjung changed the title view all collections from one archives - use mockup include archive logo, address and contact link in finding aid viewer and archive browse Nov 4, 2021
@johnjung
Copy link
Owner

johnjung commented Nov 5, 2021

This is now implemented in b941c76 and live on the server. Please take a look when you have a chance- there are still some archives missing logos, so if you'd like me to keep this open and tag it as "data" just let me know.

Also, please note: adding repository information to the finding aid viewer sidebar increased the width of the sidebar in lots of cases. I'm going to deal with that issue in #51.

@MomoMoses
Copy link
Collaborator Author

Yes, do keep open as "data" -- I'll ask Warren to check on that this afternoon after 1pm.
Yes, the width is nuts!
I had thought perhaps it could be contained within a separate content block of some kind and styled differently so it wraps. Logo might be too large... thoughts? Not sure we specified this!!!

@johnjung johnjung added data and removed backend labels Nov 5, 2021
@johnjung
Copy link
Owner

johnjung commented Nov 5, 2021

In issue #51 I'll probably constrain the width of the logo to about 60% of the width of the sidebar to get it to match the mockup, and I'll figure out something appropriate for mobile too. Some of the logos are relatively low resolution- you might want to get higher-resolution versions to keep them from upsampling.

@johnjung johnjung assigned MomoMoses and unassigned johnjung Nov 5, 2021
@MomoMoses
Copy link
Collaborator Author

This looks good!👌

@johnjung johnjung closed this as completed Nov 5, 2021
@MomoMoses
Copy link
Collaborator Author

MomoMoses commented Nov 6, 2021 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants