Curso de html

De WikiEducator
Saltar a: navegación, buscar



UX: Experiencia de usuario o usabilidad

Accesibilidad, usabilidad y estándar W3C

Usabilidad

  • Facilidad de navegación por la web para el usuario final.
  • Usuario medio (sin ningún tipo de curso especializado) y con un equipo medio.
  • Objetivos:
Presentación de la información de forma clara y concisa
Menus, opciones y botones con funcionalidad clara y sin ambigüedad
Colocación de la información importante en un área apropiada de la web

Accesibilidad

  • Se intenta garantizar una experiencia de usuario similar para personas con discapacidades.
  • WAI (Web Accesibility Initiative)
  • Uso habitual en organismos públicos, como en la web del Ayuntamiento de Zaragoza

Niveles de conformidad

  • Nivel A
    • Imágenes con texto alternativo (alt)
El atributo alt es bueno para el SEO
Uso inapropiado: 
<img src=“menswatches.jpg” alt=“”>
Uso habitual: 
<img src=“menswatches.jpg” alt=“menswatches”>
Uso adecuado: 
<img src=“menswatches.jpg” alt=“Rolex Yacht Master watches for men”>
  • Contenido multimedia: Se proporciona contenido descriptivo alternativo
  • El contenido debe tener un orden de lectura no dependiente del diseño o estilos
  • El contenido no debe depender de colores y debe ser fácilmente distinguible del fondo
  • Las funcionalidades de la pagina deben ser accesibles desde el teclado.
Ejemplo de página con acceso desde el teclado
Utilizar AccessKeys es fácil 
<div id="navigation"> 
<a href="index.html" accesskey="q">Home</a> |  
<a href="about.html">About Foos</a> |  
<a href="buy.html">Buy Foos</a> |  
<a href="sitemap.html">Site Map</a> |  
<a href="feedback.html">Feedback</a> |  
<a href="access.html">Accesskey Details</a> 
</div>
<div id="navigation"> 
<a href="index.html" accesskey="h">Home</a> |  
<a href="about.html" accesskey="1">About Foos</a> |  
<a href="buy.html" accesskey="2">Buy Foos</a> |  
<a href="sitemap.html" accesskey="3">Site Map</a> |  
<a href="feedback.html" accesskey="4">Feedback</a> |  
<a href="access.html" accesskey="k">Accesskey Details</a> 
</div>
  • Sin más de 3 destellos o cambios de imagen por segundo
  • Títulos descriptivos en cada pagina
  • Sistema para saltar de bloques de contenido y navegación secuencial
  • Nivel AA
    • Debe cumplir las pautas del nivel A
    • Subtítulos para el contenido multimedia con audio
    • Contenido alternativo descriptivo para contenido multimedia con vídeo
    • Contraste alto entre fondo y texto (al menos 4,5:1)
    • Se puede variar tamaño de fuente hasta un 200% sin perdida de funcionalidad
    • Encabezados descriptivos
    • Al menos dos formas distintas para navegar por el site
    • En los envíos de información confidencial debe existir un sistema para corregir, retroceder o advertencia de error y que te permita corregirlo.
  • Nivel AAA
    • Debe cumplir con las pautas del nivel A y AA
    • Lenguaje de signos para el contenido multimedia con audio
    • Descripción completa para el contenido multimedia con vídeo
    • Contraste muy alto entre fondo y texto (al menos 7,1:1)
    • Contenidos multimedia sin audio de fondo (sólo locución principal)
    • La pagina debe poseer un sistema para que el usuario pueda cambiar los colores de texto y fondo, limitar las lineas a 80 caracteres, alto de linea y tamaño de fuente. Todo ello sin que sea necesario utilizar el scroll horizontal para poder ver todo el contenido
    • Las imágenes con texto sólo pueden utilizarse para decorar.
    • Las funcionalidades de la pagina deben ser accesibles desde el teclado sin ningún tipo de excepción
    • Reanudación de sesión: Cuando un expira la sesión el usuario puede volver a reanudar sesión sin perdida de datos
    • Se proporciona al usuario información sobre su situación en la pagina
    • Texto descriptivo sobre el destino de cada enlace
    • Encabezados en cada sección
    • Definir el idioma de la pagina
    • En todos los envíos de información sistema debe existir un sistema para corregir, retroceder o advertencia de error y que te permita corregirlo

Uso de estándares

  • Iniciativa de la W3C
  • Las metas son compatibilidad entre plataformas (uso de esándares web abiertos) y tamaño de ficheros compacto.
  • Ejemplo: separación de contenido (html) y presentación (css).
  • Una web que cumple los estándares no tiene porque ser una web con buena usabilidad o accesibilidad.

Compromisos entre uso de estándares, usabilidad y accesibilidad

  • Aunque están muy relacionados, no siempre van de la mano. Veamos algunos casos y sus posibles soluciones:

Color

  • Herramienta visual básica para el diseño Web
  • El 10% de las personas presentan algún tipo de deficiencia visual y no pueden distinguir ciertos colores (especialmente rojo y verde).
  • Se puede sustituir parcialmente el uso de distintos colores con el uso de iconos y distintos tipos de texto en la codificación de la Web.
  • Herramienta para ver lo legible que es tu combinación de colores

Siglas, acrónimos y abreviaturas

  • Cuando las siglas se utilizan como si fuera una palabra, estamos hablando de acrónimos.
  • Ejemplo: RENFE REd Nacional de Ferrocarriles Españoles
  • Cuando las siglas se leen como la palabra que representan, hablamos de abreviaturas.
Ej: Sr
  • Los lectores de pantalla no siempre las reconocen: HTML, PDF, NaCl, SiteMap...

</div>

Imágenes y sonidos

Navegación repetitiva o excesiva

Diseño con varias columnas

  • Reducir la anchura de las líneas ayuda a la legibilidad del texto y nos permite tener más información en la pantalla.
  • Puede resultar también un inconveniente para un screen reader
  • Se pueden usar layouts de css con una sola columna y fijando su max-width para que no sea muy ancha.
  • En caso de que usemos tablas de datos, debemos indicar cabecera, títulos, etc, para que su lectura sea comprensible desde un screen reader ver ejemplo.

Herramientas de usabilidad

Eye tracking

  • Tecnologías que permiten registrar la forma en la que una persona mira una escena o imagen, en qué áreas fija su atención, durante cuánto tiempo y qué orden sigue en su exploración visual.
  • Conocer los puntos calientes en los que el usuario fija inicialmente la mirada, ayudan a estructurar los contenidos en una web.
  • Cuanto mas arriba y a la izquierda, más se verá. Cuanto más abajo a la derecha, menos relevancia visual tendrá.
  • Pruebas con grupo de al menos 5 usuarios. Se analizan las pruebas, se realizan cambios y se vuelve a probar.
  • Herramientas específicas eye tracking:
Crazyegg
Seevolution
Click Heat (Software libre)
  • Observar sesión del cliente:
Silverback (Solo MacOS)
Multiplataforma
Team Viewer

Diseños preliminares: del boceto al prototipo

Sketch o borrador de un sitio web
  • El prototipo es la mejor forma de aproximarse a la comprensión y concepción del producto final (en este caso un sitio y/o páginas web).
  • Es útil ver y porque no, COPIAR de la competencia, que algo harán bien.
  • Listado de herramientas

Elaboración de prototipo mediante lápiz y papel

  • Sketch o boceto:
Papel y lápiz.
Se recogen ideas
Se prueban composiciones
  • Wireframe
Funcionalidad y especificaciones
Layout, menús de navegación...
Sin tipografía, colores ni otros aspectos visuales
Anotaciones sobre la funcionalidad que se espera
  • Mockup
Incorporamos el look&feel
  • Prototipo
Se prueba el diseño final
Tiene funcionalidad (normalmente reducida)

Diseños preliminares:presupuesto Web

Es fundamental la elaboración de algún boceto a la hora de dar un presupuesto final de un proyecto web a un cliente. 2 casos:

  • Aplicación funcional
El boceto debe representar bien los requerimientos del cliente. Un boceto en papel puede ser suficiente.
Utilizaremos alguna herramienta informática para buscar resultados más vistosos de cara al cliente:
Balsamiq Mockup (de pago)
Pencil (gratuito, multiplataforma)
  • Página Web centrada en el diseño
Uso de programas tipo Inkscape, Photoshop o Gimp.
Cada diseño es único y lleva su tiempo. Enseñar portfolio al cliente.
  • Calculo del presupuesto Web
¿Algún tipo de clasificación por tipo de trabajo?
¿Cálculo por horas? ¿Y cómo se calculan las horas que cuesta?
Ejemplo de cálculo

Instalación de Balsamiq Mockup en Ubuntu 12.04

  • Han dejado de dar soporte Adobe-air para Linux: Versión actual 2.6. Versiones Windows y Mac 3.1 o posterior.
  • Proceso de instalación de Adobe-air (documentación original):
Lo primero será instalar algunas dependencias: 
$ sudo apt-get install libhal-storage1 libgnome-keyring0 lib32nss-mdns
Descargar e instalar getlibs, para poder utilizar las librerías 32 bits: 
$ wget http://ubuntuguide.net/wp-content/uploads/2012/06/getlibs-all.deb
$ sudo dpkg -i getlibs-all.deb
Una vez instalado, vamos a proceder a instalar las librerías necesarias, que son dos, libhal-storage: 
$ sudo getlibs -l libhal-storage.so.1
$ sudo getlibs -l libgnome-keyring.so.0.1.1
Ahora enlazamos esta última librería para que entre en funcionamiento: 
$ sudo ln -s /usr/lib/i386-linux-gnu/libgnome-keyring.so.0 /usr/lib/libgnome-keyring.so.0
Ya pasamos a descargar e instalar Adobe Air, la versión 2.6: 
$ wget http://airdownload.adobe.com/air/lin/download/2.6/AdobeAIRInstaller.bin
$ sudo chmod +x AdobeAIRInstaller.bin
$ sudo ./AdobeAIRInstaller.bin
Ahora podemos eliminar archivos descargados que ya son innecesarios: 
$ sudo rm AdobeAIRInstaller.bin && sudo rm getlibs-all.deb
  • Por fin, ahora sí, instalamos balsamiq Mockup:
Descargamos el .deb eligiendo la versión adecuada
Lo ejecutamos, se cargará el centro de software y le damos a instalar :-)

Buenas prácticas para acelerar la carga de una web

  • El tiempo de carga y la performance de una página web es muy importante para la experiencia de usuario (UX).
  • Si tu web es lenta, no solo pierdes visitas, sino potenciales clientes.
  • Buscadores como Google tienen en cuanta la velocidad de carga de las webs para sus ranking de búsqueda.
  • ¡Cada milisegundo es importante!

Minimizar los HTTP Request

  • Se cumple la regla del 80/20
  • Según los estudios realizados por Yahoo! el tiempo de carga de una página media depende en un 80% de la parte del cliente y en un 20% de la parte del servidor. Los navegadores de los usuarios dedican la mayor parte del tiempo a descargar imágenes, archivos JavaScript, hojas de estilos CSS y otros recursos externos.
  • Por este motivo, las mejoras en la parte del cliente generan muchos más beneficios que las mejoras en la parte del servidor.

Imágenes

  • Uso de sprites (y también image maps para imágenes contiguas). Ver ejercicios.
  • Elección del tamaño adecuado de las imágenes: el html no debe escalar la imagen.
  • Podemos usar programas como Shrink O’Matic o ImageMagick para generar distintas versiones de nuestras imágenes.
  • Uso de atributos: texto alternativo (alt), título de la imagen (title) y width y height.
  • Elige el formato correcto de las imágenes: JPG para imágenes grandes y llenas de colores. GIF y PNG para el resto. Más información
  • Nombres de ficheros de imágenes descriptivos (SEO) y en la medida de lo posible con links (al usuario le gustan y a google también).
  • HAZ DE LA OPTIMIZACIÓN DE IMÁGENES UN HÁBITO. 
<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU5ErkJggg==" alt="Red dot">
div.menu {
    background-image: url('elephant.png');
    background-image:  url('data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAQMAAAAlPW0iAAAABlBMVEUAAAD///+l2Z/dAAAAM0lEQVR4nGP4/5/h/1+G/58ZDrAz3D/McH8yw83NDDeNGe4Ug9C9zwz3gVLMDA/A6P9/AFGGFyjOXZtQAAAAAElFTk
                           SuQmCC');
}

Uso de CDN

  • Es importante la proximidad del servidor web al usuario
  • Un CDN propio es una solución cara. Necesitamos clientes globales para que tenga sentido.
  • Con clientes locales será importante escoger un servidor web con un buen tiempo de respuesta: pocos saltos de red, cercano.
  • Un CDN es sencillo de implementar, pero si nuestra aplicación tiene escrituras a BBDD, el diseño de la arquitectura distribuida puede ser muy complejo.

Cabeceras HTTP y cache

  • Los clientes web almacenan en una caché las páginas que van visitando, sus imagenes, css, etc.
  • Los servidores web indican el tiempo que tiene que estar almacenado en la cache mediante alguna de las siguientes cabeceras:
    • Last Modified
    • ETag
    • Expires
    • Max-Age

Más información sobre cada uno de los métodos

Uso de gzip

  • Desde HTTP/1.1 los navegadores pueden indicar en las cabeceras http los formatos de compresión que soportan: 
Accept-Encoding: gzip, deflate
  • El servidor web lee dicho header y en función de su configuración, mandará comprimida la página web, indicándolo también en los http headers: 
 Content-Encoding: gzip
  • Normalmente el servidor web utiliza una política de comprimir ficheros en un función de su extensión.
  • Comprimiremos html. También podemos comprimir css, js, xml o json. Las imágenes y pdf's no se comprimen.
  • La compresión de los ficheros suele ser de un 70%.
  • Más información

Colocación de hojas de estilos en la parte superior

  • Las páginas web se deben renderizar de forma progresiva: sirven al usuario para darle un indicador de progreso de carga.
  • Muchos navegadores no renderizan las páginas hasta que no leen todos los css:
    • Así se evitan las penalizaciones en tiempo de ejecutar varios render
    • El usuario mientras tanto ve una página en blanco.
  • Los @import se comportan como los <link> al final de la página en IE, por lo que debemos usar mejor <link>.
  • Se deben evitar expresiones CSS (se utilizaban bastante en IE hasta la versión 8): 
background-color: expression( (new Date()).getHours()%2 ? "#B8D4FF" : "#F08A00" );
  • Resumiendo... los css siempre en el head y antes de cualquier javascript.

Colocación de scripts en la parte inferior

  • La especificación HTTP/1.1 sugiere que los navegadores no deben descargar más de 2 ficheros de un mismo host de forma simultánea.
  • Cuando las descargas son scripts, se hacen de una en una
  • ¡No siempre se pueden llevar a la parte inferior!

Utilizar JavaScript y CSS externos

  • Si los CSS o JavaScript se utilizan en varias páginas mejor externos
  • El html ocupará menos y los otros ficheros estarán cacheados entre páginas de la web y no consumirán un http request
  • Es negativo para visitantes de una sola página.
  • El mantenimiento es más sencillo, así como la reusabilidad del código.

Reducir peticiones DNS

  • Si utilizamos varios hosts, permitimos descargas simultáneas
  • Si utilizamos varios hosts podemos provocar penalizaciones por búsqueda en dns
  • Los sistemas operativos y los navegadores realizan caches de dns


Uso de versiones minified de JavaScript y CSS

java -jar yuicompressor-x.y.z.jar myfile.js -o myfile-min.js


Contenido de la web

  • No juzgues un libro por su portada
  • En una web, si la primera pantalla "no gusta" el usuario no seguirá
  • Intenta "cortar elementos" si la página tiene scroll para que el usuario lo perciba
  • Utiliza la 3ª regla de Krug:
Reglas de Krug:
1.“Don’t make me think.”
2. “It doesn’t matter how many times I have to click, as long as each click is a mindless, unambiguous choice.”
3. “Get rid of half the words on each page, then get rid of half of what is left.”

</div>

Obtenido de «https://es.wikieducator.org/index.php?title=Usuario:Juanda/html/presupuestos&oldid=14032»