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]

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.

That sounds OK - let's try that and see if we need anything else. I think that there is actually a tutorial in the label screen as well, I just disabled it because the intern who built it tried to make it really fancy and it didn't fully work by the time he left. https://github.com/e-mission/e-mission-phone/blob/master/www/js/diary/infinite_scroll_list.js#L434

Note that one of the problems is going to be that the walkthrough is useful when you have trips to show what all the components are, BUT when users install the app they have no trips so you can't show anything. You may want to think through an alternate high-level walkthrough as part of the onboarding that uses screenshots from our data/fake data first.

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.

This looks like a good option. However, I don't see anybody complaining about the existing calendar in the feedback so I would tag this as lower priority.

[shankari]

@tyleryandt18 let's start making progress on the hard-to-code parts that we know we will need to implement while waiting to hear back from interns, friends and family, focus group...

map created on the fly using subsample

We don't want to make the mistakes of the original diary and pull all the trajectory information at the same time and slow down the loading

• we keep the current approach to loading the map (which loads a subsampled version of the trajectory and can maybe even drop down the subsampling since the map is smaller) BUT
  • we do this to "fill in" the map, similar to filling in the address after the initial load of the trips

pre-created map

• another option that we have considered is to have the map created as an image on the server so we don't download the map tiles and the map trajectory separately. instead we create and save the map for a trip as an image on the server and then just pull the image when we need it
  • we can create these images for the last 10 days or something like that and keep rotating them and removing the older entries OR
  • we can just create the image when we process the trip and save it as a "thumbnail" for ever

In the pre-created map option, we would also retrieve the maps asynchronously and "fill in" the map information but filling it in would require less code on the phone because the browser can deal with asynchronous image loads

Map components

• Map tiles
• Trajectory plotted on the tiles

high level pro v con

• The advantage of the pulled from server approach is that we only need to pull the trajectory from the server, we can pull the map tiles from a map tile service and that can be cached in many edge locations close to the phone etc
• The advantage of the pre-created map is that we don't have to do the work of plotting the trajectory on the phone and can pull an image directly.

@tyleryandt18 will start implementing the first approach and see how bad it looks

[shankari]

@tyleryandt18 I just realized that we have to implement the "map created on the fly using subsample" approach anyway in order to support trips that have not yet been pushed to the server (green background aka draft trips).

Ask @sebastianbarry for examples if that is not clear, or look at the difference between diary and label screens right after (~ 5 mins after) you come back from a trip.

[shankari]

@tyleryandt18 Note that, as part of the unification, we also want to make sure that the label screen displays draft trips. That will require a fair amount of javascript refactoring, so let's focus on getting the maps inline for processed trips first and then start on the draft trip display.

[shankari]

@lgharib @PatGendre @asiripanich @jf87 since we are changing the visual representation of anyway while unifying the diary and label screens, we thought we might as well improve it. We were also inspired by the Ma Mobilite redesign which looks a lot cooler than the current UI.

@tyleryandt18 has created these mockups, please vote for which you like best!

Mockup 1	Mockup 2	Mockup 3

[asiripanich]

Why is this not an option?

[shankari]

Why is this not an option?

That is pretty close to Mockup #2, right? The main difference is the base color theme which is "NREL blue" 😄 for obvious reasons

[asiripanich]

Fair enough. However, I like that one better because of the position of the start and end times.

[shankari]

Noted. @tyleryandt18 made the mockups using Figma so they are a bit rough. @tyleryandt18 please note the strong vote for just switching to the Ma Mamobilite UI 😄

[PatGendre]

@shankari I agree with @asiripanich , the position of the start/times is clearer on the mockup2 variant :-) Also, it shows a date selector : I think in this issue you want to solve in a generic fashion both the current diary and label (infinite list) views so maybe this is why you don't show explicitly the date in your mockps, however in both cases the date should appear clearly somewhere nearby the trip, in my opinion.

[tyleryandt18]

@PatGendre @asiripanich @shankari Hello all, I'm working on the unification of NREL's diary and label screen. These mockups reflect a short period of time where I was considering removing the date selector feature altogether, but I can assure you that we will include it, after some thought it seems necessary. I was considering have a filter tab in which you could jump to a specific date from a calendar popup. The final design I'm envisioning will look something along the lines of:

And yes, as Shankari stated my Figma skills are still pretty elementary haha, that's why you can see some shadows here and there and the buttons aren't lined up perfectly.

So my thought process is that when you select the calendar filter, this popup will open and allow you to choose a specific date.

[shankari]

after some thought it seems necessary. I was considering have a filter tab in which you could jump to a specific date from a calendar popup. The final design I'm envisioning will look something along the lines of:

We might also consider having separators in the scroll - e.g.

Jul 10 trip
Jul 10 trip
Jul 10 trip
---- July 11 ----
Jul 11 trip
Jul 11 trip
Jul 11 trip

[shankari]

console.log("Before reading from timeline, $scope.trip = "+$scope.trip);
console.log("using trip id "+stateParams.tripId+" to read the trip");
$scope.trip = ...
console.log("after reading from timeline, $scope.trip = "+$scope.trip);

[shankari]

Issue #1: why is $scope.trip set to undefined in your code? It is defined in the multilabel-UI which logs in the same way.

• check the matching between your controller name in the directive and the .controller definition. Because before this, your controller didn't actually do much so you may not have noticed if it wasn't linked up correctly.

$scope.trip should be defined in your controller since it is passed in

Next, look up what $stateParams does and how it is used. HINT: as you can guess from the name, it has something to do with the parameters for a state. Look at how we go to the detail screen. What function do we use, and how might it be related to $stateParams?

[shankari]

to debug, check how the multi-label-ui works maybe try to pass in some other parameters and see if they work basically figure out why $scope.trip doesn't get passed through

[tyleryandt18]

@shankari The investigation into why $scope.trip won't get passed through into the infinite_scroll_trip directive:

• Before reading from timeline, the trip is (well should be in this case) an object because it is passed into the directive. When the trip is a string, for example, 'Tyler rocks', that is what the trip will be before reading from the timeline.
• After reading from the timeline, at least in the case here that I sent you over teams, the getConfirmedTrip function returns undefined, and therefore sets the trip to undefined. The function has a conditional, where it either returns the trip from the timeline, or it returns undefined. The conditional statement is checking whether the trip with that given tripid is defined in the timeline.

And since our trip is mysteriously not being received, when we call that function, it sets the trip to be undefined because the trip object that is being passed in does not have a tripId associated with it. So undefined tripId in the function returns undefined.

[tyleryandt18]

Oh and when we are retrieving the trip, or attempting to, with the $stateParams tripId, there is nothing there. I'm not sure I understand why this would ever work, even if our trip was being passed in correctly. Is it because $stateParams has access to the attributes of the trip?

[shankari]

Next, look up what $stateParams does and how it is used. HINT: as you can guess from the name, it has something to do with the parameters for a state. Look at how we go to the detail screen. What function do we use to go to the detail screen, and how might it be related to $stateParams?

[tyleryandt18]

While I'm doing that, could you touch briefly on if the code is using the detail.js file? I was looking into that file, and it goes about formatting its tripgj object ever so slightly, so I was going to see if pulling that code would work.

[shankari]

are you importing the module from detail.js? If not, we don't use anything from it.

[tyleryandt18]

I'm not importing the module, should I be?

I was just noticing that there is a different method of retrieving the tripgj in that js file. And I was going to try out this code. But, I guess if we aren't using detail.js anymore then the code might be outdated.

This screenshot is from detail.js.

[shankari]

@tyleryandt18 you are going down the wrong path. Please answer my questions in https://github.com/e-mission/e-mission-docs/issues/740#issuecomment-1192713073 that we also discussed at our 1:1 yesterday

[tyleryandt18]

Next, look up what $stateParams does and how it is used. HINT: as you can guess from the name, it has something to do with the parameters for a state. Look at how we go to the detail screen. What function do we use to go to the detail screen, and how might it be related to $stateParams?

$stateParams is a service that captures parameters and we can use it to display information according to the state. So when we go to a different state, the parameters would change. For example, the function that we use to go to the detail screen is a $state.go, and then it takes us to the different state and hence the different page. Within that function, we have a tripId: trip.id, so does that establish the tripId as a $stateParameter for that detail screen state? @shankari

[shankari]

@tyleryandt18 yes. so what is the equivalent for the directive? do we need to use the $stateParams?

[tyleryandt18]

@shankari I'm not sure what you mean by the "equivalent for the directive". But no, we would not need to use $stateParams.tripId for that function. We could just do $scope.trip.id to go and retrieve the confirmed trip. $scope.trip = Timeline.getConfirmedTrip($stateParams.tripId); --> $scope.trip = Timeline.getConfirmedTrip($scope.trip.id)

[shankari]

@tyleryandt18 Exactly, and I would go further: why do you need $scope.trip = Timeline.getConfirmedTrip($scope.trip.id) when you already have $scope.trip?

[tyleryandt18]

Why do you need $scope.trip = Timeline.getConfirmedTrip($scope.trip.id) when you already have $scope.trip?

Well now that is a great point. We wouldn't need it

[shankari]

Right. If you already have the trip, you just need to convert it to geojson to display it. Directly. Without lookup. So you just need to figure out why the $scope.trip is undefined in the controller and you are done.

I don't know why $scope.trip is not defined in the controller. It seems like it should be given that it is a parameter to the directive. You need to poke at it with different options - you have already tried passing in a string - what if you pass in a different object.... The answer is bound to be something very stupid, probably a typo or an incorrect format issue.

[tyleryandt18]

@shankari I just tried passing in a different object, and it was able to read it in fine. So it has specifically to do with the trip object, because when I set trip=a string, it was also able to read it in.

[shankari]

I know that showDetail worked for you earlier https://github.com/e-mission/e-mission-phone/pull/853/files#diff-338ab59c91e4724bfe144369b8f692359a4faa73acb869a0f6980ec6985c0cfdR32

if you try to console.log in there, is $scope.trip set?

[tyleryandt18]

It is only set after retrieving the trip with the tripid from $stateParams, but that makes sense

.

[shankari]

@tyleryandt18 we are not worried about the detail screen. we know it works. But when the user clicks on the ..., it calls the showDetail function in the directive. Inside that function, is $scope.trip defined?

[tyleryandt18]

@shankari Right, sorry about that. So here now I added a console.log within the function, so when it's called it'll log. Logging the trip from there produces this result, so it is defined.

.showDetail()...{ console.log("Testing if showDetail has the trip defined ", $scope.trip)

[tyleryandt18]

Also, to further prove that point, trip must be defined in order to see the map on the detail screen, which still works despite the map on the inf_scroll screen working. What I mean by this is that we pass the trip id into the $stateParams...

tripId: trip.id Within the showDetail function. Therefore, it must be defined if goes to the detail screen and displays the correct state. This is so weird.

[shankari]

well, arguably, tripId: trip.id uses trip not $scope.trip. But now I know what is going on and it is the async execution that I was talking about earlier. Async operation is key to understanding javascript operation.

To understand what is going on, look at the ordering of the console logs.

• when is the controller created?
• where do the trips come from and when are they populated?
• when is console.log in showDetails invoked?

After you do all that, read up about $apply and $watch, which are techniques that angular uses to handle async execution. HINT: $watch will be key to the fix.

[tyleryandt18]

well, arguably, tripId: trip.id uses trip not $scope.trip.

Could you explain this just slightly? I'm not sure what the difference of this would be, because that showDetail function is a $scope function, is it not? So then to access the trip it would be the trip in the scope, and therefore the same as $scope.trip?

[shankari]

because that showDetail function is a $scope function, is it not? So then to access the trip it would be the trip in the scope, and therefore the same as $scope.trip?

showDetail is a $scope function, but you also pass in trip as an argument to it. Inside the function, you currently use trip, which is the passed in argument.

To improve your directive implementation, you could remove that argument and change to tripId: $scope.trip.id

[tyleryandt18]

@shankari

When is the controller created?

So in the console logs, the infinite scroll controller is created before the trip item controller, the one for my directive. The Trip Item Ctrl is created fairly early on in the process.

Where do the trips come from and when are they populated?

Well the trips come from the server. https://github.com/e-mission/e-mission-phone/blob/c0395cf3bf981e45257debad82c9c56e87dc4361/www/js/diary/infinite_scroll_list.js#L87 They are populated in the lines following that code, and therefore after the the controllers are called, correct? In the console, the trip item ctrl is called before the list of trips begins to be populated.

When is console.log in showDetails() invoked?

The console.log in showDetails() is only invoked when I click on a button on the screen, so therefore after the controllers are called and the trip list is populated.

[shankari]

great! so what are some approaches for fixing it? My high level thoughts are:

• ng-repeat vs collection-repeat
• $watch

You could also look into event broadcast/listen although IMHO that is not as attractive as the others

Please try out the first two options and list the pros and cons

[tyleryandt18]

ng-repeat vs collection-repeat

I thought that we had to use collection-repeat in order for it to function on Android Devices?` <!-- This needs to be collection-repeat instead of ng-repeat on android. Otherwise, you can only scroll using the sidebar, scrolling on the map side does not work. I have no clue why this happens, but it is not worth it to understand this deeply. It is not purely a leaflet issue, but it also clearly something to do with leaflet because scrolling on the details part does work.

    If you want to change this from collection-repeat to ng-repeat, you
    MUST test on android first to make sure that the scrolling works.
    -->` 

At least this is if you're talking about the pros and cons of switching it in the inf_scroll list html file.

[shankari]

look at the blame for that line - I wrote it in 2015. So I would try and test it out on android and see if that still holds Maybe first try on iOS to see if it even works there and then try on android

EDIT: also (I know the answer) but why does it work on ng-repeat? What does the async timeline look like in that case?

[tyleryandt18]

@shankari I went ahead and switched the tripId: trip.id to tripId: $scope.trip.id, and the trip object is still defined when I log it to the console. Is there any significance to that?

[tyleryandt18]

@shankari I went ahead and switched the tripId: trip.id to tripId: $scope.trip.id, and the trip object is still defined when I log it to the console. Is there any significance to that?

Does this mean, in theory, if I just created a $scope function that changed the trip object to a tripgj, that the trip object would be read in correctly?

I'm going to get to the pros-cons list, I was just writing my write up so I'm just getting back on to this investigation.

[shankari]

I went ahead and switched the tripId: trip.id to tripId: $scope.trip.id, and the trip object is still defined when I log it to the console. Is there any significance to that? Does this mean, in theory, if I just created a $scope function that changed the trip object to a tripgj, that the trip object would be read in correctly?

What do you think? I can tell you the answers, but the questions indicate that you haven't fully internalized what the various variables are and how they are set. Try it out, figure out the answers and then figure out the "why" behind the answers. You will understand better once you actually see it in action.

[tyleryandt18]

@shankari Pros and Cons List ng-repeat vs collections repeat

• First off, I am not too sure how to run an android emulator. I've only been working on Xcode and the apple version. I probably could just go read the phone ReadME tho huh. Anyways, I think I would also have to install android studio through IT, so the ng-repeat test on Android might have to wait until Monday. But, I will try it out and make sure to update you on this thread.
• Wow ok I find this really interesting. The ng-repeat calls the Trip Item Controller after populating the list of trips. In the console, the order of logs goes Infinite Scroll Diary Ctrl called, list populating, THEN trip item ctrl called. As opposed to the collection-repeat has the trip item ctrl called before populating the list.
• YOOOOOOOOOOOO IT WORKED!!!!!!! wow that made me happy. I just uncommented the part that actually creates the map after using ng-repeat, and displayed the maps correctly.
• Downside tho, and I feel as if this would be an easy fix, within the collection repeat, there is the html tag for the start and end time buttons, so when we switch that to ng-repeat, there is only the start time tag for the very first trip, and the end time tag for the very last trip. We could easily just change up the directive html template to include these time tags there, and then we would be set.

[shankari]

@tyleryandt18 why don't you go ahead with fixing the easy fix for the downside then, and make the changes to have the directive look like the preferred mockup at the same time? Add screenshots once you are done.

Edit: The start and end time should really be inside the directive anyway. If it doesn't work on android, we can move on to $watch

[shankari]

@tyleryandt18 has now finished the UI directive changes and will add them to the PR pretty soon along with TODOs.

In terms of reading from the server, we currently read data in

Timeline.readAllConfirmedTrips(currEnd, ONE_WEEK).then((ctList) => {

and we append it to the current list

        $scope.data.allTrips = ctList.concat($scope.data.allTrips);

So the way that we load the data is:

• load first week (list has 10 elements)
• load week before (list has 20 elements)
• load week before that (list has 30 elements)

If we wanted to select an arbitrary date (say from a year ago) how should it work?

[shankari]

• when the user selects a date from a year ago, we just pass in that date to readAllConfirmedTrips

  Issue:

• what if they select a date that they don't have a trip for?
• make sure that if they select a date that they have already selected, we don't read it twice
• don't allow them to go to a date in the future
• what they go to a year ago and then try to scroll down? Right now we start at the end, and we append to the current list, so there is always data on the phone when we scroll down, until we get to the end. But if we jump to a year ago, then the data from the time between a year ago and now will not be retrieved to the phone. So we won't have it when the user scrolls down.

High level solutions for the issues:

• we will need to find the closest previous or next trip (find next trip before....), look up in infinite scroll. It is the method we use to figure out which is the last trip that the user has.
• we should be able to check against the list of trips that we have on the phone
• this should be fixable from the date picker directly so future dates are not selectable
• think of the current trip list as a buffer with a movable start. You need to change it to to a buffer with both a movable start and a movable end. You need to add the ability to load more data (aka gray button) at the bottom of the screen in addition to the top. So look up buffers in the internet and figure how how to keep track of both start and end.

[tyleryandt18]

• make sure that if they select a date that they have already selected, we don't read it twice
• what they go to a year ago and then try to scroll down? Right now we start at the end, and we append to the current list, so there is always data on the phone when we scroll down, until we get to the end. But if we jump to a year ago, then the data from the time between a year ago and now will not be retrieved to the phone. So we won't have it when the user scrolls down.

@shankari I feel as if these two issues/solutions are conflicting. When a user jumps to a date from a year ago, are we allowing them to scroll up and down? I don't believe so, so therefore when they select a date, it just displays that date's trips, correct? So then why are we not allowing them to click on a date that they have already selected? if they use the date selector to go from a year ago, then go to a date like yesterday, why could they not use the date selector to go back to that date in the past?

[tyleryandt18]

@shankari Furthermore, I don't know if I will be able to complete the date selector functionality. I really don't understand it, and I feel as if there might be a solution to the UI even better than the date selector that Sebastian could implement. If you don't believe that the trip draft function is working, then maybe I should focus on making sure that works along with the trip percentages, because I am also stumped on that implementation, but am confident I can work it out.