Etiqueta: teoría

Uso de hints en las interfaces de usuario

Publicado el

Al diseñar una interfaz de usuario la mahyor parte del peso de comunicación entre la interfaz y el usuario es a través del canal visual. Mediante un vistazo a una pantalla se puede intuir cómo utilizar ciertos elementos de la interfaz. Pero como no todas las personas tienen la misma capacidad de intuición ni la misma posibilidad de echar un vistazo a la pantalla debemos hacer uso de los distintos elementos de accesibilidad para hacer que la misma interfaz de usuario sea comprensible y usable para todas las personas.
A veces el uso de un control sólo se puede entender de forma visual como puede ser un interruptor deslizante para seleccionar un elemento más a la izquierda o más a la derecha, un botón de 3 estados o un cuadro de edición auto completable que permite realizar ciertas operaciones mientras se edita ese campo. En todos esos casos las personas con discapacidad visual pueden encontrar problemas a la hora de entender cómo utilizar dicho control. Para ayudar a este perfil de usuario la capa de accesibilidad permite incluir al control un texto de ayuda para entender cómo utilizar el control. Es lo que se conoce como hint o pista.

¿Qué son los Hints de Accesibilidad?

Los hints de accesibilidad son textos adicionales que proporcionan información contextual sobre un control de interfaz. Para los usuarios de lectores de pantalla. Estos hints pueden ser la diferencia entre una experiencia fluida y una frustrante. Por ejemplo, en una aplicación de banca móvil, un botón que simplemente dice «Enviar» podría no ser suficiente. Un hint podría agregar: «Enviar transferencia bancaria», proporcionando un contexto claro y específico.
Otro ejemplo podría ser un botón de tres estados cuyo hint podría indicar «pulse este botón para cambiar entre aceptado, pendiente y rechazado para actualizar el estado del pedido».

Implementación de Hints en Diferentes Plataformas

iOS

En iOS, los hints de accesibilidad se implementan utilizando el atributo accessibilityHint. Este atributo permite a los desarrolladores definir una cadena de texto que será leída por VoiceOver, el lector de pantallas de Apple, al final de toda la información del control.

Por ejemplo, un botón que tiene un icono de lápiz para editar puede no ser claro para todos los usuarios, pero al añadir un AccessibilitHint con el valor «Pulsa dos veces para modificar el valor de este campo»”, se proporciona la información necesaria para el usuario.

Android

En Android, los hints de accesibilidad se consiguen con el atributo android:hint en el fichero XML de la actividad. Este hint proporciona una descripción de lo que un control hace o lo que se espera que el usuario haga con él. Por ejemplo, un campo de entrada de texto puede tener un hint como “Introduce tu nombre completo”, lo cual es leído por TalkBack (el lector de pantalla de Android) para guiar al usuario.

HTML

En HTML, los hints se implementan con los atributos aria-description y aria-describedby.

El atributo aria-description proporciona una descripción directa del elemento, mientras que aria-describedby hace referencia a otro elemento en la página que contiene una descripción más detallada. Por ejemplo, un botón de búsqueda podría tener un aria-description=»Use este botón para buscar en todo el sitio web», y aria-describedby podría apuntar a un párrafo cercano al campo de búsqueda que explique cómo funciona la búsqueda en el sitio web.

Importancia de los Hints en la Accesibilidad

Estos atributos impactan en la accesibilidad de la interfaz de la siguiente forma:

  1. Claridad y Contexto: Los hints proporcionan información adicional que ayuda a los usuarios a entender la función de un control. Esto es especialmente importante para controles que solo tienen iconos o textos ambiguos.
  2. Mejora de la Usabilidad: Al proporcionar instrucciones claras sobre cómo utilizar un control, se mejora la usabilidad de la aplicación o sitio web, haciendo que la experiencia sea más intuitiva y menos frustrante para los usuarios con discapacidades visuales.
  3. Inclusión: Al implementar hints de accesibilidad, los desarrolladores están tomando pasos activos hacia la inclusión digital, asegurándose de que sus productos sean utilizables por el mayor número posible de personas.

Problemas Comunes con los Hints

A pesar de su importancia, los hints de accesibilidad no están exentos de problemas. Algunos de los desafíos más comunes incluyen:

  1. Hints Redundantes: A veces, los desarrolladores añaden hints que repiten información que ya está clara en el contexto visual, lo que puede resultar en una sobrecarga de información para el usuario de un lector de pantalla. Por ejemplo, un botón con un texto visible “Buscar” no necesita un hint adicional que diga “Botón de búsqueda”.
  2. Falta de Actualización: Los hints pueden volverse obsoletos si no se actualizan junto con cambios en la interfaz. Esto puede llevar a confusión si un hint describe una funcionalidad que ya no existe o que ha cambiado.
  3. Hints Incompletos: No proporcionar suficiente información es otro problema. Un hint demasiado breve puede no dar el contexto necesario. Por ejemplo, un hint que solo dice “Enviar” sin más detalles podría no ser útil en una aplicación con múltiples funcionalidades de envío.
  4. Uso Incorrecto de los Atributos: En HTML, confundir aria-description con aria-describedby puede llevar a que los usuarios de lectores de pantalla no reciban la información adecuada. Es crucial usar cada atributo de forma correcta para asegurarse de que la información se transmite adecuadamente.
  5. Problemas de personalización del lector de pantallas: algunos usuarios ciegos deshabilitan la lectura de estos elementos para dar mayor agilidad a su experiencia de uso. Esto implica que en el hint sólo se debe incluir la información relacionada con el control para evitar que el usuario pierda información vital de otra parte de la interfaz.

Buenas Prácticas para el Uso de Hints

Para maximizar la efectividad de los hints de accesibilidad, es importante seguir algunas buenas prácticas:

  1. Ser Claro y Conciso: Proporcionar descripciones claras y directas que sean fáciles de entender. Evitar la jerga técnica y centrarse en el propósito del control.
  2. Actualizar Regularmente: Asegurarse de que los hints se actualizan junto con cualquier cambio en la interfaz de usuario para evitar descripciones obsoletas.
  3. Consistencia: Mantener una terminología y un estilo consistentes en todos los hints para evitar confusión.
  4. Seguir los estilos definidos en la guía de interfaces del fabricante: Apple y Google tienen recomendaciones sobre el estilo de lenguaje a emplear en los hints.

Regla YAGNI – You aren’t gonna need it

Publicado el

La última de las 5 reglas para escribir software simple y robusto es la regla de YAGNI. Su acrónimo traducido dice: no lo vas a necesitar.

En muchas ocasiones cometemos el error de hacer sobreingeniería en un proyecto. Esto significa que el cliente nos ha pedido una calculadora para hacer sumas y terminamos desarrollando una hoja de cálculo con soporte para funciones y un lenguaje propio de scripting. Esto provoca que el mantenimiento y el esfuerzo para desarrollar y mantener el proyecto se ha sobredimensionado de forma incontrolada e innecesaria.

Para evitar caer en este código innecesario o código YAGNI debemos centrarnos en los requerimientos del producto final, no desarrollar código que no se esté utilizando en el proyecto, eliminar el código comentado (Si está comentado es que no es necesario) y utilizar ciertos patrones de trabajo como TDD (Test Driven Development) o trabajar con PullRequests pequeñas enfocadas en aspectos muy específicos de un requerimiento o característica del proyecto. También realizar procesos de refactorización del código al terminar un plazo de entrega o el desarrollo de un módulo facilita la desaparición de código YAGNI.

Regla SOC – Separation of concerns

Publicado el

Dentro de las reglas para escribir software simple y robusto tenemos la regla de SOC cuyo acrónimo significa Separation of concerns. Esto se traduce como separación de intereses. Este término de ingeniería fue creado por Edsger Dijkstra en un artículo para indicar la necesidad de centrar la atención en aspectos específicos dentro de las distintas estructuras de manipulación de la información dentro del software. Esta separación de intereses dentro del software se puede aplicar a nivel de arquitectura del proyecto y a nivel de codificación de los métodos y funciones.

Arquitectura de intereses

A nivel de arquitectura debemos agrupar los distintos intereses dentro de módulos o microservicios. Cada módulo o servicio deberá encargarse de un aspecto del proyecto.

Se busca que cada módulo o microservicio sea independiente y tengan claras sus responsabilidades.

Dentro de la modularización del código se aplican patrones de diseño como MVC (Modelo vista controlador), MVP (Modelo vista presentador) y patrones de diseño similares. Esta forma de organizar el código nos permite diferenciar cláramente las clases relacionadas con el modelo de datos, la interfaz de usuario y la forma de presentar y manipular los datos en la interfaz de usuario. 

Aplicando estos patrones de diseño a la hora de modularizar nuestro código podremos realizar modificaciones en la interfaz de usuario sin necesidad de afectar al modelo de datos o a la lógica de negocio ya que las responsabilidades de cada parte del módulo están conceptualmente definidas.

Separación del código por intereses

Para separar el código por intereses se debe realizar un ejercicio de análisis observando desde el punto más alto de abstracción de nuestro proyecto, tanto en funcionalidad como en la información que se manipula, hasta delimitar la responsabilidad y relación entre las distintas clases y módulos del proyecto.

Con este esfuerzo se busca obtener las siguientes ventajas: eliminar la posible duplicación en la lógica de negocio, ampliar la capacidad de mantenimiento del proyecto, incremento de la cohesión entre clases y reducción del acoplamiento entre clases y módulos.

Una vez realizado este análisis se aplican distintos paradigmas de programación como la programación orientada a aspectos, arquitectura hexagonal, inyección de dependencias y la separación de métodos por responsabilidad.

Regla LOD – Law of Demeter

Publicado el

Una de las reglas para escribir software simple y robusto que también podemos aplicar a otros aspectos de la vida es la regla de Demeter. Esto es lo que significa LOD: law of Demeter.

Esta regla se resume en el concepto de: no hables con desconocidos.

Dentro de la ingeniería de software esta regla representa al principio del mínimo conocimiento.

Este principio nos dice que una función o método X perteneciente a un objeto Y sólo puede llamar a otros métodos o funciones pertenecientes al objeto, un parámetro del método X, cualquier objeto creado dentro del método X o cualquier propiedad definida dentro del método X.

Esto establece que la comunicación del método X se limita al dominio de su objeto contenedor o al propio dominio del método X.

De forma más comprensible este principio nos permite escribir un método de forma que cualquier información que el método necesite consultar o manipular estará dentro del propio código del método o dentro del código de la clase que lo contiene. De esta forma podemos detectar fácilmente posibles errores o seguir el movimiento de la información que manipula ese método.

Regla KISS – Keep it super simple

Publicado el

Otra de las reglas para escribir software simple y robusto es la regla KISS.

El acrónimo de KISS significa Keep it super simple (manténlo super simple). 

Esta regla indica que la mayoría de las aplicaciones funcionan mejor si se mantienen simples en lugar de complicadas; Esta regla busca que la simplicidad debe ser un objetivo clave en el diseño y se debe evitar la complejidad innecesaria.

Algunas soluciones para seguir esta regla es aplicar código limpio y utilizar algunos paradigmas para abordar la resolución de problemas como pueden ser el de divide y vencerás y las reglas de programación SOLID.

Siguiendo la regla de KISS crearemos un software estructurado en clases y módulos simples donde sea fácil localizar cada dato y función.

Regla DRY – Don’t repeat yourself

Publicado el

En el artículo sobre reglas para escribir software simple y robusto hablamos de 5 reglas para mantener la simplicidad. Una de estas cinco reglas y la más fácil de entender es la regla DRY cuyo acrónimo significa Don’t repeat yourself (No te repitas a ti mismo). Esta regla aparece por primera vez en el libro The pragmatic programmer.

Esta regla implica que cada pieza de conocimiento debe tener una representación única dentro del proyecto. Esto implica que no se deben repetir partes como la lógica de negocio en distintas partes del proyecto.

Esto reduce el código repetido en el proyecto y hace que nuestras clases y módulos sean más reutilizables.

Si no seguimos esta regla y tenemos elementos repetidos para hacer algún proceso del modelo de negocio, el día que tengamos que actualizar esa función o proceso deberemos invertir tiempo en localizar todas las partes donde se repite dicho proceso y actualizar el código.