La leggibilità consiste principalmente in euristiche che "in qualche modo funzionano bene" in molti casi.
Ho scritto alcuni articoli di ricerca su questo argomento e vorrei spiegare il motivo per cui è facile trovare una soluzione che funzioni bene e quando diventa difficile avvicinarsi al 100% di accuratezza.
Sembra esserci una legge linguistica sottostante al linguaggio umano che si manifesta anche (ma non esclusivamente) nel contenuto di una pagina Web, che separa già abbastanza chiaramente due tipi di testo (full-text vs. non-full-text o, approssimativamente, " contenuto principale "vs." boilerplate ").
Per ottenere il contenuto principale dall'HTML, in molti casi è sufficiente mantenere solo gli elementi di testo HTML (cioè blocchi di testo che non vengono interrotti dal markup) che hanno più di 10 parole circa. Sembra che gli esseri umani scelgano tra due tipi di testo ("breve" e "lungo", misurati dal numero di parole che emettono) per due diverse motivazioni di scrittura del testo. Le chiamerei motivazioni "di navigazione" e "informative".
Se un autore vuole che tu riceva velocemente ciò che è scritto, usa un testo "di navigazione", cioè poche parole (come "STOP", "Leggi questo", "Clicca qui"). Questo è il tipo di testo più prominente negli elementi di navigazione (menu ecc.)
Se un autore vuole che tu capisca a fondo cosa intende, usa molte parole. In questo modo, l'ambiguità viene rimossa a costo di un aumento della ridondanza. Il contenuto simile a un articolo di solito rientra in questa classe poiché contiene più di poche parole.
Anche se questa separazione sembra funzionare in una miriade di casi, sta diventando complicata con titoli, frasi brevi, dichiarazioni di non responsabilità, piè di pagina di copyright ecc.
Esistono strategie e funzionalità più sofisticate che aiutano a separare il contenuto principale dal boilerplate. Ad esempio la densità del collegamento (numero di parole in un blocco che sono collegate rispetto al numero totale di parole nel blocco), le caratteristiche dei blocchi precedenti / successivi, la frequenza di un particolare blocco di testo nel Web "intero", Struttura DOM del documento HTML, l'immagine visiva della pagina ecc.
Puoi leggere il mio ultimo articolo " Boilerplate Detection using Shallow Text Features " per avere un'idea da una prospettiva teorica. Puoi anche guardare il video della mia presentazione su VideoLectures.net.
"Leggibilità" utilizza alcune di queste funzionalità. Se osservi attentamente il log delle modifiche SVN, vedrai che il numero di strategie variava nel tempo, così come la qualità dell'estrazione di Readability. Ad esempio, l'introduzione della densità dei collegamenti nel dicembre 2009 ha notevolmente contribuito a migliorare.
A mio parere, quindi, non ha senso dire "La leggibilità fa così", senza menzionare il numero esatto di versione.
Ho pubblicato una libreria di estrazione di contenuti HTML Open Source chiamata boilerpipe , che fornisce diverse strategie di estrazione. A seconda del caso d'uso, l'uno o l'altro estrattore funziona meglio. Puoi provare questi estrattori su pagine di tua scelta utilizzando l'app boilerpipe-web complementare su Google AppEngine.
Per far parlare i numeri, vedere la pagina " Benchmark " sul wiki boilerpipe che confronta alcune strategie di estrazione, tra cui boilerpipe, Readability e Apple Safari.
Dovrei menzionare che questi algoritmi presumono che il contenuto principale sia in realtà il testo completo. Ci sono casi in cui il "contenuto principale" è qualcos'altro, ad esempio un'immagine, una tabella, un video, ecc. Gli algoritmi non funzioneranno bene in questi casi.
Saluti,
cristiano