Jump to content

App di Wikipedia/Team/Il futuro della modifica dei contenuti nelle app mobili

From mediawiki.org
This page is a translated version of the page Wikimedia Apps/Team/Future of Editing on the Mobile Apps and the translation is 100% complete.

Definizione del problema

Le app attirano nuovi utenti ogni anno e si prevede di promuoverle presso un pubblico più ampio. Le funzionalità di lettura sono il motivo principale per cui gli utenti scaricano le app e la maggior parte dei commenti che il team riceve riguarda proprio il miglioramento di tali funzionalità. Man mano che questi lettori si avvicinano a Wikipedia, alcuni sviluppano un interesse a contribuire. Tra coloro che tentano di modificare i contenuti, molti scoprono che l'esperienza di modifica dell'app (pur essendo funzionale per modifiche di base) non include ancora il Visual Editor e altre funzionalità disponibili sul web mobile. Inoltre, i nuovi utenti trovano difficile trovare spazi della comunità come la Teahouse e l'Help Desk dalle app.

Ciò comporta un rischio per il reclutamento dei contributori. Molti di loro cominciano a contribuire correggendo piccoli errori mentre leggono distrattamente. Se questi momenti di impulso si verificano all'interno dell'app e un nuovo utente si trova di fronte al wikitesto senza la possibilità di utilizzare VisualEditor, potrebbe scoraggiarsi prima ancora di aver preso confidenza con il sistema.

Cosa emerge dalla ricerca

Uno studio condotto nell'aprile 2025 sulla lettura e la modifica dei contenuti nell'app per iOS ha evidenziato modelli ricorrenti sia tra i contributori alle prime armi che tra quelli con maggiore esperienza: senza VisualEditor, il wikitesto diventa un ostacolo. Poiché l'app non dispone di VisualEditor, chiunque apra un articolo per modificarlo si trova immediatamente di fronte al wikitesto grezzo, che assomiglia a un codice e induce molti nuovi utenti a ritenere che la modifica richieda conoscenze tecniche. Questa percezione scoraggia attivamente il contributo prima ancora che abbia inizio. Nemmeno i contributori esperti ne sono immuni: anche chi ha dimestichezza con il wikitesto trova che la modifica diretta del codice sull'app mobile sia lenta e soggetta a errori. Il VisualEditor è stato costantemente descritto dai partecipanti allo studio come più veloce e intuitivo. La sua assenza nell'app è, per molti, il motivo principale per cui non apportano modifiche tramite essa.

Alcune citazioni dirette dei partecipanti allo studio:

Su PC è possibile scegliere tra la modifica del codice sorgente e quella visiva, il che rende il tutto molto più intuitivo. Nell'app, invece, la modifica visiva sembra non essere disponibile, il che è un peccato. Se venisse aggiunta, renderebbe la modifica più accessibile ai principianti.

Dovrebbe esserci la possibilità di modificare i contenuti senza dover vedere il codice wiki, proprio come sulla versione desktop. Visual Editor: ci vorrebbe qualcosa di simile anche per l'app. Penso che renderebbe tutto molto più pratico.

Non aggiungerei proprio nessun riferimento perché mi sento intimidito da tutti questi simboli qui. È davvero complicato fare qui una revisione approfondita basata sulla ricerca.

Feedback ricevuto dalla comunità

Questi risultati sono in linea con quanto segnalato in modo indipendente da contributori esperti. Tali preoccupazioni vengono prese sul serio. Lo scopo di questa pagina è quello di affrontarle in modo trasparente.

Questi risultati sono in linea con quanto segnalato in modo indipendente dai contributori. Le citazioni riportate di seguito sono state raccolte dalle recensioni degli app store, dalle e-mail inviate all'assistenza e da una recente discussione nel Bar di Wikipedia in inglese.

Spesso passo alla versione mobile del sito per modificare i contenuti, perché lì gli strumenti sono più facili da usare.

Se l'app limita le possibilità di modifica o presenta funzionalità mancanti rispetto alla versione web per dispositivi mobili, dovrebbe indicare chiaramente che quest'ultima è più adatta a tale attività.

Niente VisualEditor, niente accesso all'Help Desk o alla Teahouse... Non adatta ai nuovi contributori. Non adatta ai contributori esperti. Se la WMF intende rendere l'app equivalente alla versione web per dispositivi mobili, sono d'accordo. Se invece rimarrà pessima, allora è meglio allontanare i contributori dall'app il prima possibile. L'esperienza di lettura è migliore sull'app. Ma le persone leggono Wikipedia perché chi li ha preceduti ha modificato i contenuti per crearli.

Il pulsante “modifica” dell'app potrebbe reindirizzare al sito web? Molte persone apportano le prime modifiche correggendo gli errori ortografici mentre leggono. Se l'app risulta poco intuitiva per la modifica, allontanerà i potenziali contributori.

Per modificare i contenuti sull'app è necessario utilizzare il wikitesto, il che rende l'operazione complessa per i principianti.

L'app funziona bene per la lettura, ma non è molto pratica per la modifica.

Se la modifica funziona meglio sul sito web mobile, l'app dovrebbe consentire facilmente di continuare a modificare da lì.


Background e contesto

Le app mobili di Wikipedia (per iOS e Android) sono state inizialmente concepite come strumenti di lettura; nel corso del tempo sono state integrate funzionalità di modifica nativa e di "modifiche suggerite" che molti utenti utilizzano attivamente. Le app e il sito web mobile non hanno mai mirato alla parità di funzionalità; si sono invece concentrate deliberatamente sulla continuità, sperimentando al contempo diverse funzionalità e rivolgendosi a diversi segmenti di utenti. Ad esempio, le app hanno introdotto per prime le "modifiche suggerite” come metodo di contribuzione pensato innanzitutto per i dispositivi mobili, che in seguito sono state sviluppate e ottimizzate anche sul sito web mobile.

La Wikimedia Foundation ha preso la decisione strategica di investire nel pubblico dei lettori oltre che nella modifica, creando dei team di Reader per contrastare il calo dei lettori e formare una nuova generazione di utenti di Wikipedia. Nell'ambito della strategia che ne deriva, le app saranno posizionate come l'esperienza di lettura di punta per i lettori assidui, puntando sulla scoperta personalizzata, sul coinvolgimento quotidiano e su un legame più profondo con i contenuti di Wikipedia. Nel frattempo, le attività di modifica si stanno concentrando sul web grazie ai team di Contributor, che hanno integrato nell'esperienza di modifica strumenti quali il "controllo delle modifiche" all'interno del Visual Editor, delle "modifiche suggerite" e la pagina iniziale per i nuovi utenti. Il web mobile sarà inoltre teatro di investimenti derivanti dalla ricerca in corso nel campo dalla modifica mobile.

I team Reader e Contributor stanno collaborando su questo progetto, e l'introduzione della funzione di modifica è particolarmente importante nelle app, dove una grande percentuale di utenti visita il sito quotidianamente e dove gli utenti abituali sono più propensi a provare a modificare i contenuti. Quando un utente dell'app manifesta interesse a modificare i contenuti, cosa dovrebbe succedere dopo? È proprio questo l'argomento che questa pagina intende approfondire.

Possibili soluzioni

Cosa si sta prendendo in considerazione

  • Consentire l'accesso al Visual Editor della versione web per dispositivi mobili dall'interno dell'app: l'app potrebbe offrire agli utenti la possibilità di continuare a modificare i contenuti nella versione web per dispositivi mobili, dove sono disponibili il Visual Editor e altri strumenti più completi. Ciò che è meno chiaro è come farlo in modo efficace. Alcune domande su cui si sta riflettendo:
    • L'app dovrebbe consentire un passaggio diretto, aprendo l'articolo nell'editor web mobile quando l'utente tocca “Modifica” e mantenendo la posizione in cui si trovava nell'app in modo che possa tornarci in seguito?
    • L'editor web mobile dovrebbe essere proposto come opzione predefinita nel momento in cui l'utente manifesta l'intenzione di modificare il contenuto, oppure come scelta consapevole?
    • Come dovrebbe presentarsi la transizione? Tramite una visualizzazione web all'interno dell'app, un reindirizzamento al browser, un messaggio chiaro o un banner permanente.

Cosa non si sta prendendo in considerazione

  • Eliminare completamente i punti di accesso alla modifica dall'app: I lettori più attivi sono ottimi candidati per la prima modifica, e la base di lettori in crescita dell'app rappresenta un'opportunità per aumentare questa quota. Per le funzionalità incentrate sui lettori che richiedono un account, come la scheda “Attività”, una quota consistente di nuovi account viene attivata all'interno delle app. La percentuale di nuovi contributori sulle app (il 18–22% delle modifiche apportate da utenti con un anno o meno di esperienza) è attualmente inferiore rispetto al sito web, e l'obiettivo di far crescere questa fascia di utenti è uno dei temi al centro della discussione. Allo stesso tempo, il 33–37% delle modifiche sulle app proviene da contributori con cinque o più anni di esperienza, che si avvalgono dei punti di accesso già esistenti. Qualsiasi cambiamento dovrà tenere conto di entrambe le fasce di utenti.
  • Sviluppo di un editor visivo completamente nativo per le app: Si tratterebbe di un impegno notevole per il team delle app mobili e ne limiterebbe la capacità di investire in funzionalità volte a fidelizzare i lettori. Un editor visivo nativo nelle app non trarrebbe immediatamente vantaggio dai miglioramenti e dalle nuove funzionalità dell'editor visivo web; pertanto, mantenere la parità delle funzionalità richiederebbe un investimento costante in un ambito in cui lo sviluppo delle app è già in ritardo di anni.

Discussione

La pagina di discussione è aperta alle discussioni. Ci sono questioni più ampie relative al futuro della modifica sulle app, tra cui il ruolo dei “modifiche suggerite”, come supportare i contributori esperti e quali segnali consentono di identificare un potenziale contributore, in modo da poter poi proporre il giusto invito all'azione e affidargli il lavoro in modo proattivo. Sono graditi commenti su questi aspetti più generali. L'attenzione attuale, tuttavia, è rivolta a un aspetto più specifico: quando un utente dell'app tocca “Modifica” su un articolo, in che modo l'app dovrebbe garantire che possa accedere agli strumenti di modifica più avanzati disponibili, compreso VisualEditor sul web mobile?

Domande per le comunità

Alcune domande specifiche alle quali sarebbe particolarmente utile ricevere una risposta:

  • Quali sono i flussi di lavoro di modifica o gli spazi della community più importanti che devono essere accessibili (anche tramite reindirizzamento) dall'interno dell'app?
  • Se l'editor web mobile fosse accessibile dall'app, le app mobili dovrebbero eliminare del tutto l'editor nativo?
  • Per i contributori che hanno provato a modificare i contenuti tramite l'app: in quale momento l'esperienza si è rivelata insoddisfacente, e l'accesso a VisualEditor o alla versione web mobile avrebbe potuto cambiare le cose?
  • Ci sono aspetti del passaggio dall'app all'editor web mobile che è particolarmente importante gestire correttamente?
  • Come dovrebbe presentarsi questa transizione? Un messaggio di avviso, un reindirizzamento, una spiegazione chiara di dove sta andando l'utente e perché?
  • Per i contributori che seguono i nuovi arrivati: con quale frequenza l'app viene utilizzata come primo strumento di modifica e quali problemi ne derivano?