Après y a aucun commentaire sur le choix des noms au départ...
Peut-être que March 1 ça veut dire quel que chose en anglais...
Et nommer un gène de cette façon n'était peut être pas l'idée du siècle, indépendamment d'excel...
Version imprimable
Après y a aucun commentaire sur le choix des noms au départ...
Peut-être que March 1 ça veut dire quel que chose en anglais...
Et nommer un gène de cette façon n'était peut être pas l'idée du siècle, indépendamment d'excel...
Je ne sais pas de quoi tu parle, mais le commité de nomenclature en question est infiniment plus pertinent que quiconque ici pour choisir leur nom. Ce ne sont pas des politiques qui doivent prendre des décisions sur tout un tas de domaine, mais bien un commité d'expert reconnu qui agit sur son domaine d'expertise. Domaine qui n'est probablement pas le notre.
Tu as le contenu de leurs discussions? Tu connais leurs usages ? Tu sais comment était choisi la nomenclature précédente ? Tu sais pourquoi est-ce que c'est de cette façon qu'ils l'ont faite évoluer ?
Garde les pieds sur terre, il y a de l'informatique partout ce n'est pas pour ça que nous sommes expert en tout.
Si nous connaissions plus précisément leurs usages on pourraient parler de la solution technique la plus approprié, mais d'une part ce n'est pas le cas, d'autres part il est probable qu'Excel ne soit pas le seul élément qui ai poussé dans le choix de changer la nomenclature.
Il se comporte comme Microsoft l'a prévu. La norme c'est quelque chose qui va paraître potentiellement très différent d'une personne à l'autre, d'un contexte à l'autre.
Tu as déjà des utilisateurs qui ne connaissent pas la possibilité (on en voit plus haut dans le thread par exemple) et des utilisateurs qui ont des comportements de contournement. C'est normale que « tu vois d'ici la tête des utilisateurs » puisque c'est la situation actuelle.
Tu te propose de répliquer ta macro sur tous les environnements des utilisateurs de cette nomenclature ?
Laisse tomber. Il n'a aucune idée des besoins des généticiens mais il sait comment ils devraient travailler :marteau:
Si tu veux une vraie discussion qui ne se résume pas à "les généticiens sont des nuls qui ne savent pas utiliser excel", regarde plutôt les forums anglo-saxons : https://news.ycombinator.com/item?id=24070385.
Et c'est la qu'intervient la BI , le marketing, la gestion, la compta-finance ... Combien de services tributaires des DSI qui eux même ont aussi des besoins IT très poussés ?
Même la R&D en fait parti , donc la problématique des généticiens / scientifiques, pas besoin de tirer sur l'ambulance .
:roll: Comment peux-t-on faire plus ridicules que ça...
C'est sûr que c'est leur dire "comment ils devraient travailler", que d'affirmer qu'il est possible d'importer des CSV dans Libre Office, ou qu'il y a une pléthore de solutions techniques (ce qui est de notre domaine), à leur problème. Ou même de dire qu'un tel renommage risque de leur péter à la gueule quand ils utiliseront des outils développé à des moments différents n'utilisant pas les mêmes terminologies...
Pour reprendre notre exemple, c'est le commercial qui va se plaindre parce que le mécano lui dit qu'il peut regonfler ses pneus plutôt que d'acheter une nouvelle voiture... C'est sûr le mécanicien "n'a aucune idée des besoins des commerciaux, mais il sait comment ils devraient travailler"...
:fou:
Ah c'est bien de nous balancer le lien sans rien de plus... j'ai lu les premiers messages, et donc ? Que disent-ils de plus que nous ici ?
Ce n'est pas "une" personne qu'il suffit de former mais mais un ensemble extrêmement varié d'individus venant d'horizon divers de tous âges. D'ailleurs ils n'utilisent surement pas tous Excel mais le biologiste lambda a fort probablement sur son ordinateur Excel surtout ceux étant les moins "geeks".
Le format .csv est utilisé car il est le plus "universel". Oui tu peux expliquer à une ou deux personnes comment ouvrir correctement ce fichier mais il est certain que tu n'arriveras jamais à le faire aux 100 milles autres. De plus il est vain d'expliquer un concept "d'exporter" à des non-initiés. 99% de leur utilisation d'Excel ne l'oblige pas. Le moment où ce serait nécessaire ils n'y penseront plus alors que le logiciel ouvre les .csv tout seul, qu'ils ne doivent même pas voir l'extension et savoir que c'est un .csv :aie: C'est une gymnastique d'informaticien de penser à cela.
AMHA, quelque soit le logiciel, il ne devrait pas forcer le typage de valeurs ni la modification d'un fichier source sans demander à l'utilisateur. C'est pour moi des fautes élémentaires de conception... mais je fais p'être trop mon informaticien et qu'il y a des raisons valables d'utilisation pratiques :aie:
Conclusion je suis 100% avec SimonDecoline :mrgreen:
Bonjour
Pour avoir été bioinformaticien, je ne comprend pas ce point pour cette histoire.
Les bioinformaticiens passent leur temps aussi à stocker dans des bases de données des gènes, des protéines, des fonctions...
Excel, c'est le couteau suisse du biologiste. La plupart du temps, ils s'en servent pour faire des statistiques et du graphe. La culture informatique n'est pas si développé en biologie et vous seriez étonnés de voir les pratiques logicielles dans les labos, fussent-ils publics ou privés.
Bref, la bioinformatique, outre l'aspect recherche, essaie également de remédier à ces défauts en fournissant un panel d'outils et de bases de données afin d'aider le biologiste dans sa recherche (homologie de séquences ou de fonctions, réseaux) ou dans le workflow (scripts, logiciels). En bioinformatique, Excel n'est qu'un logiciel de visualisation de données.
Toujours est-il que de voir qu'une mauvaise utilisation logicielle impacte une convention de nommage de gènes me fait mal à ma biologie. On m'a toujours appris qu'un nom de gène, c'était en minuscule et italique, par exemple: sema3f. Donc, on nous demande de changer parce que l'enseignement informatique des outils de base est insuffisant? Cherchez l'erreur. En parlant bases de données génomiques et protéiques, devra t'on alors reprendre toutes les bases pour changer les noms de bases? Ca promet de belles heures de Data Management.
@++
bah non justement, tu ne fais visiblement pas assez ton boulot d'informaticien, tu ne regardes pas l'historique de l'application, tu ne regardes pas qui sont en majorité tes clients, tu ne veux/peux pas former/éduquer les gens avec la solution à leur problème, etc., etc.
c'est en tout cas assez marrant d'entendre ça de membre d'un camp qui a souvent tendance à dire qu'il faut apprendre pour pouvoir avoir accès à la concurrence non microsoft, mais là, il ne faudrait subitement plus apprendre? XD
ou alors qu'il ne faut pas apprendre la solution à ce problème de formatage mais passer à libre office?
qu'il faut changer le comportement d'un logiciel, et donc éduquer ceux qui comptent sur ce comportement un nouveau fonctionnement parce que sûrement une minorité ne veulent pas apprendre de leur coté une solution à leur problème?
ce qu'il serait cool ça serait d'avoir une logique dans la solution et son application, et pas des paroles à géométrie variable, là on aurait sûrement une discussion efficace ...
Alors déjà je ne fais parti d'aucun camp car ce n'est pas mon délire les guégerres PSG/OM. Par contre toi si tu en vois, c'est que tu ne peux t'empêcher de te sentir appartenir à un camp. Dans ce cas essaie de prendre conscience que ta demande de discussion efficace n'est qu'une chimère de ta part car par définition un supporter n'est pas une personne objective ;)
https://www.youtube.com/watch?v=0Wfc...?v=0WfcgfGTMlY
La majorité des clients n'utilisent surement pas le format ".csv" par défaut.
Tout doit être extrême avec toi ! :mouarf:
Simplement que le logiciel à l'ouverture d'un .csv indique "le logiciel interprète la colonne 42 comme un champ de dates, êtes vous d'accord pour la conversion ?
Ce n'est pas la mer à boire quand même
blah blah blah blah blah, ho purée, c'est pareil ... ha non, il manque les violons.
et donc ça doit te soustraire d'apprendre à utiliser le logiciel? quelle blague.
"le logiciel interprète la colonne 1 comme un champ de truc, êtes vous d'accord pour la conversion ?"
"le logiciel interprète la colonne 2 comme un champ de truc, êtes vous d'accord pour la conversion ?"
...
"le logiciel interprète la colonne 42 comme un champ de truc, êtes vous d'accord pour la conversion ?"
il n'y a que moi qui voit la stupidité qu'aurait le logiciel à demander pour chaque colonne si on souhaite une conversion (car techniquement ça pourrait être le cas, hein!) ?
alors que l'utilisateur, qui sait qu'il a une ou plusieurs colonnes problématiques, peut déployer le fix pour son utilisation spécifique, ça ne serait pas plus simple?
c'est affligeant ...
de plus, même dans les grandes entreprises, il est toujour fait usage de quelques services gratuis ...et dans leur version gratuit, ces services limitent souvent les export au format JSON, laissant le choix de CSV pour les payeurs (ex : Trello).
Sinin, je suis amené à parfois utiliser LibreOffice 5.2 sur une vielle machine. Quand je fait [ctrl + a] --> formater des cellules --> texte --> valider
il se trouve que le texte est systématiquement interprété... je doit appliquer le format 2x pour avoir le bon comportement, parfois les cellules doivent avoir du contenu pour que ça marche.
Avez-vous vous aussi rencontré ce bugg de LO ou MO ?
Ca rend seulement ton argumentation "ne pas embêter la majorité de gens" caduque
Voilà voilà... c'est dommage que tu ne saches prendre que la voie de caricaturer les propos de tes "adversaires imaginaires".
Enlève trois secondes ton maillot de supporter et constate que ce que tu viens de travestir est simplement ce que fait la boite de dialogue d'import d'Excel.
Elle permet de faire tout ce que tu viens de dire mais en plus ergonomique et en un minimum de cliques suivant les besoins (voir qu'un seul avec la conversion classique)
Qu'Excel (ou autre) fasse de même avec l'ouverture directe d'un cvs ne semble pas si absurde.
la majorité des gens qui comptent sur cette fonction ont appris à savoir qu'elle existe et qu'ils peuvent compter dessus, pas le contraire. donc perdu, revois ton "argumentaire"
la boite de dialogues excel est là justement pour contrer le comportement par défaut, mais bon, tu montres juste une fois de plus la malhonnêteté caractéristique des gens dans ton genre : c'est ce qu'on dit depuis le début, il y a une solution simple pour contrer le problème, et ces gens n'ont, encore une fois de plus, qu'à apprendre à utiliser le logiciel.
donc, encore perdu, et si je dois enlever mon maillot de supporter, je te conseille de ton coté d'allumer ton cerveau (la poutre qu'on ne voit pas dans son œil, tout ça...), tout ce que tu viens de raconter confirme ce qu'on dit depuis le début : le comportement par défaut ne convient pas à ces gens MAIS il y a tout ce qu'il faut pour contourner ce comportement, suffit juste d'apprendre à utiliser le logiciel.
ps: c'est quand même magique, le problème n'aurait pas de solution, je pense que n'y aurait pas grand monde pour ne pas dire que c'est débile et qu'il faut faire quelque chose, mais là, il y a une solution (voir des, merci aux contributeurs pour les avoir mises en évidence), pas beaucoup plus difficile à mettre en œuvre en plus et tu as quand même des gens pour chouiner "mais ça fait pas selon MOI ce que je veux". on est pas dans la merde ...
ps2: et admettons que demain à l'ouverture de csv, microsoft fasse ce que vous voulez, vous répondrez quoi aux gens qui pourront légitimement vous demander "pourquoi vous avez changer le comportement par défaut? ce nouveau comportement ne m'arrange pas!" ?
Je le redis, ce serait semblable à la boite de dialogue de l'option import. Par défaut les colonnes sont typés avec le comportement par défaut.
Donc tu penses sérieusement que cela ne les arrangerait pas de devoir cliquer sur un bouton [OK] (seulement UN !) par rapport à leur habitude ?
D'ailleurs je penses même l'inverse, tous ces gens le jour où ils seront confronter (même très rarement) à un .csv différent où le typage en aura trop fait, sauront plus instinctivement comment le corriger.
Car c'est sûr que ça va pas leur venir naturellement qu'il faille effectuer le cheat code haut bas gauche droit juste pour ça. Mais bon pour toi c'est ce que tu appelles apprendre à se servir d'un logiciel :aie:
Ta proposition a du sens, et certainement en entreprise, et d'ailleurs d'autres logiciels très orientés "user" font la même chose.
Mais dans ce cas elle obligerait encore et toujours les utilisateurs à redire et redire encore A CHAQUE OUVERTURE de csv, que non, March 1 n'est pas March 1st
Donc la seule solution au problème de base c'est se rendre que March 1 était un nom pourri, qu'il fallait le changer et c'est ce qu'ils ont fait.
Perso, je ne vois pas pourquoi March 1 est un nom pourri. On ne peut pas devoir tenir compte d'Excel pour nommer ce que l'on a envie de nommer.
Pour aller dans le sens d'une boite de dialogue qui s'ouvrirait à l'ouverture du CSV, les concepteurs d'Excel pourraient à moindre coût le proposer dans les options de l'application. Une simple case à cocher pour que l'utilisateur décide du comportement par défaut à l'ouverture d'un CSV. Ca me semble faisable à moindre coût, non contraignant pour les utilisateurs habitués au fonctionnement habituel et qui permettrait à celles et ceux qui le veulent d'obtenir cette boite de dialogue à l'ouverture de leurs CSV. Perso, je ne comprends même pas comment ils n'y ont pas encore pensé.
Et là où je rejoins ijk-ref et d'autres, c'est que le CSV est par nature régi par une grammaire syntaxique et non sémantique, et donc que le comportement par défaut devrait être une analyse syntaxique et non sémantique. Je reste cependant persuadé, comme je l'ai déjà dit, que la formation à l'utilisation des CSV dans Excel est quelque chose qui est loin d'être insurmontable, et qu'il existe aujourd'hui pléthore de tutos et de vidéos qui expliquent comment fonctionner. Modifier des codifications internationalement reconnues parce que l'on ne sait pas se former sur le tas, en 2020, c'est vraiment du n'importe quoi.
Rien à voir avec Excel ! Le nom était pourri à cause du conflit avec l'anglais.
Et non former les utilisateurs n'est PAS la solution, puisque dans un cas comme dans l'autre (reconnaissance automatique ou pas), l'autre moitié des utilisateurs ne sera pas contente.
Certes moins il y en a mieux c'est. Mais pour moi quelque soit le logiciel, s'il fait une "interprétation" d'un fichier au lieu de seulement l'ouvrir, c'est une "erreur" de ne pas prévenir l'utilisateur.
Sinon dans notre cas spécifique, tu penses sérieusement que ça peut faire perdre des clients à Excel ce détail sur les fichiers .csv ? :lol:
Ce qu'il faut faire aussi en passant par l'option import. Mais là au moins on y arrive plus directement. Et puis la boite de dialogue pourrait aussi proposer de sauvegarder les interprétations retirées par défaut.
Sinon, j'y pense que maintenant là, mais à quel moment "March1" peut être bien interprété dans un fichier !?
Quand nous le rentrons directement dans une cellule du logiciel, ok il va l'interpréter le 1er mars le plus proche du jour. Par contre dans un fichier... il va mettre quelle année ?
T'ouvres un fichier en décembre 2020, il te transforme ça en "1 mars 2020", tu l'ouvres en janvier 2021 il te transforme ça en "1 mars 2021"
C'est ça non ? Qui peut s'attendre et souhaite une telle interprétation ?
Bien sûr, sauf qu'il faut aussi se mettre à la place des gens qui ouvrent leurs fichiers .csv en cliquant directement dessus ou via l'option ouvrir. Donc naturellement ils s'attendent à quelque chose de ce coté là.
Pour en revenir aux essuies glaces automatiques, si pour une raison x ou y quelqu'un souhaite retirer l'automatisme, il est bien plus naturelle de placer un anneau on/off sur le comodo de l'essuie glace... que de placer un bouton sous la roue de secoure dans le coffre. C'est sûr que beaucoup ne vont pas trouver tout seul... même si c'est écrit dans le manuel de l'auto