Tag Archives: web

Sitio web de la Biblioteca Franciscana

Ahora que la web puede accederse desde una PC, una laptop, un SmartPhone o una tableta, se nos presenta una paradoja a los diseñadores: debemos creer en la estructura semántica del contenido de las páginas, pero también hay que cuidar más que nunca la presentación de la información considerando tanto al usuario como el dispositivo a usar.  Últimamente me ha llamado la atención estos sitios que aprovechan las ventajas del CSS para ajustar sus layouts dependiendo de su resolución, así que aproveché experimentar con un proyecto de rediseño web que tenía  pendiente: La Biblioteca Franciscana.

Mi solución es bastante artesanal y no tiene nada de sofisticada. Aunque hay artículos bastante completos sobre el tema, yo había leído alguna vez que tenía que ver con el viewport, y entre los resultados de mi búsqueda di con el uso del parámetro media y los CSS Media Queries. En los siguientes recursos está cómo emplear diferentes hojas de estilo dependiendo del medio:

http://css-tricks.com/6206-resolution-specific-stylesheets/

http://css-tricks.com/6731-css-media-queries/

http://www.w3.org/TR/css3-mediaqueries/

http://reference.sitepoint.com/css/mediaqueries

http://www.css3.info/preview/media-queries/

http://coding.smashingmagazine.com/2010/07/19/how-to-use-css3-media-queries-to-create-a-mobile-version-of-your-website/

http://www.thecssninja.com/css/iphone-orientation-css

En cuanto al diseño web, siempre tuve una preferencia por layouts fijos por tener un mayor control del espacio en ventana y por tomar en cuenta la resolución estándar de un usuario potencial. Nunca me había preocupado porque la información quedara bien acomodada en diferentes resoluciones; es un reto interesante conservar la estética reticular y mantener un flujo de lectura adecuado para cada resolución. Este tipo de soluciones requiere que tengamos una actitud algo quisquillosa y obsesiva, así como trabajar cada layout hasta quedar satisfechos.

Justo por el cambio de "paradigma" de fijo a adaptable, y ante una especie de "bloqueo ante la hoja en blanco", no quedaba conforme en (regresar a) maquetar primero en algún software de diseño, así que lo trabajé directo en pantalla. Un pro de esta decisión es que vas viendo "en tiempo real" como quedan las cosas en diferentes navegadores y resoluciones. Un contra es que podemos perder el control fácilmente —sobretodo si dejamos el proyecto un día o dos. Es importante hacer anotaciones en papel y documentar en las hojas de estilo para que recordemos por qué tomamos ciertas decisiones. En este proyecto, me resultaron —a mi juicio— muchas hojas de estilo y fui redundante en ciertas reglas, dejándolas en cada hoja porque no sabía como iba a verse "el final" en todas las resoluciones; algo así como "un cambio por aquí y luego ajusto por acá".

Con un layout fijo no considero útil que tengamos muchas hojas de estilo, pero dadas las múltiples resoluciones, parece ser necesario un mayor número de "enlaces". Un colega me sugirió hacer importaciones, pero al final descarté esta opción porque según hojeé, afecta el rendimiento:

http://www.stevesouders.com/blog/2009/04/09/dont-use-import/

Otro punto importante es verificar la compatibilidad de los CSS Media Queries. Originalmente estaba muy feliz —tipo the Oatmeal— porque IE se comportaba decente; pero por no leer, me llevo la sorpresa de que fuera de IE 9, simplemente no funcionan:

http://caniuse.com/css-mediaqueries

Ante esta situación, decidí dejarle un layout fijo a todos aquellos usuarios que tuvieran de IE 8 para abajo y tomando como resolución estándar 1024 px de ancho.

Luego está el asunto del iPhone y del iPad. Hay que poner una línea de código que indique qué va a pasar cuando el navegador sea Safari. Esta línea asocia la variable "ancho" empleada en el CSS Media Query con el "ancho" del iPad, iPod o iPhone —según sea el caso. Además, resulta que cuando pasamos de modo landscape a portrait, o viceversa, se hace un zoom medio raro y es posible que los textos se desplieguen de diferente tamaño a como los observamos en una computadora de escritorio. Para validar todo lo anterior está como referencia el siguiente recurso:

http://stackoverflow.com/questions/2977550/iphone-safari-css-rotation-bug

A mi me divirtió mucho esta idea de presentar el mejor layout dado el ancho del iPod, iPhone o iPad. Sin embargo, siendo sinceros y "usables", la desventaja de jugar con diferentes acomodos de la información es que rompemos con la navegación (browsing) del usuario. Cuando alguno de estos dispositivos se rota 90 grados, debido a este re-acomodo, el usuario pierde vista la información de su interés. Lo anterior es más evidente en el caso del iPod/iPhone. Cognitivamente, lo que hacemos es "resetear"  el flujo de interacción; definitivamente algo no bueno para ningún usuario. En este proyecto, la mayoría de la información es estática y aquella que podría cambiar o agregarse durante el año, estará ubicada en la parte superior de las páginas correspondientes.

Una colega me señaló que estos ajustes automáticos no siempre convenían si trabajamos en una computadora de escritorio  —o en una laptop con pantalla grande — porque quizá el re-acomodo de la información podría perjudicarnos cuando llevemos a cabo una tarea más compleja, donde trabajemos con la información proveniente de diversas ventanas. Se me hizo un punto válido; por ejemplo, yo mismo he copiado y pegado información de una página web a Word o Excel. En este tipo de situaciones, debería de haber una opción para "fijar" el layout.

Por último, no olviden visitar http://ciria.udlap.mx/franciscana/ para enterarse de qué conferencias y exposiciones habrá en dicha biblioteca. Saludos :)

El “síndrome Tv y Novelas” en una página de inicio

Las revistas de chismes del espectáculo son popularmente adictivas. En México existe una gran circulación de este tipo magazines, siendo TV y Novelas una de las más representativas y con más trayectoria. Una característica distintiva de éstas es sin duda la portada, la cual tiene que gritar para llamar la atención de los lectores potenciales. Y que mejor manera de hacerlo con textos en caja alta, colores vibrantes, falta de aire en la composición y enunciados estridentes.

Portada de TV y Novelas México

Portada de TV y Novelas

Lo importante tiene que aparecer en la portada. Pero, ¿qué es lo importante? ¿quién lo determina? Quizá a muchos nos cruza por la cabeza la palabra editor y más aún, podríamos determinar que "él decide, él dirige, y punto".

Si hacemos la analogía con la Web, la portada vendría siendo la página de inicio. ¿Cuáles son las respuestas a las mismas preguntas? El editor o webmaster sería quien determina qué, en qué orden y dónde van las cosas ¿no? Sin embargo, la Web es una de las entidades donde el poder del usuario final tiene más peso para lograr el éxito ¿o no?

Supongamos que el webmaster es en sí el "diseñador web": el que se encarga no sólo del mantenimiento sino que ha participado tiempo atrás, tanto en la estructura como en el layout. Este caso es fácilmente visible en freelancing o en trabajos donde un equipo pequeño (incluso de una o dos personas) se encarga de un sitio completo.

Cuando el diseñador se encuentra con los stakeholders

Pues bien, la premisa del "lado del diseñador" sería "poseo los conocimientos para determinar cómo indentificar la estructura del sitio y la interfaz de este"; ergo, "aquí está el sitio propuesto, úsese". Sin embargo, existe una contraparte: los stakeholders o las personas interesadas (en el sitio). No estamos hablando del usuario final. Entre estas personas puede estar quien encarga el sitio (contratista), el jefe, un comité que determina qué información se estará presentando, etc. Lo "sabroso" se da cuando la mente (y el ego, por qué no) del diseñador se encuentra con la de los stakeholders para determinar, entre otras cosas, qué incluye y cómo debe ser la página de inicio, la "gran carta de presentación".

Peticiones para mostrar algo en la página de inicio

En ese cruce de "aires", cual formación de tornado, suele darse un "Síndrome de portada TV y Novelas" en el index o página de inicio, el cual corrompe terriblemente la posible propuesta óptima de interfaz web por parte del diseñador. Todo es importante y todo debe resaltar. Claro, las opiniones son muy sesgadas dependiendo del stakeholder en cuestión. Justo ahí es donde entra el grado de influencia de cada uno de ellos; sin embargo, todos quieren tener visible el nicho de información de su interés.

Más peticiones al webmaster o diseñador por los stakeholders

 

La "homepage TV y Novelas", le pone al usuario todo a la mano, eso debe ser bueno. Se pueden encontrar banners animados en flash y muchos botones o imágenes por todas partes, textos de gran tamaño, menús desplegables con muchas pero muchas opciones, más de 5 logotipos (por eso de mostrar que el sitio es importante), etc. 

El ying-yang de este asunto puede describirse así: el diseñador web no preparó la estructura (navegacional y visual) del sitio "a prueba de balas" y tampoco se preocupó por sensibilizar a los stakeholders hacia una cultura de la usabilidad y fucionalidad (¿qué queremos con el sitio? ¿para qué servirá?); por otro lado, las personas interesadas sí quitan autoridad al diseñador (aunque se les explique), debido a que lo "importante" es lo importante y tiene que estar en el index, cuanto más opciones, mejor. No se trata de armar "pleito", ni de ver quién tiene la razón, sino de darse cuenta que un sitio web va más allá de "presentar información", porque en la mayoría de las veces están ahí para usarse.

Usuario confundido ante una página de inicio atascada

¿Y a qué lleva el último punto? La respuesta es simple: cuando los usuarios usan el sitio (valga la redundancia), se topan con una página de inicio saturada, con demasiada información, muchas opciones para seguir navegando y que pobremente responde a sus necesidades. Después, cuando llega la retroalimentación, sobretodo en esas situaciones donde se apremia "la calidad en el servicio", los stakeholders se dan cuenta que la página de inicio y todo el sitio, están mal.  Como parte de este síndrome entra su desesperación por no quedar mal y demostrar que sí hay aptitud, que se tiene un sitio web bueno, usable y relevante. Es posible que en este punto se recurra de nuevo al diseñador para que "corrija" tales desperfectos.

El síndrome puede evitarse, pero requiere de la participación de los stakeholders y que sepan hasta dónde llega su autoridad, dejando lo pertinente al diseñador web, que en teoría es el experto y sabe lo que conviene pensando en los usuarios del sitio. Lo complicado está que se involucran aspectos emocionales (en particular de egocentrismo) tanto en el diseñador como en las personas interesadas, por lo que "sanar" es más difícil de lo que parece.

El diseñador para ponerse frío, hay que reconocerlo, debe hacer su chamba, documentar en la medida de lo posible (wireframes y blueprints, esquemas y diagramas, todo lo válido para comunicar por qué se hacen las cosas) y ser claro ante los stakeholders sobre lo que se pensó, lo que se tiene, lo que puede ser y lo que se podría hacer. 

¿Complicado o díficil? Sí. Pero es parte del show ¿o no?

Legibilidad de código y documentación

Justo que vi un comentario de Ixmael en el post sobre mis experiencias en rediseño de logos, me hizo recordar sobre la indentación y documentación al momento de escribir código. 

Con respecto a la indentación, el primer pensamiento que he notado en chavos que aprenden XHTML es Who cares!! Sin embargo, no importa si es XML, CSS, C++, JavaScript o lo que sea, indentar es definitivamente una buena práctica. En mi opinión:

  1. Te permite identificar fácilmente la estructura del código: bloques de procesos y sus sub-procesos internos o estructuración semántica del contenido (en XML o XHTML); lo cual,
  2. fomenta una construcción mental ordenada de lo que estás codificando/escribiendo. Este orden te permite extraer y concentrarte en solo un bloque particular, a groso modo si es el proceso grande o detallado si es un sub-proceso.
  3. Ayuda a descansar al lector en el proceso cognitivo de lectura-entendimiento (cuando no es el autor quien lee).

Con respecto a al punto 3, y esto de descansar o descargar cognitivamente al lector (usuario), pues ¿qué no es válido que exista un "diseño" en el código mismo? Diseñadores: si nos preocupamos en diseño editorial y de información por dar una estructura jerárquica a los textos, ¿por qué no hacerlo en códigos?

Quizá no haya tanta importancia entre

<head>

</head>

<body>

<body>

con

<head>

  </head>

  <body>

  </body>

Pero cuando las cosas comienzan a aumentar como en

<head>

     <title></title>

     <meta ...>

     <meta ...>

     <link ...>

     <script>

         bla bla bla...

     </script>

</head>

<body>

  <div id="hdr">

    <ul id="menu-principal">

        <li></li>

        <li></li>

        <li></li>

    </ul>

  </div>
  <div id="content">

    <div id="col-izq">

        <p> ... </p> 

        <p> ... </p> 

    </div>

    <div id="col-der">

        <p> ... </p> 

        <p> ... </p> 

    </div>

    </div>

    <div id="ftr">

        <p> ... </p>

        <p> ... </p>

    </div>

  </div>

</body>

pues no hay duda que indentar nos da una buena "ayudadita".

Ya en lenguajes completos (de aplicaciones) o de guiones (scripts), esto de la indentación es un must, sobretodo con esto de que no necesariamente seremos nosotros quienes lean nuestro código. Nunca está demás dejar la sangría necesaria, al menos para marcar cuándo empieza y termina un bloque de código y así:

  • diferenciar entre los grandes chunks de información (clases, métodos y funciones),
  • marcar bien los procesos repetitivos (ciclos for, while y repeat until), o bien, 
  • reconocer qué decisiones se tomarán a partir de ciertas condiciones (por ejemplo en if-then, switch-case o "ifs" anidados).

También está el asunto de estandarizar el cómo codificamos. Es algo bueno de aplicar en la mayor medida de lo posible por la misma razón del párrafo anterior, aunque también nos puede beneficiar a nosotros mismos: en algunos casos si dejamos las cosas enfríar un rato para luego retomar el trabajo, puede ser que ya ni nos acordemos qué es lo que escribimos o dónde nos queamos.

Por ejemplo, si tenemos muchas especificaciones en CSS, pues un

/*Footer*/

nos ayudaría a identificar que de ahí para abajo (hasta otra marca) son cosas que tienen que ver con el contenedor footer. Se que parece tonto, pero en mi caso cuando tengo una hoja de estilo con muchas cosas, ya ni ganas me dan de leerla.

Se ve con mayor claridad este asunto en las rutinas de programación. Por ejemplo, una cabecera ayuda a recordar qué estamos haciendo, o bien, si alguien más nos lee, al menos puede tener una idea de qué hay en el archivo aunque no lea detalladamente nuestro código.

/*****************************************************************

  Nombre: imprime_datos_usuario
  Fecha de creacion: 26-julio-2008
  Autor: Omar Sosa Tzec
  Entradas: strNombreUsr - Nombre del usuario.
            strDireccionUsr - Direccion del usuario.
  Salidas: intStatus - Verificador de que se imprimieron bien los datos en documento.
          1 si estuvo todo bien. 0 si hubo algun error.
  Descripcion: Recibe datos del usuario y entonces verifica que tienen validez consultando la tabla de usuarios validos y de ahi incrustarlos en el documento-mensaje de salida con la variable de estatus.
/*****************************************************************/

También en el manejo de variables, muchas veces resulta conveniente empezar éstas con algún identificador que de antemano nos diga de qué tipo es: un int para las variables enteras, un str para las cadenas, un flt para las flotantes o punto decimal, etc.

A partir de este punto, podemos hacer combinaciones de mayúsculas con minúsculas para nombrar las variables. Por ejemplo, fltResultadoDivision. Para otras palabras reservadas también podemos definir nuestros estándares. Por ejemplo, Persona para la clase persona y Pepe para nombrar un objeto de esta clase.

En CSS por otro lado, si son cosas que tienen que ver con un ID llamado header, por ejemplo, un estándar práctico es quizá ponerle fondo-hdr.gif a su imagen de fondo o en las especificaciones poner .deocor-hdr para llamar a una clase que aplica sólo en este ID.

Sí, ya se: puede ser un verdadero fastidio estar haciendo esto. Tampoco hay que exagerar, y dependiendo de qué estemos haciendo, tomar lo que se nos acomode mejor. Pero sin duda, un poco de estandarización y limpieza de código cae bien, sobretodo cuando se trabaja en equipo.