Content de savoir que les lignes bougent dans le bon sens!
En tant qu'utilisateur final, je ne saurai que faire d'un code ouvert de microcode, car d'après ce qu'en sait (cad peu), il faut avoir accès aux documentations bas niveaux du matériel, généralement non libre et quasi-impossible à se procurer sans être fabricant/constructeur.
En revanche, il est intéressant qu'il puisse être audité niveau sécurité et aussi enfin savoir "pourquoi mes p*tins de serveurs prennent 3 minutes à démarrer" :) .
Je pense ne plus avoir grand chose à ajouter, il me semble que l'on s'est a peu près compris sur l'ensemble des points et arguments abordés, et c'est bien l'essentiel.
Nom du calque réintégré, "neutralité", diminution des tailles des polices, tu as pu voir le résultat sur la 3eme partie du mockup.
Pour le "400", c'est largeur sur la capture du slider de GIMP par défaut (380px pour être exact). Les retrouver par défaut avec ma proposition, ce n'est qu'élargir la fenêtre par défaut. (j'en profite pour signaler un truc très très mineur : lorsque l'on change la taille de la fenêtre, la valeur texte dans le slider, gigote avec un grand temps de retard, ce qui donne un effet un peu étrange)
Pour les ratios dans le bugtracker, sur nos projets quand quelque chose est "prioritaire", toute l'équipe ne bosse que sur ça jusqu'à avoir terminé. On s'attendrait donc pour GIMP à avoir un ratio ouvert/fermé sur l'UI extrêmement supérieur à la moyenne. En première lecture, fonctionnalités et bugs semblent les 2 priorités.
Pour ce qui est de GIMP et des autres logiciels :
Effectivement, je n'ai pas relevé tout ce qui est bien, car ce ne sont pas des points à améliorer (par définition). Ce que je trouve dommage en revanche, c'est l'aspect "layout" vite passé sous le tapis.
Proposer une amélioration à quelque chose, ce n'est pas la même chose de dire que c'est extrêmement mauvais de base. (rappel si besoin : si je considérais que "GIMP c'est tout pourri", il n'aurait pas sa place sur mes machines, et je ne passerai pas un peu de mon temps sur le sujet).
Plus pragmatiquement, il me parait assez "osé" d'exclure les bonnes pratiques des autres logiciels. Ils sont conçu par de grandes équipes, ont quasi tous des ergonomes, des personnes dédiés à l'UI, bref des moyens que l'on reverrait d'offrir à GIMP. Eux aussi ont itéré, et récupéré ici ou la de bonnes idées.
Le but n'est pas de dire "Photoshop c'est mieux", je fais références aux centaines (voir milliers) de logiciels pro, juste en prenant les meilleurs de leurs catégories.
Dans tous les cas, je ne peux que recommander à tous la lecture d'ouvrages très complet comme "Designing Interfaces: Patterns for Effective Interaction Design 3rd Ed."
[Mes propositions ne sont évidement pas paroles d'évangile, néanmoins du haut de mes 42 ans, un vieux diplôme d'ingénieur (en informatique) en poche, avoir bossé en R&D à Philips, créé divers logiciels (opensource en majorité), une bibliothèque pleine à craquer de bouqins de "référence" informatique, une certaine expérience utilisateur des antiques DeluxePaint & TVPaint, Photoshop, CorelDraw, GIMP, Krita; j'ai peut être la fausse impression d'avoir un minium de recul sur le sujet]
le fond de GIMP est dans un gris neutre.
avec teinte bleutée, et forcément, ça pête tout de suite
Oui, le mockup est basé sur ce que propose DaVinci, ni plus ni moins.
C'est pas non plus du rose pétant, pour être exact #2f3036 soit 18.4% de rouge, 18.8% de vert, 21.2% de bleu, soit un écart max de 1.7% par rapport à la valeur moyenne (19.5%).
Je ne conteste pas, j'ai rectifié.
Pour la petite histoire, DaVinci c'est l'outil des pros qui bossent dans des studios neutre, avec éclairage neutre, sur des écrans qui coute le prix d'une belle voiture, histoire d'avoir un environnement constant pour le "color grading" de nos films préférés.
Je présume, qu'ils savent ce qu'ils font en "bleutant" par défaut et en proposant une option pour "neutraliser" le tout.
Voici d'ailleurs ce qu'en dit la documentation : Use gray background interface: By default, DaVinci Resolve uses a blue-gray UI background, intended to provide a more attractive experience for users focused on the less color-critical aspects of DaVinci Resolve, namely editing. Turning this checkbox on switches DaVinci Resolve to a totally neutral, desaturated gray UI, which can be valuable as a point of reference for colorists concerned about the blue-gray UI’s potential to bias the eye in the dark environment of the grading suite.
C'est sûr que si j'écris tout en plus gros, on lit mieux. Tu peux te permettre de faire cela, car encore une fois, tu as travaillé sur une capture d'écran de qualité médiocre, pas sur un vrai logiciel.
Sauf que… c'est du PNG… donc sans pertes, et issu de ma capture sur ma machine sur le vrai GIMP fraichement mise à jour.
La taille de la police, je l'avais précisé : ne pouvant simplement faire un rendu subpixel, elle est un peu plus grande.
J'ai rectifié.
(N’empêche que si c'est plus lisible, je ne vois pas pourquoi s'en passer).
Mais le faire au niveau de 2 captures comme comparaison de mockups, c'est un peu de la "triche", si je puis dire. Cette différence n'existe que dans ta comparaison en image.
Non, elle provienne de la même machine, même écran, même jour.
Et tu les visionnes (en toute logique) sur le même écran, tu peux donc les comparer sans "biais".
Comme j'ai dit dans mon précédent commentaire, les noms de calque/image sont certes des infos redondantes mais utiles. La redondance est en effet parfois très utile si elle te permet de sauver de précieuses secondes, puis minutes, puis heures en cumulé.
Oui. Dans ce cas, je n'ai juste pas l'impression sauf si l'utilisateur est parti boire une dizaine de café entre le moment ou il a choisi le calque sur lequel appliqué l'ombre portée et le moment où il commence à tripoter les réglages.
J'ai rectifié.
Note à "je ne sais plus qui" : ouvrir un 2eme filtre ferme le premier, on est donc pas près de se perdre…
Les fonctions du preset sont dans le "…", car (à priori) pas des fonctions principales.
Ok. Pourquoi pas.
Super, on peut aller même un peu plus loin, cf plus bas.
Il n'y a pas de "petites flèches" dans les textfields, le support de la roulette de la souris s'y substitue bien mieux.
Pas tous les pointeurs n'ont de roulette, notamment pas les tablettes graphiques
Oui. Rien n’empêche de "l'émuler" ou même de gérer le cas stylet en utilisant le principe "shuttle wheel". Une roue / joystick virtuel qui gère non pas une position mais une vitesse.
En quelques mots, le principe est que quand on se décale peu du widget, les valeurs augmentent (ou diminuent) de 0.1 toutes les secondes, si on s'éloigne encore, de 0.2 etc etc.
Pas évident à décrire mais utilisé dans les logiciels vidéo pour avancer/reculer avec plus ou moins de précisions/vitesse simplement.
De plus, quitte à aller plus loin sur le support du stylet, il faudrait envisager les systèmes radiaux (menu, widgets…)
En testant la dernière mouture de GIMP je me suis rendu compte que le slider est encore moins pratique que je pensais, pour remplacer la valeur 10 par 15, il ne suffit pas de cliquer en taper 15, si on fait ca on se retrouve avec un comportement peu intuitif
Je comprends pas ce que tu dis. Je viens de tester, ça marche exactement comme ça. Double cliquer permet de tout sélectionner, un comportement assez classique pour un widget de texte.
Ok, j'ai fini par comprendre… ma (la) tendance naturelle est de (double) cliquer sur le texte, ce qui met le slider à l'endroit du clic, et donc change la valeur…
Pour un widget de texte dans une interface de saisie, j'aurai tendance à suivre le comportement usuel de sélectionner le texte lors du focus afin de pouvoir taper directement sans avoir à effacer (ou double cliquer).
Pour les sliders, tu t'es posé la question des valeurs? Pour une opacité (slider original de 0 à 2), tu as besoin de 400 pas?
Je comprends pas trop la remarque. Bien sûr que oui, tu as besoin du plus de précision possible. Il ne s'agit pas d'une plage de valeur entière (0, 1, 2), mais bien d'un nombre flottant entre 0.0 et 2.0. Si tu joues avec ce curseur "Opacité" du filtre Drop Shadow, tu verras que c'est un changement continu de l'effet (avec la prévisualisation instantané, c'est encore plus sympa à tester).
[NDLR : pourquoi présupposer que je n'utilise pas GIMP ? Si c’était le cas, j'aurai pas pris le temps de lire la dépêche, participer aux discussions et encore moins réfléchir, créer un mockup pour aller de l'avant.
En revanche, il est vrai, je ne le mets pas à jour souvent.]
400 pas pour l'opacité, me semble overkill, je n'ai pas demandé non plus à fixer la largeur max du slider, on a le droit de redimensionner aussi la fenêtre.
Utiliser le slider comme outil de précision, me semble peu adapté. Cf plus haut.
Pour résumé : valeur précise : textfield, incrément précis : jog/shuttle wheel.
Je crains qu'il y a beaucoup de perte de précision dans ta proposition.
Si la fenêtre est un peu plus large, non.
[J'anticipe le "oui, mais si la fenetre est plus large, on va mordre encore plus sur l'affichage de l'image." en rétorquant que l'interface ne fait rien pour maximiser l'affichage en plaçant 2 larges colonnes,respectivement à droite et à gauche.]
Ce dont tu parles est noté dans l'article et tu as vraisemblablement testé la nouvelle version du widget.
J'ai fini par comprendre.
[Mention spéciale à ceux qui me sont tombés dessus en se référant à ce comportement (haut et bas du widget), et qui s'emballe car ca serait une sacrée régression de le perdre.
Pas de bol, c'est déjà viré par la nouvelle version! ]
Pour le "reset", je pense que l'icône choisie est assez "parlante".
Comme quelqu'un le note, ta proposition d'icône fait aussi penser à "Undo" même si ce type d'icône est aussi utilisé dans des cas de "Reset".
Le "reset" n'est il pas un "undo" de toutes les modifications?
C'est typiquement ce que je disais au sujet de la tendance (depuis pas mal d'années déjà) de remplacer le plus possible les icônes par du texte.
Oui, quand c'est pertinent.
Si tu t'intéresses vraiment au design d'application, je te conseillerais de rechercher un peu sur ce sujet.
Comment dire…
Tiens regarde les captures du logiciel que tu nous as montré: du texte partout.
Il a pourtant une foule d’icône… dont l’icône "undo" et à côté de chaque widget.
Attention, on ne dit pas de ne jamais utiliser d'icônes. Personne ne dit ça. Mais vraiment quand on a le choix, du texte est toujours mieux. Pourquoi? C'est clair, beaucoup moins sujet à controverse ou à mésinterprétation.
Je suis d'accord avec toi. Mais tu ne peux pas mettre Aide, Réinitialiser, Valider et Annuler à la même sauce.
Chez GTK+ par exemple, les icônes ont sont progressivement retirés depuis des années (en cherchant un peu, il semblerait que cela ait commencé avec GTK+ 3.10.0 sorti en 2013) des menus, des boutons (typiquement "OK", pas une icône ? ou autre dessin).
Oui, c'était surtout les champions pour mettre "Texte + Icone".
Pour l'icône d'aide, bien moins usitée, éventuellement ok.
OK.
Un alignement du texte à droite (cf. ta proposition) permet-il vraiment une lecture plus rapide que l'alignement à gauche actuel? Honnêtement je sais pas, j'ai jamais rien lu qui dit ça.
Pour l'occasion j'ai ressorti un de mes bouquins sur le sujet : "Designing Interfaces", 3rd EDITION, Patterns for Effective Interaction Design, aux éditions O'Reilly.
15 ans pour 3 éditions, un nombre important d'exemples réels et d'explications claires et sourcées.
Extraits :
_Chapitre 10 : Getting Input from Users: Forms and Controls
Use alignment for clear vertical flow
Use layout and alignment so there is a strong vertical flow to the form whether in one column or more. Align the left edges of the inputs, and use the same vertical separation as much as possible. The eye should be able to move from label to input with minimum travel.
Chapitre 5 : Visual Style and Aesthetics
Right Aligned Text : Only use right aligned text in special cases like form labels_
je dirais qu'il faudrait des études sur le sujet pour me convaincre.
J'éplucherais bien encore quelques uns de mes bouquins mais je manque de temps.
En design d'application, on en est vraiment revenu des interfaces où tout est customisé, même si c'était très fun et avec quelques projets vraiment fous (pensez Winamp et ses skins de fous). Juste pour le fun, remémorons nous l'époque fun de Winamp, ahahah:
Ca y est le "il faut absolument une interface neutre" est enterré?
De nos jours, on privilégie des interfaces unies, qui utilisent les configurations du système, avec un style géré au niveau de l'OS/bureau. On veut avoir à gérer le moins possible ces choses là.
Alors, il est temps de "layouter" comme les OS, d'utiliser les widgets du système, la polie du système, les couleurs du système…
L'UI a toujours été une priorité de GIMP, au moins depuis que j'y contribue pour sûr (8 ans), comme tu peux le voir avec mes réponses.
Important, je veux bien, sinon tu n'auras pas pris le temps de réfléchir aux divers points ci-dessus.
Cependant, si on "fait parler" le bugtracker de GIMP, on a pour le tag "User Interface" : 640 ouverts, 309 fermés.
Alors que si on regarde l'ensemble : 2197 ouverts, 2861 fermés.
Les ratios ne reflètent pas une priorité.
(Je ne nies pas qu'un gros travail a été fait, globalement dans le bon sens, il n'y a qu'a regarder l'historique des releases notes.)
On peut toujours faire mieux, bien sûr, mais l'interface n'est absolument pas laissée au hasard, comme tu sembles le croire.
Non, je ne le crois pas. Je ne connais pas de code qui soit écrit "au hasard".
L'adjectif "atypique" est peut être plus adapté pour l'UI de GIMP.
En tous les cas, je suis pas vraiment convaincu par les différents points de ta proposition. Au début, ça fait joli et nouveau (une nouvelle GUI, ça fait toujours cet effet, car on est juste tellement habitué à une autre), mais une fois les biais de couleur et de taille de fonte retirés, il me semble qu'on perd pas mal en utilisabilité et efficacité (et possiblement même la lisibilité avec l'alignement à droite) sur plusieurs points.
Ayant pris en compte les différentes remarques, voici une dernière version. Dé-saturée, avec le nom du calque et le fruit de quelques nouvelles réflexions:
1/ affichage des unités, pour le coup ça manque.
2/ évolution des réglages : un réglage "Par défaut", sélectionné à l'ouverture de la fenêtre. Dès que l'utilisateur change un paramètre, cela passe en "Personnalisés". Cliquer sur le bouton "Réinitialiser" devient alors choisir dans le sélecteur "Par défaut".
Ce comportement n'est pas une invention mais décliné dans de multiples logiciels.
Quitte à me répéter, GIMP je l'utilise (par forcement beaucoup) et je suis d'avis que son UI est largement améliorable.
J’espère que tu ne prends aucune des remarques sur le logiciel comme un dénigrement du travail accompli (qui est remarquable) ou des personnes qui travaillent dessus.
Discuter, partager permet d'apprendre, de changer, de progresser (autant pour moi que pour les autres).
C'est souvent dans ces échanges que découvre des livres, des technologies, des astuces… que j'essaye de partager quand je peux. Merci donc d'avoir pris le temps.
Bon, j'ai fini par sortir la tablette graphique, ai essayé de cliquer/glisser au stylet les parties hautes et basses des sliders X,Y,Opacité… il n'y a pas de comportement particulier. Seul bouger gauche/droite change la valeur du slider, comme pour… un slider standard…
Donc soit c'est bien planqué, soit je suis débile, soit tu parles de quelque chose qui n'a rien à voir avec ce filtre.
Un grand merci aussi pour le fait de caricaturer ce que j'ai pu écrire, ça fait toujours plaisir.
Je me rend compte que ce que j'ai proposé n'est pas encore assez abouti, il manque les unités sur X/Y/rayons. De plus, la "combobox" pour les 2 choix de "rognages" pourrait être remplacée par un "radiobutton" afin d'éviter un clic.
Ce qui me rassure c'est que Jehan a trouvé pertinent mes quelques remarques.
Je vais donc lui emboiter le pas, et ne plus perdre de temps sur le sujet.
C'est toujours sympa cette tendance à commencer par un préjugé.
Pour + et [<], respectivement "ajouter un preset" et l’accès au menu import/export/gestion des presets. Je ne vois pas ce que tu perds à tout ranger dans un seul menu accessible avec une icône "…" plutôt qu'un minuscule [<] . L'ajout de preset n'étant pas la fonctionnalité majeure de cette UI.
Pour les sliders, tu t'es posé la question des valeurs? Pour une opacité (slider original de 0 à 2), tu as besoin de 400 pas?
Tu trouves ça pratique de "shooter" la valeur quand il faut double cliquer pour taper une valeur précise?
Pour ce qui est du "haut"/"bas" des sliders, j'expliquai plus haut que la fonctionnalité peut être gardée sans les fleches avec l'utilisation de la roulette. Rien n’empêche de les garder non plus sur le "textfield". Proposer n'est pas imposer. Merci.
Merci pour ton retour, voici un petit mockup en prenant en compte tes explications:
Le rendu proposé des polices n'est pas terrible, je n'ai pas de moyen simple de faire un rendu 'subpixel'.
Pour résumer : "G", ":", "nom du layer" et "du document" sont retirés, car inutiles ou visibles et connus par ailleurs.
Tout est aligné au pixel près (marges : 6px x 4px).
Les fonctions du preset sont dans le "…", car (à priori) pas des fonctions principales.
En testant la dernière mouture de GIMP je me suis rendu compte que le slider est encore moins pratique que je pensais, pour remplacer la valeur 10 par 15, il ne suffit pas de cliquer en taper 15, si on fait ca on se retrouve avec un comportement peu intuitif, il faut alors double cliquer sur le texte, et hop, fausse manip, on a vite fait d'interagir avec le slider superposé… Bref, j'ai repris du "classic".
Pour ce qui est de la largeur du slider, il est bien assez large pour avoir les valeurs qui ont du sens, on peut aussi imaginer d’adopter la stratégie d'autre logiciel en faisant un slider non linéaire quand dépasse les 75%.
Il n'y a pas de "petites flèches" dans les textfields, le support de la roulette de la souris s'y substitue bien mieux.
Pour le "reset", je pense que l'icône choisie est assez "parlante".
Note pour ceux qui pensent que c'est du pinaillage, les alignements verticaux permettent une lecture plus rapide, l'homogénéisation des marges et hauteurs aident aussi car le cerveau à tendance à donner se focaliser sur les différences.
Pour ce qui est des choix, polices/thèmes etc… en tant que programmateur j'ai tendance aussi à tout laisser paramétrable, mais je me rend compte au fil des années qu'il est plus productif de proposer un truc clean par défaut plutôt que de laisser tous les utilisateurs bricoler dans leurs coins.
Si l'UI devient une priorité de GIMP, je peux aider à raison d'une analyse/redesign de fenêtre par semaine, et aussi à poser les questions qui fâchent (genre "on s'en fout pas un peu du G"). Je n'ai pas de problème non plus à compiler les sources depuis le master et à causer Franglish.
A l'occasion, essayes DaVinci.
C'est un bijou d'ergonomie.
Étrangement, je n'ai pas vu passer d'article élogieux sur l'ergonomie de GIMP, pas contre les critiques pleuvent. Il me semble que GIMP est un bon logiciel dans un emballage pas encore à la hauteur de ses capacités.
Utiliser toute la largeur pour un slider, c'est une bonne intention, mais en pratique, est-ce utile?
Si l'on souhaite permettre de fixer une valeur particulière, on fournit généralement un "textfield".
Les programmeurs de DaVinci ont eu une bonne idée, le "textfield" permet de faire "slider" aussi pour remplacer les "flèches d'ajustements" pour gagner un peu de place et ne pas surcharger l'interface. De plus, rien n’empêche d'avoir un petit bouton sur le slider et de permettre de l'attraper sur une zone bien plus haute (et large).
Quand j’étais étudiant, il y 20 ans, j'ai déjà tenter avec des camarades de promo… l’accueil de patchs et d'améliorations concrètes fut assez "sulfureux", mais on est pas sortis rancuniers pour autant.
Pour le guide des interface graphique, Apple a fait le job il y a bien longtemps : http://www.multimedialab.be/doc/tech/doc_osx_hi_guidelines.pdf (cf alignements pages 282)
Le guide est assez général pour s'appliquer à toutes les plateformes, et contrairement aux autres productions Apple, c'est encore d'actualité.
Merci pour l'info sur le G pour GEGL, pas sûr que ça valait le coût de polluer l’interface avec (par contre l'auteur d'un bugreport pour le retirer va se prendre une balle en pleine tête).
Le multi-fenêtrage n'est pas un problème, c'est même très pratique.
Il faut plutôt chercher tout ce qui énerve, n'est pas pratique, pas facilement compréhensible, mal présenté… Souvent les problèmes arrivent avec le temps, on ajoute ci ou ça, on ne sait pas trop ou le mettre sans tout réorganiser. Avec le recul de 20 ans sur GIMP, j'aurai plutôt du écrire "en manque d'amour" que "mal pensée".
Réorganiser, simplifier, aligner, polisher seraient à mon avis plus bénéfique à court terme au projet que : optimiser, claquer "de la fonctionnalité de la mort", ajouter des réglages.
Un minimum de respect du travail des autres serait appréciable, et ça ferait sûrement du monde un endroit meilleur (un tout petit peu au moins).
Il me semble que les devs de GIMP ont aussi une lourde responsabilité.
Voila plus de 20 ans que je vois GIMP s'améliorer sans cesse, techniquement un sacré travail et surtout une grande détermination à ajouter sans cesse de nouvelles fonctionnalités qui ont de quoi balayer Photoshop. Et je vous adore pour ça.
Par contre, les lourdes critiques sont liées au revers de cette médaille : massacre en règle de l'ergonomie, peu d'écoute des retours constructifs, UI mal pensée et encore moins bien réalisée.
N’empêche que j'aime bien bien ce projet et un supporter du projet.
A chaque téléchargement de GIMP, je me dis "allez c'est bon, ils ont du faire le tour des fonctionnalités, ils ont bien du prendre un peu de temps pour repenser l'interface du logiciel", mais non, alors je patiente sans trop râler :)
Retour d'un graphiste qui juge GIMP sur un simple screenhot de son UI :
(pour quand vous aurez le temps ou l'envie de régler le problème n°1 de GIMP : l'UI )
De haut en bas:
Drop Shadow (en titre), Drop Shadow en sous titre, un machin tronqué sans raison "Drop… 27 (Untitled) : on peut pas faire mieux ? A quoi il sert ce logo à gauche? et la preview de 4mm x 3mm, elle sert à quelque chose en l'état?
Presets : pourquoi un ":" ? Icônes minuscule pas vraiment parlantes.
X : "X" collé à gauche, marge à revoir, de plus le "slider" est plus au que les autres widget. Le fait de mettre le label (X) dans le widget casse la logique de l'interface.
Clipping : un combo avec un look encore différent
Preview / Split : bizarre ce Split qui part à droite
Help & reset: des icônes discrètes seraient suffisantes
i7 c'est la version 17, évolution mineure de la 16, mais version à repayer totalement car "nouvelle version révolutionnaire" même pour ceux qui payaient la maintenance avec mise à jour depuis 10 ans.
Enfin… de ce que j'ai compris…
Sage c'est aussi les spécialistes du "c'est aux autres de faire", sur Coala, la seule réponse de la hotline c'est de restaurer depuis une sauvegarde, même quand l'export FEC déconne, quand la balance n'est pas juste, quand ça crache à l'impression… c'est d'ailleurs assez marrant de voir que l'on nous confie la "maintenance" de Sage en plus de la maintenance d'OpenConcerto dans les cabinets comptables qui utilisent les deux.
De ce que je peux en dire, de la fenêtre OpenConcerto, c'est que l'ORM gère la vie de données manipulées (création, modification et archivage) ainsi que les "listes".
OLAP ne servant qu'à faire du reporting dynamnique, cad à travers une interface graphique qui va créer une requête MDX qui sera exécutée par le moteur OLAP, nul besoin de passer par l'ORM.
Donc, au final, pas de SQL ou MDX "en dur".
Faut pas trop en demander à 'Orange Cyberdéfense', pour un audit à moins de 200 millions d'euros (enfin j’espère ;) )
Plus sérieusement, quand un audit se termine par un tableau de notes de 1 à 4… on sait qu'il est raccord avec la qualité du code.
De ce que l'on voit à travers OpenConcerto, ce n'est pas tant le "deni" que l'impuissance des discours commerciaux face à problèmes techniques qui est frappant.
On a eu le cas de clients qui ont voulu mettre à jour leur logiciels Sage, on leur a annoncé que la migration des données n'était pas possible. Magiquement, on a fait le travail pour tout rapatrier sur OpenConcerto (et pour mois cher que le prix de la nouvelle licence…).
Tous les PGIs libres sont capables de migrer les données Sage, mais pas Sage?
Le marché change très doucement, je pense que l'inertie n'est pas prête de diminuer, car les investissements et les habitudes freinent.
Il faudra à mon avis attendre au moins 10-15 ans pour que les chiffres d'affaires des gros éditeurs baissent significativement et qu'ils bougent. Sûrement à coût de rachats de solution open-source. Wait & See.
On sait tous que le monde JS n'existe plus car bientôt remplacé par le monde "ES.Next", où les performances et les architectures de pointes associées, vont amener l’écosystème Web à un niveau jamais atteint d'excellence.
Les dernières études montrent que l'architecture se montrera capable de choses surprenantes et inatteignables pour "l'ancien monde". En effet, sur un cluster de machines virtuelles, chaque fonctionnalité sera déployée en tant que container muni d'un compilateur JIT haute performance. Le tout redondé et auto-configuré par un ordonnanceur de type 4.
Une telle architecture pourra permettre de gérer jusqu'au 1 million de requêtes HTTP/2 par an avec une garantie de traitement des requêtes porté à 99.9% avec seulement 5 serveurs!
Contrairement à ce que tu penses, il est très facile de me convaincre, mais seulement avec des faits, des choses vérifiables.
En informatique on a la chance de pouvoir expérimenter à peu de frais et surtout d'avoir des systèmes complètements déterministes.
Bref, une explication technique, un bout de code, un résultat de benchmark, je suis preneur.
Un discours marketing ou un truc tiré de la "doc" d'un vendeur, non merci.
Quand Hazelcast dit que pour éviter d'avoir à utiliser plusieurs JVM (qui selon eux est un moyen d'éviter les problèmes de lags liés aux GC), ils préconisent leur solution "Hazelcast IMDG Enterprise HD", tu devrais te poser des questions.
Manque de bol, le Java et les performances, je peux t'en parler des heures (et te sourcer ou montrer par du code, tout ce que je j'avance). En 2001 j'ai commencé à faire du Java sérieusement avec la version 1.1.8 sur de l'embarqué (settopbox) avec 8Mo de mémoire et un processeur à 50MHz (et ca tournait nickel), je n'ai jamais arrêté de faire du Java depuis (en plus de bien d'autres langages).
Hazelcast fait références aux premiers GCs qui mettaient en pause la JVM, d'où un "lag" (voir https://www.baeldung.com/jvm-garbage-collectors pour les différents GC). Le problème est réglé depuis des années, avec par exemple le GC "G1". Aujourd'hui une application qui est ralentie par un GC est une application qui alloue à tout va avec une gestion de la mémoire mal ou pas pensée du tout.
Pour les protocoles texte vs binaire, effectivement je ne pense pas être convaincu que tout un tas de projets utilisent un protocole binaire et pas texte, car ils leurs développeurs aiment la complexité et introduire des bugs dans les "clients" (argument Redis).
Pour moi, il n'y a pas difficulté à utiliser un protocole binaire, et le gain en bande passante (entre x2 et x4) et en performance est tellement important que cela permet d'en faire plus avec un même matériel ou quantité d'énergie.
Quel cache ?
Ma phrase aurait pu être plus claire, je faisais référence à un cache que tu ferrais toi même avec une hash table ou équivalent, c'est à dire un cache local à l'application.
Concernant le profiling, c'est un peu plus gris, en Java je vais préférer que tout soit dans une même JVM pour avoir une vision globale et juste (historique des threads et lock dans JProfiler par exemple).
Pour la fragmentation, au contraire, plus l'espace mémoire disponible est grand, moins elle est un problème puisque mécaniquement les espaces contigus libre sont importants.
"faux problème"
Ce n'était pas de la rhétorique, je trouvais arbitraire de définir cela comme un problème, d'où mon explication du pourquoi ça ne pose pas de problèmes.
Pour les statistiques NoSQL que tu présentes, se pose en effet la question de savoir si le nombre de drivers est lié à la simplicité du protocole.
Autre réflexion :
plus une base de données est populaire,
plus le nombre d'utilisateurs est grand,
plus le nombre d'utilisateurs de langages peu utilisés est important,
plus la probabilité qu'un développeur/utilisateur se colle à la création du driver est importante.
Encore une fois, écrire un driver pour un protocole binaire n'a rien de difficile (par rapport à un protocole ascii) si le protocole est documenté.
De plus tu n'as (quasiment) jamais à le faire car les principaux langages ont tous leurs drivers officiels.
J'avais envie de te dire que le fait que le driver VB n'existe pas pour MongoDB, n'est un manque pour personne, mais en fait, ce driver existe (https://consulity.net/content/consulity-InstallMongoDB.aspx), idem pour Cassandra. Les chiffres sont donc à ajuster.
De plus, sachant qu'il n'y a pas de driver pour COBOL pour ces bases NoSQL, quelle corrélation y vois tu?
Peut-être parce que l'informatique ce n'est pas qu'une unique question de logiciels
Oui, assurément mais, à mon humble avis, tu vas un peu loin sur les aspects de gestion de la vieillesse des systèmes, des aspects légaux,… tu as le même problème avec une automobile, un jour tu ne trouves plus les pièces, elle doit respecter des contraintes légales de sécurité…
Et vu le nombre de logiciels dans ma voitures, dois-je conclure que je fais de l'informatique en l'utilisant?
Le cache devient la clé de voûte
N'est ce pas dangereux si ce cache n'est pas persistent?
N'est ce pas dangereux si ce cache n'est pas transactionnel?
Le cache … sert à maintenir des connexions à des bases de données, à alerter sur une situation anormale
Tu parles toujours d'un service de cache comme Robert/Redis ?
Oups, encore quelques nouveaux points que je ne comprend pas:
Un cache ça sert à stocker le résultat d'un traitement pour y accéder plus rapidement. Tant que le traitement en question est significativement plus long que la lecture depuis cette base de données, ça peut rester pertinent.
Du coup, dans ce cas, les performances apportées par le service de cache ne serviront à rien car un cache local ferra le boulot, non?
un système d'exploitation préfère avoir 2 processus de 4Gio qu'un seul de 8
A quoi fais tu référence? Les performances sont meilleures si l'on utilise les processus à la place des threads, où de stabilité, de consommation mémoire ?
Je loupe surement quelques choses, car il "semble" (https://eli.thegreenplace.net/2018/measuring-context-switching-and-memory-overheads-for-linux-threads/) que les threads sont plus rapides à démarrer que les processus, et le temps de "context switch" est plus court pour les threads.
tu peux ne pas avoir le choix, comme je le disais plus haut avec PHP..
tu peux vouloir que ton cache survive à un redémarrage de ton applicatif
Pourquoi pas, en effet (souvent les caches c'est le premier truc que tu veux virer au démarrage d'une appli pour être dans un état connu,donc à priori, stable).
tu peux vouloir que ton applicatif scale
Oui, mais on sort du cas "1 serveur", mes remarques n'étaient que sur ce cas d'utilisation.
On est bien d'accord qu'un cluster, Redis/Robert ont leur utilité.
simplifier la vie des développeurs pour ne pas avoir toi même à créer un client
Ce "problème" (ou "faux problème"), tu l'as pour les bases de données sous le nom de "driver" JDBC/ODBC/etc… développés et fournis par les développeurs des bases de données.
Borg est sans conteste LA solution à mettre en place pour qui cherche une sauvegarde cryptée.
C'est important de désactiver la compression au niveau ssh, les données chiffrées sont quasi incompressibles si le chiffrage est bon, inutile donc de ralentir le transfert pour rien (vu que les processeurs de NAS sont rarement très véloces).
# HPE
Posté par Guillaume Maillard (site web personnel) . En réponse au journal Microcode ouvert sur materiel HPE ?. Évalué à 3.
Content de savoir que les lignes bougent dans le bon sens!
En tant qu'utilisateur final, je ne saurai que faire d'un code ouvert de microcode, car d'après ce qu'en sait (cad peu), il faut avoir accès aux documentations bas niveaux du matériel, généralement non libre et quasi-impossible à se procurer sans être fabricant/constructeur.
En revanche, il est intéressant qu'il puisse être audité niveau sécurité et aussi enfin savoir "pourquoi mes p*tins de serveurs prennent 3 minutes à démarrer" :) .
[^] # Re: Traduction approximative
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche GIMP 2.10.14 et 2.10.18 : sans limites. Évalué à 4.
Je pense ne plus avoir grand chose à ajouter, il me semble que l'on s'est a peu près compris sur l'ensemble des points et arguments abordés, et c'est bien l'essentiel.
Nom du calque réintégré, "neutralité", diminution des tailles des polices, tu as pu voir le résultat sur la 3eme partie du mockup.
Pour le "400", c'est largeur sur la capture du slider de GIMP par défaut (380px pour être exact). Les retrouver par défaut avec ma proposition, ce n'est qu'élargir la fenêtre par défaut. (j'en profite pour signaler un truc très très mineur : lorsque l'on change la taille de la fenêtre, la valeur texte dans le slider, gigote avec un grand temps de retard, ce qui donne un effet un peu étrange)
Pour les ratios dans le bugtracker, sur nos projets quand quelque chose est "prioritaire", toute l'équipe ne bosse que sur ça jusqu'à avoir terminé. On s'attendrait donc pour GIMP à avoir un ratio ouvert/fermé sur l'UI extrêmement supérieur à la moyenne. En première lecture, fonctionnalités et bugs semblent les 2 priorités.
Pour ce qui est de GIMP et des autres logiciels :
Effectivement, je n'ai pas relevé tout ce qui est bien, car ce ne sont pas des points à améliorer (par définition). Ce que je trouve dommage en revanche, c'est l'aspect "layout" vite passé sous le tapis.
Proposer une amélioration à quelque chose, ce n'est pas la même chose de dire que c'est extrêmement mauvais de base. (rappel si besoin : si je considérais que "GIMP c'est tout pourri", il n'aurait pas sa place sur mes machines, et je ne passerai pas un peu de mon temps sur le sujet).
Plus pragmatiquement, il me parait assez "osé" d'exclure les bonnes pratiques des autres logiciels. Ils sont conçu par de grandes équipes, ont quasi tous des ergonomes, des personnes dédiés à l'UI, bref des moyens que l'on reverrait d'offrir à GIMP. Eux aussi ont itéré, et récupéré ici ou la de bonnes idées.
Le but n'est pas de dire "Photoshop c'est mieux", je fais références aux centaines (voir milliers) de logiciels pro, juste en prenant les meilleurs de leurs catégories.
Dans tous les cas, je ne peux que recommander à tous la lecture d'ouvrages très complet comme "Designing Interfaces: Patterns for Effective Interaction Design 3rd Ed."
[Mes propositions ne sont évidement pas paroles d'évangile, néanmoins du haut de mes 42 ans, un vieux diplôme d'ingénieur (en informatique) en poche, avoir bossé en R&D à Philips, créé divers logiciels (opensource en majorité), une bibliothèque pleine à craquer de bouqins de "référence" informatique, une certaine expérience utilisateur des antiques DeluxePaint & TVPaint, Photoshop, CorelDraw, GIMP, Krita; j'ai peut être la fausse impression d'avoir un minium de recul sur le sujet]
[^] # Re: Traduction approximative
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche GIMP 2.10.14 et 2.10.18 : sans limites. Évalué à 2.
Pour une raison qui m'échappe, impossible d'inclure l'image :
https://ilm-informatique.fr/images/davingimp2.png
[^] # Re: Traduction approximative
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche GIMP 2.10.14 et 2.10.18 : sans limites. Évalué à 4. Dernière modification le 27 mai 2020 à 22:42.
Oui, le mockup est basé sur ce que propose DaVinci, ni plus ni moins.
C'est pas non plus du rose pétant, pour être exact #2f3036 soit 18.4% de rouge, 18.8% de vert, 21.2% de bleu, soit un écart max de 1.7% par rapport à la valeur moyenne (19.5%).
Je ne conteste pas, j'ai rectifié.
Pour la petite histoire, DaVinci c'est l'outil des pros qui bossent dans des studios neutre, avec éclairage neutre, sur des écrans qui coute le prix d'une belle voiture, histoire d'avoir un environnement constant pour le "color grading" de nos films préférés.
Je présume, qu'ils savent ce qu'ils font en "bleutant" par défaut et en proposant une option pour "neutraliser" le tout.
Voici d'ailleurs ce qu'en dit la documentation :
Use gray background interface: By default, DaVinci Resolve uses a blue-gray UI background, intended to provide a more attractive experience for users focused on the less color-critical aspects of DaVinci Resolve, namely editing. Turning this checkbox on switches DaVinci Resolve to a totally neutral, desaturated gray UI, which can be valuable as a point of reference for colorists concerned about the blue-gray UI’s potential to bias the eye in the dark environment of the grading suite.
La taille de la police, je l'avais précisé : ne pouvant simplement faire un rendu subpixel, elle est un peu plus grande.
J'ai rectifié.
(N’empêche que si c'est plus lisible, je ne vois pas pourquoi s'en passer).
Oui. Dans ce cas, je n'ai juste pas l'impression sauf si l'utilisateur est parti boire une dizaine de café entre le moment ou il a choisi le calque sur lequel appliqué l'ombre portée et le moment où il commence à tripoter les réglages.
J'ai rectifié.
Note à "je ne sais plus qui" : ouvrir un 2eme filtre ferme le premier, on est donc pas près de se perdre…
Super, on peut aller même un peu plus loin, cf plus bas.
Oui. Rien n’empêche de "l'émuler" ou même de gérer le cas stylet en utilisant le principe "shuttle wheel". Une roue / joystick virtuel qui gère non pas une position mais une vitesse.
En quelques mots, le principe est que quand on se décale peu du widget, les valeurs augmentent (ou diminuent) de 0.1 toutes les secondes, si on s'éloigne encore, de 0.2 etc etc.
Pas évident à décrire mais utilisé dans les logiciels vidéo pour avancer/reculer avec plus ou moins de précisions/vitesse simplement.
De plus, quitte à aller plus loin sur le support du stylet, il faudrait envisager les systèmes radiaux (menu, widgets…)
Ok, j'ai fini par comprendre… ma (la) tendance naturelle est de (double) cliquer sur le texte, ce qui met le slider à l'endroit du clic, et donc change la valeur…
Pour un widget de texte dans une interface de saisie, j'aurai tendance à suivre le comportement usuel de sélectionner le texte lors du focus afin de pouvoir taper directement sans avoir à effacer (ou double cliquer).
[NDLR : pourquoi présupposer que je n'utilise pas GIMP ? Si c’était le cas, j'aurai pas pris le temps de lire la dépêche, participer aux discussions et encore moins réfléchir, créer un mockup pour aller de l'avant.
En revanche, il est vrai, je ne le mets pas à jour souvent.]
400 pas pour l'opacité, me semble overkill, je n'ai pas demandé non plus à fixer la largeur max du slider, on a le droit de redimensionner aussi la fenêtre.
Utiliser le slider comme outil de précision, me semble peu adapté. Cf plus haut.
Pour résumé : valeur précise : textfield, incrément précis : jog/shuttle wheel.
Si la fenêtre est un peu plus large, non.
[J'anticipe le "oui, mais si la fenetre est plus large, on va mordre encore plus sur l'affichage de l'image." en rétorquant que l'interface ne fait rien pour maximiser l'affichage en plaçant 2 larges colonnes,respectivement à droite et à gauche.]
J'ai fini par comprendre.
[Mention spéciale à ceux qui me sont tombés dessus en se référant à ce comportement (haut et bas du widget), et qui s'emballe car ca serait une sacrée régression de le perdre.
Pas de bol, c'est déjà viré par la nouvelle version! ]
Le "reset" n'est il pas un "undo" de toutes les modifications?
Comment dire…
OK.
Pour l'occasion j'ai ressorti un de mes bouquins sur le sujet : "Designing Interfaces", 3rd EDITION, Patterns for Effective Interaction Design, aux éditions O'Reilly.
15 ans pour 3 éditions, un nombre important d'exemples réels et d'explications claires et sourcées.
Extraits :
_Chapitre 10 : Getting Input from Users: Forms and Controls
Use alignment for clear vertical flow
Use layout and alignment so there is a strong vertical flow to the form whether in one column or more. Align the left edges of the inputs, and use the same vertical separation as much as possible. The eye should be able to move from label to input with minimum travel.
Chapitre 5 : Visual Style and Aesthetics
Right Aligned Text : Only use right aligned text in special cases like form labels_
J'éplucherais bien encore quelques uns de mes bouquins mais je manque de temps.
Ca y est le "il faut absolument une interface neutre" est enterré?
Alors, il est temps de "layouter" comme les OS, d'utiliser les widgets du système, la polie du système, les couleurs du système…
Important, je veux bien, sinon tu n'auras pas pris le temps de réfléchir aux divers points ci-dessus.
Cependant, si on "fait parler" le bugtracker de GIMP, on a pour le tag "User Interface" : 640 ouverts, 309 fermés.
Alors que si on regarde l'ensemble : 2197 ouverts, 2861 fermés.
Les ratios ne reflètent pas une priorité.
(Je ne nies pas qu'un gros travail a été fait, globalement dans le bon sens, il n'y a qu'a regarder l'historique des releases notes.)
Non, je ne le crois pas. Je ne connais pas de code qui soit écrit "au hasard".
L'adjectif "atypique" est peut être plus adapté pour l'UI de GIMP.
Ayant pris en compte les différentes remarques, voici une dernière version. Dé-saturée, avec le nom du calque et le fruit de quelques nouvelles réflexions:
https://ilm-informatique.fr/images/davingimp2.png
1/ affichage des unités, pour le coup ça manque.
2/ évolution des réglages : un réglage "Par défaut", sélectionné à l'ouverture de la fenêtre. Dès que l'utilisateur change un paramètre, cela passe en "Personnalisés". Cliquer sur le bouton "Réinitialiser" devient alors choisir dans le sélecteur "Par défaut".
Ce comportement n'est pas une invention mais décliné dans de multiples logiciels.
Quitte à me répéter, GIMP je l'utilise (par forcement beaucoup) et je suis d'avis que son UI est largement améliorable.
J’espère que tu ne prends aucune des remarques sur le logiciel comme un dénigrement du travail accompli (qui est remarquable) ou des personnes qui travaillent dessus.
Discuter, partager permet d'apprendre, de changer, de progresser (autant pour moi que pour les autres).
C'est souvent dans ces échanges que découvre des livres, des technologies, des astuces… que j'essaye de partager quand je peux. Merci donc d'avoir pris le temps.
[^] # Re: Traduction approximative
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche GIMP 2.10.14 et 2.10.18 : sans limites. Évalué à 0.
Bon, j'ai fini par sortir la tablette graphique, ai essayé de cliquer/glisser au stylet les parties hautes et basses des sliders X,Y,Opacité… il n'y a pas de comportement particulier. Seul bouger gauche/droite change la valeur du slider, comme pour… un slider standard…
Donc soit c'est bien planqué, soit je suis débile, soit tu parles de quelque chose qui n'a rien à voir avec ce filtre.
Un grand merci aussi pour le fait de caricaturer ce que j'ai pu écrire, ça fait toujours plaisir.
Je me rend compte que ce que j'ai proposé n'est pas encore assez abouti, il manque les unités sur X/Y/rayons. De plus, la "combobox" pour les 2 choix de "rognages" pourrait être remplacée par un "radiobutton" afin d'éviter un clic.
Ce qui me rassure c'est que Jehan a trouvé pertinent mes quelques remarques.
Je vais donc lui emboiter le pas, et ne plus perdre de temps sur le sujet.
[^] # Re: Traduction approximative
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche GIMP 2.10.14 et 2.10.18 : sans limites. Évalué à 5. Dernière modification le 25 mai 2020 à 11:52.
C'est toujours sympa cette tendance à commencer par un préjugé.
Pour + et [<], respectivement "ajouter un preset" et l’accès au menu import/export/gestion des presets. Je ne vois pas ce que tu perds à tout ranger dans un seul menu accessible avec une icône "…" plutôt qu'un minuscule [<] . L'ajout de preset n'étant pas la fonctionnalité majeure de cette UI.
Pour les sliders, tu t'es posé la question des valeurs? Pour une opacité (slider original de 0 à 2), tu as besoin de 400 pas?
Tu trouves ça pratique de "shooter" la valeur quand il faut double cliquer pour taper une valeur précise?
Pour ce qui est du "haut"/"bas" des sliders, j'expliquai plus haut que la fonctionnalité peut être gardée sans les fleches avec l'utilisation de la roulette. Rien n’empêche de les garder non plus sur le "textfield". Proposer n'est pas imposer. Merci.
[^] # Re: Traduction approximative
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche GIMP 2.10.14 et 2.10.18 : sans limites. Évalué à -3.
Exact, mais si retirer quelque chose n'affecte en rien le résultat -> on vire
-> https://designopendata.files.wordpress.com/2014/05/lawsofsimplicity_johnmaeda.pdf
Donc pour les ":", on peut l'appliquer, et les traductions existantes un replaceAll(":",""); ne devraient rien casser.
[^] # Re: Traduction approximative
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche GIMP 2.10.14 et 2.10.18 : sans limites. Évalué à 10. Dernière modification le 24 mai 2020 à 14:50.
Merci pour ton retour, voici un petit mockup en prenant en compte tes explications:
Le rendu proposé des polices n'est pas terrible, je n'ai pas de moyen simple de faire un rendu 'subpixel'.
Pour résumer : "G", ":", "nom du layer" et "du document" sont retirés, car inutiles ou visibles et connus par ailleurs.
Tout est aligné au pixel près (marges : 6px x 4px).
Les fonctions du preset sont dans le "…", car (à priori) pas des fonctions principales.
En testant la dernière mouture de GIMP je me suis rendu compte que le slider est encore moins pratique que je pensais, pour remplacer la valeur 10 par 15, il ne suffit pas de cliquer en taper 15, si on fait ca on se retrouve avec un comportement peu intuitif, il faut alors double cliquer sur le texte, et hop, fausse manip, on a vite fait d'interagir avec le slider superposé… Bref, j'ai repris du "classic".
Pour ce qui est de la largeur du slider, il est bien assez large pour avoir les valeurs qui ont du sens, on peut aussi imaginer d’adopter la stratégie d'autre logiciel en faisant un slider non linéaire quand dépasse les 75%.
Il n'y a pas de "petites flèches" dans les textfields, le support de la roulette de la souris s'y substitue bien mieux.
Pour le "reset", je pense que l'icône choisie est assez "parlante".
Note pour ceux qui pensent que c'est du pinaillage, les alignements verticaux permettent une lecture plus rapide, l'homogénéisation des marges et hauteurs aident aussi car le cerveau à tendance à donner se focaliser sur les différences.
Pour ce qui est des choix, polices/thèmes etc… en tant que programmateur j'ai tendance aussi à tout laisser paramétrable, mais je me rend compte au fil des années qu'il est plus productif de proposer un truc clean par défaut plutôt que de laisser tous les utilisateurs bricoler dans leurs coins.
Si l'UI devient une priorité de GIMP, je peux aider à raison d'une analyse/redesign de fenêtre par semaine, et aussi à poser les questions qui fâchent (genre "on s'en fout pas un peu du G"). Je n'ai pas de problème non plus à compiler les sources depuis le master et à causer Franglish.
[^] # Re: Traduction approximative
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche GIMP 2.10.14 et 2.10.18 : sans limites. Évalué à 3.
A l'occasion, essayes DaVinci.
C'est un bijou d'ergonomie.
Étrangement, je n'ai pas vu passer d'article élogieux sur l'ergonomie de GIMP, pas contre les critiques pleuvent. Il me semble que GIMP est un bon logiciel dans un emballage pas encore à la hauteur de ses capacités.
Utiliser toute la largeur pour un slider, c'est une bonne intention, mais en pratique, est-ce utile?
Si l'on souhaite permettre de fixer une valeur particulière, on fournit généralement un "textfield".
Les programmeurs de DaVinci ont eu une bonne idée, le "textfield" permet de faire "slider" aussi pour remplacer les "flèches d'ajustements" pour gagner un peu de place et ne pas surcharger l'interface. De plus, rien n’empêche d'avoir un petit bouton sur le slider et de permettre de l'attraper sur une zone bien plus haute (et large).
Faire simple c'est un long travail de réflexion et de tests.
J'en profite pour conseiller un livre, qui pour moi, est LA référence à ce sujet : https://designopendata.files.wordpress.com/2014/05/lawsofsimplicity_johnmaeda.pdf
[^] # Re: Traduction approximative
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche GIMP 2.10.14 et 2.10.18 : sans limites. Évalué à 6.
Quand j’étais étudiant, il y 20 ans, j'ai déjà tenter avec des camarades de promo… l’accueil de patchs et d'améliorations concrètes fut assez "sulfureux", mais on est pas sortis rancuniers pour autant.
Pour le guide des interface graphique, Apple a fait le job il y a bien longtemps : http://www.multimedialab.be/doc/tech/doc_osx_hi_guidelines.pdf (cf alignements pages 282)
Le guide est assez général pour s'appliquer à toutes les plateformes, et contrairement aux autres productions Apple, c'est encore d'actualité.
Merci pour l'info sur le G pour GEGL, pas sûr que ça valait le coût de polluer l’interface avec (par contre l'auteur d'un bugreport pour le retirer va se prendre une balle en pleine tête).
[^] # Re: Traduction approximative
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche GIMP 2.10.14 et 2.10.18 : sans limites. Évalué à 3.
Le multi-fenêtrage n'est pas un problème, c'est même très pratique.
Il faut plutôt chercher tout ce qui énerve, n'est pas pratique, pas facilement compréhensible, mal présenté… Souvent les problèmes arrivent avec le temps, on ajoute ci ou ça, on ne sait pas trop ou le mettre sans tout réorganiser. Avec le recul de 20 ans sur GIMP, j'aurai plutôt du écrire "en manque d'amour" que "mal pensée".
Réorganiser, simplifier, aligner, polisher seraient à mon avis plus bénéfique à court terme au projet que : optimiser, claquer "de la fonctionnalité de la mort", ajouter des réglages.
[^] # Re: Traduction approximative
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche GIMP 2.10.14 et 2.10.18 : sans limites. Évalué à 10.
Il me semble que les devs de GIMP ont aussi une lourde responsabilité.
Voila plus de 20 ans que je vois GIMP s'améliorer sans cesse, techniquement un sacré travail et surtout une grande détermination à ajouter sans cesse de nouvelles fonctionnalités qui ont de quoi balayer Photoshop. Et je vous adore pour ça.
Par contre, les lourdes critiques sont liées au revers de cette médaille : massacre en règle de l'ergonomie, peu d'écoute des retours constructifs, UI mal pensée et encore moins bien réalisée.
N’empêche que j'aime bien bien ce projet et un supporter du projet.
A chaque téléchargement de GIMP, je me dis "allez c'est bon, ils ont du faire le tour des fonctionnalités, ils ont bien du prendre un peu de temps pour repenser l'interface du logiciel", mais non, alors je patiente sans trop râler :)
Retour d'un graphiste qui juge GIMP sur un simple screenhot de son UI :
(pour quand vous aurez le temps ou l'envie de régler le problème n°1 de GIMP : l'UI )
De haut en bas:
Drop Shadow (en titre), Drop Shadow en sous titre, un machin tronqué sans raison "Drop… 27 (Untitled) : on peut pas faire mieux ? A quoi il sert ce logo à gauche? et la preview de 4mm x 3mm, elle sert à quelque chose en l'état?
Presets : pourquoi un ":" ? Icônes minuscule pas vraiment parlantes.
X : "X" collé à gauche, marge à revoir, de plus le "slider" est plus au que les autres widget. Le fait de mettre le label (X) dans le widget casse la logique de l'interface.
Clipping : un combo avec un look encore différent
Preview / Split : bizarre ce Split qui part à droite
Help & reset: des icônes discrètes seraient suffisantes
Polices : choix : bof, rendu de police: beurk
A comparer par exemple à :
Bref, si un jour vous avez le temps!
[^] # Re: Pluriels et internationalisation
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Sortie de Tryton 5.6. Évalué à 3.
i7 c'est la version 17, évolution mineure de la 16, mais version à repayer totalement car "nouvelle version révolutionnaire" même pour ceux qui payaient la maintenance avec mise à jour depuis 10 ans.
Enfin… de ce que j'ai compris…
Sage c'est aussi les spécialistes du "c'est aux autres de faire", sur Coala, la seule réponse de la hotline c'est de restaurer depuis une sauvegarde, même quand l'export FEC déconne, quand la balance n'est pas juste, quand ça crache à l'impression… c'est d'ailleurs assez marrant de voir que l'on nous confie la "maintenance" de Sage en plus de la maintenance d'OpenConcerto dans les cabinets comptables qui utilisent les deux.
[^] # Re: Usine à gaz
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Audit du code source de Parcoursup par la Cour des comptes. Évalué à 3.
De ce que je peux en dire, de la fenêtre OpenConcerto, c'est que l'ORM gère la vie de données manipulées (création, modification et archivage) ainsi que les "listes".
OLAP ne servant qu'à faire du reporting dynamnique, cad à travers une interface graphique qui va créer une requête MDX qui sera exécutée par le moteur OLAP, nul besoin de passer par l'ORM.
Donc, au final, pas de SQL ou MDX "en dur".
[^] # Re: Pluriels et internationalisation
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Sortie de Tryton 5.6. Évalué à 2.
Sage Ligne 100, de mémoire, la version avant l'arnaque "version i7".
[^] # Re: Usine à gaz
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Audit du code source de Parcoursup par la Cour des comptes. Évalué à 6.
Un ERP utilise généralement un ORM ou un framework pour ne pas à avoir à maintenir du SQL.
[^] # Re: Analyse statique
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Audit du code source de Parcoursup par la Cour des comptes. Évalué à 10.
Faut pas trop en demander à 'Orange Cyberdéfense', pour un audit à moins de 200 millions d'euros (enfin j’espère ;) )
Plus sérieusement, quand un audit se termine par un tableau de notes de 1 à 4… on sait qu'il est raccord avec la qualité du code.
[^] # Re: Pluriels et internationalisation
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Sortie de Tryton 5.6. Évalué à 4.
De ce que l'on voit à travers OpenConcerto, ce n'est pas tant le "deni" que l'impuissance des discours commerciaux face à problèmes techniques qui est frappant.
On a eu le cas de clients qui ont voulu mettre à jour leur logiciels Sage, on leur a annoncé que la migration des données n'était pas possible. Magiquement, on a fait le travail pour tout rapatrier sur OpenConcerto (et pour mois cher que le prix de la nouvelle licence…).
Tous les PGIs libres sont capables de migrer les données Sage, mais pas Sage?
Le marché change très doucement, je pense que l'inertie n'est pas prête de diminuer, car les investissements et les habitudes freinent.
Il faudra à mon avis attendre au moins 10-15 ans pour que les chiffres d'affaires des gros éditeurs baissent significativement et qu'ils bougent. Sûrement à coût de rachats de solution open-source. Wait & See.
[^] # Re: L'écosystème JavaScript était trop simple
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Sortie de Deno 1.0. Évalué à 10.
On sait tous que le monde JS n'existe plus car bientôt remplacé par le monde "ES.Next", où les performances et les architectures de pointes associées, vont amener l’écosystème Web à un niveau jamais atteint d'excellence.
Les dernières études montrent que l'architecture se montrera capable de choses surprenantes et inatteignables pour "l'ancien monde". En effet, sur un cluster de machines virtuelles, chaque fonctionnalité sera déployée en tant que container muni d'un compilateur JIT haute performance. Le tout redondé et auto-configuré par un ordonnanceur de type 4.
Une telle architecture pourra permettre de gérer jusqu'au 1 million de requêtes HTTP/2 par an avec une garantie de traitement des requêtes porté à 99.9% avec seulement 5 serveurs!
[^] # Re: Formatage automatique
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Robert, un logiciel de stockage en mémoire vive. Évalué à 2.
G1 a encore quelques parties du GC qui requièrent de tout stopper, mais rien à voir avec les premiers GC où tout était fait pendant la pause.
G1 : 128 Go de Heap, en moyenne 250ms
(faut tout de même y aller fort pour allouer 128Go non stop :) )
Les GC ZGC et Shenandoah font encore mieux.
ZGC : moins d'une milliseconde pour 2To…
(Voir https://archive.fosdem.org/2018/schedule/event/zgc/attachments/slides/2211/export/events/attachments/zgc/slides/2211/ZGC_FOSDEM_2018.pdf )
(on peut donc donner raison à Hazelcast pour ceux qui n'utilisent pas ZGC, et remplissent la mémoire vive leur serveur avec 2To de heap)
[^] # Re: Formatage automatique
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Robert, un logiciel de stockage en mémoire vive. Évalué à 2.
Contrairement à ce que tu penses, il est très facile de me convaincre, mais seulement avec des faits, des choses vérifiables.
En informatique on a la chance de pouvoir expérimenter à peu de frais et surtout d'avoir des systèmes complètements déterministes.
Bref, une explication technique, un bout de code, un résultat de benchmark, je suis preneur.
Un discours marketing ou un truc tiré de la "doc" d'un vendeur, non merci.
Quand Hazelcast dit que pour éviter d'avoir à utiliser plusieurs JVM (qui selon eux est un moyen d'éviter les problèmes de lags liés aux GC), ils préconisent leur solution "Hazelcast IMDG Enterprise HD", tu devrais te poser des questions.
Manque de bol, le Java et les performances, je peux t'en parler des heures (et te sourcer ou montrer par du code, tout ce que je j'avance).
En 2001 j'ai commencé à faire du Java sérieusement avec la version 1.1.8 sur de l'embarqué (settopbox) avec 8Mo de mémoire et un processeur à 50MHz (et ca tournait nickel), je n'ai jamais arrêté de faire du Java depuis (en plus de bien d'autres langages).
Hazelcast fait références aux premiers GCs qui mettaient en pause la JVM, d'où un "lag" (voir https://www.baeldung.com/jvm-garbage-collectors pour les différents GC). Le problème est réglé depuis des années, avec par exemple le GC "G1". Aujourd'hui une application qui est ralentie par un GC est une application qui alloue à tout va avec une gestion de la mémoire mal ou pas pensée du tout.
Pour les protocoles texte vs binaire, effectivement je ne pense pas être convaincu que tout un tas de projets utilisent un protocole binaire et pas texte, car ils leurs développeurs aiment la complexité et introduire des bugs dans les "clients" (argument Redis).
Pour moi, il n'y a pas difficulté à utiliser un protocole binaire, et le gain en bande passante (entre x2 et x4) et en performance est tellement important que cela permet d'en faire plus avec un même matériel ou quantité d'énergie.
[^] # Re: Formatage automatique
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Robert, un logiciel de stockage en mémoire vive. Évalué à 2.
Concernant le profiling, c'est un peu plus gris, en Java je vais préférer que tout soit dans une même JVM pour avoir une vision globale et juste (historique des threads et lock dans JProfiler par exemple).
Pour la fragmentation, au contraire, plus l'espace mémoire disponible est grand, moins elle est un problème puisque mécaniquement les espaces contigus libre sont importants.
Pour les statistiques NoSQL que tu présentes, se pose en effet la question de savoir si le nombre de drivers est lié à la simplicité du protocole.
Autre réflexion :
plus une base de données est populaire,
plus le nombre d'utilisateurs est grand,
plus le nombre d'utilisateurs de langages peu utilisés est important,
plus la probabilité qu'un développeur/utilisateur se colle à la création du driver est importante.
Encore une fois, écrire un driver pour un protocole binaire n'a rien de difficile (par rapport à un protocole ascii) si le protocole est documenté.
De plus tu n'as (quasiment) jamais à le faire car les principaux langages ont tous leurs drivers officiels.
J'avais envie de te dire que le fait que le driver VB n'existe pas pour MongoDB, n'est un manque pour personne, mais en fait, ce driver existe (https://consulity.net/content/consulity-InstallMongoDB.aspx), idem pour Cassandra. Les chiffres sont donc à ajuster.
De plus, sachant qu'il n'y a pas de driver pour COBOL pour ces bases NoSQL, quelle corrélation y vois tu?
[^] # Re: Formatage automatique
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Robert, un logiciel de stockage en mémoire vive. Évalué à 2.
Oui, assurément mais, à mon humble avis, tu vas un peu loin sur les aspects de gestion de la vieillesse des systèmes, des aspects légaux,… tu as le même problème avec une automobile, un jour tu ne trouves plus les pièces, elle doit respecter des contraintes légales de sécurité…
Et vu le nombre de logiciels dans ma voitures, dois-je conclure que je fais de l'informatique en l'utilisant?
N'est ce pas dangereux si ce cache n'est pas persistent?
N'est ce pas dangereux si ce cache n'est pas transactionnel?
Tu parles toujours d'un service de cache comme Robert/Redis ?
[^] # Re: Formatage automatique
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Robert, un logiciel de stockage en mémoire vive. Évalué à 3.
Oups, encore quelques nouveaux points que je ne comprend pas:
Du coup, dans ce cas, les performances apportées par le service de cache ne serviront à rien car un cache local ferra le boulot, non?
A quoi fais tu référence? Les performances sont meilleures si l'on utilise les processus à la place des threads, où de stabilité, de consommation mémoire ?
Je loupe surement quelques choses, car il "semble" (https://eli.thegreenplace.net/2018/measuring-context-switching-and-memory-overheads-for-linux-threads/) que les threads sont plus rapides à démarrer que les processus, et le temps de "context switch" est plus court pour les threads.
Il est possible de le faire en PHP, voir https://www.php.net/manual/en/book.shmop.php
Pourquoi pas, en effet (souvent les caches c'est le premier truc que tu veux virer au démarrage d'une appli pour être dans un état connu,donc à priori, stable).
Oui, mais on sort du cas "1 serveur", mes remarques n'étaient que sur ce cas d'utilisation.
On est bien d'accord qu'un cluster, Redis/Robert ont leur utilité.
Ce "problème" (ou "faux problème"), tu l'as pour les bases de données sous le nom de "driver" JDBC/ODBC/etc… développés et fournis par les développeurs des bases de données.
[^] # Re: Super
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Installer BorgBackup sur un NAS. Évalué à 2.
Borg est sans conteste LA solution à mettre en place pour qui cherche une sauvegarde cryptée.
C'est important de désactiver la compression au niveau ssh, les données chiffrées sont quasi incompressibles si le chiffrage est bon, inutile donc de ralentir le transfert pour rien (vu que les processeurs de NAS sont rarement très véloces).