- no touch screens
- no embedded screen below the dash, instead screen is at instrument cluster height
- in center column, where your hand natural can rest, a palm-sized wheel:
- tactile feedback on rotation
- multi-directional shifts (cardinal & diagonal)
- pushing/clicking wheel is selection/confirmation
- finger tips buttons surround wheel with shortcuts:
- navigation (either CarPlay/Android Auto nav app or GPS)
- music (either radio or CarPlay/Android Auto currently playing music app)
- favorites (can be radio, satellite, etc.)
- home (one click -> CarPlay Home, double click CarPlay Dashboard with map & media)
- back
Here's a good video showing how it functions: https://www.youtube.com/watch?v=Q8ORngbdKI4 - https://www.wardsauto.com/interiors/why-mazda-blindfolding-its-engineers-and-designers
- https://www.mazda.com/en/innovation/technology/philosophy/human-centric/
PS: not a Mazda shareholder or rep, just a happy owner, take that bias as you wish
I've had to contend with Conventional Commits both in the OSS world and at work as it proliferated from what seemed to me like robotic adoption by folks who were even loosely associated with the Angular ecosystem (remember that?).
I've always had a stance with KAC that folks trying to automate changelog creation (prior to LLM rise, mind you) were focusing on the wrong thing. I still think there's a fundamental difference in focus between what you write in a git commit and what you present in a changelog.
I know there are fundamental philosophical differences for folks who were used to HISTORY vs. NEWS vs. CHANGELOG but with the growing adoption of KAC-like CHANGELOG.md files and Release Notes (often not synonymous) I think we're thankfully past the weird era were maintainers dumped raw git log ranges between two tags and called that a changelog. I'm sure some still do it. But that's what Conventional Commits tries to replicate.
What's really odd to me is that this assumes (broadly) that every single commit in a repository is relevant to the eventual version release changelog (or release notes). Even if you assume some CC types get filtered and deprioritized from generated changelogs by some tools, it's still a huge miss on what communicating about a release typically means: these change likely matter to you as a package dependent or direct user, while others were omitted for good reason.
I'm trying to articulate that much more clearly in KAC 2.0 because there's a fundamental paradigm shift when a robot can now analyze recent work (yours or theirs) and craft changelog entries that appropriately shift the audience perspective from "git message for me/us in the future to understand this change" to "changelog entry for you/them to know what this group of changes means".
[0]: https://keepachangelog.com
[1]: https://github.com/olivierlacan/keep-a-changelog/pull/600 if anyone's curious and wants to get involved