Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Plan Qualité v 1.23 Page 1 Copyright Olivier Dahan odahan@cybercable.fr reprodu

Plan Qualité v 1.23 Page 1 Copyright Olivier Dahan odahan@cybercable.fr reproduction interdite sans l'accord de l'auteur PLAN QUALITE pour les applications écrites avec DELPHI Release 1.24 © 1997 - Olivier Dahan Email : odahan@cybercable.fr Web : http://perso.cybercable.fr/stargate/ NOTE 7-2000 Bien que nécessitant une mise à jour globale, cet article présente de nombreux concepts toujours valides. Les remarques positives des lecteurs me font penser qu’il peut être encore diffuser sous cette forme. Mais n’oubliez pas en lisant que tout cela s’inscrit dans un context qui a 3 ans et plus pour certains passages et que certains anachronismes sont possibles… merci par avance de votre indulgence. résentation Le présent document à pour but de collecter une série de « conseils » de développement. Il s’adresse donc en priorité à une population professionnelle ayant déjà de solides notions de programmation. Je n’ai pas eu ici la prétention d’édicter une « norme » au sens académique du terme, ce qui serait à la fois présomptueux et hors de toute réalité. Ce document n’est qu’une suite d’avis et conseils, parfois commentés longuement car ce qui prime est la justification des choix, et, souvent, des digressions se mêleront aux informations techniques. Une application professionnelle ne se conçoit pas à coup de « recettes », c’est avant tout un esprit, une rigueur, une attention de chaque instant, un attachement au détail, une certaine noblesse. La même que celle de l’artisan qui corrige les moindres erreurs pourtant invisibles à l’oeil du profane. Comme pour un bel objet façonné, l’utilisateur d’un logiciel ne sait pas dire ce qui a été fait techniquement et qui créé son attachement à ce dernier, il l’aime et l’utilise. C’est tout. ... Mais pour en arriver à un tel niveau de satisfaction il faut souvent beaucoup de travail dont les détails échappent et échapperont toujours à l’oeil de celui qui n’est pas initié. Un artisan est un magicien, il transforme l’inanimé en objet de plaisir et de satisfaction, soyez-en un aussi ... Les conseils proposés ici sont les fruits de réflexions longues, de nombreuses expériences, ou du simple bon sens. Ils contiendront parfois des interdictions voire des obligations. Pour d’autres rubriques il s’agira plutôt de faire des choix entre diverses possibilités. Comme il faut bien se décider j’y propose alors une solution qui a l’avantage, si elle est suivie, d’offrir cohérence et homogénéité aux développements. Tout ce que le lecteur trouvera ici doit être vu sous l’angle d’un travail en perpétuelle évolution. Cela implique qu’il a le pouvoir (le devoir ?) de proposer ses critiques, ses solutions. Toutefois, comme un tel document tire une partie de sa valeur de son « unicité », il conviendra de me faire directement ces propositions afin que je puisse maintenir à jour le « Plan Qualité » et qu’à une date donnée il n’y ait toujours qu’une seule version « officielle » en circulation. Les conseils ici prodigués le seront sous l’angle du développement DELPHI. L’existence de disparités entre la version 16 bits et la version 32 bits imposent aussi un nivellement sur une base commune. Ne seront donc pas abordés ici les Threads, le Repository, les DataModules, l’héritage de Tform et autres techniques propres à P Plan Qualité v 1.23 Page 2 Copyright Olivier Dahan odahan@cybercable.fr reproduction interdite sans l'accord de l'auteur l’environnement 32 bits. Une notice complémentaire sera conçu pour les développements utilisant DELPHI 32 (2, 3, 4, 5) et les techniques qui lui sont propres. L’ouverture sous Linux imposera une refonte… I. Ergonomie Générale Il est en fait difficile de trancher sur ce qui est du pur ressort de l’ergonomie et de ce qui ne l’est pas. Un bon logiciel n’est qu’une suite de bonnes décisions qui toutes influencent, directement ou non, l’ergonomie générale du produit. Toutefois nous nous limiterons dans ce chapitre à ce qui concerne directement l’interface. A. Les messages d’aide DELPHI propose une gestion assez souple des messages d’aide notamment avec les bulles d’aide (HINTS). Il est très important d’utiliser ce système qui peut souvent éviter la création d’un système d’aide contextuel plus lourd à gérer. Il convient dès lors de bien connaître le fonctionnement de ces HINTS et des astuces qui y sont relatives. 1. Les bulles d’aide La norme est assez floue à propos des bulles qui ne font pas partie du fonctionnement de base de Windows. Toutefois on peut affirmer que les textes doivent être très courts : une bulle d’aide ne doit pas être un pavé d’aide ! Le mot « bulle », lui-même, implique une certaine légèreté, ne l’oubliez pas... On préférera des bulles ne contenant qu’un seul mot ou expression avec le minimum d’articles et de mots de liaison : QUITTER, MISE A JOUR, et non « Quitter l’application », « Lancer la mise à jour ». Ces formes plus littéraires ralentissent le travail de l’œ il… Si la traduction française de HINT (bulle) insiste sur la légèreté, le sens original de HINT insiste lui sur le caractère fugace de l’information donnée et sur sa fonction première qui est de donner une indication et non un cours complet. Pour information : « HINT (1) Allusion, To drop a hint = faire une allusion (à noter « drop », action rapide en général, nda), (2) Conseil (piece of advise : morceau de conseil...), (3) Soupçon... » Une bulle, un soupçon, un morceau de conseil... voici bien résumé ce que doit être une bulle d’aide. Proscrivez l’aspect amateur et antinomique des bulles multi-lignes (sauf exceptions que nous aborderons plus loin). Court et précis ne signifie pas utiliser le style télégraphique ou une sibylline notation hiéroglyphique. L’ergonomie est un métier à part entière, des gens y consacrent leur profession, des chercheurs leur vie. Si tout un chacun peut aujourd’hui développer sous Windows, cette démocratisation s’accompagne (comme toujours) d’un nivellement par le bas et d’un affaiblissement de la compréhension des concepts sous- jacents. IBM et Microsoft ont publié leurs normes, il faut les lire et s’en inspirer, ou au moins en connaître l’existence et le sens. Et ce, quoi qu’on pense de ces sociétés et de l’admiration ou de l’inimitié qu’on ressent pour leurs dirigeants. Un professionnel sert un but, la qualité, ses sentiments personnels, même justifiés, ne sont que secondaires. Plan Qualité v 1.23 Page 3 Copyright Olivier Dahan odahan@cybercable.fr reproduction interdite sans l'accord de l'auteur Le choix d’un texte pour une bulle est une démarche de même nature que celle du choix et du dessin d’une icône, d’une musique d’accompagnement, d’une séquence vidéo. Le caractère multimédia de Windows impose des compétences artistiques à tout concepteur. Ainsi, choisir un mot ou une expression qui résumera bien une fonction est une tâche parfois difficile qui réclame des qualités qui ne sont pas celles d’un informaticien. L’humilité, en partie, consiste à connaître ses limites. Si vous ne trouvez pas, faites dans la simplicité et l’évidence. S’il faut être un informaticien ou un nouveau Champollion pour décrypter vos bulles, mieux vaux ne pas en mettre du tout... Dans certains cas rares, il se peut que vous ne trouviez pas quelque chose de court et de sensé. Ce n’est pas trop grave, dans ce cas veillez à ce que la bulle ne soit pas aussi large que l’écran. Pour y remédier on peut alors admettre (et uniquement dans ce cas) de placer le texte sur deux lignes, pour « ramasser » l’allure générale de la bulle. L’éditeur de DELPHI ne permet pas de placer des changements de ligne dans le texte d’une bulle. Ce dernier est considéré comme une propriété STRING, le retour chariot met simplement fin à la saisie en la validant. Cela ne doit pas vous décourager, la fenêtre affichant les bulles utilise correctement les capacités de Windows et prévoit l’affichage sur plusieurs lignes. Pour faire la jonction entre l’éditeur de propriété qui n’autorise pas la saisie du caractère #13 et la classe de fenêtre des bulles qui, elle, le gère, vous avez deux méthodes : Saisir le texte par programmation (MonObject.Hint := ‘1ère ligne’+#13+’seconde ligne’), méthode qui vous poussera à ne pas abuser de la chose, ou bien utiliser un éditeur de propriété HINT spécialisé. Il existe sur le Forum DELPHI un outil Freeware du nom de HINTEDIT qui assure cette fonction à merveille. Il est important de prévoir, par un paramètre persistant de l’application (donc stocké dans un fichier INI -ou en REGISTRY- en général), la possibilité de déconnecter les bulles d’aide. Chaque objet TFORM dispose d’une propriété SHOWHINT pour ce faire et tous les objets possédant une propriété HINT ont aussi une propriété PARENTSHOWHINT qu’on laisse à TRUE (sauf cas particuliers).La visibilité globale pour la fiche est contrôlée par TFORM.SHOWHINT. Pour gérer de façon habile cette option sans intervenir sur chaque fiche, programmez un gestionnaire de l’événement ONACTIVEFORMCHANGE de l’objet SCREEN. Systématiquement vous placerez le SHOWHINT de la nouvelle fiche active à la valeur de la fiche maître ou à celle d’une constante globale contenant le choix de l’utilisateur à propos de la visibilité des bulles. 2. La ligne de statut (status line) Si cette technique est plus uploads/Management/ plan-qualite-delphi.pdf