Adobe Digital Editions para iOS

Hasta ahora, la gama de aplicaciones móviles que reproducen EPUB3 implementando la mayor parte de sus prestaciones multimedias más atractivas (animación, interactividad, multimedia, etc.) se resumían prácticamente a iBooks de Apple en el caso de iOS y a Gitden Reader en Android. 

Pues bien, desde unas pocas semanas hemos de sumar a este ecosistema a un nuevo-viejo actor: Adobe Digital Editions.


Esta app, que es la réplica para iOS (iPhone / iPad) de su homónima para escritorio (Mac / Windows), que es un clásico en el mundo del e-book. Al inicio de la comercialización de los libros electrónicos con DRM, una solución tecnológica habitual era encontrar tiendas online que ofrecían su catálogo digitalizado en formato PDF o EPUB2 usando el DRM de Adobe (mediante la tecnología de Adobe Content Server) y Adobe Digital Editions como aplicación cliente para realizar y gestionar las compras, a la vez que la sincronización y la lectura. 

Este software está implementado en una gran parte de los e-readers ‘genéricos’ del mercado (=los que no son Kindle de Amazon) en forma del denominado RMSDK (Reader Mobile SDK), así como en otras aplicaciones que no son estrictamente ADE pero que funcionan franquiciadas como es el caso de Sony Reader. Entonces, es importante a la hora de comprar un e-book informarse sobre qué tipo de DRM incorpora (si lo lleva) para conocer con qué aplicaciones o dispositivos lo podremos leer sin problemas.

Al igual que pasó en su día con Adobe Reader para leer PDFs, Adobe ha llegado tarde a implantar su app en iOS. Y me temo que, al igual también que pasó con Reader, no solamente llega tarde si no que llega mal.

Tras testear la aplicación en un iPad 3, he de decir que, a pesar de verificar que ADE para iOS es compatible con la gran mayoría de prestaciones multimedia de EPUB3, no presenta a día de hoy un serio competidor para iBooks de Apple. El rendimiento gráfico y de la interactividad es todavía insuficiente. Hay algunos errores de representación de páginas o gráficos. El interface de usuario, aún teniendo todas las funciones imprescindibles, es algo espartano. 

No existe (o no he sabido ver) la opción de poder visualizar los libros a doble página. Tampoco hay efecto visual de doblez de página «de papel». Sin embargo, ADE implementa un curioso servicio de estadísticas que informa al usuario cuánto tiempo lleva leyendo, y cuantas hora ha leído cada día, distribuidas en mañana, tarde y noche. Algo curioso, que tendría su gracia una vez que esta app funcionara del todo bien haciendo la función que debe hacer: facilitar la lectura de libros.

aspecto de la pantalla de ADE que nos muestra nuestras estadísticas lectoras



En resumen, yo daría a ADE para iOS un aprobado justito. Es una buena noticia que al menos exista ya en el mercado y se pueda descargar, ya vendrán actualizaciones con mejoras. De momento, en el caso de Android, no se sabe gran cosa. Adobe ofrece esta página con un listado de qué apps se recomiendan según el modelo y el fabricante. 

No sé si coincidiréis conmigo en esta valoración, pero creo que a fecha actual, el universo Android sigue asombrosamente muy rezagado en lo que a libros electrónicos modernos se refiere. El presente y me temo que el futuro cercano seguirá bajo la influencia de la manzana mordisqueada.

¡Felices lecturas!


El Animalario del Pr. Revillod: un ejemplo de adaptación analógico-digital

La digitalización de libros en papel puede mostrar todos los grados posibles de dificultad. En un extremo tendríamos, por ejemplo, las novelas. Éstas se pueden transformar en archivos estándar EPUB para su lectura en la inmensa mayoría de dispositivos, dotándolas de interactividad sin más pretensiones que una tabla de contenidos interactiva y –quizás– de notas al pie de página también interactivas.

En el otro extremo tendríamos los libros de texto de primaria o secundaria, repletos de ilustraciones, notas al margen, ejercicios de todo tipo intercalados con los textos, etc. 

En este artículo quisiera analizar un caso a estudio de una digitalización de nivel intermedio (en mi opinión). Se trata de un curioso libro interactivo en papel llamado Animalario Universal del Profesor Revillod, editado por el Fondo de Cultura Económica en México.


Este libro es en sí bastante finito, pero tiene miles de páginas posibles ya que explota la combinatoria: cada página está finamente seccionada en tres columnas que se pueden pasar de manera independiente, dando lugar a numerosas combinaciones de ilustraciones de animales imaginarios junto con sus nombres y descripciones. Es un libro sin duda recomendable para todas las edades.

El caso es que, al tratarse de un libro-juego, la idea de pasarlo al universo digital era demasiado tentadora como para dejarla aparcada. Reconozco que en su día, a modo de ejercicio, escaneé fragmentos de este librito para hacerlo interactivo empleando la tecnología HTML5. Pero luego he visto que la editorial ha publicado una aplicación para el iPad del libro, que podéis encontrar en el siguiente enlace.

En el siguiente y breve vídeo podéis ver mi análisis comparativo del libro en papel vs. su versión App:



Tras este análisis, me gustaría mencionar algunos puntos a destacar:

  • Se han añadido funcionalidades extra como la de pintar los animales (accesoria, en mi opinión) pero sobre todo una fundamental que es la posbilidad de compartir a través del e-mail y las redes sociales el resultado de nuestros experimentos. Esto ha sido posible mediante la programación en paralelo de una Aplicación de Facebook que permita la comunicación entre ambas plataformas. Quizá nunca hemos hablado de las aplicaciones de Facebook como parte del currículum de un editor digital pero creo que así debería de ser. Así que me parece excelentemente implementado en este ejemplo.
  • La app de momento está solamente programada para iOS. Creo que plantear proyectos como éste, que no requieren de llevar la potencia de los tablets al extremo, como HTML5 desde el inicio hubiera facilitado la labor de su publicación multi-plataforma.
  • El principal hándicap que le veo a esta app son sus características en AppStore. Me costó unos 4,99€ (unos 65$ pesos mexicanos), un precio que me parece adecuado, pero sin embargo lo que más me hizo pensar dos veces su compra no fue tanto el costo si no el abultado tamaño de la aplicación (casi 1 GB!!). Hemos de tener en cuenta que la mayoría de usuarios suelen comprar iPads de gama económica y enseguida se pueden quedar preñados de contenidos, con lo que cada vez más se mira con cautela el tamaño de las aplicaciones que uno se dispone a descargar, so pena de ralentizar sustancialmente la velocidad de su tablet.

En general, me parece que vale la pena dar publicidad a este tipo de iniciativas que fusionan libros en papel y digital de manera que ambos sean productos homogéneos, fácilmente identificables y que merecen la pena de cara a los lectores y demás usuarios de productos digitales por lo que, a pesar de los pequeños hándicaps aquí descritos, ¡enhorabuena, Fondo de Cultura Económica!


Afrontar proyectos interactivos (III): cuestión de Actitud

En esta tercera entrega de la serie de artículos sobre cómo gestionar proyectos interactivos, quisiera comentar aspectos que tienen menos que ver con detalles técnicos del proceso y más sobre la actitud con la cual hay que afrontarlos. No solamente desde la perspectiva del desarrollador si no también del cliente final (o del intermediario). 
Llevar a buen puerto un proyecto relacionado con las tecnologías de la información no es algo sencillo en general y hay que saber interiorizar lo que supone antes incluso de ponerse manos a la obra. En mi opinión, existen una serie de axiomas que merece la pena tener en mente, a saber:
1) “No hay proyecto pequeño”. En el mundo del fútbol se ha hecho popular una frase que mencionan los entrenadores habitualmente: “No hay rival pequeño”. Pues bien, en el caso de los proyectos digitales, yo creo que esta frase se aplica de manera imperturbable.
Cuando un cliente me requiere para un nuevo proyecto y menciona que es “poca cosa” o “simple” lo primero que hago es echarme a temblar y reservar un buen paquete de horas de trabajo. Y no me excluyo, esta subestimación del poder complicador de la tecnología la practicamos –creo yo– la mayoría de nosotros. No recuerdo ni un solo proyecto interactivo en los que haya participado, por simple que pareciera al inicio, que no haya acabado sin saber cómo realizando tareas repetitivas y tediosas (como miles de clics para over miles de imágenes) hasta altas horas de la madrugada para implementar un aspecto o cambio de la aplicación. 
Y es que en IT todo, repito, todo se puede volver endemoniadamente complicado
Los motivos pueden ser de lo más variopinto: desde que de repente el cliente solicite un cambio que a él se le antoje nimio pero que a unas alturas del desarrollo lo convierte en un trabajo de chinos hasta que el software con el que trabajes “sufra” una actualización de última hora que inutilice archivos o la aplicación misma. Todo puede suceder y todo es esperable en mitad de un desarrollo. 
Por lo tanto, la respuesta instantánea que hay que decir cuando nos vengan con lo de “es algo sencillo” debe ser de una firme cautela y de una humildad extrema. No se me ocurre una réplica más sabia que un prudente y honesto “bueno, ya veremos”
2) El perfeccionismo no es tu amigo. Si cuando gigantes como Microsoft, Apple, Adobe, Google… sacan al mercado productos que son una selva de fallos e imperfecciones ¿por qué nosotros deberíamos ser mejor que ellos? No quiero hacer una apología de la chapuza, pero en proyectos digitales “pequeños”, buscar el 100% de fiabilidad y compatibilidad en un escenario donde los propios fabricantes de tecnología acaban de entender lo que ellos mismos están produciendo me parece una actitud poco realista y coherente.
Es habitual tener que lidiar con exigencias de máximos por parte del cliente final, o bien con el intermediario que hace de mera correa de transmisión. “Se tiene que ver todo igual en Android, iPad, ordenadores y por supuesto en Internet Explorer 6”. Y de ahí no se mueven un milímetro, oye. 
Entiendo que es lógico y humanamente comprensible querer ofrecer un producto universal y fiable, pero quien está pidiendo eso creo que conoce poco o nada el mundo de la tecnología digital. En este punto es cuando uno debe proceder con la máxima cautela y explicar la cruda realidad de la misma, evitando dar la imagen de querer esquivar el trabajo o poner pegas gratuitas. En este aspecto el posibilísimo es nuestro amigo y el perfeccionismo es el enemigo. 
Es por eso que puede servir el argumento socorrido del “Vamos a sacar una versión 1.0 y luego ya introduciremos mejoras en versiones posteriores” (mi experiencia me dice que al final en el mayoría de los casos esa versión 1.0 será más estable y duradera de lo que piensan y que en realidad debería llamarse versión “virgencita que me quede como estoy”). Otra amiga es la filosofía Kaizen “Primero se hace, luego se mejora”.
3) Respeta a tu developer (desarrollador): no sé vosotros, pero yo a menudo me he topado con que se respeta poco al auténtico constructor de los proyectos digitales interactivos, al que más se “pringa” las manos en ello: el desarrollador, alias “developer”, alias “programador”. 
Aunque no sea el director del proyecto, hay que escuchar con cariño sus sugerencias y criterios. Cuando el developer te avisa que no una característica de la aplicación solicitada por el cliente o diseñador no es prudente implementarla, o que directamente no es viable, escúchale. Como norma general no lo dice por fastidiar o torpedear el proyecto. A los programadores de verdad les gusta programar, experimentar y superarse a si mismos haciendo nuevos trucos. Pero recuerda que ellos conviven en un mundo de complejidad extrema donde la normal general es que las cosas sencillamente no funcionen a la primera.
Y la mayoría de efectivos chulos que ves en páginas web, etc. a menudo están basados en tecnología pseudo experimental que se sostiene con pinzas, y la idea de que algo que viste automáticamente es extrapolable a tu proyecto interactivo es en la mayoría de casos errónea.
Una vez más, humildad. Se empieza por algo estable y luego se intenta refinar. 
4) No ocultar NADA. Una vez más, la mente extrapoladora y auto-completadora de la que gozamos la mayoría de nosotros nos juega malas pasadas. Por eso es fundamental no escamotear absolutamente nada al inicio del desarrollo de una aplicación interactiva. El ejemplo más típico pero no por ello menos dramático es de las aplicaciones multi-idioma.
La escena es bastante habitual: estamos en la recta final de un desarrollo que ha superado cientos de obstáculos debido en parte a lo explicado hasta ahora en los puntos 1, 2 y 3… y de repente, cuando ya se ve la luz al final del túnel, el cliente (o cualquier otro agente implicado en el encargo) menciona la frase fatídica: “Bueno y hacer que esto esté en tres idiomas es fácil, ¿no?”.
Si alguna vez habéis estado en el rol de desarrolladores y habéis pasado por esta circunstancia, supongo que no hace falta añadir más para saber qué se siente en ese instante. Es por eso que lo prudente es trabajar con arquitecturas que siempre prevean la posibilidad de que los textos o los sonidos sean en 2, 3… N idiomas, aunque el cliente no lo haya solicitado al principio. Y por supuesto reflejar esta previsión en el presupuesto, aunque no figure explícitamente.

En fin, seguramente me dejo más puntos en el tintero digital pero a grandes rasgos éstas son mis impresiones acerca del interesante mundo del desarrollo de proyectos interactivos originales. Os deseo la mejor de las suertes y espero que os hayan quedado fuerzas suficientes para leer las futuras entregas de esa saga o incluso las anteriores:
Segunda entrega: Empezar a prototipar (II)

Comparativa: Adobe DPS vs. EPUB3 con InDesign vs. iBooks Author 2.2

El panorama de los medios de producción para publicaciones digitales ha cambiado mucho más en los últimos 3 meses que —diría yo, creo sin exagerar— en los últimos 3 años.

Después del reciente comunicado por parte de Adobe según el cual el producto DPS Single, que permitía a cualquier suscriptor a Adobe Creative Cloud compilar sus propias apps para el iPad a partir de archivos de InDesign, acabará restringido dentro del producto de pago (a parte) Digital Publishing Suite, las posibilidades de autopublicación de libros multimedia para tabletas quedarán un tanto huérfanas, ya que esta solución de Adobe era utilizada muy extensamente.

O al menos ésa es la teoría ya que, en paralelo a este anuncio hemos podido ver dos actualizaciones importantes en produtos que son sumamente competitivos en este aspecto: los e-books en formato EPUB3 y los libros en formato iBook que fabrica la aplicación de Apple iBooks Author.

Si bien tras la restricción de Adobe DPS Single muchos editores digitales perderán las vista la posibilidad de vehicular sus ideas a través de apps, el campo que se abre ahora con los libros multimedia es sin duda mucho más interesante. Sin embargo, y como siempre al inicio de cualquier cambio, surgen muchas dudas. 

¿Qué producto sería ahora el adecuado, un libro EPUB3 creado con InDesign o un .ibook de iBooks Author? ¿Por cuál de las dos soluciones me puedo decantar? ¿Qué gano y qué pierdo con respecto a las app de DPS Single que también se hacían con InDesign?

Es por eso que en este artículo me dispongo a hacer una comparativa a tres bandas de tres productos con bastante enjundia: Las apps hechas con InDesign y DPS Single (a prácticamente extinguirse a partir del 01/05/2015), los e-books en formato EPUB3 realizados con Adobe InDesign CC 2014.1 (y ninguna otra versión anterior), y finalmente los libros .ibook creados con iBooks Author 2.2. 



Y para ello, cómo no, utilizaré un recurso visual que no por viejo deja de ser menos efectivo: la tabla comparativa:

DPS Single (archivo Folio)
EPUB3 con ID
.ibook
Herramienta Adobe InDesign Adobe InDesign iBooks Author 2.2
Coste herr. Suscripción CC Suscripción CC Gratis
Plataforma herr. Mac OS o Windows Mac OS o Windows sólo Mac OS
Producto que
genera
App para iPad EPUB3 iBook
Sistemas compatibles para la lectura iOS (solo iPad) iOS (iPhone/iPad), Android, Mac, Windows, Linux (via Chrome) Mac OS, iOS
Audio y vídeo Integrados / pantalla completa Integrados / pantalla completa Integrados / pantalla completa
Incrustación iFrames (Youtube, Google Maps…)
Parcialmente (no en iBooks)
Vía Widget HTML5
Animaciones HTML5
Sí, vía iFrame
Sí, integradas desde el mismo ID
Integradas en maquetación o en pantalla completa vía Widget
Archivos origen
InDesign (desde Word, txt, PDF)
InDesign (desde Word, txt…)
Propios o desde EPUB3 o InDesign (vía IDML)
Mercados de venta disponibles
AppStore
iBookStore y otros (con restricciones de prestaciones)
iBookStore solamente
Texto accesible
No
Lectura en voz alta de textos
No
No
Texto fluido adaptable
No
No
Sí (en orientación vertical)
Estándar abierto
No
No
MathML
No
Efecto «doblez de página» (page flip)
No
Sí (en iOS)
No



como podemos ver la elección no es sencilla, y en los tres casos se pueden realizar productos de mucha calidad, auténticos libros electrónicos interactivos de nueva generación. A partir de ahí, según las necesidades de cada proyecto, se pueden deducir los criterios que primarán para tomar una elección entre una u otra herramienta.

Es posible que me haya dejado una o varias características a comparar. En ese caso, se agradecen vuestras contribuciones dentro del área de comentarios!

¡Suerte con el camino que elijáis! 🙂

Maquetación EPUB3 con el nuevo InDesign CC 10.1

El pasado lunes 6 de Octubre, Adobe presentó una nueva hornada de novedades en su conferencia anual #AdobeMAX

Además de nuevas apps para móviles, que fueron la estrella de las presentaciones, las herramientas insignia de Adobe como Photoshop o Illustrator también incorporaron innovaciones remarcables. Por supuesto, InDesign, la llave inglesa de la maquetación en papel y digital, no fue una excepción. 

En concreto, se presentó la versión 10.1 de dicha aplicación, que entre otras novedades incorpora la posibilidad de generar libros electrónicos EPUB3 de maquetación fija (cosa que ya hacía la versión 10.0) pero con animaciones CSS e interactividad con botones y «Objetos Multiestado». 

He aquí un breve vídeo de 4 minutos donde se puede ver en esencia el calado de dichas novedades:



Además de otros ajustes más finos en la estructura interna del EPUB (como la posibilidad de crear visualmente landmarks para la tabla de contenidos), la irrupción de la interactividad en este tipo de EPUB es sin duda la noticia quizá del año en lo que a Edición Digital e InDesign se refiere. Ahora, con esta versión 10.1 podremos hacer lo siguiente:

  • Convertir cualquier objeto a un hipervínculo o botón
  • Aprovechar la gran mayoría de acciones interactivas del panel de Botones y Formularios (excepto los campos de formulario, ¡de momento!)
  • Realizar animaciones con el panel de Animación y Temporización, los grandes marginados desde que la tecnología SWF empezó a decaer
  • Crear objetos Multiestado interactivos (pases de diapositivas)
Ya que InDesign genera automáticamente el código HTML, CSS necesario así como incluye una librería propia de Javascript para hacerlos funcionar. Los EPUB3 con estas prestaciones que se generan validan a la primera en EpubCheck y se pueden visualizar con aplicaciones como iBooks (para Mac OS o iOS), Adobe Digital Editions 4.0 o Readium para Google Chrome.

Después de un primer testeo en profundidad, mi opinión es que se trata de una actualización de funcionalidades muy esperada que por fin ha visto la luz. Se da la paradoja, como mencionaré en detalle más adelante, de que ha habido muchos más cambios y mucho más significativos en DOS MESES de pequeños «updates» de InDesign CC 2014 que desde cualquier otra actualización mayor de versiones anteriores. Los cambios y añadidos en los parches continuos de Creative Cloud por lo que se refiere a EPUB… ¡van a un ritmo acelerado!

Pero, como con todo, siempre hay puntos fuertes y débiles, claros y oscuros. En mi opinión, éstos serían:

Puntos a favor:
    • Creación de archivos EPUB3 que validan sin errores 
    • Posibilidad de crear un libro de maquetación fija con capacidades multimedia e interactivas sin tener que recurrir jamás a abrir el EPUB y rascar código
    • Aprovechamiento de herramientas que ya existían y que eran familiares para muchos usuarios
    • Política de designación de estilos CSS e identificadores HTML más sensata que en versiones anteriores
    • Generación de código HTML listo para ser aprovechado para añadir la funcionalidad de «Read Aloud» (lectura en voz alta de textos)
Puntos en contra:
    • En aras de la precisión en la maquetación fija, se sigue exportando un código HTML con una etiqueta SPAN individual para cada palabra, con su CSS de posicionamiento en línea
    • Los «palos de ciego» de Adobe en las políticas de etiquetado de estilos a lo largo de las últimas versiones son un mareo para el usuario, que dificulta el aprendizaje
    • El código CSS que se genera automático para las animaciones es prolijo y pesado para retocar, una vez más en aras de la precisión absoluta
ahora InDesign ya genera su propia librería Javascript para animaciones e interactividad


En general, creo que la actualización es bienvenida para la gran mayoría de los usuarios, pero para los maquetadores más puristas con el código, o los que nos gusta poder tener más control sobre el mismo para extender más las posibilidades interactivas de los EPUB3, creo que InDesign sigue generando una maraña de HTML y CSS ingobernable. 

Aspecto del código CSS fruto de la traducción de una animación visual en InDesign
Si quieres aprender a maquetar este tipo de e-books, a partir de InDesign 10.1 con todo lo que da pero aprendiendo además otros trucos y técnicas para controlar la edición de este tipo de libros, te invito a que pruebes nuestro curso online de Maquetación de libros EPUB3.

¡A crear y a publicar se ha dicho!

Curso online de CSS avanzado para EPUB

A día de hoy, aplicaciones como Adobe InDesign CC 2014 produce libros electrónicos en formato EPUB (versión 2 o 3) de manera bastante eficiente. Atrás quedaron los tiempo de las versiones CS3, CS4… donde el resultado de la exportación de un documento EPUB requería casi obligatoriamente de editar las hojas de estilo CSS de forma manual para lograr un resultado mínimamente profesional.



Sin embargo, si te dedicas a la edición de e-books en este formato EPUB, es recomendable tener cierto dominio del lenguaje de estilos CSS aplicado a los libros electrónicos, por varios motivos:

  • La interpretación de los estilos CSS varía dependiendo de la plataforma o entorno (e-reader, Android, iBooks, etc.)
  • Algunos ajustes finos en el aspecto del texto o filigranas requieren de una edición detallada de las hojas de estilo CSS
  • Libros más sofisticados pueden requerir del uso de varias hojas de estilo
Es por eso que, si ya sabes cómo maquetar e-books en formato EPUB a un nivel básico, te ofrecemos un taller online donde te enseñaremos algunas técnicas avanzadas de lenguaje CSS para que aprendar a depurar la maquetación de tus libros electrónicos para que tengan un acabado perfecto. En este curso trataremos los siguientes temas:
  1. Controlar la partición de sílabas 
  2. Control de viudas y huérfanas 
  3. Mantener palabras o párrafos unidos 
  4. Ejemplo práctico: poesía en EPUB 
  5. Uso de pseudoclases CSS 
  6. Transformaciones geométricas Webkit 
  7. Capitulares y Versalitas
El curso tiene una duración de un mes, durante el cual podrás acceder a tutoriales, ejercicios y archivos de ejemplo, foros, etc. y que incluye tres sesiones en directo con el profesor.

¿Cuándo?  

a partir del 9 de Julio de 2015

¿Dónde? online, cómodamente desde tu casa u oficina 😉

¿Cómo obtener mi plaza? 

Simplemente date de alta en nuestro Campus Virtual y automatrículate en el curso que desees. O llámanos al +34 606 13 14 84 o por e-mail a formacion@publicarendigital.com





¿Qué debería ser un e-book?

Para conmemorar el retorno de las vacaciones de verano, he decidido escribir un artículo revival, de esos cuyo título debería acabar con la palabra revisited. Hace casi cinco años que inauguré este blog con un post seminal titulado ¿Qué es un libro electrónico?

Transcurrido este tiempo y no pocos artículos, creo que toca reescribirlo. ¿Por qué? Pues porque en estos cinco años se han ido sucediendo una serie de evoluciones en el ámbito del hardware, del software y de los mercados que hacen que merezca la pena hacer un alto en el camino para reflexionar pausadamente sobre qué se ha hecho, que se está haciendo (bien o mal) pero sobre todo, qué se puede hacer de ahora en adelante en este pequeño gran universo del e-book y la prensa digital.

Al análisis que estoy a punto de exponer he querido sustraerle las consideraciones más mundanas, como cuál es el formato más producido, cuál es el soporte más vendido o la tienda de e-books más exitosa. El motivo es que me interesa que este artículo tenga algo más de recorrido que un análisis más vinculado a circunstancias volátiles. Así pues, haré un pequeño esfuerzo de abstracción sobre la cuerda floja de la especulación, sin red, con la sana intención de suscitar un debate o una reflexión (pública o privada) sobre este tema.

¿Qué debería ser un e-book? Tras muchas horas de meditar a ratos libres sobre ello, la respuesta que me viene a la mente sería: una suscripción.



Desde que Amazon popularizara el libro electrónico con su dispositivo Kindle, el producto ha ido evolucionando en funcionalidad y prestaciones acompañado por la evolución del hardware, que experimenta una migración progresiva de los e-readers de tinta electrónica hacia los tablets y smartphones. Sin embargo, la esencia del e-book sigue siendo un reflejo del libro tradicional en papel: una estructura casi idéntica, un aspecto paginado, un índice, notas al pie de página etc. 

En mi opinión esta arquitectura o diseño es algo rígido y por lo tanto una desventaja para el arraigo del libro electrónico. Y es que el principal competidor de este producto es una vieja conocida: la web.

Una página web ofrece una experiencia de lector (RX) mucho más ágil y por lo tanto más acorde con la forma de consumir contenidos de nuestro tiempo. A pesar de que muchos de los elementos de la web están presentes en el e-book (al tratarse de la misma tecnología) como por ejemplo los hipervínculos o el contenido multimedia, la capacidad de adaptación y actualización de la web sigue siendo muy superior a la de un libro. 

El dilema está en que no es factible ni práctica la conversión de un e-book en una web. El tipo de lectura en esta última no facilita la concentración durante un tiempo adecuado en unos contenidos confinados y circunscritos en una materia. La lectura en la web es una lectura ligera, superficial, sujeta a cambios rápidos y distracciones constantes, donde el contenido es actual al minuto y los tiempos de lectura casi que se pueden calibrar en segundos.

Esto es especialmente marcado en el mundo de la prensa, donde los lectores en papel siguen su tendencia hacia el abismo y donde los números de suscriptores a las versiones para tablets a penas dan para alguna alegría al editor. Los usuarios optan por lo más práctico, por la versión web de periódicos y revistas. Contenidos ágiles, adaptados a la lectura móvil en la mayoría de los casos y con la posibilidad de compartir información en las redes sociales al instante. Ésa es la RX demandada. En comparación, la lectura de un e-book se antoja como algo incompleto, demasiado cerrado. 

Quizá en el caso de una novela esa sensación no sea tan acentuada ya que son el tipo de contenidos más fáciles de encapsular, pero para los libros de texto, los ensayos, los libros técnicos etc. el e-book es un difícil competidor para la web.

En este tipo de libros, las referencias son constantes y abundantes, y el representarlas como notas al pie del capítulo o al final del libro –como en el caso del libro en papel– sabe a poco, por más que estas notas dispongan de hipervínculos de ida y vuelta. El acceso a la información tiene que ser rápido y conciso. En este sentido, la aplicación iBooks para iOS incorporó recientemente la nota al pie de página interactiva en forma de globo emergente. Un tímido paso pero que sin embargo es indicativo de la inquietud de Apple por querer evolucionar el libro electrónico. Fue también la tienda iBookstore la que incorporó el mismo concepto que ya tenía en su homóloga de aplicaciones Appstore, el de descarga de actualizaciones.

iBooks 3 permite notificar al lector sobre la actualización de los
libros que ha comprado en iBookstore (imagen de TidBITS)


Y es que ya sabemos lo difícil que es lograr que un lector de nuestra cultura pague por un e-book. “¿Para qué voy a pagar 4,99€/$ por un contenido que está gratis en la web?” es una reflexión que no pocos hacen en silencio o en público.

 Y sí, ciertamente podemos llegar a leer, ver y escuchar todo lo que un libro electrónico tiene que decirnos si somos los suficientemente sagaces con el Google. Sin embargo, a nadie se le escapa que esa información aparecerá a los ojos y oídos del usuario como un cúmulo desorganizado de diferentes fuentes, y a menudo con una apariencia poco atractiva para la lectura. Incluso la mayor parte de los libros web online están intrincados con banners monetizadores que la dificultan.

Por más que a los más jóvenes se les esté olvidando alarmantemente, el libro sigue siendo el mejor vehículo para el aprendizaje sólido. Y en la era de las redes sociales, del márketing 2.0 (o 3.0!) y las relaciones bidireccionales entre las marcas y sus clientes, un libro que pretenda ser comercializado no puede ser un baúl estanco que se compra, se lee en soledad y luego se deja olvidado en un cajón de la nube. Ha de ser una experiencia actualizada e interactiva.

No solamente Apple ofrece la posibilidad de ir avisando de la posibilidad de descargar actualizaciones de los libros que compramos a la par que facilita dicha tarea a los autores y editores. Amazon implementa en su aplicación Kindle la posibilidad de ver discretamente qué fragmentos del libro que estamos leyendo han sido subrayados por el resto de lectores que lo compraron y leyeron.

La app Kindle de Amazon permite ver los subrayados populares
 entre la comunidad de lectores de un libro.


Todos estos detalles ayudan sin duda a fidelizar al lector, no solamente con el libro y el autor, si no con el formato y la forma de consumir contenidos, de tal modo que perderse por la web le resulte menos atractivo, hasta el punto de concluir que no merece la pena. Ése creo que debería ser el objetivo de todos los que estamos metidos en este ajo de la publicación digital, ya sea como autores, editores, lectores, divulgadores, etc.

En resumen, el libro electrónico debería ser una publicación por la que el público paga por suscribirse a él, en el sentido amplio: paga por el derecho a recibir actualizaciones periódicas en exclusiva, por pertenecer a una selecto club de lectores, por tener un trato más cercano con el autor etc. De este modo y si los contenidos son los suficientemente bien elaborados y de calidad, habrá una masa crítica de lectores que abandonen paulatinamente la idea de que es preferible obtener lo que buscan gratuitamente por otros medios, e incluso así los precios de los e-books o de posibles suscripciones podrían situarse en niveles que hagan que este negocio pueda (volver a) merecer la pena.

Curso: Crear Web Apps con InDesign

En un artículo anterior hablábamos sobre la conveniencia de seguir creando Apps «clásicas» o pasarse al mundo de las «web apps».

Para crear Web Apps, básicamente hace falta lo mismo que para hacer Webs: código HTML, CSS, Javascript, etc.

Sin embargo, podemos crear atractivas Web Apps maquetadas desde Adobe InDesign, usando el plug-in «in5». 


En nuestro curso «Creación de Web Apps con InDesign» te enseñaremos cómo convertir una maquetación basada en páginas desde InDesign en una Web app interactiva HTML5 con animaciones, vídeo, sonido e interactividad básica y avanzada.

Temario:

  • Instalación del plug-in in5
  • Plantillas de páginas
  • Exportación en Web HTML5
  • El concepto de Web App offline
  • Animaciones con InDesign
  • Botones Interactivos
  • Vídeos
  • Gestión de la Caché
  • Exportación y personalización de la App
¿Qué necesito saber para este curso? Conocimientos básicos de maquetación con Adobe InDesign.

¿Cuánto cuesta? 59€

¿Cuándo será? Del 10/10/2014 al 30/10/2014

¿Dónde? ONLINE, a través de nuestro Campus Virtual

Entra y regístrate gratuitamente en el campus. Una vez registrado te podrás automatricular en los cursos que desees automáticamente.

Más información y reservas: escríbenos a formacion@publicarendigital.com  o llámanos / whatsappeanos al 606 13 14 84


El estancamiento tecnológico del e-book

Aunque pueda sonar algo chocante, en mi opinión el mundo del libro electrónico –el «clásico» es decir el autocontenido en un solo documento EPUB o PDF, etc.– está algo estancado y padece de cierta ‘represión tecnológica’, o mejor dicho, sufre de falta de innovación, de auténtica innovación.  Quizá por ello el e-book está siendo esa ‘eterna joven promesa’, algo que no acaba de despegar de manera brillante, frente a otras formas de consumir información más sólidas y persistentes como es el caso de la Web (esa vieja tozuda que ha sobrevivido a todo y que sobrevivirá a las apps también).

Desde que irrumpieron en el mercado, los e-books se han abierto paso cómodamente debido a que los usuarios se han dado cuenta de las obvias ventajas y comodidades que conlleva (portabilidad, interactividad, coste, etc.) y por lo tanto han adoptado rápidamente la nueva tecnología.

Sin embargo, creo que nos hemos quedado ahí estancados en un modelo de producto que dista muy poco de ser una mera réplica en digital de un libro en papel. Es decir, en lugar de aprovechar las posibilidades que nos ofrecen los soportes digitales –el hardware– para literalmente reinventar el concepto de libro, se han desarrollado «nuevos productos viejos» asfixiados bajo el corsé del paradigma del libro de papel. Si bien tomarlo como referencia para evitar que un producto demasiado innovador o demasiado disruptivo fuera a fracasar, aferrarse a él creo que está siendo una equivocación.

Un ejemplo de ello podría ser el célebre efecto visual de «doblez de página» que tanto furor despertó hace algunos años cuando se empezó a implementar en la Web o en CD-ROM multimedia (usando tecnología Adobe Flash) y que posteriormente adoptó por ejemplo Apple en su app lectora de libros electrónicos iBooks. 

A día de hoy la razón y la cordura se va aposentando después de esa absurda fiebre inicial y ya hay bastante consenso en que dicho efecto visual no tiene sentido, y se va retirando progresivamente de las aplicaciones de lectura, aunque hay que decir que muchas lo mantienen como opcional, como por «vergüenza torera» de no querer ser el primer valiente en proscribir semejante horterada inane.

Los e-books siguen tozudamente pareciéndose a los libros en papel


Pero ése sería un ejemplo menor, a mi modo de ver.

Pensemos por un momento en un libro electrónico típico, un EPUB o un PDF. Por más multimedia o demás luces de colores que contenga, su estructura sigue siendo igual de rígida que la de un libro en papel: paginación, tabla de contenidos, lectura lineal, etc. En este punto alguien me podría replicar que los hipervínculos interactivos permiten romper eso y efectuar una lectura no lineal del libro, lo cual es cierto, pero hay que ir más allá. Bastante más allá. Y para ello tenemos que dejarnos de prejuicios, apartar de una dichosa vez la mirada del libro en papel y empezar a fijarnos en otros paradigmas. 

¿Cuáles? Adivinen…

El formato más extendido de libro electrónico es el formato EPUB. Dicho formato no fue una creación ex nihilo si no que está cimentado sobre los estándares de la web: el HTML (para estructurar los contenidos), el CSS (para darles formato), el Javascript (para la interactividad) y el XML (para los metadatos) y finalmente la compresión ZIP para agregarlo. 

En paralelo al desarrollo de este formato, la propia Web ha seguido evolucionando con la irrupción del HTML5 y todo lo que conlleva. Aunque parte de la innovación del HTML5 está presente en el EPUB 3, seguimos fabricando e-books que siguen el mismo paradigma y siguen adheridos al mismo esquema rígido que los libros en papel, en lugar de dar rienda suelta a todas las posibilidades que nos ofrece la tecnología. 

Un ejemplo muy simple: estos días estoy maquetando una memoria de un congreso, en formato digital y en papel. Es decir, el típico documento con una tabla de contenidos dividida en capítulos y luego en títulos de ponencias, un índice alfabético de autores al final, etc. 
Mientras hago el trabajo me surgen ideas en paralelo a cierta sensación de impotencia: ¿No sería ideal que el usuario pudiera elegir cómo está organizado el contenido del libro? Es decir, que pudiera, con un simple gesto, leer el libro dividido no en capítulos por ponencias, si no en ponencias agrupadas por autor, tema, etc. o al menos siquiera indexarlo de ese modo. 

Esta funcionalidad, simple de cara al usuario, es algo fácil de implementar por ejemplo en la Web, donde una petición al servidor resulta en una nueva consulta a una base de datos, que rápidamente dispone la información organizada según otros criterios y la envía para que sea presentada de otro modo. Esta agilidad y versatilidad en la manera de consumir contenidos de momento no solo no ha sido igualada por los libros electrónicos al uso si no que no tiene pinta de cambiar a corto plazo. Al adoptar las tecnologías que lo harían posible pero a la vez al seguir auto-limitándose a un formato secuencial, paginado e indexado estáticamente, parece que la única alternativa para poder fabricar contenidos que posean la agilidad que buscamos sea crear un aplicación o –cómo no– seguir bajo el fiable paragüas de la Web. 

Pero entonces ¿en qué lugar quedará el e-book? ¿Será barrido o asimilado por una persistente Web que cada vez más se amolda a lo que debería ser realmente un libro electrónico?


¿Qué opinión tenéis al respecto?

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?