Category Archives: XML/CSS

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 :)

Rediseño de un formulario web

En el diseño de información, los formularios pueden ser complicados de resolver porque a pesar de parecer aburridos, se necesitan tomar buenas decisiones sobre cómo podría darse el flujo de lectura, el entendimiento de los campos, atender a cuestiones de legibilidad, definir jerarquías visuales, en algunas ocasiones el manejo de color y elementos gráficos, y en general preveer un buen flujo de trabajo (es decir, la "interacción" con el formulario).

En un proyecto reciente, me topé con un formulario web para búsquedas avanzadas. El texto en el formulario ya estaba previamente aprobado. En este caso, mi asignación fue realizar un posible ajuste visual al contenido del formulario.

El formulario original:

Formulario de búsqueda avanzada del catálogo de marcas de fuego de la UDLAP - BUAP antes de su rediseño

El formulario en realidad son dos: uno tiene que ver con la búsqueda por "Procedencia" y/o "Institución" y el otro con la búsqueda avanzada por "Identificador de la marca". Sin duda, una forma directa de resolver esta situación es a través de una "división visual" que rompiera la lectura tan vertical que se tenía originalmente.

La parte de "Procedencia" y/o "Institución" resulta complicada por si misma: ¿cómo sabes qué campo es más importante?, ¿se llena uno? ¿se llenan ambos? Al final se decidió que el usuario, en su curva de aprendizaje, aprendiera a trabajar esta sección sin "ayudas visuales" adicionales — como poner una leyenda al estilo: "A ver mi estimado usuario, o llenas uno o llenas los dos, etc".

De la parte de "Buscar en", "Tipología" y "Ordenar resultados por", me surgió la duda si debía cada sección acomodarse horizontalmente. Eso daría una dinámica de trabajo de ir bajando un renglón/bloque a la vez. Sin embargo, esa opción no podría ser adecuada porque al menos en "Buscar en", las 8 opciones la convierten en impráctica. El cambio que sí se realizó fue que las opciones por defecto en "Búscar en", "Tipología" y "Ordenar resultados por" sean más evidentes para el usuario poniéndolas de primero.

Este es el resultado del formulario:

Formulario de búsqueda avanzada del catálogo de marcas de fuego de la UDLAP - BUAP después de su rediseño

Aunque los cambios realmente no son drásticos, puede observarse que con un acomodo más reticulado y manejo del aire compositivo en adición a las cuestiones planteadas arriba, el formulario se ve más consistente y quizá sea más usable. Afirmación, que por su naturaleza, sólo se puede validar a través de una prueba de usabilidad :)

Beca Alzado 2008

Es muy grato toparse con iniciativas como la de Alzado. Tal como aparece en su sitio web:

Resumen: 3.000 euros para la mejor idea para un proyecto web. En estos momentos de incertidumbre financiera, creemos que la Beca Alzado tiene más importancia que nunca. Por segundo año convocamos a cualquier persona a enviarnos su idea para un proyecto web. El plazo estará abierto todo el mes de Noviembre. Daremos la beca el 15 de diciembre.

Toda la información está en el post correspondiente. Aquí dejo un par de detalles que aparecen en dicho post que pueden animar a la participación.

Envía tu idea

El proceso sigue siendo tan sencillo como el año pasado. Envía tu idea en cualquier formato.

Puedes sencillamente rellenar el formulario, adjuntar un documento, poner enlaces a la web... lo que quieras. Lo que valoramos son las ideas. Evidentemente cuanto más detallada y elaborada, mejor se podra valorar y por tanto tendrá más posibilidades de llevarse la beca.

Quién puede enviar su idea

- Desde cualquier país.
- Cualquier persona (edad, sexo, creencia...).
- El texto del proyecto puede estar en inglés o castellano.
- Ideas destinadas a internet. Portales, aplicaciones, contenidos, tiendas, diseños, comunidades... Cualquier cosa. El año pasado se recibieron ideas sobre productos industriales o productos físicos. Si bien eran ideas geniales, nosotros no somos los más adecuados para juzgarlas y por tanto preferimos descartarlas de entrada.

Es tu idea

En Alzado solo queremos apoyar a las ideas y a sus creadores. La idea ganadora, así como todas las ideas enviadas pertenecen a sus autores. La beca no compromete en nada al autor de la idea con Alzado.

Para que quede lo más claro posible: No queremos nada. Solo queremos apoyar a la mejor idea que encontremos.

Una vez pasado el proceso de selección todas las ideas enviadas serán eliminadas de nuestros archivos para siempre.

Si gustan, pueden ver el proyecto ganador del año pasado: Vi.sualiz.us.

Ciclo de Conferencias: Web 2.0 para Ingenieros y Diseñadores en Puebla, México

Veo en la Vecindad Gráfica y BoxByte que la gira de conferencias sobre web 2.0, que a su vez promocionan el evento de "México Web 2.0", tendrán su conclusión en Puebla, Puebla. Vendrán Armando Sosa y Adán Avelar de Vecindad Gráfica.

¡Excelente! Para los que no podremos ir a Cancún es un buen chance para conocer y escuchar a practicantes de los estándares y construcción de herramientas sociales en la Web. ¡Ahí nos vemos!

Por cierto, antes de que se me pase... Por si no los han visto, les recomiendo dar un vistazo a la serie de post del buen Sosa sobre cómo ser freelancer, los cuales se llaman "Lanzándose al vacío".

Comenta Adán:

Como sitio final de la gira para dar a conocer el evento de México Web 2.0, que se llevará a cabo el 3 y 4 de Noviembre en Cancún, ahora visitamos Puebla:

Ciclo de Conferencias: Web 2.0 para Ingenieros y Diseñadores
Fecha:16 de Octubre
Hora: 13:00 horas
Lugar: Conexsoft 2008, Centro de Convenciones Puebla

Ponente: Adán Avelar
Hora: 13:00 hrs. | Duración: 30 minutos
* El impacto del Web 2.0 en el México de hoy

Ponente: Armando Sosa
Hora: 13:30 hrs. | Duración: 30 minutos
* Construyendo una nueva Web

Mesa Redonda con los ponentes
Hora: 14 hrs.

Apresúrate a registrarte para el gran evento el 3 y 4 de Noviembre en Cancún.
México Web 2.0

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.

26 Sistemas Administradores de Contenido

Francesco Mugnai ha puesto en su blog una lista de 26 sistemas administradores de contenido para votar. Aunque en los resultados WordPress va ganando con el 27.5%, de verdad que hay opciones para todos: basados en php, coldfusion, java, dependiendo si quieres algo personal o empresarial, entre otros factores.

26 diferentes CMS

Aprender web es como montar bicicleta

Dado el post anterior que me dejó reflexionando, sobre cómo aprender a diseñar páginas web, comento con un colega: 

No estoy seguro si comenzar un curso de diseño web deba incluir manejo de tablas. Sino empezar directo con CSS.

Es como aprender a montar bicicleta. Puedes aprender con "rueditas" o sin ellas. Al final es lo mismo, acabas sabiendo como montar bicicleta.

Nota contextual: El "pecsi" tiene que ver con la premisa de que a los diseñadores les cuesta trabajo aprender "código"... Jum. ¿Quién habrá inventado y diseminado esta idea?

Razones para no maquetar web en Photoshop

Casi me voy de espaldas cuando leí el título que puso Elías en Isopixel: Razones por las que NO hacer un mockup con photoshop para un trabajo web. De la traducción libre que está en blog tomé los siguientes puntos:

1. Photoshop limita completamente el trabajo, no se pueden incluir enlaces, áreas “clicables” o menús. Con el papel pasa lo mismo. Lo ideal es [añadido por mi] primero hacer un planteamiento muy básico sobre el papel [/añadido por mi] y luego pasarlo a CSS/XHTML, donde representaremos lo que se hizo en papel más resto de funciones básicas como navegación, enlaces etc.

  • Si estamos hablando de una maqueta o mockup, ya desde el papel y lápiz, es buena herramienta. La idea está en maquetar el sitio, hacer una disposición de los elementos, es el pensar cómo quedarían. Justo cómo ha mencionado un alumno de Javier Cañada dentro del programa Vostok. Lo que sí, viendo una maqueta como prototipo de baja fidelidad, en Photshop es posible concentrarse en los detalles visuales, esto es, enfocarse mucho en la forma. Aunque es tardado, su ventaja podría ser el dar una mayor calidad final en el prototipo a diferencia de tomar lápiz y papel. No hay que olvidar que en el prototipeo lo relevante es obtener, de ser posible, resultados sobre aspectos de usabilidad; ahí el photoshop es un arma de dos filos, es más fácil para este caso optar por lápiz y papel o un wireframe simple. No importa si se puede "cliquear".

2. Photoshop proporciona muchas herramientas para conseguir detalles y justamente buscamos lo contrario, no queremos dar detalles concretos, solamente lo esencial. El programa nos distraerá en cosas que ahora no tocan hacer.

  • Efectivamente, pero justo se repite mi apreciación en el primer punto. ¿Qué tipo de calidad se requiere en el prototipo y con qué propósito se está realizando? Un detalle curioso es que si el proyecto lo amerita, un prototipo simple con CSS no puede competir con uno visualmente más preciso (de preferencia con una versión más simple en papel o wireframe ya evaluada).

3. La fuente de un sitio forma parte imprescindible y es muy probable que necesites cambiarla varias veces. Photoshop hace más complicado este proceso: abrir el .psd, seleccionar la fuente del lugar concreto que queremos cambiar, cambiarla, exportar a .png .jpg para poder enseñar los cambios a, por ejemplo, un cliente etc. Además de queen photoshop las letras NUNCA se comportan igual que en la web, a pesar de darle la misma fuente con las mismas características en el programa se ve de una forma y en la web de otra [añadido por mi] (nunca entendí porque pasa esto) [/añadido por mi].

  • Con respecto a la fuente, es claro que no todos los textos pueden ser arbitrarios, esto es, utilizar la fuente que quiera y luego pasarlo a imagen. Vale para ciertos encabezados y es obvio que hay que tomar en cuenta qué tanta sustitución con imagen habrá de hacerse en los textos y por qué sería conveniente tomar este tipo de decisiones. Para los textos "comunes", esas cosas no se pueden probar mejor que con texto "en vivo", que se está viendo en el browser y eso sí tiene que hacerse con CSS (referente a familia tipográfica, puntaje, interlineado y variantes).

4. Photoshop se enfoca en la producción y no en la productividad. En este primer paso se busca conseguir los puntos esenciales para crear un sitio accesible, claro etc. Luego nos preocuparemos de darle un aspecto “bonito”.

  • Eso no lo voy a negar. Si se maqueta en photoshop, cuestiones accesibilidad, navegación y usabilidad tienen que tenerse en la cabeza "en segundo plano" (como en cómputo, un proceso corriendo ahí atrás) mientras se diseña. Esto implica que no importa tanto la herramienta (photoshop o lápiz de papel) sino la integración de los conocimientos sobre diseño visual, diseño web, diseño de información, arquitectura de información, accesibilidad y usabilidad. Insisto, ¿para qué va a servir el prototipo o maqueta en cuestión?

5. Perderemos tiempo en pasar el mockup de photoshop a css/html.

  • Otra gran verdad. Llego a una conclusión rápida que este es un vicio, el cual tengo y esto casi seguro que tienen muchos que empezaron con esto de la web en los 90s cuando el ensamble de las interfaces venía en forma de tablas. Lo que creo que este punto puede ser evidente dependiendo de tu forma de "aprender web"; si desde el principio rompes con la maquetación en photoshop y te acostumbras a hacer "drafts" a partir de una lógica-de-ensamble vía CSS/HTML, entonces tu perspectiva/proceso sobre cómo ir diseñando, definitivamente cambia. La estructura mental para esta tarea cambia. Al comenzar a hacer la "integración" que menciono arriba con una maqueta hecha en photoshop, los tropiezos te enseñan a discernir cuáles áreas "no deben o tienen por qué tocarse". Pero sí es interesante ver como el cambio en el paradigma de diseño web en cosas que a gente más reciente en estos rollos (post-liberación-de-las-tablas) hace que tengan soluciones creativas que pueden pasar por obvias para ellos.

6. Con html/css podremos seguir un flujo de trabajo mucho más productivo: Hacemos el cambio, guardamos y refrescamos.

  • Esto está relacionado con el punto anterior. En ese sentido, estoy de acuerdo. Aunque una vez pasada la migración de photoshop, esas áreas "intocables" tienen que trabajarse siempre como se plantea en este punto.

7. Photoshop es poco práctico, aunque lo manejes desde hace mucho tiempo, es complicado hacer las cosas de forma simple.

  • Si es el caso de un prototipo visualmente complejo, es tardado, pero no creo que ese sea el punto general de estos siete, sino identificar quién implica a quién, si photoshop luego CSS/XHTML o primero CSS/XHTML luego CSS. Sí son dos formas de pensar/diseñar diferentes. Y también hay que recordar el contexto, el usuario y el cliente. Mis comentarios van enfocados a sitios web "usables" por no decir cuasiplanos visualmente, no tanto a esos "interactivos" ganadores de premios y llenos de factores de diseño emocional y metáforas navegacionales rebuscadas. De una u otra forma, concuerdo en que hay que obtener un equilibrio.

Y la razón por la que casi me voy de espaldas, es porque, usualmente tengo que "concretar visualmente" una maqueta en photoshop, justo como estoy diseñando algo de web en estos días. Aunque, admito que en momentos de frustración, sobre todo por el trabajo "talachero" de pasar de PSD al ensamble CSS/XHTML donde a veces suele suceder que no queda justo como "habías pensado". Un debate interesante el asunto.

PD. Ya está el foro de discusión en Isopixel al respecto.

Actualización.

CyberGus nos comparte también su opinión sobre este tema, con comentarios bien enfocados. 

Guía de Derechos de Autor

De lo último que he tenido de chamba está darle formato a una guía para los usuarios de bibliotecas y centros de información llamada "¿Respetas los derechos de autor?" tanto para impresión como para pantalla.

 Página web de la guía sobre derechos de autor del grupo Amigos

 La parte impresa.

Primero me tocó darle forma a la versión impresa... el diseño editorial había que enfocarlo más en la forma conveniente que en una reestructuración del contenido (el texto y cómo estaba organizado). De ahí que se tomara una paleta viva/vibrante con tonalidades naranja-amarillo-rojo-fucsia. Esto con el fin de dar origen a una mano (la identidad, el autor) impregnada del derecho de autor (el copyright)... Una idea muy simple quizá, pero quería probar que tan bien podría quedar... claro que a la bolita "copyright" número 50, yo ya estaba hasta la mauser... supongo que debe haber una forma óptima para hacerla.

Mano de Copyright para derechos de autor 

 Luego había que cubrir este rollo de lo no cuadrado, lo llamativo para los jóvenes usuarios; ergo, poner cosas "chuecas" (uta.. que creativisisisimo wey). Y eso dió pie un tetráptico (mucho espacio, mucho lujo) implicado en gran parte porque las dos guías en sí son diagramas de flujo por lo que requerían de un buen tamaño para leerse con facilidad.

Guía de Derechos de Autor al frente 

 guía de Derechos de Autor parte trasera

 Y ya. En teoría, pronto encontrará su guía de derechos de autor en su tiendita de la esquina o en su biblioteca más cercana (claro, mientras esté dentro de la sociedad de cooperación interbibliotecaria Amigos).

La parte web o mejor dicho, cómo IE puede fastidiarte tus diseños. 

Una desventaja de trabajar en Mac es que se te olvida (si no usas Firefox) que existe IE y otros exploradores además del Safari. Por cierto, ¿por qué los usuarios de Windows no usan Safari en vez de ponerle un skin a su FireFox?

Bueno, soy culpable... admito que debo tener más en cuenta a mis usuarios (con IE 6 y 7). Así que ya no puedo decirme más "luego lo ajusto a IE 6 y 7 y ya está" porque no es tan simple. 

Aunque la versión web de la guía la quise hacer simple, quería que tenga un punch visual (ya saben: colorcitos, sombras y cosas flotando).  Pero claro, IE me dió un lapo en la cabeza cuando quise poner PNGs a 24 bits flotando unos sobre otros y más si haces un remplazo de texto por imagenes. El IE, con su problema de flotamiento, "mueve" las cosas si aplicas el filtro a un PNG de 24 bits  y por ende, se te desactivan bloques que funcionarían como vínculos (da la sensación de que se "bloquean" los "botones").

Hablando de 24 bits, me ganó la ignorancia porque hasta el momento no me "junciona" aplicarle bien el filtro para la transparencia desde la etiqueta IMG... así que la "manita" del header (ver imagen de abajo) no tuve más remedio que ponerla como fondo de un DIV hueco.

Otra página web de la guía sobre derechos de autor del grupo Amigos

Al final cedí y puse el menú como una lista simple. Si usas Safari verás el sombreado del texto vía CSS, pero hasta ahí.

Asumiendo el perfil de usuario, preferí colocar botones de imágenes en forma directa para descargar los diagramas de flujo; también activé vínculos en las imágenes.

Otra vez experimenté lo desesperante que puede ser IE, y no sólo el 6 por no aceptar PNGs de 24 bits, sino también el 7... Al final, como se dice por aquí, Microsoft "tiene el sarten por el mano". En este caso, muchos de los usuarios verían esta guía bajo IE 6 (sí!!!, la versión 6!!!). Lo que me dejó pensando es si usar algo "menos imagen" y "más estándar actual" en lo futuro que haga de web. 

Si el IE no tuviera estas broncas (puesto que FireFox y Safari se ven prácticamente igual), no puede quitarse la cosquillita exploratoria de los PNGs con transparencia y los DIVs flotando y encimándose por doquier... pero ni pecs... el usuario es primero.