Page MenuHomePhabricator

WS Export: open 'choose formats' link in new tab
Closed, DeclinedPublic


As a Wikisource user, I want the "choose format" link in the sidebar to open in a new tab, so I don't lose my place on the Wikisource page.

Background: In the process of migrating the WSExport gadget to the Wikisource extension, we received the following comment in T256392#6753267: "Have you considered adding a target = "_blank" attribute to the "Other formats" link so as not to "lose" the Wikisource page visitor?" Overall, this would help keep readers on the page they want to export, as is the behaviour when they use any of the other export links.

Acceptance Criteria:

  • When the "choose formats" link is selected in the sidebar, the link should open a new tab (rather than in the existing tab)

Visual Example of the link:

Screen Shot 2021-01-19 at 1.24.01 PM.png (653×1 px, 274 KB)

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript
ifried renamed this task from WS Export: open 'choose format' link in new tab to WS Export: open 'choose formats' link in new tab.Jan 19 2021, 6:26 PM
ifried updated the task description. (Show Details)

No, please don't. Forcing links to open in a new tab or window to keep the user on your site is literally a dark pattern in web design. Users are quite capable of opening a link in a new tab if they want to, and, conversely, those users who have trouble with this are also apt to be confused by navigating multiple tabs or windows.

The way to do such a thing, iff it is actually important, is to progressively enhance the process with a OOUI popup of some kind for this interaction. But the progressively enhance bit there is important: if I, as a power user, want to open that link in a new tab for whatever reason, I should be able to do so. I am also not up to date on the state of screen reader tech and how they deal with JS-generated page elements, which would be a primary consideration for the design of this. Last time I was looking at that in detail they would have had trouble dealing with it, but my information is a decade or so out of date. If it can't be done without accessibility tradeoffs I am having trouble seeing a positive cost—benefit for it.

I'd love not to see target="_blank" which as usual fails to outsmart me in knowing what I [didn't] want.

Thank you, @Xover & @Aklapper, for providing this context & perspective! This ticket was written after the request of another user (T256392#6753267), but we understand that not everybody will think this is a good idea. We (the Community Tech team) were already thinking about this as a lower priority request, and we didn't know if we would take it on, but these additional comments will also be something we need to consider deeply before proceeding with any of this work (if we do at all). I'll leave this ticket open for now, so others can share their ideas on this topic, if they would like. Thanks!

This project is done, so I'm closing this ticket.