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 reto del concurso era diseñar una aplicación turística para ciudades donde ocurrirá un mega-evento, pero que al final pueda seguir siendo útil y provechosa para los locales y nuevos turistas. Fue así como presentaron InTour: una aplicación que no sólo es pensada para el turista individual, sino que fomenta la integración familiar y generacional a través de una vacaciones bien planificadas, tanto en presupuesto como en actividades. Dichas actividades son "manifestadas" por la ciudad misma —gobierno, empresas u ONGs, para demostrarle a los visitantes del mega-evento lo "viva que está la ciudad"— con opciones para armar un plan flexible dependiendo de la distancia, transporte, tópico, clima o dinero asignado para el día.

El proceso de diseño involucró investigación secundaria y entrevistas a usuarios con el perfil de usuario potencial. Se diseñaron Personas, se hizo lluvia de ideas y se elaboraron bocetos —parte que a mi siempre me parece muy entretenida. Cuando se pulieron los detalles, verificando cómo se cumplían las metas de las Personas, se elaboró el prototipo cuya usabilidad fue evaluada.

Algo que disfrute mucho y que fue parte del proceso, fue cuestionar a los muchachos sobre cómo se presenta la información, qué comunica de un solo golpe en cada pantalla, cómo sí influye la visualización en la interacción y temas similares. Espero haber dejado en ellos que el diseño visual para IHC no es solamente que se vea bonito, sino que es parte "del show".

Extiendo mis felicitaciones al equipo UDLAP: se decidieron, lo intentaron y completaron la misión. Y es que en México desde el 2010 se ha fomentado este tipo de concurso y por si no saben, México, y en particular el equipo de la UTM de Oaxaca, se ha llevado el primer lugar en foros importantes. Así que el hecho de que la UDLAP se una a este conjunto de jóvenes entusiastas y ganadores, no solo me da mucho gusto por el triunfo, sino que señala que en el ámbito universitario hay un mayor interés por desarrollar el Diseño de Interacción y la Interacción Humano-Computadora. Si la academia se pone en paralelo con lo que está sucediendo a nivel profesional desde hace un par de años —como la creación de startups y grupos de interés, entonces algo bueno sucederá o dirá de nuestro país, ¿no creen?

Más información en la nota del concurso en el Blog de la UDLAP.

Gracias a Thaís, Jorge, Rafa, Alan y Betty por haber estado dispuestos a idear, charlar, discutir, criticar y diseñar juntos. ¡Felicidades!