Improve UX regarding order matching delay

[alfetopito]

Description

Improve UX regarding order matching delay.

During network congestion or for example issues we had lately with txs being stuck for a few minutes due to slowness with Flashbots API, orders take longer than usual (30 to 60s is the normal case) to be matched.

Free form task, there are no hard requirements at this point. Part of this task is for the team to brainstorm/suggest one approach including UI/UX.

Potential ideas

• If it has been more than 30s or 60s from order placement, show a message like: It’s take longer than usual, hang on
• And/or show a progress bar/circle that changes color (from green to yellow) when it’s closer to 60s, and takes exponentially longer to complete
• Watch the contract for pending txs in the mempool and show them in the UI

Feature breakdown It includes:

• [ ]

Good to have:

• [ ]

[alongoni]

Hey @alfetopito here is the design for tell users that a order is delayed. If the user place an order and it takes more than 30-60s, the notification will appear. It's necessary to give more context about the Sell/Buy order and the tokens used? We could also add the amounts. The notification will not have the auto-close timeout (only close when the order is filled and/or with cross icon) A variant with the notification at the bottom Detail: cc @biocom

[elena-zh]

Hey @alongoni , will this bar be moving? With what speed? As you have described, the toast notification will remain opened until an order is filled/closed manually, how to understand what the progress is?

Will the bar become in red when an order has become expired? Or the order will never be filled when an order price is out of range?

Btw, could we show a message inside the activity modal as well?

Also, @alfetopito , will we add the same warning to an order details in Explorer?

[alongoni]

Hey @alongoni , will this bar be moving? With what speed? As you have described, the toast notification will remain opened until an order is filled/closed manually, how to understand what the progress is?

Yes, it will be moving, but I don't know if we can get data to exactly show a progress. The main idea is to represent a progression of the order, "something is happening".

Will the bar become in red when an order has become expired? Or the order will never be filled when an order price is out of range?

Great, I'll add this case.

Btw, could we show a message inside the activity modal as well?

Also, @alfetopito , will we add the same warning to an order details in Explorer?

[anxolin]

Btw, could we show a message inside the activity modal as well?

Yes, I think we should. The toast is easy to miss. I even find it more important there. Maybe we don't even need the toast? One alternative is that the message and the progress bar is shown always in the order details. If one or more orders are having issues (slow), we can change the spinner of pending orders that show that something is wrong.

Actually, this could apply also for when the order is out of market, it's kind of related. If some orders are out of market we can show it somehow in the spinner.

Also, this "out of market" error is a specific case for an error of slow executions. If the order has the price out of the market won't likely be executed, so we don't need the progress bar at all.

[alfetopito]

I agree with Anxo. I'm more inclined to not having individual slow orders as toast notifications. Thinking about it, it could that that if many orders are placed at the same time during network congestion we'll end up with the screen filled with "permanent" toast notifications.

One idea can be to send a single generic toast OR banner in the UI with a message like:

"One order is taking longer than usual to be filled. Open the activity details for more info"

This message would contain a link to open the modal.

And in the modal, show the slider as you proposed on each pending order

[alongoni]

Thanks for the feedback. 1- A toast notification appears when an order takes longer than usual. 2- Modal with the progress on the pending orders. (I've to add the case when an order has become expired)

[elena-zh]

Hey @alongoni , cool, thank you! From my side, I'm still concerned about a progress bar and the questions I raised above: with what speed it is going to be moved, how we can track it's progress, etc. So I'd better not to show it at all.. May be replace it with a line with a shimming effect in order to show a progress without showing a percentage?

Also, could I ask you to show prototypes for mobile views, as activity modal is a bit different there. Besides, a toast notification might be not visible at the bottom of the screen in a mobile view.

Thanks!

[fairlighteth]

Late to the discussion: Agree with @alfetopito, @elena-zh and @anxolin - I think it's more appropriate to alert the user once with a toast. The progress bar I don't think is appropriate, given the 'time to fill the order' us unknown.

[alongoni]

here are some changes and options: 1- Notification banner at the top (desktop / mobile).

2- Delay warning with a smooth shimming effect (e.g: https://pr882--gpui.review.gnosisdev.com/storybook/?path=/story/orders-statuslabel--filled&args=status:cancelling) Mobile:

3- Delay warning with a loader/spinner.

[elena-zh]

I like the 3rd option! But let wait for the team's opinion!

[anxolin]

From the options I think I would choose the 2nd.

@biocom, are you sure about not showing the progress?

I would be inclined to show something like this: https://www.lightningdesignsystem.com/components/progress-ring

Something like:

• We define the expected time, and show it green while we are within that time.
• The closer we get to the end, we slow down the progress
• If we pass the expected time, we start to change to yellow colors
• if it takes way more than expected we show the progress red, with an alert icon

[fairlighteth]

@anxolin Open to try it out and see how it works in practice. Still have question marks about showing a progress bar for an order which has no deterministic time. Unless we say anything >30 seconds (just an example) is red zone, like you proposed.

[matextrem]

I agree with @biocom. We could get a more accurate expected time by querying an external api (i.e: gas station) but it would lead to adding new complexity (setting a new api key, depends on a 3rd party api and so on). On the other hand, hard coding a time just to show a "fake" progress does not make much sense to me.

[elena-zh]

As an option, I could propose to use something like it works in Fortmatic wallet:

• Tx progress bar appears, and its length is 2.5 min by default. We can set to 30 sec.
• Progress bar is moving as Tx time passes by
• If a Tx is executes earlier, the progress bar is immediately filled in with green
• If it takes up to 2.5 min to execute transaction, progress bar is changing its color to yellow, then becomes in red
• If execution time is > 2.5 min, they change it progress bar by the message something like 'This Tx takes longer..' or so until Tx is executed.

See the video: https://watch.screencastify.com/v/AJ1tsjJ6EPYy8rlFk9pD

@alfetopito , @anxolin , @biocom , @alongoni , WDYT?

[alongoni]

As an option, I could propose to use something like it works in Fortmatic wallet:

• Tx progress bar appears, and its length is 2.5 min by default. We can set to 30 sec.
• Progress bar is moving as Tx time passes by
• If a Tx is executes earlier, the progress bar is immediately filled in with green
• If it takes up to 2.5 min to execute transaction, progress bar is changing its color to yellow, then becomes in red
• If execution time is > 2.5 min, they change it progress bar by the message something like 'This Tx takes longer..' or so until Tx is executed.

See the video: https://watch.screencastify.com/v/AJ1tsjJ6EPYy8rlFk9pD

@alfetopito , @anxolin , @biocom , @alongoni , WDYT?

I think it makes sense, even maybe it could work fine with the cannonical batches new feature (mentioned by Chen via Slack)

In general we should inform what's going on (if possible) when an order is delayed. Or at the very least suggest some solutions for recover from that problem.

[alfetopito]

Adding on top what was said here already, I'd like to try the suggestion proposed by Elena.

Yes, we don't know how long it can take, neither we have visibility of where we are, but setting the expectation on an average batch time during normal circumstances would address the goal of improving the UX with some level of feedback.

When taking longer than usual, we could say something like:

Your order is taking longer than usual. Refer to <doc link> for more info

Or have the details in the UI as a tool tip? Modal? In the toast itself?

Your order is taking longer than usual. It could be due to one or more of the reasons:
1. A network gas spike, causing tx failures which the solvers will take care of re-submit with no additional cost to you
2. Solution submission through private pools (such as Flashbots) can take longer than regular public pools
3. The price has moved against you and the order is no longer matchable

[elena-zh]

Just a small question: what execution time we should consider as a default expectation: 30 or 60 sec?

Also, will we vary this time with regard to the selected network? I mean that usually orders are executed more faster in GC, than in Mainnet. So we could set 30 sec for GC and 60 sec for Mainnet (or other values).

[alongoni]

Well, based on the last comments, some designs here:

1. Toast notification with progress bar + link to FAQs section. Cons: As a user, I'm not sure if I want to click on FAQs, read another page and miss the progress or future notifications.

2. Toast notification with progressbar + Show more/less content. The advantage of this component is that the user remains in the same window. Also I can try the tooltip component, but I think it is too much content to read.

cc @anxolin @alfetopito @elena-zh @biocom

[elena-zh]

I would vote for the 2nd option, however, I'd split the flow to several steps:

1. Order is executing less than 30 sec: show only 'executing order' progress bar
2. Order is executing more than 30 sec: show the message 'Your order is taking longer than usual... ' with 'show more' link.

[alongoni]

1. Order is executing less than 30 sec:

2. Order is executing more than 30 sec:

[alfetopito]

I would use the timers internally as suggested (60s mainnet, 30s gchain) but I wouldn't display the counter in the UI. Only the progress bar. Since this is not an accurate description but only an estimated guess, showing the timer will send the wrong impression IMO.

[alongoni]

Design updated. I think you're right @alfetopito :)

1. Order is executing less than 30 sec:

2. Order is executing more than 30 sec:

NOTE: Maybe we can move the "View details" link beside the Sell/Buy order tittle.

[alfetopito]

I would move the text It could be due... within the show more content. Then we'd have:

Your order is taking longer than usual. <>show more</>

---

Regarding view details, not sure. What about in the column below cancel order? Nah, doesn't feel like a good idea, too crammed

[elena-zh]

Hey, I wonder how it is going to be displayed when connected to Gnosis Safe wallet? We have an additional info block in the activity modal for its orders.

Also, it would be nice to keep in mind that we need to start showing this element when an order is signed by all owners, and goes to the 'Open' status

Besides, we display this banner from time to time. I think, we need to create some kind of a sequence of all these messages in the activity modal.

Also, it would be great to have a design for mobile views.

[alongoni]

Mobile view design proposal:

[anxolin]

In general, all looks great to me.

Some small additions:

• If the price moved against u, we already know. I would personalize this so if its the case, we sow a different message explaining the user that they can CANCEL or WAIT until the price is back. The progress bar in that case doesn't make sense
• In this line, we also don't need to explain the 3rd point (because it won't be the case if we handle the specific case already and we don't show the progress bar).
• I would add a link to the discord so they can complain if this happens

[alongoni]

Design updated based on lasts comments.

1. Order is executing less than 30 sec:

2. Order is executing more than 30 sec (Discord support added):

3. Order is executing less than 30 sec with Gnosis Safe Wallet (pending signing): @elena-zh

4. Mobile:

[fairlighteth]

Chiming in here. Looking at the progress bar my understanding is this exclusively tries to deal with user intended market orders, with the expectation that an order is filled ASAP.

As you know there are perfectly normal situations where users are in fact placing limit orders, without the expectation for it to be filled immediately. But instead, to be filled once limit price is matched (within set expiry time).

These 2 scenarios have different outcomes in terms of expectations. Are we convinced with the current proposal that we are adequately covering both scenarios?

[elena-zh]

Order is executing less than 30 sec with Gnosis Safe Wallet (pending signing): Hi @alongoni , I'd rather not to modify the Gnosis Safe block and leave it as it is. Then, it is better not to show the progress bar when the order is in 'Signing', as the order is not yet confirmed and not being executed. So the bar should appear when the order goes to the 'Open' status. All the rest changes LGTM!

[alongoni]

Chiming in here. Looking at the progress bar my understanding is this exclusively tries to deal with user intended market orders, with the expectation that an order is filled ASAP.

As you know there are perfectly normal situations where users are in fact placing limit orders, without the expectation for it to be filled immediately. But instead, to be filled once limit price is matched (within set expiry time).

Thanks @biocom! I think we weren't covering the second scenario. In that case, it's make sense to show the price variations and intent to show a progression to the limit price? How long can this process take? Or maybe in that case we don't show any progress bar.

These 2 scenarios have different outcomes in terms of expectations. Are we convinced with the current proposal that we are adequately covering both scenarios?

[fairlighteth]

and intent to show a progression to the limit price? How long can this process take?

This is not pre-determined as this waits for market price to match limit price (+ slippage).

As you suggested I think it's more appropriate to not show the progress bar for that scenario. But we can't distinguish both scenario's for now.

My understanding is, in this issue we're aiming to do expectation management and provide more transparency for the user's order journey.

My current thinking is if it makes sense to rather inform about the state of the order vs. saying when it will be matched (I think harder to tell/predict).

We're partially already doing that with the 'price out of market' messaging. A couple of states I could imagine:

1. Order submitted
2. Finding a CoW (30 secs - countdown)
3. Order settlement pending > Limit price is lower than Market price (?)
4. Order settlement pending > Order is taking longer than usual (?)

I think point 1 and 2 can be programmatically derived to some extent. This already gives a good insight in terms of execution time expectation.

Point 3 could be the case when:

• We know the current market price is higher than user's limit price
• Low probability for a situation with gas spikes, slower private pools, etc.

Point 4 could be 'all the rest':

• We know user's limit order price can be matched, looking at the market price.
• ... any possible other reason > Similar to your screenshot "It could be due to one of........."

A progress bar with 'steps' could still be used with the above. Point 1 and 2 in the progress bar. Then depending on the situation we show point 3 or 4.

Curious on your thoughts.

[alongoni]

Thanks again @biocom I like the approach. I've made this draft to represent the states. My only concern is what option/recommendation we offer for users on Point 3 (Order settlement pending > Limit price is lower than Market price) in order to solve that case scenario. Maybe users can wait or cancel the orden, it's right? Or do we have another options.

[fairlighteth]

@alongoni Thank you for the quick feedback with your example on this. It's more in the direction of what I mentioned. At this point I'm also curious on the feedback from others.

My only concern is what option/recommendation we offer for users on Point 3 (Order settlement pending > Limit price is lower than Market price) in order to solve that case scenario. Maybe users can wait or cancel the orden, it's right? Or do we have another options.

When your (sell/buy) order's limit price is lower/higher than market price (..price out of market...) this doesn't necessarily need to be bad. Rather a feature. The perspective taken here is a user which favors matching their limit price vs. speed.

I think that's the fundamental difference between the two scenarios:

1. A user favors matching their limit price, rather than speed of execution
2. A user favors speed of execution and wants more something akin off a (quick) market order settlement.

How do we know right what scenario the user wants/expects? Answering this question, helps further fine tune our little 'order expectation management' feature:

1. A user places a limit order -> Clear signal the user favors limit price rather than speed of execution (of course, it's nice if your limit order gets settled very quick!). Unfortunately right now we don't expose a limit price field. So we don't get this cue from the end-user (even though the orders technically are all limit orders).
2. A user sets a higher than normal transaction deadline in settings > This could be a cue that the user is less sensitive to a quick settlement.
3. We simply ask the user > Do you want a quick settlement of your order, or do you want to wait for matching your limit price? (just an example) > This could be asked when placing an order OR we could ask this in the order detail. Downside is that this adds extra friction to the end-user each time they place an order.

Point 1 is something we don't support yet. Point 2 is perhaps too big of an assumption to take as a cue. Point 3 adds frictions, by adding another question.

Looking again at your last proposal, perhaps it's an idea to merge point 3 and 4 (of your last comment) and simply say: Your order is taking longer than usual. **Show more** What do you want to do? [ Ignore, I can wait ] - [ Cancel my order ]

Until we support proper limit orders (where the user can input their own limit price) perhaps this approach makes the most sense. We simply take the assumption the user wants to go for a quick order settlement. But in case the user doesn't mind, they can ignore/suppress our notification. We then are assertive for a time sensitive user, but also can take a clear cue/signal from the user when they press [ Ignore, I can wait ].

Let me know your thoughts.

[elena-zh]

Great ideas!

But something to keep in mind:

1. We can't cancel an order when a user is connected to SC wallet (Gnosis safe or so), so we should not show 'Cancel my order' button when connected to such wallets.
2. How can we avoid duplicating 'Cancel order' button? I mean, that 'Cancel my order' button will be displayed under the order status (Open), then under the status we will see a regular 'cancel order' button.
3. Will we show a countdown for the 1st stage 'Finding a CoW' (30 secs) in the UI or it will run in the background?

Thanks

[fairlighteth]

@elena-zh Thanks for reviewing:

1. Yes good to keep in mind. We might even need to consider a slightly altered flow there, given they can't cancel (their only option is to manually cancel on their end).
2. Something to experiment with, yes.
3. Ideally yes, because this is relatively deterministic (~30 secs). Perhaps back-end can even provide it's state through the API.

[anxolin]

Hi there, we had some discussion about this feature, and we want to do a sync with you @alongoni

The objective is to close the specs in a syncronous meeting so we can start implementation as soon as possible. We have some ideas that agree mostly with your last proposal.

Lets chat in Slack to find a suitable time.

Cheers,