aesculus / evto-app-feedback Goto Github PK
View Code? Open in Web Editor NEWA project to track bugs and ideas for the EVTO App
License: MIT License
A project to track bugs and ideas for the EVTO App
License: MIT License
Suggestion:
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.
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:
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:
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.
Two options for Time field:
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
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.