Es normal que al implementar un diseño surjan situaciones que no hemos previsto. Esto no tiene porque ser un error, simplemente a veces es imposible prever ciertos casos de uso o comportamientos de nuestras aplicaciones sin dedicarle decenas de horas a la definición de una tarea. Sin embargo, hay ciertas pautas recurrentes que se suelen dar y es el propósito de este post identificarlas y analizarlas para agilizar el proceso de desarrollo si nos topamos con ellas, como facilitar el flujo de desarrollo.
Tener en cuenta que en muchos casos los datos son más largos de lo que solemos pensar en un principio
El problema con textos que no ocupan el espacio previsto es algo muy común en desarrollo. Es muy bonito ver en los diseños un formulario tal que:
Nombre: John
Apellido: Nieve
Email: jnieve@gmail.comPero el mundo real es duro y cuando menos te lo esperas aparece un usuario con lo siguientes datos:
Nombre: Francisco Javier
Apellido: Sánchez del Pinar Garroguerricaechevarria
Email: franciscojaviersanchezdelpinarGarroguerricaechevarria1992@hotmail.comLo que antes era un formulario cuqui se ha transformado en un infierno multilínea y ya no cabe nada. El email se corta en versión mobile porque no se ha tenido en cuenta la falta de espacio y nuestro precioso formulario ahora es un desastre.
Para prevenir esto es una buena idea pensar que todos nuestros usuarios son miembros de la realeza y tienen nombres de 30 caracteres.
Seguro que encuentras una solución adecuada ante este problema: agrupar los componentes de una manera más óptima, disminuir el tamaño o el uso de elipsis en ciertos casos. Simplemente recuerda que el problema con los nombres largos es algo frecuente en desarrollo y más vale prevenir que lamentar.
Tener previsto cómo se validan los formularios
El uso de formularios es algo muy común en el desarrollo de aplicaciones y tener claro cómo validar los posibles campos a tratar nos puede ahorrar tiempo de desarrollo.
Validar un formulario no es otra cosa que indicar al usuario qué campos son obligatorios o tienen un formato incorrecto. Un par de ejemplos de validación serían que un email no existiese en nuestra base de datos y que este email tuviese un formato correcto.
Es común tener varios diseños del formulario, uno en su estado inicial con placeholders, otro con los valores insertados y otro con errores. Puede que otro con los inputs resaltados si los valores son correctos.
Pero ¿cuándo se muestra cada estado? En el caso de los campos correctos es sencillo: cuando se rellene correctamente y los valores sean correctos, se aplicarán los estilos correspondientes. Pero, en el caso de los errores, pueden haber varias opciones a tratar.
¿Cuando validamos que un campo es correcto en un input de texto por ejemplo? ¿Al escribir un carácter? ¿Al cambiar el foco a otro componente del formulario? ¿Al enviar el formulario? No está demás tener definido este comportamiento de antemano ya que evitaremos posibles sorpresas y desviaciones en el desarrollo si a posteriori tuviesemos que cambiar el sistema de validación.
Implementar tu diseño de manera que facilite su implementación
Utiliza herramientas que ayuden a los desarrolladores a hacer su trabajo. Como desarrollador recibir diseños en jpg es un incordio. ¿De verdad hay gente que envía sus diseños en jpg? Te aseguro que sí, así que no seas como ellos, por favor.
Activar modo de desarrollo (Dev Mode) en las plataforma de diseño utilizadas ayudará enormemente a los desarrolladores ya que proporcionan herramientas específicas que les ahorrarán tiempo a la hora de implementar los diseños.
Tener en cuenta que no siempre se devuelven datos
En nuestras aplicaciones no siempre van a existir datos y hay que tener en cuenta que esto puede suceder.
Es muy común a la hora de desarrollar que se den preguntas tipo ¿que mostraremos si una tabla en concreto está vacía? ¿Cómo se verá esta vista si no hay descripción? ¿Qué pasará si un usuario no tiene número de teléfono (que en este caso no es obligatorio)?
Tener en cuenta que existe la posibilidad de que ciertos datos no existan agilizará aún más el desarrollo ya que no se producirá un bloqueo cuando se den estas situaciones.
Saber cómo se van a comportar las vistas en diferentes resoluciones
Es importante tener en cuenta cómo se comportará y visualizará nuestra aplicación en cada uno de los tamaños a los que damos soporte.
¿Cómo se adaptarán los textos cuando cambie el tamaño de pantalla? ¿mantendrán su tamaño? ¿aumentarán de manera dinámica? ¿cambiarán el tamaño en base a breakpoints definidos?
Ya que no hay una única aproximación al cambio de tamaño de pantalla, es importante definir su adaptabilidad antes de iniciar del desarrollo para evitar comportamientos indeseados a futuro.
En dispositivos móviles aparecerá el teclado al interactuar con formularios.
Cuando tenemos formularios en una aplicación mobile tenemos que tener en cuenta que el dispositivo desplegará un teclado para que el usuario pueda interactuar con los diferentes campos de los formularios. Cuando esto pasa se puede dar que este teclado ocupe la mitad de la pantalla (incluso más, en dispositivos pequeños).
Es importante definir el comportamiento de nuestra aplicación cuando esto ocurra. ¿El contenido se adaptará al aparecer el teclado? ¿Se empujará el contenido hacia arriba? ¿No modificaremos el contenido en estas situaciones?
No hay una solución correcta para esta casuística. Sin embargo prever este comportamiento nos ahorrará tiempo de desarrollo.
Conclusión: La importancia del flujo de desarrollo
Si lo hubiésemos previsto, haber definido el comportamiento de validación de un formulario nos hubiese llevado no más de 5 minutos. Cambiarlo a posteriori costará unas cuantas horas.
Puede que haya casos no tan flagrante. Sin embargo, el coste de cambiar el comportamiento de una aplicación cuando ya tenemos una funcionalidad desarrollada supone una perdida de tiempo, recursos y, por qué no decirlo, un incremento de nuestra frustración.
Tener detectadas las situaciones anteriores (seguro que se os ocurren unas cuantas más) nos ayudará enormemente agilizar el proceso de desarrollo, abaratando tiempos y, por consiguiente, costes.
¿Queréis mas tips con los que mejorar vuestro desarrollo? Podéis darle un vistazo a más artículos de desarrolladores para desarrolladores aquí.
