Light-client: I would like to flip between all available channels for the token I've selected directly at the transfer screen

[taleldayekh]

User Story

As Chris I would like to flip between all available channels for the token I've selected directly at the transfer screen so that I see how much capacity I have got and in which status my channel is.

Acceptance criteria

• Channels should be moved to the transfer screen
• Channels on the transfer screen should be displayed as a "carousel"/slider
• Top left channel button should be removed
• Top right deposit button should be removed

Question

• What is the capacity above „TestToken“ on the top?
  
  
  
  • If it is the total capacity of all channels we keep it
  
  

Visual

Tasks

• [ ]

[taleldayekh]

Relates to on-going discussions in issue #571 . Also, see that issue for some questions regarding channel capacity that needs to be sorted out.

cc @christianbrb

[christianbrb]

Related #364

[andrevmatos]

Is this only to see capacity? Or somehow to select an outgoing channel? Because the later depends on PFS's response, and we may need to ensure it doesn't misled the user into thinking they're selecting a channel to transfer through.

[taleldayekh]

I agree @andrevmatos . It could be both, we need to discuss what is doable and then make sure the UI does not misslead the user.

[taleldayekh]

In issue #571 @andrevmatos mentions that the common case is for it to be only one channel per token network.

If so each card would represent one channel in one token network with the input fields/button for making a transfer corresponding to respective card.

I don't understand why we are making it possible to have multiple channels when:

1. The common use case is to have one channel per token network
2. We are preventing the user to choose which channel to transfer from

Is it to enable direct transfers?

I think it will be difficult to solve the second use case (letting the user have multiple channels) with the restrictions brought on by the first use case.

[andrevmatos]

Because we can't prevent more than one channel to exist (user can open through other means, full-client's channel manager can chose us to connect to, etc). What we can do is code for the standard case, guide/wizard the user to it, but still have some capability to deal with the reality, in form of basic channel management actions.

[taleldayekh]

Yes, that makes sense.

It is still unclear for me what the technical limitations are that prevents us from implementing the possibility to manually select which channel to make a transfer from (like in the web ui). From a user perspective it seems like something you would want to do in an app where you have more than one channel?

Or, perhaps an alternative is to make the dApp display only the channel that was opened using the dApp itself and make it disregard channels opened through other means. Is there any reason we would want to display other channels than the one that was opened when using the dApp?

This is just brainstorming and some opening thoughts before our planning because I don't know the exact technical limitations.

[taleldayekh]

Of course we can keep it the way it is and add Transfer to a separate menu that makes it clear that it is not related to the channel currently displayed but rather a "global" action that selects the channel with the highest capacity. This was/is the initial idea.

[andrevmatos]

It is still unclear for me what the technical limitations are that prevents us from implementing the possibility to manually select which channel to make a transfer from (like in the web ui)

The main thing is that we're constrained by the routes provided by the PFS, which may or may not include the "selected" channel. Also, the webUI is a bit misleading on it. All it does is pre-fill the target address with that of the partner, which most likely will trigger the direct transfer, but could not: e.g. if you have a channel with A with capacity=5, and a channel with B with capacity=10, and B with A with capacity=12, if you go to the webUI, click to pay "through" a channel and try to transfer 8, it won't go through the direct route, as it doesn't have capacity, but instead request an alternative route from the PFS and if found (through B), use it.

From a user perspective it seems like something you would want to do in an app where you have more than one channel?

I'd rather not. I'd think the user shouldn't care much about which channels are being used for a payment, but just think on channels as just "resources" that connects them to a Token Network, and then they can perform transfers on this TN, not on the channels.

Or, perhaps an alternative is to make the dApp display only the channel that was opened using the dApp itself and make it disregard channels opened through other means. Is there any reason we would want to display other channels than the one that was opened when using the dApp?

I think this isn't good either. If we're recovering state, it can be very hard to know which channel was opened by us. I'd rather have minimal support for multiple channels (like managing them) but users just transfer on a token network and don't care much about in which channel a transfer is going to happen or did go through.

[christianbrb]

About swiping

• On mobile: https://medium.com/app-partner-academy/the-psychology-of-swiping-in-apps-464895b2b485
• How to transfer to the desktop: https://www.nngroup.com/articles/horizontal-scrolling/

[kelsos]

@taleldayekh on the WebUI having the pay button on the channels was actually misleading for a lot of people and we considered removing it a few times already. We were discussing it when we were evaluating the WebUI redesign. We should avoid creating a visual link between channels and transfer, because this has been a great source of confusion for people in the past.

[taleldayekh]

Thanks for you input @kelsos and @andrevmatos . It sounds like the initial approach of having a separate menu for making transfers which is independant of the cards is the way to go.

[taleldayekh]

we may need to ensure it doesn't misled the user into thinking they're selecting a channel to transfer through.

This will then only be a problem in the first iteration because moving the transfer fields to a separate menu is not in the scope of the iteration.

[taleldayekh]

One more thing, maybe it is a good idea to rethink the common use case.

To me it seems like the common use case is not only one channel per token. If the users have the freedom to open as many channels as they like elsewhere I would argue that the common use case as it is defined now is more what we wish to be the common use case.

[christianbrb]

An alternative would be to flip through the tokens.

Another perspective

Removing it from the product backlog as it is an important point, but not urgent atm.

[christianbrb]

Good collection an discussion, but not actionable. Closing.