Il "lettore Markdown/HTML per mobile" di cui avevo accennato è pronto, e si chiama Jilan.
Risolve un problema piccolo ma sempre più fastidioso:
Quando qualcuno ti invia un report AI, una presentazione web o un documento Markdown tramite WeChat, l'app File o una chat di gruppo, aprirlo sul telefono di solito si traduce in una schermata bianca, codice sorgente non elaborato, stili rotti o totale confusione su quale app usare.
File come .md, .markdown, .html, .htm, .txt e persino archivi ZIP web possono ora essere aperti direttamente su iPhone e iPad usando Jilan.
Rendering locale, archiviazione locale: niente caricamenti e nessuna registrazione richiesta.
In fondo c'è un link TestFlight; puoi candidarti direttamente se vuoi provarlo. Ho aperto 8.000 posti.
Ma non ho creato Jilan solo perché ci mancava un lettore.
Il motivo più diretto è che ultimamente ho la sensazione sempre più chiara che, con l'AI che partecipa alla produzione di contenuti, i formati che usiamo per scambiarci i contenuti stanno cambiando.
Molti contenuti testuali stanno approdando al Markdown, e molte presentazioni stanno atterrando in HTML.
Jilan è solo un piccolo strumento nato da questo cambiamento quando è arrivato al lato mobile.
Markdown non è solo un formato di testo; sta diventando il livello dati per l'AI
Qualche giorno fa ho visto una citazione dell'autore di Obsidian che trovo molto azzeccata: .md sta diventando un punto di Schelling nell'interazione tra file AI.
Un punto di Schelling è una scelta verso cui le persone gravitano naturalmente, senza alcuna regolamentazione forzata.
Markdown è un po' così ora.
Nessuno ha imposto che l'AI dovesse usare Markdown, e nessun comitato di standardizzazione è uscito a fare annunci.
Ma nell'uso reale, sia che gli umani scrivano all'AI sia che l'AI scriva per gli umani, il risultato finisce spesso in un file .md.
Il motivo è semplice.
È testo semplice, quindi leggero da leggere e scrivere per i modelli.
Ha abbastanza struttura per esprimere titoli, elenchi, tabelle, blocchi di codice e link.
E non è racchiuso in un formato complesso come .docx.
Gli umani possono aprirlo direttamente, l'AI può elaborarlo direttamente e la gestione delle versioni e i diff sono puliti.
Ma credo che la cosa più importante sia che Markdown non può più essere inteso solo come "testo in un editor".
È più come il dato sottostante in un flusso di lavoro AI.
È così che lo uso in CodePilot.
Non ha un meccanismo di memoria particolarmente complesso; molti ricordi sono in realtà solo un insieme di file Markdown.
L'AI ci scrive, l'AI ci legge, e io posso aprirli e modificarli personalmente.
Inoltre, i widget in CodePilot possono usare questi file Markdown locali e i ricordi come fonti di dati.
Quando il file cambia, la visualizzazione del componente cambia con esso.
A questo punto, Markdown non è più solo "un articolo da leggere".
Diventa un livello dati locale molto leggero: gli umani possono vederlo, l'AI può leggerlo e gli strumenti possono generare nuove interfacce e interazioni basate su di esso.
Questo è anche il motivo per cui penso che la direzione che molti stanno prendendo continuando a rifinire gli editor Markdown potrebbe essere un po' limitata.
La cosa veramente interessante non è creare una casella di modifica più bella, ma trattare Markdown come dati per costruire nuovi modi di leggere, gestire e interagire uomo-computer.
L'HTML sta diventando il livello di visualizzazione per i contenuti AI
Dall'altro lato c'è l'HTML. Anche questa tendenza è diventata sempre più ovvia ultimamente.
Il mese scorso ho reso open source una PPT Skill che genera presentazioni in formato web.
Ha raggiunto 10.000 stelle in 25 giorni e, in seguito, in difese offline, mostre e sessioni di condivisione, ho visto ripetutamente persone usare presentazioni create con essa.
Questo mi ha confermato una cosa:
In molti scenari, ciò che le persone vogliono non è un file .pptx standard, ma una presentazione che possa essere esposta, compresa e condivisa rapidamente.
Casualmente, anche il team di Claude Code ne ha parlato di recente.
Hanno un articolo che spiega perché sempre più output iniziano a usare HTML invece di Markdown.
Il motivo è diretto: l'HTML ha una densità informativa maggiore, è più facile per la gerarchia visiva, è migliore per mostrare grafici, layout e interazioni, ed è più facile per gli altri da aprire e leggere.
Questo è molto vicino alla mia esperienza personale.
Markdown è buono per consolidare i contenuti, ma diventa difficile da leggere quando è lungo. Un report di migliaia o decine di migliaia di parole ammassato in un file .md è difficile da digerire per un umano, anche se la struttura è corretta.
L'HTML è l'opposto. Può usare layout, spazio, colore, grafici e interazione per organizzare le informazioni in qualcosa che sembra più "da consumare". Non è migliore per memorizzare fatti, ma è migliore per aiutare le persone a capirli.
Quindi sono sempre più incline a vedere queste due cose separatamente:
Markdown è il livello dati, HTML è il livello di visualizzazione.
Tieni il contenuto sottostante in Markdown: pulito, leggibile e versionabile.
Quando deve essere mostrato alle persone, presentato o condiviso esternamente, renderizzalo in HTML.
Non è un nuovo grande standard; è più una divisione del lavoro che è cresciuta naturalmente dai flussi di lavoro AI.
Ma questa catena si rompe sul mobile
Il contenuto c'è, i file vengono inviati, ma il problema si presenta all'ultimo passo: le persone li aprono spesso sui loro telefoni.
Il desktop è a posto. Hai browser, editor e, in casi estremi, VS Code.
Ma il mobile è diverso.
Specialmente quando ricevi un report generato dall'AI, una presentazione web o un documento Markdown in WeChat, l'esperienza comune è che non si apre, mostra codice sorgente, ha stili rotti o richiede di passare da un'app all'altra. È una piccola cosa, ma molto fastidiosa.
Un'app di messaggistica come WeChat non è essenzialmente un lettore di file.
La sua priorità è chattare, visualizzare in anteprima e inoltrare, non aprire seriamente un file Markdown o HTML.
Neanche i browser sono progettati per questo scenario.
Per impostazione predefinita, i browser gestiscono "mi dai un link, ti apro la pagina web".
Ma ciò che gli altri ti inviano è spesso un file locale, non un link. Puoi certamente fare acrobazie per buttare l'HTML in un browser, ma l'intera catena è lunga e scomoda.
Anche molti strumenti Markdown sono orientati alla modifica e agli appunti, e non sono necessariamente adatti ad aprire temporaneamente un file inviato da qualcun altro.
Per non parlare del fatto che alcuni strumenti richiedono di importare, sincronizzare, creare una libreria o registrare un account.
L'HTML ha un ulteriore livello di problemi di sicurezza: un file strano potrebbe contenere script, e non è detto che tu voglia che vengano eseguiti per impostazione predefinita.
Quindi ho sempre pensato che mancasse una cosa molto semplice:
Un modo per aprire in modo sicuro e conveniente questi comuni file del flusso di lavoro AI su un telefono.
Questo è Jilan.
Jilan è molto focalizzato: Aprire, Leggere, Conservare
Jilan non è stato trasformato in un editor, né è stato collegato all'AI. Tra l'altro, devo lodare l'icona dell'app disegnata da CodeX; è così carina.
Sono stato molto chiaro fin dall'inizio: fa solo tre cose: Aprire, Leggere, Conservare.
Quando ricevi un file, seleziona Jilan da WeChat, dall'app File o dal foglio di condivisione di sistema per aprirlo. Supporta file .md, .markdown, .html, .htm, .txt e .zip confezionati da risorse web.
Tutti i file sono elaborati localmente: niente caricamenti, nessuna registrazione.
Quando si legge Markdown, l'ho ottimizzato principalmente per la lettura di testi lunghi.
Dimensione del carattere, interlinea e sfondo possono essere modificati; le tabelle lunghe possono essere scrollate orizzontalmente; i documenti con struttura di titoli possono usare un indice per saltare.
Anche la sintassi comune di Obsidian, come elenchi di attività, Callout, note a piè di pagina, Frontmatter e tag, è compatibile per quanto possibile.
Supporta anche il passaggio tra modalità scura e temi colore.
Quando leggo HTML, mi interessa di più il "controllo".
Usa il WebView di sistema per il rendering locale, supporta lo zoom, il passaggio tra ritratto e paesaggio e il passaggio tra modalità mobile e desktop.
Gli script dinamici sono disattivati per impostazione predefinita. Di solito non sai se ci sono script in un file HTML sconosciuto.
Quindi Jilan non presume l'esecuzione di script per impostazione predefinita; se incontri una pagina che ha davvero bisogno di JS per essere visualizzata, puoi attivarlo manualmente.
Il supporto ZIP è stato creato anche per scenari reali.
Molte pagine web esportate dall'AI non sono un singolo file HTML, ma un index.html più una cartella assets.
Jilan troverà automaticamente il punto di ingresso dopo la decompressione, e le immagini locali e i CSS potranno caricarsi normalmente, così gli stili non vengono persi e le immagini non sono rotte.
I file che hai aperto rimarranno automaticamente nella cronologia locale. Se vuoi rivederli la prossima volta, li troverai nell'app.
Importare lo stesso file più volte non crea duplicati, e quelli importanti possono essere aggiunti ai preferiti.
Questo è il suo attuale confine.
Non fa sincronizzazione cloud, account, modifica o integrazione AI.
Non perché queste funzionalità non siano importanti, ma perché un visualizzatore dovrebbe prima svolgere bene il compito di "aprire e finire di leggere".
Jilan segue le prime due cose
Guardando indietro, Jilan non è uno strumentino isolato.
Il mese scorso ho creato PPT Skill perché credo che l'HTML diventerà una forma molto naturale per l'AI di generare contenuti di presentazione.
Non sostituirà necessariamente PowerPoint, ma per "generare rapidamente qualcosa che possa essere presentato", l'HTML è abbastanza leggero, abbastanza aperto e abbastanza adatto per essere generato direttamente dai modelli.
Ho creato CodePilot perché credo che Markdown diventerà un vettore di dati e memoria molto naturale nella collaborazione AI.
Non è il formato più carino, ma è il più facile da usare contemporaneamente per umani, modelli e strumenti.
Jilan gestisce il terzo passo:
Questi formati non possono fermarsi all'essere "generati"; le persone devono poterli effettivamente aprire, leggere e conservare.
I primi due riguardano la produzione; Jilan riguarda il consumo.
L'AI può già generare Markdown e HTML.
Ma se questi file si rompono appena arrivano a un telefono, non importa quanto sia stata fluida l'esperienza di generazione, non è arrivata veramente nelle mani della persona.
Jilan colma quell'ultimo miglio.
Ma questo è tutt'altro che finito
Jilan attualmente riempie solo lo strato più superficiale: ricevere un file e aprirlo.
Andando avanti, ci sono ancora diversi problemi da risolvere.
Ad esempio, la gestione.
Molte persone hanno già un gran numero di file Markdown e HTML sparsi sui loro telefoni, cloud, chat e varie cache di app.
Non sono privi di valore; sono solo troppo sparsi per essere trovati o gestiti.
Ad esempio, la condivisione.
Jilan risolve "come faccio a vedere ciò che altri mi inviano".
Ma al contrario, "ho creato un file HTML, come faccio a far sì che altri lo aprano comodamente" è ancora una seccatura.
Se invii il file, l'altra persona potrebbe non riuscire ad aprirlo; se invii un link, devi trovare un posto per implementarlo da solo.
Ad esempio, cross-device.
Leggere a metà su un telefono e continuare su un computer, o generare un report su un computer e inviarlo a un telefono per leggerlo, sono tutte cose molto naturali.
Ma non appena fai sincronizzazione, ti imbatti in account, cloud, privacy e complessità.
Jilan è ancora molto piccolo—così piccolo che non voglio davvero confezionarlo come un grande prodotto.
Ma si inserisce perfettamente nel vuoto che incontro ogni giorno:
L'AI ha generato il contenuto, ma io voglio solo dargli un'occhiata per bene sul mio telefono.
Se anche tu sei spesso infastidito da file Markdown, HTML e presentazioni web, provalo.
TestFlight:
Mi piacerebbe anche sentire la tua opinione su questo: dopo il coinvolgimento dell'AI, cosa diventeranno realmente documenti, presentazioni e letture?
