Ir directamente al contenido de esta página

Eventos en iPhone (Traducción)

He traducido iPhone events de ppk en una entrada del 1 de agosto y lo he hecho debido a que diversas fuentes cifran en 6 millones los iPhones 3G vendidos en todo el mundo, unos 330 000 en España. Sin contar con los antiguos iPhone de primera generación, Apple espera vender el año que viene unos 40 millones de aparatos al año. En resumen, unos 150 000 diarios…

Todo esto significa que el navegador mobile Safari que trae el iPhone se convertirá, si no lo es ya, en uno de los navegadores de referencia para dispositivos móviles.

Como profesionales hemos de prestarle atención al desarrollo web para este dispositivo. Afortunadamente Peter-Paul Koch ya ha comenzado a estudiar los nuevos retos que este dispositivo plantea, y sus más que posibles influencias en los futuros interfaces y navegadores. Sin mas, dejo paso al artículo.

Ayer entré en la tienda local de móviles porque el cartel de «Agotado temporalmente» había desaparecido del póster de «Consigue aquí tu iPhone». Para mi mayor sorpresa tenían seis (¡6!) iPhones completamente disponibles para la venta, y no, no había lista de espera. Volví a casa con un nuevo y brillante artilugio, impaciente por empezar a probarlo.

Mientras tanto he estado haciendo algunas pruebas; ahora es el momento para un informe.

Antes de continuar, pongamos las malas noticias de CSS sobre la mesa: Safari en el iPhone no soporta position:fixed. Ciertos otros Navegadores fueron ridiculizados por esta carencia; Safari no lo será.

He actualizado la tabla de CSS, la tabla básica y la tabla de eventos. En esta entrada voy a hablar sobre los eventos de JavaScript en el iPhone. Son… interesantes.

Documentación: Ninguna

La primera razón por la que son interesantes es porque se comportan de manera bastante diferente a lo que la Guía de Contenidos Web en Safari para el iPhone sugiere. Sin entrar en detalles, esta «documentación» es deplorablemente incompleta, y bastante a menudo simplemente incorrecta.

Por ejemplo, echad un vistazo a esta página de prueba. Ésta demuestra que la explicación de la guía del iPhone sobre el orden de los eventos cuando el usuario toca la pantalla es incorrecta. Los eventos de mousedown, mouseup y click siempre se lanzan cuando el usuario toca la pantalla, y no sólo cuando el contenido no ha cambiado después de un mousemove (lo cual es un criterio disparatado, de todas maneras).

Todo esto no es nada nuevo. Tan sólo otro excelente navegador con una documentación de mierda. Mi principal motivo para crear este sitio era la total falta de rigor de las páginas web de documentación de los vendedores. Así que tengo que estudiar uno nuevo. Pues qué bien.

Comencemos. E ignoremos completamente la documentación, al igual que ella nos ignora a nosotros.

Moviendo los dedos

El iPhone usa un modelo de eventos sutilmente diferente al de los navegadores tradicionales. El usuario utiliza sus dedos para todas las acciones, y aunque los dedos pueden ser considerados como un ratón (o una especie de) y un golpecito o toque como un clic, esta comparación no es correcta.

El problema es que diversos gestos, especialmente el movimiento de los dedos y el doble toque, son reservados para funciones del sistema. Además, el usuario puede también poner su dedo en cualquier otro lugar de la pantalla sin ningún tipo de puntero cruzando el espacio intermedio, algo que es impensable en la interacción tradicional con el ratón.

El ratón es un dispositivo de selección continuo; el dedo es discontínuo. Ésta es una diferencia profunda que me gustaría ser capaz de comprender y explicar claramente .

No es lo mismo que mover el ratón

En cualquier caso, es una diferencia que lanza un maleficio sobre los eventos mousemove, mouseover y mouseout, así como a nuestro viejo amigo :hover.

Todo lo anterior depende de la lectura e interpretación los movimientos del ratón, y los movimientos del ratón han sido hasta ahora uno de los tópicos que se daban por sentados, así que nunca nadie ha pensado realmente sobre ello.

¿Pero qué ocurre si el ratón desaparece y reaparece en lugares al azar? ¿Qué pasa si no hay movimiento sino una serie de disconexos eventos de clic?

Con la llegada del iPhone el modelo del ratón ha perdido su lógica ineludible. mousemove, mouseover y mouseout (e incluso el pobre viejo :hover) han sido degradados a eventos específicos del sistema que puede que no sobrevivan a la larga.

Pero —y aquí reside el problema— estos eventos se usan en incontables páginas web y aplicaciones para muchos propósitos, y Apple simplemente no puede permitirse el lujo que esas páginas no funcionen en el iPhone.

Eso sitúa a los creadores del Safari para iPhone en el mismo dilema que los vendedores de navegadores de voz: han de padecer un modelo de eventos que no tiene sentido en su interfaz pero que se emplea en toda la Web.

Estos tienen que rediseñar los disparadores para los eventos de manera que cobren sentido en su interfaz, incluso si eso significa que los nombres de los eventos ya no tengan sentido. (Y también han de documentar estas triquiñuelas correctamente.)

Foco del usuario

En el iPhone, mousemove, mouseover, mouseout, mousedown, mouseup y click y :hover dependen del «foco del usuario».

  1. Cuando el usuario enfoca un elemento mediante un solo toque, los estilos :hover se aplican y los eventos mouseover, mousemove, mousedown, mouseup y click se disparan (siempre, y en ese orden).
  2. Cuando el usuario enfoca en otro elemento, el evento mouseout de los viejos elementos se lanza y los estilos :hover son eliminados.

Inicialmente, sólo enlaces y campos de formulario aceptan el evento click por el usuario en el iPhone. Sin embargo, se puede hacer cualquier elemento seleccionable al registrar un manejador de evento para el mouseover, mouseout, mousedown, mouseup, mousemove o click.

Mucho mejor, una vez que se ha registrado el manejador del evento se puede eliminar sin problemas. El elemento permanecerá seleccionable a pesar de haber eliminado el evento. Saber esto es muy útil, y la documentación obvia totalmente este punto. Tú lo has leído aquí por vez primera.

Practica con esta página de prueba para coger la idea.

Las consecuencias

Todavía no he usado el iPhone para probar una aplicación real que dependa de mouseover/out o de mousemove, pero pienso que el estilo de interacción cambia bastante. (Los comentarios son bienvenidos; estoy buscando algo de retroalimentación en este punto.)

Estoy comenzando a sentir una secreta esperanza en que esta pesada interacción del ratón (algo como «Necesitas un ratón para usar nuestra maravillosa interfaz») esté en camino de desaparecer, y las interfaces basadas en clics sean el futuro.

Un clic es un signo seguro de que el usuario quiere enfocarse en un cierto elemento, y que esa es la información que necesita. Lo que él hace o no hace con un dispositivo de control que puede estar ahí o no ha dejado de importar.

No pienso que sea una coincidencia que la mayor parte de las aplicaciones de última generación estén profundamente basadas en clics.

A fin de hacer una aplicación compatible con el iPhone hay que pensar en términos de foco del usuario, y no de movimiento del ratón. (Y no, no tengo idea de qué significa tampoco. Pero sin duda alguien lo entenderá, o quizás alguien ya lo ha entendido.)

Como plus, esto ayuda a la accesibilidad en general. Una interfaz basada en el foco del usuario es mucho mas adaptable a diferentes dispositivos y necesidades de usuario que una interfaz basada en un dispositivo de enfoque contínuo que penaliza a todos los usuarios de otro tipo de dispositivos.

El dedo como botón del ratón

Ahora consideremos el toque del dedo, que generalmente funciona como un clic. Éste incluso se comporta un poco como el tradicional clic: el iPhone sigue un enlace o abre un campo de formulario para edición cuando el usuario deja de tocar la pantalla.

Ahora la interacción del toque se parece sospechosamente al trío mousedownmouseupclick. El usuario toca la pantalla igualando al mousedown, el usuario deja de tocar la pantalla igualando al mouseup, y a ambos les sigue el evento click.

Sin embargo, esa no es exactamente la manera en la que funciona el iPhone.

Con un ratón, se puede presionar el botón en un elemento, mover el ratón y liberar el botón en otro elemento. Los eventos mousedown y mouseup son debidamente lanzados, pero debido a que sus objetivos son elementos diferentes no se lanza el evento click.

Pero ya hemos visto que el iPhone no hace movimientos de ratón, y si no se puede mover el ratón entre los eventos mousedown y mouseup, la diferencia entre mouseup y click se vuelve irrelevante.

mousedown, en teoría, todavía tiene una función válida como evento separado que se lanza cuando el usuario toca la pantalla —sin importar que ocurra después—. Desgraciadamente para la teoría, esa no es la manera en la que trabaja el iPhone.

Cuando se toca un elemento y se deja el dedo en un lugar por un tiempo, se tiene la opción de deseleccionarlo (por ejemplo, permite quedarse donde se está, si después de todo no se quiere seguir un enlace). Desde el punto de vista de eventos JavaScript, yo esperaría lanzar un evento de mousedown, pero no un click (no estaría seguro del mouseup). En cambio, no se lanza el evento click.

Por consiguiente, la única manera de lanzar los eventos mousedown y mouseup es haciendo clic en algo. Los tres eventos se refieren a la misma interacción; se han mezclado completamente en un evento con tres nombres. (Por supuesto, la realidad de la Web requiere que los tres nombres se mantengan soportados para siempre.)

No estoy seguro de si estoy contento con la situación. A pesar que mouseup no tiene sentido en ausencia de movimiento de ratón, no estoy seguro de que el evento independiente mousedown pueda también ser abolido. Alguien podría ser capaz de crear interacciones interesantes que dependan de que los usuarios presionen con sus dedos la pantalla.

A propósito del doble toque y del toque derecho; el primero está reservado para funciones del sistema (zoom) y el otro no existe. Ahí van los eventos de dblclick y los eventos del menú contextual, así como la horriblemente destrozada propiedad button. ¡Ya era hora!

Conclusión

En general, el iPhone ofrece un fascinante modelo orientado a eventos diseñado correctamente para una interfaz totalmente nueva, pero corrompido por el viejo modelo de eventos del ratón y el teclado, que hemos estado usando desde hace diez años. Todavía no tenemos la más mínima idea de qué hacer con él, pero promete ser un maravilloso viaje.

Tengo más cosas que decir sobre los eventos del iPhone, pero tendrán que esperar a otro momento. Ninguno de los demás puntos que quería comentar son tan intrigantes como los eventos del ratón, y me siento cansado.

Más noticias sobre el iPhone posteriormente.

Esta entrada se publicó el 4 de septiembre de 2008, se archivó en , y fue etiquetada como , . Autor: Jorge Fernández. Aún no hay comentarios ›.

Comentarios

Aún no hay comentarios

¿Algún comentario?

* Los campos con un asterisco son necesarios

Últimos proyectos

© Digital Icon, S.L., 2007 – 2017