aesculus / evto-app-feedback Goto Github PK

Suggestion:

• Trips are listed in compact list form with Name/Date in the title bar (where date is the last time the trip was revised)
• Sorting options are By Name, or By Date.
• Touching a right-facing disclosure triangle at the left of the trip title bar expands the compact form to show the full detail of the trip, as you currently do, replacing the right-facing triangle with downward facing triangle to collapse the detail.
• Swiping left on a trip name title bar shows the Delete button, swiping right cancels.
• Touching the title bar makes that the active trip.

Variable and not reliably duplicative

Right now each user fetches weather on their own for each trip. Could save calls to weather service if weather requests were cached on DAG server for use by all users.

Would have to expire the forecasts on the server after time (6 hours?).

(From TMC app thread, requested by user BerTX)

Add a control to indicate user's preference to drive at some lower speed. This could be expressed as a max preferred speed (e.g. 55) or a percentage of speed limit (e.g. 80%)

I will help with this.

Change the calendar so it uses the ID rather than sticking in the ID in the title.

Right now limited by what the calendar plugin can do. While it would work in iOS, it won't work in Android.

Proposed Pro Feature. See google maps. Arrive by / Depart at

Must do this in trip order.

1. Load trip [5bbafwn92acf41d2txxvxn], PIN[1234]
2. Select the second (return) segment Burlington - Seattle with multiple stops
3. Display Trip Summary or Trip Details, note that addresses are shown instead of friendly waypoint names.

Note that the waypoints were added by dropping pins on the map to force a particular routing, and that they were not added by searching Google by name or address. This may be a factor.

Reconstruct this panel to be expanding/collapsing details on an individual waypoint. The list initially presents as the route’s waypoints, with their pin icons friendly names and battery, as you have now. I’ll call this the waypoint title bar. Touching waypoint title bar expands the view so that the waypoint title bar is at the top of the display, and the bottom 80% is either the deep data view, or the map. Use a tabbed interface to switch between data and waypoint's map location. It would be important that the phone-scale rendering be sensible in portrait mode, so there may be some finicky layout constraints for the deep data view, but I think it could be done.

Touching the title bar again collapses the deep view of the waypoint, and allows you to scroll the list to select a different waypoint.

When viewing a route with waypoints, a long press on a pin (Origin, waypoint or Destination) enables the pin to be dragged to a new location.

When the app is first installed, certain dialogs should be presented before the user sees the main panel:

1. My Cars dialog with a useful set of defaults. Even if the user accepts the defaults, they will be aware that this customization dialog exists.
2. Settings dialog to ensure they'll see the appropriate supercharger database for their location

After completing this sequence, the Main panel is displayed with two buttons, New Trip and Getting Started. Experienced users may skip Getting Started and go directly to planning a trip. If they bypass the introductory Getting Started screens, the appropriate flag is set to indicate that those screens have been viewed.

After this initialization, visits to the Main panel show two buttons, New Trip and Resume Trip. If there is no active trip, Resume Trip is grayed out.

This feature request supersedes issue #25.

iOS issue. Right now it shows cryptic stuff. Not sure what version of iOS Ask is supported on. V10 has Never and Allow.

Consider having Settings and My Cars changes apply to the current trip, or at least prompt the user if they want it that way.

Minimum SOC is saved in trips (min_wp_soc) but any waypoint created uses settings. Auto chargers always use settings which means they can differ. - maybe update current trip with new settings and My Car attributes as a prompt?

Not sure if this is a problem or not. More testing in non NA countries might be needed to determine if this is an issue or not.

Using the recorded address of the charger, invoke street view directly without the 'drag icon to map' approach.

A few users report that the app over estimates energy consumption by 10-20% even when Power Factor at it's lowest setting.

Need more data and to see if it is specific to a certain configuration/model.

Most users have to increase the PF above 0 to represent their reality.

Still looking for a more solid way to confirm destinations on location edits for Android. Sometimes needs two selects.

Even when all settings are correct at least one user reported the location was not picked up on their device. User was in AU. Not sure if WiFi or Cellular at the time.

When the app is first installed, the buttons should be 'Getting Started' and 'New Trip'.

Once user clicks either button, the 'User has seen Getting Started' flag should be set, and that button should no longer be shown.

Afterwards, the buttons should be 'New Trip' and 'Resume Trip'.

I find the ‘Minimum SOC (%)’ label ambiguous. Is it the SOC at arrival? Departure? Why is it minimal? Under what circumstances would the minimum not be met?

I think changing the label for the slider would help remove some of that ambiguity.

A couple of possible alternatives for en-route waypoints:
Minimum Departure SOC
Minimum SOC at Departure
Departure SOC
Preferred Departure SOC

When destination info is displayed, maybe 'Arrival SOC'.

When a segment terminates at a destination charger, the subsequent outbound trip should assume that I recharged using the destination charger. However, that SOC should be editable, since I may not have been able to recharge to my standard departure SOC.

Currently, reusing an existing Favorite in a new trip loses the assigned charger info. This attribute should be persistent and editable in the Maintain Favorites panel.

I think the intent is “I expect to spend at least x minutes at this Waypoint while charging, even if that’s more than needed to reach my desired SOC.”

So maybe it would be adequate to simply say ‘Stop Time (mins)’ or 'Planned stop time (mins)'?

Not fully validated yet.

Works OK if the destination address is changed.

Some superchargers don't have a province. Need to insure waypoint closest chargers uses address if all pieces are there or lat/lng if not.

This is because of a choice by Tesla when cataloging superchargers. Too much trouble to fix for the app.

Can cause problems for routing or at least not the ideal routing since lat/lng seems to not be as accurate in Google as addresses are.

This is partially fixed but will need extensive testing to ensure it's ideal.

This is causing a problem for optimization outside of NA. Some charger neighbors are non charging sites and the optimization is sending routes to those locations, breaking the routing.

Without this fix app cannot be deployed in non NA markets.

OK on Trip Details

Fix has been applied but not fully tested yet. Still may be an issue.

I have no friggin' idea how that's done, but it would be a well-received feature.

Suggestions:

• Rename menu item, dialog title to Filter Chargers
• In the dialog, remove the 'Chargers:' label
• Change the menu icon from funnel to the outlet icon used on the map
• Add outlet icon to the dialog title bar prefixing the title.

Set some of the features when the user selects different car type, like battery size and drive options in Model X.

This is partially implemented but not extensively. The app does check the validity before saving though.

Can be either remaining energy from prior segment or recharge at new origin. Confusing to the user and not consistent.

For a given route listed in a Trip Summary panel, user should be able to drag any origin, waypoint or destination pin to any new location within the list. That means a waypoint may become an origin or a destination.

Upon reordering, a popup would ask whether user wants the trip optimized (waypoints scrambled to minimize travel distance) or simply recalculated using existing waypoint order. For example, swapping Origin and Destination, then clicking 'Optimize' would reverse the route.

1. Drag and drop waypoint reordering in Trip Summary (issue #36)
2. Ability to add car-specific, user-supplied images as background for main panel (issue #2)
3. Redesign Maintain Favorites dialog to allow editing of waypoint details. (issue #28)
4. Add Open in Google Maps for local device, car browser (issue #39, #40)

Two options for Time field:

1. Long press resets to current time without opening time-setting popup
2. Change 'Clear' button to 'Now'.

Power Factor: is this a percentage multiplier? Should it be?
Editing this number is very finicky. How about a popup spinner that ranges from -50% to +50%, or something similar?

Only reported by one user. Cannot duplicate.

iOS has a system-level feature allowing one app to call another with arguments. By constructing a special URL, the app can invoke Google Maps with the currently loaded route, with multiple waypoints, allowing realtime navigation.

See Google documentation at https://developers.google.com/maps/documentation/ios-sdk/urlscheme
Sample code in both Objective C and Swift is provided.

Updated RR with EPA numbers from website

https://www.fueleconomy.gov/feg/findacar.shtml

Limited on real-estate so it has been purposefully left off. Probably need to re-evaluate?

For example, if they've specified a Model X 90D, construct 'My Model X 90D' rather than just 'My Car'. Folks initializing with multiple cars will appreciate that. Also, when naming a car, you need to check that it's not duplicating an existing car name.

To support Roadsters you could remove all SC and only use HPWC or maybe get a set of NREL Tesla chargers on route or stash them into another file?

Not sure what else besides car details would be needed to support Tesla Roadsters.