Application de bureau
Design d’application de boîte de réception de revue de code
Ce design d’application réunit demandes de revue, échecs CI, tickets assignés et activité dans un espace de travail lisible d’un coup d’œil pour le tri quotidien.
Cas d’usage de la boîte de réception de revue de code
- Tri des demandes de revueRetrouvez approbations, pull requests ouvertes et réponses en attente dans une seule file.
- Suivi des échecs CIFaites ressortir les vérifications en échec avec le contexte de commit nécessaire au suivi.
- Priorisation des ticketsParcourez le travail assigné avec dépôt, statut, étiquettes et activité récente.
- Revue de l’activité d’ingénierieGardez les changements fusionnés visibles sans les mélanger au travail urgent.
Points forts du design de la boîte de réception
- Priorité d’abordLes panneaux de revue jaunes placent en haut le travail qui vous attend.
- Preuve en contexteUn diff de code compact se trouve dans la demande de revue.
- Couleur selon l’étatVert, rouge, jaune et violet distinguent les états du workflow.
- Espace de travail uniqueDemandes, vérifications, tickets et activité partagent un même flux de lecture.
La boîte de réception de revue de code, panneau par panneau
1 / 2
Structure de la boîte de réception de revue de code
Ce design d’application desktop présente une boîte de réception GitHub des demandes de revue et des mentions comme un espace de travail ordonné verticalement. Un rail gauche commence par « All 5 », puis « Participating », « Mentions » et « Review requests 2 ». La colonne principale regroupe ensuite le travail en demandes de revue, vérifications CI, tickets assignés et activité. Cette séquence transforme plusieurs signaux d’ingénierie en un seul parcours de lecture, tandis que les catégories distinctes conservent assez de contexte pour décider ce qui demande d’abord de l’attention.
Une demande de revue comme preuve
Le premier élément de revue identifie la PR #2371 de open-design/web, nomme « feat: orbit briefing card » et affiche « 3 of 5 reviewers approved · waiting on you + cody ». En dessous, le chemin de fichier « src/components/OrbitBriefingCard.tsx » introduit un diff compact avec lignes supprimées et ajoutées. Cet appariement permet au relecteur de relier l’état d’approbation à un changement concret. Le compromis est la densité verticale : l’extrait de code apporte un contexte utile, mais rend le premier élément nettement plus haut que la seconde demande.
Cas d’usage du tri d’ingénierie
Le design prend en charge plusieurs tâches distinctes sans prétendre qu’elles relèvent du même type de travail. Les demandes de revue appellent une réponse ou une approbation, les vérifications CI signalent un état de vérification en échec, les tickets assignés représentent du backlog dont on est responsable, et l’activité consigne un changement terminé. Séparer ces groupes en panneaux rend la frontière entre tâches visible. Le compromis est que des signaux liés restent répartis sur la page au lieu d’être condensés en un score universel.
Revue en attente
L’en-tête jaune « Review requests waiting on you » affiche un compteur de 2. Sa première ligne est une pull request ouverte avec avatars de relecteurs et un état d’attente explicite ; la seconde indique « Conversation needs your reply » et identifie @cody. Les libellés distinguent le travail d’approbation du travail de conversation, même si les deux demandent une action.
Vérification en échec
Le panneau rouge « CI / Checks » contient un élément : open-design/web · main · « test (e2e) failed ». Le texte voisin du dernier commit, « chore(deps): bump cheerio to 1.0.2 », fournit un point de départ probable pour l’enquête sans affirmer pourquoi le test a échoué. L’accent rouge met l’état en évidence, mais n’explique pas comment le corriger.
Travail assigné et terminé
La ligne de ticket associe « Auth middleware refactor » au statut Open, à l’étiquette « backend » et à « p1 ». En dessous, la ligne d’activité montre la PR #2401 fusionnée dans main par bob. Cet ordre place la responsabilité non résolue au-dessus de l’historique terminé, même si la page demande encore au lecteur d’interpréter l’urgence d’après les étiquettes et l’état.
Flux de lecture de l’espace de travail
L’espace de travail utilise une large colonne principale et un rail de navigation compact plutôt que des tuiles de tableau de bord de taille égale. Le CSS livré fixe une largeur de page maximale de 1280px, et la mise en page visible donne aux panneaux d’événements l’essentiel de l’espace horizontal. Cette proportion accepte les longs noms de dépôts, titres de pull requests, horodatages et lignes de code sans forcer chaque élément dans une colonne de cartes distincte. Le coût est un long balayage vertical, surtout quand la demande de revue inclut son diff intégré.
Panneau de revue
Un en-tête jaune, un badge de compteur, des pastilles de statut ouvert, des avatars de relecteurs et un diff de code associent urgence et preuve.
Panneau CI
Un en-tête rouge et une ligne de vérification en échec isolent les problèmes de vérification du travail de revue et de responsabilité.
Panneau des tickets
Le statut et les étiquettes exposent, dans une courte ligne, l’état du workflow et la catégorie de l’élément assigné.
Panneau d’activité
Le style violet des éléments fusionnés identifie l’historique terminé sans concurrencer les éléments non résolus placés au-dessus.
Du filtre au détail
Le champ de recherche en haut affiche Type / to search, mais n’a aucun gestionnaire de recherche. Les filtres de la barre latérale fonctionnent sur les groupes locaux fournis : Participating affiche les demandes de revue et les tickets assignés, Review requests affiche le groupe de revue, et Mentions n’affiche que le groupe portant le marqueur de mention de la source. Ce marqueur est attaché aux tickets assignés plutôt qu’à la ligne de revue nécessitant une réponse. Le filtrage est un comportement de présentation local, et non une recherche GitHub connectée ni un service de boîte de réception.
Changements d’état par la couleur
La couleur porte l’état sur des lignes par ailleurs similaires. Le vert marque les états de dépôt ouverts ou apparemment sains, le jaune le travail en attente de réponse, le rouge le test en échec et le violet l’élément d’activité fusionné. Les étiquettes de tickets utilisent des pastilles bleue et rose distinctes pour « backend » et « p1 ». Cela accélère le balayage par rapport à la lecture de chaque phrase, mais la couleur reste complémentaire : chaque état est aussi écrit en texte, ce qui préserve le sens quand la couleur seule ne suffit pas.
Limites des fonctionnalités
La source implémente un filtrage local par catégorie et construit des liens GitHub sortants pour les lignes et les titres. Ces liens pointent vers un dépôt fixe à l’aide des identifiants d’exemple affichés ; leur existence ne vérifie ni les pull requests, ni les tickets, ni les résultats CI représentés. La recherche, la récupération authentifiée de la boîte de réception, l’état de revue persistant et l’exécution réelle des tests ne sont pas implémentés. Les noms, compteurs, horodatages, états d’approbation et extraits de code restent du contenu illustratif pour le scénario de design.
Comment créer un design d’application de boîte de réception de revue de code dans OpenDesign
Définir l’ordre de l’espace de travail
Créez un espace de travail desktop avec un rail gauche persistant pour « All », « Participating », « Mentions » et « Review requests », suivi d’une large colonne principale. Placez d’abord les demandes de revue, puis les vérifications CI, les tickets assignés et l’activité, afin que le travail non résolu précède l’historique.
Ajouter les états propres au cas
Utilisez des lignes d’exemple pour la PR #2371 et la PR #2389, une vérification « test (e2e) » en échec sur main, le ticket assigné ENG-148 et l’élément d’activité de la PR #2401 fusionnée. Conservez les libellés explicites tels que « waiting on you », « Conversation needs your reply », « backend » et « p1 ».
Invite suggéréeCrée un design d’application desktop de boîte de réception de revue de code avec un rail de filtres gauche persistant et un large espace de travail groupé. Affiche d’abord les demandes de revue, dont la PR #2371 avec un diff compact de OrbitBriefingCard.tsx et la PR #2389 avec un état de réponse attendue ; puis affiche CI / Checks avec un test (e2e) en échec, Issues assigned to you avec ENG-148, et Activity avec la PR #2401 fusionnée. Utilise uniquement des données locales illustratives et n’implique ni connexion GitHub réelle, ni backend, ni stockage, ni exécution réelle de tests.
Affiner le parcours de lecture
Vérifiez que l’accent jaune des revues, le traitement rouge des échecs CI, les états ouverts en vert et l’activité fusionnée en violet restent lisibles grâce aux libellés écrits. Gardez l’extrait de code subordonné à sa ligne de revue, conservez les longs noms de dépôts et de fichiers, et vérifiez que le regroupement vertical reste cohérent quand l’espace de travail se réduit.
Exporter et obtenir un lien de partage
Exportez votre design finalisé, puis utilisez Partager dans OpenDesign pour obtenir un lien de partage. Ouvrez le lien dans une fenêtre de navigateur distincte et vérifiez que la version souhaitée ainsi que ses ressources sont disponibles avant de l'envoyer.
Conception de wireframe de tableau de bord analytique
Un tableau de bord greybox OpenDesign cartographie un espace de travail analytique au moyen d’une barre latérale, de quatre emplacements KPI, d’un graphique schématique, de cinq lignes de tableau et d’annotations de mise en page bleues.
Application de bureau
Design de tableau de bord de performance des contenus
Un tableau de bord de contenus sombre relie les aperçus par plateforme à l’examen des graphiques, à la planification des brouillons et à une analyse approfondie des signaux d’audience et de conversion.
Application de bureau
Design de planificateur d'excursion à la journée
Planifiez six étapes minutées dans la ville fictive de Solara Bay, avec une carte illustrée, des estimations de marche et des avertissements utiles sur l'itinéraire.
Application de bureau
Design de présentation produit interactive
Explorez les couches séparées d’un téléphone conceptuel grâce à des vues prédéfinies, un curseur et un panneau de huit groupes d’assemblage.
Application de bureau