[regression] mode/purpose dropdowns no longer show prior "other" responses

[shankari]

Before the rewrite, we used to incorporate "other" responses into the dropdowns. Concretely, if the user added "pogo stick" as the selected mode, then for the next trip that they try to label, "pogo stick" will be an option. This allows us to eventually build a user-specific selection of mode and purpose choices, which allows us to capture the long tail of modes that are very important to individual users, even if they are not known to be very prevalent societally. This allows us to understand how prevalent such modes actually are, and how they should be accounted for in societal-level decision-making.

This behavior has regressed during the rewrite. This is not a showstopper and can be addressed in a cleanup change.

[shankari]

Before the rewrite, the new modes were filled in based on the modes that were pulled from the server. So if the "pogo stick" mode was last used last month, it will not show up this month by default, until the user pulls more data. While re-implementing this, we want to:

• make sure that all prior labels for the user are considered, potentially by storing the labels in the user profile or similar
• maybe only show the top 'n' modes for the user, with the remaining available via dropdown expansion or search
• if time permits, allow users to specify make/mode/year for cars so we can have more informative carbon footprints
  • we can either have users fill out their car make/model/year during onboarding OR
  • do so at the time they enter the new mode, so that we can more easily capture changes to the cars available to participants over time.

[shankari]

I would suggest doing this incrementally in the order above. Let's design and implement (1) first and then (2) and then (3) But keep (2) and (3) in mind while designing (1) so we don't have to refactor/revisit too much code.

[shankari]

@jiji14 will work on this end to end, next step will be to add in a design with pros and cons

[jiji14]

Step 1

• Save the Mode when a user writes a customized mode through the Other option.
• Show customized modes ordered by most frequently used and most recent after the default list of modes.

User Flow:

1. For trip A, a user saves my car through the Other option.
2. After this, my car option will be displayed after the default list of modes.
3. From trip B, a user saves my bike through the Other option.
4. After this, my bike and my car will be shown after the default list of modes, ordered by creation time in reverse (Because each mode is equally used once).
5. For trip C, a user selects my car mode.
6. my car and my bike will be shown after the default list of modes. (The order is based on usage frequency; my car appears twice, and my bike once.)

Handling Long Text:

• We can either limit characters in the input (e.g., 20 characters) or use text truncation.
  • Limit Character:
    • Pros:
      • Ensures a clean UI with one mode displayed in one line.
    • Cons:
      • Users might find the character limit restrictive.
  • Use Text Truncation:
    • Pros:
      • Allows flexibility in mode description.
      • Maintains a clean UI with truncated text.
    • Cons:
      • Users can't see the full text.

I am more inclined towards limiting characters but our current UI is using text truncation. I believe 20 characters are sufficient, and if we use truncation, we would need to display the full text, but I can't find any good ways to show it without affecting the UI. I will discuss this matter next UI meeting.

Handling a Large Number of Modes:

• I propose limiting the number of modes (e.g., to 50) to prevent users from adding numerous modes for unnecessary purposes. When displaying modes, I don't think a "more" button is necessary since there is a scroll function in the modal.

• Pros:

  • This limitation can prevent users with malicious intentions.

• Cons:

  • Users might perceive the limit as restrictive.

I strongly believe in the necessity of limiting the number of modes a user can upload, but we should engage in further discussion about determining the specific limit.

How Should We Store Modes?

1. Save Modes in Native App Storage:

   • Initially, I considered saving modes in native app storage. However, this approach has a drawback—it's temporary. When a user logs out or redownloads the app, the previously stored data will be lost, which doesn't align with our intended use.

2. Save Modes in Database (Consider Profile Collection):

   • After reviewing collections, the Profile collection appears to be a suitable choice for storing mode data.

Option 1 - Store Data in Object Type:

We can store data as a name-object pair and organize it based on frequency and creation date. To achieve this, we would need to update the frequency whenever a user saves or changes a customized mode. For instance, if a user adds my car,the frequency of my car becomes 1. Subsequently, if the user changes my car to other customized mode, we need to decrease the frequency of my car to 0 and increase the frequency of the other mode.

   {
       ...
       "mode": {
           [name]: {
               [createdAt]: Date,
               [frequency]: Number,
               ...
           }
       }
   }

• Pros:

  • Ensures uniqueness in keys to avoid displaying the same mode twice.
  • Facilitates sorting modes by frequency, achievable through a straightforward sort function in MongoDB.
  • Simplifies the delete function, allowing us to retrieve the mode with O(1) time complexity.

• Cons:

  • Requires frequency updates whenever a user saves or changes a customized mode.

Option 2:

Despite efforts to explore alternative methods and data structure, option 1 seems to be the most efficient. Please share if you have other ideas or considerations.

Step 2

• Add Manage My Mode to the Profile tab.
• Same functions as Step 1 (Add mode / show mode list) but within the Profile tab.

Step 3

• Add Delete Mode function on Manage My Mode.

User Flow:

1. A user clicks on Manage My Mode.
2. The user clicks the delete button next to the item in the list.
3. A confirmation popup appears, asking if the user wants to proceed.
4. The user clicks yes, and the mode is deleted.

What if a user deletes a mode and adds the same mode again?

If a user deletes a mode and subsequently adds the same one, consider treating it as a new mode and resetting the information. Alternatively, we can set an isActive key to retain all modes and change isActive from true to false when a user deleting it.

   {
       ...
       "mode": {
           [name]: {
               [createdAt]: Date,
               [frequency]: Number,
               [isActive]: Boolean
               ...
           }
       }
   }

Step 4

• Get more information When a user add new mode
• I'll provide an update to this section after collaborating with other interns to determine the specific information we require from users.

Note: I intend to submit a pull request in the order of Step 1 > 2 > 3 > 4. Kindly review each step and feel free to comment if you have any questions or if I overlooked anything.

[shankari]

@jiji14 Step 1 looks fine at a high level.

Comments to ponder and discuss:

I strongly believe in the necessity of limiting the number of modes a user can upload, but we should engage in further discussion about determining the specific limit.

I think this needs some thought. Maybe I first live in a small rural area with one set of modes, and then I go to a big city with a completely different set of modes. So between the two, I end up at the limit. Will I be prevented from adding any more modes? I think that it would be better to remove the lowest frequency older modes and allow the user to add new modes. But maybe this is moot when we have "Manage my mode"

Add Manage My Mode to the Profile tab.

I think we may want to have this during onboarding as well, at least in Step 4. Because otherwise, the user might just use "drove_alone" instead of taking the effort to enter "my car" since it is not "other". Or is the expectation that we would not have any default modes after this change?

[jiji14]

@shankari

Yes, this is when we have "manage my mood" because a user can delete unused modes there. My thought was that it would not limit the user experience when a user can add enough modes, and they can delete some of the modes they haven't used for a while. I will discuss this issue in the UI meeting too.

Also, adding it to onboarding seems like a good idea. I will implement that after adding the "manage my mode" feature.

[jiji14]

During the meeting, we addressed the following points:

@shankari

1. Setting a character limit of 20 for customized modes will make better UI.
2. While limiting the number of customized modes is a good approach, we need to implement the deletion feature first.
3. Concerns were raised that onboarding might become lengthy with the addition of the mode feature. An alternative suggestion is to inform users that they can create their own mode.

I'll proceed with the implementation of Step 1. Please let me know if you need me to collect something.

[shankari]

when we get to (iii) I would like to discuss further. I see the comment about onboarding, but I don't think people will do anything that they don't have to.

[shankari]

Related changes are merged. We still need to determine how to account for the energy/emissions of the newly entered modes.