Estrenamos nueva página web, más actualizada a los tiempos que corren y que nos da una mayor flexibilidad a la hora de gestionar nuestros contenidos ya sean para el portfolio o para el blog. También nos metemos de lleno en Twitter para poder informar de nuevos trabajos, entradas del blog y alguna cosilla extra como proyectos paralelos que tenemos en el horno. Si nos sigues en @QInteractiva te mantendremos al tanto de todo

Nuestra idea es continuar con el blog tal y como lo estábamos haciendo: publicando truquitos del día a día de este mundillo, reflexiones o palabros, entre otras cosas claro. Porque también queremos emplear el blog como una forma de generar comunicación en torno a los proyectos que podamos ir publicando para poder daros detalles, contaros qué tal fue y si hubo algo que se nos atragantó en el proceso de desarrollo. Además, durante todos estos meses hemos acumulado un montón de cosillas y experiencias que queremos compartir con todos vosotros. Pero pasito a paso!

Bienvenidos una vez más a [Q]Interactiva

En Domestika hay un hilo llamado Publicaciones digitales al que me gustaría dar cierto bombo porque proporcionamos unos cuantos datos interesantes sobre este campo “nuevo” del diseño. Un servidor desconocía la existencia de soluciones diferentes a las de Adobe que pueden ser más interesantes en función del tipo de publicación o proyecto que vayamos a realizar.

Con Adobe DPS por ejemplo nos vemos obligados a suscribirnos a su servicio por un periodo mínimo de un año que supone un desembolso considerable si estamos pensando en realizar algún proyecto puntual. El servicio cuesta 355 euros al mes por lo que la suma total asciende a 4.260 € por el año que debemos pagar. Esto nos da derecho a la publicación ilimitada durante todo ese tiempo. Pero si hablamos de productos de tipo suscripción (una revista mensual por ejemplo) la cosa cambia. En la web de Adobe tienen un documento sobre ello que merece la pena leer.

En la situación en la que lo que queremos desarrollar se trate de una publicación única (un reportaje, un libro…) quizá sea más sugerente la opción de Aquafadas puesto que permiten realizar pagos en función del tipo de proyecto. Esto quiere decir que si sólo queremos realizar una publicación sólo pagaremos por una, sin necesidad de realizar el desembolso de un pago anual. Os dejo el enlace a un PDF con precios de Aquafadas. La pega es que no he probado aún su sistema de creación de contenidos pero parece seguir el estilo de DPS, es decir, plugin para InDesign. Otra pega es que actualmente su sistema no está preparado para publicar contenido en plataformas que no sean las de Apple con lo que todo el marketplace de Android, se queda fuera por el momento.

Un tercer participante es WoodWing y sus Digital Magazine Tools. Es quizá la solución mayormente enfocada al sector editorial profesional. Sólo hace falta echarle un ojo a su sistema de precios en la FAQ.

Está claro que hay otro tipo de soluciones. Entiendo que se puede crear el contenido mismamente en Flash y encapsularlo como app. Nos saltaríamos todo este proceso pero personalmente no me veo maquetando en Flash.

Resumiendo. La publicación digital se mueve, no sólo ya en formato EPUB y la cantidad de dispositivos diferentes hace que la tarea del diseñador/maquetador sea más costosa y elaborada. Si el cliente está dispuesto, adelante. Porque la interactividad editorial, ha llegado para quedarse.

Están comenzando a hacerlos públicos, y la primera serie de ellos va destinada a una recopilación bastante extensa (aunque muy resumida de las listas de enlaces que manejo personalmente… de la cual tuve que quitar muchísmos links…) sobre recursos imprescindibles para un desarrollador de web móvil. Los recursos están agrupados en temáticas bien diferenciadas:

• Parte I: Referencias generales
• Parte II: Diseño, Arquitectura y Usabilidad
• Parte III: Desarrollo
• Parte IV: Testeo y Emulación
• Parte V: HTML5 y comunidad

Y como remate final, todo esto en un archivo PDF, que podéis descargar desde aquí y que puedes distribuir si respetas las restricciones de Creative Commons.

El artículo versa sobre las aplicaciones contextuales, y es la primera entrega de una serie de dos partes, a modo de introducción para abordar posibles soluciones técnicas a las características de este tipo de aplicaciones.

Resulta que en [Q] tenemos bastante que decir sobre el tema, basando nuestra experiencia en uno de nuestros grandes retos que es Synctur, en la que trabajamos desde hace ya un buen montón de tiempo a través de Infocket, empresa donde nos puedes encontrar de la mano de quadrícula y recientemente con el fichaje estelar de Raúl Jiménez.

Aplicaciones Contextuales Parte I

Si no trabajas con sesiones que almacenan el session ID en cookies, entonces este tip no te afecta demasiado. Esto es así porque cuando se trabaja de esta forma, las cookies que se guardan son dependientes del dominio por motivos de seguridad, con lo que te protegen de lecturas externas, pero también entorpecen a veces procesos internos (por defecto cualquier subdominio (www, blog, …) se considera diferente dominio que el base).

Imaginemos que tu web está bajo el dominio midominio.com, has de saber que estarías afectado por diferentes dominios si el usuario a www.midominio.com o si accede a midominio.com. Si siempre empleas rutas relativas, respetarás el dominio con el que accedió el usuario, pero como decimos hay ocasiones en las que existen enlaces absolutos, que podrían crear el efecto de estar bajo dos dominios diferentes. Lo mismo ocurriría si trabajas sobre subodminios tipo blog.midominio.com, etc.

Para solventarlo y poder trabajar bajo diferentes dominios compartiendo la sesión, tenemos que modificar el session.cookie_domain, mediante el método session_set_cookie_params, concretamente analiza lo que indica en el parámetro “domain” de la ayuda. Esto se ha de llamar en cada petición, antes del session_start().

Sin embargo, personalmente encontramos más rápido, eficaz y directo modificar el .htaccess (que también lo permite) mediante un comando similar a este:

php_value session.cookie_domain ".midominio.com"

Este fichero ha de estar en los directorios que representen los subdominios correspondientes, de manera que las sesiones en ese subdominio, serán compartidas con cualquier subdominio del tipo xxx.midominio.com

Y finalmente… si tu problema es https… entonces te recomiendo pegarle un ojo a session.cookie_secure

Nuevamente CIMPRO confió en nosotros para darle forma y color a una de sus nuevas publicaciones destinadas a los profesionales de su sector: Ecografía Transrectal en el Estudio de la Glándula Prostática

Voy a contaros lo que me pasó el otro día: Como algunos sabéis, en el estudio hemos hecho cursos para video2brain. Estoy seguro que no es sólo por dinero. Es porque creemos en un proyecto de educación y autoformación así. Yo particularmente creo (de verdad) que tienen unos precios buenos y que se tornan en irrisorios si tenemos en cuenta lo que valen las suscripciones. Por ofrecer un dato y podáis comparar: hace 4-5 años pagué 600 euros por un curso de 3Dmax de 2 semanas de duración.

Bien. Estos cursos (y muchos otros) están disponibles poco después, desde otras páginas web en las que puedes descargarlos sin pasar por caja. Y me parece “perfecto”. De hecho hasta me hizo gracia verme a mí “pirateado”. Me picó la curiosidad y me puse a leer los comentarios de agradecimiento a la persona que cuelga el contenido y me hizo especialmente gracia uno que además de esto se excusaba basándose en el contenido de uno de los cursos para no pagar.

El contenido del curso se basa en un índice totalmente disponible antes de realizar la compra y que te sirve para hacerte una idea de qué estás comprando. Hay vídeos gratis para ver el estilo del curso e incluso regularmente puedes acceder a estos cursos gratuitamente mediante códigos que ofrecen en su newsletter. ¿Qué más quieres?

No me lo tomé como algo personal por supuesto. Es uno de los problemas existentes a día de hoy que afectan prácticamente a todo servicio o producto al que puedes acceder de manera sencilla a través de la red. Ese sector de usuarios que no piensan pagar NADA.

Ojo, que yo no soy ninguna hermanita de la caridad y en su momento mi módem de 56k o mi primera ADSL echaban humo. Hice mal. Intento ponerle remedio ahora. Puedo permitirme pagar por aquello en lo que siento que no me están estafando y encima tenga que dar las gracias.

Entiendo que hay personas que no sepan valorar lo que suponen determinados productos y en el desconocimiento se encuentre parte de la culpa. Pero cuando el desconocimiento es inexistente, ¿qué me quieres contar?

Mi problema no son los que desconocen. Mi problema no son los que descargan. Mi problema son los que lo hacen, no valoran lo que haces y encima lo usan como excusa para autoconvencerse, para justificarse. (Puedes insertar aquí la típica frase de “esto lo hace mi sobrino por menos”). Mi problema son esos eslabones de la cadena donde se busca maximizar el beneficio a costa de los demás. Intentemos reconocer lo que hace cada uno, cojones.

Esto va a terminar haciendo “crack”. Y es que pasa en todas partes: Please design a logo for me. With pie charts. For free. , Quiero hacer una Torre Eiffel por 300 euros o Nos la estamos cargando son lecturas que recomiendo como anexos a este post.

También he estado leyendo sobre los modelos freemium. Realmente creo en modelos así y en sistemas como Steam. Creo y pago por cosas así. Pictos, Toggl, Orange Commands… Hay un montón de ejemplos de productos o servicios en los que creemos y hemos pagado lo que piden por ello. Si ni siquiera lo hacemos por cosas así, ¿qué nos queda entonces?

Quiero pensar que no soy yo el problema, no al menos de manera absoluta. Quiero pensar (y así toco otro palo ya que me pongo) que Filmin o la futura Youzee son plataformas que me permitirán pagar por contenido cinematográfico y audiovisual a un valor más ajustado a la realidad. Quiero pensar que estas ideas buscan el beneficio propio (para algo son empresas) sin reirse del personal ni chuparles la sangre.

Estoy orgulloso de poder decir que en [Q]Interactiva no hay vampiros. Cobramos y valoramos lo que creemos que es justo. Ni más ni menos. Puede gustarte o no. Pero mira… no me cuentes excusas.

Voy a tratar de exponer mi visión sobre el mal uso habitual que se hace de los calendarios, ya que me gustaría que este post no sean más que mis reflexiones, sino que me fusiléis mis razonamientos todos aquellos que tengáis argumentos para hacerlo. (o aunque no los tengáis, pero entonces no esperéis que os haga caso).

El calendario es un componente que tiene principalmente dos funcionalidades en la web, la de introducción de datos, y la de organización temporal de información. Vamos a analizar ambas, aunque la primera en menor medida, la que más falla en la web habitualmente para mi es la segunda.

Esta forma de emplear los calendarios en formularios web, no solo me parece que no es incorrecta, sino que puede tener su razón de ser. Su competidor sería un selector de fechas en 3 bloques (dia / mes / año) o 2 bloques (dia / mes + año), que tiene algunas ventajas frente a los calendarios, y que para mi precisamente significan las claves para tomar una decisión correcta para cuando usarlos.

CASO A: Reserva de un vuelo de avión

En este caso, el usuario se encuentra en un contexto de búsqueda de una fecha, en condiciones habituales tiende a ser cercana (máximo unos meses de antelación), y normalmente en el caso de ser un viaje de ida y vuelta, dicha vuelta es relativamente cercana. Con esta situación un calendario aporta visualmente una referencia interesante a la hora de elegir una fecha, concretamente la ayuda visual que aporta un calendario mostrando los días de la semana, no es nada despreciable, ya que ayuda a orientar al usuario en su planificación más inmediata (la gente tiende a pensar cuando se trata de fechas próximas en formato semanal, no mensual).

De esta manera, cuando el calendario que se muestra al usuario, ya aparece situado en la fecha actual, es muy directa la selección del día deseado, con un solo clic, 2 máximo si el viaje fuera al mes siguiente. Punto a favor.

Si comparamos este sistema con la introducción por selectores independientes (dia/mes/año o dia/mes+año) podemos decir que en gran cantidad de casos el formato de calendario es mejor, ya que solamente cuando el viaje fuera muy a largo plazo, los selectores aportarían más velocidad y fiabilidad.

Como ejemplos existentes en la web de calendarios adecuados os dejo algunos:

Iberia

Se combinan las dos opciones comentadas, y además el calendario de vuelta muestra una referencia visual sobre el día de ida elegido

Rumbo

Mantiene 2 calendarios simultáneamente para ayudar más aun la referencia futura

Hotelopia

Mejora la combinación de las dos opciones aunando en un mismo selector mes y año.

Date Picker, jQuery

Concretamente el “flat mode, range selection, 3 calendars” que permite visualización de varios meses como el de rumbo, pero además te marca los intervalos de tiempo seleccionados de forma gráfica.

Y como ejemplo del tipo de selector de fechas en formato calendario que yo emplearia por su utilidad directa, os dejo el siguiente ejemplo que se utilizaba en KLM pero que actualmente han cambiado por otro diferente que pierde la velocidad de acceso a meses / años futuros:

CASO B: Selección de fecha de nacimiento

Aunque el objetivo es idéntico al CASO A (seleccionar una fecha) el caso que planteo aqui es totalmente diferente al anterior, y creo que marca la diferencia clara entre cuando un calendario puede ser útil para introducir información y cuando no. Aqui se demuestra claramente que lo que ha de definir la decisión de qué elemento visual e interactivo emplear es su utilidad final, su contexto y su lógica, no su estética.

Cuando en la web se ha de introducir una fecha de nacimiento, normalmente el usuario tiene que remontarse más de una década hacia atrás, lo cual establece un punto clave a la hora de cubrir la facilidad de acceso a fechas tan lejanas. Las fechas de nacimiento se piensan y recuerdan en “absoluto”, y sin ninguna referencia espacial en la semana o mes, es decir: 03 de Enero de 1934, ni día de la semana, ni referencia general de un periodo, ni nada.

Teniendo en cuenta que los componentes calendario que se emplean en la web tienen por lo general un acceso sencuencial para todos los periodos posibles (meses y años), retroceder a una fecha tan lejana puede ser bastante tedioso. Aqui las ventajas de un triple selector son evidententes, y no tanto de un doble selector con formato combinado mes / año para el segundo, ya que al poder tener que retroceder muchos años, la combinación mes + año aumentaría notablemente la longitud del selector).

Otro punto a tener en cuenta aqui es que es mejor marcar el mes en texto que en numérico, ya que las fechas de nacimiento se recuerdan con más claridad en este formato que en el numérico. No es crítico, pero es un pasito más para facilitar al usuario su misión.

“En estos dos casos no he tenido en cuenta la introducción manual, por el problema que puede implicar la validación de la entrada, que en el caso de los dos componentes anteriores, si están bien realizados se reduce a que el propio usuario elija mal la fecha, pero que en una introducción 100% manual implica posibles errores al teclear, cosa que hay que evitar siempre que sea posible.”

Este es el aspecto del uso de un calendario que más quiero elaborar, porque en mi opinión adolece de grandes problemas que los clientes o algunos desarrolladores, no ven, quizás por el hecho tan absurdo de querer una representación gráfica en formato calendario. Pero yo me pregunto… ¿aporta realmente algo al usuario?

Analizando lo que aporta un calendario gráfico para mostrar información:

• Información sobre el mes, semana y día en el que nos encontramos, visión conjunta a nivel de mes.
• Información visual, pero no informativa sobre determinados datos que pueden suceder en ese rango de tiempo visualizado.
• Acceso a los elementos marcados en dicho periodo de tiempo (con un click)

Ahora tenemos que preguntarnos si eso es realmente información útil o es prácticamente inútil. Digo yo…

• ¿Me aporta algo saber que el dia 5 hay algo, sin saber lo que es?
• ¿Qué ocurre si un día hay más de un item informativo?
• ¿Si pincho en un día con varios eventos o información, a dónde voy?
• ¿Qué pasa si hoy es 30 de mes, que los eventos de dentro de 3 días no son importantes para mi porque son del mes siguiente?
• ¿Por qué todo tiene que ser tan pequeño, para que quepa en una columna lateral de una web? ¿Es eso un motivo de peso para limitar la información?
• Si el calendario está vacío… ¿qué debo pensar del él?
• Y si el calendario está lleno de días marcados, ¿qué debo pensar de él? ¿tiene utilidad un calendario en el que casi todo los días se marcan de la misma manera (por ejemplo subrayado, otro color, negrita, etc.)?
• ¿Por qué he de hacer un click, o si han sido considerados un pasar por encima de un elemento normalmente minúsculo, para saber lo que hay en un día?
• ¿Me hace gracia tener que ir haciendo click en los días y volver atrás o seleccionar otro hasta encontrar la información que busco?

Estas son algunas de las preguntas más directas y evidentes… Se pueden hacer muchos esfuerzos a nivel de programación para solventar algunas de estas limitaciones, y que por desgracia no están implementadas en la mayoria de los calendarios informativos existentes, pero la pregunta es… ¿por qué complicar lo simple?

Una agenda de eventos, las noticias, las tareas pendientes por hacer, etc. no tienen tras de si el ceoncpto de calendario en su esencia, no nos confundamos, representan de manera clara un listado de elementos informativos, y como tal se deberían tratar. El calendario sirve para mostrar una referencia temporal dentro de un contexto semanal/mensual/anual, pero no para mostrar información. Emplearlo como el intermediario entre el usuario y la información me parece un craso error, estamos poniendo una barrera adicional innecesaria entre los datos verdaderamente importantes y el usuario.

De esto se han dado cuenta hace mucho los organizadores personales, las agendas, las aplicaciones de gestión de proyectos, sistemas de gestión de contenidos,… Como una imagen vale más que mil palabras, os dejo una representación que he elaborado para representar lo que quiero decir, juzgar vosotros mismos.

Una especie de dashboard de wordpress, un to-do list, un listado de eventos por proximidad, categorizado por colores, con limitaciones de rango de fechas mucho más flexibles, con posibilidad de ver los días importantes sin necesidad de navegar por meses, con posibilidad de conocer los eventos, noticias o tareas sin necesidad de hacer clic en un lugar que no sabemos a donde nos lleva…

Pues hasta aquí he llegado, ahora te toca a ti darme caña!

Ahí estaremos para poder palpar y ver de primera mano las novedades que se avecinan, y trastear con la ingente cantidad de móviles y tablets que ya incorporan Flash Player 10.1 entre sus características, bien porque van con Android 2.2 o superior, o porque directamente lo han implantado como será el caso de la PlayBook de RIM. Como no nos conformamos con esto, y el MWC es la excusa perfecta, aprovecharemos para repetir por tercer año consecutivo los DeviceDays, un evento dedicado al diseño y desarrollo para dispositivos móviles que organizamos a través de BlocketPC, y con la inestimable colaboración de Adobe.

En esta ocasión el evento tendrá lugar en la Escuela Técnica Superior de Ingeniería Industrial de Barcelona, de la Universidad Politécnica de Cataluña, con un aforo de hasta 200 personas y el programa promete ser muy interesante, con la participación de Maximiliano Firtman, la gente de Justinmind, el Adobe Evangelist Mark Doherty y por supuesto BlocketPc.

[Q] interactiva participará tanto como miembros del equipo de BlocketPc como a través de Infocket, presentando una ponencia dedicada al desarrollo multidispositivo bajo plataforma flash, y empleando para ello la aplicación Synctur, de la que pronto os podemos hablar largo y tendido…

• 09:30 – 09:45 – Bienvenida (Equipo de BlocketPC)
• 09:45 – 10:30 – Synctur, esarrollo multiplataforma con Flash (Infocket)
• 10:30 – 11:30 – COFFEE BREAK
• 11:30 – 12:15 – HTML5 para dispositivos móviles (Maximiliano Firtman)
• 12:15 – 13:00 – Safe time! Boost prototyping (Justinmind)
• 13:00 – 13:45 – Meet the Blackberry Playbook (Mark Doherty) [ENG]
• 13:45 – 14:30 – Cierre y entrega de regalos

Si te interesa el tema del diseño y desarrollo para dispositivos y tienes la posibilidad, no dudes en inscribirte a los DeviceDays, es un evento que realmente merece la pena, y no es porque lo digamos nosotros. Y con suerte te llevas alguno de los regalazos que se sortearán