Test report : my weekend

[laem]

This test report is based on my last weekend, which is particulary interesting as I took the metro, the TGV (high speed train), walked, took the car, took the bus, skied the latter being I guess quite interesting.

@PatGendre @shankari

UI

• the home page is not very interesting : the CO2 footprint, without any contexte (e.g. climate objectives, evolution) is very abstract and not actionable. The mode-distance table is quite interesting, and could be in my opinion the only thing on this screen
• the calendar view is very interesting, but I see way too many things. E.g. the button top-left takes the most important place but does nothing.
• the calendar view is to me the most interesting this, better than the "dashboard", but it should be a scroll rather than tabs. In a scroll view, the empty days (which appear like bugs) would be just one empty line, and important content would be put forth.
• the day of the week should be displayed instead of "31 january 2021", I'd prefer to see "sunday 31 january 2021" or even "last sunday"
• the map is more interesting than the addresses in my opinion, in particular because they do not include the city, just the number and street name
• there's a permanent notification that is quite annoying and its text not user friendly : In state local.state.waiting_for_trip_start
• the tutorial button "?" is bugged, it covers the right > arrow.

E.g. taking the car from Autrans (french alps) to Lyon (big french city), the app displays "Avenue Léopold Fabre to [street in Lyon]", but not "Autrans to Lyon" 😅

Quality of tracing and mode recognition

It's mostly good ! Most trips were recognized correctly, both in terms of segments and in termes of modes...

Except :

• the ski was a mix of car-bike-walk. This is not surprising, except for the car segments, which are completely improbable, as they do not map to existing roads
• biggest problem : the high speed train from Paris to Lyon was recognized as a plane trip. This is quite embarassing, as this is a confusion between the most harmful mode for the climate (planes) and the least (TGV, french carbon free electricity and most energy efficient transport) 😅 . The train goes at 300-320km/h, so I wonder how this could be classified as a plane trip, as far as I know planes go way faster

Battery

Battery usage is a mixed bag. On not-very-active days (< 1h walking or cycling, working in a flat the rest of the time), battery usage is ~5% (I didn't open the app, it was just running in the background when needed), which is quite sober.

Interesting : RocketChat used 3% though I only used it 5 minutes, which is quite a problem for this kind of popular app.

On my most active day where I skied 4 hours and travelled by car 2h and took the train for 2 other hours, battery consumption peaked at 16%. The day before, with only 2-4 hours of "regular transport" (train, car, walking not skiing 4 hours), it took 8%.

As a user, this is quite OK, I'll keep using it... but my phone is in good shape (top spec phone bought 2 years ago). With an already feable battery, 10-20% could be a reason to remove the app.

[laem]

PS : trace proof 😄

[shankari]

@laem #2 (comment)
wish I was there!

[shankari]

I will address some of the non-UX comments since there are multiple possible UIs by design, and the spacing, etc also depends on the text. I built e-mission with a customizable UI just so I would not have to argue about maps v/s no maps etc for the display.

the home page is not very interesting : the CO2 footprint, without any contexte (e.g. climate objectives, evolution) is very abstract and not actionable. The mode-distance table is quite interesting, and could be in my opinion the only thing on this screen

The CO2 footprint is expandable and on expansion, does have more information. I leave it to FabMob to decide how they want to display/highlight it.

the calendar view is to me the most interesting this, better than the "dashboard", but it should be a scroll rather than tabs. In a scroll view, the empty days (which appear like bugs) would be just one empty line, and important content would be put forth.

There is a scroll view that I have not merged to master (e-mission/e-mission-docs#226 (comment)). It will not have maps by default because retrieving map data is part of the reason for the slow performance of the current diary screen. It does have maps when you click on the entry. e-mission/e-mission-docs#226 (comment)

there's a permanent notification that is quite annoying and its text not user friendly : In state local.state.waiting_for_trip_start

The permanent notification is required for a foreground service, which is currently required to perform many background operations on android. Without a foreground service, many bad things happen for continuous tracking (https://github.com/e-mission/e-mission-docs/search?q=foreground+service&type=issues). Since we don't need to hide our tracking, I have not invested in the significant effort to remove it, and test it on all possible android versions to ensure that there is no data loss.

The text is translatable, although I am not sure @PatGendre has caught up with all the french translations yet.

the ski was a mix of car-bike-walk. This is not surprising, except for the car segments, which are completely improbable, as they do not map to existing roads

We don't actually do map matching at this point. If there is a motorized mode which doesn't map to transit locations at the start and end points, we mark it as CAR. You must have been going really fast for the section to be marked as motorized!

biggest problem : the high speed train from Paris to Lyon was recognized as a plain trip. This is quite embarassing, as this is a confusion between the most harmful mode for the climate (plains) and the least (TGV, french carbon free electricity and most energy efficient transport) 😅 . The train goes at 300-320km/h, so I wonder how this could be classified as a plane trip, as far as I know planes go way faster

The server actually marks it as AIR_OR_HSR as you can see from the dashboard. We could try to distinguish further between planes and HSR. One problem with using only speed for the distinction is that the start time and end time of a plane trip are not very clearly defined when the phones have to go into airplane mode. So if you are sitting waiting for the plane to depart for a while, then the overall speed becomes much lower.

(e-mission/e-mission-docs#206 (comment)) has some plane trips:

• 1626 km in 3 hours = 526 kmph
• 2618 km in 8 hours = 327 kmph
• 3799 km in 6 hours = 633 kmph
• 3357 km in 3 hours = 1199 kmph

I think a better option is to use OSM since the airport location will be very different from the HSR location. @PatGendre do you want to tackle this? The CanBikeCO program will have few air trips, so I probably won't tweak this further.

On my most active day where I skied 4 hours and travelled by car 2h and took the train for 2 other hours, battery consumption peaked at 16%. The day before, with only 2-4 hours of "regular transport" (train, car, walking not skiing 4 hours), it took 8%.

This is a known issue and one I have highlighted for a long time. Adaptive sensing was a "call for help" back in the e-mission TRB paper. Alas, nobody has answered the call, and I have not had time of my own to prioritize it either.

[PatGendre]

Hi, thanks @laem for the tests and @shankari for the reply !

I am not sure @PatGendre has caught up with all the french translations yet

Correct, we have not fixed the translations yet, End of February I guess

I think a better option is to use OSM since the airport location will be very different from the HSR location. @PatGendre do you want to tackle this?

I'd be glad but I wonder if la Rochelle would include a budget for improving the pipeline... for the moment I have to work on not so interesting consulting tasks but this is my current job:-(
In principle I suppose it would be in the clean and resample step and of course in the GIS branch inference rule engine step.
I would raise the air plane mode threshold to say 400kmph and include HSR/TGV as a standard TRAIN mode, as first approach.
(last week I flew to Corsica, 380km in 1 hour, so the threshold may rather be 350kpmh).

Airport are located in OSM but as complex areas rather than points, and air routes are not described, so the the AIR mode would work very differently as the RAIL mode, whereas HSR seems mostly similar as any other TRAIN.
Also, I note that the overpass transit stops requests look 1km around : the distance could safely be lowered to 100m in most areas (with a possible larger request if nothing is found). There is room for optimisation there.

[laem]

Thanks for your answers ! Very intestersting to read the details :)

Maybe some of these questions would be useful for the user (or testing user) in a FAQ ?

E.g.

### One of my trips was categorized as a car trip, but I was [cycling/skiing/etc.] 

> We don't actually do map matching at this point. If there is a motorized mode which doesn't map to transit locations at the start and end points, we mark it as CAR. You must have been going really fast for the section to be marked as motorized!

[PatGendre]

Hi @laem
I wrote a small evaluation (in French) of our 2019 e-mission tests, several enhancement are identified. It could be used for a FAQ.

[shankari]

@PatGendre @laem e-mission has changed a bit since then, is the report still valid?

[PatGendre]

@shankari the report is mostly valid I guess, as far as the server side is concerned. But you're right it could updated and published in a wiki or a FAQ and/or translated to English. Maybe in March...

[shankari]

@PatGendre @laem I just merged the new infinite scroll screen to master. Try it out and if you need any fixes, you can contribute them back as well.

[PatGendre]

@shankari thanks a lot :-))
I am not sure we will test it rapidly because of current contract issues but we will test it for sure and give you a feedback. @iciatech-yprime