¿Son convenientes los botones back to top?

Los botones back to top son aquellos que le permiten al usuario regresar rápidamente a la parte superior de la página luego de haberse desplazado hacia abajo. Su objetivo es que el usuario pueda volver al tope de la página sin tener que realizar el esfuerzo de hacer scroll o swipe hacia arriba varias veces. Esto puede ser muy útil cuando la página tiene mucho contenido (lo que ocurre, por ejemplo, en los sitios web one page o cuando se usa scroll infinito). Este botón puede estar al pie de la página o bien aparecer y quedar en un lugar fijo una vez que ya nos desplazamos cierta cantidad de píxeles hacia abajo. También pueden aparecer en páginas de preguntas frecuentes, debajo de cada respuesta y apuntando de vuelta a la lista de preguntas, para un escaneo más rápido por parte del usuario. Tras presionar el botón, se realiza un desplazamiento automático hacia la parte superior, que puede ser instantáneo o (mejor) tener una rápida transición animada.

Sapiens usa botón back to top pero solo en resoluciones mobile, donde la página se hace más larga verticalmente.

Activiti usa botones back to top en su sección de preguntas frecuentes: al pie de cada respuesta encontramos un enlace para volver a la lista de preguntas. Así, si solo queremos acceder a algunas preguntas y respuestas en particular, no es necesario realizar scroll hacia arriba a cada rato.

Naturalmente, el botón back to top debe implementarse como un enlace interno, es decir, un link que no conduce a otra página, sino a un elemento con identificador dentro de la misma página (<a href=”#identificador”>…).

En los últimos años, este botón se popularizó por una razón sencilla: ahora los sitios web se consumen desde pantallas chicas (teléfonos, tablets), donde el espacio dedicado al contenido se reduce horizontalmente y se expande verticalmente. Por lo tanto, se genera más desplazamiento vertical (la página es más «alta») y parece necesario contar con un botón que nos ahorre el esfuerzo de volver arriba. Sin embargo, muchos señalan motivos para evitar su uso:

  • El botón distrae al usuario del contenido [Jukka Korpela, 2012].
  • Los usuarios con discapacidad visual, que utilizan lectores de pantalla, escucharán el texto asociado al botón como si fuera parte del contenido, lo cual puede ser molesto o bien confuso [Jukka Korpela, 2012].
  • Cada marcador implica un registro nuevo en el historial de navegación. Por lo tanto, al accionar un botón back to top, como todo link interno, se generará una entrada (innecesaria) en el historial[Jukka Korpela, 2012].
  • El experto Jakob Nielsen desaconseja cualquier tipo de links internos, porque su funcionamiento es diferente al que esperan los usuarios (acostumbrados a los links externos). Nielsen solo admite links internos para tres casos: listas en orden alfabético, secciones de preguntas frecuentes y tablas de contenidos.
  • Si el botón back to top es necesario porque la página tiene mucho contenido, entonces el problema es que la página tiene demasiado contenido. Habría que dividirlo en varias páginas.
  • Los teclados y algunos browsers ya traen opciones para subir al tope de la página, además de existir la barra de scroll. ¿Por qué deberíamos agregar otro botón?

Comentarios finales

Si el contenido de la página es necesariamente largo, o está dividido en secciones (por ejemplo, preguntas y respuestas), el botón back to top puede ser una buena opción. En otros casos, su uso no es recomendable. Es importante que el link contenga un texto descriptivo (por ejemplo, «volver arriba» o «volver al principio» en vez de «volver» o «subir») y el ícono de una flecha apuntando hacia arriba.

SVG vs. icon fonts: ¿cuál es la mejor técnica para crear íconos responsivos?

Los íconos constituyen una parte esencial de cualquier interfaz gráfica de usuario, y los sitios web no son la excepción. Todos los días navegamos por páginas que usan íconos para representar ideas o complementar gráficamente lo que expresa el texto. Una característica habitual de los íconos es que se muestran en tamaño pequeño y (a diferencia de, por ejemplo, la fotografía de un paisaje) siguen formas geométricas con contornos bien definidos. Por eso hoy, en una época con incontables resoluciones y densidades de píxeles, ya no es conveniente implementar íconos con PNG: en ese formato, los íconos pierden calidad cuando los agrandamos o achicamos, pudiendo quedar prácticamente irreconocibles. Para generar íconos responsivos necesitamos formatos escalables, y es allí donde se enfrentan SVG y los icon fonts.

SVG, por Scalable Vector Graphics, es un formato de imágenes vectoriales basado en XML, con soporte para interactividad y animación. Icon fonts es una técnica que, a través de la regla @font-face y una tipografía especial, representa caracteres de texto como íconos en la pantalla. Conozcamos las características de cada uno.

Íconos con SVG (Scalable Vector Graphics)

Ventajas

  • Como son gráficos vectoriales, cambian de tamaño sin perder definición en los contornos.
  • Como están implementados en XML, podemos manipular sus partes por separado. Así, es posible crear íconos multicolores. También tenemos mayores posibilidades de animación.
  • Es más correcto en términos de semántica: mientras los icon fonts nos obligan a usar elementos vacíos o pseudoelementos de CSS, los íconos SVG se pueden representar con etiquetas como <img> o <svg>, que fueron hechas especialmente para mostrar imágenes.

Desventajas

  • Para suplir los íconos SVG en browsers que no soportan el formato hay que usar fallbacks (reemplazos) con varios inconvenientes. Por ejemplo, la necesidad de generar un archivo alternativo en PNG.

Íconos con icon fonts

Ventajas

  • Mayor compatibilidad: la regla @font-face es soportada, aunque con limitaciones, incluso en Internet Explorer 6.
  • El color y el tamaño son más fáciles de manipular, ya que se manejan como cualquier texto a través de CSS.
  • El tamaño de archivo es menor que en SVG, y las fuentes son almacenadas en caché. Esto garantiza un mejor rendimiento.
  • Son más fáciles de integrar.

Desventajas

  • Como son texto normal, el browser les aplica antialias, generando contornos borrosos.
  • Como cada ícono es un carácter, no es posible crear íconos multicolores (aunque se puede crear varios íconos por separado y apilarlos para lograr el mismo efecto).
  • Suele suceder que el browser no logra cargar el archivo de la fuente (a veces no lo hace por cuestiones de seguridad), o bien tiene problemas con el soporte de @font-face. Por eso, muchos desarrolladores de icon fonts advierten que se trata de una tecnología experimental.
  • Pueden no mostrarse debido a aplicaciones para bloquear contenido que tenga instaladas el usuario.
  • Son más difíciles de crear.
  • Los browsers presentan diferencias en la forma de mostrar las fuentes; por ejemplo, aplican más o menos grosor a cada carácter. Esto también aplica a los icon fonts y puede causar problemas para distinguir la forma de cada ícono.
  • Son más difíciles de posicionar visualmente con respecto a otros elementos.

Conclusión

SVG es una tecnología más poderosa que icon fonts, y, a medida que vayan desapareciendo los browsers que no lo soportan, es probable que se convierta en la opción por excelencia para mostrar íconos. Sin embargo, icon fonts es una buena elección cuando necesitamos una solución rápida y no tenemos grandes exigencias.

En términos de adaptabilidad a múltiples pantallas, ambas técnicas son superiores a los tradicionales CSS Sprites realizados con una imagen en PNG. Sin embargo, es posible emular esta técnica con SVG.

WebP: construyendo el futuro de las imágenes en la Web

Los formatos de imagen más habituales en las páginas web tienen una larga historia detrás. Las primeras versiones oficiales de GIF, JPEG, PNG y SVG nacieron entre 1987 y 2001. Pero dentro de poco podríamos estar integrando un nuevo jugador a esta lista: WebP, un formato de imagen desarrollado por Google con soporte para transparencia y animación, y orientado a generar archivos de bajo peso.

Casi exclusivamente, las imágenes en WebP son resultado de la conversión desde otro formato (como los antes mencionados), y solo pueden consumirse de forma nativa a través de browsers compatibles (mayormente, Chrome y Opera). No existen cámaras de fotos ni editores de imágenes que produzcan gráficos directamente en WebP (sin un proceso de conversión). Y, de manera nativa, Android es el único sistema operativo que puede mostrarlos fuera de un browser, como si se tratara de imágenes en un formato tradicional. Sin embargo, existen funciones de PHP, plugins y codecs que salvan en parte estas falencias. WebP apareció en 2010 y todavía está muy lejos de alcanzar su madurez.

¿Para qué necesitaríamos convertir una imagen en GIF, JPG, PNG o SVG a WebP? Para reducir el tamaño del archivo. En muchas páginas web, las imágenes representan la mayor parte de los bytes que habrán de cargarse. Por lo tanto, reducir su peso mejorará drásticamente la velocidad de carga. WebP ofrece dos tipos de compresión:

  • Compresión sin pérdida (lossless). Se reduce el tamaño del archivo sin generar ninguna pérdida de calidad.
  • Compresión con pérdida (lossy). Se reduce el tamaño del archivo en mayor medida que con lossless, pero a cambio de sacrificar calidad.

De acuerdo con Google, las imágenes WebP con compresión lossless son un 26% más livianas que las PNG, mientras que las imágenes WebP con compresión lossy son entre un 25% y un 34% más livianas que las JPEG. El impacto sobre la velocidad de carga es tan importante, que empresas con altísimos volúmenes de tráfico están utilizando WebP para reducir el consumo de ancho de banda de sus servidores (y, con ello, el gasto de dinero que representa).

Pero no todo son ventajas. En 2013, Facebook empezó a convertir automáticamente las imágenes que subían los usuarios a WebP, mostrando esa versión en los navegadores que fueran compatibles (y JPEG en los otros casos). Las críticas no tardaron en llegar. Muchos usuarios, al descargar fotos de Facebook en su computadora para verlas offline, descubrían que estaban en un formato que no era reconocido por su sistema operativo, por lo que, a diferencia de las imágenes comunes (que pueden verse y editarse fácilmente con aplicaciones de escritorio), solo podían verlas a través del browser. Facebook tuvo que dar marcha atrás con la medida.

En aplicaciones donde los usuarios suben imágenes, la conversión a WebP es un arma de doble filo. Si bien la imagen resultante será más liviana para descargar, el proceso de conversión es complejo y exige un mayor trabajo por parte del servidor. En otras palabras, lo que se gana en ancho de banda se pierde en procesamiento de datos.

Por último, los resultados de la conversión también han sido objeto de crítica. En cuanto al formato JPEG, la conversión lossless a WebP puede generar imágenes incluso más pesadas que las originales, mientras que la conversión lossy puede causar pérdidas de calidad bastante apreciables para el ojo humano.

Conclusión

WebP combina muchas de las ventajas de JPEG, GIF y PNG en un mismo formato, por lo cual podría alcanzar una gran importancia en el futuro de la Web. Sin embargo, todavía tiene un bajo soporte cross-browser y debe resolver los muchos problemas de su algoritmo.

Enlaces externos

Minificar código: una técnica sencilla para hacer más liviano nuestro sitio web

La velocidad de carga es uno de los factores más influyentes en la experiencia que reciben los usuarios de nuestro sitio web. Por eso, tiene una incidencia directa en las tasas de abandono: los usuarios tienden a cerrar la página cuando ven que tarda demasiado en cargar.

Una de las muchas técnicas que apuntan a resolver este problema es la minificación de código: reducir el peso de los archivos de código fuente a través de la eliminación de bytes innecesarios —espacios adicionales, saltos de línea, sangrías y comentarios—, además de simplificar todo lo posible la escritura de las sentencias (por ejemplo, usando nombres de variables y funciones más cortos, o evitando lo más posible la repetición). Otra técnica relacionada es juntar todos los archivos de código fuente de un mismo lenguaje en uno solo. En desarrollo web, los lenguajes que se suelen minificar son CSS y JavaScript (la simplificación de código HTML puede generar una interpretación incorrecta por parte del browser, mientras que en los lenguajes del lado del servidor —como PHP— no se producen mejoras significativas). El verbo no existe oficialmente en español, sino que es una traducción literal del inglés minify.

Veamos un ejemplo. El siguiente código CSS no ha sido minificado, ya que contiene saltos de línea y sangrías, que son útiles para que una persona lo comprenda bien, pero prescindibles para una correcta interpretación por parte del browser:

#main #archives {
     margin-bottom: 30px;
     margin-top: 0px;
     padding-bottom: 40px;
     padding-top: 0px;
     position: relative;
}

Al minificarlo, el código pasa a verse así:

#main #archives{margin-bottom:30px;margin-top:0;padding-bottom:40px;padding-top:0;position:relative}

Un archivo CSS que contenga el primer código pesará 128 bytes, mientras que el segundo tendrá apenas 100 bytes. El peso se ha reducido en un 21,875%.

Conozcamos las ventajas y las desventajas de esta técnica.

Ventajas

  • Se reduce el peso del código fuente del sitio web. Dependiendo de la técnica utilizada, el código fuente original y la posible combinación con otros métodos (como ofuscación de código y almacenamiento en caché), esto puede acelerar de forma drástica la carga de las páginas.
  • Como se reduce la cantidad de bytes que necesita nuestro sitio web, también se reduce el espacio ocupado en el servidor y el consumo mensual de ancho de banda. A partir de cierto nivel de tráfico, esto se traduce en un ahorro de dinero en servicios de hosting.

Desventajas

  • El código minificado es extremadamente difícil de depurar: no hay comentarios y todos los errores se producirán en una única línea larga.
  • Especialmente en JavaScript, si no conocemos la técnica en profundidad, minificar el código puede alterar de manera indeseada su funcionamiento.

Por las características señaladas, muchos plugins de JavaScript y CSS vienen con cada archivo en dos versiones. La versión sin comprimir se recomienda para la etapa de desarrollo, mientras que la versión minificada se destina al sitio ya en producción.

Obviamente, el proceso de minificación nunca es manual, sino que debe realizarse con herramientas específicas como YUI Compressor (Yahoo!) y Closure Compiler (Google).

Izquierda o derecha: ¿dónde deberíamos ubicar la sidebar?

La sidebar, o barra lateral, es la sección que aparece a uno de los costados del contenido principal en muchas páginas web. Puede exponer contenido relacionado (a la página o al sitio en general), noticias vinculadas, menús de navegación, banners publicitarios, formularios para suscribirse al newsletter y todo tipo de widgets. El concepto proviene del diseño gráfico.

Tradicionalmente, la sidebar era una sola y se ubicaba al costado izquierdo. Sin embargo, durante el boom de los blogs (entre 2004 y 2008) se popularizó la sidebar a la derecha. Hoy podemos encontrar sitios web con una u otra disposición, o incluso con dos sidebars (una a cada costado). ¿Cuál es la mejor opción?

TechCrunch usa dos sidebars

1stwebdesigner usa sidebar derecha

Kotaku usa sidebar izquierda

Sidebar a la derecha

  • Para los usuarios occidentales, el orden de lectura predominante es de izquierda a derecha. Por eso, si la sidebar está a la izquierda el usuario la alcanzará con la mirada en primer lugar, antes que el contenido principal. En el diseño de blogs, revistas digitales y sitios de noticias, muchos eligen ubicar la sidebar a la derecha para que los usuarios vean el contenido principal (las noticias) antes que el secundario. De esta manera, suponen, capturarán la atención del lector apenas abra la página. Así, esta decisión ayudaría a cumplir con la «regla de los tres segundos».
  • Según Paul Boag, la navegación a la derecha refleja el tradicional sistema de «navegación» de los libros y las agendas, donde las pestañas están ubicadas a la derecha. Además, la barra de scroll vertical siempre se ubica a la derecha, y es allí donde el usuario coloca naturalmente el cursor del mouse.
  • Probablemente sea mejor en términos de posicionamiento en buscadores. Lo normal es que en el código fuente el contenido principal se presente antes que la sidebar, y los buscadores podrían basarse en este orden para determinar qué contenido es más importante.

Sidebar a la izquierda

  • Hay quienes objetan que los usuarios de Internet están más acostumbrados a ver las sidebars a la izquierda, y cambiar esta disposición implica traicionar sus expectativas.
  • El ojo tiende a posicionarse al centro de la pantalla. Con la sidebar ubicada a la izquierda, el título del post empieza cerca del centro. Pero si la sidebar está a la derecha, el título del post empieza «pegado» a la izquierda.

Conclusiones

No hay una opción mejor que otra. Muchos estudios revelan que el costado donde esté ubicada la sidebar no influye de manera significativa en el comportamiento del usuario: la duración de la visita y las tasas de conversión son prácticamente las mismas, con una leve diferencia a favor de la sidebar derecha. Sin embargo, se recomienda tomar una decisión según el contenido que queremos que el usuario encuentre a simple vista. Los demás aspectos del diseño y el nicho al que se oriente nuestro sitio web también deben ser tenidos en cuenta.

En el caso de utilizar dos sidebars, lo ideal es usar la izquierda para mostrar enlaces de navegación, publicidad, el formulario de suscripción y noticias relacionadas, y usar la derecha para brindar información complementaria (sobre el autor del post o sobre la empresa) y enlaces a nuestras cuentas en redes sociales.

Por último, debemos tener en cuenta que, en resoluciones chicas como las de las tablets y los smartphones, resulta conveniente quitarle espacio a la sidebar para privilegiar el ancho de la sección principal.

Diseño web centrado en el usuario: un enfoque exitoso

Son varios los actores que pueden estar involucrados en la realización de un proyecto de desarrollo web. Y todos pueden tener distintas opiniones o intereses sobre un mismo tema.

Por ejemplo, el diseñador puede tener la intención de desarrollar un sitio visualmente inusual, que le resulte divertido construir y le permita destacar su trabajo, sin importarle que esto afecte la usabilidad.

El programador, en cambio, puede querer que todo funcione de acuerdo con sus parámetros de eficiencia y rendimiento, para lo cual quizás prefiera despojar al diseño de elementos atractivos pero «pesados».

Y el cliente probablemente busque que su sitio web se parezca a otro, o que tenga la mayor cantidad de funciones posible, o que cuente con alguna característica novedosa independientemente de su utilidad.

En todos los ejemplos mencionados, los impulsores del proyecto se olvidan del agente más importante: el usuario final.

El diseño web centrado en el usuario es una metodología que, a lo largo de todo el proceso de desarrollo del sitio web, prioriza los intereses, las necesidades, las características y los objetivos del usuario. El resultado será un sitio web usable y accesible, que cumplirá adecuadamente con las expectativas de quien navega por él. El diseño web centrado en el usuario se preocupa por cuatro aspectos principales:

  1. Visibilidad. El comportamiento de la página debe ser transparente. Con un simple vistazo, el usuario debe poder determinar qué puede y qué no puede hacer con la página.
  2. Accesibilidad. Los usuarios deben poder encontrar información rápida y fácilmente a través de la página, más allá de su tamaño.
  3. Legibilidad. El texto debe ser fácil de leer. Se recomiendan fuentes sencillas y buen contraste.
  4. Lenguaje. El texto siempre debe ser comprensible, sin importar el tema a tratar.

Teniendo en cuenta estos criterios es posible diseñar sitios web de utilidad para nuestro público más importante: el de los usuarios.

Buscamos Diseñador Gráfico con orientación Web.

Hola como estás, queremos contarte cual es el perfil de Diseñador Gráfico que estamos buscando, de manera que si pensas que podes sernos útil y nosotros a vos, nos envíes tu curriculum y tu portfolio de trabajos. A lo largo de los más de 7 años que llevamos trabajando en el mundo online, hemos recibido centenares de curriculums de diseñadores gráficos, tanto de la ciudad de Santa Fe, como de alrededores y si te contamos, cuántos son los que realmente nos servían al menos para realizar una entrevista, creo que nos sobran los dedos de las manos y queremos explicarte porqué. Lamentablemente la facultad local, no tiene una especialización o una rama de la carrera dedicada a preparar alumnos en diseño gráfico orientado a “digital”. Con esto que queremos decirte, que la mayoría de los estudiantes avanzados, de los recibidos y de hasta los profesionales con varios años de trabajo, no tienen en su curriculum trabajos de diseño relacionados a proyectos como Sitios Webs de Alto impacto, Aplicaciones para facebook, Juegos Online, Sitios Móviles, Campañas de Banners y las decenas de piezas derivadas de este tipo de proyectos que se pueden ver en el mundillo online. Los pocos trabajos que se incluyen, dejando a un lado todo lo que son diseño de identidad, papelería comercial, packaging, etc, tienen que ver con sitios muy básicos, institucionales y que no muestran el real potencial que puede llegar a tener ese diseñador si se especializa en proyectos online. Por otra parte y aquí ya no tiene la culpa la falta de especialización de la facultad, recibir un curriculum de un diseñador gráfico, en un documento de Word, sin ningún tipo de estilo, diseño, impronta y muestra de trabajos, es algo que lamentablemente suele suceder a menudo y que nos deja prácticamente sin chances de analizar al candidato. Si bien el terminar la carrera es sumamente importante, en esta profesión lo que más valoramos como empresa, es el talento, la creatividad y el aspecto humano (pero esta última parte, se ve en el día a día). Ahh, no queremos olvidarnos de esta aclaración, la cual no es menos importante. NO NECESITAS SABER PROGRAMAR! Siempre que hemos publicado avisos en búsqueda de diseñadores Web, enseguida nos aclaran que no saben programar o que saben algo de html. En 4r Soluciones, el diseñador diseña, el maquetador maqueta html/css y el programador, programa en PHP o en Action Script, pero el diseñador Web, diseña interfaces o anima en Flash para Web, pero no tiene que saber programar. En base a esto que te acabamos de contar, esperamos haberte ayudado a decidirte por sí o por no, a enviarnos tu CV, tus trabajos y a que nos cuentes si te interesaría sumarte a trabajar en diseño gráfico, 100% orientado al mundo online. Vas a tener que diseñar sitios de campañas online para marcas como las que podes ver en nuestro sitio Web, vas a tener que diseñar aplicaciones de facebook, pequeños juegos que van dentro de sitios, vas a tener que diseñar y animar banners como los que ves cada día al abrir un sitio de alto tráfico (Clarin, La Nacion o el mismo MSN), vas a tener que diseñar un sitio para móviles y muchos otros trabajos los cuales, solo se podrán ver en un monitor, en una tablet o en un celular, pero que seguramente no verás en un afiche en la calle. En 4r Soluciones vas a encontrar una empresa en constante crecimiento, innovadora en la región, con un equipo de trabajo formidable, en un ambiente muy cómodo en donde seguramente vas aprender mucho y vas a trabajar en proyectos de lo más variados, para clientes y marcas de prestigio nacional e internacional. El puesto se requiere de forma presencial en nuestras oficinas en la ciudad de Santa Fe en horario corrido. Animate, envíanos tu CV y portfolio a sumate@localhost/4r-sitio-web-2016/blog Gracias por tu tiempo!