Sovrascrivere la scorciatoia da tastiera del browser per "Trova nella pagina"

Ciao, sono un fan di Discourse, proveniente da una piccola comunità che sta discutendo di una migrazione da vBulletin5. Una persona si è opposta a Discourse perché “Hijacking_ Ctrl+f is _evil” e, dopo aver capito cosa intendeva, devo concordare. C’è un serio problema di usabilità su come Discourse gestisce attualmente Ctrl+f, che è la scorciatoia del browser per “Trova testo in questa pagina”.

Il problema

  • Alcune volte, Ctrl+f funziona come dovrebbe e Discourse utilizza la funzione di ricerca integrata del browser in modo che la pagina scorra immediatamente al primo risultato mentre si digita. Ctrl+G porta al risultato successivo.
    • La vita è bella.
  • Altre volte, Ctrl+f non funziona e invece mostra un elenco di risultati da una ricerca nel database.
    • Non scorre la pagina al primo risultato mentre l’utente digita.
    • La frase di ricerca viene evidenziata solo se si trova già sullo schermo.
    • Non consente di cercare termini troppo brevi, come “UX”.
    • Non accetta Ctrl+g per mostrare il risultato successivo.
    • Mostra risultati per argomenti irrilevanti che Ctrl+f non avrebbe mostrato se non fosse stato in grado di trovare il termine nella pagina.
  • Il motivo per cui questo si rompe è completamente invisibile agli utenti, ma è estremamente frustrante. Sentono che la possibilità di cercare all’interno di una pagina è stata tolta senza alcuna spiegazione.
  • Non aiuta dire loro che premendo Ctrl+f due volte si esegue una ricerca del browser, poiché ciò non troverebbe i post che effettivamente esistono.

La causa principale

Questo non è un problema estetico, ma un problema fondamentale di usabilità che Discourse dovrà risolvere alla radice: l’illusione che un’intera conversazione sia effettivamente nel DOM del browser, quando invece viene caricata dinamicamente.

Quando ci sono più di venti post in un argomento, Discourse invia i post al browser solo quando necessario. Potresti visualizzare un filo di oltre 1000 post con quasi nessun carico sul server perché la maggior parte del DOM è solo stub vuoti. È un’idea brillante, ma è anche ciò che fa sì che Ctrl+f si rompa misteriosamente.

Non sto suggerendo di eliminare l’illusione, poiché ritengo che valga la pena. Discourse ha fatto bene a abbandonare il vecchio metodo di suddividere le conversazioni in pagine arbitrarie con circa 40 post ciascuna.

Discourse deve solo fare meglio nel rendere l’illusione senza soluzione di continuità.

Soluzioni

Per essere onesti, non conosco la soluzione migliore a questo problema, ma ho alcune riflessioni che spero siano utili.

Rompere consapevolmente l’illusione

Innanzitutto, ecco alcune idee semplici e ragionevoli se Discourse decide di rompere l’illusione passando a una ricerca nel database:

  1. Informa l’utente su cosa sta succedendo. Inserisci un piccolo messaggio dove apparirebbe normalmente la casella di ricerca del browser, con una scusa e una spiegazione.
  • “Ci dispiace, ma questo argomento contiene 1002 post, ma il tuo browser ne ha caricati solo 7, quindi la funzione Trova nella pagina probabilmente non funzionerà. Se vuoi provare comunque, premi di nuovo Ctrl+f.”
  1. Dai all’utente un certo controllo. Quando un utente preme Ctrl+f, mostra un pulsante in modo che gli utenti possano caricare manualmente il testo da tutti i post dell’argomento nel DOM.
  • Se ciò fosse considerato impossibile a causa del limite di 100 post memorizzati nella cache nel browser contemporaneamente, mostra un pulsante che permetta agli utenti di tornare al vecchio modo di visualizzare gli argomenti: suddivisi per pagina.
  • “Clicca qui per visualizzare questo argomento in un modo compatibile con Ctrl+f: [Pagina 1] [2] [3] [4] [5] [6] [7] [8] [9] […] [>>]”
  1. Aumenta il limite predefinito da 20 a 100 post. Potrebbe non essere troppo difficile da modificare, dato che Discourse è già in grado di memorizzare nella cache quel numero di post nel DOM.

Riparare l’illusione

Naturalmente, queste idee sono poco eleganti e le considero solo soluzioni temporanee. Alla fine, la soluzione migliore sarebbe che Discourse implementi Ctrl+f in modo che funzioni come gli utenti si aspettano. Replicare in Discourse ciò che il browser fa per la ricerca interattiva ne varrebbe la pena, ma immagino che sarebbe difficile.

Tuttavia, potrebbe esserci una soluzione (relativamente) semplice.

Non rimuovere il testo dal DOM

Credo che la soluzione migliore per Discourse sia rimuovere dagli oggetti multimediali dei post, non il testo. In tal caso, non ci sarebbe bisogno di “hijackare ctrl+f” e sostituirlo con una ricerca nel database.

La funzione Trova nella pagina cerca solo testo, quindi non è necessario che il browser abbia l’intero DOM caricato per poterlo cercare. Il testo è incredibilmente leggero da inviare, soprattutto se il server HTTP ha la compressione gzip attivata. Il testo non occupa nemmeno molta memoria in un browser web.

Lo saprete meglio di me, ma ho alcune ipotesi:

  • Dimensione media di un post: 5 KiB di testo
  • Lunghezza media di un argomento: 50 risposte
  • Testo medio da trasferire: 250 KiB, che sembra ragionevole.

Naturalmente, ogni byte conta per la reattività. Se le mie stime sono errate e la dimensione del testo è un problema, il riempimento del DOM con il testo potrebbe essere eseguito come processo in background dopo che le parti importanti della pagina sono state inviate. Se il DOM non è stato completamente popolato con il testo al momento in cui l’utente preme Ctrl+f, può apparire un indicatore che informa l’utente di attendere e mostra l’avanzamento mentre il testo viene caricato gradualmente.

Grazie

Sebbene sia un problema serio che Ctrl+f rompa l’illusione creata da Discourse, sono impressionato dal lavoro straordinario che gli sviluppatori di Discourse hanno fatto nel creare quell’illusione fin dall’inizio. Sono fiducioso che troveranno presto anche la soluzione giusta per questo.

Grazie per aver dedicato il vostro tempo a considerare i miei suggerimenti.

Cordiali saluti,

Mx. F.N.

3 Mi Piace

Condivido la tua sensazione che l’esperienza utente qui sia frustrante e sorprendente. Per me è simile la goffaggine nel provare a scorrere su e giù in un semplice thread di 30 argomenti. È l’unica cosa di Discourse che mi mette in imbarazzo.

Mi chiedo se l’equilibrio tra una buona UX nei thread piccoli e medi e il non rompere tutto nei thread grandi sia davvero corretto. Nel mio progetto, i thread molto grandi difficilmente saranno un grosso problema, quindi è frustrante vedere l’esperienza utente compromessa dalle loro esigenze.

Ricordo di aver letto che il vero problema che limita l’approccio attuale è il tempo di rendering su Android. Se è così, sembra un peccato zavorrare tutti i dispositivi basandosi sui limiti di alcuni.

Mi piacerebbe sapere se è ragionevolmente possibile per uno sviluppatore personalizzare:
(1) il numero di argomenti per blocco (ad esempio, variabile in base al dispositivo)
(2) mantenere visibili gli argomenti già renderizzati, invece di scaricarli come avviene attualmente (il che rende lo scorrimento verso l’alto macchinoso)

Apprezzo che si tratti di un’area davvero complessa, senza soluzioni ideali e in cui è già stato dedicato molto lavoro.

1 Mi Piace

Ci sono state molte buone idee in questo thread, l’implementazione attuale (ancora) è pessima.
Non farlo, semplicemente non sovrascrivere le scorciatoie potenti. Anche il vecchio approccio dei Bulletin Board con diversi pulsanti di ricerca è più accessibile. Trova un buon modo per cercare un argomento o lascia che sia l’utente a caricare tutto il contenuto pertinente nel DOM (che è anche pessimo). Uno dei co-fondatori ha dato il miglior consiglio, premilo due volte. Sembra che siamo più intelligenti…