Audit UI/UX

theme/Type.kt est le gabarit d'Android Studio, mot pour mot

theme/Type.kt:1-36

val Typography = Typography(
    bodyLarge = TextStyle(/* … */)
    /* Other default text styles to override
    titleLarge = TextStyle(…),
    labelSmall = TextStyle(…)
    */
)

Quatorze des quinze rôles sont les valeurs par défaut de Material, et aucune famille de police n'est choisie. Critique pour cette application : il n'y a aucun rôle monospace ni à chiffres tabulaires. Un instrument qui affiche régime, km/h, Hz et dB en lecture continue a besoin de chiffres qui ne se décalent pas horizontalement quand les valeurs changent — or tous les affichages numériques sont en sans-serif à chiffres proportionnels, donc la ligne de KPI tremble à chaque mise à jour.

Correction — définir les quinze rôles ; ajouter un rôle NvhTypography.readout avec fontFeatureSettings = "tnum" pour chaque valeur de mesure ; envisager une famille condensée pour la barre inférieure afin que les libellés tiennent sans descendre à 10 sp.

Zéro icône ; des emojis en guise d'iconographie, dans des chaînes traduisibles

res/values/strings.xml (30+ sites) · WavPlayerBar.kt:98,111,118 · MainScreen.kt:1368,1425

<!-- strings.xml -->
<string name="gmpe_button">⚙️ GMPe</string>
<string name="export_frozen">📸 Exporter</string>
<string name="player_reading">📂 LECTURE : %1$s</string>
<string name="notice_with_close">%1$s   ✕</string>

// WavPlayerBar.kt
IconButton(onClick = …) { Text("⏪", fontSize = 14.sp) }

Six problèmes indépendamment disqualifiants :

1. Non thématisable. Les emojis sont rendus dans la police emoji système, à ses propres couleurs — color = NvhOnSurface sur Text("⏸") est ignoré. La palette soigneusement spécifiée de l'application s'arrête à l'icône.
2. Dépendant de l'appareil. Samsung, Pixel, Xiaomi et Huawei livrent des polices emoji différentes. ⚙️, 🚘 et 📸 diffèrent matériellement sur chacun ; certains diffèrent assez pour changer le sens perçu.
3. Mauvaises métriques. Les emojis portent leur propre ligne de base et leur propre avance — d'où le réglage de fontSize glyphe par glyphe, et leur décentrage visuel dans un IconButton de 48 dp.
4. Dans des ressources traduisibles. Un traducteur reçoit 📸 Exporter et peut réordonner, supprimer ou dupliquer le glyphe. Une icône n'est pas une langue.
5. ✕ comme affordance de fermeture vit à l'intérieur d'une chaîne formatée — ce n'est pas une cible tactile, pas 48 dp, pas étiqueté indépendamment.
6. Glyphes texte pour l'état — ●/▲/✕ dans GpsLedIndicator. L'intention est admirable et documentée (la forme comme second canal pour un opérateur daltonien) et doit être préservée — mais avec trois formes vectorielles, pas trois caractères en FontWeight.Black.

Correction — ajouter material-icons-extended, ou mieux pour un instrument, dessiner ~20 vecteurs pour que le jeu soit délibéré et propre en licence. Retirer chaque emoji de strings.xml. Chaque contentDescription existant est conservé tel quel.

Aucun Shapes() dans le thème ; huit rayons d'angle appliqués au cas par cas

theme/Theme.kt:44-50 (aucun argument shapes =) · 40 sites d'appel

Mesuré : 8.dp×15, 4.dp×8, 6.dp×7, 12.dp×4, 16.dp×3, plus un chacun de 3.dp, 10.dp, 14.dp. MaterialTheme utilise donc les formes par défaut pour ses propres composants, tandis que les surfaces construites à la main autour d'eux emploient 3 à 16 dp — une Card à 12 dp contenant une Surface à 4 dp dans un dialogue à 16 dp, à côté d'un Button au défaut de Material. Quatre rayons dans un seul groupe visuel.

Correction — passer un Shapes(extraSmall = 4.dp, small = 8.dp, medium = 12.dp, large = 16.dp, extraLarge = 28.dp) explicite, utiliser MaterialTheme.shapes.* partout, et laisser ci/checks.sh verrouiller les RoundedCornerShape( bruts hors du paquet theme — exactement le motif déjà éprouvé pour les couleurs.

Aucune échelle d'espacement ; 275 littéraux dp, et les petits provoquent le serrage

tout le dépôt

Deux problèmes distincts. D'abord, 1, 2, 3, 5, 6, 10 et 14 dp sont hors de toute grille de 4 dp, donc rien ne s'aligne sur rien et aucun rythme vertical ne s'établit.

Ensuite, et c'est plus visible : 58 emplois d'espacement de 1 à 2 dp — dont le contentPadding = PaddingValues(horizontal = 2.dp, …) de la barre inférieure sur cinq boutons — ne sont pas « denses », ils sont collés. Les interfaces professionnelles denses (Bloomberg, Ableton, Logic) emploient un rythme serré mais constant de 4/8 px avec un espacement interne généreux sur les contrôles. Cette application fait l'inverse : marges externes lâches, et des contrôles dont les libellés touchent leur propre bordure.

Correction — object NvhSpacing { val xs = 4.dp; val sm = 8.dp; val md = 12.dp; val lg = 16.dp; val xl = 24.dp }, plancher d'espacement interne à sm, et verrouillage des dp bruts hors du paquet theme.

La barre inférieure se dispute sa propre place

MainScreen.kt:237-518

Cinq contrôles se partagent la barre en Modifier.weight(1f) chacun, avec contentPadding = PaddingValues(horizontal = 2.dp, …), des libellés à 10–11 sp, maxLines = 1 et softWrap = false. Chacune de ces cinq décisions est le symptôme d'une même cause : les libellés sont trop longs pour la place, et plutôt que de les raccourcir ou de passer aux icônes, on a réduit la typographie et supprimé l'espacement jusqu'à ce que ça rentre sur l'appareil du développeur.

• weight(1f) donne à « Rapport Manuel » (15 caractères) la même largeur qu'à « Figer » (5) — l'un est tronqué pendant que l'autre a du mou.
• softWrap = false avec maxLines = 1 signifie une troncature brutale, pas une ellipse, dès que l'échelle de police dépasse 1,0. Le libellé devient un fragment.
• 2 dp de marge horizontale placent le texte à ~2 dp du bord du bouton — visuellement, le libellé est hors de son propre conteneur.
• La barre est la navigation principale et le sélecteur de mode de l'application, et c'est la surface la moins lisible de l'application.

Correction — avec quatre modes persistants plus une action de figeage, NavigationBar pour les modes et un FloatingActionButton pour figer/exporter est la réponse Android idiomatique, et elle libère toute la largeur de la barre.

L'état d'activation est communiqué en échangeant la couleur de conteneur d'un bouton plein

MainScreen.kt:250-256, 274-280, 337-343, 385-405

containerColor = if (kinematicsConfig.isEnabled) NvhActiveContainer else colorScheme.primary
containerColor = if (isReportModeActive)          NvhReportMode     else colorScheme.primary
containerColor = if (isFrozen)                    NvhRecording      else colorScheme.secondary

Un bouton plein bleu qui devient plein vert est un signal marche/arrêt faible : les deux états paraissent également « pressables », aucun ne paraît « engagé », et le sens doit être appris. L'application le sait en partie — gmpe_button_active ajoute le mot (Actif) — ce qui est le bon réflexe appliqué au mauvais widget.

Material 3 possède des contrôles faits pour cela, qui rendent la sélection sans ambiguïté par conteneur + contour + coche optionnelle. Et FilterChip est déjà employé correctement ailleurs dans ce même fichier (MainScreen.kt:1145-1160, le sélecteur de métrique) — l'application contient donc sa propre solution et ne l'applique pas à ses contrôles les plus importants.

Correction — SegmentedButton pour les modes de source exclusifs, FilterChip pour les bascules de fonctionnalité, IconToggleButton pour le figeage.

Deux idiomes de dialogue concurrents, et aucune bottom sheet

7 fichiers utilisent AlertDialog · 3 utilisent un Dialog { Card { … } } brut

Deux langages visuels pour le même travail — rayons, typographie de titre, placement des boutons et marges différents, choisis fichier par fichier. Et SettingsDialog (571 lignes, trois sections Card bordées, cinq Slider, un AddFilterDialog imbriqué) est un AlertDialog défilant : le conteneur le moins approprié de la plateforme pour une surface de réglages de cette taille, plafonné à ~60 % de la hauteur d'écran avec sa propre barre de défilement dans un dialogue dans un voile.

Correction — un seul wrapper NvhDialog pour les vraies confirmations ; déplacer SettingsDialog, KinematicsDialog et EmergenceReportDialog vers ModalBottomSheet (poignée, expansion pleine hauteur, conscient de l'edge-to-edge) ou vers un véritable écran de réglages.

Le mouvement est absent, et son absence se lit

6 appels d'animation : animateFloat×3 (pulsation canvas) · animateColorAsState×3 (ReportModeScreen)

Rien d'autre ne bouge. Aucune transition ne couvre :

• L'entrée et la sortie du mode rapport — un remplacement plein écran à MainScreen.kt:196-199 qui coupe net.
• L'apparition du menu de source audio ; l'apparition du bouton Exporter au figeage.
• L'apparition de WavPlayerBar au chargement d'un fichier — il surgit dans la mise en page et pousse la carte de télémétrie vers le bas.
• Les changements de couleur de mode sur la barre inférieure.

Correction — AnimatedContent sur le basculement de mode rapport ; AnimatedVisibility avec expandVertically sur le lecteur et le bouton Exporter ; animateColorAsState sur chaque couleur de conteneur dépendant du mode. Budget 150–250 ms. C'est le meilleur rendement visuel par ligne de code de tout l'audit.

La réactivité tient à un seul test de ratio d'aspect ; aucun WindowSizeClass

MainScreen.kt:1206-1223

BoxWithConstraints(…) {
    if (maxWidth > maxHeight) { Row { spectrogramPane(…); vehicleDataPane(…) } }
    else                    { Column { spectrogramPane(…); vehicleDataPane(…) } }
}

Le motif « deux panneaux déclarés une seule fois » est réellement bon, et le commentaire documente un vrai bug qu'il a corrigé. Mais le ratio d'aspect est le mauvais axe. Une tablette de 10 pouces en portrait fait 800×1280 dp — maxWidth < maxHeight, donc elle reçoit l'empilement téléphone, dans une fenêtre assez large pour trois panneaux. Un grand pliable déplié subit la même chose. À l'inverse, un petit téléphone en paysage (640×360) reçoit la division côte à côte avec un spectrogramme de 352 dp de large.

Correction — material3-window-size-class n'est pas une dépendance actuellement. L'ajouter et brancher sur WindowWidthSizeClass : Compact → empilement, Medium → division, Expanded → division avec un panneau de réglages visible en permanence au lieu d'un dialogue. Conserver le test d'aspect seulement comme critère de départage.

Des poids imbriqués morts rendent les proportions du panneau de données fictives

MainScreen.kt:884-925, 913-916

Column(modifier = paneModifier) {
    if (…) { WavPlayerBar(…) }                  // sans poids, hauteur intrinsèque
    Card(modifier = Modifier.weight(0.45f) …)   // le SEUL enfant pondéré
}

weight(0.45f) sur l'unique enfant pondéré d'une Column lui distribue tout l'espace restant — le 0.45f n'a aucun effet. La même constante morte figure sur VideoPlayerView. La prochaine personne qui règlera cette mise en page croira raisonnablement que la carte prend 45 % du panneau et que 55 % vont ailleurs ; cet ailleurs n'existe pas.

Pendant ce temps, le comportement réel — WavPlayerBar prenant sa hauteur intrinsèque en haut et la carte absorbant le reste — fait que charger un WAV rétrécit silencieusement le graphique de télémétrie de toute la hauteur du lecteur, sans transition (UX-M8).

Correction — supprimer les poids sans effet (fillMaxSize() exprime le comportement réel), ou introduire le second enfant pondéré que les constantes sous-entendent.

themes.xml configure les barres système via des API que targetSdk 36 ignore

res/values/themes.xml:19-21 · MainActivity.kt:22

<item name="android:statusBarColor">@color/nvh_primary_container</item>
<item name="android:navigationBarColor">@color/nvh_background</item>

Ces deux attributs sont dépréciés et ignorés depuis l'API 35, et l'application est en targetSdk = 36 avec enableEdgeToEdge(). Les deux entrées sont de la configuration morte. L'edge-to-edge est donc actif avec une apparence de barres système non gérée, et aucune gestion de WindowInsets n'existe dans l'application au-delà de ce que Scaffold, TopAppBar et BottomAppBar appliquent par défaut. (windowSplashScreenBackground juste au-dessus reste correct et fonctionne.)

Les défauts de Material 3 dégagent probablement le contenu des barres, mais rien ne le vérifie, l'application n'exprime jamais d'intention sur le contraste des icônes de barre d'état, et les Popup de UX-B1 sont entièrement hors du périmètre d'insets de Scaffold.

Correction — supprimer les entrées mortes, piloter l'apparence des icônes via WindowInsetsControllerCompat.isAppearanceLightStatusBars, et ajouter une vérification d'insets aux tests UI (actuellement absents).