¿Cómo empiezas a construir un sitio web?
La mayoría de los desarrolladores probablemente comiencen de cero o incorporen algunos recursos de sitios anteriores. Los más organizados entre nosotros han desarrollado una caja de herramientas personalizada desde la cual comenzar un sitio que demuestra ser una parte esencial de su flujo de trabajo.
Hoy analizaremos por qué debería considerar la posibilidad de crear su propio paquete frontal para que sirva como punto de partida para cada sitio que cree.
¿Qué es un paquete de front-end?
Lo que quiero decir con paquete frontal es esencialmente un conjunto de herramientas y convenciones que estandarizan ciertos elementos del proceso de desarrollo web. La inspiración para este artículo proviene de las mentes creativas de Erskine Design. Como diseñador, es probable que seas un pensador visual, así que iremos directamente al diagrama:
El esquema básico o el último paquete frontal de Erskine
Como puede ver, Erskine esencialmente ha construido un marco básico desde el cual saltar para los principales proyectos de diseño web. Lo resumen como ? un compendio de parachoques de archivos CSS conectados y en cascada, convenciones de nomenclatura, módulos, complementos y scripts de biblioteca que aseguran que cualquier proyecto liderado o trabajado por cualquier miembro del equipo se mantendrá en la convención, y será más sencillo para cualquier otro Entra y trabaja en cualquier momento.?
La posesión de un marco de este tipo puede ser invaluable por varias razones, que veremos a continuación. El argumento planteado por algunos es que dicho marco o conjunto de herramientas no solo es útil, sino que es absolutamente necesario. Simon Collison de Erskine Design va tan lejos como para decir: Sin lugar a dudas, todos los sitios web deben construirse con una capa de base sólida y un Último paquete.?
Echemos un vistazo a algunos de los beneficios y las razones para construir su propio paquete frontal personalizado. (Basado en algunas de las sugerencias de la Presentación de Erskine, que se encuentran aquí)
Eliminación de la repetición
Esta es la razón más básica y comprensible para desarrollar un paquete frontal. Cada vez que comienza a crear un sitio, realiza varios pasos de configuración, como formar la estructura HTML básica, crear archivos CSS externos, vincular HTML con CSS externo, importar jQuery y / o cualquier otra biblioteca de JavaScript que utilice con frecuencia, etc. .El desarrollo de un paquete frontal recupera todo este tiempo perdido al hacer que sea extremadamente fácil comenzar un nuevo sitio: simplemente copie la carpeta que contiene el marco y estará listo y funcionando.
Podría argumentar que estas tareas no toman una cantidad de tiempo significativa o incluso son necesarias para poner su cerebro en una mentalidad de desarrollo web. Para responder a estos argumentos, primero sugiero que se tome el tiempo para ver cuánto tiempo pierde en cada proyecto al establecer su jerarquía de archivos, configurar y cargar scripts y estilos, descubrir convenciones de nombres y corregir errores descuidados. Apuesto que es mucho más de lo que piensas. Finalmente, al último argumento, lo desafiaría a que vuelva a entrenar su cerebro para que acepte una nueva parte del proceso como comienzo. Intente saltar directamente a la experimentación con su sistema en su lugar y descubra qué tan mejor es omitir todas las tareas tediosas y repetitivas.
Normalización
La estandarización es un beneficio importante del uso de un conjunto de herramientas prefabricadas. Cada vez que comienzas un nuevo proyecto, puedes hacer cosas ligeramente diferentes. Esto puede ser algo grande, como cambiar la forma en que diseña su HTML, o algo pequeño, como decidir sobre una nueva convención de nomenclatura. Esto puede hacer que a los demás les resulte extremadamente difícil seguir su trabajo o incluso que usted vuelva más tarde y recuerde cómo estaba haciendo las cosas en ese momento.
A medida que desarrolle su paquete frontal, mantenga la estandarización al frente de su mente. Decida cuál es la mejor manera de hacer todo lo posible y respete esas convenciones en cada proyecto que comience. Marque sus comentarios de la misma manera, organice su CSS de la misma manera, use las mismas convenciones de nomenclatura de variables, utilice la misma jerarquía de carpetas, use los mismos restablecimientos de CSS, etc. El hecho de eliminar todas las pequeñas decisiones y conjeturas de su sistema tiene el beneficio de optimice todo el proceso de desarrollo para asegurarse de que está creando un sitio discernible y organizado lo más rápido posible.
Esto no quiere decir que deba elegir un sistema y seguirlo permanentemente. Deje que evolucione a medida que aprende y descubra mejores métodos, simplemente no integre nuevos métodos con la suficiente frecuencia para anular la utilidad de todo el paquete. Cuando decida una mejor manera de hacer algo, asegúrese de estar absolutamente seguro de que mejorará su sistema y de hacer una nota que describa el cambio y cuándo se integró para que sepa qué esperar de los proyectos más antiguos.
Mejor colaboracion
Aquí es donde un paquete de front-end se cruza de "bueno tener" absolutamente indispensable. Cuando trabajas con un equipo de desarrolladores en un proyecto grande, una de las mayores ineficiencias que puedes tener es el hecho de no tener a todos en la misma página desde el inicio del proyecto.
Si tienes a Bill estructurando su parte del proyecto de una manera, Jill la estructuró de otra manera, y Will intentará mantenerse al día con los métodos de Bill y Jill, las cosas se complicarán rápidamente (y no solo porque todos tus los nombres de los empleados pasan a la rima). Esto inevitablemente conducirá a largas reuniones dedicadas a discutir sobre las tonterías. Si tiene miembros del equipo que ya han comenzado un proyecto utilizando ciertas convenciones, puede apostar a que defenderán ese método hasta la muerte para evitar volver y arreglar lo que consideran un trabajo terminado. Esta es la razón por la que es extremadamente importante desarrollar un paquete de aplicaciones para usuario en los casos en que exista una colaboración significativa.Es probable que aún tenga que celebrar una reunión para decidir qué convenciones específicas seguir, pero encontrará que los miembros del equipo son mucho más flexibles a los nuevos métodos si no es necesario realizar un seguimiento.
La clave para llevar aquí es desarrollar un sistema antes de que comience un proyecto, no durante. Esto aumentará las posibilidades de aceptación y evitará muchos problemas de incompatibilidad en el futuro. Además, asegúrese de incluir a su equipo en el proceso de toma de decisiones. Esto es muy importante para el éxito del paquete por varias razones. Primero, siempre es una mala idea para la administración crear un sistema para simplificar una tarea determinada sin consultar a las personas que están más cerca de esa tarea. No importa cuántos títulos universitarios tenga más que la gente que tiene debajo, es probable que sean la mejor autoridad para lo que funcionará y lo que no. Finalmente, aparte del tema de la efectividad, se encuentra nuevamente el tema de la aceptación. Si le das a tu equipo un conjunto de pautas que no han tenido parte en el desarrollo, arrastrarán sus pies y se quejarán todo el camino porque los estás forzando a hacer algo que no quieren hacer. Sin embargo, si permite que los miembros del equipo de todos los niveles participen activamente en el desarrollo de las convenciones, es mucho más probable que se ajusten al nuevo sistema porque ayudaron en su creación y dirección.
Control de calidad
El desarrollo de un paquete frontal le permite implementar un cierto grado de control de calidad entre los miembros de su equipo desde el inicio del proyecto. Asegura que no se cometan errores comunes, como tomar el tipo de documento incorrecto u olvidar incluir una determinada hoja de estilo específica del navegador. Además, contar con un sistema estricto puede ayudar a prevenir el trabajo intencionalmente descuidado. En una loca carrera por poner en marcha un proyecto, los desarrolladores a menudo usarán códigos que no cumplen con los estándares, nombres de variables vagas, trucos oscuros y cualquier otro número de otros atajos con el argumento de que volverán y arreglarán estas cosas más adelante. El problema, por supuesto, es que generalmente no hay tiempo para regresar y arreglar estas cosas más adelante en el proyecto a medida que se acerca a los plazos clave. Muchos de estos problemas desaparecerán si fomenta una cultura que evite tales prácticas y desaliente el alejamiento de las convenciones acordadas.
En materia de diseño e innovación
Antes de que cierre y pido escuchar sus opiniones, quiero anticiparme a un argumento que pueda surgir. Muchos ven las convenciones comunes y las reglas estrictas como algo que paralizará el proceso de diseño, eliminando virtualmente cualquier espacio para la creatividad o la innovación. Esto simplemente no es el caso en este caso y, de hecho, es el resultado opuesto de lo que proporcionará un paquete frontal bien diseñado.
Un buen paquete frontal le permitirá enfocarse más en los elementos creativos del proceso de desarrollo a través de la estandarización de áreas que consumen tiempo y cuya variación no haría una diferencia significativa en el resultado final. Lo que quiero decir con esto es que los elementos como la jerarquía de su carpeta pasarán completamente inadvertidos para el usuario final y, por lo tanto, no son el lugar para enfocar su creatividad en cada proyecto. La idea aquí es superar las cosas aburridas de una sola vez para que pueda profundizar rápidamente en las cosas que hacen, y deberían, variar de un sitio a otro; Las cosas que hacen que cada sitio sea único. Con este tipo de sistema implementado, puede pasar más tiempo desarrollando interfaces de usuario originales, eligiendo esquemas de colores personalizados, probando diferentes familias de fuentes y codificando funciones innovadoras.
Si el sistema con el que creas obstaculiza el proceso creativo, simplemente no está haciendo su trabajo y, por lo tanto, debe ser desechado en favor de un viaje de regreso al tablero de dibujo.
Recursos Gratis
¿Se vendió con la idea de desarrollar su propio paquete frontal pero no sabe por dónde empezar? Aquí hay algunos recursos gratuitos para comenzar.
- Una colección asesina de estilos de restablecimiento de CSS global
- Ejemplos de páginas en blanco HTML
- Un simple sistema de plantillas PHP
- Código de Google: Bibliotecas de JavaScript alojadas (jQuery, MooTools, etc.)
- 16 plantillas básicas de diseño CSS
Habla tu mente
Lo anterior representa mi largo argumento por qué creo que Erskine Design tiene razón al afirmar que cada sitio web debe construirse a partir de una base sólida, estandarizada y predeterminada. Háganos saber si cree que desarrollar un sistema así vale la pena. Mejor aún, si tiene un sistema instalado, ¡háganos saber cómo funciona!