A driver checks a screen between mirrors, signs, traffic, and the road ahead. That changes the whole interface problem. A dense menu that works at a desk becomes a bad bargain when someone has to look away from driving to use it.
Put the next driving decision first. A turn cue should be obvious at a glance. Media controls can stay close by, but they should not cover the route or force a trip through nested screens. Keep important controls in stable places, use labels people can scan quickly, and never make color the only clue that something changed.
Day and night need different care. Sunlight washes out weak contrast; a bright white screen can feel harsh on a dark road. A dark palette helps, though it still needs readable type and clear focus. Motion should explain a change in state, not keep the screen busy while the car is moving.
Android Auto sets its own rules for app categories, templates, and interactions. Google’s Android for Cars guidance lays out the available templates and supported use cases. A real Vesprr prototype would have to start inside those rules. The current archive records Vesprr as a concept: navigation, music integration, and a retro-modern look. There is no released app or tested in-car build in this repository.
A useful first prototype is a small set of static screens: route guidance, an upcoming turn, and media controls that leave navigation visible. That is enough to judge hierarchy and visual character. It does not answer how the interface feels on a moving road; that takes platform-approved implementation and proper usability testing.