22 de diciembre de 2013

El futuro: ¿Apps o Web Apps?


Durante los últimos 2-3 años hemos vivido una especie de 'fiebre' de las apps para móviles. Desarrollar una app, de lo que fuera, parecía –y todavía parece– como un elemento obligatorio para el correcto desarrollo del branding de una empresa u organización.

Cuando la tienda de aplicaciones de Apple, la AppStore, inició su andadura hace unos pocos años, el negocio de vender aplicaciones de todo tipo a precios 'populares' y en un mercado global se antojaba como un negocio suculento. En sus inicios la AppStore se empezó a llenar tímidamente de todo tipo de apps sin demasiado criterio: por un lado aparecían auténticas obras de arte de la programación en forma de sofisticados juegos o utilidades de ofimática, mientras que por otro lado no eran menos los oportunistas que convertían una pequeña colección de imágenes JPEG reunidas a última hora en una supuesta guía turística por cuatro dólares (o euros), aprovechándose de la permisividad de Apple, en aquella época interesada en inflar el número de aplicaciones disponibles en su tienda.

Con el furor de los últimos dos años, todo el mundo se ha subido al carro de las apps, no solamente para AppStore si no también para Android, es decir para el Play Market. Esta fiebre ha producido algunas consecuencias curiosas que me gustaría destacar, a saber:

1) Sacar al mercado apps demasiado específicas: si bien hay apps para utilidades cívicas o sociales de lo más práctico (como la que permite renovar una zona de estacionamiento de pago sin tener que acudir al coche a una máquina en la calle), también es cierto que a menudo, con tal de aparentar modernidad algunas organizaciones sacan a la luz 'con bombo y platillo' apps tan específicas que bien podrían ser meros apartados de una app más genérica, como por ejemplo ésta que permite localizar las fuentes más cercanas. Seamos prácticos: es mucho más simple y deseable tener todos los puntos de interés (¡fuentes incluidas!) dentro de una única app de geolocalización urbana como Foursquare o el mismo Google Maps que tener nuestra pantalla de inicio atestada de apps diversas, una para localizar cada uno de ellos ¿no?

2) Devaluación de las apps por saturación: se estima que en Julio de 2009 había unas 65 000 aplicaciones en AppStore. En Noviembre de 2013 se estima que esta cifra ha superado el millón, cantidad similar a la que maneja la Play Store de Google (si bien con una calidad dispar). Es decir, el mercado está saturado y esto ha provocado que, entre otras cosas, siempre haya una app gratuita que compita con su equivalente de pago, aunque ésta última sea mejor.


Número de apps en el mercado de Android (Play Market) hasta Diciembre de 2013. (Fuente: Appbrain)


 La consecuencia directa es que el modelo de negocio basado en la venta de apps de pago –que se las prometía muy felices– está muerto, como sugieren las últimas estadísticas. En su lugar se está imponiendo un modelo llamado Freemium, consistente en el acceso gratuito a las apps y su posterior monetización mediante la compra por separada de complementos (las llamadas in-app purchases) o bien mediante publicidad adaptada dentro de la app.

3) Descenso de la visibilidad de la app en la tienda: al principio de la 'fiebre del oro' de las apps, no eran pocos los que confiaban en que bastaba con subir una aplicación a AppStore para que, por un mágico mecanismo de percolación ascendiera hasta el Top 10 o Top 50 de las más populares. Hoy en día, aun con un buen planteamiento de marketing por redes sociales, no es tarea fácil conseguir una tasa de descargas que garantice que nuestra app aparezca ni tan siquiera en el Top 100.

Teniendo en cuenta estos factores, y constatando que el consumo de información se hace cada vez más a través de dispositivos móviles (sobre todo smartphones) ¿qué futuro tienen las apps? ¿Es hora de pensar en lo que vendrá después? En ese caso ¿qué vendrá después?

Pues parece ser que será una vieja conocida, una superviviente veterana que parece que resiste a todas las modas: la Web. O la web evolucionada más bien. ¿En qué me baso para decir esto?

  • Exceptuando las aplicaciones más sofisticadas (videojuegos básicamente), ya son muchas las apps, sobre todo del tipo editorial o social, que están programadas en HTML5, el estándar multiplataforma de la web. Si una app no requiere de la máxima potencia de la CPU del dispositivo móvil, se puede evitar programar dos veces la misma app (con XCode y con Java) para iOS y Android si se desarrolla con tecnología HTML5.

  • Una web con diseño adaptable a pantallas móviles puede tener el mismo aspecto y funcionalidad que una app, y de paso librarse de las restricciones que supone depender de un mercado para su distribuciónEs decir, si planteamos nuestra app como una 'Web App', la experiencia de usuario será prácticamente la misma. Éste, en lugar de tener que descubrir nuestra app buscando en la AppStore o Play Market, entrará en una URL nuestra (a través de un código QR, por ejemplo) y podrá añadirla a la pantalla de inicio junto con el resto de apps. Con este método, al no tener que estar sujetos a ningún market, evitamos procesos de aprobación, gestión de certificados digitales, así como el problema de la actualización de las versiones. Con una webapp se puede conseguir que ésta se actualice sola y de forma silenciosa (sin que intervenga o interrumpa al usuario).

Por ejemplo, el otro día al intentar acceder a Facebook a través de su aplicación móvil en mi smartphone, ésta me obligaba a actualizarla antes de poder acceder. ¿Qué hice entonces? Pasar por alto este impedimento entrando a la versión móvil de la web de facebook, que supone una experiencia de usuario muy similar y 'siempre está actualizada'. A partir de entonces he abandonado el acceso móvil mediante app y me he acostumbrado a tener siempre abierta una pestaña de m.facebook.com en mi navegador. ¡Es más usable!


o actualizas la app o nada...


  • Más que una app para cada utilidad específica, tiene más sentido desarrollar una web app con todos esos servicios centralizados en un interface simple y práctico

  • Desprendernos de la dependencia de los mercados hace que las webapps no se puedan monetizar directamente puesto que no existe ya ninguna barrera de pago para acceder a ellas. Pero, según lo visto anteriormente, éste ya no es el modelo de negocio que funciona de todos modos.


Algunos grandes medios de prensa como Financial Times vieron hace ya tiempo esto y se pasaron de forma decidida al formato de la WebApp como forma más sencilla de publicar sus contenidos digitalmente para tablets y basándolo en un negocio de suscripción donde no tengan forzosamente que entregar el 30% o 40% de sus beneficios a terceras partes (Apple o Google).

Aspecto de la web app del Financial Times en un tablet


Si tú también lo ves claro y te interesa aprender a desarrollar tus propias WebApps, puedes inscribirte a nuestro taller online de diseño de Web Apps para iOS / Android con HTML5 y Dreamweaver. 



¡Te esperamos!

10 de noviembre de 2013

¡Publicar en Digital visita México!


Desde nuestros inicios allá por 2009 han sido crecientes los mensajes de interés que hemos recibido del otro lado del Atlántico, concretamente de México, Chile, Argentina... pues bien, finalmente nos hemos decidido y coincidiendo con la Feria Internacional del Libro de Guadalajara... ¡Publicar en Digital lleva sus mejores cursos de formación profesional en Ediciones Digitales a México!

Serán tres talleres intensivos:




Adobe Digital Publishing Suite (DPS), revistas interactivas para el iPad realizadas con Adobe InDesign:

      • México DF (en el museo mexicano del diseño MUMEDI) los días 29 y 30 de Noviembre de 5 a 9 PM
      • Guadalajara (Col. Moderna) los días 3 y 4 de Diciembre de 9 a 13 h




iBooks Author, la aplicación gratuita de Apple para crear y publicar libros electrónicos para el iPad y también para Mac OS, y venderlos en la iBookStore:

      • México DF (en el museo mexicano del diseño MUMEDI) los días 29 y 30 de Noviembre de 9:00 AM a 01:00 PM





El precio de estos talleres es de $1500, pero existen posibles descuentos para inscripciones tempranas.

Aprovecha esta excelente oportunidad para subirte al carro de la industria de la edición digital que ya está triunfado en Estados Unidos y Europa, y fórmate con los mejores profesionales del sector. Se entregará diploma del curso firmado por experto certificado Adobe ¡Será una experiencia única!

Rellena el formulario de pre-inscripción al final de esta página y nos pondremos en contacto contigo enseguida para darte más detalles sobre cómo formalizar tu plaza en nuestros talleres. También puedes escribirnos un e-mail a mexico2013@publicarendigital.com

¡Te esperamos!

2 de noviembre de 2013

Maquetando poesía en EPUB (2): Partición de estrofas

En el artículo anterior de introducción a esta serie dedicada a la maquetación de poemas en EPUB, se había introducido una técnica para evitar la partición (ni por palabras ni por sílabas) de los versos de una estrofa, mediante la añadidura de una propiedad CSS a tal efecto. De este modo es posible asegurar que el reflujo del texto dentro del e-reader (al cambiar el tamaño del cuerpo del texto) no rompa los versos del poema de ninguna manera, preservando entonces la disposición visual de los mismos y facilitando entonces la lectura e identificación de la métrica del poema.

Sin embargo, la contrapartida es que el texto de dichos versos puede acabar desbordándose por el margen derecho de la pantalla, quedando por lo tanto invisible para la lectura.

En esta segunda parte vamos a abordar tres técnicas adicionales de control de versos y estrofas. De este modo dispondremos de más recursos a la hora de abordar el problema de cómo queremos que se visualicen nuestros poemas en EPUB una vez que éstos refluyan por la pantalla del e-reader (o tableta, o smartphone claro está):

He aquí de nuevo un ejemplo de poema maquetado en Adobe InDesign CC. Se trata de una Rima de Gustavo Adolfo Bécquer, donde al igual que en el ejemplo del artículo de introducción, se ha limpiado el texto original de tal modo que cada estrofa es un solo párrafo y cada verso está separado por saltos de línea forzados.:



En una de las estrofas de esta rima, aparece al final un verso suelto con una sangría diferenciada:


Aquí la persona que en su día transcribió este verso recurrió a acumular caracteres de espacio en blanco para implementar dicha sangría. Lógicamente existen otras formas de hacer esto, tanto en maquetación fija para papel como en maquetación fluida para dispositivos electrónicos. Sin embargo esta forma de sangrar nos sirve como ejemplo para conocer qué sucede con toda esta ristra de espacios en blanco una vez exportamos este documento a EPUB. 

InDesign añade todos esos espacios en blanco en el código, pero lo hace como caracteres básicos no como entidades HTML de espacio de no separación, que sería interpretable por el lector ADE, así que obtenemos este resultado:


donde se puede apreciar claramente que desapareció la sangría. El código HTML generado sería el siguiente (el estilo de párrafo de las estrofas en este caso se llama 'estrofa'):


el espacio en blanco que se ve antes del verso de "Tal es la inspiración" son dichos espacios en blanco —copiados y pegados desde el código en Dreamweaver— pero que el lector lógicamente ignora, al igual que lo haría un navegador web.

Una forma sencilla de que el e-reader respete literalmente el formato manual de una estrofa, fabricada a golpe de saltos de línea, espacios o tabulaciones, para disponer los versos de una manera peculiar determinada, es establecer una equivalencia entre un estilo de párrafo de InDesign y una etiqueta HTML específica que respete esos formato manual. Una opción podría ser dedicar un estilo de párrafo específico a esas estrofas y, en la definición de dicho estilo en InDesign, asignarle manualmente la etiqueta reservada para texto preformateado en la opción 'Etiquetas de exportación':



Al hacerlo, el aspecto visual a base de formatear añadiendo espacios se preserva en el lector. Sin embargo, al igual que cuando forzábamos la no partición de los versos, si aumentamos demasiado el texto, éste se acaba perdiendo por el margen derecho de la pantalla:


El código HTML equivalente que exportaría InDesign para este estilo de párrafo específico sería el siguiente:




donde se emplea la etiqueta "pre" en lugar de la de párrafo "p".

Otro asunto pendiente es la separación de las estrofas en páginas. En este caso, la rima consta de estrofas compuestas por cuatro versos cada una (excepto las que tienen ese 'verso suelto' extra, que tienen cinco). En la imagen anterior se puede observar que al final aparece, solitario, el primer verso de la siguiente estrofa. Esto es fruto del reflujo de texto, que va rellenando "pantallas" a medida que vamos cambiando el tamaño del mismo o, en el caso de ADE para ordenadores, también el tamaño de la ventana del software. 

Si no queremos que esto ocurra, podemos optar por varias soluciones:

1) Desde el mismo InDesign, podemos editar el estilo de párrafo de las estrofas, y ahí en Opciones de Separación, activar la opción de "Conservar todas las líneas juntas" de cada párrafo de ese estilo:


Este cambio tiene un doble efecto: además de conseguir que las estrofas no se dividan en la paginación que hace el e-reader al refluir el texto, también hace lo propio en las páginas del documento de InDesign. Al exportar dicho documento a EPUB, InDesign consigue este efecto modificando la propiedad CSS orphans (huérfanas) de este modo:

  orphans:99;

2) Dejando intacto el estilo de párrafo en InDesign, una vez exportado el EPUB podemos editar la hoja de estilos CSS que éste genera, y modificar allí el estilo de las estrofas añadiendo una propiedad adicional: display: inline-block;

con Adobe Dreamweaver es sencillo retocar el código CSS con precisión con la ayuda de la opción de autocompletar dicho código mientras se escribe. Aquí en la última línea de CSS se añade la opción "display: inline-block" de esta manera.


De este modo, utilizando cualquiera de estos dos métodos, al visualizar el poema en el lector tipo ADE, el poema sólo puede leerse en estrofas completas y no partidas, aunque se induzca el reflujo de texto cambiando el tamaño de la ventana o el cuerpo del texto, como se puede apreciar en el siguiente vídeo:


Sin embargo, y ya para finalizar, se puede observar que todavía los versos pueden partirse por sílabas. Si no queremos que se produzca ese efecto, es posible hacerlo, pero tendremos que recurrir a editar levemente el código CSS si queremos que surja efecto tanto en iBooks de iPad como en e-readers tipo ADE (Sony Reader, por ejemplo).

En las opciones del estilo de párrafo en InDesign, si desmarcamos la opción de Separación por sílabas, ésto tendrá efecto en el estilo CSS equivalente al exportar en EPUB de la siguiente forma:

          -epub-hyphens:none;
    -webkit-hyphens:none;

Sin embargo, éstas dos propiedades no funcionan en ADE. Es preciso añadir una propiedad extra específica para este tipo de lectores ("adobe-hyphenate"), de tal modo que el fragmento de código CSS resultante modificado quedaría así:


     -epub-hyphens:none;
  -webkit-hyphens:none;
  adobe-hyphenate:none;

De este modo nos aseguramos que ningún verso de las estrofas de ese estilo se partan por sílabas.

Existen otros muchos métodos para manipular los estilos CSS de un archivo EPUB de tal modo que se acomoden a nuestras necesidades de maquetación. En próximas entregas de esta serie de artículos dedicados al género de la poesía iremos desgranando algunos más. 

Por lo pronto, si estás interesado/a en aprender más de estilos CSS aplicados a EPUB, te puedo recomendar mi curso en vídeo "CSS específico para EPUB" para que puedas aprender a tu ritmo y desde casa este interesante mundo:






31 de octubre de 2013

Maquetando poesía en EPUB (1): Introducción

A raíz de un interesante debate técnico en un foro sobre cómo maquetar poemas en formato electrónico, he decidido dedicar una pequeña serie de artículos a esta materia. Aunque no es una tarea complicada, diseñar libros de narrativa electrónicos en formato EPUB 2 tiene sus intríngulis, más aún si se trata del género lírico, donde las diferentes métricas a respetar han de encajarse en un entorno de texto fluido al antojo del lector (dicho aquí "lector" en el sentido amplio, tanto la persona que lee como el aparato e-reader).

Así pues, me dispongo a desglosar paso a paso algunos aspectos de la maquetación de poemas en este formato, siguiendo un flujo de trabajo basado en Adobe InDesign CC y, por supuesto, en CSS; y enfocado tanto a e-readers de la clase de Adobe Digital Editions como iBooks para iPad/iPhone.

Éste sería el aspecto típico de un poema "en bruto" tal y como puede aparecer tras colocarlo desde un archivo de texto, Word, o copiando y pegando:



Al mostrar los caracteres ocultos podemos observar algo frecuente: cada verso es un párrafo, y la separación entre estrofas (el ejemplo de la imagen es un soneto) se hace así mismo con caracteres de párrafo. 

Aunque ésto no sea del todo incorrecto, el primer paso podría ser dejar cada estrofa en un solo párrafo, de tal modo que pudiéramos controlar el espaciado entre los mismos con el espacio después de párrafo en lugar de añadir párrafos vacíos.

Entonces, hay que realizar una primera limpieza del texto en InDesign, sustituyendo los caracteres de fin de párrafo de cada verso por saltos de línea forzados, y eliminando los que separan las estrofas. Es algo que se puede llevar a cabo fácilmente con la ayuda de Estilos GREP (opcion Buscar/Cambiar de InDesign):





Entonces, hay que realizar una primera limpieza del texto en InDesign, sustituyendo los caracteres de fin de párrafo de cada verso por saltos de línea forzados, y eliminando los que separan las estrofas. Luego, se puede crear y aplicar un estilo de párrafo para cada una de las estrofas, de tal modo que al final tendríamos algo como ésto:


Aquí, en la definición de dicho estilo de párrafo, aunque hayamos especificado en Opciones de Separación y Separación por sílabas que no queremos que las líneas se partan o que las palabras se rompan, al exportar en EPUB estos ajustes no tendrán efecto. He aquí el aspecto de dicho poema una vez que lo visualizamos en Adobe Digital Editions, a tamaño normal del texto:


Sin embargo, al aumentar el tamaño del texto y/o cambiar el tamaño de la ventana de ADE, para provocar el reflujo del texto habitual, obtenemos lo siguiente:


Que no es, claro está, el aspecto que deseamos, ya que han aparecido de todos modos particiones por sílabas que rompen los versos. 

En este punto, hay que realizar un sencillo retoque en los estilos CSS del libro EPUB. Con CSS es posible evitar dicha partición por sílabas de las palabras, pero en este caso queremos ir más allá, evitando que los versos se puedan llegar a partir incluso por palabras. Esto lo podemos conseguir añadiendo una propiedad adicional al estilo de párrafo CSS de las estrofas, en concreto:

white-space: nowrap;

Si usamos editores web como Adobe Dreamweaver, éste nos puede echar una mano a completar el código CSS sin errores de sintaxis:



Al introducir este cambio y volver a reconstruir el archivo EPUB, al visualizarlo con ADE y volver a forzar el reflujo de texto, obtendríamos algo como ésto:


es decir, antes que partirse, los versos quedarían ocultos por el margen derecho de la pantalla. 

Existen propiedades de estilos CSS muy útiles y específicas para el entorno de los libros electrónicos en formato EPUB, que puedes aprender a tu ritmo si lo deseas con el curso en vídeo que te ofrecemos en Publicar en Digital.

En próximas entregas de este artículo continuaremos explorando más detalles de la maquetación de poesía en EPUB, como por ejemplo las sangrías en los versos. ¡Hasta la próxima entrega entonces! :-)













3 de octubre de 2013

Asegurarse la descarga del PDF

La tendencia ya casi consolidada del todo de que los navegadores web no dependan de plug-ins externos para visualizar los diferentes tipos de formatos de archivo, a pesar de ser bastante razonable, puede traer algunos pequeños inconvenientes.

Es el caso por ejemplo de los documentos PDF vinculados dentro de una página HTML. Antiguamente seguir un link en una web que contenía un archivo PDF era sinónimo de descargar dicho documento y posteriormente abrirlo con Adobe Reader. Más adelante esta misma aplicación (Adobe Reader o Acrobat) instalaban una especie de extensión dentro del navegador (Internet Explorer, el hegemónico en aquella época) que hacía más ágil el proceso ya que ejecutaba el mismo Adobe Reader dentro de la ventana del propio navegador.

En la actualidad, aunque todavía existe este método, algunos navegadores más avanzados como puede ser Google Chrome ya son intérpretes directos de documentos PDF, y no necesitan depender de plug-ins o de tener Acrobat o Adobe Reader instalado en el sistema.

Esto tiene pros y contras. Entre los últimos podríamos destacar que Google Chrome no interpreta todas las posibles capacidades que puede tener un PDF cuando lo muestra directamente. Por ejemplo, algunos elementos interactivos como los vídeos no son mostrados (pero tampoco da ningún mensaje de alerta o error). 

Esto puede ser un inconveniente si decidimos publicar nuestros PDFs avanzados, con efectos multimedia e interactivos enriquecidos, ya que a no ser que nos aseguremos de que serán vistos usando Adobe Reader, no podemos garantizar el 100% de la experiencia de usuario en dichos documentos.

Por defecto, Google Chrome abre los archivos PDF en la misma ventana del navegador, o en una pestaña adicional si al hipervínculo al .pdf le añadimos el atributo "_blank". Si queremos forzar la descarga del PDF para dar la oportunidad al usuario a abrirlo a parte (de manera deseable, con Adobe Reader), podemos añadir el atributo download en la etiqueta del hipervínculo:



De este modo, cuando el usuario haga clic en él, el documento siempre se descargará en lugar de abrirse directamente en Chrome. Además, a este atributo se le puede forzar un nombre concreto al archivo que se descargue, ya que no tiene porqué coincidir con el del documento original que está en el servidor.


De ordinario, Google Chrome abre los PDF dentro de una ventana del mismo


Con la modificación del atributo download, el PDF siempre se descarga (para abrirlo con Adobe Reader, por ejemplo)


A fecha de hoy, este atributo funciona en los navegadores Chrome, Firefox y Opera (como podéis comprobar en el siguiente cuadrante), pero no en navegadores móviles como Safari para iOS el navegador de Android... ¡es lo que hay! ;-)





23 de septiembre de 2013

Compartir contenidos de publicaciones digitales

Las publicaciones periódicas digitales al uso (Diarios y Revistas para Tablets básicamente) se abren paso a duras penas en un mercado todavía demasiado reticente a invertir su dinero en la compra de este tipo de productos.

En parte el motivo de esta dificultad estriba en la presencia de un viejo (aunque renovado) y obstinado competidor: la Web. En lo que a contenidos digitales enriquecidos se refiere, en experiencia de usuario, pocas cosas superan a este formato. En una era donde la información que no circula rapidísimamente es descartada, La web ofrece más inmediatez y percepción de frescura que una publicación digital.

En el caso de los diarios tradicionales, las versiones digitales de la inmensa mayoría de ellos son meras réplicas congeladas de su equivalente en papel (un "PDF" por así decirlo). Mientras que el usuario cada vez más promedio va en busca de la página web del mismo diario en busca del titular de última hora o de participar activamente en la sección de comentarios de cada noticia. 

Además, con la evolución de la tecnología CSS y la aplicación de los diseños adaptables (también conocidos como responsive), es posible presentar la información de una publicación con un aspecto igual de atractivo que una App o publicación en papel. La prueba está en el número aceleradamente creciente de diarios o revistas que están adoptando la filosofía "Web App" con plantillas homogéneas entre sí.

Una ventaja de los contenidos web es que pueden satisfacer una necesidad acuciante del consumidor actual: la avidez por compartir lo visto y leído con sus amistades en las Redes Sociales (Facebook, Twitter, etc.) Éste era hasta ahora un talón de Aquiles de las publicaciones digitales al uso, que se presentaban como una especie de "caja negra" donde los contenidos no salían de ella. Si un lector disfrutaba de un artículo de una de estas revistas, ya sea por su contenido o por la experiencia de usuario, no hallaba el modo de compartir su hallazgo con su red de amistades, cosa muy fácil de hacer con —por ejemplo— un blog, ya que la inmensa mayoría ya vienen equipados con sencillos botones de compartir de Facebook, Twitter, e-mail, etc.

Lograr una solución viable e interesante para todas las partes no es sencillo, ni técnica ni económicamente. A menudo los contenidos de dichas publicaciones se descargan en la memoria interna del tablet y hay que "extraerlos" de ahí de algún modo para poderlos compartir.

A partir de aquí, los editores buscan soluciones creativas. Un ejemplo podría ser el del magazine mensual gratuito UNBREAK, donde lo que se hace es capturar una región o una página entera en forma de imagen que se puede luego compartir fácilmente en Twitter o Facebook.

Aspecto del interface de compartir regiones de un artículo como
 imágenes de la revista UNBREAK


Otra opción es la que ofrece por ejemplo la solución de publicación de Adobe, llamada Adobe Digital Publishing, donde es posible replicar los artículos que el editor desee en formato HTML5 y albergalos en una URL accesible de modo que cualquier usuario puede acceder potencialmente a ellos. En este caso lo que se comparte no es una imagen estática si no una copia exacta (o casi) del mismo artículo que está leyendo el usuario que adquirió la revista. Esta técnica podría originar un posible agravio comparativo: ¿Para qué gastar dinero en adquirir una revista digital cuando cualquiera puede entrar a su equivalente via web? Lo cierto es que esta solución es mas bien un método algo desesperado para que el editor elija qué artículos quiere dejar "en abierto" a modo de reclamo vía web y URL. Así, los usuarios que accedan por esta via libre podrán comprobar si merece la pena suscribirse o no a dicha revista, algo que pueden hacer desde esa misma página. 

Además, a partir de un cierto número de artículos visualizados "gratis", aparece una página a modo de Paywall que invita al lector a suscribirse a través de su iPad o al menos a comprar números sueltos de la revista. 

Una revista realizada con Adobe Digital Publishing permite compartir los artículos 
en Twitter, Facebook o Pinterest, así como por e-mail.

Si estos métodos para compartir contenidos y competir así con una WWW ya abierta y en constante actualización fallaran, tengo mis serias dudas sobre la viabilidad a medio plazo de este modelo de negocio. Es posible que el futuro cercano vea una lenta (o rápida) agonía del modelo "app" y vayamos a parar a una web evolucionada, con diseños atractivos, todo tipo de interactividad y multimedia, y a pantalla completa. Pero web en el fondo, con la misma esencia de hace 20 años...

Aspecto de un artículo replicado vía Web a partir de una
 publicación realizada con Adobe DPS




28 de agosto de 2013

Vender e-books en la tienda de Apple (iBookstore)

Una de las tiendas de libros electrónicos más dinámicas, después de la de Amazon, sería la de Apple, llamada iBookStore. Desde que se puso en marcha hace ya más de dos años con más de 25.000 títulos de salida, en fecha de Octubre de 2012 la librería de Apple contabilizaba más de 400 millones de descargas de libro entre los usuarios de iPhone, iPod Touch, iPad y entre libros gratuitos y de pago.

¿Cómo se pueden vender e-books en la iBookstore? ¿Cuáles son los procedimientos y requisitos?

Para empezar, hay que saber con qué formatos trabaja la librería de Apple. Los e-books adquiridos en la iBookstore han de leerse con la app iBooks, que es la que permite desencriptar el DRM de Apple. Esta aplicación permite leer archivos en formato EPUB 2, EPUB 3, iBOOK (de iBooks Author) y PDF, aunque a efectos de comercialización hay que descartar el último ya que Apple no vende libros en formato PDF.

Así pues, tendremos primero que disponer de nuestros libros en formato EPUB 2/3 (ya sea en maquetación fluida o fija) o archivos .ibook. Para confeccionar e-books en formato EPUB podemos trabajar con herramientas de software variadas, como pueden ser Sigil, Atlantis WordProcessor, Adobe InDesign u Open Office. Para crear archivos .ibook necesitamos la herramienta gratuita de Apple iBooks Author.

Una vez tengamos nuestro fondo editorial listo, tenemos que darnos de alta como proveedores de contenido en forma de e-books con Apple. Para ello, es preciso registrar un Apple ID en uno (o en ambos) de los programas de publicación que iBookstore tiene a tal efecto: el de Free eBooks (libros gratuitos), o bien el de Paid eBooks (libros de pago).






En ambos casos es necesario disponer del Apple ID y de tener los derechos de autor o editor de las obras que se deseen publicar. Aunque es altamente recomendable, Apple no exige obligatoriamente que registremos el ISBN válido de los e-books que vayamos a publicar (hay que recordar que cada edición de cada formato de un libro electrónico necesita un ISBN diferenciado).

Luego, en el caso de que registremos un Apple ID para el programa de libros de pago (Paid eBooks) es además necesario que indiquemos a Apple nuestro número de identificación fiscal del sistema fiscal de EEUU (el Internal Revenue Service, IRS). Este trámite burocrático consiste en solicitar mediante teléfono, correo o fax un número EIN (en caso de ser empresa) o ITIN (en caso de particulares). Para el EIN es preciso rellenar el formulario llamado SS-4 mientras que para el ITIN es el formulario W-7. Este paso es necesario ya que cuando Apple nos pague las regalías aplicará una retención de impuestos que, en el caso de no ser ciudadanos estadounidenses, podemos pedir su correspondiente devolución usando nuestro identificador fiscal.

Es preciso disponer de un Identificador Fiscal del IRS propio 

Una vez que dispongamos de estos datos, Apple revisará nuestra solicitud en un plazo aproximado de 48 horas. Si nos aprueban la solicitud, ya estaremos en condiciones de subir e-books a la iBooksStore. 

Para ello, el procedimiento técnico consiste en descargar la utilidad de gestión de contenidos iTunes Producer donde, además del archivo del libro, tendremos que proveer de toda la información extra adicional como capturas de pantalla, capítulo de muestra, clasificación, metadatos, etc. Esta misma utilidad también hace las veces de "epubcheck" y valida el contenido del paquete a enviar. Una vez enviado, hay que esperar unos días a que Apple revise nuestro libro y lo admita para su venta o bien lo rechace.

Sin embargo, si no nos vamos a dedicar a la edición de libros en profundidad y queremos que un intermediario nos proporcione éstos y otros servicios adicionales, una buena idea puede ser recurrir a lo que se denomina un iBookstore Aggregator



Éstos se encargan de todo, incluso a menudo hasta de convertir nuestro material al formato adecuado, además de distribuirlo en más tiendas además de iBookstore. También nos evitan el papeleo burocrático con el IRS. En España el primer Aggregator fue iBuksgrup, pero existen varios en Europa y América, como se puede consultar en esta página de Apple.

iBookstore está repleta de libros de temática variada. También es cierto que la calidad de los mismos también es variaba. Personalmente creo que merece más la pena aportar menos cantidad y más calidad a este tipo de librerías. Es relativamente sencillo reeditar la versión digitalizada de un libro en papel, sin aprovechar el proceso para aportar ningún valor añadido. Por contra, se pueden idear nuevos e-books o remodelar los existentes empleando la imaginación y el gran abanico de posibilidades tecnológicas que nos ofrece el medio.

¡Feliz edición a todos!

(Si tienes alguna duda sobre lo explicado en este artículo puedes contactar conmigo a través de Twitter: @ignaciolirio o bien @publicardigital)

30 de julio de 2013

El formato PDF: algunos Mitos y Realidades

A pesar de que el formato PDF ya lleva un tiempo con nosotros (más de 20) y es por lo tanto un viejo conocido en el mundo del diseño y la preimpresión, existe todavía bastante desconocimiento sobre sus posibilidades, sobre todo ahora en la nueva era digital donde parece ser que todo ha de ser HTML (o EPUB) o no será.

Es por eso que, a pesar de no ser la primera vez ni mucho menos que abordo este tema en este blog, me dispongo a relatar un breve listado de mitos y realidades sobre el PDF en la era digital:


  • El PDF sólo sirve para imprimir, no es un formato viable de e-book: Falso. La principal razón por la que el formato EPUB está superando al PDF como formato hegemónico de comercialización de libros electrónicos es el espaldarazo de algunos fabricantes clave, como por ejemplo Apple, al formato EPUB en detrimento del PDF. Un documento PDF se puede leer perfectamente tanto en e-readers como en tablets y smartphones, tanto en modo de maquetación fija como en modo reflujo, dispone de hipervínculos, tabla de contenidos, etc. y todo lo necesario para que pueda ser una opción perfectamente válida para distribuir e-books.

  • El PDF no se adapta para la lectura en pantallas pequeñas. Falso. Recuerdo que hace diez años (antes de la era de los tablets y smartphones) yo ya leía archivos PDFs en mi pequeño PocketPC usando la app Adobe Reader (sí, la de Adobe) y ahí podía elegir si veía mis archivos en modo maquetación fija o reflujo con una sencilla opción de menú. Estamos hablando de pantallitas de 3.5 pulgadas a una resolución de 320x240 pixels !!
Muestra de un PDF en modo reflujo en Adobe Reader para PocketPC (año 2002)

La opción de poder visualizar un PDF en modo reflujo es muy antigua, pero quizás desconcida. Si dispones de Adobe Reader (desde versiones ‘inmemoriales’) tanto para Mac como para Windows, tendrás disponible una opción de Vista en Reflujo. Ello te permitirá hacer la ventana de Adobe Reader Desktop tan estrecha como quieras, que adaptará los contenidos refluyendo el texto, pero respetando las fuentes incrustadas y, por supuesto, las imágenes en su posición original.

Esta posibilidad es una funcionalidad de Adobe Reader y no del PDF, a no ser que el archivo PDF sea una mera imagen fruto de un escaneado donde no se ha querido hacer la labor de reconocimiento de texto por OCR (opción incluida en Adobe Acrobat y que tarda segundos en hacer).


La opción de vista en reflujo está en Adobe Reader (Mac/Win) desde hace años.


Cualquier archivo PDF se puede convertir en un documento accesible según los estándares ISO vigentes usando solamente Adobe Acrobat. De este modo, la documentación digital en PDF estará certificada para ser leída en voz alta con software especial para personas invidentes, además de conservar un orden de lectura adecuado para cuando los contenidos refluyan en una pantalla pequeña (e-reader, smartphone, etc.). Por ejemplo con Adobe Reader para Android es posible hacerlo de manera muy sencilla.


Captura de pantalla de Adobe Reader para Android en un Smartphone, indicando la opción que permite conmutar de la vista de maquetación fija a la vista en reflujo


La única excepción son los dispositivos móviles iOS (iPad, iPhone, iPod Touch). ¿Por qué? Cuando Apple desarrolló su sistema operativo para móviles, decidió no sacarle el máximo partido a los PDFs y tratarlos como meros gráficos vectoriales, relegándolo entonces para usos marginales al impedir o dificultar en extremo la posibilidad de que los desarrolladores de iOS pudieran crear apps que permitieran extraer los contenidos accesibles de un PDF y mostrarlos en modo reflujo. El motivo último por el cual Apple optó por esa vía no lo sabremos del todo, pero se pueden intuir...

  • No se puede extraer información de un PDF: Casi Falso. Cuando se ideó el PDF todavía era mucho antes de nuestra era actual y su fiebre del Big Data. Ahora se desea acceder, extraer y manipular fácilmente los datos que se hacen públicos. Cuando el formato elegido para ello es el PDF, se critica que es algo inaccesible, donde es difícil de sacar información purificada.
    Ciertamente no hay —que yo sepa— ninguna herramienta que permita extraer fácil y alegremente datos de párrafos o tablas dentro de un PDF. En el caso de páginas web HTML sucede algo similar. A penas ahora empiezan a ver la luz herramientas prácticas como Scraper para el navegador Google Chrome que permiten hacer este tipo de prácticas empleando tecnologías como XPath. Hasta entonces, era casi igual de complicado extraer información pública a no ser que el organismo que la ofrecía se molestara en permitir su descarga en formatos planos como el .CSV, .TAB o .XLS (Excel). Un documento PDF se puede etiquetar para hacerlo accesible en cuestión de segundos y exportarlo en una variedad de formatos, incluyendo la hoja de cálculo Excel también. 

  • El formato PDF no es óptimo para el almacenamiento a largo plazo: Falso. Precisamente una de las variantes del PDF, el estándar ISO PDF/A es el que están usando muchas bibliotecas públicas de entidad para construir un archivo definitivo de su fondo bibliográfico.
    Este formato permite guardar diseño y contenidos abiertamente en un solo documento unificado, y tiene el respaldo de ser un estándar ISO, con todo lo que ello conlleva a efectos de fiabilidad. Otros estándares de documentación electrónica más en boga hoy en día, como el EPUB, no pueden decir lo mismo y todavía adolecen de ser formatos demasiado veleidosos y sujetos a cambios e indecisiones constantes por parte de los encargados de su promoción y mantenimiento.  

Muchos expertos en documentación digital afirman con buen criterio que el candidato óptimo para ser el formato de almacenamiento digital a largo plazo debería ser el XML. Y así es, pero hay que tener en cuenta que PDF también es compatible no solamente con XML si no que algunas versiones del mismo PDF ya se almacenan directamente siguiendo este formato. 

Cabe recordar que, por ejemplo Google, tanto en su iniciativa Google Books de archivo masivo del fondo bibliográfico histórico mundial como con su tienda de e-books Play Books emplea como base el formato PDF para poder guardar tanto la información accesible (y por lo tanto, refluible) de esos libros como su aspecto gráfico original.


Con esto no quiero decir que con el PDF todo sean bondades. Existen todavía muchos hándicaps a superar en el mundo digital sobre todo y donde no parece que este formato esté haciendo los deberes a la velocidad que debería, pero eso ya será en todo caso motivo de otro post en el futuro ;-)

9 de julio de 2013

Adobe InDesign CC y EPUB ¿Cómo ha evolucionado la cosa?

Huelga decir que, para los que trabajamos en la edición de e-books en formato EPUB usando Adobe InDesign como herramienta de cabecera, estábamos esperando la salida de la nueva versión CC (de Creative Cloud) para ver qué novedades traía en general y en la exportación de EPUB en particular.

La verdad es que InDesign CC ha introducido algunas mejoras de carácter "técnico" (lo que no se ve a simple vista) bastante prácticas y esperadas, ya que van en la senda de evitar al editor tener que retocar manualmente el EPUB para añadir fragmentos de código CSS o XML que mejoren el acabado de los libros. Sin embargo, si esperábais grandes revoluciones en cuanto a EPUB se refiere, quizá esta versión no es la vuestra todavía.

¿Cómo ha mejorado la exportación EPUB en el nuevo InDesign CC? Hagamos un breve repaso por los principales puntos de atención:


  • Exportación CSS más precisa: podemos decir que la exportación de estilos CSS en InDesign CC es algo más completa, en cuanto añade más información que no aparecía en versiones anteriores, como por ejemplo la de viudas y huérfanas, o los saltos de página forzados con la regla CSS page-break-before/after.
CSS generado por InDesign CS6

CSS del mismo archivo InDesign generado por la versión CC, 
incluyendo saltos de página, viudas y huérfanas
  • Por otro lado, el nombre del archivo de hoja de estilos que exporta es más específico, ahora se llama por defecto idGeneratedStyles.css , pensando en que no entre en posible conflicto con otras hojas de estilo CSS externas que ya tuviéramos con nombres más genéricos como template.css o similar.
  • Posibilidad de generar CSS o no para cada estilo en concreto: esta opción puede ser interesante si hay estilos orientados fundamentalmente a papel que no tenemos porqué ver en el archivo CSS final. En el cuadro de diálogo de definición de estilos tenemos una casilla nueva llamada Emitir CSS. Por defecto todos los estilos se emiten al exportar a EPUB.
Nuevo aspecto del apartado "Etiquetas de exportación" del cuadro
de diálogo de Estilos de Párrafo de InDesign CC, donde se puede 
apreciar la opción de "Emitir CSS"


  • Además de las tablas de contenido (que ahora se exportan como archivos html por separado) también se incluyen las cajas de texto que contienen los índices alfabéticos que generemos con el panel de Índice de InDesign. Estos índices además contienen hipervínculos que apuntan a diversos puntos de anclaje para cada párrafo del libro donde aparezcan cada una de las instancias del término referenciado en el índice. Estos puntos de anclaje los genera automáticamente InDesign, claro.
  • Los problemas de incrustación de fuentes ya no lo son para iBooks, y de hecho InDesign ahora exporta por fin dentro de la carpeta META-INF el clásico archivo com.apple.ibooks.display-options.xml configurado de tal manera que desbloquee la opción "Original" del menú de fuentes disponibles en la app iBooks. Esto, sumado a la reciente actualización de la herramienta de comprobación epubcheck 3.0.1 que ya no genera el clásico error de que no podía desencriptar las fuentes incrustadas por InDesign, es un gran alivio para los editores que se podrán ir desprendiendo de la "maldición" de tener que renunciar a sus fuentes tipográficas en sus libros EPUB.

Al elegir la —otrora problemática— opción de incrustar fuentes en InDesign, éste genera el archivo que permite a iBooks desbloquear la opción "Original" del listado de fuentes, permitiendo así respetar el diseño tipográfico que le habíamos dado en InDesign

Por otro lado, en lo que respecta a la exportación en CSS de Estilos de Objeto, a efectos prácticos poco ha cambiado respecto a la versión CS6. Ahora estos estilos se pueden hacer corresponder con las etiquetas HTML que elijamos con su clase CSS correspondiente, como ya sucedía con los estilos de párrafo o carácter. 
Sin embargo, la exportación CSS sigue creando esa serie de subclases CSS auto-generadas para los DIV y las imágenes por separado que, a nuestro modo de ver, son accesorios: aunque no suponen ningún problema para la maquetación, tampoco suponen ninguna ayuda...



Finalmente hay algunos leves retoques en la forma de denominar la Tabla de Contenidos en el panel de exportación de EPUB, etc.

En resumen y en una frase: InDesign CC exporta un EPUB más depurado y que requerirá de menos retoques artesanales del CSS por nuestra parte (o casi ninguno).

Sobre EPUB3, Maquetación Fija, etc. de momento, vale lo mismo que para CS6. Pero de ello ya hablaremos en un próximo artículo ;-)


Consulteu aquí la versió en català d'aquest blog