[$250] Update Search page to always show search input and type tabs at the top

[shawnborton]

Right now we face some inconsistent behavior with the Search page depending on if you use a LHN nav item or if you search via the router. The LHN has default navigational items that don't use search input across the top of the page, but we do indeed show a search input if you search for something via the router. Furthermore, the default Search experience does not show a type selector across the top, however we are planning to show one across the top if you searched for something via the router.

In order to clean up these consistencies, we're proposing these incremental updates to the search page:

• Always show a search input at the top of the page
• Do not show expense types in the LHN. Instead, use the LHN for default suggested searches as well as saved searches
  • The two default searches will be "All expenses" and "Expenses waiting on you" to start
• Move the status selector (All, drafts, outstanding, etc) to be within the RHP filters panel

That gives us something like this:

CleanShot.2024-11-11.at.16.52.54.mp4

On mobile, the idea is to use a UI like this where we use a full-page router experience that you can close in the top right corner after focusing:

CleanShot.2024-11-11.at.16.51.48.mp4

On the note of filters, the idea is to move Status into the list of filters in the RHP:

One small update though is we'd like to make it so you can select multiple statuses as once, which more closely matches OldDot's behavior for expense/report status selection:

cc @luacmartins @JmillsExpensify @trjExpensify @Expensify/design

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021864720653992598336
• Upwork Job ID: 1864720653992598336
• Last Price Increase: 2024-12-05

Issue Owner

Current Issue Owner: @SzymczakJ

[luacmartins]

@Kicu anyone from SWM interested in working on this one?

[Kicu]

@luacmartins hm, right now Im actually refactoring this code, so that the input has the autocomplete behavior similar to router, and so that the query always stays correct, if a user keeps editing it and resubmitting.

The change described here would be affecting the (react) components flow in the header of the Search Results page, and I think it would be better if someone doing this waits for my PR.
I can open a draft later today so you could add HOLD to this issue, and my PR should be done withing 1-2 days I think + review.

And yes, we would definitely like to work on this in SWM, I'll post this internally and someone will pick it up. For now perhaps assign me to this?

[Kicu]

here is the aforementioned PR: #52568 still a draft, but now we can link it

[luacmartins]

I agree we should hold on your changes. Thanks for the linked PR and looking forward to getting someone from SWM assigned to the issue!

[shawnborton]

Another thing I wanted to note for this issue - I think it makes way more sense to bring the multi-select button out of the router so it sits below it like this:

Curious what everyone thinks about that though.

[dannymcclain]

I think it makes way more sense to bring the multi-select button out of the router so it sits below it like this

Where does it show up now? Inside the search input where the filters button is? Anyhoo, I agree and I think what you're showing in that mock looks good and makes sense. 👍

[shawnborton]

Yeah it currently replaces the filter icon within the search bar, which feels a little strange.

[dannymcclain]

Agree with that. Definitely like what you posted much better.

[shawnborton]

Not overdue, still working through this one.

[luacmartins]

Still holding

[melvin-bot]

@shawnborton, @luacmartins Eep! 4 days overdue now. Issues have feelings too...

[Kicu]

Waiting on merge of: #52568
I remember about this PR and someone from SWM will pick it up once 52568 is close to merging. Currently scope is growing a bit for the PR.

[shawnborton]

Not overdue, see comment above

[trjExpensify]

The linked PR has merged, so shall we take this issue off hold? I'm also going to move this now into #migrate, so we track it there as a key foundational issue to get in place for the rest of our recently discussed plans. Excited for it!

[luacmartins]

We'll be working on a follow up to that PR to fully enable the features on the Search results page, so I don't think we should remove the hold quite yet

[trjExpensify]

Alright, sounds good!

[Kicu]

We can now update the HOLD to be on this issue: #53126

I estimate the PR should be ready in 1-2 days.

[SzymczakJ]

Sorry for interrupting your discussion but here's my update 😄 :
I decided to split this issue into two parts:

• 1st part will add status filter, put search types in the place of status, and add new canned queries
• 2nd part will add SearchInput to mobile view of SearchPage, update SearchPage mobile view to match designs, update SearchPage so we always show SearchInput and improve code quality in Search module

PR for 1st part should be ready for swm review tomorrow
Is it okay with you if I split this that way @luacmartins? If we don't split this the PR might grow to enormous size

[luacmartins]

Yea, that's totally fine.

[SzymczakJ]

So @JmillsExpensify @trjExpensify what should we put in canned searches? For now I added All expenses(type:expense status:all) and Expenses waiting for you(type:expense status:outstanding,approved to:[signed-in-user]@domain.com), but I suppose that's not the full list.
I will create one more PR for this issue, in which we could update it, so take your time discussing it, but I'm just bumping the discussion.

[trjExpensify]

Given this, I think we'd do the following:

• "Draft expenses" - type:expense status:draft from:[signed-in-user]@domain.com
  • seeded to any user with delayed submission enabled on the workspace (which uses open reports).
• "Expenses to approve" - type:expense status:outstanding to:[signed-in-user]@domain.com
  • seeded to any user that is a submitsTo or forwardsTo on a workspace with "Add approvals" enabled.
• "Expenses to pay"
  • Delayed submission || Instant submit enabled + Approvals enabled + Payments enabled: type:expense status:approved
  • Delayed submission disabled + approvals disabled + Payments enabled: type:expense status:closed
  • Instant submit + approvals disabled + Payments enabled: type:expense status:outstanding
  • Who to seed the suggested search to:
    • Direct reimbursement: seeded to the designated reimburser on the workspace
    • Indirect reimbursement: seeded to all workspace admins

This question is still bothering me though for "Expenses to pay", as we'd not want to include an expense report that only contains non-reimbursable expenses:

Should we also consider including something in the query to ensure that the reports that show up here have at least one expense on the report that's reimbursable? Otherwise a report with all card transactions on it will show.

[SzymczakJ]

What would be the icons for these @dannymcclain ?("Draft expenses", "Expenses to approve", "Expenses to pay")

[shawnborton]

Hmm maybe something like this? cc @Expensify/design for thoughts though...

[dannymcclain]

Yeah I like those Shawn. If we wanted to go W I L D we could add small hourglasses to the thumbs up and money bag icons like we have with the credit card icon:

But I'm not sure that's super necessary.

[shawnborton]

Oh I would be down to see something like that if you feel like exploring it! I don't feel strongly, but I like the idea.

[dannymcclain]

I did a little bit of exploring here, not a huge fan TBH haha.

[shawnborton]

Hah yeah, I can see that. Kinda feels slightly forced maybe. So maybe we just go with the simple ones for now?

[dannymcclain]

So maybe we just go with the simple ones for now?

Yeah I think this is the right move. So in summary, let's go with what Shawn posted here.

[JmillsExpensify]

Coming back to this issue, are we sure that we should do this right now? I'm nervous about implementing "suggested" searches before we've published an extensive design doc, especially with the HL "Search v3" design on the horizon.

Additionally, this plan with all, draft, approve, pay is highly dependent on workspace set up. Most workspaces would have the first three, though there is a enough variability even based on use case (employee, approver, admin), that I think we should honestly pump the breaks on this initiative and wait for "Search v3" to work itself through the design process.

I'm sorry, I know that when we first created this issue, things were different. So this goes back on why we started this issue in the first place. But the planning dynamics have changed quite a bit since then, so I think it's best that we put a HOLD back on this issue, probably until the more specific design doc for "suggested" searches goes out.

Anyone else feeling similar?

[SzymczakJ]

This task consists of two independent parts:

1. Adding new suggested searches, which were under our discussion.
2. Always showing search input on desktop and mobile views, which doesn't touch any of the suggested searches logic and can be implemented independently.

Unfortunately I've already created PR for part 1 😭, but I think we could put that part 1 PR on hold and I could start working on part 2. Or do you think we should put both parts on hold because the whole design will change @JmillsExpensify @trjExpensify @shawnborton

[trjExpensify]

Anyone else feeling similar?

Agreed.

but I think we could put that part 1 PR on hold and I could start working on part 2

Yep, exactly. Let's focus on the search input here for now, and then we can look to take the PR to move the type tabs and replace them with suggestions off hold later.

[JmillsExpensify]

Ok cool. I like working on part 2 now. That's effectively just a superficial "design" change that is consistent with the future.

[SzymczakJ]

Then I'll start it right away.

[shawnborton]

So I think that gives us something like this then, right?

[shawnborton]

And for mobile, I think this is what we want in the meantime as well:

[JmillsExpensify]

@shawnborton one small comment on the second mock. Wouldn't the saved searches use the bookmark icon? Or are we going to change that out for the magnifying glass. This is what saved searches look like in production.

[dannymcclain]

Great catch Jason. I do think we should use the bookmark icon for saved searches, especially since the user will tap on a bookmark icon button to get there.

[shawnborton]

Ah yeah, that's my bad. Updated mock here:

[shawnborton]

Also note that we want to update the search input to use a height of 40px, like so:

[shawnborton]

Why just mobile? I was thinking everywhere, for consistency's sake!

[dannymcclain]

OH! Yeah ok I just did a little doodle in Figma to see what it's like on desktop and I'm good with it!