[$250] [New feature] Formalize loading UX patterns

[MitchExpensify]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: v1.4.77-11 Reproducible in staging?: Yes Reproducible in production?: Yes If this was caught during regression testing, add the test name, ID and link from TestRail: Email or phone of affected tester (no customers): NA Logs: https://stackoverflow.com/c/expensify/questions/4856 Expensify/Expensify Issue URL: https://github.com/Expensify/Expensify/issues/350373 Issue reported by: @flodnv Slack conversation: Original proposal here: https://expensify.slack.com/archives/C01GTK53T8Q/p1699972596342559

Action Performed:

Find any loading state with skeleton view, ideally all the bigger loading states we have to replicate this

Expected Result:

A few random scenarios:

Actual Result:

Sometimes, the app is loading something for a little while; as an end user, you have no clue what's happening. Then, when loading finishes, sometimes several seconds later, all of a sudden, new data pops up and takes you by surprise, resulting in a very unpleasant UX that almost feels broken.

Workaround:

Wait for load to finish

Platforms:

Which of our officially supported platforms is this issue occurring on?

• [x] Android: Native
• [x] Android: mWeb Chrome
• [x] iOS: Native
• [x] iOS: mWeb Safari
• [x] MacOS: Chrome / Safari
• [x] MacOS: Desktop

Screenshots/Videos

See above in expected outcome.

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01abc617cb419429a0
• Upwork Job ID: 1802720967915457458
• Last Price Increase: 2024-07-29

Issue Owner

Current Issue Owner: @getusha

[melvin-bot[bot]]

Triggered auto assignment to @slafortune (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[MitchExpensify]

I think we need:

1. Reproduction steps for long loads where skeleton view is shown
2. List of all situations where #1 happens to ensure our solution covers them

[melvin-bot[bot]]

@slafortune Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[melvin-bot[bot]]

Job added to Upwork: https://www.upwork.com/jobs/~01abc617cb419429a0

[melvin-bot[bot]]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @getusha (External)

[slafortune]

@getusha I haven't had a chance to dig into listing this out yet, but would be glad to team up with you on that.

[getusha]

@slafortune @MitchExpensify i am not able to see the expected result, could you attach it again please? thanks

[MitchExpensify]

Weird, can you see these @getusha ?

[melvin-bot[bot]]

@slafortune, @getusha Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[mananjadhav]

Just to chime in, I can't see the expected results either. But I can see screenshots uploaded by @MitchExpensify here. I am assuming @getusha should be able to see them too.

[getusha]

Just to chime in, I can't see the expected results either. But I can see screenshots uploaded by @MitchExpensify https://github.com/Expensify/App/issues/43453#issuecomment-2179554040. I am assuming @getusha should be able to see them too.

Yes, I am able to see the screenshots, thanks!

[melvin-bot[bot]]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[getusha]

Discussing here https://expensify.slack.com/archives/C01GTK53T8Q/p1699972596342559

[melvin-bot[bot]]

@slafortune @getusha this issue was created 2 weeks ago. Are we close to approving a proposal? If not, what's blocking us from getting this issue assigned? Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!

[slafortune]

@getusha do you have an update?

[melvin-bot[bot]]

@slafortune, @getusha Whoops! This issue is 2 days overdue. Let's get this updated quick!

[getusha]

@slafortune Still discussing. i think the design team is working on it https://expensify.slack.com/archives/C01GTK53T8Q/p1699972596342559

cc @Expensify/design

[melvin-bot[bot]]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[melvin-bot[bot]]

@slafortune, @getusha Whoops! This issue is 2 days overdue. Let's get this updated quick!

[dubielzyk-expensify]

I'm not sure we (design) are still working on it. From what I've understood the pattern has been decided, but we aren't 100% sure exactly where to use it vs where to not. There was a suggestion from an engineer internally to only show it on ReconnectApp which sounds right to me as a start. This loading pattern is pretty visually demanding so we'd wanna only show it in a few instances as we have skeleton loaders for everything else.

I'd be keen to get @MitchExpensify or @flodnv help in fully understanding the loading cycle and maybe I can help lean in to where we use this pattern vs our skeleton patterns? cc @Expensify/design

[melvin-bot[bot]]

@slafortune, @getusha Eep! 4 days overdue now. Issues have feelings too...

[MitchExpensify]

understanding the loading cycle

I'd need to defer to @flodnv here, I'm not 100% sure how to clarify. Is the crux of the question about when to show the new pattern versus the skeleton view?

Do we already show the skeleton view on ReconnectApp?

[dubielzyk-expensify]

Yeah, I guess what would be helpful is an understanding of the lifecycle of the app in terms of loading requests. From loading a message, going offline, the whole app loading etc.

I do think ultimately we'd only wanna show this "Connecting..." pattern when loading is longer like above 5 seconds. Or that the app is completely offline or disconnected, and we're reconnecting the app back.

[flodnv]

My suggestion is to start showing the thin bar loader at the top of the screen when ReconnectApp is running.

[dannymcclain]

My suggestion is to start showing the thin bar loader at the top of the screen when ReconnectApp is running.

After experiencing this a bit more... I think I might agree with using the thin green bar pattern. I know we previously settled on the Connecting... badge, but I kinda think the green bar loader would be more understandable for these situations. The issue for me is that typically (at least in my experience) the app LOOKS like it is fully loaded. No skeletons, lots of messages already populated, and then all of the sudden BAM, new message just appear. So I kinda think the green loading bar will be more visible, recognizable, and understandable.

Having said that, I'm not sure we have a consistent place to put it. The LHN doesn't have a bottom border on the header like chats do. So I'm not super sure how to handle that.

@dubielzyk-expensify @shawnborton any thoughts on using that pattern instead and where it might live if we did?

[shawnborton]

Hmm I am a bit stumped, maybe along the top of the bottom tabs where we have a border line and a clear divide between content and bottom tabs? I've never seen a loading bar in that kind of place though, so it might look strange. Maybe we can make a couple of prototype ideas and bring them to Slack for greater visibility too.

[dubielzyk-expensify]

Having said that, I'm not sure we have a consistent place to put it. The LHN doesn't have a bottom border on the header like chats do. So I'm not super sure how to handle that.

Maybe just me, but I don't think that matters cause it has a background so there's a depth delineation anyways.

Hmm I am a bit stumped, maybe along the top of the bottom tabs where we have a border line and a clear divide between content and bottom tabs? I've never seen a loading bar in that kind of place though, so it might look strange.

We don't always have the bottom tabs visible though? This is why I'm thinking page/app header is a more natural place.

I'm definitely okay with the direction of going with the green line on ReconnectApp and see how that feels. This is definitely one of those that has to be tried on staging to get a sense of how often it runs etc.

Could we start with that?

[dubielzyk-expensify]

Relevant mocks:

[shawnborton]

We don't always have the bottom tabs visible though?

True, I suppose mobile might open up the app to an existing chat or something?

I like what you have in your mocks above but I have a feeling that the main thing that happens when we call "ReconnectApp" is that we are loading all of the relevant chat in the LHN. I bet there's a chance that the chat view on the right on desktop might load before the LHN finishes loading, right? So that being said, I kinda feel like it makes more sense to just always have that green loading bar feel more attached to the LHN area. Thoughts on that? I might be wildly off though haha.

[dubielzyk-expensify]

Yeah, I see what you mean. I don't feel super strongly, I just assumed that ReconnectApp is generic that anything can be loading and I therefor put it in the main content area to ensure that it's visible on the screen you are currently on (regardless of whether it's desktop or mobile). Especially for pages like Search.

You got any thoughts @dannymcclain?

[shawnborton]

Oh that's a great point too... yeah, that makes total sense to me and I can see why you picked that spot then.

[dannymcclain]

I could go either way. After seeing your mocks, I totally agree that it works just fine even with headers that don't always have a bottom border. So I'm into that approach. I think I might be aligned with Jon on using the big content area on desktop. Here's a mock of that without the skeleton loaders (only because this is how the app usually looks for me when this situation happens):

And lastly, we could potentially try to just go across the whole top of the app to avoid any distinction between "this pane" vs. "that pane". But I don't really see how that would work with native apps or the desktop app... So I think I'm still in favor of what Jon has proposed.

[melvin-bot[bot]]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[getusha]

Not overdue!

[dubielzyk-expensify]

And lastly, we could potentially try to just go across the whole top of the app to avoid any distinction between "this pane" vs. "that pane". But I don't really see how that would work with native apps or the desktop app... So I think I'm still in favor of what Jon has proposed.

Yeah I tried that at some point and actually visually prefer is, but it breaks with native apps and the desktop app like you said, so I recon at least for the prototype phase we keep it simple and then re-evaluate!?

[shawnborton]

All good points... Could we see a quick mock of desktop where just the LHN has the loading bar though? I think I am still a little hung up on the idea that on one platform, it seems like the LHN is loading but the other platform, it feels like just the chat is loading. So if we can make it work where we standardize on making it feel like the LHN is loading, I think that would be ideal.

[dubielzyk-expensify]

[dannymcclain]

The mocks Jon just posted look good. I get why we'd want to use the big content pane on desktop—but to start, why don't we implement this loading bar for the LHN for all platforms and see how that feels?

That'd be a meaningful step forward and would probably slightly simplify the implementation. Might be worth noting that I think on mobile, you could still potentially get the loader on the chat header since that's a full-screen experience (unlike on desktop).

What do you all think about that?

[shawnborton]

I can totally get down with that, yup!

[melvin-bot[bot]]

@slafortune @getusha this issue is now 4 weeks old, please consider:

• Finding a contributor to fix the bug
• Closing the issue if BZ has been unable to add the issue to a VIP or Wave project
• If you have any questions, don't hesitate to start a discussion in #expensify-open-source

Thanks!

[dubielzyk-expensify]

Sure thing 👍

[mvtglobally]

Issue not reproducible during KI retests. (First week)

[melvin-bot[bot]]

@slafortune, @getusha Whoops! This issue is 2 days overdue. Let's get this updated quick!

[dubielzyk-expensify]

Sounds like we have a plan to implement this as a proof of concept.

Not sure what the next steps are, but perhaps you can help @MitchExpensify?

[getusha]

Could we also get the animated mockup? i assume it'll behave different than a progress bar.

[dannymcclain]

Could we also get the animated mockup? i assume it'll behave different than a progress bar.

@dubielzyk-expensify what were you thinking? I kinda thought it would behave like a progress bar... But I can definitely see the argument for it just filling up over and over again until everything is loaded. Curious what you had in mind!

[shawnborton]

That was my initial thinking too, though I guess that presents some technical feasibility questions - can we reasonably know how long something is taking to load and show progress in a start to finish fashion? No idea how that works. Otherwise I guess we would do some kind of horizontal movement/pulsing, which also feels pretty standard for these sorts of things.

[flodnv]

Otherwise I guess we would do some kind of horizontal movement/pulsing

This is by far the easiest here 👍

[dannymcclain]

Cool - I'm down for that. That's pretty typical behavior for these kinds of loaders anyways. So I don't really think it's worth the effort to try to make it a realistic progress bar.

[dubielzyk-expensify]

Gonna take the animation of the loading bar internal and I'll report back here with final specs asap 👍