Clicking Links Interrupts Music

[unusualbob]

Links in chat break the groove by navigating the page away from the music, they should open in a new window/tab

[martindale]

There are strong UX arguments against opening links in new windows and the WCAG (Web Content Accessibility Guidelines) requires the following:

Changes of context are initiated only by user request or a mechanism is available to turn off such changes.

I am strongly opposed to this as a solution to another underlying problem. Specifically, the issue is "Clicking links interrupts music," which has a known cause and a suggested solution, but as part of our mission we need to uphold standards and find a better way. The idealist in me wants to take absolutely no action in favor of deferring to the browser's settings, but the pragmatist in me realizes that some users do not care about standards and never will.

I see a couple potential actions we can take;

1. Add an option to enable this behavior to user preferences. This enables the desired behavior for those who wish it, but does not change browser behavior by default. This has wider-reaching implications that might result in undesirable complexity and application footprint; my main concern is with having a custom lexer per-user. I like this option, but we'll need to work through how to do it the right way.
2. Prompt user to confirm when an action will disable the playing of music. This has other painful implications (interrupting an expected action), but might be a necessary evil. Perhaps paired with a disabled-by-default user preference, we can offer a smooth experience.

Under no circumstances should any links on the site behave as something other than a link; users should always be able to 1) close the window without any prompt, 2) use one of the three methods available to open the link in a new context (a) right click, open in new tab b) ctrl+click c) middle-click). Several modern web applications break this behavior, but we should strive to be better.

What other options do we have?

[unusualbob]

Look I'm really just saying that 95% of people that use the internet expect it to just work, they click something and expect magic to happen. If that means preventing them from killing their music experience by opening things up in a new tab automatically then they want that. If they click something in chat that screws up their experience then people get madbro. Websites that have gained popularity have done so mostly by keeping a good user experience going.

List of sites that you may have heard of:

• Google+
• Twitter
• Gmail
• Facebook
• Youtube
• Plug.dj
• turntable.fm

They all open external links in new tabs. Millions of users. They do this because there's an ongoing experience they don't want to remove you from. For the social media sites thats the stream, for gmail thats the email application. Plug and turntable do it for the same reason we should, clicking links currently breaks the core functionality of the application and that should never happen.

[lakario]

Everything @unusualbob said.

[cannjeff]

Don't make me cmd+click, I will shank you.

[CrazyLittle]

If we're talking internal links to site functionality, then I agree with Martindale that it shouldn't open a new tab/window... BUT it shoudn't break the site's core purpose either. Perhaps a small "player" box in the corner would suffice. Barring a more elegant player on the page, we should at least implement a confirmation dialogue that gives the user the option to click-through, click-to-new, or cancel.

Also when considering standards we need to consider what the motivation behind the standard is. A lot of usability standards for the web are predicated on the idea of accessibility for all devices & all users. It doesn't make sense for us to follow a web standard that recommends against using sound on a page because deaf people won't hear it. Likewise it doesn't make much sense to try to reconfigure a web-color-palate picker to be screen-reader compatible for blind people. Standards-based CSS and design helps a lot, but it's not the panacea to all ailments.

Sorry if this is rambling. I whipped myself in the eye with a power-brick's cable this morning. RAAAAGe

[martindale]

@CrazyLittle agreed 100% on all points. I think @unusualbob is working on the Angular stuff we need to collapse the player to the header and turn the site into a single-page app as originally intended (granted, so long as the server still renders the pages on first pageload before the Javascript application takes over!). I've intentionally avoided manipulating links in any way until this is complete, which I think is causing a lot of attention to this issue and will persist until we finish this task.

I definitely think the standards question is relevant here, since it impacts all users. In the same spirit as #37, we should be careful to not implement features that fit a subset of desired audiences (in this case, users in a browser as a subset of clients) but degrades the semantic objective by modifying client behavior in an uncontrollable way. This is why I'm opposed to adding this as a default, but completely desiring of implementing whatever we determine to be the solution as an opt-in preference.

We should still aim to implement this at the browser level, outside of this discussion.

[khemikale]

Overwhelming consensus is that external site links should open in a new tab/window. This is what my vote goes toward. The people have spoken! It's so annoying to be jamming out when someone posts a link, to have your music taken from you. If we you guys are so adamant about being standards compliant, then put in an option to have this functionality defaulted per user.

[martindale]

Overwhelming consensus is that external site links should open in a new tab/window.

If this were actually true, we wouldn't be having this discussion. We need to evaluate this logically, specifically:

the issue is "Clicking links interrupts music," which has a known cause and a suggested solution.

I've laid out two options and have asked for more suggestions; let's think about the original problem before jumping to conclusions about the solution.

[unusualbob]

Look, I'm just going point to the fact that on day two that I was on this site you said no one was in charge. Now half the site at least has asked for this feature and you are literally the only person who has argued against it and are using your repo control to make the rest of the site bend to your will because you want your way.

Absolute power corrupts absolutely.

[martindale]

I completely understand your frustrations about not having your solution implemented, but that's an absurd argument to make about an open-source project whose entire existence is based around the idea that it can be forked and deployed freely. As repo maintainer, I have a duty to make sure that what gets merged in makes sense to this end. If you don't want to go through the process of discussing things like this logically, then you are free to maintain your own fork.

Additionally, I'm asking for input and ideas, and have made zero assertions about "my way". On the contrary, I've proposed a couple of solutions that are exactly opposite to what I want (client idempotence, see #37). I'm asking for other suggestions before we take action, so that we can come to the best logical solution.

I have no interest in power; only in building great software.

[unusualbob]

Really my issue at this point is that you said this was a democratic when we started and that is clearly not the case. What you are now saying is that you get to decide what is in soundtrack and what isn't and if anyone else doesn't like it then they can go make their own site. That's not a site I want to be a part of.

[martindale]

That's also a gross misrepresentation of everything I've said; it should be clear, after my first post and my most recent post, that we're having a public discussion about this for the very reason you're trying to say I'm opposed to. Let's get back on topic and figure out a solution instead of complaining about tangential and erroneous [1] things that are not relevant to actually solving the problem.

[1]: we have openly discussed building this as a federated site before, and that's still an open discussion. I think people can and should deploy their own versions, because that makes the idea (#1) that much stronger.

[unusualbob]

Alright well just so you know, there is a fix for this in #27 It defaults to _blank, however its easily disabled via an option I added just for you.

[CrazyLittle]

Can we at least fix the immediate pain now and implement a _blank target for links until a more permanent solution is implemented?

[damntourists]

Sorry but I have to agree with unusualbob. If so many main stream websites break WCAG, users will be used to that functionality. I don't think users are concerned whether or not we follow WCAG to a T. I think we should give the users what they ask for.

[fractaloop]

I agree that all chat links should have target="_blank" in them.

This whole argument seems absolutely ridiculous. Users are complaining daily about this.

[martindale]

Let's clear up a few things before this gets even more out of hand. Firstly, this is not a discussion about whether or not links should open in new windows. What I'm asserting is that any modification of a default behavior should be an explicit user choice. It is so critically important that we do not get distracted into trying to make decisions for other users.

Moreover, I'm asking for suggestions on how to implement a solution that meets the goals of this project. In lieu of other suggestions, we'll move forward with the original plan.

[fractaloop]

If you're not willing to receive community feedback for this issue then close this issue as wont fix and reopen a new thread that covers your intended goal.

[mikemimik]

What community feedback? No one has actually answered @martindale's question. @CrazyLittle has been the only one to even suggest something close. @martindale is asking for some ideas here, simply saying target="_blank" just because you can (and people do) doesn't make it a good solution. Moreover, that doesn't answer the question being posed.

[jDizzyYall]

Seriously?

Do this:

Add an option to enable this behavior to user preferences. This enables the desired behavior for those who wish it, but does not change browser behavior by default. This has wider-reaching implications that might result in undesirable complexity and application footprint; my main concern is with having a custom lexer per-user. I like this option, but we'll need to work through how to do it the right way.

But in the mean time - just make the damn chat links open in a target="_blank".

[fractaloop]

The issue was opened for opening chat links in a new window. The linkify changes introduced this bug as a regression and the community has clearly submitted their preference to have it reverted to previous functionality.

There has been ample argument in support of it (just read the thread). @martindale has dictated that the issue as requested will not be fixed. He is proposing a new feature instead of a regression fix and as such it makes sense to constrain that discussion and code to a separate issue and drop this thread.

[CrazyLittle]

Yeah I'm with fractaloop/diz/etc

It's pretty clear to me that the original intent of the bug filing was to simply put back target="_blank", and that solution has been proposed multiple times. Expanding that request into a larger question of web standards and overall site behavior really should be addressed in a separate discussion, and this particular issue should either be closed "not going to fix" or should be implemented as requested. Bigger solutions should be addressed on their own merits - not at the expense of the CURRENT user experience.

Even I pointed out, "BUT it shoudn't break the site's core purpose either" where clicking links stops the music on a website that's a "collaborative online jukebox." How would you like it if your CD player turned off every time you tried to read the cover art on the CD case?

[martindale]

I don't want to repeat myself yet again, but in lieu of suggestions beyond the original two we should keep this issue open until the problem is resolved. I've updated the title of the issue to reflect the scope.

@fractaloop the changes you made were openly recommended against in favor of modifying the pre-existing lexer (which I also addressed in the first post). I don't think anyone expected those modifications to change any link behavior, and the changes were quickly reverted for other reasons. This isn't limited in scope to the chat, either -- let's make sure we address all links and not just a small subset.

[fractaloop]

Given the original suggestions, I think going with a message popup as suggested in 2 is likely the best, and most effective option at the moment. It would help users at least have a chance to cancel the navigation and be simple to implement.

For the record, there were no chat links at all when I made those changes. It was a stop-gap fix that provided an avenue for improvement. It succeeded in both respects.

[jDizzyYall]

Option 2 requires more user-completed steps, which is undesirable.

Option 1 allows for a one time setting, which is acceptable.

[fractaloop]

I should add that while I support Option 1 for a long term implementation, this is a ongoing annoyance that users would likely prefer have an intermediate solution sooner rather than later. Option 2 can be implemented very simply as a window.onBeforeUnload handler that will ameliorate the issue until Option 1 is implemented.

[martindale]

One of the temporary fixes, #45, is now merged & deployed. You can now enable this new behavior via the settings icon. Thanks for the code, @fractaloop!

[zbeekman]

FWIW I like the way it is with the setting to allow you to decide if you really want to leave the page…. I consider this issue resolved… Just wanted to share my opinion.