66 results found

1. Increase Primo search capability to support major common search expansions on synonyms.

   Salesforce case #00583901 refers (unpublished)

   Ex Libris advises that, due to performance considerations, Primo search is unable to support the search expansion for the spelling variants that include the use of 's' or 'z' within a word. This is a common trans-Atlantic spelling variation, and omitting it has a significant impact on search results.

   Example: a search for the terms “practice globalisation” produces 441,248 results, but by changing the 's' in globalisation to a 'z', Primo produces an additional 12,000 search results.

   213 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   1 comment  ·  Other  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

2. Add an Abstract resource type for the Primo Central Index

   Primo Central Index contains many records for abstracts of conference papers that have been published in journal issues/supplements.

   These records are given the Article resource type in Primo. This confuses users, who when they find these items expect a full-length article instead of a short abstract.

   It also creates problems with link resolvers, which attempt to generate article-level links and fail (publishers usually do not provide these abstracts as individual articles).

   To fix this, Primo Central should be given a new resource type for abstracts.

   The sources for these records are usually large indexes such as Scopus or Web of Science, which already mark these items as abstracts. This would make it easy to reclassify items as the Abstract resource type.

   Primo Central Index contains many records for abstracts of conference papers that have been published in journal issues/supplements.

   These records are given the Article resource type in Primo. This confuses users, who when they find these items expect a full-length article instead of a short abstract.

   It also creates problems with link resolvers, which attempt to generate article-level links and fail (publishers usually do not provide these abstracts as individual articles).

   To fix this, Primo Central should be given a new resource type for abstracts.

   The sources for these records are usually large indexes such as Scopus or Web of… more

   168 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   3 comments  ·  Other  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

3. Enable the Hebrew Acronym file in CDI

   I would like the Hebrew Acronym file to work in the same manner for local and remote records and enable the correct retrieval of records with any of the many Hebrew words that are comprised of initials (eg פלמ"ח, תנ"ך, תשנ"א, אדמו"ר, בג"ץ, רמב"ם, מפא"י…….).

   Currently, searching a term either with or without the " sign will retrieve the term both with and without the quotation sign (") but ONLY for local records. Until this will work in CDI, many remote records will not be retrievable when searching terms that can be written in both ways (with or without the " sign).

   I would like the Hebrew Acronym file to work in the same manner for local and remote records and enable the correct retrieval of records with any of the many Hebrew words that are comprised of initials (eg פלמ"ח, תנ"ך, תשנ"א, אדמו"ר, בג"ץ, רמב"ם, מפא"י…….).

   Currently, searching a term either with or without the " sign will retrieve the term both with and without the quotation sign (") but ONLY for local records. Until this will work in CDI, many remote records will not be retrievable when searching terms that can be written in both ways (with or without the… more

   167 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   6 comments  ·  Other  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

4. [Primo] - frbr - improve algorythm - consider all keys and not only the first matching key

   In Primo FRBR documentation is explained that (I added ** signs):
   "
   In the FRBRization process, the keys are compared. If a record has a matching key with another record, it is added to the same FRBR group. Once a match is found, the system does not continue searching for matches since a record can belong to one FRBR group only.
   "
   In our experience this may lead to false positives. When comparing keys between frbr candidates, the system should consider instead the whole set of matching keys, not just the first matching one. And for example do not group records having more non matching keys than matching keys.

   In attachment an example where the books share the title and only 1 of the authors. This is not uncommon in case of exhibitions catalogues where the artist works together with the curators. FRBR considers the 2 different books as 2 different versions.

   Here are matching keys of the record proposed as example:
   Record 1 (2006):
   <frbr><t>1</t><k1>$$Kubzroyoux jean christophe$$AA</k1><k1>$$Kubzdean tacita$$AA</k1><k1>$$Kubzwarner marina$$AA</k1><k1>$$Kubzgreer germaine$$AA</k1><k3>$$Kubztacita dean$$AT</k3></frbr>
   Record2 (2004)
   <frbr><t>1</t><k1>$$Kubzde cecco emanuela$$AA</k1><k1>$$Kubzdean tacita$$AA</k1><k3>$$Kubztacita dean$$AT</k3></frbr>

   In Primo FRBR documentation is explained that (I added ** signs):
   "
   In the FRBRization process, the keys are compared. If a record has a matching key with another record, it is added to the same FRBR group. Once a match is found, the system does not continue searching for matches since a record can belong to one FRBR group only.
   "
   In our experience this may lead to false positives. When comparing keys between frbr candidates, the system should consider instead the whole set of matching keys, not just the first matching one. And for example do not group… more

   •  

   118 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   2 comments  ·  Other  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

5. Primo Central Index ( PCI ) - more granularity in excluding content from activated resources - e.g. exclude from index by resource type

   Right now in Primo Central Index the customer can either activate or not a resource. But sometimes more granularity would be appreciated. Namely adding a filter by resource type allowing inclusion or exclusion in the index would be very useful. Please note: it's not a matter of adding a resource type in PCI. It's a matter of excluding records with a specific resource type from activated resources.

   For example, some resources/data sources contains not only articles, but also journals and other resource types we actually catalogue. Since right now dedup does not work between local records and PCI, this ends up leading to a lot of duplicated entries in the search results (1 for the journal in the catalogue + 1 for the same journal in PCI).
   Allowing us to exclude Journals from PCI, thus having only articles, would greatly reduce noise and bias in the search results.

   Right now in Primo Central Index the customer can either activate or not a resource. But sometimes more granularity would be appreciated. Namely adding a filter by resource type allowing inclusion or exclusion in the index would be very useful. Please note: it's not a matter of adding a resource type in PCI. It's a matter of excluding records with a specific resource type from activated resources.

   For example, some resources/data sources contains not only articles, but also journals and other resource types we actually catalogue. Since right now dedup does not work between local records and PCI, this ends… more

   103 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   4 comments  ·  Other  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

6. Embargoed resources displaying in Primo

   Currently records from within an embargo period are discover-able to end-users via Primo.
   The user then thinks we have access to the records and selects it only to be presented with No full text available.
   Embargoed records are outside of our coverage range and should not display in our discovery interface.

   60 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   0 comments  ·  Other  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

7. CDI records: please provide us the ORCIDs in the PNX record in a usable form

   Unfortunately, we have received the following case response: "We have reviewed your request with our content operations team and determined that our system is currently not designed to provide the functionality you requested, so the next step is to pursue this as an enhancement."
   So we hope to get support for our proposal in the Alma community.

   We are currently working on making the ORCID more visible in our Primo (incl. linking to the ORCID entry of an author).

   We are glad to see that CDI records already contain the ORCIDs in the PNX record.
   Unfortunately, they cannot be used for normalization, because:
   - the XML fields <creator>/<creatorcontrib> list all authors of a record and the extra field <orcidid> lists the ORCIDs
   - however, the connection between these fields is missing

   It is not possible to find out which ORCID belongs to which author.
   Please provide us the ORCIDs in the PNX record in a usable form, so that we can create a link for those people who have an ORCID entry.

   Thank you in advance!

   Some PNX record examples:

   (1) TNcdiwebofscienceprimary000288028600012CitationCount
   Benefit of atrial septal defect closure in adults: Impact of age
   Humenberger, Michael ; Rosenhek, Raphael ; Gabriel, Harald ; Rader, Florian ; Heger, Maria ; Klaar, Ursula ; Binder, Thomas ; Probst, Peter ; Heinze, Georg ; Maurer, Gerald ; Baumgartner, Helmut
   OXFORD: Oxford Univ Press
   European heart journal, 2011, Vol.32 (5), p.553-560

   11 authors, 3 ORCIDs

   PNX record:
   <creator>Humenberger, Michael ; Rosenhek, Raphael ; Gabriel, Harald ; Rader, Florian ; Heger, Maria ; Klaar, Ursula ; Binder, Thomas ; Probst, Peter ; Heinze, Georg ; Maurer, Gerald ; Baumgartner, Helmut</creator>
   <creatorcontrib>Humenberger, Michael ; Rosenhek, Raphael ; Gabriel, Harald ; Rader, Florian ; Heger, Maria ; Klaar, Ursula ; Binder, Thomas ; Probst, Peter ; Heinze, Georg ; Maurer, Gerald ; Baumgartner, Helmut</creatorcontrib>
   (...)
   <orcidid>0000-0002-6902-126X ; 0000-0003-1147-8491 ; 0000-0002-9043-7657</orcidid>

   (2) TNcdicrossrefprimary101093eurheartj_ehq377
   Atrial septal defect: Waiting for symptoms remains an unsolved medical anachronism
   Berger, Felix ; Ewert, Peter
   OXFORD: Oxford Univ Press
   European heart journal, 2011, Vol.32 (5), p.531-534

   2 authors, 1 ORCID

   PNX record:
   <creator>Berger, Felix ; Ewert, Peter</creator>
   <creatorcontrib>Berger, Felix ; Ewert, Peter</creatorcontrib>
   (...)
   <orcidid>0000-0001-7881-1557</orcidid>

   (3) TNcdipubmedcentralprimaryoaipubmedcentralnihgov6194635
   Adherence to inhaled therapy and its impact on chronic obstructive pulmonary disease (COPD)
   Humenberger, Magdalena ; Horner, Andreas ; Labek, Anna ; Kaiser, Bernhard ; Frechinger, Rupert ; Brock, Constanze ; Lichtenberger, Petra ; Lamprecht, Bernd
   LONDON: Springer Nature
   BMC pulmonary medicine, 2018, Vol.18 (1), p.163-163

   8 authors, 2 ORCIDs

   PNX record:
   <creator>Humenberger, Magdalena ; Horner, Andreas ; Labek, Anna ; Kaiser, Bernhard ; Frechinger, Rupert ; Brock, Constanze ; Lichtenberger, Petra ; Lamprecht, Bernd</creator>
   <creatorcontrib>Humenberger, Magdalena ; Horner, Andreas ; Labek, Anna ; Kaiser, Bernhard ; Frechinger, Rupert ; Brock, Constanze ; Lichtenberger, Petra ; Lamprecht, Bernd</creatorcontrib>
   (...)
   <orcidid>0000-0003-3365-3449 ; 0000-0001-7746-3335</orcidid>

   Unfortunately, we have received the following case response: "We have reviewed your request with our content operations team and determined that our system is currently not designed to provide the functionality you requested, so the next step is to pursue this as an enhancement."
   So we hope to get support for our proposal in the Alma community.

   We are currently working on making the ORCID more visible in our Primo (incl. linking to the ORCID entry of an author).

   We are glad to see that CDI records already contain the ORCIDs in the PNX record.
   Unfortunately, they cannot be used… more

   53 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   1 comment  ·  Other  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

8. Advanced search functionality for the Newspaper Search

   Please provide advanced search functionality for the Newspaper Search. Users would like to limit searches by criteria such as publication name.

   37 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   3 comments  ·  Other  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

9. [Primo] - add tag delivery/fulltext to local PNX , thus improving blended search and full text availability information

   The feature "Expand My Results / Results with no full-text" allows to include in the search results PCI records with no full text. It relies on a pnx value in tag "fulltext" delivery section:
   <delivery>
   ...
   <fulltext>no_fulltext</fulltext>
   </delivery>

   The problem is that <fulltext> tag / field is not available in the Normalization Rule for local records.

   The consequence is for example that when we harvest data from our dpace institutional repository we may have fulltext, but sometimes we may have just metadata records. But without the delivery/fulltext field in the PNX we can't manage records with just metadata so that they are displayed only when Expand your results is checked. Records with no full text are now displayed with records with full text, making the behavior inconsistent and the label "Results with no full-text" misleading.

   We propose to add the <fulltext> tag / field also to the local PNX, so that we can create NR putting a fulltext/no_fulltext consistent value and having local records behave like PCI records do.

   The feature "Expand My Results / Results with no full-text" allows to include in the search results PCI records with no full text. It relies on a pnx value in tag "fulltext" delivery section:
   <delivery>
   ...
   <fulltext>no_fulltext</fulltext>
   </delivery>

   The problem is that <fulltext> tag / field is not available in the Normalization Rule for local records.

   The consequence is for example that when we harvest data from our dpace institutional repository we may have fulltext, but sometimes we may have just metadata records. But without the delivery/fulltext field in the PNX we can't manage records with just metadata so that… more

   24 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   0 comments  ·  Other  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

10. Allow blocking access to our Primo view outside of our campus IP, to allow access from only inside the institution.
    24 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    1 comment  ·  Other  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

11. Add the option to restrict PCI results for resources when only a physical manifestation of those resources exist in the library’s inventory

    If we have a physical book/journal in stock (item status could be anything: lost / on loan / available etc.)
    and we have PCI collections activated that happen to also include these titles,
    then
    Primo will display the PCI results for the electronic version of these Books + their chapters & Journals + their articles and present them as ‘Full text available’ with ‘View online’ tabs – even when we do not have access to the online version of the titles.

    This leads to an error message + makes for a confusing experience for staff and students. We understand from what Ex Libris have told us that this is expected Alma Primo behavior, but for our distance learners who require access to electronic resources this is problematic.

    If we have a physical book/journal in stock (item status could be anything: lost / on loan / available etc.)
    and we have PCI collections activated that happen to also include these titles,
    then
    Primo will display the PCI results for the electronic version of these Books + their chapters & Journals + their articles and present them as ‘Full text available’ with ‘View online’ tabs – even when we do not have access to the online version of the titles.

    This leads to an error message + makes for a confusing experience for staff and students. We understand from… more

    23 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    2 comments  ·  Other  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

12. Modify Primo display to use standard MARC holdings.

    We're migrating well-formed MARC holdings with 85x/86x pairs but Primo cannot use them for generating displays. Instead Alma must run a job to copy that data into 866 fields for Primo to be able to display them. Primo displays should make use of standard MARC fields/subfields (our 15 year old current system's public interface can do this)

    22 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    2 comments  ·  Other  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

13. ABC-CLIO Daily Life Through History

    Please add ABC-CLIO Daily Life Through History to Primo client resources index so it can be activated for discovery.

    22 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  Other  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

14. Field for MeSH-terms in CDI bib records to make it possible to search in advanced search

    MeSH-terms, primarily from PubMed, in CDI bib records are mixed with other subjects. Create a subject field for MeSH-terms and make them posisble to search via advanced search.

    21 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  Other  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

15. Primo smartphone inhabilitar bajada de archivos

    El material digital visualizado en Primo a través de smartphone permite bajar y copiar los archivos. Sería necesario para proteger derechos de autor inhabilitando esta opción.

    20 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    4 comments  ·  Other  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

16. The BibTex export from Primo does not include the DOI. Would it be possible to add the doi field? I know doi isn't a standard field in Bib

    Include the DOI in the BibTex export from Primo

    Would it be possible to add the doi field? I know doi isn't a standard field in BibTex, however it would be very useful and is requested by our users.

    20 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  Other  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

17. Send the same enriched query (stemming, synonyms, etc) to both local index and Primo Central PC index ( important for blended search )

    As default behavior, Primo not only looks for the patron's query, but according to the guessed language enriches the original keywords of the user with additional terms, in order to improve the performance. Linguistic features ( https://knowledge.exlibrisgroup.com/Primo/Product_Documentation/Technical_Guide/120Linguistic_Features ) may be customized by the systems librarian, for example removing or adding synonyms. But these changes affects only the results coming from the local index (i.e. the index built with records coming from the library's pipes for the catalogue, the institutional repository etc.). Primo Central (PC) records are not affected: for PC records the query enrichment is run separately and using the default synonyms, thus ignoring customization applied by the systems librarian.
    Expecially in a blended search, results may therefore result hardly explainable or misleading.
    To have a consistent behavior the enriched query used for local records should be the one used for PC records as well.

    As default behavior, Primo not only looks for the patron's query, but according to the guessed language enriches the original keywords of the user with additional terms, in order to improve the performance. Linguistic features ( https://knowledge.exlibrisgroup.com/Primo/Product_Documentation/Technical_Guide/120Linguistic_Features ) may be customized by the systems librarian, for example removing or adding synonyms. But these changes affects only the results coming from the local index (i.e. the index built with records coming from the library's pipes for the catalogue, the institutional repository etc.). Primo Central (PC) records are not affected: for PC records the query enrichment is run separately and using the… more

    19 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    1 comment  ·  Other  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

18. ahead of print

    More appropriate link resolving for "Ahead of Print" (pre-publish) articles.

    We recently had a report of problem linking for an "Ahead of Print" Primo article result. In this instance, linking resolved to an incorrect article - since it matched by keyword search at the journal.

    If better metadata cannot be obtained for "Ahead of print" articles, and these are not formally published articles, perhaps these results should not be included for Primo results -- or be able to be pulled into results in a separate facet?

    19 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  Other  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

19. Use an alternative to reCAPTCHA that's word based.

    Our patrons are having a hard time using the reCAPTCHA because of it being picture based. It's problematic to use it in Firefox and IE especially which we use on all of the campus computers. If we need a robot detector, can we switch to something that's word-based? These are also difficult for visually impaired patrons, but better than the photo test.

    18 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  Other  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

20. Citation Linker does not ignore initial articles

    The Journal search in the Citation Linker doesn't always ignore the initial article. I'm referring to "articles" in the grammar sense (the, a, an, etc). So for example, you get different "view it" results for Washington Post vs. The Washington Post. This isn't a huge issue, but it is confusing.

    17 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  Other  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close