Web de Nokia con todas las especificaciones y más vídeos »

Mañana sabremos las características del Nokia 5800 XpressMusic, la esperadísima respuesta de Nokia al iPhone de Apple, y que se suma a la nueva ola de dispositivos móviles con pantall táctil (iPhone, Xperia, Omnia, HTC Touch, G1…). Aunque muchos dicen lo contrario, no es el primer dispositivo de Nokia con pantalla táctil.

Las características del Nokia 5800 XpressMusic son:

- Sistema operativo S60 Taco 5
- Pantalla táctil de 3,2 pulgadas
- Resolución de pantalla 640×360 px (es decir un ratio 16:9, para películas en formato panorámico)
- 16 millones de colores
- Quatri-banda GSM (850 / 900 / 1800 / 1900 Mhz) y conectividad EDGE/UMTS-3G/HSDPA
- Wi-Fi y Bluetooth 2.0
- Cámara fotográfica de 3,2 megapíxels, con autofoco, y doble flash LED
- Grabación de vídeo con sonido, a una velocidad de 30 fps VGA
- Salida para conectar a la televisión
- 140 MB de memoria interna y soporte para tarjetas MicroSD de hasta 16 GB (viene con tarjeta de 8 GB)
- 111 mm de altura, 52 mm de ancho y 14,5 mm de grosor
- 104 gramos
- aGPS integrado
- Conector USB 2.0
- Conector de 3,5 mm para auriciulares
- Tres modos de escritura: teclado qwerty horizontal (para dedo), teclado reducido (con T9) para stylus, e incluso reconocimiento de escritura manual con plectrum o stylus (hay que enseñar antes al móvil a reconocer tu escritura manual escribiendo todas las letras).

El Nokia 5800 XpressMusic se presenta mañana jueves en Londres en un evento para presentar ComeWithMusic, aunque no se sabe si se fijará un precio, pero seguro que sabremos las características del Nokia 5800 XpressMusic.

España será el primer país de Europa Occidental en el que se comercialice, a un precio de 279 € libre (IVA no incluido), el 1 de diciembre de 2008.

El próximo 15 de Septiembre se lanzará oficialmente Woices, una nueva web 2.0 de la que tenía muchas ganas de hablar porque he tenido la gran suerte de haber podido participar directamente en ella.

Woices es una web que básicamente permite cargar sonidos, ya sean hablados o ambientales, para ser compartidos. Pero más allá de esta sencilla idea hay algo de mucha más trascendecia, porque Woices aspira a ser la memoria de los lugares. De alguna manera, Woices permite crear una especie de woicesfera, una esfera de woices alrededor de la tierra, como si de una capa más de la atmósfera se tratara; ésta creada por el hombre. La idea de Woices es guardar para la posteridad la historia de los sitios en forma de relatos o sonidos contribuídos por los usuarios. Grabar los recuerdos y la sabiduría de la humanidad en relación a los sitios que conocemos. Como tal, Woices no es sólo una web 2.0 más.

En Woices, los usuarios pueden geoposicionar en Google Maps los audios para que cualquier otro usuario pueda escucharlo en la ubicación pertinente. Los audios pueden ser relatos personales sobre un sitio especial (por ejemplo el lugar en el que te declaraste a un/a chica/o), el lugar donde sucedió algo digno de mención, el sitio en el que se encuentra una casa o un monumento que conoces bien y del que quieres hablar, etc…). Los entusiastas de la historia podrán compartir sus conocimientos sobre un lugar, a la vez que los viajantes o personas interesadas podrán acceder a esa riqueza de información para vivir el lugar de un modo más profundo, y descubrir detalles sobre un lugar que de otro modo sería casi imposible conocer.

Los audios te los puedes descargar en varios formatos para escucharlos en el ordenador, pero también te los puedes descargar a iPods o móviles (vía ordenador o via Over-The-Air), de modo que te puedas llevar los woices contigo para escucharlos in situ de un modo más inmersivo. Esta posibilidad es especialmente interesante porque puedes conocer un lugar como si alguien que lo conoce perfectamente te lo estuviera explicando al oído en ese mismo sitio.

Igualmente, se pueden enlazar varios woices para crear una ruta (llamada “walk”) en la que se irán consumiendo los woices en movilidad. Estas rutas son completamente personalizables enlazando varios woices cercanos entre ellos, y pueden tener un sentido histórico, turístico, literario, deportivo… Por ejemplo un walk de los lugares descritos en una novela como por ejemplo “La plaça del diamant” en Barcelona.

La web permite subir audios, o grabarlos on-the-fly con un recorder integrado (sólo hace falta un ordenador con micrófono). En un futuro, se podrán subir woices desde cualquier dispositivo móvil mediante una conexión de datos, etiquetando ese woice con las coordenadas que indique el GPS del móvil y así poder emplazarlo en el mapa en su ubicación pertinente.

La versión para móviles está en woices.mobi, y el blog en el que se detallan los avances y novedades de este proyecto está aquí.

¿Por qué las aplicaciones open-source suelen tener tan mala usabilidad? He aquí algunas de mis razones:

- Hay pocos incentivos para que haya una buena usabilidad. Los fabricantes de productos comerciales tienen que ganar dinero para pagar los sueldos de los desarrolladores, y eso significa que se deben esforzar en que sus productos sean usables, para maximizar ventas. En el open-source no existe esta obligación.

- Muchas aplicaciones open-source se entregan “as it is”; no suele haber un sistema de soporte técnico que colapse ninguna centralita si el producto tiene una mala usabilidad. En cambio, en el software comercial se intenta evitar al máximo las llamadas al soporte técnico y ello significa que se cuida la facilidad de uso. En el open-source los problemas de usabilidad en una aplicación no suelen tener ningún impacto en sus desarrolladores.

- Por su propia naturaleza, las personas involucradas en el open-source suelen estar centradas en el código. Cualquier otro aspecto es secundario. Ello incluye el diseño o la usabilidad, que son aspectos que quedan relegados. El resultado son aplicaciones con interfaces bastante caóticas, sin orden, jerarquía o estructura visual.

- Cualquier producto open-source necesita diseño, pero en cambio suele haber pocos diseñadores en el software libre. Tal como está pensado el open-source, no es lugar para un diseñador. Por ejemplo, mientras que un desarrollador puede identificar un bug y contribuir un patch para solucionarlo, un diseñador que encuentre un fallo de diseño o de usabilidad no puede más que indicarlo, y esperar que alguien de mala gana lo intente arreglar.

- Al no haber muchos diseñadores, muchas decisiones de diseño y usabilidad se deciden sin el criterio necesario. Al igual que los mejores intérpretes de música suelen ser pésimos compositores, los mejores programadores suelen ser pésimos diseñadores. La ausencia de criterio propicia decisones erróneas y, en consecuencia, en el desarrollo de aplicaciones con las que trabajar no suele ser muy ergonómico. En segundo lugar, al no haber diseñadores las decisiones se toman a modo de compromiso entre las sensibilidades de todos los programadores, lo que resulta en una interfaz sin unidad, integridad y consistencia.

- Los bugs son objetivos, los fallos de diseño o usabilidad son en su mayoría subjetivos. Cuesta mucho más aceptar un error de diseño que un error de funcionamiento, porque aquél es mucho menos obvio. También cuesta mucho más que el grupo de desarrolladores se ponga de acuerdo sobre si algo es un fallo de diseño o esa una “feature” especial. Al ser los errores de diseño o usabilidad más subjetivos, es más dificil llegar a su identificación.

- Se programa antes de diseñar. El software suele ser mucho más usable si se diseña antes de programar, pero los entusiastas voluntarios de muchos proyectos open-source tienen tantas ganas de escribir código que prefieren saltarse los wireframes, los prototipos y los mockups. Sin embargo, estos elementos inciden directamente en el flujo de trabajo y uso de la aplicación, por lo que afecta al modelo de datos, a los algoritmos, al orden en que las acciones se realizan, etc. Programar antes de diseñar es cómo construir una casa sin planos.

- Al ser programadores, los desarrolladores suelen ser también power users. En consecuencia, las aplicaciones están pensadas para usuarios avanzados como ellos, para los que los problemas de usabilidad de una aplicación pueden ser superados sin mayores esfuerzos, pero eso no ocurre con los usuarios normales. Ejemplo de esta mentalidad de power-user es la ausencia casi total de asistentes o de prompts que guíen la navegación, elementos que en cambio suelen ser habituales en los programas comerciales.

- Los programadores open-source, al ser voluntarios, trabajan en aquellos proyectos que les interesan. Eso suele resultar en una falta de capacidad de abstracción. Al estar tan metidos en ese proyecto, a los desarrolladores les falta distancia y visión global, y la empatía necesaria para ponerse en el lugar de los usuarios. Los árboles no suelen dejarles ver el bosque.

- Por su propio carácter libre, el open-source facilita el intercambio de código y la reintegración de componentes, por lo que a menudo muchos módulos de diferentes orígenes se integran en una única aplicación. Ello suele resultar en inconsistencias en el diseño, en el manejo, o incluso en el léxico empleado de las aplicaciones de software libre, perjudicando por tanto la usabilidad.

- Todos los programadores voluntarios quieren que su pieza de software o la funcionalidad que han desarrollado aparezca en la aplicación, y cuánto más aparezca, mejor. Para aplacar ese deseo y asegurar la continuidad del voluntario, esa funcionalidad suele meterse donde quepa y de la mejor manera, pero a menudo sólo estorba y añade caos a la aplicación, tanto a nivel de diseño como de uso. Del mismo modo, quitar componentes de la aplicación para poder mejorar la ergonomía de la aplicación suele poner furioso al desarrollador que los hizo, con lo que a veces continúan aunque sean un estorbo o rompan completamente el uso lógico de la aplicación.

- Las aplicaciones open-source suelen competir unas con otras por el nivel de features que tienen, no por su diseño o por su facilidad de uso, mucho menos por obtener una cualificación mayor en la capacidad que tienen de ser usadas por los usuarios. Ello significa que la featuritis suele primar por encima de la experiencia de usuario. La simplicidad se ve como una carencia de features, no como una virtud.

- Los programadores no suelen distinguirse por su sensibilidad estética, por lo que muchas aplicaciones tienen un aspecto visual que ellos dan por bueno pero que a menudo horrorizan a cualquier usuario normal y corriente. Que las aplicaciones aparezcan bien es tan o más importante que el que funcionen bien. Un diseño pobre no sólo decepciona estéticamente al usuario, sino que perjudica sobremanera su usabilidad.

- Detalles como informar al usuario del progreso de una acción con una barra de progreso, explicar lo que  ocurrirá al presionar un botón determinado, rotular correctamente los botones y las secciones, redactar con propiedad la mensajería del sistema o la ayuda, ilustrar la interacción del usuario con el sistema con estados como hover o focus no suelen ser muy excitantes para los programadores, por lo que suelen faltar en las aplicaciones realizadas por voluntarios. Sin embargo, tienen un efecto crítico sobre la experiencia de uso de la aplicación.

Open source no es lo mismo que software gratis (freeware), ni que software libre. Estas razones no pueden aplicarse a todas las aplicaciones open-source (por ejemplo, hay aplicaciones open-source de pago con muy buena usabilidad), sino a muchas aplicaciones que aparte de ser open-source son también gratuitas.

After reading this post I wanted to post a comment, but as I began writing it sort of grew into a post by itself, so here is my response:

I think web designers should know how to build with (X)HTML/CSS but no more than an architect knows how to build with formworks and concrete. Designers think websites while coders build those websites just like architects think buildings while masons construct those buildings.

In circumstances, it is an advantage to know little of the tech details because that innocence allows for greater revolutionary thinking. Many designers who also code themselves restrict unconsciously their designs to what they can code - or to that which won’t mean a hard work to get it coded. I speak for my own experience.

At the same time, I think that knowing to code does not make a designer, just like knowing how to use concrete or formworks does not make you an architect. There are coders out there who call themselves “web designers”, but have no clue about design, about web principles, about proportion, space, hierarchy, order, balance, contrast, usability, consistency and all which makes great design great.

So while it is true that a designer who does not know HTML/CSS cannot call himself a web designer, the contrary is also true: a person who knows HTML/CSS cannot call himself a web designer if he has no formation whatsoever in design. And, by the way, print design formation helps much because much of the best principles and practices in design are universal and apply to both the offline and online spheres.

By the way, where is Flash in this debate? Or a Flash web designer is not a web designer?

Dos ideas:

El diseño es esencialmente prescriptivo mientras que la ciencia es predominantemente descriptiva. Los diseñadores no se encargan de cuestiones como qué es, cómo y por qué, sino con lo que podría ser o lo que debería ser. Mientras que los científicos pueden ayudarnos a entender el presente y predecir el futuro, los diseñadores prescriben y crean ese futuro.

Los diseñadores, a diferencia de los científicos, parece que no tienen derecho a equivocarse. Mientras que a menudo se acepta que una teoría científica que ha sido deprecada puede haber contribuido al avance de la ciencia, raramente a los diseñadores se les reconoce una contribución de este tipo.

(inspirado por How Designers Think)

Un tema recurrente en las relaciones entre diseñadores y clientes y que ya ha sido comentado, entre otros sitios aquí y aquí, es el empleo del espacio en blanco. En este post intento explorar un poco más la cuestión, pero además aportar también una manera fácil y objetiva de explicar al cliente la importancia del espacio en blanco y su papel en cualquier diseño, y así intentar evitar atiborrar cada píxel del diseño que realizamos.

El uso (y el no uso) del espacio en blanco (que por cierto, no tiene por qué ser blanco) es uno de los motivos típicos de discusión entre diseñadores y clientes. Para los diseñadores, es un espacio necesario para mantener el equilibrio y el orden del diseño. Para los clientes, es un espacio vacío y desaprovechado que podría aprovechar para introducir nuevos elementos.

En la mayoría de los casos, a grandes rasgos son los diseñadores los que tienen razón, aunque ello está exento de mérito teniendo en cuenta que se trata de una cuestión técnica de diseño. Es un hecho que el uso inteligente del espacio en blanco es un elemento esencial del buen diseño. El espacio en blanco es como la respiración en poesía, algo necesario.

Pero el problema es otro. No es tanto que el cliente quiera rellenar cualquier espacio en blanco que encuentre, como que nosotros, los diseñadores, no somos capaces de justificar su uso, y por tanto no acabamos de convencer al cliente sobre por qué debería dejarl ese espacio en blanco. Solemos defender el uso de espacio en blanco aduciendo que “queda mejor” o que “queda más bonito”. Con estas justificaciones, es normal que no se logre convencer a ningún cliente. Sin embargo, bien argumentado y explicado, es incluso posible obrar el milagro de que el cliente acabe apoyando el uso del espacio en blanco. Sí, es posible.

Cuando defendemos el uso del espacio en blanco alegando que “queda bien” o que “así respira más”, nos estamos equivocando. Son argumentos muy débiles. Debemos justificarlo de otra manera: deberíamos defender su uso explicando que cada elemento nuevo que se añade al diseño le resta importancia a los demás elementos. Eso sí lo entiende un cliente. En otras palabras, cuanto más elementos añadas, menos importancia obtienen todos y más diluido (y menos impactante) será el resultado. El diseño pierde efectividad entre el ruido que se genera. Eso sí lo entiende un cliente. El diseño de impacto necesita el uso prolijo del espacio en blanco para que el mensaje principal aparezca en soledad, esté libre de distracciones, sea único y por tanto atraiga magnéticamente toda la atención. El espacio en blanco, más que espacio desaprovechado, es la luz que ilumina un elemento del diseño. Cuanto más espacio en blanco tenga a su alrededor, más visibilidad obtendrá. Eso sí lo entiende un cliente.

He hecho mención al término “visibilidad”. En cualquier diseño, rápidamente se puede comprobar que cuantos más elementos se añaden a un tapiz, más probable es que los elementos más importantes se pierdan entre la multitud. Eso va en detrimento de lo que suelen querer muchos clientes: atención e impacto. En cambio, con la utilización de espacio en blanco, la supuesta oportunidad perdida de no aprovecharlo se compensa con la obtención de una mayor atención a los elementos restantes, que obtienen una visibilidad aún mayor. Eso es lo que se llama técnicamente “visibilidad relativa”.

Hay una manera muy clara de explicar el concepto de visibilidad relativa, y este concepto nos puede ayudar mucho a explicar a nuestros clientes la necesidad del espacio en blanco de un modo convincente. Hay un hecho incontestable y es que la atención de la audiencia es limitada, y que por tanto no por añadir más elementos a un diseño se obtiene más atención por parte del lector. Digamos por ejemplo que un lector dispone de 10 puntos de atención sobre un anuncio. Si en el anuncio sólo hay un mensaje, ese mensaje obtiene 10 puntos de atención. Si hay dos mensajes expresados gráficamente en igualdad, cada uno de ellos obtiene 5 puntos de atención. Si hay un slogan, una foto, un texto y un logo, el reparto de la atención del lector se hará acorde con la importancia visual que el diseñador haya asignado a cada elemento. En un caso típico, el slogan se llevaría 3 puntos, la foto 4 puntos, el copy 1 y el logo 2 puntos.

Por tanto, dado que la atención es limitada, utilizar espacio en blanco en un diseño no es desaprovechar territorio, sino dar más puntos de atención al resto de elementos, concentrar la atención en otros elementos. Es una manera de dar importancia a algo y de guiar el ojo del usuario hacia lo que queremos destacar.

El sistema de puntos de atención no sólo nos permite explicar muy bien el rol que juega el espacio en blanco en un diseño, sino que también es muy práctico para poder definir conjuntamente con el cliente la importancia que tienen varios elementos dentro de una composición. Asignándoles puntos hasta llegar al tope de 10 puntos (algo así como el “saldod e atención” del lector), el cliente puede priorizar los elementos de un modo más objetivo y comprensible para nosotros, y nosotros repartir consecuentemente la atención del lector a los diferentes elementos según la importancia que les ha sido atribuida. Por supuesto, ello lo conseguiremos otorgando más o menos relevancia visual a los elemento mediante colores, distribuciones, contrastes, gruesos, formas, tipografías… y sí, también con espacios en blanco.