Skip to content

How can we improve Primo?

← Primo

Better Primo VE Menu Link Options

Custom menu links in Primo open in a new tabbed window. This is bad behavior. If I go back to the original screen and press the button again, it opens up another window in another tab, and so on.

Desired Behavior:
Menu link goes to address -- does not open a new window or tab. At the very least, it should have be an option for developers. Currently it is hard-coded in the html and not changeable. Using it leads to cluttered browsers.

46 votes
Vote

We're glad you're here

Please sign in to leave feedback
Signed in as (Sign out)
Close
Close
You have left! (?) (thinking…)
ward smith shared this idea  ·   ·  Admin →
How important is this to you?

We're glad you're here

Please sign in to leave feedback
Signed in as (Sign out)
Close
Close

We're glad you're here

Please sign in to leave feedback
Signed in as (Sign out)
Close
Close
Submitting...
An error occurred while saving the comment
  • Manu Schwendener commented  · 

    I follow Orbis Cascade Alliance's "Primo VE Toolkit" – thank you so much for making it public! – and found this by Tamara Marnell:

    https://www.orbiscascade.org/programs/systems/pcsg/primo-ve-toolkit/same-tab-menu-links

    The full code by Jeremy McWilliams from Lewis & Clark College is available via
    https://github.com/alliance-pcsg/ve-central-package/blob/8fddeb8bc6624958572638a6c0b0d9cb3a4100ac/01ALLIANCE_NETWORK-CENTRAL_PACKAGE/js/custom.js#L1320

    In Tamara's words:

    "However, this functionality could be provided in a much better way by Ex Libris, because they have control over components we don't. This code uses intervals to repeatedly check whether the menu links exist until they do, then changes their target properties. It's very inefficient because we don't have a better way to do it through customization packages, but Ex Libris developers would."

    I completely agree – please fix this, Ex Libris. All main menu links should open within the browser tab, unless the user decides otherwise.

    Also, the active browser tab should be visually distinguished from the inactive ones.

  • Jessica commented  · 

    >I don't agree. This should be the users' decision: if they want to open a link in a new tab, they can do so.

    Yes. Users should absolutely be able to decide if they want to open something in a new or same tab. But I think that's a browser issue.

    I'm talking about the default behavior hard coded into the HTML.

    Custom menu html links are currently coded with the attribute target="_blank" as an attribute, which opens in a new window or tab.

    Out of the Box menu links do NOT have this attribute, so they open in the same tab.

    OTB/sametab and Custom/newtab is technically consistent from a coding standpoint, but it's weird from a user standpoint.

    Ideally, an institution should be able to toggle each link's default behavior regardless of if it's custom or out of the box.

    But removing the target attribute from custom links (or addding it to OTB links) would at least create consistent (though not necessarily ideal) behavior.

  • Manu Schwendener commented  · 

    > That's external. It makes sense for it to be a new tab so that the user doesn't have to
    > navigate back to their search results.

    I don't agree. This should be the users' decision: if they want to open a link in a new tab, they can do so.

    (See also the two references in my first comment).

  • Jessica commented  · 

    Agreed. I understand opening a new tab/window for menu links with external URLS, but if the URL is internal, then it should open in the same tab.

    For example: We have a menu link that opens up a LibGuide. That's external. It makes sense for it to be a new tab so that the user doesn't have to navigate back to their search results.
    We also have a menu link that opens a new advanced search with options already checked for the user. This is an internal link to Primo (/discovery/search?) It does not make sense for that to open in a new tab when the other Primo search links (Collection Discovery, Newspapers, Journal Search, Library Search) open in the same tab.

    The fact that this behavior is very well documented as bad user interface design makes it baffling that Ex Libris hard coded this bad behavior into the Primo interface 20 years later.

  • Allan Berry commented  · 

    I'm surprised this still happens.

    Nielsen/Norman identified this over 20 years ago as bad practice:
    https://www.nngroup.com/articles/the-top-ten-web-design-mistakes-of-1999/

    Again, a decade later:
    https://www.nngroup.com/articles/top-10-mistakes-web-design/

    This is an insightful way to think about the issue:
    https://ux.stackexchange.com/a/53551/48949

    Other pages in the menu (those initiated by ExL) do not open new windows. This makes the menu internally inconsistent.

    Could there at least be a checkbox in the administration section to turn this on/off on a per-link basis?

Primo: User Interface

Categories

Feedback and Knowledge Base

(thinking…)