[Epic - Search] Search bar within the map for addresses / locations

[mwpark2014]

Summary

Create a search bar on the main map page to allow users to search for things.

M0 - Search Design

• https://github.com/waterthetrees/wtt_front/issues/526
• https://github.com/waterthetrees/wtt_front/issues/527
• [Map Search - Design] Mobile Hamburger Menu integrated into Search
• [Map Search - Design] Mobile Hamburger Menu Dropdown to be Slide In
• [Map Search - Design] Search Results Components
• [Map Search - Design] Filter Components
• https://github.com/waterthetrees/wtt_front/issues/474

M1 - Search for addresses, lat/longs, and potentially places

• [x] #130
• [x] https://github.com/waterthetrees/wtt_front/issues/522
• [x] https://github.com/waterthetrees/wtt_front/issues/523
• [x] https://github.com/waterthetrees/wtt_front/issues/613
• [ ] https://github.com/waterthetrees/wtt_front/issues/614
• [ ] #131
• [ ] #140
• [ ] https://github.com/waterthetrees/wtt_front/issues/623
• [ ] https://github.com/waterthetrees/wtt_front/issues/646
• [ ] https://github.com/waterthetrees/wtt_front/issues/659

Related, but not necessarily blocked by https://github.com/waterthetrees/wtt_front/issues/412

M2 - Personalized searches for Trees

Reverse geolocation of trees (Tree -> TreeId -> DB query -> Lat/Lng -> trigger lat/lng search)

• [ ] https://github.com/waterthetrees/wtt_front/issues/524
• [ ] https://github.com/waterthetrees/wtt_front/issues/525
• [ ] https://github.com/waterthetrees/wtt_front/issues/528
• [ ] https://github.com/waterthetrees/wtt_front/issues/529

M3 - Search and filter by Tree fields

• Search for Trees with queried "maintenance needed" tags in selected area
• Query by type of tree in selected area
• Allow users to use advanced search queries (query tree properties with conditional operators)
• [Search Feature - Design] Mobile Search Additional Components
• [Search Feature - Design] Desktop Search Additional Components

M4 - Search and filter by Tree fields

• [ ] https://github.com/waterthetrees/wtt_front/issues/453
• https://www.algolia.com/industries-and-solutions/voice-search/?utm_source=google&utm_medium=paid_search&utm_campaign=rl_amer_search_nb_site_search_nuanced_lowintent&utm_content=voice_search&utm_term=voice%20search%20website&utm_region=amer&utm_model=nonbrand&utm_ag=rl&_bt=600058735667&_bm=p&_bn=g&gclid=Cj0KCQiAx6ugBhCcARIsAGNmMbjg3YMlQ3ztcgTxkNm26cWnpsPcnb8QRBdAt68i2X1Y_9oSOkmfpsIaAgzyEALw_wcB

Resources: https://dribbble.com/shots/9873759-UNIFI-Travel-app https://dribbble.com/shots/14041865-Vertt-Mobile-App-Design https://uxplanet.org/design-a-perfect-search-box-b6baaf9599c https://m2.material.io/design/navigation/search.html#expandable-search

[ri0nardo]

is this a search bar similar to google maps search bar?

[ri0nardo]

i was on instagram desktop and how they integrated the search bar within the vertical menu was pretty cool. I like to go down this route with the search bar for the map.

[ri0nardo]

started to integrate the search into the vertical menu for the map. Its just a layout, but im not sure what content we want to put in here. If its just past trees searched, addresses, random searches.

[ri0nardo]

Forgot I started a search menu for mobile. But I like the idea of removing the green header bar and having the search bar there instead. still a work in progress.

[ri0nardo]

[ri0nardo]

I am looking at ways to incorporate the search into our current interface. I have thought of the idea of having it at the very top to remove the horizontal green bar or now I looked at tesla having it at the bottom. Both are valid solutions to explore. I was looking at the bottom to be more of a tool to see your trees or do more actions (similar to what google maps does). I see the search being more valuable at the top as its not as easy to access with a finger. I see the search not being the primary tool to a certain degree as planting is much more of the focus with the actions at the bottom.

[mwpark2014]

I am looking at ways to incorporate the search into our current interface. I have thought of the idea of having it at the very top to remove the horizontal green bar or now I looked at tesla having it at the bottom. Both are valid solutions to explore. I was looking at the bottom to be more of a tool to see your trees or do more actions (similar to what google maps does). I see the search being more valuable at the top as its not as easy to access with a finger. I see the search not being the primary tool to a certain degree as planting is much more of the focus with the actions at the bottom.

yah I feel like whatever we want to be the most prominent should be on the bottom - this sounds like the planting or other maintenance actions flow from discussions we've already had I think!

[mwpark2014]

started to integrate the search into the vertical menu for the map. Its just a layout, but im not sure what content we want to put in here. If its just past trees searched, addresses, random searches.

Have you finalized whether you want the search bar on the main screen or hidden away in the menu? Or maybe the former is for desktop and the latter is for mobile?

Honestly getting a bit confusing from a developer's perspective on what phase we are in the design iteration. Might want to consider splitting out into design tickets in the future. For now, I can see it being helpful for getting everyone's opinion.

[mwpark2014]

@ri0nardo

We talked about this briefly, but I'm curious if this matches up to what you had in mind for searching trees. https://github.com/waterthetrees/wtt_front/issues/524 (include favorited and adopted trees in search autocomplete results)

Are there other lists of trees we would want to populate the autocomplete with? Are there other entities that users might be searching for besides trees?

Oooh, I think it would be cool to search for trees with a "maintenance needed" feature. This looks to go hand in hand with implementing the tagging feature (see screenshot). An example use case would be to search "Needs water" on the search bar much like you would type "food" on google maps. The map would populate with the 10-15 results closest to the centroid of the user's current viewport.

[ri0nardo]

Are there other lists of trees we would want to populate the autocomplete with? Are there other entities that users might be searching for besides trees?

We can brainstorm a whole list of filters we want to include. Its quite a large task to include it all. A few more we could incorporate in the future include:

• User Search - Profiles
• Organization Search
• DBH size
• Nurseries

I would focus on values that are currently already included in the tree details sidebar.

Oooh, I think it would be cool to search for trees with a "maintenance needed" feature. This looks to go hand in hand with implementing the tagging feature (see screenshot). An example use case would be to search "Needs water" on the search bar much like you would type "food" on google maps. The map would populate with the 10-15 results closest to the centroid of the user's current viewport.

That's the idea, but I believe that "watering" feature needs work with timing plus the notifications. Do we want to start a ticket on filters we want to include, and scope it out to what we currently could include and future implementation?

[ri0nardo]

started to integrate the search into the vertical menu for the map. Its just a layout, but im not sure what content we want to put in here. If its just past trees searched, addresses, random searches.

Have you finalized whether you want the search bar on the main screen or hidden away in the menu? Or maybe the former is for desktop and the latter is for mobile?

I want to go down the route of integrating the search into the side menu which I started. Right now I am just going to use the mobile results and place them into the search and see how that looks. I would also make space for the filters. I would essentially make mobile and desktop look very similar just so its less components and possibly quicker to incorporate. How soon do you need it? I haven't spent anytime on the search, so i can switch priority to this if you need it soon.

Honestly getting a bit confusing from a developer's perspective on what phase we are in the design iteration. Might want to consider splitting out into design tickets in the future. For now, I can see it being helpful for getting everyone's opinion.

I was exploring all the possibilities of the search and the placement on a mobile device. Mobile is the priority to me at this moment. But I do have a solution, but need to design it out.

[mwpark2014]

I want to go down the route of integrating the search into the side menu which I started. Right now I am just going to use the mobile results and place them into the search and see how that looks. I would also make space for the filters. I would essentially make mobile and desktop look very similar just so its less components and possibly quicker to incorporate. How soon do you need it? I haven't spent anytime on the search, so i can switch priority to this if you need it soon.

I think I have 1-2 weeks worth of work to do before I work on the UI component. You don't need to rush, but it would be good to get a general sense of what you were envisioning for the search bar, since it seems different than what you previously had in your mock. Sounds like it'll be hidden until the side menu is opened if it's incorporated into the side menu? I think that makes sense for mobile, but I feel like with the screen real estate we have on desktop, we could probably keep the search bar on the top of the map for desktop.

Take your time! I have plenty of work to occupy me in the meantime, but this will be my main project starting next week.

As an aside, what do you mean by filters? I think you're talking specifically about the autocomplete results?

[ri0nardo]

I think I have 1-2 weeks worth of work to do before I work on the UI component. You don't need to rush, but it would be good to get a general sense of what you were envisioning for the search bar, since it seems different than what you previously had in your mock. Sounds like it'll be hidden until the side menu is opened if it's incorporated into the side menu? I think that makes sense for mobile, but I feel like with the screen real estate we have on desktop, we could probably keep the search bar on the top of the map for desktop.

I dont think the search should take its own space on the map due to it being in the same space as all the other actions. See my example. While there is screen real estate the focus should be the map. also the less we populate the screen makes it look cleaner imo.

As an aside, what do you mean by filters? I think you're talking specifically about the autocomplete results?

I was just talking about the filter tags I put in the search.

[mwpark2014]

I think I have 1-2 weeks worth of work to do before I work on the UI component. You don't need to rush, but it would be good to get a general sense of what you were envisioning for the search bar, since it seems different than what you previously had in your mock. Sounds like it'll be hidden until the side menu is opened if it's incorporated into the side menu? I think that makes sense for mobile, but I feel like with the screen real estate we have on desktop, we could probably keep the search bar on the top of the map for desktop.

I dont think the search should take its own space on the map due to it being in the same space as all the other actions. See my example. While there is screen real estate the focus should be the map. also the less we populate the screen makes it look cleaner imo.

As an aside, what do you mean by filters? I think you're talking specifically about the autocomplete results?

I was just talking about the filter tags I put in the search.

Got it! This all LGTM! 🙏

[ri0nardo]

@mwpark2014 im actually reconsidering how the search will work on mobile. I find more value with the search showing the user where the tree(s) are in relation to the map. I found an example from a case study someone was doing. What do you think? I am just talking about the first screen from this example.

[mwpark2014]

@mwpark2014 im actually reconsidering how the search will work on mobile. I find more value with the search showing the user where the tree(s) are in relation to the map. I found an example from a case study someone was doing. What do you think? I am just talking about the first screen from this example.

I think we discussed this elsewhere. Yeah, I think I can get on board with a search that opens up from the bottom. It sounds like one case would be when planting a new tree. Would there be other cases where a user would be likely to need to use search? I'm afraid that hiding it would make it undiscoverable

[ri0nardo]

@mwpark2014 im actually reconsidering how the search will work on mobile. I find more value with the search showing the user where the tree(s) are in relation to the map. I found an example from a case study someone was doing. What do you think? I am just talking about the first screen from this example.

I think we discussed this elsewhere. Yeah, I think I can get on board with a search that opens up from the bottom. It sounds like one case would be when planting a new tree. Would there be other cases where a user would be likely to need to use search? I'm afraid that hiding it would make it undiscoverable

just ignore that message. We can just have this as an idea.