Gitea: Discussão de atualização da interface do usuário

Eu adoraria ver isso acontecer, já que o Gitea não é muito utilizável em dispositivos móveis, mas seria uma tarefa gigantesca e espero que não impeça todos os desenvolvedores de manter e trabalhar em recursos regulares para o Gitea. :risonho:

Concentrando-me apenas em CSS agora, tenho duas preocupações principais:

1. semantic-ui é um beco sem saída em termos de tecnologia. Ele não adota o flexbox e geralmente acho que está fazendo muito por conta própria. Eu prefiro ter um pouco mais de controle, talvez apenas adicionando algumas classes auxiliares.

2. less provavelmente não é necessário. Acho que o aninhamento do seletor é ruim porque leva a seletores inutilmente longos que são difíceis de pesquisar na origem. Com CSS suportando variáveis, não vejo muita utilidade em ter um pré-processador. Eu sugiro converter para CSS simples.

Abandonar menos a favor de variáveis ​​css nativas significaria abandonar o suporte para alguns navegadores, mas acho que concordaria com isso, já que a maioria das pessoas que usam Gitea são desenvolvedores de qualquer maneira que geralmente usam navegadores atualizados.
Um problema maior para mim seria não conseguir usar coisas como darken($color) e dividir o css em vários arquivos que seriam combinados em um único css (sei que o css nativo também pode fazer isso. .. tipo de)

Um novo design também pode ajudar a deixar mais claro o Gitea é muito diferente do Gogs porque, a partir de agora, ambos compartilham praticamente a mesma interface do usuário.

Em termos de molduras, eu colocaria bulma.io na mistura, pois é algo que usei no passado e achei muito bom. I elimina o incômodo da maioria das coisas, ao mesmo tempo em que permite uma alta custimização e, portanto, uma tematização fácil.

Acho que dar ao Gitea sua própria IU exclusiva é algo que certamente ajudaria a mostrar a diferença entre ele e o Gogs. Ao mesmo tempo, devo dizer que less ou scss é provavelmente algo que deve continuar a existir neste projeto como alguns de seus funcionalidade não está disponível em CSS, no que diz respeito ao framework, não tenho nenhuma opinião que beneficiaria esta discussão, já que eu pessoalmente uso apenas o Bootstrap 4 para meus projetos (não é algo que deveria ser usado aqui)

Bulma parece bom para mim :) pensei que significa reescrever a IU completa, infelizmente

Definitivamente, sou a favor do CSS simples e do uso de padrões como Flexbox e Grid em vez de frameworks. O Grid oferece muitos recursos que os frameworks não-Grid não podem.

@andrewbanchich Bulma é baseado em flexbox

Sim, mas se não for baseado no Grid, então ainda é um framework que está usando algo de uma forma que não foi feita. Primeiro, os frameworks de grade usavam floats para layout, o que era uma solução alternativa, pois os floats não eram feitos para nenhum tipo de layout. Agora eles estão usando o Flexbox para o layout 2D completo, mas o Flexbox destina-se apenas a layouts 1D. O Grid destina-se a layouts 2D e pode fazer coisas que o Flexbox não pode facilmente, então acho que devemos usar apenas o Grid CSS padrão. Na minha opinião, não há mais muita necessidade de uma estrutura de grade.

Bulma é muito leve e dá a você um estilo bastante bonito fora da caixa, não acho que temos um designer que poderia nos fazer um design bonito para gitea aqui

@lafriks Eu realmente gostei do design de @kolaente .

Um problema maior para mim seria não ser capaz de usar coisas como darken($color)

Concordo, certamente preciso deles também e não existe uma solução CSS limpa para ajustes de cores como este. Eu pessoalmente prefiro SCSS a MENOS, mas para uso leve, ambos devem ser quase iguais.

mas se não for baseado em Grid, então ainda é um framework que está usando algo de uma forma que não foi feita para

Grid é certamente uma opção, mas há algum framework adequado baseado nele disponível?

Aqui está um rascunho com o qual brinquei: (escrito em Bulma)

Não estou muito feliz com isso.

@kolaente você pode compartilhá-lo em algum

@lafriks Certo: https://kolaente.dev/konrad/gitea-design

O design feito por @kolaente me lembra um pouco do Gitlab. É ótimo que haja um tópico para discutir um aprimoramento da IU. Pessoalmente, gosto do design do desktop porque fica próximo ao Github. Acho que isso pode ajudar muitos desenvolvedores a começar a usar o serviço.

Às vezes, adiciono problemas por meio do meu telefone. A IU pode ser usada, sim. Mas alguns outros serviços têm uma IU com melhor resposta. Infelizmente, não sou muito bom com CSS.

Talvez o Twitter Bootstrap pudesse ser usado para ser responsivo (você só pode selecionar grade, por exemplo) e os outros componentes como botões têm o layout personalizado.

@incorporado, ele usa Bulma do @jgthms , que também é uma estrutura CSS responsiva.

Aqui está um rascunho com o qual brinquei: (escrito em Bulma)

Eu gosto do design do GitHub (tudo no meio) mais do que do GitLab. Acho que é menos perturbador.

Sou novo aqui - comecei com o problema de abertura # 6687 e olhei menos código e perguntei sobre uma solução no sass. Posteriormente, @techknowlogick me apontou esse problema.

GitHub
Eu gosto do design do GitHub, mas ultimamente com muitos novos recursos ele fica lotado. Configuração de status no menu suspenso, novos recursos experimentais na barra lateral. -> Muitos tipos de menu diferentes. A maioria das coisas muda para um menu lateral, como um novo recurso de verificação (também quebra o design em largura). Parece que o Github tem um problema para encaixar tudo no site.

GitLab / Bitbucket
Não apenas o GitLab usa a barra lateral. Muitos serviços mudaram para uma barra lateral, porque são fáceis de localizar e expandir. Cada entrada e subentrada no mesmo elemento. Funciona em dispositivos móveis com tela de até 5k (um pouco perdido) e é fácil de integrar fora do conteúdo principal. A área do cabeçalho começa com as informações deste tópico da página atual.
Se você adicionar um novo recurso ou fornecer um sistema de plug-in, há espaço suficiente para adicionar uma nova entrada de (sub) menu.

Css / vs. sass
Use um compilador :) Css vários de navegador para navegador e ferramentas como um autoprefixer corrige uma série de pequenos problemas sem escrever várias linhas para cada navegador e descartá-lo mais tarde. Também recursos como variáveis ​​de cores de aninhamento e funções como mais escuro / mais claro, rgba ($ color, .8). Com um linter, você pode forçar o uso de cores apenas como variáveis ​​de profundidade máxima de aninhamento. Ajustar variáveis ​​para um novo tema é muito fácil.

Tema Bulma
Parece bom (mantenedor único / sem conta da organização), não bootstrap padrão, material design ou base (zurb-). Só importaria os componentes desejados. A sintaxe Bulma Sass é incomum. Comparado com o bootstrap, mais tamanhos são codificados.

Vou usar o gitea de qualquer maneira, mas gostaria de um tema escuro melhorado (sem patch de stylus) e sem variáveis ​​mais trabalho para ajustar algo e obter todas as páginas. Talvez eu possa ajudar um pouco com as coisas de estilo, é o que quero.

Sobre uma barra lateral ou outras grandes reformulações: acho que o principal apelo para muitos usuários é que a IU do Gitea é muito semelhante ao GitHub. Se mudarmos os fundamentos do layout, como adicionar uma barra lateral, isso prejudicará muito os usuários acomodados ao layout atual e ao GitHub. Não tenho certeza se aceitaria.

Como @silverwind disse: Acho que é muito fácil para os usuários trocar ou usar o Gitea se estiverem familiarizados com o Github porque a interface do usuário é quase a mesma.
Por outro lado (como @ xf- disse): Colocar o menu do lado esquerdo torna mais fácil agrupar configurações ou itens de menu. Além disso, a maioria das telas são largas. Portanto, um menu do lado esquerdo dá acesso permanente a esses itens e não interrompe o conteúdo. Talvez o tópico "onde colocar o menu" precise ser discutido posteriormente se houver mais do que apenas 3-4 itens.

Talvez começando com o uso de variáveis ​​e mixins para obter mais consistência no tema atual.

Por exemplo. Um repo privado com altura lateral de 36 px e um repo ou organização pública de 35 px. Além disso, a organização tem menos margem para o lado esquerdo. Além disso, a largura de ambos os contêineres é diferente. No perfil, a segunda linha de organizações não tem margem para a primeira linha.

Sobre o menu: A maior parte da navegação é OK e intuitiva, mas os Menus na parte superior em configurações / admin são realmente estranhos. Prefiro os menus em uma lista. Muito mais fácil / rápido encontrar a entrada desejada.

Além disso, o font-face é uma bagunça completa. Lato é definido em sematic-ui.css e em index.css. Não me refiro aos interruptores :lang . Eu usaria a fonte Noto - quase todos os idiomas estão disponíveis, monoespaçado e também emojis. (Talvez um pouco offtopic)
https://en.wikipedia.org/wiki/Noto_fonts
https://www.google.com/get/noto/

Isso é verdade. Da minha experiência (estou apenas fazendo um pouco de web design porque sou mais um programador do que um designer): Ferramentas como SASS ou LESS estão tornando o uso de CSS muito fácil. A possibilidade de usar e atualizar o código de variáveis ​​é incrível.

A maioria dos IDEs inclui um compilador SALL / LESS por padrão ou pode ser adicionado como um plug-in para atualizar o arquivo css quando o arquivo de código-fonte é salvo. É verdade que a fonte pode estar fora do assunto aqui. Mas é uma parte da postagem inicial para

Estou abrindo este tíquete para que possamos discutir o futuro da IU do Gitea

Talvez eu possa ajudar um pouco na organização de alguns arquivos ou converter algumas partes para SASS. Do meu ponto de vista (as opiniões podem divergir), existem duas coisas importantes que devem ser atualizadas:

• Layout responsivo ao usar gitea em seu telefone celular (por exemplo, para adicionar problemas enquanto você não consegue usar seu dispositivo normal)
• Melhore a exibição das configurações de administrador (ou configurações pessoais, também) porque existem muitas configurações. Um menu vertical pode ser melhor do que horizontal. Alguns podem ser adicionados dependendo dos recursos planejados ou desejados.

Por exemplo: No Github (se Gitea gosta de ter um design semelhante ao Github) seus itens "normais" são horizontais para código, problemas, wiki, marcos ..

Outras configurações do seu repositório, organização ou conta pessoal são listadas verticalmente. Do meu ponto de vista, esta é uma grande decisão de design. No Gitea ainda não existem tantas configurações. Mas comparado ao github (se o gitea crescer muito) o espaço horizontal não será suficiente ou teremos que mudar para telas 16:10 ou telas de televisão :)

Como você pode ver nas seguintes imagens:

Configurações do Github, conta pessoal:

Configurações do Gitea, administração do sistema:

O que você acha?

Acho que devemos sempre manter menos itens nos menus para lidar com isso. Menos é mais. :)

Algo que tornaria o desenvolvimento de front-ends personalizados super fácil seria a (não fácil) tarefa de criar uma API para servidores Gitea. Dessa forma, o front-end pode ser escrito em qualquer estrutura com a qual as pessoas se sintam confortáveis ​​- Mithril, React, vanilla JS, qualquer que seja.

@NetOperatorWibby Gitea tem uma api, mas não está completa com os recursos agora, consulte https://try.gitea.io/api/swagger

Estou desenvolvendo um tema personalizado semelhante ao bitbucket para gitea.

A biblioteca de IU que o bitbucket usou foi construída sobre o React (Ref: Atlaskit ), então eu

Eu mantive um mapeamento de string para módulo em JS e expus uma função render() para window . Posso chamar a função em cada modelo correspondente a uma página, passando uma string única e algumas variáveis ​​de contexto exigidas pela página como argumentos. Em seguida, a função render() descobre qual componente React deve ser montado na página e o renderiza com essas variáveis ​​como acessórios.

Honestamente, a implementação atual realmente não atende à filosofia dos aplicativos React, mas funciona e, na verdade, é mais simples do que um React SPA "real", porque você não precisa se preocupar com roteadores e estados globais.

@balthild Parece incrível! Portanto, esta é essencialmente uma "camada de tradução" colocada em cima do Gitea que traduz o modelo Gitea para React?

@kolaente Sim. O motivo não é apenas a falta de APIs, mas também a biblioteca de internacionalização. Não há equivalência JS para github.com/Unknwon/i18n , então devo formatar as strings em Go.

@balthild Bom trabalho, você tem um

@NetOperatorWibby https://github.com/balthild/bitcup O projeto está em um estágio inicial. Apenas a página do painel é substituída e tem uma experiência ruim em dispositivos móveis.

Isso não está relacionado, mas seria legal se houvesse um lugar para encontrar temas diferentes. Eu acho que apenas deixar a comunidade saber onde encontrar temas pode levar a alguns novos looks inovadores para o gitea.

Os temas atualmente não são abstraídos o suficiente. Pude ver que estávamos mudando para variáveis ​​CSS nativas para definir as cores do tema, de forma que um tema consistisse apenas em um conjunto de variáveis ​​de cores. Isso também significaria remover o suporte do IE 11.

@silverwind Acho que em janeiro de 2020 podemos remover o suporte ao IE11, de acordo com https://en.wikipedia.org/wiki/Internet_Explorer_11 , quando chegará ao fim do prazo

"Não me dê esperança"

https://support.microsoft.com/en-us/help/17454/lifecycle-faq-internet-explorer

O Internet Explorer 11 será compatível até que o Windows 10 seja EOL

@marcstreeter Não é mais o navegador padrão e não receberá nenhuma atualização além de questões críticas de segurança.

É muito simples: se o IE estiver nos impedindo de distribuir um recurso, seu suporte será encerrado.

Tudo bem - apenas ter certeza de que a decisão não foi baseada em uma data falsa.

As próximas etapas para a modernização JS devem ser:

• Adicionar Webpack - https://github.com/go-gitea/gitea/pull/8440
• Adicionar Minificador - possivelmente https://github.com/go-gitea/gitea/pull/8440
• Adicione o Babel que nos permite escrever JS moderno ao mesmo tempo em que oferece suporte a navegadores mais antigos.
• Obtenha dependências JS de npm onde possível, em vez de vendê-las. Isso tornará a atualização deles uma brisa.

@silverwind Você pode querer considerar o uso de JS moderno em navegadores modernos. Aqui está um artigo sobre isso: https://philipwalton.com/articles/using-native-javascript-modules-in-production-today/

@ mrg0lden Há muito a ser feito, mas fazer todas essas otimizações avançadas pode ser um fardo de manutenção, especialmente em relação às configurações do webpack. Algum tipo de forma de "baterias incluídas" de agrupar código de front-end que não precise de muita configuração seria o ideal.

Se você acabar fazendo isso, use um kit de ferramentas com acessibilidade adequada para seus widgets de estoque e não faça widgets personalizados, a menos que queira torná-los acessíveis.

@silverwind Você já teve a chance de experimentar o parcel ? Seu propósito é ser exatamente isso, um zero-config js bundler, ele já lida com minificação e também tem um servidor dev com HMR .

Trabalho com JS há alguns anos e estou mais do que feliz em ajudar, se necessário.

Eu tentei parcel no passado, mas achei um pouco deficiente em termos de configurabilidade e ecossistema de módulos. Acho que o webpack ainda é o padrão de ouro quando se precisa de flexibilidade, mesmo que sua sintaxe de configuração seja uma droga.

Na verdade, o vue-service-cli torna a configuração do webpack para projetos Vue muito mais fácil

@lafriks Acho que essas ferramentas de SPA pressupõem que o HTML é servido via webpack, o que não é o nosso caso atualmente. Podemos servir apenas index.html via webpack, mas não será fácil.

Vamos fazer passo a passo. Podemos começar de uma página mais simples.

@silverwind não, ele irá gerar index.html, mas você pode facilmente servir isso de golang

Sim, acho que poderíamos tentar mover index.html para webpack eventualmente, para que pudéssemos usar um dos modelos de configuração de webpack existentes. Não precisa ser estritamente o vue porque, da última vez que verifiquei, nosso uso do vue era mínimo, de modo que poderia ser facilmente convertido em outra coisa, se desejarmos.

Acho que Gitea não deveria ser um SPA, mas sim um MPA.

vote para MPA:

• menos recursos necessários do lado do cliente

EDITAR: alguém ainda pode escrever SPA com html + css + js usando os endpoints da API gitea como backend ...

Sim, já investimos muito na renderização do lado do servidor, então acho que uma conversa completa com o SPA está quase certamente fora de questão.

Acho que seria interessante se o Gitea adotasse um layout horizontal, semelhante ao que o Azure Repos usa. Esse layout é muito mais elegante e eficiente imho e usa o espaço da tela de uma forma mais inteligente. Aqui estão algumas capturas de tela para ilustrar o que quero dizer:

como qualquer outra IU faz isso porque também funciona em dispositivos menores e rolar para baixo está OK.
Até mesmo o GitHub começa a usar 100% da tela, por exemplo, novas notificações (ou verificações / alterações de arquivo em um PR)

Eu gosto do estilo atual - mas esta é apenas minha opinião

Nem sempre gosto da exibição em "Arquivos alterados". De vez em quando, recebo solicitações de pull em que 20 arquivos ou mais foram modificados - o que nem sempre é evitável (Migração PHP 5.6 -> 7.3).

O problema é que o navegador precisa de muito tempo para mostrar as mudanças. A página Pull Request carrega rapidamente. Apenas o realce de sintaxe consome muito tempo.

Aqui, uma visão semelhante ao Gitlab é recomendada.

Estou falando sobre uma visualização de solicitação de pull como neste estilo: https://github.com/go-gitea/gitea/issues/5937#issuecomment -584859265