Mudar a front page
jfoclpf opened this issue · comments
Mudar a página principal https://geoapi.pt/ para ficar mais user friendly
- Retirar tabela com os diferentes caminhos (routes), é muita informação que já consta em docs.geoapi.pt
Além de Obter informação de Freguesia adicionar outros tópicos:
Obter informação de Município
| Detalhes sobre município | Freguesias do município |
|---|---|
| [selecione] | [selecione] |
Obter informação de Distrito
| Municípios do distrito | Freguesias do distrito |
|---|---|
| [selecione] | [selecione] |
que te parece @waldyrious ?
gosto das tuas opiniões porque és muito minucioso no UI/UX e queria uma front-page super user friendly que obedecesse a um bom UI/UX
Concordo que se possa remover a tabela de caminhos, e tornar a página principal (e o site como um todo, usado a partir do browser) como uma interface para a API. No entanto, acho que a info sobre o uso da API devia estar mais visível do que apenas na badge "JSON API | Documentation" — afinal, o projeto tem API no nome, e seria estranho não tornar isso evidente logo à partida. Se calhar faria sentido haver um parágrafo introdutório, acima do mapa, e incluir nele um link bem destacado para https://docs.geoapi.pt/.
Também era bom se o mapa na home page não ocupasse tanto espaço... aqueles formulários de uso pela web ("Obter informação de Freguesia", etc.) acabam por ficar escondidos below the fold. Entendo que queiras dar destaque ao mapa, mas ele só expõe parte da funcionalidade (nomeadamente, a navegação por distritos e drill down para municípios, etc.)
Mesmo que não se mexa na posição/tamanho do mapa, acho que devia-se implementar um método para evitar o zoom no mapa quando se faz scroll. Li recentemente que o Mabbox GL 2.6 implementou uma opção chamada cooperativeGestures para ajudar a resolver o problema:
While attempting to scroll a page with a full-width map, end users may get frustrated by their scroll or zoom interactions acting on the map, instead of the web page. Cooperative gesture handling simplifies user interaction between the web page and the map. Developers no longer need to implement custom event handling to get a consistent experience across multiple device types.
When
cooperativeGesturesis enabled, scroll-to-zoom requires using the control or command key while scrolling to zoom the map, and panning on touch devices requires using two fingers to pan the map.
WhencooperativeGesturesis disabled, the user is unable to continue scrolling to contents below a map until moving the cursor, or their finger, off of the map.
Não sei se o Leaflet tem essa funcionalidade out of the box, mas acredito que seja um problema comum e que haja no mínimo soluções partilhadas p.ex. no StackOverflow.
Que te parece agora @waldyrious ?
Mesmo que não se mexa na posição/tamanho do mapa, acho que devia-se implementar um método para evitar o zoom no mapa quando se faz scroll.
boas em relação a isso, implementei algo (1a2d4a2) usando directamente o CSS, fonte, já permite fazer scroll na página, exceto quando o ponteiro está sob um distrito do mapa, experimenta
obrigado pelas dicas @waldyrious
julgo agora estar bem, qq questão adicional diz
Nice work! Alguns comentários:
- Acho que os formulários deviam aparecer pela ordem hierárquica: distrito, município, freguesia, código postal (e eu acrescentaria ainda um formulário para introduzir coordenadas geográficas).
- Nos títulos de cada formulário, as palavras "Distrito", "Município", etc., deviam estar em minúsculas.
- Eu mudaria ligeiramente as labels dos radio buttons:
- "Detalhes sobre município/distrito" → "Detalhes sobre o município/distrito"
- "Freguesias do município" → "Lista de freguesias do município"
- Acho que era melhor haver um botão de submissão em vez da página reagir instantaneamente quando se seleciona uma opção do dropdown.
- O campo "Município" na secção "Obter informação de Freguesia" podia ter uma opção [selecione], como os outros, em vez de ter auto-selecionado "Abrantes". Mas entendo que seja mais fácil a implementação estática.
- Continuo a achar que um parágrafo introdutório por cima do mapa seria fixe.
- Em relação ao scroll, funciona melhor sim :) bom workaround.
obrigado, implementei tudo excepto do botão de submissão, porque acho que fica mais rápido assim, menos clicks; que te parece?
- Continuo a achar que um parágrafo introdutório por cima do mapa seria fixe.
concordo, queres sugerir algo?
implementei tudo
- Em relação aos nomes das entidades, eu sugeri minúsculas, não maiúsculas. Foi uma escolha deliberada usar o segundo, ou apenas troca do que eu propus? Pergunto porque faz-me confusão estar assim em all caps. Se a ideia é destacar, eu antes usaria negrito ou uma cor diferente.
- Já agora, nesses títulos eu acrescentaria "um" → "Obter informação de um municípo", etc.
- Foi deliberado não incluir um formulário para pesquisa de coordenadas geográficas?
- O prefixo "Lista de" que eu sugeri era na ideia de ser usado na secção de distritos também, não apenas na de municípios.
excepto do botão de submissão, porque acho que fica mais rápido assim, menos clicks; que te parece?
Pessoalmente prefiro a interação explícita. Acho que o flow de interação mais intuitivo é escolher primeiro o item da lista que nos interessa, e depois filtrar o tipo de informação que se pretende sobre esse item (lista de sub-entidades ou detalhes da entidade). Aliás, eu até propunha colocar os dropdowns menus à esquerda e os radio buttons à direita, para melhor refletir esse flow.
Para facilitar a interação em menos cliques, e evitar um botão adicional de submissão, podia-se tornar os radio buttons em links ou botões; assim seria expectável que ao clicar neles iríamos para uma página nova.
concordo, queres sugerir algo?
Porque não o que já está no início do README? Escusamos de duplicar trabalho :)
foste rápido a responder :)
ainda não tinha colocado em produção, tinha alterado apenas o código, agora já está em produção e muitas das questões que mencionaste já estão implementadas, por favor verifica: https://geoapi.pt/
Para facilitar a interação em menos cliques, e evitar um botão adicional de submissão, podia-se tornar os radio buttons em links ou botões; assim seria expectável que ao clicar neles iríamos para uma página nova.
bem visto essa de substituir os radio buttons por simples botões, fica de facto mais intuitivo e resolve o problema de excesso de cliques, vou implementar
Porque não o que já está no início do README? Escusamos de duplicar trabalho :)
referes-te exatamente a que passagem? O principal já está no cabeçalho da página
Foi deliberado não incluir um formulário para pesquisa de coordenadas geográficas?
foi mesmo falta de tempo :) mas achas que vale mesmo a pena, i.e., quem é que insere coordenadas à mão?
muito obrigado por todo o feedback
que te parece este nesting com dropdown e botões do bootstrap?
https://getbootstrap.com/docs/4.0/components/button-group/#nesting
fiz um codepen como exemplo, que te parece?
https://codepen.io/jfoclpf/pen/eYQEWbZ
referes-te exatamente a que passagem? O principal já está no cabeçalho da página
No cabeçalho está o que eu considero uma tagline, dá uma ideia breve do que se trata mas não chamaria de descrição:
Dados gratuitos e abertos para Portugal sobre regiões administrativas oficiais, georreferenciação, censos e códigos postais
Em contrapartida, o README menciona explicitamente (embora não esteja num bloco único copy-pastable, agora que vi com mais atenção) que se trata de uma RESTful API, que o uso é gratuito pelo endpoint público em https://geoapi.pt (com um limite por IP de 1 pedido por segundo), e que a documentação da API está em docs.geoapi.pt. Acho que seria importante estes pormenores estarem indicados logo na homepage. Ah, e também mencionar que é open source, com link para GitHub, e talvez até fazer menção ao formato de resposta (HTML/JSON) como pretexto para linkar para o HATEOAS 😄. É demasiado detalhe para uma tagline, daí ter sugerido um parágrafo introdutório. O que te parece?
achas que vale mesmo a pena, i.e., quem é que insere coordenadas à mão?
A meu ver é uma questão mais de expor a funcionalidade disponível, caso contrário é um pouco menos discoverable. Penso que contribui para uma primeira impressão mais completa sobre as potencialidades e valor do projeto, mesmo que não seja muito usado. (Mas olha que ainda no outro dia eu precisei usar isso, tinha uma localização geográfica e quis saber qual era o código postal associado.)
que te parece este nesting com dropdown e botões do bootstrap?
getbootstrap.com/docs/4.0/components/button-group/#nesting
fiz um codepen como exemplo, que te parece?
codepen.io/jfoclpf/pen/eYQEWbZ
Tá fixe :) mas eu não colocaria os botões colados aos dropdowns. Se calhar punha-os numa linha em baixo dos dropdowns. Aliás, eu estava aqui a pensar se não seria melhor ter o layout de cada secção na vertical, em vez de ter os radio buttons / botões no lado direito. Ou seja, ficaria título em cima, dropdown(s) no meio (uns em cima dos outros se houver mais que um, como no caso das freguesias) e botões em baixo. Assim, cada secção não teria de ocupar 100% da largura num desktop; podiam ficar 2 ou 3 lado-a-lado, e assim ficaria mais funcionalidade da API exposta sem ter de se fazer tanto scroll. Só em ecrãs mais pequenos é que as secções ficariam com 100% da largura, e empilhadas verticalmente — como aliás já acontece no design que está deployed agora. Ou seja, estou a pensar num design tipo "cards", como aqui. O que achas?
Em contrapartida, o README menciona explicitamente (embora não esteja num bloco único copy-pastable, agora que vi com mais atenção) que se trata de uma RESTful API, que o uso é gratuito pelo endpoint público em https://geoapi.pt (com um limite por IP de 1 pedido por segundo), e que a documentação da API está em docs.geoapi.pt. Acho que seria importante estes pormenores estarem indicados logo na homepage. Ah, e também mencionar que é open source, com link para GitHub, e talvez até fazer menção ao formato de resposta (HTML/JSON) como pretexto para linkar para o HATEOAS 😄. É demasiado detalhe para uma tagline, daí ter sugerido um parágrafo introdutório. O que te parece?
parece-me bem, vou implementar
A meu ver é uma questão mais de expor a funcionalidade disponível, caso contrário é um pouco menos discoverable. Penso que contribui para uma primeira impressão mais completa sobre as potencialidades e valor do projeto, mesmo que não seja muito usado. (Mas olha que ainda no outro dia eu precisei usar isso, tinha uma localização geográfica e quis saber qual era o código postal associado.)
concordo, vou implementar
Tá fixe :) mas eu não colocaria os botões colados aos dropdowns. Se calhar punha-os numa linha em baixo dos dropdowns. Aliás, eu estava aqui a pensar se não seria melhor ter o layout de cada secção na vertical, em vez de ter os radio buttons / botões no lado direito. Ou seja, ficaria título em cima, dropdown(s) no meio (uns em cima dos outros se houver mais que um, como no caso das freguesias) e botões em baixo. Assim, cada secção não teria de ocupar 100% da largura num desktop; podiam ficar 2 ou 3 lado-a-lado, e assim ficaria mais funcionalidade da API exposta sem ter de se fazer tanto scroll. Só em ecrãs mais pequenos é que as secções ficariam com 100% da largura, e empilhadas verticalmente — como aliás já acontece no design que está deployed agora. Ou seja, estou a pensar num design tipo "cards", como aqui. O que achas?
precisamos mesmo de estabelecer isto no codepen antes de avançarmos, porque dá imenso trabalhar mudar o código CSS, html, JS diretamente no projeto
fiz umas alterações como recomendaste (boa ideia BTW ;), que te parece agora?
https://codepen.io/jfoclpf/pen/eYQEWbZ
Nice :) Eu ainda assim poria um espaço entre os selectores (input boxes e select dropdowns) e os botões. Ou seja, acho o layout da esquerda mais perceptível que o da direita na imagem abaixo:
Também acho que os selects ficavam melhor com o estilo cinzento/branco como está nos forms de código postal e coordenadas GPS. Again, à esquerda o que acho que fica melhor, e à direita o output atual do CodePen:
(Nota: estas imagens foram feitas com um mix de browser inspector e GIMP, por isso infelizmente não tenho HTML/CSS para te passar que implemente isso 😅)
obrigado pelo retorno
que te parece agora?
https://codepen.io/jfoclpf/pen/eYQEWbZ
Estive a ver os docs do Bootstrap, talvez se pudesse usar o custom select para os dropdowns?
Estive a ver os docs do Bootstrap, talvez se pudesse usar o custom select para os dropdowns?
com que vantagem? acho os outros mais bonitos
Estive a ver os docs do Bootstrap, talvez se pudesse usar o custom select para os dropdowns?
o que eu quero dizer é que os custom select não dão para os colocar em pilha vertical, servem para adicionar campos ao lado
Estive a ver os docs do Bootstrap, talvez se pudesse usar o custom select para os dropdowns?
já percebi a que te referes, ora vê se concordas, usei os custom-select como recomendaste
https://codepen.io/jfoclpf/pen/eYQEWbZ
É isso! Tá excelente :) Eu só ajustaria os labels dos botões para não serem tão extensos. Já que cada secção/card vai ter um título tipo "Obter informação de um município", etc. (certo?), podíamos remover a parte final dos labels dos botões. Por exemplo, para os municípios os botões diriam apenas:
- Detalhes
- Lista de freguesias
Se calhar podemos pensar numa alternativa para "Detalhes", até para distinguir dos caminhos .../detalhes que já existem na API, onde a palavra tem um significado diferente. Que tal "Dados gerais"?
Como é que sugeres que devemos colocar os títulos em cada secção/card?
De resto, já está:
https://codepen.io/jfoclpf/pen/eYQEWbZ
@waldyrious já pus os títulos, como sugeriste, que te parece?
https://codepen.io/jfoclpf/pen/eYQEWbZ
Tá muito bom! Por mim já se pode avançar assim 😃
que te parece @waldyrious ?
https://geoapi.pt/
alguma coisa a acrescentar ou alterar no teu entender?
Ficou excelente! 👏
Eu quando estiver no computador tento fazer um PR com alguns ajustes mínimos. Se não der ainda este fim de semana, tentarei no próximo :)
Assim rapidamente, só para confirmar: sabes se dá para combinar os dois campos do formulário de GPS para não ficarem com os cantos arredondados na linha que os une? Nas versões iniciais do codepen estavas a usar um modo de stacking que fazia isso.
Assim rapidamente, só para confirmar: sabes se dá para combinar os dois campos do formulário de GPS para não ficarem com os cantos arredondados na linha que os une? Nas versões iniciais do codepen estavas a usar um modo de stacking que fazia isso.
sim, dá, nem que tenha que fazer ajustes CSS à mão. Vou implementar.
Ficou excelente! 👏
Eu quando estiver no computador tento fazer um PR com alguns ajustes mínimos. Se não der ainda este fim de semana, tentarei no próximo :)
sim sff, faz uns PRs, para que fique registado que também participas no projecto :)
sabes se dá para combinar os dois campos do formulário de GPS para não ficarem com os cantos arredondados na linha que os une?
já está, diz o que achas
Tá quase, mas ainda precisa de pequenos ajustes 😄 Deixa o issue aberto pf, eu faço um PR em breve com as minhas sugestões.
sure :)
eu faço um PR em breve com as minhas sugestões.
fico à espera :)
@waldyrious para não andares à procura dos ficheiros quando quiseres fazer PR :)
Com relação à front-page
- CSS: https://github.com/jfoclpf/geoapi.pt/blob/main/src/public/src/css/main.css#L196
- distrito HTML block: https://github.com/jfoclpf/geoapi.pt/blob/main/src/views/partials/districtQuery.hbs
- município HTML block: https://github.com/jfoclpf/geoapi.pt/blob/main/src/views/partials/municipalityQuery.hbs
- freguesia HTML block: https://github.com/jfoclpf/geoapi.pt/blob/main/src/views/partials/parishQuery.hbs
- código postal HTML block: https://github.com/jfoclpf/geoapi.pt/blob/main/src/views/partials/cpQuery.hbs
- coord. gps HTML block: https://github.com/jfoclpf/geoapi.pt/blob/main/src/views/partials/localeQuery.hbs
qualquer dúvida diz
Obrigado @waldyrious
muito obrigado @waldyrious pelos PRs
já está em produção
mais uma vez muito obrigado @waldyrious pelos teus últimos PRs
Já estão em produção