Aplicación de escritorio
Diseño de aplicación de bandeja de entrada para revisiones de código
El diseño de aplicación de bandeja de entrada para revisiones de código reúne solicitudes de revisión, fallos de CI, incidencias asignadas y actividad en un espacio de trabajo fácil de revisar para la priorización diaria.
Casos de uso de una bandeja de entrada para revisiones de código
- Priorización de solicitudes de revisiónEncuentra aprobaciones, solicitudes de incorporación de cambios abiertas y respuestas pendientes en una sola cola.
- Supervisión de fallos de CIMuestra las comprobaciones fallidas junto al contexto del commit necesario para continuar la investigación.
- Priorización de incidenciasEscanea el trabajo asignado con repositorio, estado, etiquetas y actividad reciente.
- Revisión de la actividad de ingenieríaMantén visibles los cambios fusionados sin mezclarlos con el trabajo urgente.
Aspectos destacados del diseño de la bandeja de entrada de revisiones
- La prioridad, primeroLos paneles amarillos de revisión colocan arriba el trabajo que está esperando tu intervención.
- Evidencia en contextoUna diferencia de código compacta aparece dentro de su solicitud de revisión.
- Color basado en el estadoEl verde, el rojo, el amarillo y el morado distinguen los estados del flujo de trabajo.
- Un único espacio de trabajoLas solicitudes, comprobaciones, incidencias y la actividad comparten un mismo flujo de lectura.
La bandeja de entrada de revisiones, panel por panel
1 / 2Estructura de la bandeja de entrada de revisiones de código
Este diseño de aplicación de escritorio presenta una bandeja de entrada de solicitudes de revisión y menciones de GitHub como un espacio de trabajo ordenado verticalmente. Una barra lateral izquierda comienza con “All 5”, seguida de “Participating”, “Mentions” y “Review requests 2”. La columna principal agrupa después el trabajo en solicitudes de revisión, comprobaciones de CI, incidencias asignadas y actividad. Esta secuencia convierte varias señales de ingeniería en una única ruta de escaneo, mientras que las categorías separadas conservan suficiente contexto para decidir qué requiere atención primero.

Una solicitud de revisión como evidencia
El primer elemento de revisión identifica open-design/web PR #2371, nombra “feat: orbit briefing card” y muestra “3 of 5 reviewers approved · waiting on you + cody”. Debajo, la ruta de archivo “src/components/OrbitBriefingCard.tsx” introduce una diferencia compacta con líneas eliminadas y añadidas. Esta combinación permite al revisor conectar el estado de aprobación con un cambio concreto. La contrapartida es la densidad vertical: el fragmento de código aporta contexto útil, pero hace que el primer elemento sea considerablemente más alto que la segunda solicitud.
Casos de uso para la priorización de ingeniería
El diseño permite realizar varias tareas distintas sin fingir que son el mismo tipo de trabajo. Las solicitudes de revisión piden una respuesta o aprobación, las comprobaciones de CI señalan un estado de verificación fallido, las incidencias asignadas representan trabajo pendiente asumido y la actividad registra un cambio completado. Mantener estos grupos como paneles separados hace visible el límite entre tareas. La contrapartida es que las señales relacionadas permanecen distribuidas por la página en lugar de condensarse en una única puntuación universal.
Revisión pendiente
El encabezado amarillo “Review requests waiting on you” muestra un recuento de 2. Su primera fila es una solicitud de incorporación de cambios abierta con avatares de revisores y un estado explícito de espera, mientras que la segunda fila indica “Conversation needs your reply” e identifica a @cody. Las etiquetas distinguen el trabajo de aprobación del trabajo de conversación, aunque ambos requieren una acción.
Verificación fallida
El panel rojo “CI / Checks” contiene un elemento: open-design/web · main · “test (e2e) failed”. El texto cercano del último commit, “chore(deps): bump cheerio to 1.0.2”, proporciona un posible punto de partida para la investigación sin afirmar por qué falló la prueba. El énfasis rojo hace que el estado destaque, pero no explica cómo remediarlo.
Trabajo asumido y completado
La fila de la incidencia combina “Auth middleware refactor” con el estado Open, la etiqueta “backend” y “p1”. Debajo, la fila de actividad muestra la PR #2401 fusionada en main por bob. Este orden mantiene la responsabilidad no resuelta por encima del historial completado, aunque la página sigue requiriendo que el lector interprete la urgencia a partir de las etiquetas y el estado.
Flujo de lectura del espacio de trabajo
El espacio de trabajo utiliza una columna principal amplia y una barra de navegación compacta, en lugar de mosaicos de panel de igual tamaño. El CSS entregado establece un ancho máximo de página de 1280px, y el diseño visible concede a los paneles de eventos la mayor parte del espacio horizontal. Esta proporción admite nombres largos de repositorios, títulos de solicitudes de incorporación de cambios, marcas de tiempo y líneas de código sin obligar a colocar cada elemento en una columna de tarjetas independiente. El coste es un escaneo vertical largo, especialmente cuando la solicitud de revisión incluye su diferencia integrada.
Panel de revisión
Un encabezado amarillo, una insignia de recuento, etiquetas redondeadas de estado abierto, avatares de revisores y una diferencia de código combinan urgencia y evidencia.
Panel de CI
Un encabezado rojo y una fila de comprobación fallida aíslan los problemas de verificación del trabajo de revisión y asignación.
Panel de incidencias
El estado y las etiquetas muestran el estado del flujo de trabajo y la categoría del elemento asignado en una fila breve.
Panel de actividad
El estilo morado de elemento fusionado identifica el historial completado sin competir con los elementos no resueltos de arriba.
Del filtro al detalle
El campo de búsqueda superior muestra Type / to search, pero no tiene un controlador de búsqueda. Los filtros de la barra lateral sí funcionan con los grupos locales proporcionados: Participating muestra las solicitudes de revisión y las incidencias asignadas, Review requests muestra el grupo de revisión y Mentions muestra únicamente el grupo que contiene el marcador de mención de origen. Ese marcador está asociado a las incidencias asignadas, no a la fila de revisión que requiere respuesta. El filtrado es un comportamiento de presentación local, no una búsqueda conectada de GitHub ni un servicio de bandeja de entrada.
Cambios de estado mediante el color
El color transmite el estado en filas que, por lo demás, son similares. El verde marca estados de repositorio abiertos o aparentemente saludables, el amarillo marca el trabajo que espera una respuesta, el rojo marca la prueba fallida y el morado marca el elemento de actividad fusionado. Las etiquetas de la incidencia usan etiquetas redondeadas azules y rosas independientes para “backend” y “p1”. Esto agiliza el escaneo frente a leer cada frase, pero el color sigue siendo complementario: cada estado también aparece escrito como texto, lo que conserva el significado cuando el color por sí solo no es suficiente.
Límite de capacidades
La fuente implementa el filtrado local por categorías y construye enlaces salientes de GitHub para las filas y los títulos. Esos enlaces apuntan a un repositorio fijo mediante los identificadores de ejemplo mostrados; su existencia no verifica las solicitudes de incorporación de cambios, incidencias ni resultados de CI representados. La búsqueda, la recuperación autenticada de la bandeja de entrada, el estado persistente de las revisiones y la ejecución real de pruebas no están implementados. Los nombres, recuentos, marcas de tiempo, estados de aprobación y fragmentos de código siguen siendo contenido ilustrativo para el escenario de diseño.
Cómo crear un diseño de aplicación de bandeja de entrada para revisiones de código en OpenDesign
Establece el orden del espacio de trabajo
Crea un espacio de trabajo de escritorio con una barra lateral izquierda persistente para “All”, “Participating”, “Mentions” y “Review requests”, seguida de una columna principal amplia. Coloca primero las solicitudes de revisión, después las comprobaciones de CI, las incidencias asignadas y la actividad, para que el trabajo no resuelto preceda al historial.
Añade los estados específicos del caso
Usa filas de ejemplo para PR #2371 y PR #2389, una comprobación fallida “test (e2e)” en main, la incidencia asignada ENG-148 y el elemento de actividad correspondiente a la PR #2401 fusionada. Conserva etiquetas explícitas como “waiting on you”, “Conversation needs your reply”, “backend” y “p1”.
Prompt sugeridoCrea un diseño de aplicación de bandeja de entrada para revisiones de código de escritorio con una barra lateral izquierda persistente de filtros y un espacio de trabajo amplio agrupado. Muestra primero las solicitudes de revisión, incluida la PR #2371 con una diferencia compacta de OrbitBriefingCard.tsx y la PR #2389 con un estado que requiere respuesta; después muestra CI / Checks con un test (e2e) fallido, Issues assigned to you con ENG-148 y Activity con la PR #2401 fusionada. Usa únicamente datos locales ilustrativos y no des a entender que existe una conexión activa con GitHub, backend, almacenamiento ni ejecución real de pruebas.
Perfecciona el patrón de escaneo
Comprueba que el énfasis amarillo de las revisiones, el tratamiento rojo de los fallos de CI, los estados abiertos en verde y la actividad fusionada en morado sigan siendo legibles junto con sus etiquetas escritas. Mantén el fragmento de código subordinado a su fila de revisión, conserva los nombres largos del repositorio y de los archivos, y verifica que la agrupación vertical siga leyéndose correctamente cuando el espacio de trabajo se estreche.
Exportar y obtener un enlace para compartir
Exporta tu diseño terminado y luego usa Compartir en OpenDesign para obtener un enlace. Abre el enlace en una ventana del navegador independiente y comprueba que la versión prevista y sus recursos estén disponibles antes de enviarlo.



