Hace tiempo que tenía en mente hacer una web de juegos. Al final me he decantado por juegos en Flash.

La verdad es que últimamente ando bastante liado con otras cosas que no tienen nada que ver con los juegos, pero este Sábado pasado, a medio día, me puse un reto personal. Me dije: “A ver si soy capaz de hacer la web antes de que acabe el fin de semana”.

Así que, dicho y hecho. Ha nacido NextGameGen.

He hecho toda la web (incluso la parte que se encarga de subir los juegos) entre el Sábado por la tarde (unas 4 horas), el Domingo por la mañana (otras 4 horas) y el Domingo por la tarde/noche (otras 8 horas). Como no podía estar el 100% del tiempo delante del ordenador, cuando estaba era en plan superintensivo.

La verdad es que estoy bastante contento con el resultado. En 16 horas una web de juegos desde cero. Únicamente le he dedicado 45 minutos más hoy, para añadir los botones de compartir en Facebook & amigos, poner algo de publicidad, y corregir 4 bugs tontos.

Sé que hay muchas cosas mejorables (todo llegará), y que hay un par de bugs invisibles para el ojo humano, pero de momento el que quiera ya puede jugar. La web es 100% funcional.

Incluso recomienda algunos juegos relacionados, según el juego al que juegues (el algoritmo es bastante mejorable).

Pues nada más, ahora voy a ver si aumento las visitas de mi web con ShareUsers, que para los que no lo conoceis, es una web cojonuda para intercambiar enlaces de forma gratuita y automática y conseguir muchas más visitas (ya os contaré más sobre esto).

Lo dicho, podéis viciaros un rato en la web de juegos, y aquí estoy para cualquier crítica o sugerencia que querais hacer

Básicamente hay quien se pregunta si ha llegado el momento de eliminar el botón de permanecer logueado, teniendo las páginas web que recordar siempre a los usuarios. Pero claro, esto tiene sus problemas, ya que compromete la seguridad de las personas.

Me pongo en la piel del usuario medio:

Imagina que te vas a un sitio público (universidad, …) o no tan público (casa de un familiar, de un amigo, …) y se te ocurre entrar en una página web con tu usuario, luego cierras el navegador, y… oh! no!! se te ha olvidado desloguearte de esa web!! Qué cabeza la tuya, ahora si alguien abre el navegador y entra en esa página, automáticamente entrará en tu cuenta, y ¡dios sabe lo que guardas ahí! Han tenido acceso a tus datos y probablemente tu ni te hayas enterado.

Básicamente, por lo que abogan en esta web, es hacer lo que hace Google desde algún tiempo (Google por aquí, Google por allá, siempre sale Google, seguro que hay mil empresas que empezaron a hacer esto antes que Google, que pena que no tengan tanta visibilidad). Pues bien, la idea es básicamente dejar marcado por defecto este botón de “recuerdame”, ya que, probablemente, esta acción complace a la mayoría de las personas, y si a una no le complace, es tan fácil como desmarcar el checkbox.

La verdad, es que meditandolo un poco, quizás no haría que siempre esté marcado, quizás lo que haría es que la web recordara la última opción del usuario, de tal manera que la primera vez que alguien visitara la web, este botón apareciera desmarcado. Es decir, por poner un ejemplo:

El usuario pepe (se acaba de registrar) entra a la web, el botón está desmarcado. Pepe, que se conecta desde casa, y no le gusta andar poniendo el password cada dos por tres, marca el botón de “recordarme”. Tres dias más tarde, se desloguea de la web. La siguiente vez que entra le aparece el botón de “Entrar” con el checkbox de recordarme marcado, porque la última vez entro de esta manera (en ese navegador).

Si lo desmarca esta vez, la próxima vez que intente entrar, este botón aparecerá desmarcado.

Sí, definitivamente creo que esta es la manera más conveniente de implementar el “Recuerdame”.

Conclusión:

Si hay poco tiempo para implementar, tonterias pocas, se deja como marcado y listo. Si tienes tiempo para pensar en las musarañas, o  escribir o leer artículos como este, entonces creo que la mejor forma es la que he descrito al final, un “recuerdame” que recuerde la última opción del usuario en cada máquina.

Esta es mi conclusión, ¿tú que opinas?

Por una parte creo que soy pésimo diseñando webs (a nivel gráfico), sin embargo creo que me estoy volviendo bastante bueno en cuanto a usabilidad se refiere (mis horas me está costando).

Conseguir un interfaz que sea agradable a la vista e intuitivo en cuanto a usabilidad no suele ser fácil. Sobretodo porque muchas veces nuestra perspectiva está limitada, vivimos en nuestro mundo y creemos, de forma inconsciente, que los demàs piensan y razonan como nosotros. Obviamente esto no es así

El tema de usabilidad, al igual que el diseño,  puede ser considerado un arte. Si bien no hay recetas mágicas que nos digan como hacer que un determinado diseño sea bonito y usable, si que hay ideas y conceptos que nos pueden ayudar.

El libro de Don’t Make Me Think es un clásico, y es de lectura obligada, tanto para diseñadores como para programadores. El concepto que se me ha quedado del libro (varios años depués de haberlo leido) es el mismo que reza su título, no me hagas pensar. Si quieres que un usuario se sienta agusto en tu página web, no lo agobies con muchos enlaces, no pongas menús con 200 acciones posibles, si el usuario quiere hacer algo que lo encuentre fácil y lo pueda hacer en par de clicks. Cuantos menos clicks tenga que hacer y cuanto menos le hagamos pensar mucho mejor. Que la navegación por la página sea como un acto reflejo

Por otra parte, hace tiempo empecé a leer otro libro, que por cierto no he terminado, titulado The design of everyday things. Este otro libro, aunque está pensado y escrito desde la perspectiva de alguien que está diseñando cosas tangibles, cosas para el mundo real, es otro libro muy muy recomendable. Después de leer varios capítulos de este libro se me abrió un poco más la mente. Ahora soy consciente de que uno tiene que diseñar cosas de tal manera que las personas que las usen ni siquiera se den cuenta de que están ahi.

Seguramente más de uno se preguntará, por qué diseñar algo para que luego el usuario ni siquiera se de cuenta. La razón es muy sencilla, viene de la parte de usabilidad de un diseño, es muy fácil darse cuenta cuando algo está mal, cuando algo cuesta, pero si va bien uno ni se entera.

Por poner un ejemplo del mundo real, ¿no os ha pasado alguna vez, que intentais usar un determinado aparato o utensilio y siempre empezais a hacerlo mal? Ya no digo que no sea intuitivo, si no que sabiendo que se hace de la forma X vosotros lo empezais a hacer de la forma Y, y cuando os dais cuenta rectificais.

Pensad en el siguiente ejemplo superevidente de fallo garrafal. Imaginad que teneis un bote de mermelada que quereis abrir, y resulta que os poneis a abrir, a abrir, haceis fuerza y no hay manera. No se abre. Cogeis un paño de cocina por encima de la rosca, le dais le dais, nada. Cogeis un cuchillo, le dais golpecitos. Nada, que no se abre. ¿Por qué no se abre esta maldita mermelada? Resulta que la marca hace las roscas al revés, por lo tanto el sentido intuitivo que habeis desarrollado para abrir el bote, resulta que  lo cierra, mientras que cerrarlo lo abre.  Seguro que no volveis a comprar esa marca. Lo lógico es que las roscas, al igual que los tornillos, giren todas en el mismo sentido para evitar problemas de usabilidad.

Ahora un fallo no tan evidente que habreis observado más de una vez, si no en vuestra propia casa, en la de algún amigo/a (si no lo habeis observado probablemente no lo entendereis). No os ha pasado querer enchufar una determinada luz de la casa (la luz de un pasillo, del salón, etc…), y  resulta que encendeis otra. Y resulta que llevais años viviendo en la casa, y/o yendo a esa casa, y casi siempre os equivocais.  Pues bien, os hago saber que no es culpa vuestra. Vereis que le pasa también a más gente al utilizar esos interruptores. Normalmente, suele ocurrir en interruptores que controlan dos luces, y resulta que la luz más cercana a la puerta/habitación es la que enciende la luz más alejada (esto es lo que yo he observado al menos). Lección que podemos aprender: si un usuario mete la pata una y otra vez, a pesar de que es consciente y sabe como se tiene que hacer, el diseño falla.

Por cambiar el chip y dar un ejemplo de un buen diseño, siguiendo con el mundo real,  un gran acierto en diseño que me viene a la cabeza ahora mismo, son los muebles de IKEA. Dios mio, ¡¡¡que no tienen instrucciones!!! ¡¡¡Son 5 dibujitos!! Probablemente muchos de los muebles se puedan montar sin siquiera mirar instrucciones. ¿Por qué? A parte de que los dibujos de las instrucciones son muy sencillitos,  creo que la razón principal es que si  lo intentas montar mal, ¡las piezas no encajan! En los muebles de IKEA suele haber muy pocas combinaciones para montar algo. Sinceramente, dudo mucho que la gente de IKEA deje al azar el tema de que tornillos usar para encajar las distintas piezas en cada uno de sus muebles. Esta gente sabe lo que se hace. Sabe de usabilidad.

Hasta donde yo soy consciente hoy día, los aciertos en diseño son muy dificiles de detectar, y sin embargo detectar cuando algo le falla a un diseño es algo bastante fácil. Si sientes, aunque no sepas el motivo, que a un diseño le falla algo, es porque con un 99% de certeza, le falla algo.

El problema con los diseños, como he dicho al principio, es que son un arte, y tu puedes saber que está fallando X, pero señores, no hay receta para saber como arreglarlo. Depende de cada situación (imagino que habrá patrones de diseño para evitar errores comunes en determinadas areas).

Finalmente, recordad esto: si el usuario tiene que pararse a buscar que es lo siguiente que tiene que hacer, si tiene demasiadas opciones, si no encuentra lo que busca, si tiene que hacer varios clicks o navegar por varias páginas hasta llegar a donde quiere, o si el usuario siempre comete algún tipo de error una y otra vez, entonces el diseño, amigos mios, es mejorable.

La verdad es que no es algo que a uno le haga falta todos los días, pero a mi me hacía falta y me ha resuelto el problema.

En el ejemplo que hay en dicha página se usan las funciones getSelectionStart y getSelectionEnd. La primera nos dice donde está el cursor, mientras que la segunda nos dice dónde finaliza la selección (siempre y cuando getSelectionEnd devuelva un valor distinto a getSelectionStart).

A continuación teneis estas dos funciones:

function getSelectionStart(o) {
 if (o.createTextRange) {
   var r = document.selection.createRange().duplicate();
   r.moveEnd('character', o.value.length);
   if (r.text == '') return o.value.length;
   return o.value.lastIndexOf(r.text);
 }
 else {
    return o.selectionStart;
 }
}
 
function getSelectionEnd(o) {
 if (o.createTextRange) {
 var r = document.selection.createRange().duplicate();
 r.moveStart('character', -o.value.length);
 return r.text.length;
 } else {
   return o.selectionEnd;
 }
}

Uno de estos conceptos es el “edit in place”, que no me atrevo a traducir, pero si me atreviera sería algo como “editar en el sitio”.

El concepto de “edit in place” es muy simple. Se trata de convertir en editable un texto que a priori no lo es.  La idea de esto es evitar usar formularios o campos de formularios para que la información quede más bonita en pantalla, pero al mismo tiempo, permitiendo editar esa misma información sin tener que ir a otra página.

En Google, Flickr y otros muchos sitios lo usan desde hace tiempo.

A continuación un ejemplo de Google Analytics:

Como se puede ver, al cargar la página de Analytics sale un listado con todas las cuentas e información asociada a cada una de ellas (información que he borrado y aparece en blanco).

A priori no hay nada editable, sin embargo si pongo el ratón encima de Artypist (puesto que visualmente parece un enlace), resulta que cambia el estilo de esa celda, y me aparece un botón con un  lapiz dibujado (claramente me está diciendo, si me pinchas me convierto en editable). Vease la siguiente imágen:

Finalmente, puedo optar por pinchar en Artypist y seguir el enlace, o bien pulsar el botón de editar. Si finalmente lo pincho, tendríamos el edit-in-place:

Como veis, el texto de “Artypist” en azul se ha cambiado por un text input, y me ha aparecido el botón de Save y Cancel.

El problema de utilizar los edit in place, es que los campos que son editables y los que no lo son, a priori son indistinguibles, por lo que hay que establecer pistas visuales que ayuden al usuario a identificarlos fácilmente. Por ejemplo usar un color distinto, poner un Edit pequeñito, poner un botón, que al pasar el ratón por encima aparezca el botón…

En el caso de Google Analytics, para este ejemplo en concreto, se puede ver que necesariamente tengo que pasar el ratón por encima de Artypist  y el hecho de que se me ilumine esa celda y me aparezca un botoncito con un lapiz, es un claro signo de que ese campo es editable. Está bien pensado porque necesariamente tengo que pasar el ratón por encima para seguir viendo estadísticas.

La otra cosa que me gusta, es que cuando el campo se convierte en editable, me aparece el botón de guardar y la palabra “cancelar” a la derecha, y esto es algo que visualmente no deja lugar a dudas.

Según la especificación, debería bastar con definir “border-radius” a los pixeles deseados, lamentablemente los navegadores aún no soportan los atributos estándar

En cualquier caso, se pueden conseguir bordes redondeados tanto para mozilla, como para webkit, pero hay que usar “-moz-border-radius” para el primero, y “-webkit-border-radius” para el segundo.

Después de hacer algunas pruebas, he visto que tanto Firefox 2, como Firefox 3, Safari 3.1 y Chrome lo soportan, mientras que tanto  Opera, como Internet Explorer (tanto IE6 como IE7) aún están rezagados (lo de Opera no me lo esperaba… aiss).

Este texto deberías verlo con los bordes redondeados tanto en FF como en Safari.
Si te fijas, no hay javascript, sólo he usado:
-moz-border-radius: 10px;
-webkit-border-radius: 10px;

Lo que fastidia es que no se pueda hacer fácil con IE. ¿Que os parece el tema de las esquinas redondedas?
]]> http://www.codigomanso.com/es/2008/12/rounded-corners-en-css3/feed/ 11 http://www.codigomanso.com/es/2008/11/tiempo-de-respuesta-en-una-aplicacion-web/ http://www.codigomanso.com/es/2008/11/tiempo-de-respuesta-en-una-aplicacion-web/#comments Sun, 23 Nov 2008 09:34:53 +0000 Pau Sanchez http://www.codigomanso.com/?p=149 En cuanto a la usabilidad de una página web, un aspecto bastante importante es el tema del tiempo de respuesta. El tiempo de respuesta no es más que el tiempo que tiene que esperar el usuario para que salga la información, página, formulario, imagen, etc… que ha solicitado mediante algún click.

Normalmente es fácil encontrar partes de una aplicación donde los tiempos de respuesta no son lo que deberían ser.

Para ilustrar un poco de lo que hablo voy a hablar del editor TinyMCE que hay en WordPress 2.6.3 y de porqué opino que los botones de añadir media está mal diseñados.

Cuando edito contenido y quiero meter una imágen en el post que estoy escribiendo, le doy al botón de añadir imagen:

Botones para añadir contenidos media en WordPress

El problema es que cuando hago click en ese botón, la aplicación no me muestra el formulario que yo he pedido, me muestra una barra de progreso como la siguiente:

Barra de progreso al clicar en añadir imagen

Esta barra de progreso, me tiene esperando el diálogo durante unos segundos, hasta que finalmente, tras mi espera sale el diálogo esperado:

Formulario para añadir imagen en WordPress

Ahora, habiendo visto que me tiene que salir un formulario, sabiendo que el servidor no tiene que precalcular nada, si no que simplemente tiene que enviarme los contenidos HTML de un formulario… ¿Porqué tengo que esperar 3 segundos?  ¿No puede la aplicación web símplemente embeder ese formulario en la página para que cuando yo haga click, me salga el formulario en 0 segundos? De hecho se ahorra una llamada al servidor.

Incluso en el caso donde se tenga que hacer una llamada AJAX al servidor, ¿por que no cachear el formulario? Así la siguiente vez que haga click, para añadir la segunda, tercera y cuarta imagen, los tiempos de espera serían cero.

Sin duda, son esos pequeños detalles, como los tiempos de respuesta, lo que hace que las aplicaciones web aún no estén a la altura de las aplicaciones de cliente de toda la vida. En cualquier caso, si uno se fija en la aplicación web que está desarrollando, normalmente no suele ser demasiado difícil darse cuenta de estos problemas y solucionarlos.

Minimizar el tiempo de respuesta no es lo más importante de una web, y desde luego no es una prioridad en un producto, pero es una de esas cosas que hará que mejore la experiencia de usuario. Es más, es de esas cosas que cuando el tiempo de respuesta es 0, el usuario no se entera, ni lo aprecia, pero cuando el tiempo de respuesta es de tan sólo unos segundos, frustra y martiliza a muchos muchos usuarios.