¿Mantener el "código" alejado de los diseñadores?

Construyo bastantes proyectos con un amigo mío, pero siempre encontramos el mismo escollo una y otra vez. Sé cómo escribir PHP, Javascript y todo eso (también sé CSS y HTML) para poder hacer la mayor parte del trabajo a la hora de construir la funcionalidad real. Sin embargo, no puede, pero puede hacer algo que yo apenas puedo: diseñar los sitios.

Pero cada vez, nos topamos con un problema, ya que él no sabe cómo escribir código, generalmente ralentiza bastante nuestro desarrollo. Por el momento este es nuestro flujo de trabajo:

1. Creamos una característica
2. Construye el diseño frontal (dónde debe colocarse, cómo se verá, etc.)
3. Me envía la plantilla completa (la exportación HTML desde Pinegrow)
4. Busco los cambios que hizo, luego los implementa en el sitio real (desde hace unas semanas, uso CakePHP para ello).
5. cuando algo no funciona según lo previsto (por ejemplo, no funcionó como lo planeamos por alguna razón), soluciono el problema de mi lado y luego le devuelvo la plantilla
6. enjuagar y repetir

Este proceso, como uno podría imaginar, es minuciosamente lento e ineficiente. Entonces mi pregunta es, ¿cómo podemos hacer que este proceso sea más fácil? He visto muchas cosas sobre eso, deberíamos usar React y RESTful y otras cosas, pero queremos usar CakePHP para ello. ¿Podría alguna gente guiarme a algunos recursos útiles al respecto? He estado buscando esto por un tiempo, pero nunca llegué a una solución decente para esto.

Básicamente, todo lo que mi compañero puede hacer es diseñar el sitio. No puede usar Docker (yo uso Docker todo el tiempo), PHP, Javascript y casi cualquier otra cosa (sabe algo de CSS, pero principalmente trabaja con un WYSIWYGeditor). Estoy dispuesto a aprenderlo, pero él es No me interesa (así que lo respeto). Espero que alguien aquí pueda ayudarme (y probablemente otros que vengan con esta pregunta más adelante) con esto, ya que creo que es algo muy importante.

¿Desea liberar a su Diseñador front-end del código? ¿Quieres acelerar la integración? ¿Desea utilizar las técnicas profesionales utilizadas por los sitios web más hábiles? Con mucho, la mejor herramienta para esto es:

Pintar.

Si pintura. Bueno, algún programa de dibujo de todos modos. Permítale tomar capturas de pantalla de su sitio, mover cosas y agregar cosas que encuentre en otro lugar. Esto le permitirá trabajar a la velocidad de sus ideas y lo liberará para que doble el código en la forma que le resulte mejor mientras le da lo que necesita.

Si todavía es demasiado lento, digamos porque el cliente está en la habitación con ambos, recomiendo un conjunto de herramientas mucho más avanzado:

Papel, tijeras y cinta adhesiva.

Tal vez una pluma si te sientes ambicioso.

He utilizado esta técnica para tomar decisiones con éxito sobre el tema, el estilo, el contenido y las características principales de un sitio en una mesa en un Panera Bread con un cliente antes de que nadie se diera cuenta de que habíamos terminado de comer.

Eso lo hará rápido, lo liberará de su "código", y en realidad es la forma más poderosa de desarrollar una interfaz de usuario. Puede comenzar a hacer pruebas de usabilidad antes de que haya escrito una línea de código.

Puede estar pensando "oh, esto está bien al comenzar, pero no lo usa una vez que se desarrolla el sitio". No es verdad. Funciona igual de bien en sitios estables. Pero ahora la mayoría de las capturas de pantalla provienen de su propio sitio.

¿Qué sucede si su Diseñador front-end quiere usar algunas herramientas generadoras de código para hacer sus maquetas? Bien, pero no pienses por un segundo que tienes que usar su "código". Lo que debe respetar son sus decisiones sobre la apariencia, el flujo y la presentación. Lo que sucede detrás de la cortina para que eso suceda no es su área de especialización. Es tuyo. Asumir la responsabilidad de eso.

Solo respeta su trabajo lo suficiente como para que cuando hayas terminado le muestres cómo resultó. Permítale que revise todo lo que el usuario experimentaría. Prepárate para recibir ideas nuevas.

Este es un desarrollo iterativo. No hagas mucho antes de preguntar. Haz lo menos que puedas. Pregunta tan a menudo como puedas. Coloque juguetes en su escritorio para mantenerlo entretenido mientras implementa su última idea para que pueda revisarla tan pronto como se cargue. Siga así hasta que sea hora de reunirse con el cliente.

Si el código que produce su Diseñador front-end realmente vale la pena, entonces necesita aprender a integrar su código con el suyo. Por esto, le recomiendo que aprenda el control de fuente . Aprende tan bien que puedes enseñarle a tu Front End Designer cómo usarlo.

Solo una vez que ambos puedan usar de manera confiable una herramienta de control de código fuente, les recomiendo que basen su plan de integración en el código de fusión. En este punto, tu amigo merecería un cambio de título de Front End Designer a Front End Developer.

Ahora, incluso si haces esto, no me sorprendería si la técnica de garabatear en la pantalla no resulta ser la forma más rápida para que ustedes dos colaboren.

Quizás no puedas soportar el caos de todos estos cambios. Está creando demasiado trabajo. Bueno, se llama software porque acepta cambios. De lo contrario, tendríamos un ingeniero eléctrico que lo haría en un chip especializado. Es posible que necesite comunicarse con el objeto para mover su lógica de comportamiento fuera de la interfaz de usuario para que los cambios en la interfaz de usuario no afecten sus reglas comerciales principales. Si acelera su Front End Designer, debe estar preparado para mantenerse al día con ellos.

La única buena razón para obligar a un Diseñador front-end a producir código es porque estás cansado y quieres ralentizarlo. Bueno, supongo que esa no es realmente una "buena" razón.

En términos de herramientas, el flujo de trabajo óptimo que he visto es utilizar Sketch y Zeplin. Sketch es una herramienta de diseño directo. Equivalente a Photoshop o InDesign, pero optimizado para diseñar aplicaciones y sitios web. Zeplin es una herramienta para compartir y aprobar diseños en Sketch (o Photoshop). Puede proporcionar mediciones precisas de píxeles e incluso fragmentos de código para CSS u otro código de diseño y exportar activos gráficos. Una vez que se establece un diseño, se entrega al desarrollador. En este punto, el desarrollador lo recoge y construye la interfaz de usuario. Luego puede volver al diseñador para el control de calidad visual. Cualquier cosa que encuentre mal con él, solo debe registrarse como un error para que usted lo priorice y resuelva.

cuando algo no funciona según lo previsto (por ejemplo, no funcionó como lo planeamos por alguna razón), soluciono el problema de mi lado y luego le devuelvo la plantilla

Esa es la raíz de tus problemas. El flujo del diseño siempre debe ser de Designer to Developery nunca invertido. El diseñador debería haber realizado revisiones y cambios, y luego haberlo enviado a usted para su implementación en el sitio web. Siempre puede hacer arreglos rápidos usted mismo, pero trate de aceptar que esos arreglos rápidos son solo temporales. El diseñador necesita volver a sus diseños y encontrar la solución adecuada. Luego, te envía el cambio, y si resulta ser lo mismo que tu solución rápida, entonces genial, de lo contrario, actualizas desde sus diseños.

Me envía la plantilla completa (la exportación HTML desde Pinegrow)

No se vuelva adicto a recibir HTML con el que pueda trabajar. Es mejor si implementa la tecnología del sitio web (Bootstrap, CSS, jQuery, React, PHP, etc., etc., etc.) de la manera que la necesita. Luego reproduces sus diseños usando esas herramientas. Si el HTML que le da es un comienzo rápido, entonces excelente, pero más tarde a medida que el proyecto crezca, no será de mucha utilidad. Tendrá que hacer los cambios usted mismo porque solo usted comprende su motor de plantillas (es decir, vistas, plantillas, complementos, componentes, etc. de CakePHP, etc.)

Este proceso, como uno podría imaginar, es minuciosamente lento e ineficiente.

Siempre ha sido así. Los diseñadores no son programadores. Se toman su tiempo para descubrir qué funciona mejor para el usuario y, a veces, cometen errores. No entienden conceptos como componentes, marcos y demás. Como programador, tiene que hablar con su diseñador y compartir cómo implemento lo que diseña .

El diseñador está atrapado en el medio. Por un lado, deben satisfacer las necesidades del programador y, por otro lado, deben satisfacer las necesidades del usuario.

Entonces mi pregunta es, ¿cómo podemos hacer que este proceso sea más fácil?

Descubrí que sentarse físicamente al lado del diseñador y programar allí realmente ayuda con la comunicación. Si ustedes dos están trabajando de forma remota, entonces mantengan el tiempo de funcionamiento durante unos días. Realmente ayuda a acelerar las cosas.

He visto muchas cosas sobre eso, deberíamos usar React y RESTful y otras cosas, pero queremos usar CakePHP para ello.

CakePHP es uno de los mejores frameworks del planeta (divulgación completa, estoy en el equipo central de CakePHP).

Cake es un marco de desarrollo de conejo donde las características están diseñadas para construir sitios web rápidamente. Sé que suena como un argumento de venta, pero esto es lo que se clasifica como. Hay muchos otros marcos que se clasifican como conejo. Java sería un ejemplo de un marco que es más empresarial que el conejo. Si estuvieras usando ese idioma, habría hecho una recomendación para cambiar. Ya que estás usando CakePHP. Yo diría que deberías quedarte con eso.

CakePHP es un buen servidor de fondo si necesita API RESTful.

React / Angular / Vue son marcos front-end populares y de tendencia, pero no han existido por mucho tiempo. CakePHP por otro lado ha existido por más de 13 años. Mi punto no es una crítica. Es el hecho de que estas bibliotecas de JavaScript tienen una vida útil corta. En 5 años todos hablaremos de algo nuevo, pero sospecho que CakePHP seguirá existiendo.

Entonces digo. Usa React / Angular / Vue ahora mientras están calientes, pero no te comprometas con ellos. Algo nuevo y mejor llegará pronto. Creo que ahora vivimos en un mundo donde no puedes construir buenos sitios web sin ellos.

¿Podría alguna gente guiarme a algunos recursos útiles al respecto?

Las solicitudes de listas están fuera de tema aquí. Lo siento.

EDITAR :

Me perdí la parte sobre el seguimiento de los cambios de diseño.

Haga que su diseñador guarde su salida HTML en BitBucket (tienen repositorios privados gratuitos). Luego puede realizar un seguimiento y hacer comparaciones utilizando el sitio web de BitBucket. Cada vez que el diseñador realiza un cambio importante, agrega una nueva sucursal con un número de versión.

Debería ser relativamente fácil para él hacer esto, y esto le permitirá tener un lugar para comentar dichos cambios. Por ejemplo; él puede hacer una solicitud de extracción para actualizar el repositorio donde realice una revisión de los cambios antes de que se fusionen.

Necesita separar estas dos cosas:

1. Diseño UX y UI, una actividad no codificante
2. Implementación, definitivamente una actividad de codificación

El diseñador debe usar herramientas creativas como Marvel, que son solo para diseñar. No debería ser asunto del diseñador hacer nada con código, HTML, CSS, etc. Los colores, las dimensiones, la estética, las interacciones, las animaciones son todas las cosas en las que debe centrarse.

El programador debe recibir los activos y la maqueta (con interacciones y animaciones) y debe hacerlo mediante la programación del software. Esto incluía HTML y CSS también. El programador también puede usar herramientas generadoras de su lado.

Para acelerar el flujo de tareas, recomiendo usar una herramienta mínima como Trello y vincular / documentar todo para cada unidad de trabajo.

¿Cómo podemos hacer que este proceso sea más fácil?

Insistir en el control de versiones

Ramificación de software y universos paralelos

• Trabaja en ningún código que no esté en control de versiones. punto final Y me refiero a ir a la huelga hasta que el proyecto esté todo en un VCS.
• Rama formal, liberal, local
  • Formalmente: ramificación para lanzamientos y subparte de lanzamientos, corrección de pruebas formales, etc. Desarrolle un plan de control de versiones formal, es decir, escríbalo.
  • Liberalmente: más allá de la numeración de lanzamiento formal de 4 partes, bifurca si tu instinto te dice que podría ser una buena idea.
  • A nivel local: mantuve un repositorio personal con sucursales nunca destinadas al consumo del equipo porque, como equipo, al principio no nos ramificamos, y a menudo tengo experimentos, exploración, por si acaso, etc.

Diseña al máximo tus API de middleware

Beneficios:

• Estabilidad, incluso cuando el código subyacente está evolucionando.
• Código comprobable
• Reutilizar
• Una herramienta de comunicación en equipo.
• Es un contrato. Una promesa de servicios prestados (juego de palabras)
• Codificación en el ámbito de SOLID == programador de mantenimiento feliz

Es el principio de preguntar, no decir aplicado de la manera obsesiva compulsiva que debería ser. Si la interfaz de usuario está manipulando una sola propiedad de capa empresarial, eso está mal.

Todo y cualquier cosa sobre los objetos comerciales debe estar en dichos BO's. Incluso cosas triviales que pueden parecer mejor hechas en la interfaz de usuario, incluso un solo LOC. A Minuita le gusta agregar 2 valores proporcionados por el usuario: toda la lógica asociada, incluida la validación, debe estar en la API de la capa empresarial. La redundancia de la OMI a veces está bien. Para mitigar la redundancia, puede tener objetos de capa empresarial pequeños y enfocados a los que la UI tenga acceso completo.

Todo y cualquier cosa que la IU necesite de los objetos de negocios debe ser API '. Por ejemplo, tenga métodos explícitos que conecten sus argumentos a los controladores de eventos.

Cuidado con los marcos como una muleta

En manos de los no calificados, los marcos y los IDE no son barreras para los monstruos de películas B que crean.

Con marcos como React, se podría decir que es todo del lado del cliente, no hay una capa de lógica de negocios de back-end. La idea clave aquí es desacoplar lo que el usuario ve de lo que hace el programa. Eso es factible. No es solo un servidor físico frente al navegador de los usuarios.

Creo que es un buen indicador de la inmadurez de la profesión y la práctica que aceptamos que las personas que diseñan no pueden hacer.

Esto no sería aceptable en casi ninguna otra profesión.

Es razonable esperar que un diseñador especializado en diseño de sitios web / aplicaciones conozca CSS y HTML lo suficientemente bien como para proporcionarle archivos funcionales y utilizables de ese tipo.

Los diseñadores que proporcionan editores gráficos WYSIWYG son diseñadores visuales o gráficos. Hay muchos tipos diferentes de diseñadores.

Sin embargo, también hay muchos tipos diferentes de niveles, habilidades y experiencias. Quien diseña muebles puede hacerlo únicamente en una computadora con herramientas de diseño en 3D, en cuyo caso su conocimiento sobre cómo girar un torno u operar un enrutador CNC puede ser totalmente teórico. Hacen sus diseños y luego los envían para que otros los hagan.

Por el contrario, algunos diseñadores expertos pueden tener control sobre todo el proceso y tener la capacidad y el conocimiento para construir sus muebles con atención a cada detalle, tal vez incluso a mano.

No podrá convencer a su amigo para que cambie su forma de trabajar. Si prefiere tener un diseñador web con las habilidades de HTML y CSS para crear sus propios diseños, necesitará encontrar uno.