[karambir]

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.

[dbbk]

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

[giancarlostoro]

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.

[z3t4]

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.

[madeofpalk]

There's not really much of a delimma. This is a problem that was solved in "single page apps" 10 years ago.

    - links are for navigation
    - buttons are for action

Styling and appearance are not a factor - you can make buttons look like links, links look like buttons.

Simple rule is "should this view have a url". Should the user be able to navigate directly to this page? Should it exist in the history? Should the user be able to share a URL to that page to someone else? Most times the answer to all of these is.

In your javascript application, it is trivial to do single page app view navigations (without triggering a full browser request) by listening to link clicks and acting on it just as you would if it were a button click. All frameworks and routing libraries will handle this for you out of the box. If you roll your own, its not that difficult to add this functionality.

[throwaway0885]

You're just making blanket assumptions about pretty hard UX problems.

Are tabs a view? Should they be buttons or links? What if the tabs are in the sidebar in some widget?

What about collapsible items? HN uses JavaScript to store your collapsible preferences to your account. Not shareable but consistent on page refresh. Is that good? I don't know.

The fact is, in PWA world, what's a links and what's a button is blurred, and there's nothing wrong with admitting it.

[dalore]

Should "book now" be a button or a link?

It is an action, but it navigates you to the booking page. That page should have a url and should be able to be shared. But wanting to "book now" is an action and most sites have them as a button.

[kaoD]

I will reword GP: if your <button> onClick navigates to another URL, your button is not a button but a link.

[vinniejames]

There is no dilemma. 99 times out of 100 the user is expecting a link (aka a browser history update) and a way to get back to that screen (an idempotent collection of data on that url).

[kall]

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]

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]

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.

[no_wizard]

You’re leaving out major accessibility differences when using a button vs anchor tags

[CapsAdmin]

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]

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.

[lucasverra]

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]

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.

[jchw]

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.

[MikeCoats]

In our in-house apps we went for the progressive-enhancement, almost-2 option.

When we're presenting data, one of our columns is nearly always a 'primary identifier' of some kind - a name, an id, etc. We make this column a hyper-link and then we also add a click handler to the row. This means it's still fully accessible to screen readers and tab navigators, but users who expect a more 'app'y experience are happy too.

The click handler has to be a little smart to ensure it's not receiving the mouse-up of a selection event, but it's not bad.