Donos de fóruns Discourse: vocês têm interesse em aplicativos móveis nativos?

Mercado
23

Isso é interessante quando se pensa na quantidade de aplicativos “wrapper” do WordPress por aí.

@Aa7 Estou com dificuldade de pensar nas vantagens, mas estou aberto a ouvir as ideias de todos, com certeza. Gosto do fato de você mencionar que o foco no usuário em vez do administrador é inteligente.

Talvez oferecer um serviço de publicação com marca branca possa ser uma porta de entrada para isso? A razão pela qual digo isso é que a pessoa que fazia isso em determinado momento (o nome me escapa) parou.

Ou talvez construir algo a partir de uma análise detalhada da UX do tema móvel. Notei que algumas pessoas desativam o tema móvel e usam apenas a versão desktop nos meus fóruns… então isso pode ser uma pista.
Além disso, o Google, em algumas ocasiões, reclamou de algumas áreas de toque estarem muito pequenas.

1 curtida
24

A Apple definitivamente tem sido inconsistente na aplicação de suas políticas.

25

Então, primeiro, você vai recriar todo o frontend em um app? Acredito que você está subestimando grosseiramente a complexidade e a quantidade de trabalho que precisa ser feita ali.

E, em seguida, toda vez que houver uma atualização incompatível do Discourse, você precisará:

  • perceber isso
  • entender o que está acontecendo
  • adaptar seu código
  • enviar o app para revisão e passar por um processo de aprovação incerto e possivelmente demorado
  • esperar até que os usuários do fórum descubram que há uma atualização e atualizem o app em seus celulares

Então, quanto tempo isso levaria? Algo entre um dia e três semanas, imagino? Talvez cinco semanas, se você estiver de férias?

Enquanto isso, dependendo do seu processo, seja:

a) o fórum não pode ser atualizado, possivelmente expondo questões de segurança
b) o fórum não pode ser usado por meio do app

Não acho que isso vai funcionar.

Acho que essa é a principal questão que precisamos resolver: encontrar a funcionalidade definitiva que fará a Apple aprovar esses apps wrapper e, em seguida, usar a abordagem de wrapper.

10 curtidas
26

Sei que disse que uma atualização do app seguiria, mas o desenvolvimento de novas versões ocorre de forma aberta. Qualquer adaptação pode acontecer simultaneamente a essas mudanças. Além disso, o Discourse é uma base de código madura. Se fosse algo tão novo quanto Talk (não é uma comparação justa), onde a API muda com frequência, eu não acho que consideraria isso.

Quanto a perceber as mudanças e se manter atualizado, afirmo que isso é um trabalho de tempo integral.

Ainda não estimei o trabalho. Tenho cerca de 13 anos de experiência em desenvolvimento de software — espero não cometer um erro grave ao dar passos concretos para trabalhar nisso.

1 curtida
27

A maioria dos sites executa testes-passados, o que significa que você estará sempre perseguindo compatibilidade em vez de se preparar para lançamentos.

2 curtidas
28

Estaria interessado no aplicativo nativo do Discourse.

1 curtida
29

O que é bastante irônico, considerando que eles não oferecem notificações push para o Safari móvel…

3 curtidas
30

As “vantagens” não são principalmente para quem opera os sites/serviços, e não para os usuários? Quando você tem um aplicativo, seus usuários ficam um pouco mais “cativos”: eles abrem o app e estão em um ambiente fechado, em vez de um navegador web onde podem ir a qualquer lugar a qualquer momento. Eles têm um ícone que leva diretamente ao seu aplicativo, em vez de outro marcador para o seu site (se tiverem um, ou talvez acabem esquecendo sua URL em algum momento). E geralmente há a possibilidade de notificações push quando um aplicativo foi instalado, mesmo que o usuário não o tenha aberto há algum tempo.

É sutil, e há, de fato, argumentos de que isso não é verdade ou de que você poderia fazer praticamente a mesma coisa sem um aplicativo. Mas, no início, não foram os provedores que pressionaram para que seus aplicativos fossem instalados (mesmo que não tragam realmente nada aos usuários), em vez de os usuários pedirem isso? (Os usuários aceitaram e se acostumaram com esse jeito de fazer em algum momento, e talvez agora estejam pedindo aplicativos, mesmo sem saber exatamente por quê. Talvez eles agora considerem isso conveniente.)

4 curtidas
31

Eu acho que sim.

Atualmente, uso o aplicativo oficial do Discourse e não consigo pensar em nada que esteja faltando (exceto notificações push para meu site e alguns outros). Gosto dele.

A única outra coisa que realmente quero é que ele tenha o nome e o logotipo da minha comunidade, pelo motivo…

É o meu caso. As pessoas acham dispositivos de propósito único agradáveis de usar. No celular, você o transforma em um dispositivo de propósito único abrindo um aplicativo.

Exatamente. Irritante.

5 curtidas
32

Então, análise de dados. Nada mal.

35

Desculpe, não entendi. Poderia explicar, por favor?

36

Por curiosidade, qual fórum você administra? Obrigado.

37

Deixe-me elaborar sobre o que @Stephen disse.

Como desenvolvedor de plugins, posso afirmar que manter o código atualizado para ser compatível com o núcleo não é uma tarefa trivial e exige uma estratégia cuidadosa. Os plugins geralmente são mantidos em sincronia com a branch tests-passed. Você poderia optar por uma branch mais lenta, mas isso significaria que seus clientes também ficariam para trás. Tudo bem, mas você precisará de um prazo para atualizar seu aplicativo após cada lançamento estável. Isso será um grande trabalho e pode levar a atrasos significativos nas atualizações dos clientes.

Assim como os plugins, você sempre corre o risco de algo quebrar após uma mudança significativa no núcleo.

Você afirma que o núcleo do Discourse é estável. Talvez mais do que no início, mas dê uma olhada cuidadosa no repositório; ele evolui (embora grande parte disso possa ser o aplicativo web). Basta ver quantos commits são feitos diariamente. Olhe o número de PRs abertos. Pegue apenas um arquivo, por exemplo, Topic.hbs, e considere como você manterá-se atualizado apenas com isso? Até mesmo fazer um fork da base do núcleo do Discourse é desencorajado exatamente por esse desafio. E isso será uma reescrita nativa?

Você usará apenas a API deles? Então tudo bem, mas como você implementará qualquer um dos plugins populares? Alguns deles têm mudanças visuais significativas, a maioria das quais usa monkey-patching com, por exemplo, JQuery ou plugin outlets, que você não poderá reutilizar se for nativo. Você reimplementará tudo isso com código nativo?

Os plugins são apenas a ponta do iceberg. O que você está propondo é presumivelmente o escopo completo de toda a funcionalidade de front-end para o usuário. Tudo isso precisará ser testado. E casos de teste. Apenas uau.

E quão grande é sua equipe? Novamente, veja quantos desenvolvedores estão contribuindo para o núcleo. Some a população de autores de plugins dentro do escopo. Isso lhe dá outra métrica para o tamanho do desafio.

Você precisará de uma velocidade que acompanhe os lançamentos do Discourse (!), ou todos os seus clientes começarão a sentir que estão sendo impedidos de acessar novos recursos.

Você precisará justificar cada hora que gastar e recuperar isso em receita (e isso é ok, você precisa colocar comida na mesa, como o resto de nós).

Mas, de qualquer forma, acho que você poderia tentar implementar isso com o objetivo de demonstrá-lo. Eu começaria apenas com o aplicativo principal. Isso rapidamente lhe dará uma noção de quão grande é a tarefa. Ou basta contar todas as chamadas de API que você precisará suportar.

Tenho certeza de que você já pensou em tudo isso. Não quero desanimar, mas isso é uma quantidade séria de trabalho que você está propondo, e de forma contínua e brutalmente implacável.

Que tal olhar para o aplicativo oficial e ver o que você pode fazer com ele?

13 curtidas
38

Para ser justo, não acho que isso seria um problema para um aplicativo feito em código nativo, em vez de ser “apenas” uma webview de um site.

3 curtidas
39

Isso é verdade e há muitos exemplos de implementações nativas de aplicativos web por aí. Por exemplo, o Facebook (embora seu aplicativo web seja terrível).

Uma implementação totalmente nativa provavelmente não estaria em risco.

São os aplicativos ‘envolvidos’ que eles mirariam. Editei minha postagem.

3 curtidas
40

Também brinquei com a ideia de desenvolver um aplicativo totalmente nativo (sou desenvolvedor iOS de profissão). Eu o basearia na API HTTP (pública?) do Discourse. Existe alguma garantia sobre a estabilidade da API ou se ela é versionada de alguma forma, para evitar que versões antigas do aplicativo quebrem inesperadamente?

2 curtidas
41

Comunidades que investiram no aplicativo nativo podem seguir nossa branch lenta (também conhecida como “estável”). Além disso, não alteramos as APIs com frequência; elas são muito estáveis.

7 curtidas
42

O aplicativo poderia ser baseado na API REST do Discourse, que deve ser bastante estável. Assim, ele poderia ter qualquer interface/UX que desejar, talvez até diferente da versão web (isso pode ser melhor ou pior). Se o autor do aplicativo escolher qualquer outra abordagem (não tenho certeza se é mesmo possível), ele encontrará a dor que você descreve.

2 curtidas
43

Sim. Ter uma aparência diferente, mas consistente, pode ser visto de forma positiva por algumas pessoas, mas provavelmente apenas se fosse um aplicativo no qual você pudesse adicionar várias instâncias, como o aplicativo oficial. No entanto, isso não é o que muita gente tem interesse. Imagine se o aplicativo personalizado do seu site tivesse um estilo completamente diferente do site. Não seria bom.

E não consigo imaginar que alguém ficaria muito satisfeito com um aplicativo que não suportasse todos os recursos do seu site. Portanto, os plugins começam a se tornar um problema logo de cara.

4 curtidas
44

Concordo, essa pode ser a parte complicada. Um aplicativo nativo pode acabar ficando pior do que o wrapper web se os plugins não forem suportados. Uma primeira abordagem sensata seria dar suporte aos plugins mais populares e, com o tempo, adicionar suporte a mais.

4 curtidas