#21
#21
Pas mal, tu nous feras une petite démo quand ça sera fini ? 
C'est pas mal effectivement
C'est pas mal effectivement
-
Rechercher un sujet
#22
Pas mal, tu nous feras une petite démo quand ça sera fini ?
C'est pas mal effectivement
C'est pas mal effectivement
#23
Je chipote beaucoup pour le moment, j'avais pensé à un truc dans l'espace.
Sinon en fait dans Unity, le truc génial c'est ce fameux "Debug.log ();".
Cette ligne toute bête affiche du texte dans la console.
Sauf que tu peux mettre genre n'importe quoi dedans comme variable, et surtout tu peux la mettre n'importe où dans ton code (et voir en fonction de si elle s'affiche ou pas voir où ça débloque)
Cette ligne m'a déjà sauvé beaucoup de temps.
Sinon en fait dans Unity, le truc génial c'est ce fameux "Debug.log ();".
Cette ligne toute bête affiche du texte dans la console.
Sauf que tu peux mettre genre n'importe quoi dedans comme variable, et surtout tu peux la mettre n'importe où dans ton code (et voir en fonction de si elle s'affiche ou pas voir où ça débloque)
Cette ligne m'a déjà sauvé beaucoup de temps.
Pour moi, et par expérience, les règles d'un "bon" développement sont à raisonner selon deux cas
- La maintenance d'un existant
- La création totale
Les deux semblent identiques (du code, et du code)... sûrement pas: avec l'existant il faut tenir compte de ce qu'il y a déjà, et ce même si c'est pourri. Donc, il est fondamental de bien comprendre ce qu'on doit faire, et surtout ce que fait l'existant.
Quand on crée de zéro, là il y a trois aspects fondamentaux à mettre en oeuvre:
- On part du plus simple pour enrichir. Inutile de se disperser de suite, cela ne peut qu'être chiant à contourner par la suite
- Ne mettre que les données indispensables au départ, puis enrichir les données au fil des besoins
- Toujours bien raisonner le format et/ou la structure des données qu'on traite. En faisant de mauvais choix, on peut vite regretter des choix de conception antérieurs.
A partir de là, il y a la structuration du code
- Prévoir un maximum de petits "services" vitaux de partout (par ex. mettre en place des méthodes de gestion des dates pour les réutiliser de partout). Personnellement je crée toujours une boite à outils (toolbox) qui me liste des dizaines de trucs plus ou moins évolués
- Construire l'application avec à l'esprit qu'on peut l'enrichir, donc en découpant les fonctionnalités en modules
- Se méfier énormément des méthodes trop longues: si le code devient trop verbeux, c'est qu'il y a soit de la mutualisation de code possible, soit que l'algorithme est devenu trop complexe/mal fait. Les cas où les règles sont bien trop complexes signifient qu'on les regarde mal. Il y a toujours des choses qu'on peut redécouper pour s'éviter de la redondance de code.
- Intégrer dès le départ des traces pour le suivi d'exécution. Par exemple, on peut démarrer un programme avec une option "/log" qui active partout des traces écrites comme du debug.log() ou toute autre fonction du même acabit. Le but? identifier si tout fonctionne bien!
- Toujours prévoir l'imprévisible! Si on a de la donnée venant du monde extérieur au programme (ie fichiers/base de données/entrées au clavier/etc ) elle peut toujours arriver vérolée ou non cohérente. Un exemple très concret: si l'on structure des adresses, les codes postaux français sont numériques... mais bien des pays ont des codes alphanumériques. Donc, si l'on ne contrôle pas, c'est droit dans le mur au premier code postal anglais!
- Toujours prévoir des clauses d'échappement sur les traitements itératifs. ça semble idiot, mais une boucle peut vite devenir infinie si la clause de sorte n'est jamais remplie. Cela peut donner une bonne série de bugs chiants à trouver... ou des jeux à la Bethesda où l'écran se fige sans raison valable.
- Commenter le code, et donner des noms de méthodes/variables explicites! Rien ne m'horripile plus que les $toto ou les tabBidule, ou les méthodes FaitPleinsDeTrucsInutilesEtPasclairs! c'est bien simple: 90% du temps perdu en correction de bugs est lors de la relecture du code pour comprendre ce que le crétin (accessoirement c'est souvent VOUS le crétin) a fait pour rendre le code tout sauf explicite.
Et en complément
- Ne pas hésiter à documenter un minimum les méthodes créées
- Suivre les modifications via Git ou un équivalent. un bon outil de suivi de version. C'est vital pour ne pas corriger à tort, voire faire des régressions. j'aime bien gitkraken pour cette fonction, mais il y en a d'autres
- Toujours disposer de x sauvegardes annexes (c'est logique, mais combien le font vraiment?)
- En entreprise, penser à voir s'il est possible de standardiser des librairies. Plus c'est centralisé à ce niveau, moins on a de boulot par la suite... mais ça, c'est du domaine du rêve, car cela requiert de la rigueur et du temps pour rédiger un wiki dédié. Donc c'est du "bonus".
- Toujours penser à faire des tests pas uniquement en unitaire avec les données qui conviennent bien, mais avant tout qu'avec des données réelles (du client), ou dans des conditions dégradées pour s'assurer que tous les cas (si possible) sont couverts.
#24
Chouette résumé. 
Peut-être pourrais-tu rajouter quelques réflexions sur un chapitre pas si indépendant que ça, celui des BDD ? Quant aux applications interactives, en dehors du débogage, ne jamais faire soi-même les tests et encore moins les valider : la façon qu'ont les utilisateurs de les appréhender est souvent étonnante (prévoir l'imprévisible, dis-tu !).
Peut-être pourrais-tu rajouter quelques réflexions sur un chapitre pas si indépendant que ça, celui des BDD ? Quant aux applications interactives, en dehors du débogage, ne jamais faire soi-même les tests et encore moins les valider : la façon qu'ont les utilisateurs de les appréhender est souvent étonnante (prévoir l'imprévisible, dis-tu !).
#25
Chouette résumé. Peut-être pourrais-tu rajouter quelques réflexions sur un chapitre pas si indépendant que ça, celui des BDD ? Quant aux applications interactives, en dehors du débogage, ne jamais faire soi-même les tests et encore moins les valider : la façon qu'ont les utilisateurs de les appréhender est souvent étonnante (prévoir l'imprévisible, dis-tu !).
Peut-être pourrais-tu rajouter quelques réflexions sur un chapitre pas si indépendant que ça, celui des BDD ? Quant aux applications interactives, en dehors du débogage, ne jamais faire soi-même les tests et encore moins les valider : la façon qu'ont les utilisateurs de les appréhender est souvent étonnante (prévoir l'imprévisible, dis-tu !).
Chose que je ne peux pas réellement faire. ..
Demander à quelqu'un de tester...
#27
#27
Salut !
Je viens un peu aux nouvelles, j'ai toujours pas pu le commencer, j'ai commencé le boulot saisonnier en restaurztion et je fais des horaires de dingues, le seul temps libre que j'ai c'est pour dodo..... j'ai pas oublié j'essais de le faire quand j'ai un moment.......
Merci de votre compréhension les gars !
Je viens un peu aux nouvelles, j'ai toujours pas pu le commencer, j'ai commencé le boulot saisonnier en restaurztion et je fais des horaires de dingues, le seul temps libre que j'ai c'est pour dodo..... j'ai pas oublié j'essais de le faire quand j'ai un moment.......
Merci de votre compréhension les gars !
#29
Salut !
Je viens un peu aux nouvelles, j'ai toujours pas pu le commencer, j'ai commencé le boulot saisonnier en restaurztion et je fais des horaires de dingues, le seul temps libre que j'ai c'est pour dodo..... j'ai pas oublié j'essais de le faire quand j'ai un moment.......
Merci de votre compréhension les gars !
Je viens un peu aux nouvelles, j'ai toujours pas pu le commencer, j'ai commencé le boulot saisonnier en restaurztion et je fais des horaires de dingues, le seul temps libre que j'ai c'est pour dodo..... j'ai pas oublié j'essais de le faire quand j'ai un moment.......
Merci de votre compréhension les gars !
#30
Chouette résumé. Peut-être pourrais-tu rajouter quelques réflexions sur un chapitre pas si indépendant que ça, celui des BDD ? Quant aux applications interactives, en dehors du débogage, ne jamais faire soi-même les tests et encore moins les valider : la façon qu'ont les utilisateurs de les appréhender est souvent étonnante (prévoir l'imprévisible, dis-tu !).
Peut-être pourrais-tu rajouter quelques réflexions sur un chapitre pas si indépendant que ça, celui des BDD ? Quant aux applications interactives, en dehors du débogage, ne jamais faire soi-même les tests et encore moins les valider : la façon qu'ont les utilisateurs de les appréhender est souvent étonnante (prévoir l'imprévisible, dis-tu !).
Cela peut effectivement faire l'objet de deux réflexions distinctes concernant les bases de données et l'utilisation des applications interactives.
Je vais voir si je m'en donne le temps et les moyens pour y répondre, car ce sont des sujets très délicats à manipuler. Quand on en parle, on peut très vite égarer les auditeurs, et pire que tout les mener à comprendre de travers certains concepts, et donc les envoyer sans le vouloir dans le mur lors de la mise en pratique.
#31
Allez hop, quelques réflexions générales sur ce que sont les interfaces utilisateur et les bases de données. Il y a là deux domaines très différents, et chacun a ses problématiques et ses règles. Contrairement au développement, ce sont là des choses qui méritent nettement qu'on se penche sur le sujet de manière totalement dissociée. Alors, je vais faire deux chapitres séparés pour que l'on ne mélange pas les réflexions.
#32
L'interface utilisateur
Quelques rappels
Tout d'abord, il faut tordre le cou à une idée préconçue: l'interface utilisateur, c'est tout ce qui permet d'interagir avec le système. Il n'y a pas que la gestion à al souris qui est une interface, le shell sur n'importe quel OS est aussi une interface utilisateur. Donc, en partant de ce postulat, il faut clairement grossièrement distinguer quatre types d'interfaces:
- Celles pilotées par lignes de commande
- Les interfaces utilisant le clavier/souris en mode "bureau" ("desktop")
- Les interfaces tactiles qui sont très particulières
- Les interfaces "autres" qu'on peut rencontrer dans les jeux par exemple (tactiles ou non). Je reviendrai plus spécifiquement sur ce dernier point.
Une fois qu'on a défini celle sur laquelle on veut travailler, on va réfléchir sur un terme fondamental: l'ergonomie.
L'usage
Evacuons immédiatement la question: chaque mode a ses avantages et inconvénients. C'est fondamental de réfléchir sur le choix qu'on va faire. Il peut être bien plus judicieux de faire une application en ligne ce commande qu'en mode graphique... Tout dépend du périmètre d'utilisation! Il faut immédiatement exclure le faux prétexte du "avec la souris c'est plus accessible". Un outil développé en ligne de commande peut avoir pour besoin d'être employé uniquement dans des conditions "root" sur le système, hors de portée de l'utilisateur, ou bien carrément sans interface tout court (service) que l'utilisateur n'a même pas à connaître. C'est un choix à arbitrer avant même de se lancer dans le développement.
nota: et si l'on bosse vraiment bien, on peut faire en sorte que l'outil en shell puisse être appelé en mode graphique afin que ses fonctionnalités deviennent exploitables depuis des menus/écrans dédiés. Cette solution est idéale car elle répondra à des problématiques aussi bien professionnelles que dans des domaines plus "utilisateur". (N'oubliez jamais qu'un serveur en production a très rarement un bureau, et l'immense majorité de ces machines sont administrées en lignes de commande. Le but? Les configurer une fois pour toute puis on ferme la boite "à tout jamais")
L'interface graphique "bureautique" (ou "GUI")
C'est quoi donc "GUI"? C'est l'acronyme pour "Graphical User Interface".
En résumé? C'est la partie utilisable par une personne pour piloter un programme depuis une présentation graphique. On est donc là face à tout ce qui représente un programme informatique appelé sur un bureau d'un OS.
Pour quoi faire et comment organiser
Entrons dans le "dur". Les programmes comme Photoshop, Word, mais également 7Zip, les menus de paramétrage Windows, toutes ces applications sont des GUI. Donc, déjà, on peut repérer l'étendue des ergonomies et des organisations de l'information, ainsi que la multitude de façon de les mettre en place à l'écran.
Il est donc évident que donner une bonne pratique n'a aucun sens. Chaque vision de l'ergonomie fait sens, dès lors qu'elle répond au besoin. Pour prendre une exemple, chaque période de l'histoire de Windows a donné lieu à une vision de l'ergonomie. Quelqu'un qui a un historique dans le monde Windows pourra en un coup d'oeil repérer la période de création d'un programme... parce que les environnements de développement sont à chaque fois dans l'air du temps en terme de présentation et d'esthétique.
De ce constat quelque peu pénible, il faut alors raisonner en ces termes:
- Je présente quoi
- Combien d'informations vont être à l'écran
- Quel est le style actuel
- Est-ce qu'il y a des règles immuables
- Comment rendre le tout lisible et confortable à l'usage
Ces cinq questions sont fondamentales. Elles déterminent à peu près tout le ressenti utilisateur. Si une seule de ces questions demeure irrésolue, l'utilisateur final sera au mieux un peu frustré, au pire il rejettera le produit en l'estimant laid/non pratique/mal fait.
Nota: l'ordre n'est pas celui des priorités. Selon le périmètres, on fera en sorte que ce soit plus joli qu'autre chose, et réciproquement s'il y a énormément de choses un aspect aride mais efficace sera la bonne solution.
Comment organiser et présenter la donnée
Répondons aux différentes questions précédemment posées....
Et faisons un parallèle avec le jeu vidéo! Paradoxalement, c'est plus simple d'appréhender les problèmes via les jeux vidéo, car ils font le maximum (en général) pour respecter les questions d'ergonomie et simplifier la vie du joueur.
Si un jeu qui est utilisé via une manette est accessible, c'est qu'il a été pensé pour!
Donc, pour saisir les concepts ergonomiques, l'idéal est de les faire comprendre via le jeu. Faire ce même rapprochement avec un outil comme Photoshop, car ce style d'outil requiert une certaine expertise, et la richesse et la complexité des outils inclus rend difficile à saisir ces mêmes concepts, alors que pourtant Photoshop s'attache à être le plus exploitable avec le moins de clics possibles.
Je présente quoi
C'est le coeur du problème. On commence par se demander ce qu'on veut présenter à l'utilisateur. De là, il faut avoir le bon sens de créer une échelle de priorité. Cela semble "bizarre"? Non. Prenons un fps: l'écran de jeu global présentera les informations fondamentales au joueur, et évitera de le polluer avec des choses accessoires. Donc, on va trier ce qui est prioritaire, et mettre ailleurs ce qui l'est moins.
On hiérarchise l'information. On va du plus important au plus anodin.
Ensuite, on groupe les thèmes afin de construire une logique. Reprenons l'exemple du jeu vidéo: si on a un inventaire (RPG par exemple), le plus cet inventaire est organisé par thèmes/types d'objets, le plus le tout semble plus clair et compréhensible. Se retrouver avec un vrac bordélique peut vite devenir insupportable. Il en va de même dans une application. Si l'on prend un éditeur de textes, on va grouper les choses par thématique logique afin de simplifier la compréhension de l'utilisateur. Ce serait stupide de laisser un énorme vrac de raccourcis non triés, non groupés.
Combien d'informations vont être à l'écran
Cela a toujours fait débat. Combien de choses peuvent être appréhendées en même temps? Personnellement je n'ai pas de vraie règle ferme. L'idéal? Organisez la donnée de sorte à respecter les critères précédemment établis, puis TESTEZ. Mais pas "trois clics et hop ok ça roule". non, faites de la saisie par dizaines, vérifiez x fois que cela fait sens dans l'ordre de présentation (du style nom/prénom avant le téléphone pour un client), puis assurez-vous que les données fondamentales soient les plus visibles. Un code couleur, un encadré... cela peut changer la vie.
Quoi qu'il en soit, inutile de noyer l'utilisateur sous des tombereaux d'informations hétérogènes.
Prenons le cas d'une application gérant des clients. En créant une fiche client, on pourra raisonner par onglets, avec en premier lieu l'identité, un onglet dédié à ses adresses de livraison, un onglet à ses commandes en cours, un autre à son historique de paiement... bref, on va regrouper par thèmes et éviter de mettre 10.000 objets visibles sur le seul premier onglet.
Donc, ça se réfléchit et ça s'essaye jusqu'à trouver des compromis.
Quel est le style actuel
A moins d'être un spécialiste... Pompez! Surfez sur le net, cherchez les outils qui sont équivalents/concurrents au vôtre, et réfléchissez. S'il y a de bonnes idées, appropriez les vous et refaites les selon votre goût. Pensez également à vous approcher de la norme graphique du moment. Rien n'est pire qu'une application rejetée parce qu'elle semble bordélique ou pire encore vieillotte. Cela n'est qu'esthétique, mais c'est la seule chose que voient les utilisateurs finaux. C'est donc au moins aussi important que le côté fonctionnel.
Quelques rappels
Tout d'abord, il faut tordre le cou à une idée préconçue: l'interface utilisateur, c'est tout ce qui permet d'interagir avec le système. Il n'y a pas que la gestion à al souris qui est une interface, le shell sur n'importe quel OS est aussi une interface utilisateur. Donc, en partant de ce postulat, il faut clairement grossièrement distinguer quatre types d'interfaces:
- Celles pilotées par lignes de commande
- Les interfaces utilisant le clavier/souris en mode "bureau" ("desktop")
- Les interfaces tactiles qui sont très particulières
- Les interfaces "autres" qu'on peut rencontrer dans les jeux par exemple (tactiles ou non). Je reviendrai plus spécifiquement sur ce dernier point.
Une fois qu'on a défini celle sur laquelle on veut travailler, on va réfléchir sur un terme fondamental: l'ergonomie.
L'usage
Evacuons immédiatement la question: chaque mode a ses avantages et inconvénients. C'est fondamental de réfléchir sur le choix qu'on va faire. Il peut être bien plus judicieux de faire une application en ligne ce commande qu'en mode graphique... Tout dépend du périmètre d'utilisation! Il faut immédiatement exclure le faux prétexte du "avec la souris c'est plus accessible". Un outil développé en ligne de commande peut avoir pour besoin d'être employé uniquement dans des conditions "root" sur le système, hors de portée de l'utilisateur, ou bien carrément sans interface tout court (service) que l'utilisateur n'a même pas à connaître. C'est un choix à arbitrer avant même de se lancer dans le développement.
nota: et si l'on bosse vraiment bien, on peut faire en sorte que l'outil en shell puisse être appelé en mode graphique afin que ses fonctionnalités deviennent exploitables depuis des menus/écrans dédiés. Cette solution est idéale car elle répondra à des problématiques aussi bien professionnelles que dans des domaines plus "utilisateur". (N'oubliez jamais qu'un serveur en production a très rarement un bureau, et l'immense majorité de ces machines sont administrées en lignes de commande. Le but? Les configurer une fois pour toute puis on ferme la boite "à tout jamais")
L'interface graphique "bureautique" (ou "GUI")
C'est quoi donc "GUI"? C'est l'acronyme pour "Graphical User Interface".
En résumé? C'est la partie utilisable par une personne pour piloter un programme depuis une présentation graphique. On est donc là face à tout ce qui représente un programme informatique appelé sur un bureau d'un OS.
Pour quoi faire et comment organiser
Entrons dans le "dur". Les programmes comme Photoshop, Word, mais également 7Zip, les menus de paramétrage Windows, toutes ces applications sont des GUI. Donc, déjà, on peut repérer l'étendue des ergonomies et des organisations de l'information, ainsi que la multitude de façon de les mettre en place à l'écran.
Il est donc évident que donner une bonne pratique n'a aucun sens. Chaque vision de l'ergonomie fait sens, dès lors qu'elle répond au besoin. Pour prendre une exemple, chaque période de l'histoire de Windows a donné lieu à une vision de l'ergonomie. Quelqu'un qui a un historique dans le monde Windows pourra en un coup d'oeil repérer la période de création d'un programme... parce que les environnements de développement sont à chaque fois dans l'air du temps en terme de présentation et d'esthétique.
De ce constat quelque peu pénible, il faut alors raisonner en ces termes:
- Je présente quoi
- Combien d'informations vont être à l'écran
- Quel est le style actuel
- Est-ce qu'il y a des règles immuables
- Comment rendre le tout lisible et confortable à l'usage
Ces cinq questions sont fondamentales. Elles déterminent à peu près tout le ressenti utilisateur. Si une seule de ces questions demeure irrésolue, l'utilisateur final sera au mieux un peu frustré, au pire il rejettera le produit en l'estimant laid/non pratique/mal fait.
Nota: l'ordre n'est pas celui des priorités. Selon le périmètres, on fera en sorte que ce soit plus joli qu'autre chose, et réciproquement s'il y a énormément de choses un aspect aride mais efficace sera la bonne solution.
Comment organiser et présenter la donnée
Répondons aux différentes questions précédemment posées....
Et faisons un parallèle avec le jeu vidéo! Paradoxalement, c'est plus simple d'appréhender les problèmes via les jeux vidéo, car ils font le maximum (en général) pour respecter les questions d'ergonomie et simplifier la vie du joueur.
Si un jeu qui est utilisé via une manette est accessible, c'est qu'il a été pensé pour!
Donc, pour saisir les concepts ergonomiques, l'idéal est de les faire comprendre via le jeu. Faire ce même rapprochement avec un outil comme Photoshop, car ce style d'outil requiert une certaine expertise, et la richesse et la complexité des outils inclus rend difficile à saisir ces mêmes concepts, alors que pourtant Photoshop s'attache à être le plus exploitable avec le moins de clics possibles.
Je présente quoi
C'est le coeur du problème. On commence par se demander ce qu'on veut présenter à l'utilisateur. De là, il faut avoir le bon sens de créer une échelle de priorité. Cela semble "bizarre"? Non. Prenons un fps: l'écran de jeu global présentera les informations fondamentales au joueur, et évitera de le polluer avec des choses accessoires. Donc, on va trier ce qui est prioritaire, et mettre ailleurs ce qui l'est moins.
On hiérarchise l'information. On va du plus important au plus anodin.
Ensuite, on groupe les thèmes afin de construire une logique. Reprenons l'exemple du jeu vidéo: si on a un inventaire (RPG par exemple), le plus cet inventaire est organisé par thèmes/types d'objets, le plus le tout semble plus clair et compréhensible. Se retrouver avec un vrac bordélique peut vite devenir insupportable. Il en va de même dans une application. Si l'on prend un éditeur de textes, on va grouper les choses par thématique logique afin de simplifier la compréhension de l'utilisateur. Ce serait stupide de laisser un énorme vrac de raccourcis non triés, non groupés.
Combien d'informations vont être à l'écran
Cela a toujours fait débat. Combien de choses peuvent être appréhendées en même temps? Personnellement je n'ai pas de vraie règle ferme. L'idéal? Organisez la donnée de sorte à respecter les critères précédemment établis, puis TESTEZ. Mais pas "trois clics et hop ok ça roule". non, faites de la saisie par dizaines, vérifiez x fois que cela fait sens dans l'ordre de présentation (du style nom/prénom avant le téléphone pour un client), puis assurez-vous que les données fondamentales soient les plus visibles. Un code couleur, un encadré... cela peut changer la vie.
Quoi qu'il en soit, inutile de noyer l'utilisateur sous des tombereaux d'informations hétérogènes.
Prenons le cas d'une application gérant des clients. En créant une fiche client, on pourra raisonner par onglets, avec en premier lieu l'identité, un onglet dédié à ses adresses de livraison, un onglet à ses commandes en cours, un autre à son historique de paiement... bref, on va regrouper par thèmes et éviter de mettre 10.000 objets visibles sur le seul premier onglet.
Donc, ça se réfléchit et ça s'essaye jusqu'à trouver des compromis.
Quel est le style actuel
A moins d'être un spécialiste... Pompez! Surfez sur le net, cherchez les outils qui sont équivalents/concurrents au vôtre, et réfléchissez. S'il y a de bonnes idées, appropriez les vous et refaites les selon votre goût. Pensez également à vous approcher de la norme graphique du moment. Rien n'est pire qu'une application rejetée parce qu'elle semble bordélique ou pire encore vieillotte. Cela n'est qu'esthétique, mais c'est la seule chose que voient les utilisateurs finaux. C'est donc au moins aussi important que le côté fonctionnel.
#33
Est-ce qu'il y a des règles immuables
Oh que oui, il y en a quelques-unes. En voici les principales
- Lisibilité: rendez vos polices d'écriture uniformes, pas de variation de taille/style de police selon le sens du vent et l'écran considéré.
- Couleurs: évitez le n'importe quoi. Votre application, c'est le contact de votre utilisateur avec ce qu'il veut en faire. Evitez les teintes rendant l'écran illisible (l'ignoble rose ou le jaune fluo rendant la lecture impossible...)
Si vous avez des listes, alterner la couleur de fond entre blanc et un gris très clair peut améliorer fortement la lisibilité.
- Les colonnes des grilles: Fuyez les grilles à 50 colonnes! Ne mettez que le strict nécessaire, quitte à ajouter une fonctionnalité ligne à ligne pour avoir les détails complémentaires. S'il y a des colonnes à ajouter, n'ajoutez que le minimum afin d'épargner à l'utilisateur des écrans surchargés et imbuvables.
- FILTREZ! Ajoutez de partout des capacités de tris et de filtres. Rien n'est plus pénible que des outils de recherche mal foutus, où l'utilisateur, à force de frustration, va finir par vous créer des doublons à la pelle pour ne plus s'emmerder avec votre outil. Pensez également aux extractions de données, aux impressions de listes, bref de quoi faciliter l'existence de vos utilisateur.
- Si traitement long il y a, barre de progression tu placeras. Nous n'avons aucune patience... donc mettez TOUJOURS des barres de progression si vous savez que le traitement activé est susceptible de prendre du temps. Rien n'est pire que s'entendre dire "ça bug" alors qu'il s'agit seulement d'un manque de patience lors de l'exécution du programme.
- Maintenez une logique générale. Si le bouton "OK" est en bas à droite, il le sera PARTOUT, et pas selon votre fantaisie. Il en va de même dans l'organisation des menus.
- La prise en charge du clavier. Penser à des choses comme le copier/coller semble évident... et si vous ajoutiez des raccourcis? Par exemple fermer les fenêtres par ECHAP, F1 pour l'aide, CTRL+P pour imprimer... bref, prenez en compte la possibilité de coller des raccourcis qui facilitent la vie.
- Toujours demander confirmation de l'utilisateur quand il y a un risque de perdre de la donnée. Vous demanderez à chaque fois qu'il y a ajout/modification/suppression un acquittement. C'est le concept du CRUD (que j'aborderai dans les bases de données): Create / Read / Update /Delete.
Create: on confirme
Read: on confirme si la lecture risque de perdre une sélection précédente
Update; on confirme
Delete: on confirme et même on alerte sérieusement.
Comment rendre le tout lisible et confortable à l'usage
En respectant les aspects décrits précédemment. On expérimente soi-même en jouant l'imbécile, en saisissant à la volée énormément de données pourries, en exploitant toutes les idées les plus débiles. L'idée n'est pas de valider la partie technique, mais bien de s'assurer que tout est fait pour qu'une logique générale et un confort d'utilisation se retrouvent dans l'ensemble de l'outil.
Un dernier point
Pensez aussi.. à vous laisser des portes dérobées. C'est idiot dit comme ça, mais la plupart des outils professionnels et même des jeux disposent de portes dérobées pour la maintenance ou les tests. Dans les jeux, on a parfois accès à une console. Celle-ci, c'est le coeur réel du jeu. En connaissant les commandes, on peut changer le comportement ou étudier des anomalies. Faites-en autant dans vos outils, songez à des menus cachés/protégés afin de pouvoir intervenir, le cas échéant, en direct plutôt qu'avec l'espoir de faire une maintenance complexe.
Oh que oui, il y en a quelques-unes. En voici les principales
- Lisibilité: rendez vos polices d'écriture uniformes, pas de variation de taille/style de police selon le sens du vent et l'écran considéré.
- Couleurs: évitez le n'importe quoi. Votre application, c'est le contact de votre utilisateur avec ce qu'il veut en faire. Evitez les teintes rendant l'écran illisible (l'ignoble rose ou le jaune fluo rendant la lecture impossible...)
Si vous avez des listes, alterner la couleur de fond entre blanc et un gris très clair peut améliorer fortement la lisibilité.
- Les colonnes des grilles: Fuyez les grilles à 50 colonnes! Ne mettez que le strict nécessaire, quitte à ajouter une fonctionnalité ligne à ligne pour avoir les détails complémentaires. S'il y a des colonnes à ajouter, n'ajoutez que le minimum afin d'épargner à l'utilisateur des écrans surchargés et imbuvables.
- FILTREZ! Ajoutez de partout des capacités de tris et de filtres. Rien n'est plus pénible que des outils de recherche mal foutus, où l'utilisateur, à force de frustration, va finir par vous créer des doublons à la pelle pour ne plus s'emmerder avec votre outil. Pensez également aux extractions de données, aux impressions de listes, bref de quoi faciliter l'existence de vos utilisateur.
- Si traitement long il y a, barre de progression tu placeras. Nous n'avons aucune patience... donc mettez TOUJOURS des barres de progression si vous savez que le traitement activé est susceptible de prendre du temps. Rien n'est pire que s'entendre dire "ça bug" alors qu'il s'agit seulement d'un manque de patience lors de l'exécution du programme.
- Maintenez une logique générale. Si le bouton "OK" est en bas à droite, il le sera PARTOUT, et pas selon votre fantaisie. Il en va de même dans l'organisation des menus.
- La prise en charge du clavier. Penser à des choses comme le copier/coller semble évident... et si vous ajoutiez des raccourcis? Par exemple fermer les fenêtres par ECHAP, F1 pour l'aide, CTRL+P pour imprimer... bref, prenez en compte la possibilité de coller des raccourcis qui facilitent la vie.
- Toujours demander confirmation de l'utilisateur quand il y a un risque de perdre de la donnée. Vous demanderez à chaque fois qu'il y a ajout/modification/suppression un acquittement. C'est le concept du CRUD (que j'aborderai dans les bases de données): Create / Read / Update /Delete.
Create: on confirme
Read: on confirme si la lecture risque de perdre une sélection précédente
Update; on confirme
Delete: on confirme et même on alerte sérieusement.
Comment rendre le tout lisible et confortable à l'usage
En respectant les aspects décrits précédemment. On expérimente soi-même en jouant l'imbécile, en saisissant à la volée énormément de données pourries, en exploitant toutes les idées les plus débiles. L'idée n'est pas de valider la partie technique, mais bien de s'assurer que tout est fait pour qu'une logique générale et un confort d'utilisation se retrouvent dans l'ensemble de l'outil.
Un dernier point
Pensez aussi.. à vous laisser des portes dérobées. C'est idiot dit comme ça, mais la plupart des outils professionnels et même des jeux disposent de portes dérobées pour la maintenance ou les tests. Dans les jeux, on a parfois accès à une console. Celle-ci, c'est le coeur réel du jeu. En connaissant les commandes, on peut changer le comportement ou étudier des anomalies. Faites-en autant dans vos outils, songez à des menus cachés/protégés afin de pouvoir intervenir, le cas échéant, en direct plutôt qu'avec l'espoir de faire une maintenance complexe.
#34
Bien qu'à peu près totalement d'accord avec tes préconisations sur les GUI, je diverge sur ton parallèle avec le développement des jeux vidéos. En effet, ces derniers s'affranchissent totalement de ce qui est la base d'un développement d'application traditionnelle : le respect des normes de présentation requis par l'OS considéré. Tu en donnes d'ailleurs un aperçu en évoquant les raccourcis, mais cela s'applique aussi aux menus, à la gestion des fenêtres, etc. Dans ces domaines, on n'a pas à faire selon son goût ou ses envies, mais selon les requis de Microsoft, ou Apple (pour Unix, je crains qu'il y ait autant de normes que de versions...). Grâce au respect par chacun de ces normes, si tu tombes sur une version suédoise d'une appli, tu arriveras tout de même à la quitter proprement...
Et puis il y aussi le cas particulier du développement Web qui mériterait un chapitre à lui tout seul ! (oui oui, c'est dégueulasse de te surcharger comme ça...)
Et puis il y aussi le cas particulier du développement Web qui mériterait un chapitre à lui tout seul ! (oui oui, c'est dégueulasse de te surcharger comme ça...)
Dernière édition:
#35
Bien qu'à peu près totalement d'accord avec tes préconisations sur les GUI, je diverge sur ton parallèle avec le développement des jeux vidéos. En effet, ces derniers s'affranchissent totalement de ce qui est la base d'un développement d'application traditionnelle : le respect des normes de présentation requis par l'OS considéré. Tu en donnes d'ailleurs un aperçu en évoquant les raccourcis, mais cela s'applique aussi aux menus, à la gestion des fenêtres, etc. Dans ces domaines, on n'a pas à faire selon son goût ou ses envies, mais selon les requis de Microsoft, ou Apple (pour Unix, je crains qu'il y ait autant de normes que de versions...). Grâce au respect par chacun de ces normes, si tu tombes sur une version suédoise d'une appli, tu arriveras tout de même à la quitter proprement...
Et puis il y aussi le cas particulier du développement Web qui mériterait un chapitre à lui tout seul ! (oui oui, c'est dégueulasse de te surcharger comme ça...)
Et puis il y aussi le cas particulier du développement Web qui mériterait un chapitre à lui tout seul ! (oui oui, c'est dégueulasse de te surcharger comme ça...)
Concrètement on a trois philosophies.
1° Apple
Apple a imposé une logique où les objets graphiques sont standard (menu rémanent contrairement à Windows où les menus sont propres à chaque application). De là, en s'intégrant dans cet écosystème, cela instaure des normes et des restrictions très strictes. Apple fournit des libellés normés qui, si l'on change de langue, évolue naturellement dans l'affichage. Dans ces conditions, cela rend la chose à la fois plus simple sur les bases, mais plus pénibles parce que nombre de libellés sont propriétaires... donc imposant de détecter la langue et de s'adapter.
2° Windows
Nombre de librairies graphiques sont standard. En développant sur Windows pour de l'application classique, le format des boutons/menus et autres objets visuels sont en principe standard. Mais, la localisation est tout aussi problématique que pour Apple: si ce sont des termes standard, il y a des "possibilités" d'avoir les libellés qui évoluent selon les régions. Par contre, dès que les libellés sont délicats, c'est au développeur de préparer des fichiers de ressources localisés. C'est comme ça que nombre de programmes disposent de .ini ou .lng où chaque élément du style "validbutton=Valider" permet de traduire "facilement" l'application.
3° La foire à la saucisse
Quand on prend certains outils, ceux-ci réinventent totalement la forme et l'ergonomie. Spotify par exemple a sa présentation personnelle, qui diffère lourdement des autres philosophies des produits concurrents.
Au-delà de ça: j'ai fait l'analogie avec le jeu parce que le raisonnement vaut par équivalence. Les jeux ont toujours un raisonnement supposé faciliter l'expérience utilisateur. Que ce soient des menus bien pensés, des affichages concis et concrets, ou encore des regroupements d'informations, même si visuellement c'est tout sauf de l'application "classique", cela reste tout de même pensé avec les mêmes impératifs. Nombre de jeux sont justement insupportables à cause de ce manque de réflexion sur l'ergonomie générale!
Attention: en épurant à mort, on peut arriver au paradoxe du "trop de simplification tue la simplification". L'exemple concret serait de faire "une fenêtre=une action". Là, on multiplierait les fenêtres pour rien, et pire encore cela imposerait énormément de clics inutiles, là où des groupes par idées/utilisations rendrait le tout plus simple à utiliser.
Le web
Pour ce qui est des développements Web, c'est la foire totale, le bordel absolu, et aucune normalisation n'est parvenue à calmer les ardeurs des développeurs et des pseudo designers. Prenons quelques fondamentaux:
- Quand on développe sur la toile, très majoritairement on est sur des librairies libres. Cela peut mener à de vrais problèmes de suivi, de qualité de code, de charge réseau.. bref c'est le bordel total
- L'ergonomie est pensée et revue constamment parce que le design évolue sans cesse. Les affichages envisagés évoluent constamment pour se donner une impression d'être "à la page", là où, finalement, on ne fait que changer un peu les couleurs et les formes pour donner une sensation de changement. Facebook a semble-t-il revu son design. Cela veut dire quoi? Faire la même chose avec l'apparence du changement. Est-ce judicieux? S'il y a simplification et/ou amélioration ergonomique, pourquoi pas... mais est-ce le cas? ça se discute
- Sur le net, l'apparence prime sur la praticité parce que c'est la première voire la seule chose que perçoit l'utilisateur. Le choix esthétique devient un vrai sujet de débat, et je ne parle même pas d'une ergonomie sciemment foireuse pour rendre délicat le changement de paramètres.
En aparté: nombre de produits sont volontairement obscurs pour aller à la pêche aux paramètres. Cela permet de freiner le changement de forfaits par exemple, gêner les désabonnements, bref de maintenir une pression commerciale sur les clients. C'est difficile à justifier, mais juridiquement c'est inattaquable puisque l'option existe... même si elle est difficile à trouver. (demandez à Cdiscount à quel point leur ergonomie côté paramétrage est merdique... juste pour vous bloquer chez eux!)
#36
Ce que je voulais dire avec l'exemple de l'appli en suédois ne faisait pas référence aux problématiques de localisation, mais aux "normes" de menus : l'option Quitter devrait toujours être la dernière du menu Fichier, lequel devrait toujours être le premier des menus.
Pour ce qui est du web, on ne peut qu'approuver ton triste constat. Ayant quelques années géré le site marchand interne d'un grand groupe, les galères venaient des demandes démoniaques de la direction qui pouvaient se résumer en : à chaque utilisateur son site personnalisé ! Par contre, une mauvaise manip m'a conduit à installer un fond de page de couleur différente suivant le site de prod ou de dév...
Pour ce qui est du web, on ne peut qu'approuver ton triste constat. Ayant quelques années géré le site marchand interne d'un grand groupe, les galères venaient des demandes démoniaques de la direction qui pouvaient se résumer en : à chaque utilisateur son site personnalisé ! Par contre, une mauvaise manip m'a conduit à installer un fond de page de couleur différente suivant le site de prod ou de dév...
#37
C'est pour ça que j'insiste sur la dichotomie de marché. Pour faire une application Apple, tu es tenu de respecter des livrets blancs, là où sous Windows c'est totalement n'importe quoi en terme d'implémentation. Et pourtant, Microsoft n'est en cause car ils offrent ces mêmes cahiers... sauf que Apple est plus psychorigide, et les utilisateurs bien plus exigeants. Chez Ms il y a tellement de produits concurrents que le choix se porte sur la quantité d'utilisateurs (office par exemple), de réputation du produit (Winzip en son temps), que par l'ergonomie générale. C'est tout le souci.
Etant développeur et chef de projet depuis un paquet d'années, je peux te dire que ce qu'il se passe derrière ce qu'on voit n'est pas une nouveauté. Dès la fin des années 90, on avait le droit à la débilité du "faut que ça claque visuellement!"... Essaye de rendre sexy une application comptable toi...
Etant développeur et chef de projet depuis un paquet d'années, je peux te dire que ce qu'il se passe derrière ce qu'on voit n'est pas une nouveauté. Dès la fin des années 90, on avait le droit à la débilité du "faut que ça claque visuellement!"... Essaye de rendre sexy une application comptable toi...
#39
Les bases de données
Déjà, il faut s'entendre sur ce qu'est une BDD! Pour que le commun des mortels comprenne de quoi il en retourne, il faut définir ce que sont les BDD, et bien expliciter leur usage.
Une définition (grossière) des BDD
Une base de données, c'est une manière de stocker les informations pour permettre trois choses:
- Les rendre accessibles par interrogation logicielle
- Les stocker dans une structure articulant les données entre elles
- Permettre une amélioration de la vitesse d'accès aux données.
Pourquoi organiser les données
Faisons une analogie compréhensible. Prenons une bibliothèque avec des ouvrages hétéroclites, et qui peuvent être présents en plusieurs exemplaires aux formats différents (Poche, édition originale, format pléiade et j'en passe).
Les étagères, c'est le niveau zéro du classement. On les range comment? Par auteurs? Par titres? Par référence ISBN (je vous invite à vous documenter à ce sujet)? Par thèmes?
Cela semble anodin, mais au-delà d'une certaine quantité, le cauchemar commence. "On a combien de Zola?", ou encore "est-ce que l'édition du bouquin X est présente?" et j'en passe. Ces questions sont essentielles, car elles permettent de gérer tant le stockage que le rangement des références disponibles.
Alors que faire? Si l'on fait autant de fiches "simples" qui contient
- Auteur
- Titre
- Edition (année)
- Format
On aura autant de fiches que de livres... donc on multipliera les auteurs autant de fois qu'il y a un livre dans la bibliothèque. C'est juste n'importe quoi. Pire, on les trie dans quel ordre? En agissant de la sorte, on n'a pas de règle... et ça ne simplifiera pas les choses.
Créer des classements
Alors l'idée serait "un listing d'auteurs qui mentionnent des références de livres, et un listing de livres à compulser triés par titre"
Est-ce suffisant? Non. Cela rend juste un rien plus "facile" la recherche, mais en aucun cas la mise à jour. Il suffit de vouloir ajouter un bouquin pour que tout doit être mis à jour: la liste des livres référencés par auteur, et de l'autre côté insérer une nouvelle référence. Pire: si l'on a strictement deux fois le même ouvrage... aucun moyen de voir clairement le nombre d'exemplaires disponibles.
Donc, sans une organisation plus rigoureuse, on est forcément dépassé par l'ampleur du chantier.
Que faire
Il y a là un terreau idéal pour une organisation par base de données!
Organiser la donnée
L'idée première est d'éviter le doublon d'information. Si on a une fiche auteur, on ne le crée qu'une fois, et tout ouvrage de cet auteur y fera juste référence. Il en va de même pour toute liste "finie" d'informations. Le sexe, le nom d'une ville en France, une liste d'éditeurs, toutes ces listes n'ont pas vertu à avoir plein de doublons. Il n'en va pas de même pour les clients car on peut avoir des homonymes.... j'y viendrai ensuite.
Articuler la donnée
La donnée doit se structurer, et s'organiser de sorte à permettre des recherches plus ou moins complexes
On appelle ces "listes fondamentales" des tables. Chaque table permet de lier les informations les unes par rapport aux autres.
Commençons simple, créons des données
Sans entrer dans les détails techniques, admettons une liste d'auteurs et une liste de livres.
Chaque ligne a un identifiant unique qu'on peut appeler "clé primaire".
Admettons ceci:
ID Nom
1 Baudelaire
2 Zola
3 Nothomb
ID Titre
1 Lettres
2 L'assomoir
3 L’Art romantique
4 Métaphysique des tubes
5 La bête humaine
On voit un peu l'organisation des titres. Notons ceci: le numéro d'ordre n'a aucune importance. Le livre "3" a été créé avant le "4" et... c'est tout. Cela ne définit en rien son association! Donc la colonne "ID" (clé primaire) augmente graduellement et rien d'autre.
Comment on associe la donnée
Voilà une question qu'elle est bonne! Comme on peut le voir, on veut lier les livres à leurs auteurs respectifs. (pour faire simple, je n'aborde pas la question des livres à auteurs multiples, cela requiert une réflexion plus complexe que j'aborderai plus tard)
Reprenons:
- on a X auteurs, et Y livres à associer.
- Pour un auteur, on peut avoir de 0 à n bouquins (j'explique ensuite pourquoi "zéro")
Donc de là, comment qu'on fait? Déjà, s'il y a zéro livre, c'est qu'on vient de créer l'auteur. On ne va pas créer les livres avant de créer l'auteur, ce qui bloquerait la liaison. Donc, en créant un auteur, une fois celui-ci mis en place, on peut rattacher par la suite la création de nouveaux livres, ou mettre à jour les livres non associés. J'aborde la question juste après.
Déjà, il faut s'entendre sur ce qu'est une BDD! Pour que le commun des mortels comprenne de quoi il en retourne, il faut définir ce que sont les BDD, et bien expliciter leur usage.
Une définition (grossière) des BDD
Une base de données, c'est une manière de stocker les informations pour permettre trois choses:
- Les rendre accessibles par interrogation logicielle
- Les stocker dans une structure articulant les données entre elles
- Permettre une amélioration de la vitesse d'accès aux données.
Pourquoi organiser les données
Faisons une analogie compréhensible. Prenons une bibliothèque avec des ouvrages hétéroclites, et qui peuvent être présents en plusieurs exemplaires aux formats différents (Poche, édition originale, format pléiade et j'en passe).
Les étagères, c'est le niveau zéro du classement. On les range comment? Par auteurs? Par titres? Par référence ISBN (je vous invite à vous documenter à ce sujet)? Par thèmes?
Cela semble anodin, mais au-delà d'une certaine quantité, le cauchemar commence. "On a combien de Zola?", ou encore "est-ce que l'édition du bouquin X est présente?" et j'en passe. Ces questions sont essentielles, car elles permettent de gérer tant le stockage que le rangement des références disponibles.
Alors que faire? Si l'on fait autant de fiches "simples" qui contient
- Auteur
- Titre
- Edition (année)
- Format
On aura autant de fiches que de livres... donc on multipliera les auteurs autant de fois qu'il y a un livre dans la bibliothèque. C'est juste n'importe quoi. Pire, on les trie dans quel ordre? En agissant de la sorte, on n'a pas de règle... et ça ne simplifiera pas les choses.
Créer des classements
Alors l'idée serait "un listing d'auteurs qui mentionnent des références de livres, et un listing de livres à compulser triés par titre"
Est-ce suffisant? Non. Cela rend juste un rien plus "facile" la recherche, mais en aucun cas la mise à jour. Il suffit de vouloir ajouter un bouquin pour que tout doit être mis à jour: la liste des livres référencés par auteur, et de l'autre côté insérer une nouvelle référence. Pire: si l'on a strictement deux fois le même ouvrage... aucun moyen de voir clairement le nombre d'exemplaires disponibles.
Donc, sans une organisation plus rigoureuse, on est forcément dépassé par l'ampleur du chantier.
Que faire
Il y a là un terreau idéal pour une organisation par base de données!
Organiser la donnée
L'idée première est d'éviter le doublon d'information. Si on a une fiche auteur, on ne le crée qu'une fois, et tout ouvrage de cet auteur y fera juste référence. Il en va de même pour toute liste "finie" d'informations. Le sexe, le nom d'une ville en France, une liste d'éditeurs, toutes ces listes n'ont pas vertu à avoir plein de doublons. Il n'en va pas de même pour les clients car on peut avoir des homonymes.... j'y viendrai ensuite.
Articuler la donnée
La donnée doit se structurer, et s'organiser de sorte à permettre des recherches plus ou moins complexes
On appelle ces "listes fondamentales" des tables. Chaque table permet de lier les informations les unes par rapport aux autres.
Commençons simple, créons des données
Sans entrer dans les détails techniques, admettons une liste d'auteurs et une liste de livres.
Chaque ligne a un identifiant unique qu'on peut appeler "clé primaire".
Admettons ceci:
ID Nom
1 Baudelaire
2 Zola
3 Nothomb
ID Titre
1 Lettres
2 L'assomoir
3 L’Art romantique
4 Métaphysique des tubes
5 La bête humaine
On voit un peu l'organisation des titres. Notons ceci: le numéro d'ordre n'a aucune importance. Le livre "3" a été créé avant le "4" et... c'est tout. Cela ne définit en rien son association! Donc la colonne "ID" (clé primaire) augmente graduellement et rien d'autre.
Comment on associe la donnée
Voilà une question qu'elle est bonne! Comme on peut le voir, on veut lier les livres à leurs auteurs respectifs. (pour faire simple, je n'aborde pas la question des livres à auteurs multiples, cela requiert une réflexion plus complexe que j'aborderai plus tard)
Reprenons:
- on a X auteurs, et Y livres à associer.
- Pour un auteur, on peut avoir de 0 à n bouquins (j'explique ensuite pourquoi "zéro")
Donc de là, comment qu'on fait? Déjà, s'il y a zéro livre, c'est qu'on vient de créer l'auteur. On ne va pas créer les livres avant de créer l'auteur, ce qui bloquerait la liaison. Donc, en créant un auteur, une fois celui-ci mis en place, on peut rattacher par la suite la création de nouveaux livres, ou mettre à jour les livres non associés. J'aborde la question juste après.
#40
On a donc des livres et des auteurs.
Sachant qu'on veut faire le lien entre les livres et les auteurs, on ajoute où ce lien? La pratique la plus communément utilisée (sauf cas spécifique que je ne détaille pas ici), on ajoute le lien du côté du membre qui a le plus de données à lier.
Les liaisons
La notation est la suivante: x->y. X représente le nombre d'unités de départs, liées au nombre y de données
Les liens sont globalement de trois types:
0->n
1->n
n->n
Explicitons:
0->n: je peux avoir "rien d'un côté, donc libre, qu'on rattache à n lignes possibles. C'est ce qu'on va utiliser dans le cas où la liaison n'est pas obligatoire. Prenons un cas concret: je crée une facture, mais je n'ai pas encore de paiement. Donc... j'aurai zéro paiement, "rien" donc... d'où un "zéro"
ATTENTION: ce n'est pas une n->n!!! n->n c'est une liaison TRES délicate à utiliser. Lisez la suite vous comprendrez.
1->n: Une valeur est obligatoire au départ, pour arriver à n lignes. Typiquement, c'est ce qu'on trouve pour s'assurer qu'une facture a forcément un client de rattacher. ça veut dire aussi l'obligation de créer le client avant la facture.
n->n: Attention, manipulation bien chiante. Cela donne comme cas la situation complexe du genre une ligne d'un côté associée à n lignes de l'autre... Et réciproquement. C'est un vrai cirque à gérer. A utiliser que quand on sait ce qu'on fait (cas des auteurs multiples qui peuvent avoir écrit des livres seuls, et qui ont participé en groupe sur un ouvrage particulier).
Et ça donne quoi sur notre exemple
ID Nom
1 Baudelaire
2 Zola
3 Nothomb
ID Titre IDAuteur
1 Lettres 1
2 L'assommoir 2
3 L’Art romantique 1
4 Métaphysique des tubes 3
5 La bête humaine 2
C'est quoi le but? Dire que les livres identifiés "2" et "5" sont de Zola... donc d'identifiant "2"! On appelle cela une 'clé étrangère".
Tout ça c'est bien, mais c'est quoi le but
Une fois qu'on enrichit peu à peu le modèle, on obtient quoi?
- Les auteurs
- Les titres
- Les exemplaires
- Les éditeurs
- Le type d'édition
- Les formats possibles
- Les langues (si nécessaire)
Cela donne une vision plus claire et structurée de l'information et des livres!
Alors, on fait quoi à présent? On complète le raisonnement en intégrant aux livres une numérotation indépendante pour traiter le cas des doublons de livres identiques. Petit rappel; l'ISBN est une référence unique de publication... mais deux livres identiques auront donc le même ISBN (sauf s'ils sont d'éditions différentes). Conséquence? Ce n'est pas suffisamment "unique". Alors on va coller un code unique au stock de livres
d'où l'apparition de la table "exemplaire"
Quel est son rôle?
Parlons peu mais parlons bien
ID idTitre ISBN CodeExemplaire
1 3 AAA E1000
2 3 AAB E1001
3 1 123 E1002
4 2 456 E1003
5 4 789 E1004
5 3 AAA E1004
On a trois livres de même titre, dont deux qui sont strictement identiques. On va avoir donc trois codes exemplaire, pour les distinguer une fois pour toute... Donc une vraie distinction pour tous les ouvrages disponibles!
Sachant qu'on veut faire le lien entre les livres et les auteurs, on ajoute où ce lien? La pratique la plus communément utilisée (sauf cas spécifique que je ne détaille pas ici), on ajoute le lien du côté du membre qui a le plus de données à lier.
Les liaisons
La notation est la suivante: x->y. X représente le nombre d'unités de départs, liées au nombre y de données
Les liens sont globalement de trois types:
0->n
1->n
n->n
Explicitons:
0->n: je peux avoir "rien d'un côté, donc libre, qu'on rattache à n lignes possibles. C'est ce qu'on va utiliser dans le cas où la liaison n'est pas obligatoire. Prenons un cas concret: je crée une facture, mais je n'ai pas encore de paiement. Donc... j'aurai zéro paiement, "rien" donc... d'où un "zéro"
ATTENTION: ce n'est pas une n->n!!! n->n c'est une liaison TRES délicate à utiliser. Lisez la suite vous comprendrez.
1->n: Une valeur est obligatoire au départ, pour arriver à n lignes. Typiquement, c'est ce qu'on trouve pour s'assurer qu'une facture a forcément un client de rattacher. ça veut dire aussi l'obligation de créer le client avant la facture.
n->n: Attention, manipulation bien chiante. Cela donne comme cas la situation complexe du genre une ligne d'un côté associée à n lignes de l'autre... Et réciproquement. C'est un vrai cirque à gérer. A utiliser que quand on sait ce qu'on fait (cas des auteurs multiples qui peuvent avoir écrit des livres seuls, et qui ont participé en groupe sur un ouvrage particulier).
Et ça donne quoi sur notre exemple
ID Nom
1 Baudelaire
2 Zola
3 Nothomb
ID Titre IDAuteur
1 Lettres 1
2 L'assommoir 2
3 L’Art romantique 1
4 Métaphysique des tubes 3
5 La bête humaine 2
C'est quoi le but? Dire que les livres identifiés "2" et "5" sont de Zola... donc d'identifiant "2"! On appelle cela une 'clé étrangère".
Tout ça c'est bien, mais c'est quoi le but
Une fois qu'on enrichit peu à peu le modèle, on obtient quoi?
- Les auteurs
- Les titres
- Les exemplaires
- Les éditeurs
- Le type d'édition
- Les formats possibles
- Les langues (si nécessaire)
Cela donne une vision plus claire et structurée de l'information et des livres!
Alors, on fait quoi à présent? On complète le raisonnement en intégrant aux livres une numérotation indépendante pour traiter le cas des doublons de livres identiques. Petit rappel; l'ISBN est une référence unique de publication... mais deux livres identiques auront donc le même ISBN (sauf s'ils sont d'éditions différentes). Conséquence? Ce n'est pas suffisamment "unique". Alors on va coller un code unique au stock de livres
d'où l'apparition de la table "exemplaire"
Quel est son rôle?
Parlons peu mais parlons bien
ID idTitre ISBN CodeExemplaire
1 3 AAA E1000
2 3 AAB E1001
3 1 123 E1002
4 2 456 E1003
5 4 789 E1004
5 3 AAA E1004
On a trois livres de même titre, dont deux qui sont strictement identiques. On va avoir donc trois codes exemplaire, pour les distinguer une fois pour toute... Donc une vraie distinction pour tous les ouvrages disponibles!
Dernières actus
-
Ring Alarm : le kit de surveillance va vous revenir à moins de 180 €
29 Mar 2023 18:16
-
Netflix : voici la liste des codes secrets pour accéder aux catégories cachées en 2023
29 Mar 2023 16:26
-
Samsung veut lancer un SSD de 1 000 To avant 2033, la course au pétaoctet s’intensifie
29 Mar 2023 16:25
-
Resident Evil 4 Remake : 3 millions d’exemplaires vendus en 2 jours, le jeu original avait atteint ce palier en un an
29 Mar 2023 15:48
-
Windows 12 : date de sortie, nouveautés, prix, à quoi s’attendre ?
29 Mar 2023 15:40
-
Windows 12 : la configuration minimale de l’OS de Microsoft en RAM pourrait sonner le glas des vieux PC
29 Mar 2023 15:32
Membres en ligne
- labul671
Derniers messages publiés
Statistiques globales
- Discussions
- 839 019
- Messages
- 7 506 124
- Membres
- 1 584 072
- Dernier membre
- hudheifa1
Partager cette page