UX improvement during Sign Up

[cchirag]

Feature Description

During the Sign Up process, the user has to input his/her signature. The experience of trying to sign in a place using mouse or trackpad is bad and the result might be inaccurate. The feature might be to let the user shift to a mobile device (mostly touch screen these days) for making the initial signature without loosing the context in the desktop.

Use Case

Use case is when a user has to sign up to the app using his/her desktop or laptop. I faced this issue while registering myself and quickly understood that the UX could be improved.

Proposed Solution

Proposed solution is:

• Start a session with a session ID and generate a QR code with link to a web page and the session ID as it's param.
• This QR can be displayed within a tooltip, next to the signature field.
• Users who want to sign using a mobile device can easily scan the QR and be taken to the page with the session ID.
• This page consists a simple area where users can sign and it will be in sync with the desktop (Same session) using Sockets.
• Once signed, the user can proceed with the registration flow and the webpage (generated using the Session ID) is invalidated.

Alternatives (optional)

No response

Additional Context

No response

Please check the boxes that apply to this feature request.

• I have searched the existing feature requests to make sure this is not a duplicate.
• I have provided a detailed description of the requested feature.
• I have explained the use case or scenario for this feature.
• I have included any relevant technical details or design suggestions.
• I understand that this is a suggestion and that there is no guarantee of implementation.
• I want to work on creating a PR for this issue if approved

[github-actions]

Thank you for opening your first issue and for being a part of the open signing revolution!

One of our team members will review it and get back to you as soon as it possible 💚

Meanwhile, please feel free to hop into our community in Discord

[cchirag]

Would like to work on this feature, if approved.

[dguyen]

Hey @cchirag!

This is a feature we have been researching in our backlog for a while to improve the signature workflow for all places where signatures are required.

There are some considerations we are waiting on, such as:

• UI/UX Design
• Implementation choice (WebRTC/WebSocket/etc)

Since we're still researching this, our desired outcome might end up being different to yours, which will mean we can't guarantee merging your solution.

If you want, you can work on this issue and we will review it to see if it fits our purposes.

[cchirag]

Thanks @dguyen . Will keep you guys posted

[cchirag]

Screen.Recording.2024-05-07.at.5.44.51.PM.mov

Hey @dguyen,
This is a small demo that I created using Socket IO.

• When the signup page loads, it creates a UUID and joins a room with the same ID.
• The QR code that is displayed at the bottom of the signature field is the QR code that can be scanned to take the user to the other page.
• In the second page, we join the same room (room ID is passed as path param) when the page is loaded. This brings both the pages in sync as they are connected through the common channel, the room with room ID.

There are many things that needs to be refined here, like:

• Where to place the QR code?
• How is the second page styled?
• How do we handle the width difference in canvas.
• Can we add different colours for stroke (Another feature).

Please feel free to share your thoughts so that I can continue with improving or changing things wherever necessary.

[dguyen]

Hello!

Are you using a custom server for socket.io?

If so I don't think Vercel supports that

[cchirag]

Ohh okay. I was trying a different approach with trpc subscriptions. Let me check and get back.

[cchirag]

Hey @dguyen,
I have been searching around Next JS and Vercel documentation for Websocket implementation but there seems to be an issue with WS and Vercel.
Since Vercel uses serverless functions, the connection cannot be of indefinite time. Therefore, implementation of websocket or any realtime data transfer protocol seems unachievable.
Versel itself suggests using third party providers to achieve realtime features.
I was looking at other alternatives and polling (I know that it is not very efficient) is an option we can look into.
Please do tell your opinion on this approach.

[dguyen]

Thanks for looking into that! We're very against being vendor locked for features so I think websockets are out

Have you had a look at WebRTC? That was probably going to be our choice of communication method between devices

Also just a note in your demo, you have the devices bi communicate on the signature canvas whereas we only really want the mobile device to be able to modify the canvas, if that makes sense

Edit
Just noting we haven't fully reviewed WebRTC so we just assumed it'd fit our use case based on the summary of it's features

[cchirag]

Hey, just went through WebRTC's implementation and I don't think it can help us achieve the feature we are looking for.
Before a Peer-to-Peer connection is established, we need to signal the parties their credentials. For us to have this exchange in realtime, we need sockets. WebRTC does not touch on the signalling is achieved. It leaves it to the developer. Now, to exchange credentials and establish a P2P connection, we would need a Socket which can then be closed after the credentials are exchanged. This is what my initial findings fetched.

[dguyen]

I don't think you need sockets or signaling

https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Session_lifetime#signaling

In order to exchange signaling information, you can choose to send JSON objects back and forth over a WebSocket connection, or you could use XMPP or SIP over an appropriate channel, or you could use fetch() over HTTPS with polling, or any other combination of technologies you can come up with. You could even use email as the signaling channel.

[cchirag]

Hey @dguyen, I did few experiments with WebRTC using socket and fetch. Sockets are out of options since we cannot have an open connection in a serverless environment.
Now, with respect to polling, using fetch() over HTTP, it is an approach which works but the issue is:

• Storing SDP and ICE Candidates data on database. These two needs to be exchanged between the clients for a successful connection.
• Constant polling to the DB for SDP and ICE Candidates' information.
• Unnecessary technical implementation when we can directly query the data (base64 converted signature) from the DB using fetch() over HTTP from the client.

I am really sceptical with respect to the use of WebRTC for this specific use case. Maybe we can refine this a little more and come up with something. Sorry for the constant back and forth.

[cchirag]

Hey @dguyen, any updates?

[dguyen]

Sorry I don't currently have time to deeply look into this so I don't have much suggestions at the moment