Unifying label and diary views

[shankari]

• code for label and diary is in www/js/diary and www/templates/diary
• diary view is list.js and list.html
• label view is inf_scroll.js and inf_scroll.html

In angular1, the UI is in .html and the javascript controlling the UI is in .js in a type of class called a controller

The functionality in both of them is almost the same. Our goal is to modularize and unify the two so that we have one codebase and the users have one place to go do label trips.

[shankari]

in angular1, the way to create modules, or at least the way that we will use, is called directives. documentation: https://docs.angularjs.org/guide/directive example: https://www.w3schools.com/angular/angular_directives.asp ("Create new directives")

I also have examples in the code of directives - e.g. in the list.html, and in inf_scroll.html we include linkedsurvey with a flag that is the surveyOpt.elementTag variable to represent the labels that that users can edit.

             <div class="row" style="padding-left: 5px;padding-right: 5px;">
              <linkedsurvey element-tag="{{surveyOpt.elementTag}}" class="col" trip="tripgj"></linkedsurvey>
             </div>

linkedsurvey is defined at https://github.com/e-mission/e-mission-phone/blob/master/www/js/survey/survey.js as you can see, its HTML is a simple wrapper which chooses the multilabel or enketo-trip-button depending on the input flag.

multilabel is another directive, defined at https://github.com/e-mission/e-mission-phone/blob/master/www/js/survey/multilabel/multi-label-ui.js

Directives allow you to define custom tags. Instead of the classic HTML tags such as <div or <img or <button or anything, you can define a tag called diary-item which encapsulates the view and the controller for each row in the diary/label screens.

You can then pull out the code from the existing diary and list views that deal with the items, put in here and unify it. you may want to start with first having two versions that are controlled by a flag (isDiaryView or isLabelView) then see how much code overlap there is, and then unify.

[shankari]

Task 1 is to take the stuff in the <ion-item for the diary or inf_scroll view and create a directive for it. you can pass in the trip as a parameter. There should be very few controls/no controls because most of the user interaction is in the labels which I have already created a directive for.

when you see the <ion-item, you will see class="row" and class="col". these are part of CSS flow elements which ionicframeworkv1 has defined to ensure that elements can resize as needed. https://ionicframework.com/docs/v1/components/#grid

[tyleryandt18]

Here is the directive that I created

[shankari]

so this is a great start, but it puts too much information into the controller. So if we wanted to use this directive in another screen with its own controller, we would need to copy-paste the tripSummary function that combines everything into the return statement into that controller as well. So we are not getting the benefit of pulling it out into a directive.

An even simpler example is if we wanted to have a list of 5 trips that we are showing. Naively you would need to copy tripSummary 5 times. Try using ng-repeat and convince yourself that the naive approach does not work to show 5 different trips and document what you tried and how it failed so I can know you are understanding it.

Instead, we want to put the code that creates that string into the directive. We want to have the directive take a trip object with sub-fields for startAddress, endAddress.... and then construct the string inside the directive.

In the e-mission-phone codebase, trip objects are already created by reading them from the server. But you cannot do that yet because you are building this standalone. So you should create a trip object with the fields in an e-mission trip, but populated manually for now. e-mission trip object structure: https://github.com/e-mission/e-mission-server/blob/master/emission/core/wrapper/cleanedtrip.py

So the next steps are:

• try to use the current directive to populate a list of 5 different trips and post your attempts here
• change the directive to take a trip object with a similar structure to the e-mission trip object
• populate a list of 5 different trips with the new directive
• (stretch goal) change the HTML for the directive to actually have 2-D structure instead of being a string
  • you can look at the current ion-item for an example https://github.com/e-mission/e-mission-phone/blob/master/www/templates/diary/list.html#L46

[tyleryandt18]

This was my first attempt to use ng-repeat to create a list of 5 trips. It is a little different than the directive that we were working with earlier because I coded the array of trip objects into it, and therefore with ng-repeat I could print out each attribute (startAddress, endTime, etc). I realize that ng-repeat would not work with the tripSummary function because the trip object itself does not have a tripSummary function, so in the below screenshots when I use ng-repeat="trip in trips", the trip.tripSummary() will not produce anything. Furthermore, in the directive that we worked on earlier, ng-repeat would not function properly to produce a list of 5 different trips because there is only one trip hardcoded in; only one $scope.startAddress etc. If this isn't the realization you wanted me to come to, let's talk about it in our 1:1.

[shankari]

If this isn't the realization you wanted me to come to, let's talk about it in our 1:1.

Yup, that is the realization. Note also that with the first approach, you are not even using a directive. You are putting in the h3 directly into the ng-repeat. This is effectively the approach that we use right now in list.html only using collection-repeat instead of ng-repeat.

See if you can read the list.html code and map your first solution to it.

Why is this not good enough? Why do we even need a directive?

[tyleryandt18]

I might need some guidance going over list.html in our meeting. I do notice the collections-repeat; that part makes sense to me wherein it's taking each trip in data.currDayTripWrappers and displaying it's start time with {{tripgj.display_start_time}}.

I understand that directives allow us to create custom html tags, but what is the benefit of this? I'm not sure why we need a directive other than to consolidate the code from the label and diary views.

[shankari]

one of the benefits is the one that you outline right here:

I might need some guidance going over list.html in our meeting. wherein it's taking each trip in data.currDayTripWrappers and displaying it's start time with {{tripgj.display_start_time}}.

As you can see from the app UI, it displays a lot more than the start time, but it is hard to read it in the code because it quickly gets very complex. Pulling out the code into separate modules and sub-modules makes it easier to read and modify one small part of a complex system.

[tyleryandt18]

As you can see from the app UI, it displays a lot more than the start time, but it is hard to read it in the code because it quickly gets very complex. Pulling out the code into separate modules and sub-modules makes it easier to read and modify one small part of a complex system.

Ok, yeah that makes sense. Using directives to make the code easier to read / modifying smaller parts of a complex system

[tyleryandt18]

Here's my attempt to populate a list of trips using directives. Again, I know it is very simple, but I've never worked with directives before and I feel like it's a good baby-step start  .

[tyleryandt18]

It pushes the new trip that I created using the input buttons into the scope's array of trip objects (obviously you can figure that out but I like to talk about my thought process haha)

[shankari]

By Monday, remaining tasks are:

• use a directive that takes trip objects instead of using controller + inline HTML
• populate a list of 5 different trips with the new directive
• (stretch goal) change the HTML for the directive to actually have 2-D structure instead of being a string
  • you can look at the current ion-item for an example https://github.com/e-mission/e-mission-phone/blob/master/www/templates/diary/list.html#L46

In parallel:

• install the CanBikeCO app using the instructions that I provided earlier
• correlate what you see in the UI to list.html
  • this is probably the best way to understand what the current ion-item does

[shankari]

concretely, for step 1, the goal is for your HTML to look like (psuedo-code, DO NOT COPY AND PASTE).

<div ng-app="">
   <div ng-repeat="trip in tripList">
     <trip-summary trip="trip"></trip-summary>
   </div>
</div>

and have the output be the same as your prior output.

You literally have to create a directive that encompasses everything within the h3

[tyleryandt18]

• look up how to pass an object into a directive
• create 5 trips with that directive without repeating the functions like in the code that I have here already
• look up creating two-dimensional structures for directives
• install and log trips into CanBikeCO to see what is going on in the list.html

[tyleryandt18]

Here is what I was able to get through on Friday. I understand now how to pass an object into a directive, but I did have struggles with populating the list within the directive, and not just simply having the list of 5 trips already established in the ng-init. I tried to create a function within the directive that would push a trip into a tripList array. This tripList array would initially be an empty array, which could be accessed the same way that we are accessing each trip tripList: '=tripList', and then the function would be function addTrip(trip, tripList) {tripList.push(trip)};, but I couldn't get it to work.

I was unable to format a 2D structure. I did not have enough time over Friday, nor do I fully understand the list.html elements even after logging trips on the CanBikeCo app.

[shankari]

so this is actually fine so you are done with everything other than the 2-D structure. My high level comments are:

• naming matters: so don't call this my-directive
• the template is typically not a full HTML document, but the part that is within the body. So the top level of the directive would be something like <ion-content or <div or something like that. Concrete examples:
  • https://github.com/e-mission/e-mission-phone/blob/master/www/templates/survey/multilabel/multi-label-ui.html (top level is a div)
  • https://github.com/e-mission/e-mission-phone/blob/master/www/templates/metrics/range-display.html which just has a span

Next step is to understand the list view and to pull out the items in the list view into a directive.

[shankari]

• Use only iOS for now
• ios-sim or xcrun simctl to start a simulator
• unzip the app.zip and drag/drop to the simulator to get the devapp working (check with @sebastianbarry if you have issues)

Next task:

• Get the app working on your laptop and be able to load data
  • If you don't want to set up a server, you can use the staging server with your token but make sure not to mess up the data too badly because we do use it for analysis down the road.
  • To connect to the staging server, create a file in the phone repo called www/json/connectionConfig.json with the following text

    {
    "connectUrl": "http://stage.canbikeco.org",
    "aggregate_call_auth": "no_auth",
    "android": {
    "auth": {
        "method": "prompted-auth",
        "clientID": "ignored"
    }
    },
    "ios": {
    "auth": {
        "method": "prompted-auth",
        "clientID": "ignored"
    }
    }
    }

    and login with your token

Next step after that:

• Pull out everything in the ion-item in the infinite scroll (https://github.com/e-mission/e-mission-phone/blob/master/www/templates/diary/infinite_scroll_list.html) into a directive that you pass the trip into.
  • The HTML part of this is relatively easy
  • The javascript should also be fairly easy because you don't have to touch the code around how the trips are read, you just need to pass in correctly from the ng-init

Try to get both of these done in 2 days (by Wed evening).

[tyleryandt18]

Pulled out the ion-item into a directive. Instead of using the scope, simply used the itemHt and passed in a height of 150, which was established in the $scope.

[shankari]

Next steps (note that we are a week late):

• Update this issue and submit a PR with what you have
• Pull out this directive into its own module instead of putting it into the infinite scroll module
  • this will allow us to use it in both files and also reduce the temptation to just include parts of the existing module without pulling them out
• create a separate controller for this directive in this module
  • pull out the functionality that is in the infinite scroll controller that is related to this (surveyOpt, itemHt variables, any functions, ....) and include it in the directive's controller instead of passing it in
• stretch goal: pull out the diary item into a separate directive so that we can then focus on the differences between the directives and unify them.

[shankari]

the diary and infinite scroll directives are almost the same visually, but they expect the trip structure to be fairly different.

diary

in the diary items, each trip is expected to be a geojson object. geojson is a standard format to represent geographic data as json.https://geojson.org/

So it retrieves the full list of trips for a particular day, with each trip as geojson that includes all of the objects that make up the trip. So I think that the trip is a geojson feature collection: start feature, end feature, n section features, each section is a feature collection with a start/stop and a linestring for the trajectory. Each feature has properties for distance/duration/...

Putting a breakpoint at https://github.com/e-mission/e-mission-phone/blob/master/www/js/diary/list.js#L204 will allow you to see the base structure of the geojson that is retrieved from the server. DiaryHelper.directiveForTrip); adds some formatting fields to the retrieved trip geojson. Again putting a breakpoint at https://github.com/e-mission/e-mission-phone/blob/969d8a1274eda809e261506f43d7cc6540d036df/www/js/diary/list.js#L211 will help you see what new fields are added and map them to what is shown in the directive.

infinite scroll

For the infinite scroll, the retrieved trips are in the openpath trip format. https://github.com/e-mission/e-mission-server/blob/master/emission/core/wrapper/confirmedtrip.py

Note that this does not have sections or trajectories embedded when we retrieve them. We retrieve a downsampled version of the trajectory when the map popup is opened, which is why we don't show the map by default.

To see the trip format here, put a breakpoint at: https://github.com/e-mission/e-mission-phone/blob/969d8a1274eda809e261506f43d7cc6540d036df/www/js/diary/infinite_scroll_list.js#L108

to see how we retrieve the trajectory

that returns the trip as geojson with an embedded trajectory, which we can then show in a leaflet map https://github.com/e-mission/e-mission-phone/blob/969d8a1274eda809e261506f43d7cc6540d036df/www/js/diary/infinite_scroll_detail.js#L70

        <leaflet geojson="tripgj" id="infscroll-detail" defaults="mapCtrl.defaults" 
            height="50%" width="100%" data-tap-disabled="true">

This is particularly confusing because we sometimes call a variable tripgj aka trip geojson when it is actually a trip object.

to unify the two, we should really standardize on one method for retrieving and representing trips, otherwise, we will continue to have two implementations and a lot of confusion.

[tyleryandt18]

I am going to go ahead and go out on a limb here and say that we should implement the diary trip item, the one that is a geoJSON. As you noted in this second-to-last line, there is a confusion when we read in the trip from inf_scroll as a tripgj. Furthermore, I feel as if having the map data in the trip without having to do that extra step of retrieving the trajectory when we open the map popup.

NOW If I am wrong, or if I have the same implementation as you do in mind but the wrong reasoning behind it, or if I have let out any key details, please let me know. I would love to understand this fully, and as it sits right now I am still a little shaky on my understanding. I also believe that the structure of the diary tripgj was much simpler <img width="961" alt="Screen Shot 2022-07-09 at 7 42 13 PM" src="https://user-images.githubusercontent.com/8

9606659/178128940-93d3471e-6862-4439-b306-0245687d46d0.png"> .

[shankari]

@tyleryandt18

Furthermore, I feel as if having the map data in the trip without having to do that extra step of retrieving the trajectory when we open the map popup.

Agreed that having the map inline instead of opening another popup is useful.

I also believe that the structure of the diary tripgj was much simpler

Not sure why this is; can you clarify?

I am going to go ahead and go out on a limb here and say that we should implement the diary trip item, the one that is a geoJSON.

Did you look into which came first, diary or label screen? What were the problems with the older version that prompted the creation of a newer version? Did you search through the existing list of issues?

[tyleryandt18]

@shankari

Not sure why this is; can you clarify? <img width="839" alt="Screen Shot 2022-07-09 at 8 11 14 PM" src="https://user

When looking at the trip objects at those breakpoints, the trip in the diary has less features. I believe this is due to the fact that in the diary item (top screenshot), the start time and end time and trip information is saved in the geoJSON, and therefore we do not need to create the separate fields such as in the trip object in the inf_scroll (bottom screenshot).

Did you look into which came first, diary or label screen? What were the problems with the older version that prompted the creation of a newer version? Did you search through the existing list of issues? It appears that the list.js appeared first, as the oldest commit change that I noticed was 6 years ago as opposed to the inf_scroll which was 2 years ago.

I found this issue particularly interesting, #623. Idk if that links to the issue, but the issue stated that the start and end times could not be read into the leaflet map from the tripgj, so a start and end time attribute were added, possibly causing the implementation of the trip object that we know in the inf_scroll.

[shankari]

@tyleryandt18 Do you know how to find the original checkin for various files? Look at Github blame - e.g. https://github.com/e-mission/e-mission-phone/blame/master/www/js/diary/infinite_scroll_list.js and https://github.com/e-mission/e-mission-phone/blame/master/www/js/diary/list.js

A search for prior diary issues could also be instructive https://github.com/e-mission/e-mission-docs/search?p=3&q=diary+screen+load&type=issues

Notably: https://github.com/e-mission/e-mission-docs/issues/226 and https://github.com/e-mission/e-mission-docs/issues/488 and https://github.com/e-mission/e-mission-docs/issues/707

Note that several of these are linked here, or to each other.

[tyleryandt18]

@shankari Ok so looking over those issues, loading in the data from the geoJSON trip is too slow. This is due to the fact that loading in the trip onto the map in the geoJSON takes too long? That checks out in my mind, mapping each trip onto the map in the diary screen would take some time. And yes, I was using the blame feature, but perhaps in the wrong way.

So, with this delay in loading in the data, we should use the trip object found in the inf_scroll_list. This would provide a solution to the slow loading of the geoJSON trip since the map leaflet would only appear when we go to the popup, ie click on the trip on the label screen.

[shankari]

@tyleryandt18 yes, I think we should use the trip object found in the inf_scroll_list. However, that provides much less information than the diary screen. Note that the bug wants to focus on unifying the list and diary screens, not just picking one.

• We should think through which aspects for the diary screen we want to port over to the label screen
  • we probably do want the inline map, BUT
  • we may not want to port everything over - maybe the diary screen is too complex the way it is
  • you may want to brainstorm with @sebastianbarry/other interns/friends and family on what the new unified design should have and draw it out on figma et al if needed.
• Then, we can figure out how to populate those aspects by using the base e-mission objects to fill in pieces dynamically on the client side instead of the server side.

[tyleryandt18]

@shankari Ok great! Noted on the unification, not just picking one.

I'm actually looking over right now what features I would want to pull over from the diary screen as you sent this! I think the in-line map is a must. I also agree with @sebastianbarry regarding the color scheme of the UI, that NREL blue looked really good.

[tyleryandt18]

@shankari High-Level Implementation Functionality for the Unified Screen

• in-line map leaflet
• left-to-right scroll instead of infinite up-down. I feel like this will provide a simpler look because you are only seeing one trip at a time, therefore seeing less information at once.
• NREL blue replacing the mint green
• include the percentages of trip mode on the trip

Other than that, I think that our infinite_scroll screen has a good baseline. It's simple and concise, I think that maybe we just switch to a left to right scroll, sort of like the "notebook feel" that @sebastianbarry had mentioned. Or, maybe we implement the diary screen's method of having the date drop-down, and then you can scroll through your trips up-down for that given day.

[tyleryandt18]

Instead of the left-right scroll, let's go with the diary screen's date chooser, where you can go to a certain day and then see all of the trips from that day.

[shankari]

@tyleryandt18

Instead of the left-right scroll, let's go with the diary screen's date chooser, where you can go to a certain day and then see all of the trips from that day.

How would this work concretely? like the current diary view? How would you address the limitations with the current diary view and its selection process?

[tyleryandt18]

@shankari I was thinking that it would look the same as the current diary view, but I think that the current issue with the slow retrieval is in relation to this date selector; once the user chooses a date, the app then must retrieve the data from the server. Could we fix this issue by storing the data locally on the user's phone?

[shankari]

@tyleryandt18 the slow retrieval is not the only issue; please read through all the related issues that I have tagged.

A challenge with the date selector approach is that, while labeling, you have to know which is the previous date on which:

• you had a trip
• you had an unlabeled trip

How would you propose to overcome that challenge?

[tyleryandt18]

@shankari I see what you mean by this issue. That is a nice feature of the infinite scroll Label screen, that it can show you the trips that you need to label.

A solution that I have for this is that we could implement a notification, perhaps a red flag, on the dates that you have not yet labeled a trip for. And when you are on a date that you have all your trips labeled, there could just be a little red flag on the date itself so you know that you have trips to label.

For example, the red flag would appear in the corner of the "11 Jul" button on the top if I had a trip to label for the 10th.

Furthermore, in terms of aesthetics, I find their simple color scheme super appealing. I think we should stick with one color, the NREL blue throughout. I think it looks good that their buttons are not red when unlabeled. For us, the purpose and mode button are red if you haven't labeled a trip. Although I like that aesthetic choice, it does provide functionality in the sense that it alerts the users that they haven't labeled a trip there. My thought is to leave the trips white as our friends in Montreal have, but carry over the red flag from earlier and attach it to a label button that has not yet been filled out.

I also like the split down the middle with the map leaflet on the left and trip data on the right, but I wouldn't want to copy their design choices.

[shankari]

@tyleryandt18

First, I want you to stop thinking of the final solution as either/or. Our goal is not to pick either infinite scroll or diary but to unify them. What might a unified view look like?

I see what you mean by this issue. That is a nice feature of the infinite scroll Label screen, that it can show you the trips that you need to label. A solution that I have for this is that we could implement a notification, perhaps a red flag, on the dates that you have not yet labeled a trip for. And when you are on a date that you have all your trips labeled, there could just be a little red flag on the date itself so you know that you have trips to label.

I am going to push back on this for two reasons:

1. The infinite scroll not only shows you trips that you have to label, but also "All trips" as an unbroken timeline that you don't have to keep clicking through for. Let's say I have labeled all my trips but I want to scroll through to what I did last week. With diary, you would need to click though to last Sunday and then click through day by day. And on some days, I wouldn't even have any trips. Why is more clicks better than fewer clicks?
2. You also need to think about ease of implementation. How concretely would you determine (from the phone) which dates have trips to label? How and where would you display the flag so users could easily see it?

For example, the red flag would appear in the corner of the "11 Jul" button on the top if I had a trip to label for the 10th.

What if you had labeled 9th and 10th, but had an unlabeled trip for the 8th? You launch the app and you see the diary for the 11th. What do you do?

The diary option is essentially an query pattern for trips - pulling out the trips for one particular day. Can you articulate your reasons why you want to pick this, and only this access pattern? I haven't yet heard a reason why supporting only day-by-day access is optimal.

Furthermore, in terms of aesthetics, I find their simple color scheme super appealing. I think we should stick with one color, the NREL blue throughout. I think it looks good that their buttons are not red when unlabeled.

This is because they haven't implemented the label assist feature yet.

For us, the purpose and mode button are red if you haven't labeled a trip. Although I like that aesthetic choice, it does provide functionality in the sense that it alerts the users that they haven't labeled a trip there.

Note that although you don't have them, we also have yellow labels to indicate our guesses for the labels. You can see them too if you actually label your trips!

My thought is to leave the trips white as our friends in Montreal have, but carry over the red flag from earlier and attach it to a label button that has not yet been filled out.

What would this look like concretely (sketch plz)? And how would you deal with yellow labels?

[tyleryandt18]

@shankari

I am going to push back on this for two reasons:

1. The infinite scroll not only shows you trips that you have to label, but also "All trips" as an unbroken timeline that you don't have to keep clicking through for. Let's say I have labeled all my trips but I want to scroll through to what I did last week. With diary, you would need to click though to last Sunday and then click through day by day. And on some days, I wouldn't even have any trips. Why is more clicks better than fewer clicks?

You're right, I wasn't thinking of the number of clicks, more in the sense of organization by date. I was thinking more along the lines of what if I wanted to view a trip from three months ago? (not sure why I would per say, so maybe that is an important note too) With the infinite scroll screen, I would have to scroll up all the way to find that trip, as opposed to the date selector, where I can go to that certain date and look at it with ease.

2. You also need to think about ease of implementation. How concretely would you determine (from the phone) which dates have trips to label? How and where would you display the flag so users could easily see it? In the multiabel html, we have an ng-if determining if it's labeled, inferred, or neither. Very elementary, but couldn't we include the flag popup if.... ng-if="!trip.userInput[input.name] && !trip.finalInference[input.name]"? And include the flag icon in the button class?

For example, the red flag would appear in the corner of the "11 Jul" button on the top if I had a trip to label for the 10th.

What if you had labeled 9th and 10th, but had an unlabeled trip for the 8th? You launch the app and you see the diary for the 11th. What do you do?

There would be a flag icon in the date selector. I will draw a sketch of what I mean by this. You then would click on the date selector, see the calendar, where there would be a flag indicator on the date with an unlabeled trip, then go to that date and label it. But you're right, after typing that out, the implementation doesn't sound too easy.

The diary option is essentially an query pattern for trips - pulling out the trips for one particular day. Can you articulate your reasons why you want to pick this, and only this access pattern? I haven't yet heard a reason why supporting only day-by-day access is optimal.

I believe that the main reason why I was in favor of that access pattern is for accessing past trips. With the infinite scroll access pattern, I have to scroll up to find a previous date. My mind fixated on this problem without considering that that issue may not arise as often as I think, because how often do users access previous trips? Probably not often after they are already labeled.

For us, the purpose and mode button are red if you haven't labeled a trip. Although I like that aesthetic choice, it does provide functionality in the sense that it alerts the users that they haven't labeled a trip there.

Note that although you don't have them, we also have yellow labels to indicate our guesses for the labels. You can see them too if you actually label your trips!

I do see what you mean by the yellow labels. I think stylistically we should consider a different color scheme instead of the red green and yellow. Aesthetically I think they clash, but in terms of functionality, they provide good indicators.

I will work on the sketches now.

[tyleryandt18]

Red flag notifying that there is a day without a trip labeled

Red flag indicating that the day to label is on the fifth

[tyleryandt18]

But again, I see the benefit of the infinite scroll access as opposed to date selector (I understand that we are creating a unified screen, that is just poor wording), but I wanted to diagram my thoughts for how the red flag idea would work.

[shankari]

You're right, I wasn't thinking of the number of clicks, more in the sense of organization by date. I was thinking more along the lines of what if I wanted to view a trip from three months ago? (not sure why I would per say, so maybe that is an important note too) With the infinite scroll screen, I would have to scroll up all the way to find that trip, as opposed to the date selector, where I can go to that certain date and look at it with ease.

@tyleryandt18 You are absolutely right that the infinite scroll pattern also has its drawbacks, which is why I think we should come up with a way to unify the two approaches and support both kinds of access patterns.

Think through how the other apps handle the use case that you want to be able to scroll smoothly and see your history/timeline but also jump around in it to specific places?

• Just checked and WhatsApp doesn't do anything specific - you do just have to scroll back to find older messages, even if they are from a year ago (so we have to be better than WhatsApp. Hmmm....)
  • WhatApp does have a search button, though. Maybe thinking of this as a searching problem can give you some ideas.
  • For example, what if we just added a date selector to the top of the infinite scroll screen? People can then use it to quickly "jump" to a place in the scroll list, but then continue scrolling from there to avoid clicks.
• I don't really have any other social media (I am not on FB/IG/TikTok etc) to use as examples, but maybe you or your friends/family do
• In a related domain, how do calendar apps (which have the same problem) deal with this? at least on mobile, you want to be able to see your meetings for a week "at a glance" but you want to be able to pick a date as well.

[tyleryandt18]

@shankari I'm thinking that on our unified screen, we add a button to the top that has a calendar popup that can take you to a certain day. I liked your idea above of just adding a date selector to the top of the infinite screen. I am thinking that it would look something like this, with the to label/all trips/unlabeled trips buttons shifted over to the right slightly more to create even spacing. Then the date selector would function the same, with the red flag also appearing to mark days that you haven't labeled yet.

[shankari]

@tyleryandt18

• we could also consider removing "All Unlabeled" or convert the labeling buttons to a dropdown to make some room. Not sure how many people are using each screen, maybe check with the focus group as well?
  • Edit: if we are focusing on user utility and are removing the diary screen, maybe we should make the "All Trips" be the default and have a separate filter for "To Label"
• also what color do you plan to use for the red labels? you should have a screenshot showing them as well.
• edit: wrt "Then the date selector would function the same, with the red flag also appearing to mark days that you haven't labeled yet."
  • Edit: Do you know whether the date selector library we are using supports this? If not, is there another one which does, or are you going to modify it to support the functionality that you want?

Plan out which 3 options (colors/layout) you are going to mock up and share with the other interns for feedback

[tyleryandt18]

wrt the red labeling, I was planning on having a white button with the NREL as an outline for it, and then once the user labels it switches over to the NREL blue full button. I think that having All Trips as the default is a good idea. I'm not sure what the difference is between unlabeled and to label trips is, so maybe we eliminate that and only have the three filters; Calendar, To Label, and All Trips.

I will look into the calendar library.

[shankari]

I will look into the calendar library.

I would first mock up and get feedback

[shankari]

Also, think about the labels to make more sense:

• mode -> dominant mode?
• purpose -> destination?
• replaced mode -> if unavailable?

[shankari]

I'm thinking that on our unified screen, we add a button to the top that has a calendar popup that can take you to a certain day.

Could you also list out what other apps do as a sort of "related work"? At least in a lab, we would like to have more justification for our decisions than what one person likes.

[tyleryandt18]

@shankari

The only social media platforms that I have are instagram and a fairly new format called BeReal. Both have implementations of an infinite scroll on the feed. I could provide screenshots if you would like, but I would have to import from my phone. I suggest that we scratch the calendar feature. I can't find any social media platforms to support implementing that feature. Nor would I think that one would want to see their past trips with enough enthusiasm to the point in which it is worth implementing, if that makes sense. If you want to see a past post on instagram, you either have to scroll until you find it, or search for a person's profile to find that user, and then scroll on their specific profile's feed to find that post in the past.

My mockups have only two filters on the screen, All Trips and To Label. This provides the users to have an infinite scroll feature to see all of the trips that they need to label, and then a scroll to see all of their past trips. I received feedback from the team on the color schemes, so the ones that I have implemented here are the most popular. I have not yet shown them these mockups, so I will send out some surveys to them after I finish writing this up.

Mockup 1: I figured I would just include to the side what an inferred label color would look like, because adding in another trip would extend past the visible screen on a phone anyway.

Mockup 2:

Mockup 3:

My Figma skills are still very elementary, so I understand that not everything lines up to an exact pixel, but obviously that will be fixed when I decide upon a design and implement it with code.

Again, popular social media supports the decision of an infinite scroll, as it is found to be very addictive. A recent trendy app is TikTok. I don't use it because it is so addictive. It uses an infinite scroll feature to display its content. Recently, it has even begun to develop updates to stop you from infinite scrolling because it has been so addictive. I'm not saying that our users will become addicted to labeling their trips, but it is a better option as opposed to the calendar / date selector.

[shankari]

@tyleryandt18 wrt

I received feedback from the team on the color schemes, so the ones that I have implemented here are the most popular.

what was the feedback? Did you ask them about the green/yellow/red color scheme as well? Because the advantage of using the green/yellow/red scheme is that it is super clear to explain "Make all trips have green labels"

I suggest that we scratch the calendar feature. I can't find any social media platforms to support implementing that feature.

Well, let's not jump to that conclusion. It does seem to indicate that people are used to an infinite scroll, which argues for keeping it as the primary interface. But the date selection is also useful - note that social media apps want to keep you scrolling longer so you spend more time on the app, and hopefully more items in the feed catch your eye. This is really not a huge consideration for us.

I also don't see any check on how calendar apps (which do care a lot about looking up dates) work.

Removing existing functionality in one big swoop is generally a bad idea without significant user feedback.

I would check with the other interns on their preferences around how to combine the list again, and also ask Sebastian about the feedback from the Smart Commute participant focus group. Please report a summary of the feedback.

[tyleryandt18]

@shankari Key takeaways from Smart Commute feedback -

• They liked the diary-style views with the in-line map, which we will implement
• slow labelling
• it isn't obvious how the app works. I have experienced in feedback from my own family, where I have to explain how the app works to them too. Maybe we should implement a tutorial walkthrough. Other interns also suggested that there be a color-scheme key whether that be with the blue scheme or red/green/yellow; explaining what each color represents.
• They liked the date selector, which Sebastian also specifically mentioned when I asked him about this focus group.
• A common theme that I have seen in all feedback forms is that there is no motivation to label trips, and it feels like a chore to do so.

AngularJS has a date selector/calendar library that supports notifications, it "can display events on a month, week or day view. It's called angular-calendar.

[tyleryandt18]

wrt to the interns' opinions on red/yellow/green vs new color scheme, most of them stated that they preferred the new color schemes, as it provided a clean look. I feel as if we take their feedback in creating a tutorial/color schematic key, and it will provide an easier usage.

[shankari]

@tyleryandt18

Maybe we should implement a tutorial walkthrough.

There is already one for the diary view. You should adapt it for the unified view.

Other interns also suggested that there be a color-scheme key whether that be with the blue scheme

Where would we put this?

A common theme that I have seen in all feedback forms is that there is no motivation to label trips, and it feels like a chore to do so.

Well, if you can figure out how to make that fun, I can pretty much guarantee you a publication.

AngularJS has a date selector/calendar library that supports notifications, it "can display events on a month, week or day view. It's called angular-calendar.

Can you add a link to it? The only one I could find was https://www.npmjs.com/package/angular-calendar which is for angular 12+. We are on angular1.

I also don't see any check on how calendar apps (which do care a lot about looking up dates) work.

Any results of the investigation into how calendar apps work?

You should send out the mockups for feedback from the current set of interns, and in parallel, we should plan out how to proceed with the code changes so we don't get too stuck on the UI.

[tyleryandt18]

There is already one for the diary view. You should adapt it for the unified view.

Other interns also suggested that there be a color-scheme key whether that be with the blue scheme

Where would we put this?

When I port the tutorial from the diary view into the unified view, perhaps I could add a color schematic into the tutorial. Just a thought.

A common theme that I have seen in all feedback forms is that there is no motivation to label trips, and it feels like a chore to do so.

Well, if you can figure out how to make that fun, I can pretty much guarantee you a publication.

The first idea that I had was that you could have "friends" on the app, pulling that idea from virtually any social media platform. But after thought, we probably couldn't share others travel data with others, if that makes sense.

AngularJS has a date selector/calendar library that supports notifications, it "can display events on a month, week or day view. It's called angular-calendar.

Can you add a link to it? The only one I could find was https://www.npmjs.com/package/angular-calendar which is for angular 12+. We are on angular1.

Yes, that is the one I was talking about. I will see if I can find one for angular1.

I also don't see any check on how calendar apps (which do care a lot about looking up dates) work.

https://github.com/angular-ui/ui-calendar https://angular-ui.github.io/ui-calendar/ I'm not sure if we could use this, it doesn't explicitly state whether it functions on Angular1.

StackOverflow pointed me in the direction of this library, where a user stated that they used it in their Angular1 project https://github.com/mattlewis92/angular-bootstrap-calendar.

Any results of the investigation into how calendar apps work?

I looked into the Angular1 library linked above. He has functions to create events for a day, week, month or year. And then in the html template, the functions are called so that you can see any events that you have in that specific period of time(year, day, week, month). I haven't ran the code yet, but I will do that tomorrow to look into the workings of the JS/html. You should send out the mockups for feedback from the current set of interns, and in parallel, we should plan out how to proceed with the code changes so we don't get too stuck on the UI.

I've sent out the mockups to all except I think Sebastian, Kacie, and Zach. But I will do that tomorrow morning as well.