Gitea: Discussion sur la mise à jour de l'interface utilisateur

J'adorerais que cela se produise car Gitea n'est pas très utilisable sur les appareils mobiles, mais ce serait une entreprise énorme et qui, j'espère, n'empêchera pas tous les développeurs de maintenir et de travailler sur des fonctionnalités régulières pour Gitea. :souriant:

En me concentrant uniquement sur CSS maintenant, j'ai deux préoccupations principales :

1. semantic-ui est une impasse technologique. Il n'embrasse pas flexbox et je pense généralement qu'il fait beaucoup trop tout seul. Je préférerais avoir un peu plus de contrôle, peut-être simplement en ajoutant des classes d'aide.

2. less n'est probablement pas nécessaire. Je pense que l'imbrication des sélecteurs est une mauvaise chose car elle conduit à des sélecteurs inutilement longs et difficiles à rechercher dans la source. Avec CSS prenant en charge les variables, je ne vois pas vraiment l'utilité d'avoir un préprocesseur. Je suggérerais de convertir en CSS simple.

Abandonner moins en faveur des variables CSS natives signifierait abandonner la prise en charge de certains navigateurs, mais je suppose que je serais d'accord avec cela car la plupart des personnes utilisant Gitea sont de toute façon des développeurs qui utilisent généralement des navigateurs à jour.
Un plus gros problème pour moi serait de ne pas pouvoir utiliser des choses comme darken($color) et de pouvoir diviser le css en plusieurs fichiers qui seraient ensuite combinés en un seul css (je sais que le css natif peut le faire aussi. .. type de)

Un nouveau design pourrait également aider à rendre plus clair que Gitea est très différent de Gogs car pour l'instant, les deux partagent à peu près la même interface utilisateur.

En ce qui concerne le cadre, je mettrais bulma.io dans le mélange car c'est quelque chose que j'ai utilisé dans le passé et que j'ai trouvé assez bon. Je simplifie la plupart des choses tout en permettant une personnalisation élevée et donc une thématisation facile.

Je pense que donner à Gitea sa propre interface utilisateur unique est quelque chose qui aiderait certainement à montrer la différence entre elle et Gogs. En même temps, je dois dire que less ou scss est probablement quelque chose qui devrait continuer à exister dans ce projet comme certains de leurs la fonctionnalité n'est pas disponible dans CSS, en ce qui concerne le framework, je n'ai aucune opinion qui profiterait à cette discussion puisque personnellement, j'utilise simplement Bootstrap 4 pour mes projets (pas quelque chose qui devrait être utilisé ici)

Bulma me semble bien :) je pensais que cela signifiait une réécriture complète de l'interface utilisateur, malheureusement

Je suis définitivement en faveur du CSS simple et de l'utilisation de normes telles que Flexbox et Grid par rapport aux frameworks. Grid fournit de nombreuses fonctionnalités que les frameworks non-Grid ne peuvent pas.

@andrewbanchich Bulma est basé sur flexbox

Oui, mais s'il n'est pas basé sur Grid, il s'agit toujours d'un framework qui utilise quelque chose d'une manière pour laquelle il n'était pas destiné. Premièrement, les cadres de grille utilisaient des flotteurs pour la mise en page, ce qui était une solution de contournement car les flotteurs n'étaient destinés à aucun type de mise en page. Maintenant, ils utilisent Flexbox pour la mise en page 2D complète, mais Flexbox n'est destiné qu'aux mises en page 1D. Grid est destiné aux mises en page 2D, et il peut faire des choses que Flexbox ne peut pas très facilement, donc je pense que nous devrions simplement utiliser la grille CSS standard. À mon avis, il n'y a plus beaucoup besoin d'un cadre de grille.

Bulma est très léger et vous donne un style assez joli hors de la boîte, je ne pense pas que nous ayons un designer qui pourrait nous faire un joli design pour gitea ici

@lafriks J'ai beaucoup aimé le design de

Un plus gros problème pour moi serait de ne pas pouvoir utiliser des choses comme darken($color)

D'accord, j'en ai certainement besoin aussi et il n'y a pas de solution CSS propre pour des ajustements de couleur comme celui-ci. Personnellement, je préfère SCSS à LESS, mais pour une utilisation légère, les deux devraient être à peu près égaux.

mais s'il n'est pas basé sur Grid, il s'agit toujours d'un framework qui utilise quelque chose d'une manière pour laquelle il n'était pas destiné

La grille est certainement une option, mais existe-t-il des frameworks appropriés basés sur celle-ci ?

Voici un brouillon avec lequel j'ai joué : (écrit en Bulma)

Je n'en suis pas très content.

@kolaente pouvez-vous le partager dans un

@lafriks Bien sûr : https://kolaente.dev/konrad/gitea-design

Le design réalisé par @kolaente me rappelle un peu Gitlab. C'est formidable qu'il y ait un sujet pour discuter d'une amélioration de l'interface utilisateur. Personnellement, j'aime le design du bureau car il est proche de Github. Je suppose que cela peut aider de nombreux développeurs à démarrer avec le service.

Parfois, j'ajoute des problèmes via mon téléphone. L'interface utilisateur peut être utilisée, oui. Mais certains autres services ont une interface utilisateur plus réactive. Malheureusement, je ne suis pas très bon avec CSS.

Peut-être que Twitter Bootstrap pourrait être utilisé pour être réactif (vous ne pouvez sélectionner que la grille par exemple) et les autres composants tels que les boutons ont la disposition personnalisée.

@mbedded, il utilise Bulma de @jgthms , qui est également un framework CSS réactif.

Voici un brouillon avec lequel j'ai joué : (écrit en Bulma)

J'aime le design de GitHub (tout au milieu) plus que celui de GitLab. Je trouve ça moins gênant.

Je suis nouveau ici - cela a commencé avec l'ouverture du problème # 6687 et a regardé moins de code et a demandé une solution dans sass. Ensuite, @techknowlogick m'a signalé ce problème.

GitHub
J'aime la conception de GitHub, mais dernièrement, avec de nombreuses nouvelles fonctionnalités, il y a beaucoup de monde. Paramètre d'état dans la liste déroulante, nouvelles fonctionnalités expérimentales dans la barre latérale. -> De nombreux types de menus différents. La plupart des éléments se déplacent vers un menu latéral comme la nouvelle fonctionnalité de vérification (interrompt également la conception en largeur). On dirait que Github a un problème pour tout faire rentrer dans le site Web.

GitLab/Bitbucket
Non seulement GitLab utilise la barre latérale. De nombreux services sont passés à une barre latérale, car elle est facile à trouver et à développer. Chaque entrée et sous-entrée sur le même élément. Il fonctionne sur un écran mobile jusqu'à 5k (un peu perdu) et facile à intégrer en dehors du contenu principal. La zone d'en-tête commence par les informations de ce sujet de page en cours.
Si vous ajoutez une nouvelle fonctionnalité ou fournissez un système de plugin, il y a suffisamment d'espace pour ajouter une nouvelle entrée de (sous-)menu.

CSS/ vs sass
Utilisez un compilateur :) Css divers d'un navigateur à l'autre et des outils comme un préfixe automatique résolvent de nombreux petits problèmes sans écrire plusieurs lignes pour chaque navigateur et les supprimer plus tard. Des fonctionnalités telles que l'imbrication de variables de couleur et des fonctions telles que plus foncé/plus clair, rgba($color, .8). Avec un linter, vous pouvez imposer de n'utiliser que les couleurs comme variables de profondeur d'imbrication maximale. Ajuster les variables pour un nouveau thème est vraiment facile.

thème Bulma
Semble bien (mainteneur unique/pas de compte d'organisation), pas de bootstrap standard, de conception matérielle ou de fondation (zurb). N'importerait que les composants souhaités. La syntaxe Bulma sass est rare. Par rapport à bootstrap, plus de tailles sont codées en dur.

J'utiliserai gitea de toute façon, mais j'aimerais un thème sombre amélioré (pas de patch de stylet) et sans variables, plus de travail pour ajuster quelque chose et obtenir chaque page. Peut-être que je peux aider un peu avec des trucs de style, c'est voulu.

À propos d'une barre latérale ou d'autres refontes majeures : je pense que l'un des principaux attraits pour de nombreux utilisateurs est que l'interface utilisateur de Gitea est si similaire à GitHub. Si nous modifions les principes fondamentaux de la mise en page, comme l'ajout d'une barre latérale, cela perturbera beaucoup les utilisateurs adaptés à la mise en page actuelle et à GitHub. Je ne suis pas sûr de l'accepter.

Comme @silverwind l'a dit : je suppose qu'il est très facile pour les utilisateurs de changer ou d'utiliser Gitea s'ils connaissent Github, car l'interface utilisateur est presque la même.
D'un autre côté (comme l'a dit @xf-): Placer le menu sur le côté gauche facilite le regroupement des paramètres ou des éléments de menu. De plus, la plupart des écrans sont larges. Ainsi, un menu sur le côté gauche donne un accès permanent à ces éléments et ne perturbe pas le contenu. Peut-être que le sujet "où mettre le menu" doit être discuté plus tard s'il y a plus que 3-4 éléments.

Peut-être en commençant par utiliser des variables et des mixins pour plus de cohérence dans le thème actuel.

Par exemple. Un dépôt privé dans la barre latérale de hauteur 36px et un dépôt public ou une organisation 35px. L'organisation a également moins de marge sur le côté gauche. La largeur des deux conteneurs est également différente. Dans le profil, la deuxième rangée d'organisations n'a pas de marge pour la première rangée.

À propos du menu : La plupart des navigations sont correctes et intuitives, mais les menus en haut dans les paramètres/admin sont vraiment étranges. Je préfère les menus dans une liste. Beaucoup plus facile/plus rapide pour trouver l'entrée recherchée.

Font-face est également un gâchis complet. Lato est défini dans sematic-ui.css et dans index.css. Je ne parle pas des commutateurs :lang . J'utiliserais la police Noto - Presque toutes les langues sont disponibles, à espacement fixe et aussi des emojis. (Peut-être un peu hors sujet)
https://en.wikipedia.org/wiki/Noto_fonts
https://www.google.com/get/noto/

C'est vrai. D'après mon expérience (je fais juste un peu de conception de sites Web parce que je suis plus un programmeur qu'un concepteur) : des outils comme SASS ou LESS rendent l'utilisation de CSS si facile. La possibilité d'utiliser et de mettre à jour le code des variables comme est géniale.

La plupart des IDE incluent un compilateur SALL/LESS par défaut ou peuvent être ajoutés en tant que plugin pour mettre à jour le fichier CSS lorsque le fichier de code source est enregistré. Vrai, la police peut être hors sujet ici. Mais c'est une partie du message initial pour

J'ouvre ce ticket pour que nous puissions discuter de l'avenir de Gitea UI

Peut-être que je peux aider un peu à organiser certains fichiers ou à convertir certaines parties en SASS. De mon point de vue (les avis peuvent différer) il y a deux choses importantes qui devraient être mises à jour :

• Disposition réactive lors de l'utilisation de gitea sur votre téléphone mobile (par exemple, pour ajouter des problèmes lorsque vous ne pouvez pas utiliser votre appareil normal)
• Améliorez l'affichage des paramètres d'administration (ou des paramètres personnels également) car il existe de nombreux paramètres. Un menu vertical peut être meilleur qu'horizontal. Certaines peuvent être ajoutées en fonction des fonctionnalités prévues ou souhaitées.

Par exemple : dans Github (si Gitea aime avoir un design similaire à Github), vos éléments "normaux" sont horizontaux pour le code, les problèmes, le wiki, les jalons.

Les autres paramètres de votre référentiel, organisation ou compte personnel sont répertoriés verticalement. De mon point de vue, c'est une excellente décision de conception. Dans Gitea, il n'y a pas encore beaucoup de paramètres. Mais par rapport à github (si gitea grandit beaucoup) l'espace horizontal ne sera pas suffisant ou nous devons tous basculer sur des écrans 16:10 ou des écrans de télévision :)

Comme vous pouvez le voir sur les captures d'écran suivantes :

Paramètres Github, compte personnel :

Paramétrage Gitea, administration système :

Qu'est-ce que tu penses?

Je pense que nous devrions toujours garder moins d'éléments sur les menus pour gérer cela. Moins est plus. :)

Quelque chose qui rendrait le développement de frontaux personnalisés super facile serait la tâche (pas facile) de créer une API pour les serveurs Gitea. De cette façon, le front-end pourrait être écrit dans n'importe quel framework avec lequel les gens sont à l'aise - Mithril, React, vanilla JS, peu importe.

@NetOperatorWibby Gitea a une API, elle n'est tout simplement pas complète pour le moment, voir https://try.gitea.io/api/swagger

Je développe un thème personnalisé de type bitbucket pour gitea.

La bibliothèque d'interface utilisateur utilisée par bitbucket est construite au-dessus de React (Réf : Atlaskit ), j'ai donc intégré React dans le modèle Go avec des moyens "sales".

J'ai maintenu un mappage de chaîne à module dans JS et exposé une fonction render() à window . Je peux appeler la fonction dans chaque modèle correspondant à une page, en passant une chaîne unique et certaines variables de contexte requises par la page comme arguments. Ensuite, la fonction render() découvre quel composant React doit être monté sur la page et le rend avec ces variables comme accessoires.

Honnêtement, l'implémentation actuelle ne correspond pas vraiment à la philosophie des applications React, mais cela fonctionne, et en fait, c'est plus simple qu'un "vrai" React SPA, car vous n'avez pas besoin de vous soucier des routeurs et des états globaux.

@balthild a l'air génial ! Il s'agit donc essentiellement d'une "couche de traduction" placée au-dessus de Gitea qui traduit le modèle Gitea en réaction ?

@kolaente Oui. La raison n'est pas seulement le manque d'API, mais aussi la bibliothèque d'internationalisation. Il n'y a pas d'équivalence JS pour github.com/Unknwon/i18n , je dois donc formater les chaînes dans Go.

@balthild Excellent travail, avez-vous un

@NetOperatorWibby https://github.com/balthild/bitcup Le projet en est à ses débuts. Seule la page du tableau de bord est remplacée, et elle a une mauvaise expérience sur les appareils mobiles.

C'est quelque peu sans rapport mais ce serait cool s'il y avait un endroit pour trouver des thèmes différents. Je pense que le simple fait de laisser savoir à la communauté où trouver des thèmes pourrait conduire à de nouveaux looks innovants et sympas pour gitea.

La thématisation n'est actuellement pas assez abstraite. Je pouvais nous voir passer aux variables CSS natives pour définir les couleurs du thème afin qu'un thème ne soit constitué que d'un ensemble de variables de couleur. Cela signifierait également la suppression de la prise en charge d'IE 11.

@silverwind Je pense que janvier 2020, nous pouvons supprimer le support d'IE11, selon https://en.wikipedia.org/wiki/Internet_Explorer_11 c'est à ce moment-là qu'il atteindra EOL

"Ne me donne pas d'espoir"

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

Internet Explorer 11 sera pris en charge jusqu'à ce que Windows 10 soit en fin de vie

@marcstreeter Ce n'est plus le navigateur par défaut et il ne recevra aucune mise à jour autre que des problèmes de sécurité critiques.

C'est assez simple : si IE nous empêche de livrer une fonctionnalité, son support va être abandonné.

Tout va bien - juste en s'assurant que la décision n'était pas basée sur une fausse date.

Les prochaines étapes de la modernisation de JS devraient être :

• Ajouter Webpack - https://github.com/go-gitea/gitea/pull/8440
• Ajouter Minifier - éventuellement https://github.com/go-gitea/gitea/pull/8440
• Ajoutez Babel qui nous permet d'écrire du JS moderne tout en prenant en charge les navigateurs plus anciens.
• Sourcez les dépendances JS à partir de npm lorsque cela est possible au lieu de les vendre. Cela rendra leur mise à jour un jeu d'enfant.

@silverwind Vous pouvez envisager d'utiliser JS moderne sur les navigateurs modernes. Voici un article à ce sujet : https://philipwalton.com/articles/using-native-javascript-modules-in-production-today/

@mrg0lden Il y a beaucoup à faire, mais toutes ces optimisations avancées peuvent être une charge de maintenance, en particulier en ce qui concerne les configurations de packs Web. Une sorte de moyen « piles incluses » de regrouper le code frontal qui ne nécessite pas beaucoup de configuration serait idéal.

Si vous finissez par faire cela, veuillez utiliser une boîte à outils avec une accessibilité appropriée pour ses widgets de stock, et ne créez pas de widgets personnalisés à moins que vous ne vouliez les rendre accessibles.

@silverwind Avez-vous déjà eu l'occasion d'essayer parcel ? Son but est d'être exactement cela, un bundler js sans configuration, il gère déjà la minification et dispose également d'un serveur de développement avec HMR .

J'ai travaillé avec JS au cours des deux dernières années et je suis plus qu'heureux d'aider si nécessaire.

J'ai essayé parcel dans le passé, mais j'ai trouvé qu'il manquait un peu de configurabilité et d'écosystème de modules. Je suppose que webpack est toujours la norme d'or quand on a besoin de flexibilité, même si sa syntaxe de configuration est nulle.

En fait, vue-service-cli facilite beaucoup la configuration du pack Web pour les projets Vue

@lafriks Je pense que ces outils SPA supposent que le HTML est servi via webpack, ce qui n'est pas le cas pour nous actuellement. Nous pourrons peut-être servir seulement index.html via le webpack, mais ce ne sera pas facile.

Faisons-le étape par étape. On peut partir d'une page plus simple.

@silverwind non, il générera index.html mais vous pouvez facilement le servir depuis golang

Oui, je suppose que nous pourrions éventuellement essayer de déplacer index.html vers webpack afin que nous puissions utiliser l'un des modèles de configuration webpack existants. Cela ne doit pas strictement être celui de la vue car la dernière fois que j'ai vérifié, notre utilisation de la vue était très minime, elle pourrait donc facilement être convertie en autre chose si nous le souhaitons.

Je pense que Gitea ne doit pas être un SPA, mais une AMP.

voter pour l'AMP :

• moins de ressources nécessaires côté client

EDIT : quelqu'un peut toujours écrire SPA avec html+css+js en utilisant les points de terminaison de l'API gitea comme backend ...

Oui, nous sommes déjà trop investis dans le rendu côté serveur, donc je pense qu'une conversation complète avec SPA est presque certainement hors de question.

Je pense qu'il serait intéressant que Gitea adopte une disposition horizontale, similaire à ce qu'utilise Azure Repos. Cette mise en page est beaucoup plus élégante et efficace à mon humble avis, et utilise l'espace de l'écran de manière plus intelligente. Voici quelques captures d'écran pour illustrer ce que je veux dire :

comme toutes les autres interfaces utilisateur, car cela fonctionne également sur des appareils plus petits et le défilement vers le bas est correct.
Même GitHub commence à utiliser 100% de l'écran, par exemple les nouvelles notifications (ou les vérifications / modifications de fichiers dans un PR)

J'aime le style actuel - mais ce n'est que mon avis

Je n'aime pas toujours la vue sous "Fichiers modifiés". De temps en temps j'ai des pull request où 20 fichiers et plus ont été modifiés - ce qui n'est pas toujours évitable (Migration PHP 5.6 -> 7.3).

Le problème est que le navigateur a besoin de beaucoup de temps pour afficher les changements. La page Pull Request se charge rapidement. Seule la coloration syntaxique prend beaucoup de temps.

Ici, une vue similaire à Gitlab est recommandée.

Je parle d'une vue pull request comme dans ce style : https://github.com/go-gitea/gitea/issues/5937#issuecomment -584859265