Deja de pedir al usuario que elija modo: búsqueda que adivina la intención
Un diccionario que acepta tres escrituras puede pedir al usuario que elija, o deducirlo. Pedirlo es más fácil de construir y peor de usar. Cómo hicimos que la deducción fuese fiable.
KoiSpeak acepta tres tipos de entrada en un solo campo: vietnamita, pinyin y caracteres chinos. El diseño obvio sería un selector de modo. Deliberadamente no lo construimos, y el razonamiento se generaliza mucho más allá de los diccionarios.
Por qué fallan los selectores de modo
Un selector parece inofensivo. Le cuesta al usuario un toque. Pero se lo cuesta cada vez, y falla de una forma muy concreta y exasperante: cuando el modo está mal, obtienes cero resultados, y cero resultados es indistinguible de «esta palabra no existe».
El modelo mental real del usuario no es «ahora estoy haciendo una búsqueda en pinyin». Es «qué significa esto». Cada elemento de interfaz entre esa intención y la respuesta es fricción, y la fricción se acumula en una herramienta que se abre cuarenta veces al día.
Aquí se esconde una regla general. Si el sistema puede determinar algo a partir de la entrada, no debería preguntárselo al usuario. Un selector de modo es la interfaz admitiendo que no quiso hacer ese trabajo.
Las tres escrituras se separan mejor de lo que parece
La buena noticia es que ocupan espacios en gran medida distintos.
Los caracteres chinos se detectan trivialmente
Los caracteres han están en bloques Unicode conocidos, sobre todo CJK Unified Ideographs, de U+4E00 a U+9FFF, con extensiones en otros rangos. Si la entrada contiene un carácter de ahí, el usuario escribió chino. Esto es casi certeza, no conjetura.
El vietnamita tiene diacríticos que el pinyin no usa
El vietnamita se escribe en alfabeto latino con su propio juego de marcas: cuerno (ơ, ư), circunflejo (â, ê, ô), breve (ă), la đ con trazo, y marcas tonales que incluyen el punto suscrito (ạ) y el gancho (ả).
El pinyin usa macron, agudo, carón y grave, y solo sobre a, e, i, o, u, ü. Los conjuntos apenas se solapan. Una cadena con đ, ơ, ư o punto suscrito es vietnamita, sin más.
El pinyin es un conjunto pequeño y cerrado
Esta es la parte que se subestima. El mandarín tiene solo unos cientos de sílabas legales. zhang, xue, qiong son válidas; blorp y strem no.
Así que puedes validar: intenta segmentar la entrada en sílabas legales de pinyin. Si segmenta limpiamente, es muy probable que sea pinyin. Esto además captura el pinyin sin tonos, que es lo que la gente escribe de verdad.
Lo difícil es el solapamiento
La detección es fácil en los casos claros e interesante en los ambiguos. Colisiones reales:
- Cadenas cortas que son ambas cosas.
maes pinyin válido y palabra vietnamita válida.ba,co,canigual. - Vietnamita sin acentos. Mucha gente escribe vietnamita sin diacríticos, y eso elimina tu señal más fuerte.
- Inglés. Los estudiantes escriben palabras en inglés, y el inglés no es ninguna de tus tres lenguas.
Intentar resolverlo con más reglas es una batalla perdida. Las reglas se alargan, se contradicen y siguen fallando.
No clasifiques. Busca en todo y ordena.
El diseño que funcionó fue dejar de tratarlo como un problema de clasificación.
En lugar de decidir qué es la entrada y buscar en un índice, se lanza la consulta contra todas las interpretaciones y luego se fusionan los resultados con una puntuación que tiene en cuenta la verosimilitud de cada una.
A grandes rasgos:
- Puntúa cada interpretación: ¿contiene caracteres han?, ¿lleva diacríticos exclusivos del vietnamita?, ¿segmenta como pinyin legal?
- Consulta los índices que implican esas interpretaciones.
- Fusiona, ponderando cada resultado por la puntuación de su interpretación, la exactitud de la coincidencia y la frecuencia de la palabra.
El usuario ve una sola lista. Para ma recibe los resultados de pinyin y los de vietnamita juntos, las palabras comunes primero, y la respuesta que quería está en pantalla en cualquier caso. La ambigüedad deja de ser un estado de error y pasa a ser una lista ordenada.
Clasificar obliga a una decisión que puede estar mal. Ordenar te permite estar inseguro y seguir siendo útil. Cuando el sistema no puede estar seguro, prefiere diseños que degraden a «varias respuestas plausibles» en lugar de «una respuesta equivocada con mucha confianza».
Lo que cuesta
Seamos honestos con el intercambio: haces más consultas por pulsación. Es real, y por eso este diseño vive o muere según el rendimiento.
Lo que lo hizo asumible:
- Las interpretaciones baratas primero. Detectar han es comprobar un rango en los primeros caracteres. Si acierta, te saltas todo lo demás.
- Índices de prefijo por escritura, de modo que cada consulta individual sea una búsqueda barata y no un recorrido.
- Frecuencia horneada en el índice, para que ordenar no requiera otra pasada sobre los resultados.
- Debounce y cancelación de consultas en vuelo cuando cambia la entrada. La mayoría de pulsaciones nunca produce una búsqueda completada.
Dónde sigue haciendo falta una salida de emergencia
La detección automática no debería ser la única vía. Dos casos necesitan de verdad otra cosa:
- No puedes escribir el carácter en absoluto. Para eso están la entrada manuscrita y la búsqueda por radical.
- Quieres forzar una dirección. A veces el usuario sí quiere solo vietnamita a chino. Ofrecemos controles de dirección explícitos, pero como anulación disponible cuando hace falta, no como una decisión exigida de entrada.
Ese orden es el principio real. Adivina bien por defecto y deja que la gente corrija la conjetura. No: niégate a adivinar y obliga a todos a declarar.
La lección general
Todo producto tiene un momento en el que la implementación fácil le pregunta al usuario algo que el sistema podría haber respondido. Un tipo de archivo. Un país. Una moneda. Un modo de búsqueda.
Cada uno es pequeño. Juntos son la diferencia entre una herramienta a la que la gente recurre sin pensar y otra que hay que operar.