3 de julio de 2014

Cómo son los EPUB de maquetación fija que exporta InDesign 10

Hace poco, coincidiendo con la salida al mercado de Adobe InDesign 10 (CC 2014), dábamos la primicia de su principal novedad: la capacidad de exportar EPUB 3 de maquetación fija.

Sin embargo, una mirada algo más minuciosa a esta importante novedad, ¿qué nos aporta?

A primera vista, la fidelidad del resultado es casi perfecta: fuentes incrustadas bien preservadas, maquetación igualmente respetada, páginas separadas, vídeo etc. Esto convierte sin duda a Adobe InDesign CC 2014 como una herramienta óptima para la creación rápida de este tipo de libros electrónicos, sin más pretensiones.

Las opciones de exportación son simples y directas, aunque dejan desiertas algunas opciones importantes que sí se abordan en el caso de EPUB de maquetación fluida:


Cuadro de diálogo de opciones de exportación EPUB 3 
de maquetación fija en InDesign CC 2014


Sin embargo, en caso de que tengamos nociones de HTML y CSS, ¿es posible hacer "bricolage" dentro de un EPUB 3 tal como sale del horno de InDesign CC 2014?

La esencia de un libro de Maquetación Fija es precisamente ésa, que conserve con precisión la posición, tamaño y aspecto de los objetos, es decir, las cajas de texto e imagen. Esto se consigue con bastante eficacia en la exportación desde InDesign, pero con un "peaje" a pagar: un código HTML un tanto inaccesible. He aquí una muestra:



Pequeño fragmento de código HTML correspondiente 
a un trozo de cuadro de texto en InDesign

Por si no has tenido la paciencia suficiente para ponerte a leer con calma el código de la imagen, simplemente mencionar que InDesign coloca cada palabra individualmente en su sitio, usando etiquetas HTML del tipo . Es decir, aunque nuestra página en InDesign conste de un simple e inocente marco de texto, InDesign lo va a convertir en una especie de puzzle donde cada palabra es una pieza, para conseguir el aspecto fidedigno en el libro ePUB 3.

Sinceramente, desconozco el porqué hacerlo así en lugar de posicionar los marcos de texto como un solo objeto contenedor con un texto fluido en su interior. Si bien es cierto que esta forma de generar el código puede ser algo conveniente a la hora de hacer libros que se leen solos en voz alta (con el efecto "Read Aloud"), es fácil ver que en cualquier caso la fracción de etiquetas —de código— excede con mucho a la fracción de contenido de texto. Además, el CSS responsable del posicionamiento está totalmente en línea (incrustado) dentro de los mismos párrafos de texto, cuando en general la praxis recomendada es la de separar el contenido del diseño, o lo que es lo mismo, el HTML semántico de las hojas de estilo CSS.

Quizá un motivo por el cual se genera este código tan intrincado sea para asegurar a la perfección que no haya ningún tipo de diferencias o inexactitudes entre lo que se ve en InDesign y lo que se ve luego en el libro EPUB3, o sea, que la experiencia sea 100% WYSIWYG.

A veces es posible que al exportar todo un contenedor de texto como un solo bloque DIV dentro del HTML de nuestro libro, haya ligeras diferencias en el tamaño de los textos, la partición por sílabas, el encaje de palabras, etc. Nada que no puedan solucionar unos leves retoques en la hoja de estilos CSS común del libro. Quizá lo que Adobe está diciendo con este código es "mira, lo exporta perfecto pero no lo toques ni un milímetro". Ésa es al menos mi impresión. ¿Qué opináis vosotros?




18 de junio de 2014

Novedades EPUB en Adobe InDesign CC 2014

Hoy se presenta la nueva versión de Adobe InDesign (la v10, CC 2014), que trae una importante novedad en lo que a publicaciones digitales se refiere: la posibilidad de crear EPUB 3 de Maquetación Fija.

Mira este breve vídeo y sigue hoy en Twitter en hashtag #CCNext para estar a la última:


Recuerda que para sacar el máximo jugo a TODO lo que se puede hacer con EPUB 3 tenemos disponible un curso online de Maquetación de libros EPUB 3 en nuestro Campus Virtual

6 de junio de 2014

Afrontar proyectos interactivos (2): Empezar a Prototipar

En la entrega anterior de esta serie de artículos sobre consejos a la hora de afrontar proyectos interactivos, había mencionado la importancia de empezar haciendo preguntas sobre el tipo de productos que realizaremos, qué características tendría y cuáles de dichas características son compatibles con los mercados objetivos donde pretendemos comercializar dicho producto.

Para ello, conviene realizar una tabla similar a ésta (con formatos, dispositivos y prestaciones) para ayudar a incluir o descartar tanto mercados como funcionalidades. 

Por ejemplo, imaginemos que nuestro cliente desea editar una guía turística interactiva, digital. No sabe si habrá de ser un e-book, una app o qué. Solo sabe que quiere sacar al mercado, a la venta, una de sus guías turísticas en formato digital. Por supuesto, desea la máxima difusión posible y que tenga una serie de elementos interactivos que la conviertan en un producto diferenciado y novedoso. Y también, como siempre, que sea algo B.B.B. 

Lo primero que podemos plantear a este cliente es una serie de preguntas simples:

1) ¿Cuál será el entorno de reproducción típico de tu guía? (en casa, en la calle, etc.)
2) ¿Piensa incluir contenido multimedia? (audio, vídeo)
3) ¿Será un contenido offline o dependerá de una conexión? (¡o mixto!)
4) ¿Es una guía de lectura, de consulta, o un manual práctico?

Estas preguntas nos pueden servir para discernir si el producto final se adapta mejor a lo que sería una app para smartphones, un e-book para e-readers o una publicación digital para tabletas, y construir combinaciones posibles, como por ejemplo:

Combinación A: Manual práctico, pensado para entorno móvil (calle), sin necesidad de vídeos pero con gran capacidad interactiva (secciones, mapas, etc.) y con todos los contenidos offline —> Solución más factible: Una app. 

Combinación B: Guía de referencia para la lectura, tanto para leer en casa como en movilidad, que no dependa de la conexión, y donde los contenidos sean de alta calidad (vídeos HD, fotos alta resolución) pero donde la interactividad no sea sofisticada —> Una publicación digital para una tablet.

Combinación C: Guía interactiva donde la clave sea el intercambio social “2.0” de la información entre una comunidad de usuarios. Solución más factible —> Web móvil o ‘“Web App”

Una vez que se ha despejado el horizonte en cuanto al tipo de producto a desarrollar, antes de iniciar la programación (en caso de ser una app sobre todo) es preciso realizar un prototipo o “mockup”. Los prototipos son un paso intermedio indispensable. Por un lado, permiten mostrar diferentes propuestas de diseño gráfico de la aplicación, así como lo que se denomina el UX / UI (Experiencia de Usuario, Interfaz de Usuario, sobre todo esto último) y escalar el proyecto en fases separables. 


Ejemplo de diseño esquemático de interfaz de usuario para app móvil


Esto es importante, ya que a menudo los proyectos se alargan más de lo previsto debido a que el cliente final no acaba de decidirse por un diseño, una funcionalidad, debe consultarlo con otras personas que deciden o que, simplemente, no sabe bien lo que quiere.

Entonces, antes de invertir una cantidad importante de tiempo y recursos en movilizar a toda una plantilla de desarrolladores, que son los que se limitarán a implementar un diseño según unas instrucciones precisas, es conveniente crear prototipo a modo de “modelos de juguete” para que el cliente se familiarice lo más posible con el aspecto y usabilidad que tendrá su aplicación. 

En el caso de un libro electrónico, las posibilidades de diseño de interfaz de usuario se reducen, ya que el libro no es más que un contenido insertado en una aplicación de lectura que ya dispone de su propio interfaz de usuario, cuyo aspecto o funcionalidad queda fuera del presupuesto del desarrollo del proyecto obviamente (a menos que el cliente se empeñe en suplantar “como sea” esa interfaz, cosa que a menudo no es posible). Entonces, en un libro electrónico cobra más protagonismo el diseño gráfico y la arquitectura de la información visual más que el User Interface (UI).

Cuando el producto será una App, es muy probable que el cliente tarde en decidirse por una propuesta de diseño de interfaz u otra. Por eso, conviene presupuestar el diseño de varias propuestas puramente visuales sobre el aspecto que tendrán, al menos, las principales pantallas de la aplicación. 


Ejemplo de mockup con conexiones entre pantallas, otra forma más avanzada
de construir prototipos para apps (cortesía de fluidui.com)


El crear un proyecto por etapas es también conveniente desde el punto de vista de evitar las lógicas tensiones de todo proyecto. En el desarrollo de un proyecto interactivo, uno de los puntos claves es la comunicación entre el cliente, el diseñador y el programador. 

Por desgracia, con bastante frecuencia los proyectos naufragan por una comunicación defectuosa entre cualquiera de las partes, y no es rara ver cómo hay proyectos que empezaron con buen pie pero que al cabo de un tiempo el cliente decidió reiniciarlo de nuevo con otro proveedor (con éxito incierto) porque acabó “quemado” con el suyo actual, frustrado por una sensación de incomunicación. “El cliente no sabe lo que quiere” –dice el diseñador/programador– mientras que “Esta gente tarda mucho y no hacen lo que les pido” –se queja el cliente–

Para evitar estas situaciones desagradables, es preciso ser consciente de que estamos ante una tarea compleja. Y, como bien decía uno de los más grandes gurús de la simplicidad, John Maeda, la complejidad se empieza a disolver cuando dividimos los complejo en componentes más sencillas. 

Siguiendo esta pauta, podemos empezar movilizando únicamente a un diseñador de UI para que dibuje, con la aplicación que le sea más fácil, una serie de pantallas interconectadas donde aparezca el diseño de la interfaz, las diferentes opciones y una serie de elementos simulados. Un prototipo o “mockup”, es decir, una representación ficticia, un guión visual de lo que será luego una aplicación interactiva. 

De este modo, en una primera reunión el cliente y el proveedor pueden identificar en una fase temprana posibles problemas de diseño que, de otro modo, hubieran “explotado en la cara” en una fase muy avanzada del desarrollo, donde los cambios pueden no ser viables, donde los plazos aprietan y el presupuesto se acaba. Esta zona peligrosa se suele denominar Development Hell.

Por ejemplo, en esta fase, con el prototipo en forma de diseños en un papel, se puede detectar si los elementos de la aplicación caben físicamente en la pantalla, si la navegación es complicada, si se echa a faltar alguna funcionalidad, etc. sin tener que haber escrito antes ni una sola línea de código. Además, se puede someter al cliente a una elección de un diseño que más le guste de entre varias propuestas. 

Una vez haya elegido un diseño y esté del todo de acuerdo con la navegación y elementos de la aplicación (sobre el papel, recordemos), puede ser un buen momento para pasar a la siguiente fase. Antes, se le puede solicitar al cliente que pague un % del presupuesto

De este modo, nosotros como diseñadores/desarrolladores obtenemos una lógica y saludable recompensa económica (que estimula la motivación a seguir) y el cliente es consciente que ha pagado por algo tangible y que ya es suyo. En caso de que, por los motivos que fueren, éste decidiera no seguir contando con nuestros servicios, al menos ha pagado por algo finalizado (un prototipo) que le puede ser de utilidad para seguir con otra gente sin partir de cero, y nosotros no hemos perdido dinero desarrollando durante un largo tiempo un producto que al final no ha visto la luz y cuyo cobro estaría lícitamente en entredicho.

En la siguiente entrega hablaré sobre algunas recomendaciones que pueden ser útiles a la hora de diseñar estos prototipos.


¡Felices desarrollos!
Consulteu aquí la versió en català d'aquest blog