Proprietari di forum Discourse: siete interessati alle app mobile native?

È interessante, se si pensa al numero di app wrapper di WordPress che esistono.

@Aa7 Fatico a immaginare i vantaggi, ma sono certo aperto ad ascoltare le idee delle persone. Mi piace il fatto che tu abbia sottolineato come il focus sull’utente rispetto all’amministratore sia una scelta intelligente.

Forse offrire un servizio di pubblicazione white label potrebbe essere una porta d’accesso per questo? Il motivo per cui lo dico è che la persona che lo faceva in passato (il nome mi sfugge) ha smesso.

Oppure, si potrebbe costruire partendo da un’analisi UX del tema mobile. Ho notato che alcune persone disabilitano il tema mobile e usano la versione desktop completa sui miei forum… quindi potrebbe essere un indizio.
Inoltre, Google ha talvolta segnalato che alcune aree tattili sono troppo piccole.

1 Mi Piace

Apple è stata sicuramente incoerente nell’applicare le proprie normative.

Quindi, per prima cosa, ricostruirai l’intero frontend in un’app? Penso che tu stia sottovalutando enormemente la complessità e la quantità di lavoro che dovrà essere svolta in quel settore.

E poi, ogni volta che c’è un aggiornamento incompatibile di Discourse, devi:

  • accorgertene
  • capire cosa sta succedendo
  • adattare il tuo codice
  • inviare l’app per la revisione e attraversare un processo di approvazione incerto e potenzialmente lungo
  • aspettare che gli utenti del forum scoprano che c’è un aggiornamento e che abbiano aggiornato l’app sul loro telefono

Quanto tempo ci vorrebbe? Qualcosa tra un giorno e tre settimane, immagino? Forse cinque settimane, se ti capita di essere in vacanza?

Nel frattempo, a seconda del tuo processo, oppure

a) il forum non può essere aggiornato, esponendo potenzialmente problemi di sicurezza
b) il forum non può essere utilizzato tramite l’app

Non credo che questo funzionerà.

Penso che questa sia la questione principale che dobbiamo risolvere: trovare la funzionalità chiave che porterà Apple ad approvare queste app wrapper, e poi utilizzare l’approccio delle app wrapper.

10 Mi Piace

So che ho detto che un aggiornamento dell’app sarebbe seguito, ma lo sviluppo delle nuove release avviene in modo aperto. Qualsiasi adattamento può avvenire proprio parallelamente a questi cambiamenti. Inoltre, Discourse è una base di codice matura. Se si trattasse di qualcosa di così giovane come Talk (non è un confronto alla pari), dove l’API cambia spesso, non credo che lo prenderei in considerazione.

Per quanto riguarda il rilevamento delle modifiche e il rimanere aggiornati, sostengo che questo sia un lavoro a tempo pieno.

Non ho ancora stimato il lavoro. Ho lavorato nello sviluppo software per circa 13 anni: spero di non commettere un errore grave se intraprendo passi concreti per lavorare su questo.

1 Mi Piace

La maggior parte dei siti esegue test-passed, il che significa che sarai sempre alla ricerca della compatibilità invece di prepararti per le release.

2 Mi Piace

Sarei interessato all’app nativa di Discourse.

1 Mi Piace

[quote=“jtbayly, post:17, topic:127456”]
e non ritengono che le notifiche push siano un miglioramento sufficiente a giustificare un’app[/quote]

Il che è piuttosto ironico, considerando che non forniscono le notifiche push per Safari mobile…

3 Mi Piace

I “vantaggi” non sono forse principalmente per chi gestisce i siti/servizi piuttosto che per gli utenti? Quando hai un’app, i tuoi utenti sono un po’ più “cattivi”: aprono l’app e si trovano in un ambiente chiuso, piuttosto che in un browser web dove possono andare ovunque in qualsiasi momento. Hanno un’icona che porta direttamente alla tua app, invece di un altro segnalibro per il tuo sito (se ne hanno uno, o forse semplicemente dimenticheranno il tuo URL in un certo momento). E c’è solitamente la possibilità di ricevere notifiche push quando un’app è stata installata, anche se l’utente non l’ha aperta da un po’ di tempo.

È sottile, e ci sono effettivamente argomenti che dimostrano il contrario o che mostrano come si possa fare praticamente la stessa cosa senza un’app. Ma all’inizio, non sono stati i provider a spingere affinché le loro app venissero installate (anche se non portano davvero nulla agli utenti), piuttosto che gli utenti a chiederlo? (Gli utenti hanno accettato questa situazione e si sono abituati a questo modo di fare in un certo momento, e forse ora chiedono le app, anche se non sanno davvero perché. Forse ora la trovano comoda).

4 Mi Piace

Penso di sì.

Attualmente uso l’app ufficiale di Discourse e non riesco a pensare a nulla che le manchi (a parte le notifiche push per il mio sito e alcuni altri). Mi piace.

L’unica altra cosa che vorrei davvero è che avesse il nome e il logo della mia comunità, per il motivo…

È il mio caso. Le persone trovano piacevoli da usare dispositivi a scopo singolo. Su un telefono, lo trasformi in un dispositivo a scopo singolo aprendo un’app.

Esatto. Irritante.

5 Mi Piace

Quindi l’analisi. Non è una cosa negativa.

Scusa, non ti ho capito. Puoi per favore spiegare?

Per pura curiosità, quale forum gestisci? Grazie.

Lascia che io amplifichi quanto detto da @Stephen.

Come sviluppatore di plugin, posso dirti che mantenere il codice aggiornato per garantire la compatibilità con il core non è un compito banale e richiede una strategia attenta. I plugin vengono solitamente mantenuti in linea con il ramo “tests-passed”. Potresti optare per un ramo più lento, ma ciò significherebbe che anche i tuoi clienti lo sarebbero. Va bene, comunque. Tuttavia, avrai bisogno di un tempo di anticipo per aggiornare la tua applicazione dopo ogni rilascio stabile. Questo comporterà molto lavoro e potrebbe causare ritardi significativi negli aggiornamenti per i clienti.

Come i plugin, corri sempre il rischio che qualcosa si rompa dopo un cambiamento significativo nel core.

Affermi che il core di Discourse è stabile. Forse più di quanto non lo fosse all’inizio, ma dai un’occhiata accurata al repository: si muove (anche se gran parte di ciò riguarda l’app web). Basta guardare quanti commit vengono effettuati ogni giorno. Osserva il numero di PR aperte. Prendi un solo file, ad esempio Topic.hbs, e considera come intendi stare al passo solo con quello? Anche il fork del codice base di Discourse viene sconsigliato proprio per questa sfida. E si tratterebbe di una riscrittura nativa?

Userai solo la loro API? Allora va bene, ma come implementerai i plugin più popolari? Alcuni di essi apportano modifiche visive significative, molte delle quali utilizzano il monkey-patching con, ad esempio, JQuery o plugin outlet, che non potrai riutilizzare se passerai a una soluzione nativa. Dovrai reimplementarli con codice nativo?

I plugin sono solo la punta dell’iceberg. Ciò che proponi presumibilmente copre l’intera gamma delle funzionalità front-end per gli utenti. Tutto questo dovrà essere testato, con casi di test. Solo a pensarci fa impressione.

E com’è grande il tuo team? Ancora una volta, guarda quanti sviluppatori stanno facendo commit sul core. Aggiungi la popolazione degli autori di plugin inclusi nel perimetro. Questo ti dà un’altra metrica per la dimensione della sfida.

Dovrai avere una velocità che tenga il passo con i rilasci di Discourse (!), altrimenti tutti i tuoi clienti inizieranno a sentirsi bloccati rispetto alle nuove funzionalità.

Dovrai giustificare ogni ora che trascorri e recuperarla in termini di ricavi (e va bene, devi mettere il cibo in tavola come tutti noi).

Comunque, penso che potresti provare a implementare questa soluzione con l’obiettivo di crearne una demo. Inizierei con “solo” l’app core. Questo ti darà rapidamente un’idea di quanto sia grande il compito. Oppure, conta semplicemente quante chiamate API dovrai supportare.

Sono sicuro che tu abbia già pensato a tutto questo. Non voglio essere negativo, ma stai proponendo un lavoro considerevole, da svolgere in modo continuo e brutalmente incessante.

Che ne dici di guardare l’app ufficiale e vedere cosa puoi fare con quella?

13 Mi Piace

Per essere obiettivi, non credo che questo sarebbe un problema per un’app basata su codice nativo invece che su “semplicemente” una webview di un sito.

3 Mi Piace

È vero e ci sono moltissimi esempi di implementazioni native di app web. Ad esempio Facebook (anche se la loro app web è terribile)

Un’implementazione completamente nativa probabilmente non è a rischio.

Sono le app ‘incapsulate’ che prenderebbero di mira. Ho modificato il mio post.

3 Mi Piace

Ho soppesato l’idea di sviluppare anche un’app nativa completa (sono sviluppatore iOS di professione). La baserei sulla (pubblica?) API HTTP di Discourse. Esiste qualche garanzia sulla stabilità dell’API o su una sua versionatura, per evitare che vecchie versioni dell’app smettano di funzionare inaspettatamente?

2 Mi Piace

Le comunità che utilizzano l’app nativa possono seguire il nostro ramo lento (ovvero “stable”). Inoltre, non modifichiamo spesso le API, che sono molto stabili.

7 Mi Piace

L’app potrebbe basarsi sulla REST API di Discourse, che dovrebbe essere piuttosto stabile. Potrebbe quindi avere qualsiasi interfaccia utente/esperienza utente desideri, magari anche diversa da quella dell’app web (questo potrebbe essere meglio o peggio). Se l’autore dell’app sceglie un approccio diverso (non sono sicuro che sia nemmeno possibile), incontrerà il problema che descrivi.

2 Mi Piace

Sì. Un aspetto diverso ma coerente potrebbe essere visto positivamente da alcune persone, ma probabilmente solo se si trattasse di un’app a cui è possibile aggiungere più istanze, come l’app ufficiale. Tuttavia, non è questo che interessa a molte persone. Immagina che l’app personalizzata del tuo sito abbia uno stile completamente diverso dal sito. Non è una buona idea.

E non riesco a immaginare che qualcuno sia soddisfatto di un’app che non supporta tutte le funzionalità del proprio sito. Quindi i plugin diventano un problema fin da subito.

4 Mi Piace

Sono d’accordo, questa potrebbe essere la parte più delicata. Un’app nativa potrebbe finire per sembrare peggiore del wrapper web se i plugin non sono supportati. Una prima soluzione ragionevole sarebbe supportare i plugin più popolari e, col tempo, aggiungere il supporto per altri.

4 Mi Piace