Revisión de la experiencia de búsqueda actual (input #q + chips de temas). No es urgente, se recoge aquí para retomarlo más adelante.
Funciona bien (no tocar sin motivo)
type="search" nativo (index.html:81) da botón de limpiar gratis en la mayoría de navegadores.- Los chips de temas (
app.js:1030-1058) son buen patrón de descubrimiento progresivo: solo muestran tags que, combinados con el filtro actual, siguen dando resultados.
Problemas encontrados
-
Sin normalización de acentos. eventHaystack() (app.js:233-241) solo hace .toLowerCase(), no quita diacríticos. Buscar "malaga" no encuentra "Málaga", pese a que el propio placeholder (index.html:81) invita a escribir con tilde. Arreglo barato: normalizar con NFD tanto el query como el haystack.
-
Substring sin límites de palabra. El matching de filters.q usa indexOf puro (app.js:264), así que términos cortos generan falsos positivos ("ia" matchea "Guía", "IA" matchea "Colombia"...). No hay ranking de relevancia: un match en description (invisible en la tarjeta) pesa igual que un match en el nombre del evento.
-
Sin highlighting del término buscado en las tarjetas de resultado. Agrava el punto 2: si el match viene de la descripción o del organizador, el usuario no tiene pista visual de por qué apareció esa tarjeta.
-
Estado vacío mudo. Solo dice "No hay eventos con esos filtros" (app.js:1113), sin sugerir qué quitar. Ya existe lógica reutilizable para esto (wouldReturnResults, app.js:1065) que podría adaptarse para sugerir, p. ej., "prueba sin 'CFP abierto'".
-
Sin atajo de teclado para saltar al buscador (/ o Cmd/Ctrl+K). Solo hay un listener global de teclado y es para Escape (app.js:1679).
-
Sin debounce. Cada tecla dispara render() completo, incluido el recálculo de chips que recorre todos los eventos por cada tag candidato (app.js:1607-1613 + renderFacets). No se nota con pocos feeds, pero escala mal con más suscripciones.
-
state.savedFilters a medio construir. Está declarado e inicializado (app.js:29, app.js:96) pero no encontré ningún uso real más allá de eso — parece pensado para guardar búsquedas frecuentes.
Sobre fuzzy search
Se evaluó usar una librería de fuzzy search (tipo Fuse.js) y se descartó por ahora: rompería la restricción de "vanilla JS, sin build step" del proyecto, y el problema real no es la tolerancia a errores tipográficos sino los puntos 1-4 de arriba, que se resuelven con JS plano (normalización NFD, ranking simple por campo de coincidencia, <mark> en el texto). Tolerancia a typos reales (que "kubernets" encuentre "Kubernetes") sería el siguiente paso si se confirma que hace falta, con un helper de distancia de Levenshtein pequeño, sin dependencias.
Prioridad sugerida (impacto/esfuerzo)
Alto valor, bajo esfuerzo: 1, 2, 3, 5.
Medio: 4, 6.
Más largo plazo: 7 (guardar búsquedas), tolerancia a typos.
Revisión de la experiencia de búsqueda actual (input
#q+ chips de temas). No es urgente, se recoge aquí para retomarlo más adelante.Funciona bien (no tocar sin motivo)
type="search"nativo (index.html:81) da botón de limpiar gratis en la mayoría de navegadores.app.js:1030-1058) son buen patrón de descubrimiento progresivo: solo muestran tags que, combinados con el filtro actual, siguen dando resultados.Problemas encontrados
Sin normalización de acentos.
eventHaystack()(app.js:233-241) solo hace.toLowerCase(), no quita diacríticos. Buscar "malaga" no encuentra "Málaga", pese a que el propio placeholder (index.html:81) invita a escribir con tilde. Arreglo barato: normalizar con NFD tanto el query como el haystack.Substring sin límites de palabra. El matching de
filters.qusaindexOfpuro (app.js:264), así que términos cortos generan falsos positivos ("ia" matchea "Guía", "IA" matchea "Colombia"...). No hay ranking de relevancia: un match endescription(invisible en la tarjeta) pesa igual que un match en el nombre del evento.Sin highlighting del término buscado en las tarjetas de resultado. Agrava el punto 2: si el match viene de la descripción o del organizador, el usuario no tiene pista visual de por qué apareció esa tarjeta.
Estado vacío mudo. Solo dice "No hay eventos con esos filtros" (
app.js:1113), sin sugerir qué quitar. Ya existe lógica reutilizable para esto (wouldReturnResults,app.js:1065) que podría adaptarse para sugerir, p. ej., "prueba sin 'CFP abierto'".Sin atajo de teclado para saltar al buscador (
/o Cmd/Ctrl+K). Solo hay un listener global de teclado y es para Escape (app.js:1679).Sin debounce. Cada tecla dispara
render()completo, incluido el recálculo de chips que recorre todos los eventos por cada tag candidato (app.js:1607-1613+renderFacets). No se nota con pocos feeds, pero escala mal con más suscripciones.state.savedFiltersa medio construir. Está declarado e inicializado (app.js:29,app.js:96) pero no encontré ningún uso real más allá de eso — parece pensado para guardar búsquedas frecuentes.Sobre fuzzy search
Se evaluó usar una librería de fuzzy search (tipo Fuse.js) y se descartó por ahora: rompería la restricción de "vanilla JS, sin build step" del proyecto, y el problema real no es la tolerancia a errores tipográficos sino los puntos 1-4 de arriba, que se resuelven con JS plano (normalización NFD, ranking simple por campo de coincidencia,
<mark>en el texto). Tolerancia a typos reales (que "kubernets" encuentre "Kubernetes") sería el siguiente paso si se confirma que hace falta, con un helper de distancia de Levenshtein pequeño, sin dependencias.Prioridad sugerida (impacto/esfuerzo)
Alto valor, bajo esfuerzo: 1, 2, 3, 5.
Medio: 4, 6.
Más largo plazo: 7 (guardar búsquedas), tolerancia a typos.