DEV Community: Eloy Parga

La Maravilla del Modelo de Caja "Border-box"!

Eloy Parga — Mon, 22 Jan 2024 10:24:34 +0000

Uno de los aspectos que menos me gusta sobre el diseño con CSS es la relación entre el ancho y el relleno (padding). Estás ocupado definiendo anchos para que coincidan con tu rejilla o proporciones generales de columnas, y luego, al agregar texto, necesitas definir relleno para esas cajas. Y de repente, estás restando píxeles de tu ancho original para que la caja no se expanda.

¡Uf! Si digo que el ancho es de 200px, maldición, va a ser una caja de 200px de ancho, incluso si tengo 20px de relleno. Como sabes, esto NO es cómo ha funcionado el modelo de caja en los últimos diez años. Wikipedia tiene un gran historial de este modelo de caja. Jeff Kaufman también profundizó en la historia.

De todos modos, tengo una recomendación para tu CSS en adelante:

/* Aplica un modelo de caja natural a todos los elementos, pero permite cambios en los componentes */
html {
  box-sizing: border-box;
}
*, *:before, *:after {
  box-sizing: inherit;
}

Esto te brinda el modelo de caja que deseas. Se aplica a todos los elementos. Resulta que muchos navegadores ya utilizan border-box para muchos elementos de formulario (por eso los inputs y textareas se ven diferentes con width: 100%). Pero aplicar esto a todos los elementos es seguro y sensato.

Soporte del Navegador

Debido al soporte del navegador, esta recomendación es solo para proyectos que admitan IE8 en adelante. Firefox <= 28 todavía necesita el prefijo -moz-, y <= iOS4, Android <= 2.3 necesitan el prefijo -webkit-, pero todos los demás usan el sin prefijo. Puedes encontrar más información sobre un polyfill para box-sizing en IE6 y 7 en html5please.com/#box-sizing (que fue desarrollado con * { box-sizing: border-box!).

Ajustes para Contenido de Terceros

Cualquier widget de terceros que agregue contenido directamente a la página puede necesitar atención adicional. Cualquier widget dentro de un iframe (como el nuevo tema de Disqus) está naturalmente aislado de los estilos de diseño de la página principal. Si necesitas hacer ajustes al contenido de terceros, puedes aplicar box-sizing: content-box;
al widget y sus descendientes. Esto puede no ser trivial, ya que los controles de formulario en particular son border-box de forma predeterminada, así que también tendrás que tener eso en cuenta.

Principios SOLID

Eloy Parga — Thu, 18 Jan 2024 07:47:25 +0000

Principios SOLID son una serie de principios de diseño orientado a objetos que nos ayudan a crear código más mantenible y reutilizable. Estos principios fueron definidos por Robert C. Martin (Uncle Bob) en su libro “Agile Software Development, Principles, Patterns, and Practices” en 2000.

Los principios SOLID son:

S: Single Responsibility Principle (Principio de Responsabilidad Única)
O: Open-Closed Principle (Principio de Abierto-Cerrado)
L: Liskov Substitution Principle (Principio de Sustitución de Liskov)
I: Interface Segregation Principle (Principio de Segregación de Interfaces)
D: Dependency Inversion Principle (Principio de Inversión de Dependencias)

Single Responsibility Principle (Principio de Responsabilidad Única)

Este principio nos dice que una clase debe tener una única responsabilidad, es decir, que debe tener una única razón para cambiar. Esto nos ayuda a crear clases más pequeñas y con una única responsabilidad, lo que facilita su mantenimiento y reutilización. Por ejemplo, si tenemos una clase que se encarga de gestionar los usuarios de nuestra aplicación, esta clase debería tener las siguientes responsabilidades: CRUD de usuarios

Open-Closed Principle (Principio de Abierto-Cerrado)

Este principio nos dice que las entidades de nuestro código (clases, módulos, funciones, etc.) deben estar abiertas a la extensión pero cerradas a la modificación. Esto nos ayuda a crear código más mantenible y reutilizable. Es decir, si tenemos una clase que implementa una funcionalidad, no deberíamos modificar esa clase para añadir nuevas funcionalidades, sino que deberíamos crear una nueva clase que herede de la clase base y que implemente la nueva funcionalidad.

Liskov Substitution Principle (Principio de Sustitución de Liskov)

Este principio nos dice que las clases derivadas deben ser sustituibles por sus clases base. Esto nos ayuda a crear código más mantenible y reutilizable. Es decir, si tenemos una clase base que implementa una funcionalidad, las clases derivadas deben poder usar esa funcionalidad sin tener que modificar el código de la clase base.

Interface Segregation Principle (Principio de Segregación de Interfaces)

Este principio nos dice que las interfaces deben ser lo más pequeñas posibles. Esto nos ayuda a crear código más mantenible y reutilizable. Es decir, si tenemos una interfaz que define una funcionalidad, no deberíamos añadir más funcionalidades a esa interfaz, sino que deberíamos crear una nueva interfaz que herede de la interfaz base y que defina la nueva funcionalidad.

Dependency Inversion Principle (Principio de Inversión de Dependencias)

Este principio nos dice que las clases de alto nivel no deben depender de las clases de bajo nivel, sino que ambas deben depender de abstracciones. Esto nos ayuda a crear código más mantenible y reutilizable. Es decir, si tenemos una clase que implementa una funcionalidad, no deberíamos depender de la implementación de esa funcionalidad, sino que deberíamos depender de una interfaz que defina la funcionalidad.

¡DISEÑO UI! Las leyes de Gestalt

Eloy Parga — Wed, 17 Jan 2024 13:50:47 +0000

Hola Mundo, hoy vamos a hablar de un aspecto teórico del diseño UI

¿Qué son las leyes de Gestalt?

Son unas serie de leyes que creo la facultad de Gestland, estas leyes se crearon a partir de como los humanos interpretamos las cosas.
Estas leyes ayudan al diseñador a interpretar como focalizar el objetivo del diseño de cara al Usuario.

Ley de figura y fondo

En todo diseño hay una figura y un fondo, estas se diferenciaran por su forma, tamaño o color.

Otras formas de diferenciar la figura del fondo: Sombras, bordes, patrones, etc

Ley de la semejanza

Si hay elementos que son similares, el cerebro asociará que están en un mismo grupo.

Como hacer semejanzas: Por forma, por tamaño, por color, etc.

Ley de la proximidad

Si hay elementos cerca, el cerebro los asocia como un mismo grupo pero, si están lejos los toma como grupos separados.

Otras formas de separar y agrupar: Espacios, líneas, colores, peso de la fuente, etc.

Ley del cierre

El cerebro cierra los espacios de las figuras así no estén completas

Como hacer cierres: Puntos, líneas discontinuas, sombras desplazadas, etc.

Ley de la pregnancia

En un diseño debe haber un elemento que resalte más que los demás (Elemento más importante).

Como resaltar: Peso de la fuente, color diferente, líneas, fondo, capas, etc.

Ley de la experiencia

El ser humano tiene experiencias previas almacenadas en el subconsciente y puede relacionar elementos.

Como aplicar: Botones con sólo bordes, figuras nuevas con texto, iconos en vez de textos, etc.

Ley de la simplicidad

El cerebro simplificará lo que más pueda las figuras y elementos.

Como simplificar: Utilizar la cantidad mínima de elementos posibles (bordes, separadores, cajas, etc)

Ley de la simetría y el orden

El cerebro asocia en un mismo grupo a los elementos que tienen simetría.

Como hacer simetría: Compensar espacios, alinear elementos, etc.

Ley de la continuidad

El cerebro asocia a los elementos que siguen una misma dirección, como parte de un mismo grupo.

Como hacer continuidad: Carruseles, tabs, secuencias, partir elementos, etc.

Conclusiones
Si quieres ser un experto en UI debes manejar muy bien las leyes de Gestalt, te ayudarán en gran medida para obtener interfaces intuitivas, limpias y profesionales.

Si os gusta mi contenido no dudéis en darle apoyo.

Linkedin: https://www.linkedin.com/feed/
GitHub: https://github.com/EloyParga