Del Smartphone al No-tan-Smartphone - Aplicaciones para Nokia S40

Pues si, luego uno se pone muy fino pensando que hacer aplicaciones es iOS y Android (y quizá Windows y BlackBerry…) pero ¿Qué tal para un Nokia S40?

La problemática surgió con una petición laboral de una versión de app para Nokia S40. El principal dilema fue que originalmente era una aplicación planeada para Android y iOS ¿Qué podíamos traducir de eso a un Nokia S40? Comenzamos pensando en las funcionalidades principales y una por una fuimos encontrando su equivalente.

1. Menús desplegables - Sí podemos hacer esto siguiendo los guidelines de Nokia, pero tiene sus limitantes. Nuestra interfaz original tenía tres elementos de menú que filtraban el contenido, que tuvimos que traducir en uno solo con pantallas adicionales de apoyo. Como pueden observar en la imagen, los lineamientos de Nokia son muy claros en este tema (además de que el espacio es mucho más reducido).
   
   
   
2. Barra de navegación fija - Nokia tiene sus propios estándares para una barra de navegación fija parecida a la que vemos en aplicaciones de iOS, así que podemos trabajar con algo así.
   
   
   
   

3. Mapas y contenido filtrado por ubicación - Este video explica mejor que cualquier cosa que yo pueda decirles al respecto
   
   

4. Formularios (que no solo tienen campos de texto) - De nuevo tenemos lineamientos muy claros. La documentación de diseño de Nokia es muy buena.
   
   
   
5. Listados con imágenes - Esto si tuvo sus complicaciones, pero se puede trabajar con listados sencillos. La imagen puede venir después, en una ubicación con más espacio.
   
   
   
   
6. Personalización del diseño de la interfaz - Por desgracia no hay mucha libertad. Pero, hey, lo básico lo tenemos.

Para más información, pueden consultar los lineamientos de diseño de Nokia S40 completos. ¿Quién ha trabajado en diseño/desarrollo para Nokia?

Diseño realista o diseño plano: Esa es la pregunta

Revisando el newsfeed, me topé con un artículo en Webdesigner Depot que hablaba precisamente de esto, pero creo que no entró casi en detalles de la discusión que ha habido últimamente al respecto.

Primero lo primero ¿Qué consideran ustedes como diseño realista? El término que se ha utilizado para esto es skeumorfismo, que literalmente significa crear un objeto con la apariencia o funcionamiento de una versión antigua del mismo. Este es el estilo que ha utilizado Apple en sus productos, con todos los relieves y sombras y texturas que implementa en sus aplicaciones, por no mencionar el detalle adicional (por ejemplo, hacer que una aplicación de notas parezca un cuaderno real). 

Esta manera de diseñar ha sido muy criticada y creo que va más allá del tipo de proyecto que se está creando. En este artículo más detallado de Andy Mangold sobre el uso del skeumorfismo y las razones por las cuales es utilizado por Apple, menciona el sentimiento de nostalgia y de adaptación psicológica a los dispositivos móviles. Esto va más allá de ser una persona de edad avanzada que no se adapta a la tecnología. Alguien con un apego personal al uso de una herramienta que ahora lleva incluida en su teléfono o tablet puede sentir un apego especial a una aplicación que visualmente emula el uso del mismo.

No por esto pierde sentido toda la discusión que avala el uso del diseño plano que ha hecho tan popular el surgimiento de Windows 8. Las obvias ventajas de limpieza y claridad no pueden ser ignoradas, además de el hecho que por más realista que se vea una interfaz, no deja de ser una aplicación en un dispositivo a cuyo uso hay que adaptarse.

Es mucho más práctico el diseño plano, y trae una experiencia más limpia, pero no puede ser ignorado el valor tanto artístico (para el diseñador) como sentimental (para el usuario) de la implementación de un diseño de interfaces realistas.

¿Cuál es tu preferencia y en qué casos? Algunas personas prefieren de manera muy totalitaria un diseño u otro, pero de manera más abierta es necesario segmentar esa decisión ¿En qué casos es más o menos grato ver un diseño realista?

No hagamos sentir estúpido al usuario

¿Les suena un poco drástico el título? Muchas veces, si no se analiza bien la implementación de ciertas interacciones en una interfaz, desgraciadamente llegamos a eso. Lo vi mucho con validaciones en web, pero ahora que soy usuario de iPad, me doy cuenta que esto sigue pasando.

Un ejemplo es el registro de nuevo usuario de la aplicación de Evernote. Pide tres datos: Correo, usuario y contraseña. Cuando empiezo a teclear mi correo, sin embargo, me encuentro con la siguiente pantalla:

No he terminado de teclear mi correo electrónico. Sin embargo, la aplicación ya me está diciendo que es una dirección inválida. No has cometido el error aún y la pantalla ya te está indicando algo que hiciste mal. 

Ocurre lo mismo con la aplicación de Zite (la cual por cierto me encanta, pero eso no la exenta de errores). 

Y por desgracia esto se repite en el mismo formulario de registro, al momento de pedir la confirmación de la contraseña (la cual por cierto está marcada un tanto ambiguamente con solo la repetición de la misma etiqueta en cada campo).

Apenas me posiciono en el campo de repetición de contraseña y ya me está indicando que no son iguales (además es algo que asumo, pues el error exacto no se me indica).

No podemos asumir que el usuario entiende lo que está pasando cuando las interfaces marcan situaciones negativas. El objetivo es ayudarlo, no traumatizarlo. Para esto, ¿Cuando es el mejor momento para indicarle que ha cometido un error? Cuando realmente lo cometa. En los casos anteriormente mencionados, el error debió haber sido indicado hasta el momento en el que el usuario hace el cambio de foco al campo siguiente, claro indicador de que ha terminado de teclear el campo anterior y momento perfecto para revisar lo que ha tecleado e indicarle que debe cambiarlo.

¿Qué pasa con las validaciones en tiempo real? Aplican únicamente a campos con alto índice de error, como por ejemplo el campo de nombre de usuario. Si tecleo un nombre de usuario que ya está siendo usado, es útil para mi saber cuando he logrado crear uno original (para esto normalmente agregamos números o letras hasta que el campo nos indica que está bien). Esto último, por cierto, lo escuché en una conferencia impartida por Luke Wroblewski hace un par de años.

Avanzando con HTML5: Cut the Rope para web

Para todos aquellos fanáticos de este jueguito, creo que les estoy trayendo muy buenas (y con suerte interesantes) noticias. Esta versión de Cut The Rope pueden jugarla de manera gratuita en línea, y es compatible con Internet Explorer. 

¿Estaremos viendo ya la luz al final del túnel en la adopción del HTML5?

Por cierto, no se pierdan el Behind the Scenes para saber más sobre el desarrollo de esta aplicación.