The CSS/JS load Idea was closed - https://ideas.exlibrisgroup.com/forums/929326-esploro/suggestions/42304072-esploro-portal-and-home-page?tracking_code=c69bab7468ff8e896a94196d9e242aba
and proposed to open the new Idea
If there is specific functionality or customization option that we think we should add to Esploro, We have to open a dedicated idea for this idea and Ex Libris will be happy to evaluate it.

Please Vote:
We would like to receive the options in Esploro’s configuration pages to edit:

Home page and Portal:
Width of the page
Tabs
Headers
Font colors
Background colors

On the Portal
Logo size
Header height, background-color
Font colors - part of them is not readable - following Accessibility rules.
(Like email addresses > yellow on grey).
Persons' information location.
Width of the main page.
Accessibility menu - would like to be added or we can provide our accessibility menu, you can implement it into the Esploro home page and Portal page (it is not something we are going to change every day).

Currently, the Date facet in the research portal includes all types of dates associated with an asset (e.g. created, published, submitted, availability). Some of these dates may be used more for administrative purposes (i.e. we use Submitted for when items like ETDs were added to the repository, which may not be related to when the asset was created), and therefore should not be used for filtering search results for users.

Additionally, because not all of the date types display in the asset details, the search results when using the date facet can be confusing for users. If a user filtered to a certain date range, and results include assets that do not display dates within that range (but do include a date that isn’t displayed), it gives the impression that the date filter did not work correctly.

We would like for the Dates used for searching and faceting to be configurable for the research portal, specifically to be able to specify what date types are included.

Research outputs typically go through several different iterations or versions over the course of their lifecycle. NISO, for example, defines up to seven versions of scholarly journal articles http://www.niso.org/publications/niso-rp-8-2008-jav. In order to avoid confusion, support proper citation, and ensure compliance with publisher open access policies, it is critically important that institutional repositories clearly distinguish between different versions of the same work by prominently displaying this information in both the asset record and PDF cover sheet.

Esploro currently offers two options for communicating version: asset type and file type.

Asset type refers to the type of resource being deposited. When categorizing asset types, Esploro distinguishes between “Publications” and “Posted Content”. “Publications” refer to published works such as journal articles, book chapters, conference proceedings, etc. “Posted Content” refers to works that have not been formally published, which Esploro defines as working papers, preprints, and accepted manuscripts. Each asset can be assigned only one asset type. Asset type values are predefined and not customizable.

File type is used to describe the individual files or external links associated with an asset. The list of default values consists of a mix of terms used to indicate format (text, image, audio, video) and version (preprint, submitted, accepted, published, correction). Unlike asset type, however, file type values are customizable. Although choosing a file type is not required for deposit, this is the field Esploro uses to display version information on PDF cover sheets.

We believe the overlapping use of asset type and file type to capture version information is a potential source of confusion and data inconsistency. For example, if a researcher wishes to deposit an article that has been accepted for publication, should they deposit it as an "Accepted Manuscript" or as a "Journal Article" with the file type "Accepted"? Either is possible but having two ways to deposit the same work will likely confuse researchers. This inconsistency also creates problems for discovery and analytics. For example, if a user wanted to obtain a list of all preprints, they would only retrieve those defined at the asset level as opposed to the file level. Meanwhile, version information only appears on cover sheets if it specified at the file level. Avoiding this confusion seems to require a single, consistent model for representing versions in Esploro.

Ultimately, we don’t think it makes sense to manage version as an asset type or a file type; it is neither. Instead, we recommend version be managed as a completely separate field. When a researcher deposits an asset, they should be prompted to select the version of the asset being deposited. This information should be prominently displayed in both the asset record and cover sheet and be queryable in Analytics.

We further recommend that Esploro allow researchers to submit new versions of previously deposited works. Different versions of the same work should either be FRBRized or displayed in a way that directs users from superseded version(s) to the current preferred version.

i. When depositing an asset, prompt researchers to indicate if the asset is a new version of a previously deposited work.

ii. If the asset is a new version, allow the researcher to select the previous version from a list of their previously deposited assets.

iii. After the previous version has been selected, a) auto-populate the deposit form with the metadata from the previous version, and b) automatically link the old and new versions via the appropriate relationships (is new version of / is previous version of).

iv. Once the new version has been approved, either a) FRBRize all versions with the latest as the preferred record, or b) exclude the previous version from search indexing (but continue to allow it to be accessible via DOI) and add a prominent note notifying users that this version has been superseded and directing them to the latest version.

To summarize, we believe the following enhancements would significantly improve version control in Esploro.

1) Create a single, dedicated, and prominently displayed field for version

2) Allow researchers to easily deposit new versions of previously deposited works

3) FRBRize different versions of the same work OR provide some mechanism for identifying and directing user to the latest or preferred version of a work

Currently, the file label displays in the File Viewer above the file itself and appears as prominently as the title of the asset (same font and size). For the thousands of assets we migrated to Esploro, this file label is by default the file name, which references the ID number of the file in our previous repository and nothing else (e.g., no author, title, year). This is not at all helpful to our patrons and is frankly quite ugly. So I would recommend that you add a job to edit and/or suppress the file labels in batch. Right now we can edit the file labels individually, but it's not practical for us to edit thousands of them that way.

Here at RMIT University, we would like to make available our open access repository content to Unpaywall. https://unpaywall.org/

In order to do this, Unpaywall have advised us of two changes that need to be made to our OAI-PMH output to enable harvesting by them.
Firstly, they require us to configure our OAI-PMH to include clear identifications of the versions of the attached open access files, i.e.. Published Version, Accepted Manuscript and Submitted Version.
These descriptions are used in our current Esploro Repository instance and it would be ideal if these could be included in our OAI-PMH output. Unpaywall have recommended this be structured as follows:

<dc:type>publishedVersion/dc:type
when you have verified that the PDF you are hosting is the version of record, with all publisher copyediting and formatting.

<dc:type>acceptedVersion/dc:type
when you have verified that the PDF you are hosting meets this definition of acceptedVersion.

<dc:type>submittedVersion/dc:type
when you know the PDF you are hosting does NOT meet the definitions for publishedVersion or acceptedVersion (for example if it was uploaded before the paper was accepted for publication)

Secondly, Unpaywall advised us to make harvest of our content possible, the OAI-PMH component of the repository to include PDF URLs for all Esploro Repository records that have them.

Unpaywall will harvest those records that have both an open access file attached and a DOI registered in Crossref.org and this will serve to significantly promote our repository content and increase the opportunity to increase impact of our researcher's publications.

Thanks
Keely

We would like to track presentations, grants, student art exhibits, performances, and other activities that would qualify as artistic or scholarly outputs by students completed as part of their studies. We would like to add students (via their Alma profile) as Creators or Contributors to research assets. However, it doesn't seem like we can do this unless we add students as researchers. We do not want to create researcher profiles for students. Esploro allows tracking of these via ‘Assets’ but students can only be manually added, instead of imported from their Alma user record. This prevents us from running analytics that includes student identifiers (e.g. ID number, email address) that could be used by our Institutional Effectiveness office to report outcomes of the academic program.

Enhancement request - add ability to add student Alma accounts as ‘Authors’ or ‘Contributors’ to Assets. This would link student contributors to Alma records so that identifiers can be searched in Analytics. ETDs already allow for this.

An alternative would be to modify the ETD submission form to include these types of submissions, but I don’t know the long-term implications of this but would welcome feedback on either of these options as we make plans to add student assets to the system.

Though many Esploro researcher deposits naturally disappear from the research deposits queue as part of their lifecycle -- approved, returned to researchers, etc. -- for deposits that for one reason or another have to remain in the deposits queue for an extended period, a type of internal note explaining their presence in the brief display would be very helpful.

In our case, our library does the work of seeking OA permissions for deposits, leaving deposits in the queue awaiting responses for a period of days, weeks, and in rare cases months. As you may imagine, this can build up very quickly, and with no obvious indices why the deposits are still there. We already keep "For follow-up" notes of this type in the records, but we have to click into the record to read them; if this or a similar note could display in the brief display, it would make managing dozens of in-limbo deposits much easier. Thank you!