Usabilidad Web

AUTOR

 Ingeniero informático, músico compositor, filantropo, escritor y profesor.

A la edad de 14 años descubri mi vocacion casi por accidente y, un año mas tarde, empece a programar de forma autodidacta. Pocos años despues, en 1992, realice un sofware de aprendizaje de cardiologia para los estudiantes de la Universidad Complutense de Medicina de Madrid mientras continuaba formandome como profesional. Posteriormente estuve dando clases a jovenes en la academia Santillana, trabajando como Administrador de Sistemas y como Técnico de reparación de ordenadores hasta que en 1996, empece la Ingeneria Técnica de Sistemas Informáticos

PREFACIO 

Cuando se habla de usabilidad, se esta hablando de experencia de usuario(UX) ya que es una de las partes o elementos que forman el conglomerado que dan sentido al termino. En la experencia de usuario, todos los elementos interactuan con los usuarios proporcionando un conocimiento emocional sobre ellos ya a ese proceso se le denomina experencia de usuario. 

De todas esas partes que intervienen, la usabilidad es una de las que destaca ya que puede marcar la diferencia entre el exito o el fracaso. Tanto es asi que Rex Hartson en 1998 afirmo, "para la mayoria de los usuarios, la parte que ven y con la que interactuan(la interfaz) es la parte que decide su uso, la interfaz, es lo que define el exito o el fracaso de un producto.


                                                            


6. DISEÑO CENTRADO EN LA USABILIDAD

"Me esfuerzo por dos cosas en l diseño:simplicidad y claridad . El gran diseño nace de esas dos cosas"    
Lindon  Leader


Por norma general los usuarios ojean velozmente, dicho de otra manera, realizan un barrido rápido de los documentos on-line, leyendo palabras y frases sueltas. Esta afirmación supone el 79% de los usuarios de Internet. Solo el 16% leen detalladamente los contenidos mostrados.

En usabilidad cada información compite con el resto por llamar la atención del usuario, con lo que cualquier elemento irrelevante distraerá la atención del documento. Durante el primer barrido rápido se ignoran las áreas de navegación, gráficos y otros elementos de diseño global ya que se suelen centrar en las áreas de contenido.

6.1 LA ARQUICTECTURA

La arquitectura cliente-servidor, también llamada sistema software, esta formada por un navegador(que funciona como cliente realizando peticiones), un servidor(que recibe las peticiones y responde al navegador) y un protocolo HTTP(que se utiliza como una via de comunicación entre ellos).

En la arquitectura cliente-servidor, uno de los modelos de desarrollo que mas se utilizan es la "programación por capas" y que se compone de una capa de presentación, una capa de negocio, una capa de datos y un "algo" que lo interconecta todo. Como se realice esta interconexion es lo que definira la usabilidad del sistema.

Para que una arquictectura sea usable debe cumplir una serie de requisitos:

Tener una estructura consistente y bien organizada.

Establecer un unico tipo de documento SGML y un unico formato de codificacion de caracteres.

Ser facil de desarrollar y mantener.

Ser semantica, es decir, ser capaz de dotar de significado los contenidos.

Gestionar de forma optima los sistemas de almacenamiento como la memoria cache o las sesiones.

Establecer un tiempo de comunicacion entre capas no superiores a 1000 ms

Si se cumplen todos estos requerimientos, se podra asegurar que la eleccion de la arquictectura es usable.

6.1.1 Hojas de estilo

Las hojas de estilo(CSS), técnicamente, son un documento que define el estilo de una aplicacion o pagina web.

Las hojas de estilo se deben colocar al principio del documento, dentro del elemento contenedor de metadatos HEAD.

En entornos de Desarrollo, es muy frecuente que las interfaces tengan varias fuentes de Código CSS. En este tipo de entornos, deben primar la facilidad de mantenimiento y , su distribución en varios archivos pueden ser una buena idea.

Sin embargo, en entornos de Producción se deben agrupar todos los estilos en un único documento y eliminar todos  los caracteres y símbolos que sean innecesarios(minificacion). El resultado de esta concentración y minificacion puede aumentar la velocidad de carga de forma considerable.

Se debe proporcionar una programacion compatible con el mayor numero de navegadores posibles(programación Cross Browser) a traves de:

La definicion de las pseudo-clases adecuadas para los estados especiales de cada elemento.

Establecimiento de todos los prefijos de los proveedores necesarios como - moz, -webkit, -ms-,..) Estos prefijos ayudaran a la compatibilidad regresiva o retrocompatibilidad y aseguraran su buen funcionamiento.

Tratar de utilizat medidas relativas en vez de medidas absolutas. Las unidades absolutas no funcionan correctamente en todas las resoluciones ni son accesibles. Por esta razon, en vez de pixeles o puntos, se debe utilizar porcentajes o unidades relativas al tamaño de la letra" M".

Es importante averiguar si los usuarios que van a acceder a la interfaz o sistemas son invidentes. Si es así, se deben utilizar las propiedades auditivas de CSS para que las tecnologías asistidas pueden usarlas en beneficio de los usuarios. Si ademas de utilizar las propiedades adecuadas, se definen los selectores, clases e identificadores con una sintaxis acorde a la funcionalidad asociada, se conseguirá facilitar el mantenimiento.

Por ultimo, no se deben cambiar las funcionalidades basicas predefinidas a las están acostumbrados los usuarios. Esta practica puede no ser una gran idea ya que les podria provocar confusión. Un ejemplo clasificador podria ser cambiar el subrayado de los enlaces y hacerles parecer texto normal. LA confusion que provocaría a los usuarios seria tal que, probablemente, rechazarían su uso y abandonarían el sistema.

6.1.2 JavaScritp

Los archivos de JavaScript deben colocarse dentro del elemento BODY, al final de este. Los navegadores renderizan los contenidos según van llegando, de tal manera que, si encuentra una petición de un archivo de JavaScript, debe esperar a que sea cargado para continuar renderizando. El que los script estén al principio, y no al final, es una de las razones por las que las paginas adquieren un tiempo de latencia elevado.

En entornos de Desarrollo, es habitual que las interfaces tengan varias fuentes de código JavaScript. En este tipo de entornos, debe pimar la facilidad de mantenimiento, por lo que lo es bueno que se quede asi. Sin embargo, en entornos de Producción se deben concentrar todos los archivos JS en un único archivo. Si ademas de agrupar todos los archivos JS en un único documento, se minifica dicho archivo, la velocidad de carga de la pagina aumenta de forma considerable.

Crear comportamientos en JavaScript es bastante mas costoso a nivel de procesador que realizarlos en CSS o SVG. Por este motivo, si el desarrollo que se desea realizar en JavaScript puede hacerse desde CSS o SVG, no se debe utilizar JavaScript.

Se debe  proporcionar una programación compatible con el mayor numero de navegadores posibles(programacion Cross Browser) a traves de:

Utilizacion de la version mas actual que se pueda. Por ejemplo, si la interfaz va dirigida a un uso bajo Internet Explorer 8, se debe utilizar ECMA Script v4. Si va dirigido a usuarios con Internet Explorer 11, la version compatible sera la 5.1.

Un uso limitado y optimo de los plugins, librerias o frameworks, Añaden  otra capa de complejidad al sistema y pueden ralentizar el sistema.

Enviar, en la medida de lo posible, el uso de variables globales. Estas, provocan que el riesgo de colision aumente y que la mantenibilidad sea mas compleja.
 
6.1.3  Metadatos

Un metadato es un termino que se refiere a datos sobre los propios datos. Los metadatos son una informacion que no se visualiza y que pueden ser usados para clasificar, recopilar datos o configurar los contenidos de la pagina.

Existen multitud de tipos de metadatos que estan enfocados a proporcionar una informacion.

 

6.1.4 Bases de datos 
Las bases de datos son unas de "esas cosas" que más pueden influir en e rendimiento de las interfaces o los sistemas.El tiempo de latencia, en este contexto puede ser muy elevado si se realiza una mala gestión de los join entre tablas durante las consultas, si existe una carencia de índices, una mala configuración de la caché, etcétera 
No importa el Sistema Gestor Base de Datos (SGBD) utilizado, ni tampoco el motor de almacenamiento elegido, lo realmente importante es que se encuentre bien configurado y optimizado, de acuerdo al contexto físico de la infraestructura 

Que un SGBD este correctamente configurado dependera mucho del tamaño  de la cache, numero de consultas frecuentes cacheadas, numero de tablas abiertas, numero de conexiones, etcetera. Algunos gestores (como Oracle ) van mejorando el rendimiento automaticamente segun pasa el tiempo y otros (como MySQL) deben optimizar manualmente.

Subir el valor del tamaño de la cache puede mejorar enormemente los tiempos de respuesta, sin embargo, estos puede ser insuficiente si no se ajusta, ademas, el tamaño de las consultas que pueden almacenar en cache. Este ajuste es porque, si las consultas tienen muchos resultados podria llenarse y no dejar que se almacen las mas utilizadas.

Los errores de cotejamiento de datos (que convive distintas codificaciones como son ISO y UTF-8) en bases de datos pueden provocar tambien  problemas en el proceso  de insercion y actualizacion . Por este motivo , es importante que toda la interfaz y sus base de datos utilicen el mismo tipo de codificacion.

Sin embargo, no todos los problemas de rendimiento residen en la configuracion ya que, como se realicen las consultas puede producir que los tiempos de repuesta se vuelvan muy altos y pasar a formar parte del grupo que denominan " Slow Queries" o "Consultas lentas", Una consulta lenta es una peticion a la base de datos que tarda mas tiempo de lo permitido o estimado. En usabilidad se utiliza el principio de tiempo de reaccion como punto de partida, en otras palabras, que una consulta no debe tardar mas de tres segundos en devolver una respuesta y mostrarla en pantalla.

Una de las vias para conseguir que las queries no sean lentas es establecer las condiciones de filtrado en orden descendente de restriccion. Se debe empezar por la condicion mas restrictiva e ir añadiendo condiciones menos restrictivas para no requerir mas memoria de la necesaria.

Para medir como de optimizado esta un sistema se pueden hace estres. El problema es que, solo teniendo en cuenta el procesador , la memoria y la cache, el numero de transacciones por segundo puede variar  mucho. Eso si,si el numero de consultas es muy bajo es probable que haya algun problema con las restricciones, los join, indices o con las claves foraneas.

Tambien se puede mejorar los tiempos de respuesta realizando una asignacion adecuada de claves primarias, indices y claves foraneas.






 
 





No hay comentarios:

Publicar un comentario