I’ve been meaning to give the trippler UI a glow up for MY2025 and my PyCon AU selection finally provided the impetus.
In previously envisioning migrating to a Javascript front-end (vibe coded?), I was possibly making the next step bigger than it needed to be, as I’ve managed to squeeze a bit more out of the Streamlit stack, for now.
My main objectives for a more polished UI were:
- Better signal the purpose of the app from the first impression
- Make the grab-bag of “advanced” trip planning parameters clearer
- Give consistent treatment of non-happy-path scenarios
This post doesn’t contain any groundbreaking UI design insights, just a brief reflection on coming back to an old interface with fresh eyes.
New directions
Key to a clear design is clarity on the overall information flow:
- Define route
- Select chargers
- Plan charging stops
Define route
Previously, I wasn’t showing a map until the route had been determined. This meant some “ready for adventure…” text was doing the heavy lifting of signalling intent. The first major change was to add a preliminary map widget for signalling on landing, and for feedback during route definition.
The preliminary map starts with Australia then shows validated locations until the whole route is validated, at which point we switch over to the standard map. This also required some refactoring of the logic around validating start and end places, which is now much clearer.
As an aside, the very first time I decided to present an error message to trippler users I chose the cactus emoji, as it suggests adventure and it’s also Aussie slang for something that’s broken. This is one feature I’ve preserved for its character.
Select chargers
Note that the select chargers step is automagical by default, unless the user expands the dialog to edit configuration options. I left this largely untouched but added a network exclusion option for Tesla-only chargers, as I think this is useful for owners of other EVs.
Plan charging stops
The charge plan previously had a big range slider and just two resilience options, in addition to many “advanced” parameters, which were hidden by default, but confusing when presented. In removing “advanced” parameters I divided them between:
- vehicle parameters
- resilience parameters
- solver parameters
I introduced a clearer group for vehicle parameters. I migrated the “advanced” resilience parameters to what is now a richer set of resilience options. The solver parameter I simply removed and set to reasonable defaults to reduce user complexity. The range slider remains!
Non-happy-paths
Most of the true errors happen early due to open input; places that can’t be located in Australia or routes that can’t be connected. In contrast, when it comes to adjusting charge plan parameters, a failed plan is a legitimate outcome of an over-constrained scenario, one which the user may be trying to uncover in testing the limits of resilience.
In these cases I decide a warning of possible causes and informative resolution suggestions were the appropriate response. I’ve moved from always using st.write to consistent use of st.error, st.warning and st.info in presentation.
Success (st.success) is not marked explicitly, as it’s implicit on the happy path to EV adventure, but if it were, it would be accompanied by an green apple emoji – she’ll be apples, mate!