6 ms·

Awesome collection! One thing I am always curious about, the right click and open in new tab does not work on the list items. I have seen this on many recent JS

Awesome collection! One thing I am always curious about, the right click and open in new tab does not work on the list items. I have seen this on many recent JS heavy web applications. Is this normal for PWAs to not support traditional browser interaction points? I can understand PWA wants to be more than just a web page and have their own UX. I have more experience in Backend software development and right now leading a small web/mobile/devops team, and always stress to not override browser controls unless absolutely necessary. Somewhat similar thing happens with scrolling. I feel most of the JS overridden scrolling is not needed.

lucasverra 6y ago
As a pwa maker, your point hit the nail on the head. In pwa we have w & a For the app part, ux generally does not allow you to right click or pinch & zoom. For the web part, it does. The best compromise is media queries and have some ux for mobile and another for desktop. From a business point of view, im not sure final user will value that investment
- CapsAdmin 6y ago
  You can long press on links on mobile to open the right click menu so you can then open a link in a new tab. :) On iOS you even get a preview window with the links' content when using Safari. But I assume few people do this, so your last point applies.
CapsAdmin 6y ago
They would need to set the href attribute that points to the url on the card. After doing that you need to prevent the browser from actually going to that url when clicking on the card to prevent a full page refresh. I think this happens a lot nowadays because we create and style div elements from scratch while also hooking onto more fundamental events and preventing any browser behavior.
- dragonshed 6y ago
  When building webapps I like to keep a list of nit picks for ux and usability issues (usually things I find myself that aren't directly related to feature stories) and I fight to schedule as many passes as possible for fixing them. It tends to be difficult because no one besides artists and ux engineers will want to prioritize/pay-for them. I will also sneak in a pass when I finish something that unexpectedly takes less points to finish.
z3t4 6y ago
You often have the dilemma whether something should be a link, or just a button. Links trigger a navigation to another page/URL, although in an "app" it could just render a new view rather then making a new browser request. A button is usually not a navigation, although it can render a new view and also have a unique URL. So the only difference is that you can right click and open in new tab on links, but not on buttons. And then you have to decide if you should style it like a button element or a:href element, where a:href signals to the user that they can right click and open in new tab, while a button does not. But you can also make an a:href look like a button, which can be considered an anti-pattern. Buttons do look nicer then links though. And buttons can also trigger a navigation, like in a form submit, but it's technically difficult to support submitting and open in new tab at the same time, because browsers have a hard separation between tabs, where one tab can't easily access another tab and vice versa. So while it's technically possible UX is often a matter of budget/laziness and stack/architecture.
- kall 6y ago
  That's actually a heuristic I often use to decide this dilemma: Would I want to open this in a new tab / copy the link? In terms of styling, I like to start both from zero so that a button "look" can easily be a link (like "learn more").
- wyqydsyq 6y ago
  Yeah it's a trade-off and button links what this person would be experiencing. General best practice IMO is any navigation link/button that is just some permalink like a profile page should be an a tag to support natural browser interactions like open in new tab or bookmark link, it also helps crawlers index your app if the interface in question is some sort of public directory you'd like indexed and has SSR. Only navigation based on ephemeral state (submitting forms etc) to things nobody would typically share a link to (logout URL, submit button going to a thankyou page) should be buttons.
  - lstamour 6y ago
    Yeah, another way of putting it is a link is great for GET requests while a button is better for POST requests (form submissions, AJAX, etc.) If you use a link for these, you have to think about what the href points to, you can’t just use JavaScript alone when it’s a link. If it’s a button, JS is more acceptable due to the inability to open new tabs, etc.
jchw 6y ago
In my personal experience, the real problem is when there's an impedance mismatch in the web platform. Here's an example. Let's say you have some tabulated data. So, being a good developer, you use a <table>. Done. Then, you want to make the rows clickable. Oops. You can't nest table row <tr>s within anchors <a>, so you have a few options: 1. Each column has a link, and the link extends to the width of the containing cell. Pros: It's easy to implement. It doesn't break browser behaviors. Cons: There's unintended holes in the click targets. It's ugly as sin in code. It is quite confusing for screen reader users. It may be hard to get this right if your cells contain more layout than pure text. All in all, it's not an elegant solution. 2. Instead of making it a link, override the behavior of clicking on a row by registering a click event handler. Pros: It does what you want. It's easy to generalize. It's a little bit of a kludge but certainly less hacky than 1. Cons: It requires extra work to make it work well with screen readers. It requires extra work to make it work well with ctrl clicking and other behaviors - in fact, many webapps that apply this approach actually emulate the browser behavior, which, imo, is horrifying. Right clicking no longer gives contextual options for links, since there is no real link. 3. Restructure the DOM to not use a <table>. Perhaps use `display: table` with plain divs. Pros: Now you can use a proper anchor tag link. It's also fairly easy to generalize. It shouldn't require too much work to get working well with screen readers. Cons: Although it's less of a kludge in the end, it has one annoying flaw: just to get this behavior, you have to completely restructure your document. Which leaves you with choices: Should all tables be structured using other HTML elements instead of <table>? Ultimately, some applications end up with trouble where anchor links are pretty hard for one reason or another. I don't think PWA or JS developers generally strive to break things or needlessly reimplement them; everything from client-side routing to custom link event handling has a reason to exist, and usually the intent is to make things work as well as possible. That having been said, I've noticed a great deal of issues even with mature frameworks. For example, if you go to a really heavy PWA that has proper anchor links for fallback, try ctrl+clicking the anchor links and see what happens. You might find that it navigates in the current tab and spawns a new window! (Note: I'm not suggesting this example is perfect; you could probably argue about whether the tabulated data should ever have clickable rows, or something like that. Still, it is a real thing that I've come across a few times now, and there's some pretty similar siblings to this problem.) edit: Oh, and on a historical note... some of you who also were early adopters on XHTML will remember that in XHTML, you could actually put an href attribute on more elements, allowing you to get the behavior on list items, spans, etc. Sadly, it was never widely implemented.
dbbk 6y ago
This isn't normal, it's a mistake. They should be normal links.
giancarlostoro 6y ago
They could absolutely fix the URL thing. At least if they are using a routing library at all they can. Even if they arent they could very well manage routing as well.

lucasverra 6y ago

As a pwa maker, your point hit the nail on the head. In pwa we have w & a For the app part, ux generally does not allow you to right click or pinch & zoom. For the web part, it does. The best compromise is media queries and have some ux for mobile and another for desktop. From a business point of view, im not sure final user will value that investment

CapsAdmin 6y ago
You can long press on links on mobile to open the right click menu so you can then open a link in a new tab. :) On iOS you even get a preview window with the links' content when using Safari. But I assume few people do this, so your last point applies.

CapsAdmin 6y ago

They would need to set the href attribute that points to the url on the card. After doing that you need to prevent the browser from actually going to that url when clicking on the card to prevent a full page refresh. I think this happens a lot nowadays because we create and style div elements from scratch while also hooking onto more fundamental events and preventing any browser behavior.

dragonshed 6y ago
When building webapps I like to keep a list of nit picks for ux and usability issues (usually things I find myself that aren't directly related to feature stories) and I fight to schedule as many passes as possible for fixing them. It tends to be difficult because no one besides artists and ux engineers will want to prioritize/pay-for them. I will also sneak in a pass when I finish something that unexpectedly takes less points to finish.

z3t4 6y ago

You often have the dilemma whether something should be a link, or just a button. Links trigger a navigation to another page/URL, although in an "app" it could just render a new view rather then making a new browser request. A button is usually not a navigation, although it can render a new view and also have a unique URL. So the only difference is that you can right click and open in new tab on links, but not on buttons. And then you have to decide if you should style it like a button element or a:href element, where a:href signals to the user that they can right click and open in new tab, while a button does not. But you can also make an a:href look like a button, which can be considered an anti-pattern. Buttons do look nicer then links though. And buttons can also trigger a navigation, like in a form submit, but it's technically difficult to support submitting and open in new tab at the same time, because browsers have a hard separation between tabs, where one tab can't easily access another tab and vice versa. So while it's technically possible UX is often a matter of budget/laziness and stack/architecture.

kall 6y ago
That's actually a heuristic I often use to decide this dilemma: Would I want to open this in a new tab / copy the link? In terms of styling, I like to start both from zero so that a button "look" can easily be a link (like "learn more").
wyqydsyq 6y ago
Yeah it's a trade-off and button links what this person would be experiencing. General best practice IMO is any navigation link/button that is just some permalink like a profile page should be an a tag to support natural browser interactions like open in new tab or bookmark link, it also helps crawlers index your app if the interface in question is some sort of public directory you'd like indexed and has SSR. Only navigation based on ephemeral state (submitting forms etc) to things nobody would typically share a link to (logout URL, submit button going to a thankyou page) should be buttons.
- lstamour 6y ago
  Yeah, another way of putting it is a link is great for GET requests while a button is better for POST requests (form submissions, AJAX, etc.) If you use a link for these, you have to think about what the href points to, you can’t just use JavaScript alone when it’s a link. If it’s a button, JS is more acceptable due to the inability to open new tabs, etc.

jchw 6y ago

In my personal experience, the real problem is when there's an impedance mismatch in the web platform. Here's an example. Let's say you have some tabulated data. So, being a good developer, you use a <table>. Done. Then, you want to make the rows clickable. Oops. You can't nest table row <tr>s within anchors <a>, so you have a few options: 1. Each column has a link, and the link extends to the width of the containing cell. Pros: It's easy to implement. It doesn't break browser behaviors. Cons: There's unintended holes in the click targets. It's ugly as sin in code. It is quite confusing for screen reader users. It may be hard to get this right if your cells contain more layout than pure text. All in all, it's not an elegant solution. 2. Instead of making it a link, override the behavior of clicking on a row by registering a click event handler. Pros: It does what you want. It's easy to generalize. It's a little bit of a kludge but certainly less hacky than 1. Cons: It requires extra work to make it work well with screen readers. It requires extra work to make it work well with ctrl clicking and other behaviors - in fact, many webapps that apply this approach actually emulate the browser behavior, which, imo, is horrifying. Right clicking no longer gives contextual options for links, since there is no real link. 3. Restructure the DOM to not use a <table>. Perhaps use `display: table` with plain divs. Pros: Now you can use a proper anchor tag link. It's also fairly easy to generalize. It shouldn't require too much work to get working well with screen readers. Cons: Although it's less of a kludge in the end, it has one annoying flaw: just to get this behavior, you have to completely restructure your document. Which leaves you with choices: Should all tables be structured using other HTML elements instead of <table>? Ultimately, some applications end up with trouble where anchor links are pretty hard for one reason or another. I don't think PWA or JS developers generally strive to break things or needlessly reimplement them; everything from client-side routing to custom link event handling has a reason to exist, and usually the intent is to make things work as well as possible. That having been said, I've noticed a great deal of issues even with mature frameworks. For example, if you go to a really heavy PWA that has proper anchor links for fallback, try ctrl+clicking the anchor links and see what happens. You might find that it navigates in the current tab and spawns a new window! (Note: I'm not suggesting this example is perfect; you could probably argue about whether the tabulated data should ever have clickable rows, or something like that. Still, it is a real thing that I've come across a few times now, and there's some pretty similar siblings to this problem.) edit: Oh, and on a historical note... some of you who also were early adopters on XHTML will remember that in XHTML, you could actually put an href attribute on more elements, allowing you to get the behavior on list items, spans, etc. Sadly, it was never widely implemented.

dbbk 6y ago

This isn't normal, it's a mistake. They should be normal links.

giancarlostoro 6y ago

They could absolutely fix the URL thing. At least if they are using a routing library at all they can. Even if they arent they could very well manage routing as well.