Nota sobre ergonomía de ciertos efectos de texto.

Tag: Articulos tecnicos

Los efectos de texto son una poderosa herramienta, uno de los pilares en ciertas obras, de hecho. Pero creo que no podemos descuidar los detalles.

No soy experto, ni mucho menos, pero soy lector como cualquier otro. En ocasiones me encuentro un efecto que perjudica mi lectura y me pregunto: ¿es necesario? Y, si lo fuese, ¿se podría implementar correctamente?.

A la hora de leer, no es lo mismo estar distraído entre ruidos, que solo y concentrado en la lectura. A veces leo medio dormido, a veces enfermo. Puedo imaginar multitud de factores. En resumen, no hay dos momentos iguales y el ritmo de lectura es diferente cada vez.

Texto temporizado y borrado de página. Bajo mi pobre experiencia, puedo decir que hay peligros en su aparente simpleza.
 

Texto temporizado (o animado)

Suele aparecer cuando el autor desea mostrar una relativa cantidad de texto, por ejemplo en una introducción. También lo he encontrado como recurso dramático en momentos cumbre. Con la sutileza y el refinamiento técnico adecuados puede ser muy efectivo.

En cambio, lo habitual es que me encuentro con que el efecto no tiene el ritmo adecuado.

    - Si va más rápido, la linea que estoy leyendo cambia de posición debido al desplazamiento (scroll) que se produce mientras se llena la pantalla. Me toma mi tiempo encontrar de nuevo la frase que estaba leyendo, mi ritmo de lectura decrece y me caza de nuevo otro desplazamiento: vuelta a empezar. Quiero leer, no buscar la frase que estaba leyendo.

    -Si va más lento, se me impone cierta pausa. Mucho más molesta en grandes fragmentos cortados entre palabras o frases cortas. En los peores casos, además, la pausa es fija y sólo queda esperar.

En mi piel de autor, pienso que definir los intervalos de tiempo asignados a cada texto es tedioso y propenso a errores. Si el tiempo se calculase con algún tipo de función y dado algún método de configuración, a base de ensayo y error el lector podría encontrar un punto dulce. ¿Cómo definir la escala? ¿Cómo sabe el lector a qué corresponde cada opción? ¿Alguien conoce su velocidad de lectura en alguna magnitud?.

No me parece buena solución. Como lector, mi ritmo fluctúa y quiero leer, no buscar la configuración correcta a medida que me voy durmiendo.

Por último, hay intérpretes o aplicaciones que no reaccionan bien ante el texto temporizado. Por ejemplo, recuerdo algún intento con rebot vía IRC. El resultado fue: "esta obra no nos vale".
 

Borrados de pantalla

El peor antipatrón es el borrado temporizado de pantalla. Suele ocurrir al finalizar una (sub)escena. A veces, el tiempo de espera es prácticamente inexistente. Otras veces insuficiente. Sea fallo de diseño o de implementación, las consecuencias son nefastas: cuando el presumido gatito y el perro valiente culminan la emocionante tercera escena, ¡me lo pierdo!

En muchos intérpretes, creo que bajo especificación, un borrado de pantalla significa la destrucción del historial de salida de texto, lo que me impide acceder a las partes anteriores del relato (ya sea porque perdí algo en un borrado inesperado o, simplemente, para repasar algún detalle clave).

Yo me lo pensaría dos veces antes de incluir un borrado de pantalla. Nunca lo haría temporizado.
 

Concluyendo

Me gustaría no encontrarme con el tipo de problemas descritos. Suelo pensar que la solución es escribir todo lo disponible de un golpe, sin pausas ni temporizadores: que se respete mi ritmo particular.

Como autor intentaré no sucumbir al efecto por el efecto. Sopesaré los posibles beneficios y las seguras molestias. No cabe duda de que en alguna contada ocasión, el efecto está justificado.

Por último, para tener a todos contentos, podría ayudar la existencia de una opción para desactivar los efectos. Por supuesto, antes de que aparezcan.

0.02
dddddd.-

El autor agradece la colaboración de Al-Khwarizmi y los sabios consejos de estilo de Notxor.

Comentarios

Johan Paz
Mié, 06/06/2012 - 21:15

<duplicado>

Johan Paz
Mié, 06/06/2012 - 21:16

...en que la solución sea escribir todo de golpe. Temporizar lentamente y descubrir pulsando una tecla sí, pero mostrar todo de golpe mataría muchas introducciones, ya que la no presencia en la pantalla de un giro en la narración es fundamental para la intensidad de la misma y es una ventaja frente a la literatura no interactiva.

dddddd
Mié, 06/06/2012 - 22:36

Pulsar una tecla parece una buena solución, aunque no elimina todos los problemas. Eso sí, me gusta porque deja que el ritmo lo marque el lector. Claro que existen usos dramáticos o experimentales en cuanto a ritmo, pero hablo en general. Un ejemplo extremo: una gran cantidad de texto animado a toda velocidad, con la intención de sorprender al lector, que en realidad no necesita leerlo, sino sentir esa sensación de velocidad, como flashes muy rápidos e inapreciables en una película.

Dejaría de lado el temporizador, el mayor de los culpables en el artículo. Un ejemplo más de posibles problemas... Mi pulsación un instante después de que saltase el temporizador, con lo que estoy haciendo avanzar el siguiente temporizador al esperado. Si ese siguiente temporizador es un borrado de pantalla, texto perdido.

Lo dicho, creo que se necesita refinamiento técnico para no causar problemas.

Johan Paz
Jue, 07/06/2012 - 12:41

...yo creo que es hilar demasiado fino preocuparse por la remota posibilidad de que el temporizador coincida justo con la pulsación del usuario.

En cualquier caso en la librería más clásica de Inform de todo esto Cortos.h, ya tienes lo siguiente:

Si el tiempo se calculase con algún tipo de función

 

[ PrintAutoPausa txt k;
  if (velocidad_texto==0)
    k=PrintPausa(txt,0);
  else
    k=PrintPausa(txt, LStrLen(txt)*10/velocidad_texto+10);
  return k;
]; 
 
Como ves ya usaba dos parámetros para calcular ese tiempo: la longitud del texto y una velocidad regulable del texto. Y por supuesto, tienes la posibildad de poner velocidad_texto  a 0 que significaba infinito.

dddddd
Vie, 08/06/2012 - 10:30

Se podría intentar, entonces, lo que completa la hipótesis a la que pertenece la cita.

Si el tiempo se calculase con algún tipo de función y dado algún método de configuración [...] el lector podría [...]

Si interpreto bien, sería poder modificar en tiempo de ejecución la variable "velocidad_texto" y evaluarlo durante betatesting. Aunque ya expresé que no acaba de convencerme tener que andar retocando el valor(!) según las circunstancias, al menos es otra forma de dar de nuevo el control al lector, que podría incluso desactivar virtualmente la temporización (con pausas no perceptibles).

Incanus
Jue, 07/06/2012 - 14:14

Yo he implementado esto de la desactivación opcional de los efectos de texto desde el 2010 a la fecha (3 trabajos) y, la verdad, los comentarios a favor y en contra de esos efectos no son muy diferentes de los comentarios de mis 7 trabajos previos, esté o no la opción destacada en un "box" al principio del juego o en el texto inicial de "Acerca de" para el comando "VERSION" :-/

[INCANUS]

jarel
Jue, 07/06/2012 - 20:37

Personalmente me repatean bastante los textos temporizados, principalmente (que no es poco) por lo comentado, que no se ajustan a tu ritmo de lectura y o te retienen o te estresan.

En cuanto al borrado de pantalla, cuando lo uso, suelo poner un tope temporal delante para evitar que la pantalla vuele debido a una doble pulsación o una pulsación larga del jugador arrastrada desde el último "pulsa una tecla".

Es decir, que cuando sale el último texto antes de un borrado de pantalla hay una pausa de 1 segundo (por ejemplo) antes de que llegue la verdadera línea de código que espera que pulses una tecla.

ejemplo en inform 6, de un freno preborrado:

print "texto 1";

esperartecla("",10); ! espera a que pulses una tecla o 10 fracciones de segundo

esperartecla("",10); ! espera a que pulses una tecla o 10 fracciones de segundo

esperartecla("",10); ! espera a que pulses una tecla o 10 fracciones de segundo

esperartecla("",10); ! espera a que pulses una tecla o 10 fracciones de segundo

esperartecla("..."); ! espera a que pulses una tecla

borrapantalla();

print "texto 2 con la pantalla limpia";

 

Fernando Gregoire
Jue, 07/06/2012 - 20:44

Interesante artículo. A mí los cortos me gustan, pero me has hecho pensar en el ritmo de lectura. Yo pensé que la velocidad que los autores configuraban era siempre perfecta para una persona que ve; pero bueno, con tu artículo veo que no. Lo que siempre me pregunté es si habrá en los intérpretes por ejemplo alguna forma para autoadaptar a nivel de código de la obra (según la que el autor estableció) la velocidad de pase a la velocidad de la voz que se esté utilizando. Dos cosas que me molestan mucho son el hecho de tener que apretar una tecla para que se me permita escribir, aunque no haya habido ninguna escena de corte (se ve por ejemplo desde cierto punto en TC), y la incompatibilidad de los juegos viejos con la nueva máquina Glulx que se la pasan imprimiendo una advertencia con cada corto que pasa (¡ocurriendo eso los cortos son ilegibles!). Y bueno, lo del borrado de pantalla no lo veo mal; es responsabilidad de los intérpretes proporcionar un historial de la salida de texto que no se destruya, y el hecho de hacer desaparecer el texto de la ventana de juego en sí es una buena forma de dividir la historia al realizar ciertas acciones, sería algo así como en el teatro hacer caer el telón. Además, desde el punto de vista de la accesibilidad viene bien tanto a ciegos como a disminuidos visuales:

Los ciegos que lean las obras con su lector de pantalla configurado para que lea todo lo que va apareciendo en pantalla porque el intérprete no permite dirigir por sí mismo la salida a una librería de texto a voz (SAPI 4 o 5 en Windows, Speech Dispatcher en Gnome de Linux, Speech Manager en Mac) se benefician del borrado de la pantalla en tanto se disminuye la posibilidad de que se lea texto anterior (cosa que pasa bastante y a veces estaría bueno que se pueda borrar la pantalla manualmente), y a los disminuidos visuales les sirve en tanto al borrarse la pantalla les queda más espacio para magnificar el texto nuevo. Además, a los ciegos y sordociegos que utilicen líneas o pantallas Braille se les liberan celdas de la misma, lo que es útil cuando tienen líneas Braille de tan sólo 20 celdas (distinto es cuando son de 40 u 80).

dddddd
Vie, 08/06/2012 - 09:43

Me interesan especialmente los problemas de ergonomía en los casos de problemas visuales, más o menos acusados, y siempre es ilustrativo conocer las experiencias que acumulas al respecto.

Dejé fuera del articulillo dos tipos de efectos por no hacerlo demasiado extenso, pero creo que merece la pena tocarlos aquí de pasada.

Boxes y menús. ¿Que tal resultan bajo lectores de pantalla o tecnologías afines? Por ejemplo, los completísimos menús de Alpha Aventuras.

No sería nada funcional un menú que permita activar ciertas opciones de accesibilidad si el propio menú causase problemas.

Fernando Gregoire
Dom, 10/06/2012 - 07:11

El problema con estos menús es una importante falta de estandarización, si así se le podría llamar, ya que en la accesibilidad de los mismos hay diferencias importantes tanto según el intérprete como según el método que utilice el lector de pantalla para obtener la información. Aunque es un tema perfecto para escribir un artículo de SPAC al respecto, en este comentario te puedo resumir la situación actual diciendo que aunque estos menús no son imposibles de utilizar por una persona ciega que emplee un lector de pantalla, en los intérpretes actuales de Z y Glulx para Windows (formatos de máquina virtual muy utilizados actualmente y con los que por tal motivo tengo ya cierta experiencia como jugador) debería estandarizarse algo más el layout técnico de estos menús de un juego o, mejor aún, en el caso de intérpretes como los de David Kinder que tienen opciones de lectura en voz alta, corregirse algunos problemas de la lectura de los menús específicos de los intérpretes.

 

Escribir este comentario me dio ya ideas y ganas, así que en cuanto acabe con la oleada de parciales actuales me pondré a escribir sobre esto en el SPAC.

(c)1998-2019 CAAD

Todos los contenidos de esta web son propiedad de CAAD. Las colaboraciones son propiedad de sus respectivos autores.