We should make a quick onboarding that gives an overview of the app as a whole -- tracking jobs, saving data, sharing with researchers -- before diving into consent.

We need to show users what kinds of screenshots they can upload to enter pay and tips.

We are hand-rolling types to have consistency between our graphql API in the flask backend and our frontend.

Options:

graphql-code-generator

Assignees: @dcalacci
Labels: enhancement

!-- Edit the body of your new issue then click the ✓ "Create Issue" button in the top right of the editor. The first line will be the issue title. Assignees and Labels follow after a blank line. Leave an empty line before beginning the body of the issue. -->

it should instead use the begininng of this week

We should automatically deploy our server code to our k8s cluster (development or production/default namespace) when we push to develop or master, respectively.

In the shift detail screen, when a user deletes a shift, it should...actually delete it.

Instead of first-letters (I, S, D, etc) the boxes should show the recognizable brand icons for those apps

• select columns to include
• Create export format for location histories
• expense data + mileage deductions

We are not currently testing our graphql api!!

Linking to PR #26

A 'smart' way to do this would be to compute only new distance, but it's seemingly cheap right now to compute mileage.

The idea is to show user pay by app, but allow them to select (1) which apps to show and (2) their pay + hours sliced different ways

This issue is a request for a new feature, a map aggregation of all of a user's jobs from the filter screen.

A common way that people track tips and work is on a map -- who has tipped, what stores they shopped at, etc. No trackers currently offer this feature.

A few possible implementations:

1. Users filter jobs on the 'jobs list' screen, and then can tap a button to see a map view of all their jobs

• an alternative version of this is being able to switch between a map view and a list view for jobs.

** 2. We implement a separate map screen, with markers for job starts and stops, with its own filter (same filter as the job list) **

Things to consider / solve

• What's the best way to represent pay or tips on a map visualization of jobs?
• If users want to add notes on markers for job starts and ends, what's the best way to display these or search them?

After onboarding, users should hit a brief app walkthrough that shows them how to use gigbox, how to track a shift & jobs, and how to edit / enter pay

Right now our user flow looks something like:

1. user clocks-in (to a "shift")
2. trips are automatically extracted when they end their shift
3. user has to merge trips and tag them with their pay, tip, and the service they used
4. those trips become available in stats.

Right now, there are a few issues with this flow:

1. The link between "trips" and "jobs" isn't made clear, and isn't described to users on sign-up.
2. The only action to take on the "trips" screen is to "merge" trips. "merging" trips to create a job doesn't make user-sense, and in the case of a Job that only has one trip entry, makes even less sense.
3. It's not clear to users yet that they have to "process" their trips from the day.
4. the trips screen does not show any demarcation between days or weeks for trips they've taken.

TO fix this issue, we need to:

• Make the language around shifts, trips, and jobs more consistent, and describe our reasoning + how we're confident workers will understand it
• Decide on an action that users can take that isn't "merging" in order to process jobs, and what processing one trip means
• Where, when, and how to communicate to users that they have to process their trips at the end of the day or week
• Make visual hints at what trips are from today, yesterday, etc. on the trip screen.

We need to develop the consent flow in routing and state

• Consent flow in frontend, implementing consent documents from COUHES application
• State considerations (and implement / move permissioning code) for data permissions
• Signature drawing on consent screen
• Create additional user fields / models for consent flow

I should be able to zoom in on a map for a job or shift to see its details.

• time started, duration
• mileage so far
• app / employer

One way, using cronJobs in kubernetes and s3: https://jmrobles.medium.com/how-backup-your-postgres-db-into-aws-s3-in-kubernetes-edf6cf0db11

Screenshot processing code and app parsing

We need to implement a back-end API to process user screenshots using methods from shipt calculator.

We can use the layoutLM approach eventually but to start, I think a simple OCR solution should work better.

• File submission API in graphql / graphene
  • API is able to process screenshots
• Client-side code for attaching a screenshot to an active shift
  • should only upload screenshots if a shift is currently being tracked
  • Should post a notification if it identifies it as part of a 'job'
    • To start, it could be a quick ("is this the start of a job? which app?")
• Model development for screenshots, including future parse-able data
• Model development for Jobs, using screenshots, and relation to screenshot schema
• Logic for assigning screenshots to jobs and inferring jobs

The OSRM map matching algorithm adds false miles trips when a user stays stationary for a long period of time.

To close this issue, the following needs to happen:

• create a test suite with example routes with known mileage and run against the OSRM backend
• include example routes with long stationary times
• test different solutions. Some ideas:
  • Run a clustering algorithm to compress high-density clouds of GPS traces to single points in our trajectories. This, run on a user's trajectory, might solve the issue.
  • Save the original estimated mileage when users change the value so we can have a record of inaccuracies
  • run infostop (https://github.com/ulfaslak/infostop) on location data before sending to map match, and get medioid of stay locations. Then, use existing trajectories between these stop points to calculate mileage.

When a user forgets to end a shift, it can be much longer than their real time working.

We should:

• allow users to edit the times of jobs and shifts manually
• ask users if the time of their shift is correct if any of the following is true:
  • The shift is more than 8 hours
  • The shift spans two days (overnight)
  • There is a large ( > 2 hr?) span of no jobs recorded in the shift.

The last job displayed is below the screen. Seems to be pushed down by the header with stats.

I think it should be in the form of cards that sit on the screen, above the today and this week cards, that are a call to action for users.

If a user forgets to end a shift or job, it will continue tracking for many hours. We should both end shifts at a reasonable time and allow users to manually edit the start and stop times of both shifts and jobs.

Right now, to publish our we either depend on our workflow having the correct API_URL env var (in github), or setting the env var manually when we publish (i.e. $ API_URL=https://dev.gigbox.org expo build:ios --release-channel develop).

Instead, we should make these env vars:

API_URL=app.gigbox.org
DEV_API_URL=dev.gigbox.org
STAGING_API_URL=staging.gigbox.org

and then, in our config/code, we should test which release candidate we are building for, and use the proper var:

import { Constants } from 'expo'



function getApiUrl () {
  const rc = Constants.manifest.releaseChannel
  if (rc === 'develop) { ...}
}

we get a response 'too big' from OSRM. I've tried changing limits in our docker-compose.yml.

This feature should enable us to:

• calculate total mileage for a user over an arbitrary time period (start_date and end_date)
• construct routes for each shift (map-matching) from trajectory data
• easily and quickly query for routes

I think this means we need to implement a map-matching service on our backend.

Options:

fast-map-matching

This is a C++ backend that integrates with data from OSM. No docker image. For each shift, the flow would be:

• shift is saved
• we get bounding box of location data and query openstreetmap / osmnx for it
• we use fmm to match trajectory to osmnx street driving network
• return polyline as a shape and project onto appropriate map in frontend.

open-source routing machine

This is a more fully-featured system and might result in faster queries, especially if we download the US road map ahead of time from e.g. geofabrik. The US road map is 7.3GB currently, and we will need to keep this up to date.

I think I prefer this route because:

• the API is clear and accessible through a docker container with a given data file
• If we use fmm, I imagine that we'd eventually want to cache parts of bounding boxes from requests. I don't think this app has to implement that kind of caching to work properly
• I imagine we will use less bandwidth over time if we simply include the US road map on the build for the server and update it periodically

associated:

Location records do not have an associated user_id. This makes finding e.g. total mileage for a user over a time period greater than a shift difficult.

When location is being tracked on a shift, and we see that a user has stopped or started driving out of a stop, we should prompt them to start a job.

After consent, users should be given an initial survey that asks some basic demographic information and what apps they work for.

• store employer data in user model
• survey design on frontend with selecting employers (pill design?)
• employer from user model should be used to populate tracking bar selector

We need to update the OSRM docker image to run the US latest maps or on planet, to provide accurate mileage. This is a big image and will take some time to build!

• build it locally, ensuring it works properly by testing driving emulation in different areas
• try to build it on a deployment infrastructure, and note what resources it needs

• taking screenshots should prompt starting a new job or ending a job depending on context
• Adding a screenshot that we can parse should add pay and other details to a job item
• Screenshots we can't parse should be shown in a useful way.

We should display a separate view for each "trip" in a tracked shift.

• calculate trips using a stay algorithm in the backend
• map-match each trip
• for each shift, display and show trips with a map view

Mileage is calculated on-demand when a query hits the GetWeeklySummary endpoint. Instead, we should cache this result in the Shift model itself when it's saved.

Workers should be able to export their data to a CSV that they can then email or just download to their phone

We should send a toast or some similar UX validation when an OTP is sent to a user to make sure they know it's been sent

Instead of the source for images being a user's copy // the local URI for a resource, we should request and display the image that's been uploaded to the server instead. This allows a user to use multiple devices, and it means that the local screenshot can be deleted but this feature will still work.