rlopdav392
commented
5 months ago PROTOTIPADO FIGMA - DOCUMENTAR PASO DE DESKTOP A MOBILE
Sigo mirando tu prototipo Figma, que está super currado, con modo oscuro y modo claro, incluso.
Muy bien lo de simular el diseño para un nuevo usuario versus para un usuario ya registrado, para que se haga una idea más detallada el cliente, está genial.
Por lo que estoy viendo ahora, también tienes hecha ya la versión mobile, genial.
Estaba mirando si se parecían los átomos de mobile con respecto a los desktop, esto es, si has podido reusar alguno de esos átomos. Si es así, documéntalo please, como ha sido el paso de desktop a mobile, si has podido reusar algún átomo de desktop
Es muy enriquecedor, ver documentado tanto en documentación como en presentación, pues el proceso de creación en sí, en este caso, como ha sido el paso de desktop a mobile en figma, tanto técnicamente, pues si has podido reutilizar algún componente, como a nivel de diseño, diseño home desktop vs home mobile.
cmilsor245
REVIEW PARTE FRONTEND - CHRISTIAN:
Solo un aplicativo ha de tener toda la lógica, el otro aplicativo, solo una parte de la misma, la que vosotros os dé tiempo.
Por lo tanto, no, no es necesario que en vanilla javascript implementes conectividad con backend.
DISEÑO / FIGMA
Pues está super currado, genial !!!
=> Estructura de ficheros: ok, me gusta mucho esa estructura, yo también la uso, y con los íconos pues ya te ha quedado genial.
=> Reusable (Atomic design) => nivel de reusabilidad alto, genial, todas las reviews son componentes.
=> Responsive (responsive design) => importante detallar en la presentación / documentación nivel de responsive de tu prototipo.
Mira, los átomos de las reviews (plotscore lets you), es super fácil hacerlos responsive, los pones como fill y hug, a los dos hijos (imagen + text) del autolayout.
Aunque, a veces, esto no nos interesa, el ponerlo como fill o hug, porque se nos desconfigura, por eso, hay que pensar bien el tipo del contenedor padre que usaremos para esos hijos, si un frame o un layout. con un frame no tienes que tocar el ancho / alto con fill /hug solo tocas las constraints a scale.
Así mismo, es importante lo del responsive, porque luego se le puede enseñar al cliente como quedaría en diferentes resoluciones el prototipo, y entonces para ello, lo que se hace es generar varias versiones del prototipo, pues una en un frame de 400, otra en un frame de 800, otra para un frame de 1200 y luego otra para tu frame de 1400, y si es toda responsive, adaptarlos a cada uno de esos frames pues es super fácil.
Y luego una vez que se tienes esos frames, se les renombra como breakpoints, y hay un plugin super chulo de figma, (breakpoints) que te permite ir pasando de un breakpoint a otro según vas cambiando las resoluciones del “navegador/visor figma”.
(https://www.youtube.com/watch?v=y7Evj_ClQeo)
Sabes que pienso hacer para el año que viene, voy a coger todos vuestros prototipos de este año, con vuestro permiso, y se los voy a poner de práctica a los nuevos del año que viene, para que hagan de práctica, pues convertirlos a responsive.
=> Interacciones => ok
=> Plantilla de átomos: Acuérdate que del diseño figma tiene que salir una plantilla de átomos que luego se actualizará en su maquetación CSS
Pues todos los estilos que has definido para los textos y los colores, eso es lo que habría que recoger en la plantilla de átomos,
(https://drive.google.com/file/d/1Cn2LvjCbddrenFXy4i84zaV8F-1gjw5W/view)
=> Plugin de accesibilidad=> importante pasarle algún plugin de accesibilidad (able)
=> Patrones / Principios de diseño => importante explicar en la documentación los patrones y principios de diseño usados para el prototipo.
MAQUETACIÓN CSS3
=> variables: muy bien el uso de variables para los colores, las fuentes y los espaciados.
=> BEM (block element modifier):
Vamos a comentar, el tema de los anidamientos con BEM, esto que me haces por aquí:
.common--content-footer--content
Yo no soy muy amiga de usar anidamientos con BEM, al final BEM se creó para dar claridad al código, para solo de una pasada, sin tener que ir a HTML, pues saber que tales clases son hijos de tal padre, o son una variante de tal padre.
Pero si, por ejemplo, tu tienes en tu árbol HTML un árbol de hijos de n niveles de profundidad que cuelgan de un padre, ejemplo:
.padre .padre .hijo .padre .hijo .nieto
Pues, la forma correcta de extrapolarlo a la metodología BEM sería:
.padre .padrehijo .padrenieto
Esto se hace, por no complicar el código, solo de una pasada sabes que todos esos hijos, sean del nivel que sean del árbol, su nodo ráiz es padre.
Aquí un artículo, por si quieres profundizar, o por sino me he explicado bien.
(https://andrew-barnes.medium.com/bem-css-tip-dealing-with-grandchild-elements-d7378b51e722)
Vale, eso ya, por un lado.
Ahora, por otro lado, es importante que entendáis la diferencia entre un element y un modifier, dentro de la metodología BEM (block / element / modifier)
Entonces, extrapolando esta explicación a tu código, pues por ejemplo, estos serían elements y no modifiers:
Footer Footertop Footertop-main-links Footertop-socials Footerbottom
Landing-pagelist Landing-page Landing-pagelist Landing-page__list-posters …
Estos si que serían modifers: media-slot--small 'media-slot--medium' ..
Vale, y entonces, con la metodología BEM buscamos claridad, de tal forma, que sin ir al html pues sepamos cual es el padre raíz de un elemento.
Pero si lo que quieres, de alguna forma, es desde CSS ver todo el anidamiento del árbol, sin ir al HTML, pues saber que tal nodo cuelga de tal nodo, el que a su vez, cuelga de tal nodo.
Esto, tal como te he comentado, no es recomendable, replicarlo con BEM, pero si se puede hacer con native CSS nesting
=> Native CSS Nesting
(https://lenguajecss.com/postcss/plugins/css-nesting/)
https://caniuse.com/?search=css%20nesting
Este, al parecer, se puede usar tanto con el símbolo &, como sin él, yo como me es más legible con ese símbolo, he hecho un ejemplo con tu footer.css y lo he pasado a css nesting, y es el que te adjunto aquí:
footer_nesting.zip
Esto como verás es acercarnos cada vez más a SASS, sin usar SASS.
=> Documentación interna:
Con respecto a los comentarios CSS, a mi personalmente, me gusta documentar, entre otras movidas:
=> código - reusabilidad - abstracción: Importante detallar en documentación / presentación nivel de reusabilidad de tu código (cuantas clases reusas en varios sitios, como los layouts (grid, flex), los botones, las listas, los espaciados (margin, padding),.., si haces uso de variables)
=> Arquitectura de ficheros CSS: Esto tienes que explicarlo en la documentación, pues eso que tienes una carpeta con tus componentes, y luego una para tus páginas, bueno y demás estructuras que tengas (layout.css, page.css,..)
=>SEO / html semántico: uso ok de favico y title, no veo la meta description, añádela sino está, please.
Acuérdate de revisar que tengan todas las imágenes alt, si estás usando background-image en un div genérico, puedes hacer uso del atributo aria-label del div.
=> Big layout: el big layout, esto es, el super container que se encuentra entre las etiquetas body de una página html, ha de estar estructurado semánticamente bien, por ejemplo, si se trata de la página principal ha de estar divido en un header – main – footer. Y dentro del header han de estar los enlaces a través de un nav.
Está ok, además luego dentro del main usas section para estructura mejor el contenido. Me parece bien.
=> Imágenes:
Como usas la técnica de lazy loading, pues está genial.
Además veo que usas el formato webP que te reduce el peso con la misma calidad, así que genial.
No obstante, pásale algún test de perfomarce (lighthouse, https://tools.pingdom.com/, https://pagespeed.web.dev/)
Y comprueba cómo se ven en diferentes resoluciones, si mantienen la calidad o no. En caso de que no, tendrás que crear para una imagen, diferentes versiones según las resoluciones donde se vayan a renderizar, y eso se lo dices al navegador, con la etiqueta html picture => source
=> Responsive design -media querys: Importante detallar en documentación / presentación, ,pues cuantos breakpoints se han definidos, esto es, para cuantas resoluciones es responsive tu diseño.
=> Responsive design – layout grid / flex: acuérdate de explicar en la documentación / presentación los layouts que tienes implementados en tu página.
=> Responsive design – unidades relativas: Haces uso tanto de unidades relativas (rem) como de unidades absolutas (px). Esto ya me lo comentaste por correo, pero has de explicarlo en la documentación / presentación, pues como me explicaste en los correos. Y puedes incluso, incluir las pruebas que hiciste, pues en cada breakpoint, cambiando el font size.
=> Plantilla de átomos: Aquí un ejemplo de una plantilla de átomos con un nivel de detalle alto:
(https://drive.google.com/file/d/1Cn2LvjCbddrenFXy4i84zaV8F-1gjw5W/view)
Acuérdate que esta plantilla de átomos no es más que una actualización de la plantilla de átomos que salió de la maquetación CSS.
REACT/NEXT.JS
=>Lazy loading => Explicas en el vídeo que las imágenes tienen dos resoluciones, uno para bajas resoluciones (1x) y otra para altas resoluciones (2x). Y que en la lógica react, lo tienes en cuenta, para que en la primera carga, sean renderizadas las de baja resolución,y luego las otras, esto explica en la documentación como está implementado, please.
=>Información dinámica vs estática: Dejar bien claro en la presentación / documentación que sección de tu página son dinámicas, se cargan desde servidor, y cuales estáticas. En tu caso, por lo que he entendido, todas las cards son dinámicas, y con respecto a las imágenes, algunas serán dinámicas, también, pues eso has de especificarlo en la documentación.
=> Arquitectura de ficheros: Explicar en la documentación cómo están estructurados tus ficheros js.
=> Reusabilidad – abstracción código: explicar que piezas / componentes / átomos son reusables.
=> Riqueza React: pues eso, explicar todo lo que has usado de react:
useState / useEffect / Hooks personalizados / Context API, / UseRef / React-router-dom / react-modal / react-tostity,..
=> Documentación interna: acuérdate de documentar tu lógica react con comentarios.
JAVASCRIPT
Esta parte te faltaría.
Lo que te comentaba al principio, no es necesario que implementes la conectividad con backend.
Es suficiente con que tenga una buena gestión de eventos, manipulando información estática o a lo sumo leyendo de algún json estático.
Así mismo, con implementar una página, la principal, por ejemplo, es suficiente.
Repaso lo que tendrías que documentar de esta parte:
=> Información dinámica / estática: En este caso, solo si haces algo dinámico, pues lo comentas, sino nada.
=> código - reusabilidad - abstracción: Importante detallar en documentación / presentación nivel de reusabilidad de tu código (uso de funciones, librerías)
=> Documentación interna: acuérdate de documentar tu javascript con comentarios.
=> DOM: acuérdate de usar delegación siempre que sea posible, para mayor eficiencia del código y gestionar todas los eventos siempre desde js, nada de javascript en html.
=> Arquitectura de ficheros: has de explicar la arquitectura de ficheros usada.
PENDIENTE PARTE FRONTEND - CHRISTIAN:
=> del aplicativo desktop => pues ya lo tienes casi todo (prototipado + maquetación + lógica react)
=> del aplicativo mobile => pues te faltaría ponerte con la maquetación CSS y la lógica vanilla javascript. Si todavía no lo has empezado, te animo a que uses SASS en este aplicativo, pues para amplicar conocimientos, y obvio si usas SASS, no solo por el tema de las variables o el anidamiento que ya te lo da CSS, sino por el tema de los extend / mixin.