PUI pre-launch checklist

Not using the PUI? Not using OAI, or Docs? If so, consider turning these services off in your configuration file. (e.g. AppConfig[:enable_docs] = false)

You are going to use the new PUI? Here are some things to consider before you launch this service:

Sit down with your public services staff and explore all of the new features together. Talk about what adjustments your site will want to make to the application before going live.

Review the use of the "publish" checkbox in your staff site!!! Seriously, review this a few times, and consider adjusting any staff-side workflows if need be.
- In the new public interface, any agent record that is "published" will show up. Previously, these records also had to be linked to a material description record (resource, accession, digital object, or a component-level record) to show up in the public interface. Now, having them published will suffice.
- If you have the "publish" checkbox turned on by default in the staff interface, any time you add a new record or note that's published, that record will be indexed and added to your public interface in a matter of minutes. That said, if the new addition is a child of an unpublished ancestor, it still won't show up in the public interface until its parent or ancestor is also published.
- Do you import EAD records into your system?
  - If want these to be unpublished by default, and not added to your public interface shortly after they're imported, make sure to update your EAD so that the archdesc element will have an audience attribute set to internal.
  - Right now, any agent headings that are added during the EAD import process are unpublished regardless of what's in your EAD finding aid. Please note that you'll also need to publish any agents that are added via an EAD import before they will show up in the public interface.

Check out all of the configuration options that are in the config.rb file. To do that, search for "public" and "pui". Here are few things you'll want to consider:
- Do you want to suppress any of the seven links that are included in the primary navigation bar of the site?
  - Do you have more than one repository? If not, consider removing the repositories option from your primary navigation row of links (e.g. AppConfig[:pui_hide][:repositories] = true)
  - Do you have any digital object records ready to go? If not, suppress that link.
  - Same for classification records, which are labelled "Record Groups" in the new public interface by default.
- If you're not going to configure the Request action button to work with an email client, or replace it with another plugin, like the Aeon plugin, then you should turn off this action button before going live. (e.g. AppConfig[:pui_page_actions_request] = false)
- Once you choose a new URL and configure that in the application, make sure that all of the links work in the application (e.g. the homepage links from any of the pages in the interface, aside from the home page) and that your new link is also included in the Citation action button.
- Don't like the default inheritance settings? Good news. They're completely customizable, and you can even turn off inheritance altogether if you'd like (although I'd suggest keeping title inheritance at the very least, since archival objects don't need to have both a title and a date in the staff interface). Here's an example of modified inheritance features: https://gist.github.com/fordmadox/6f91ee378ae9d8a471bb8720fd6f2bd9

Review the labels and language in the public interface. If you need to make any updates, you'll want to get up close and personal with the new public YML files and override some of those values with a local plugin.

Don't like the default colors, icons, etc? To really overhaul the look and feel of your new public interface, you might need to create a new public.war file. However, you can do lot by overriding the CSS stylesheets in a simple plugin. Here's an example: https://github.com/YaleArchivesSpace/yale_pui_css

Want your site indexed by search engines? Of course you do! Once you're done testing your local configurations, be sure to update your robots.txt file so that the site can be crawled (and consider blocking crawls on "/search?" pages and anything else you don't want to show up as a search result). Here's an example set of disallows:
```
    
    Disallow: /search*
    Disallow: /inventory/*
    Disallow: /collection_organization/*
    Disallow: /repositories/*/top_containers/*
    Disallow: /check_session*
    Disallow: /repositories/*/resources/*/tree/*
```

Consider adding something so that you can track and evaluate online use of your new public interface. For instance, you could add Matamo (https://matomo.org/) or Google Analytics to your site. With either of those options, you might also want to use their "tag manager" feature to do more in-depth analysis, like tracking how often the accordions are used, the new action buttons, and possibly even to group finding aid page views together (i.e. so that you can combine the archival object page views with their respect parent-level resource record page views).

After you've launched, let the ArchivesSpace community know what works well in the interface and what doesn't. The public interface should evolve over time based on feedback from the community and your researchers. And please share any tips, tricks, or custom plugins that you decide to use. Here's an example: https://github.com/hudmol/aspace_yale_pui