PRDT: Explore Search

[Dianadec]

Description:

Informed by the "choose your own adventure" concept from story mapping, we need to explore how we might optimize search, specific to backcountry booking. Update from Aug 20 refinement - eg: you don't need to state your dates or what you're looking for precisely. more like, you can look at a map and see everything and not necessarily have to specify the type you want.

This ticket is to explore and identify next steps for search.

Acceptance Criteria:

• [ ] Review output from bcgov/reserve-rec-api#6 data exploration and bcgov/reserve-rec-api#10 policy inventory
• [ ] Document considerations/limitations specific to backcountry search that should be incorporated into search designs

Development Checklist:

• [ ] All data authoritatively is in dynamo with exception of geojson
• [ ] DynamoStream should replicate changes to auth data to OpenSearch
• [ ] searching opensearch is for map or any unstructured query
• [ ] Dates open/close should be pulled via script/offline into the system, and an ETL to update DynamoDB/OS data so that searching endpoints will work. No live connections to strapi should be made.

Dependencies

• Blocked by bcgov/reserve-rec-api#6
• Blocking bcgov/reserve-rec-public#13

Relevant documentation as reference

Definition of Ready

• [ ] Acceptance criteria are included
• [ ] Wireframes are included (if applicable)
• [ ] Design / Solution is accepted by Product Owner (if applicable)
• [ ] Dependencies are identified (technical, business, regulatory/policy)
• [ ] Story has been estimated (under 13 pts)

Definition of Done

• In progress:
  • [ ] Acceptance criteria are tested (Functionality meets the acceptance criteria defined in the ticket)
  • [ ] UI meets accessibility requirements
  • [ ] Unit tests are written
  • [ ] Work is traceable in GitHub
  • [ ] PR linked to ticket number
  • [ ] If needed/required - Dev adds flag/label to highlight any migration steps necessary prior to PROD deployment
• Code review:
  • [ ] Code is peer reviewed and has passed CI/CD tests
• QA:
  • [ ] Acceptance criteria are tested (Functionality meets the acceptance criteria defined in the ticket)
  • [ ] Code is potentially shippable to the production environment
  • [ ] Functional features have been tested and passed by QA
  • [ ] UI components tested by designer
  • [ ] Code is deployed to PROD when moved to 'done' column (unless requested otherwise by PO)
• PO Review:
  • [ ] Acceptance criteria are tested (Functionality meets the acceptance criteria defined in the ticket)
  • [ ] Reviewed and approved by Product Owner

Notes:

-

[Dianadec]

Refinement notes:

• we have everything we need technically to do the search piece
• we have the raw data to create an experience but someone will have to go through it and grab all the segments that apply to create a whole thing around the experience. Eg. West coast trail. That's a huge data exercise. And, need to build a system that looks at all the inventory and notes which items are now limited on a resource by resource instance. Todo: figure out how things are attributed together. Secondary is building a tool that lets them manage that.
• backcountry registrations don't have a limit of permits they will give you (limit in system though - very high) - but you could go the day-of and get it. Reservations IS limited. But some registrations get changed into a reservation to limit the capacity, so that people can also be guaranteed a tent pad. Registrations = tent pads are fcfs. Every year reservations systems will do a call-out. First, an RSO, area supervisor section head, then Regional Director. Executive - approves decision note. Overall res services wants to review this process.

So for this ticket we can use maps to search. Currently can't do search by dates etc

Search could use a blue sky workshop to brainstorm all the different ways to search and all the things we could do. Then how we can use the data to allow that search to happen.

[Dianadec]

Notes from Darcie/Mark/Diana mtg:

less about designs - more about all the questions

• Do we want this recorded to make sense of the story?
• Defining the user experience (not about the Front end look), but how are they moving through the system conceptually.

-->To find the questions, let's look at the user story map. Eg: give me user story #1 and let me try to conceptualize at each stage of that person's flow, what info we'll be needing to grab, eg: looking at park or looking at geo. If geo, what are they filtering on (food caches, region, what, etc). Then want to see where everything is on a map, want to go from point A to Point B - what are my requirements? Do I need to register for this area, reserve? (this brings in policy, biz rules, ). TLDR need to go through a story, walk through it from a data perspective, then find the data and find a group of data that wraps around it. --> need Brittany or Jessica to link policies to geo

Does Cam's flow diagram capture any of this? yes, and we need to build upon it.

[Dianadec]

Aug 20 Refinement notes:

• This is pretty much done (the exploration piece) - opensearch is built and running