UI/UX around connection fields for BN and VC

[paulhauner]

On the "configure connection" page, a couple of our team got stuck without realising that http:// is required. It might be nice to hint to the user that you need that prefix.

Here's some suggestions from me:

• Prefill the address field with http://localhost.
• Add a little bit of text to say that http/https prefix is required
• Show a specific error if they omit this part (we'd probably have to pattern match *://* or something, so we don't artificially limit protocols)

[daniel-flex]

@paulhauner there's a regex pattern match in there already, but might have to tweak it.

Also if we're going to revise the host part of the connection form to be more verbose or provide more control (#7), then I think it's natural that this update fits in there somewhere.

[paulhauner]

there's a regex pattern match in there already, but might have to tweak it.

Is this the warning that appears on the right? If so, can we move that over to the left, underneath the text input?

[AgeManning]

Perhaps if a protocol isn't submitted we default to http?

[daniel-flex]

I think we run this through UI/UX again with the new requirements and see what can be done. We can probably solve it here but I think design will have some better ideas.

considerations (feel free to update):

1. we need all parts independently configurable (protocol, ip/domain, port), with validation, for both BN and VC
2. do we want to have 6 editable fields on screen just for what the user may perceive as a single endpoint (might be too complicated)
3. do we hide most of it (how much of it?) behind a easy-to-digest 'summary' with the ability to open and configure?

Also considering when a user returns, they don't want to have to deal with it again, it should have everything saved and they just hit the connect button.

Could even consider having more options: save my data (which is does currently by default - in localstorage), and auto-connect, so it just connects them straight into the dahsboard.

[daniel-flex]

fyi current designs

[qnou]

Is it only the http/s protocol for connection? If so, it should be prefilled automatically and shown persistently, only the address afterwards should therefore be editable. If it is not the only protocol and we need to leave room for others, then as @AgeManning mentioned we should also have a default fallback to http. Will address #7 accordingly.

[daniel-flex]

@qnou for both the BN and VC endpoints, the user needs to be able to independently configure:

1. protocol: options will be http or https (I believe that's all)
2. ip/domain: either an ip address (127.0.0.1) or a domain name (mydomain.io)
3. port: 4-5 digit configurable port number (eg: 5689)

So it needs to be:

BN: [protocol][ip][port]
VC: [protocol][ip][port]

For point 1 (protocol), we could have it hardcoded with a checkbox for 'secure connection', which changes from http to https, but will still need it for both the BN and VC, and not sure if that's familiar UI/UX.

But in saying that, a single input field for each where the user enters everything in a single string, ie https://127.0.0.1:5052, would work too

[qnou]

Points 123 understood.
The reason the port and address were separated was based on the understanding the addresses would usually be the same.

That being said, need some context on: how common would it be for the BN and VC address to be different. so can adjust accordingly whether (progressive disclosure) or core part of UI.

[daniel-flex]

@qnou

how common would it be for the BN and VC address to be different

I'd presume they'd be more often than not on the same machine, but they could also have completely different domains/subdomains associated with them, meaning even if they're on the same machine the address could be completely different.

This would need some input/clarification from @paulhauner I think

[daniel-flex]

have merged #7 into this, as it's in the same problem space