in-my-district
in-my-district copied to clipboard
jfoclpf
Gestão das ocorrências, como e quem as marca como resolvidas
Boas.
Como é que os municípios alteram o estado de uma reclamação, quando a situação está resolvida?
Obrigado.
Tenho pensado nisso, mas contrariamente às outras APPs gosto que isso fique do lado do munícipe, ou seja, da pessoa que reporta. Neste momento apenas quem reportou pode dar a situação como resolvida.
Mas tenho pensado num sistema em que o município declara como resolvido e tal pede a confirmação ao munícipe, mas tal exige um serviço de email que ainda não está funcional.
Mas ficará o quanto antes. Está na todo list.
Tenho pensado nisso, mas contrariamente às outras APPs gosto que isso fique do lado do munícipe, ou seja, da pessoa que reporta. Neste momento apenas quem reportou pode dar a situação como resolvida.
Mas tenho pensado num sistema em que o município declara como resolvido e tal pede a confirmação ao munícipe, mas tal exige um serviço de email que ainda não está funcional.
Mas ficará o quanto antes. Está na todo list.
Boa iniciativa!
Sugestão: Penso que seja importante cada entidade (Municipio ou Junta de Freguesia) se conseguir associar a determinada área/território. A partir daí, poderia receber, por email, como sugerido, todas as novas ocorrências. Nesse email, poderia ter um link para a marcar como resolvida.
@bastiao isso é possível, a questão é saber se deverá ser o município a dar a ocorrência como resolvida, ou deve ser o cidadão que reporta a ocorrência.
Na minha opinião, deve ser possível para ambos. Assim, conseguem ter um serviço mais comunitário a funcionar, e contribuições dos municípios ou freguesias aderentes à plataforma. O ideal seria existir uma norma de software para fazer a gestão de ocorrências e garantir a interoperacionalidade. Na verdade, acho que estás ocorrências são ainda geridas de forma ad-hoc.
uma dica seria a separação do backend e uma api que o municipio possa se comunicar para marcar como resolverido.
@enieber o backend já existe e está correr bem numa máquina Linux https://github.com/jfoclpf/in-my-district/tree/main/server é este backend que regista as ocorrências e que as coloca num mapa para todos verem https://nomeubairro.app/mapa/
O que é preciso é um serviço de email e não tenho tido tempo para implementá-lo e nem sei se deva instalá-lo eu na máquina backend ou delegar para outros servidores, o que acarretaria um custo adicional, que não é comportável com um serviço gratuito, sem publicidade e open source.
@bastiao bem visto, na realidade imaginava simplesmente a freguesia ou município simplesmente receber uma notificação por email e dá-la como resolvida com um link
Caros, após 2 dias de volta disto, o servidor de email local já está funcional, agora precisamos de decidir que modelo queremos adotar.
Fiz este fluxograma e gostaria de saber a vossa opinião @bastiao @enieber @RobinSapo @worm69 @waldyrious
Alguns pontos:
- No email gerado que o município e/ou freguesia recebem vai um link para marcarem a ocorrência como resolvida
- O cidadão marca a ocorrência como resolvida apenas na APP (Menu->Histórico)
Que vos parece?
@jfoclpf acho que ficou bem simples o desenho e resolveria bem o problema..
Olá! Sim, concordo com o fluxograma e a perspetiva de "o cidadao é que confirma", visto que muitos municipios marcam coisas como resolvidas por causa das métricas. Contudo, penso que se poderia refletir nas situações em que: i) Várias pessoas reportaram a mesma questão e poderão ter visões diferentes sobre o que é "resolvido" ii) Tentativas individuais de trolling, em que individuos nunca deixam que a coisa assuma o status de resolvido.
Penso que para estas poderia ser interessante pensar nalgum sistema de arbitragem. Faz-me pensar até nos mecanismos de fact-checking, em que não há verdades absolutas.
Olá! Sim, concordo com o fluxograma e a perspetiva de "o cidadao é que confirma", visto que muitos municipios marcam coisas como resolvidas por causa das métricas. Contudo, penso que se poderia refletir nas situações em que: i) Várias pessoas reportaram a mesma questão e poderão ter visões diferentes sobre o que é "resolvido" ii) Tentativas individuais de trolling, em que individuos nunca deixam que a coisa assuma o status de resolvido.
Penso que para estas poderia ser interessante pensar nalgum sistema de arbitragem. Faz-me pensar até nos mecanismos de fact-checking, em que não há verdades absolutas.
Boa visao critica @luisjfvieira. Sobre teu primeiro ponto sugiro que se faça uma comparação simples de cada nova submissão com as existentes comparando se estão relativamente perto e o titulo. Um pouco parecido com o que o stackoverflow faz para as novas questões. Sobre o segundo ponto podemos guardar quantas vezes a mesma submissão fez esse loop e por exemplo a terceira vez disparar um alerta para que um admin possa tentar validar melhor.
Acho que faz sentido que seja o cidadão que reportou o problema a ter a palavra final sobre a resolução. Mas há três casos em que a confirmação pode não acontecer:
- O cidadão discorda da resolução
- O cidadão não tem a oportunidade de confirmar (esqueceu-se do login, trocou de email, usou um email incorreto, o email da plataforma vai para o spam, o cidadão não dá importância à necessidade da confirmação, desde que o problema tenha ficado resolvido, etc.)
- O cidadão deliberadamente não confirma por intenção maliciosa (trolling, vingança pelo atraso, whatever)
Sem estar a montar um sistema de intermediação/arbitragem, acho que a solução mais simples é expor precisamente a informação que existe de forma transparente e explícita, isto é, o estado das duas confirmações: a do município/freguesia, e a do cidadão.
A UX disto não tem que ser complexa: veja-se por exemplo os double-checks (✔️✔️) que vários sistemas de IM, como o WhatsApp, usam para indicar que uma mensagem foi enviada, recebida, ou lida.
Outro exemplo que podia ser útil aqui é a UI do sistema de revisão de sugestões de edição do StackOverflow, que permite ver as avaliações individuais, e até sua justificação. Por exemplo, nesta edit, pode-se ver como os três reviewers votaram, e até as estatísticas dos intervenientes, o que ajuda a interpretar o estado final/agregado:
Claro, isto parece confuso visto tudo de uma vez, mas no nosso caso só há dois intervenientes em vez de 4, pelo que a informação pode ser mostrada de forma mais compacta; e de notar que a segunda caixa, com as estatísticas, só é exibida quando se clica no botão "reviewer stats" da primeira caixa, ou seja, é usado o padrão de progressive disclosure que torna a informação mais fácil de consumir, o que certamente deveríamos usar também.
Acho que algo deste género (mais simplificado, claro) seria definitivamente preferível a estar a montar um sistema de arbitragem/mediação.
Caros, muito obrigados pelo retorno e pelos comentários
1) Evitar que várias pessoas submetam a mesma ocorrência
Para isso sugiro colocar no mapa do formulário de submissão de ocorrência, as ocorrências que já existem e que estão por resolver. O mapa do formulário mostra sempre a zona onde o utilizador se encontra e por isso verá as ocorrências existentes nas redondezas. O utilizador poderá vê-las e clicar num botão "Também quero reportar esta ocorrência", adicionando fotos se quiser. Que te parece @luisjfvieira e @worm69 ?
Neste caso precisaria de adicionar um campo à tabela da BD, para contemplar utilizadores adicionais para a mesma ocorrência.
2) Tentativa de trolling, utilizador que desaparece, etc.
@luisjfvieira exigir trabalho de moderadores não é solução a longo prazo, o sistema precisa de ser o mais autónomo quanto possível. No futuro, como sugere o @worm69 podemos implementar algoritmos para detectar trolling e abusos, mas para já não é prioritário nesta fase. Sugiro implementar a sugestão do @waldyrious , ou seja, em cada ocorrência saber se o município, freguesia e cidadão, cada um deles, colocaram o item como resolvido.
A ocorrência apenas estaria completamente resolvida quando o cidadão marcasse como resolvida, ou quando, se não respondesse, tivesse decorrido 15 dias desde a data em que o município marca como resolvido. Que te parece @waldyrious ?
A ocorrência apenas estaria completamente resolvida quando o cidadão marcasse como resolvida, ou quando, se não respondesse, tivesse decorrido 15 dias desde a data em que o município marca como resolvido. Que te parece @waldyrious ?
Honestamente, não me agrada muito que a resolução fique confirmada simplesmente por não resposta do cidadão, o que pode acontecer por várias causas, mas entendo que seja a solução mais simples. Eu só insistiria em dois pontos:
- Deve ficar explícito que o cidadão não confirmou e que a situação considera-se resolvida apenas por omissão (por exemplo, com iconografia de double checks :heavy_check_mark::heavy_check_mark: como eu sugeri acima, ou algo semelhante);
- Devia ser possível ao cidadão responder mesmo depois dos 15 dias passados, o que mudaria o estado da ocorrência novamente para "não resolvida".
Olá @waldyrious
- Sim, isso ficará claro na ocorrência com esses checks
- Sim, o cidadão poderá sempre marcar a ocorrência como não resolvida, na APP
Adicionar campos à tabela da base de dados SQL, para poder contemplar estas novas funcionalidades.
Neste momento a tabela tem estes campos
Precisamos de adicionar os seguintes campos
- nome_op (nome do original poster)
- email_op (email do original poster)
-
utilizadores_adicionais (text string, JSON array com users adicionais
{nome, email, device_uuid}, que referem que tal ocorrência também lhes diz respeito) - ocorrencia_resolvida_por_op (boolean)
- ocorrencia_resolvida_por_municipio (boolean)
- ocorrencia_resolvida_por_freguesia (boolean)
-
ocorrencia_resolvida_por_utilizadores_adicionais (text string, JSON array com users adicionais
{nome, email, device_uuid}, que referem que tal ocorrência está resolvida)
Estive 3 noites a programar :)
Neste momento o email gerado já gera dois URLs, um para o município dar a ocorrência como resolvida e o outro para a freguesia dar a ocorrência como resolvida. Falta apenas notificar o OP com o email.
Agora a ocorrência fica assim: https://nomeubairro.app/ocorrencia/?uuid=35a01022-3568-48ad-8041-e1b7d98a26b3
Que vos parece?
Promissor! Mas gostava de ver como ficaria com um estado intermédio, por exemplo o município a dar como resolvida e o cidadão não. O campo "Ocorrência resolvida" passaria de "Não" para "Sim", ou outro valor?
Além disso, acho que seria bom apenas mostrar o campo relevante para a entidade que recebe a ocorrência, assumindo que apenas a freguesia ou apenas o município recebe a comunicação; se esta assunção estiver errada, faz sentido ficar como está, naturalmente.
Finalmente, tenho uma sugestão para simplificar a leitura dos dados, marcando os três estados como sub-estados do principal. Por exemplo, algo deste género:
Isso pode-se implementar apenas modificando o HTML e CSS da seguinte forma:
<details><summary><b>Ocorrência resolvida</b>: Não</summary>
<b>Declarada como resolvida pelo cidadão que reportou</b>: Não<br>
<b>Declarada como resolvida pelo município</b>: Não<br>
<b>Declarada como resolvida pela freguesia</b>: Não<br>
</details>
details summary ~ b { padding-left: 2em; }
details { margin-bottom: 1em; }
WDYT?
Olá @waldyrious , obrigado pelos comentários
Neste momento já tenho o servidor de email a funcionar mas não está implementado no código ainda, por isso neste momento a ocorrência está resolvida apenas quando o OP a marca como resolvida. Depois seguirá o fluxograma já posto ali em cima:
Sugeres modificações a este fluxograma? @worm69 este fluxograma parece-te bem?
Muito obrigado pelas tuas sugestões em relação aos detalhes, já foi feito com 6e5638ac8b0b6c9ef0b0ddf30551d55bc62c275b ora vê: https://nomeubairro.app/ocorrencia/?uuid=35a01022-3568-48ad-8041-e1b7d98a26b3
@worm69 @luisjfvieira @enieber @bastiao @RobinSapo
concordam com este fluxograma? Sugerem alguma alteração?
Desculpa, realmente isso já tinha sido discutido e acordado acima. Não tenho nada a apontar sobre o fluxograma, a não ser talvez acrescentar um asterisco no "Sim" quando a ocorrência é resolvida por não resposta do cidadão.
Quanto ao uso do elemento <details>, obrigado pela rápida implementação :)
@worm69 @luisjfvieira @enieber @bastiao @RobinSapo
concordam com este fluxograma? Sugerem alguma alteração?
Acho que está muito bom!
Eu vejo algumas vantagens no município ou freguesia receber também uma notificação/e-mail, caso o cidadão marque a ocorrência como resolvida. Por exemplo, no caso da Freguesia ela muitas das vezes funciona de 'broker' entre organizações responsáveis. Recebe reclamação e reporta a outra entidade (sem grande seguimento posterior, infelizmente). Uma desvantagem disso é que com larga utilização isso pode ser interpretado como 'spam' pelos operacionais (responsáveis das Freguesias). Deixo à vossa consideração.
boas @bastiao se reparares bem no fluxograma, quando o cidadão declara a ocorrência como resolvida, o município e/ou freguesia são alertados por email
boas @bastiao
se reparares bem no fluxograma, quando o cidadão declara a ocorrência como resolvida, o município e/ou freguesia são alertados por email
Eu sei, apenas levantei algumas vantagens e desvantagens :) Por exemplo, eu não sei se a possibilidade de receber um e-mail semanal com dados agregados não seria mais vantajoso no caso das Freguesias (recursos mais limitados e menos tempo para análises caso a caso). No entanto, acho que está muito bom, e podes ir tendo feedback com a utilização.
@bastiao e @waldyrious que vos parece para já termos também URLs com listas de ocorrências para cada freguesia ou município?
Por exemplo, a ligação https://nomeubairro.app/freguesia/Santa Maria Maior (Lisboa) dar uma lista de todas as ocorrências dessa freguesia
@jfoclpf Acho excelente! Também seria ótimo se se pudesse filtrar o mapa de anomalia por distrito, município e freguesia (semelhante ao que se pode fazer, por exemplo, no mapa de resultados das eleições). No entanto, esta funcionalidade deveria ser tratada num issue à parte, para não poluir esta thread. Se gostares da ideia, eu abro o issue com algumas sugestões para essa funcionalidade :)
Um pequeno issue: ao navegar para https://nomeubairro.app/freguesia/Santa%20Maria%20Maior%20(Lisboa), sou redirecionado para https://nomeubairro.app/freguesia/Santa%20Maria%20Maior%20(Lisboa (sem o parêntese no fim) e isso dá um 404. Podes verificar o que se passa?
@waldyrious gosto dessa ideia dos mapas filtrados por municipios e freguesias, sim, por favor abre um novo issue.
Dá página não encontrada porque o caminho /freguesia ainda não está implementado, queria apenas saber qual a vossa opinião a propósito. Estava a pensar colocar uma lista de todas as ocorrências associadas à freguesia específica.
@waldyrious gosto dessa ideia dos mapas filtrados por municipios e freguesias, sim, por favor abre um novo issue.
Dá página não encontrada porque o caminho /freguesia ainda não está implementado, queria apenas saber qual a vossa opinião a propósito. Estava a pensar colocar uma lista de todas as ocorrências associadas à freguesia específica.
Parece excelente ideia!
gosto dessa ideia dos mapas filtrados por municipios e freguesias, sim, por favor abre um novo issue.
Will do!
Dá página não encontrada porque o caminho /freguesia ainda não está implementado
Ah! Sorry, realmente li mal. Mas ainda assim, acho estranho o redirect a remover o ) no final do link. Não seria expectável o próprio URL https://nomeubairro.app/freguesia/Santa%20Maria%20Maior%20(Lisboa) dar um 404?
Estava a pensar colocar uma lista de todas as ocorrências associadas à freguesia específica.
SGTM!
Tens razão @waldyrious , de facto é estranho o redirect remover o ) no final, mas eu vejo isso melhor quando implementar os caminhos.
Na realidade como o Wordpress usa PHP e tem uma estrutura menos flexível para os caminhos, terei de ter um caminho único /ocorrencias (no plural) e depois filtrar com "query parameters", por exemplo /ocorrências?freguesia=Santa%20Maria%20Maior&municipio=Lisboa ou /ocorrências?municipio=Évora.
Que te parece @waldyrious ?
parece-vos bem @waldyrious e @bastiao ? https://nomeubairro.app/ocorrencias https://nomeubairro.app/ocorrencias/?municipio=Lisboa&freguesia=Lumiar