scenari
Bonnes Pratiques pour les Modélisateurs
- Indiquez la provenance et les licences des éléments graphiques :
- Transflist dans le répertoire parent d'un ensemble de .transf : si vous voulez rassembler plusieurs .transf dans un .transflist, il est recommandé de créer le transflist, de créer un répertoire du même nom au même endroit, et de mettre tous les .tansf du .transflist dans ce répertoire.
- Correspondance nom de fichier / code : le nom des fichiers .model doit correspondre à son code, et le nom du fichier .transf s'écrit en <code>@<axis>.model ou juste <code>.model s'il est sans axis.
- Nom et codes cours : limitez la taille des noms de fichiers et du code associé : le chemin total ne dois pas dépasser environ 255 caractères. Le constructeur d'application (appMake) en dupliquant les fichiers dans certains sous répertoires peu rallonger encore ces noms au moment de la création de l'installateur pour certains systèmes d'exploitation.
- Pas d'accent dans les noms de fichiers (discussion forum) : que ce soit pour SCENARIbuilder, SCENARIchain ou même dans l'usage quotidiens des systèmes de fichiers, l'UTC recommande de ne pas utiliser de caractères spéciaux ou accentués (à l'exception des cas spécifiques spécifiés dans ce documents - exemple avec les @ pour les axis). Lors d'un passage de fichiers d'un système d'exploitation a un autre, les caractères spéciaux ne sont pas forcément encodées de la même manière, c'est pourquoi il est bon de se limiter a l'ensemble suivant :
[a-z][A-Z][0-9][_][-]
- Simplification des primitives : que votre modèle soit simple ou complexe, n'hésitez pas a faire une passe de retouche pour simplifier les primitives. Exemples d'éléments qui suivant les situations peuvent éventuellement être enlevés :
- Les listes à puce dans les textPrim si les listes simples sont suffisantes, ou garder uniquement listes a puces + listes ordonnées (discussion forum).
- Certaines balises inline "équations", "imagettes", acronymes
- Les meta des binaryPrim si votre modèle a pour objectif des petites démonstrations
- Si vous savez d'avance que vous allez recevoir des contenus en langue française et que vous publiez des documents ODT, suivez ces instructions pour éviter les problèmes de mots soulignés par le correcteur orthographique : StylageFrancais
- Limitez la diversité des noms d'extensions des fichiers de contenus pour permettre a l'auteur de les mémoriser (pour plus de 10 extensions différentes, c'est une opération difficile).
- Les noms cours sont préféré aussi pour les extensions, veillez bien à ne pas reprendre des extensions qui ont déjà un sens et qui pourraient induire en erreur les utilisateurs. Pour réduire les chances de collisions, il est recommandé de ne pas utiliser les extensions de 3 lettres, mais plutôt 4, 5 ou 6. Dans tous les cas, évitez les extensions qui ont une longueur très variables à l'intérieur d'un même modèle.
- Evitez d'effectuer des choix "deprecated" (=obsolètes) : CallOutline, HTML 4.01 without URI, librairie SC3
- Utilisez les numéros de version de manière adaptée :
- Evitez de diffuser deux versions différentes du même modèle sous le même numéro ;
- Evitez de "faire baisser" le numéro de version.
- Nomage par défaut des nouveaux items créés (discussion forum) : le nom par défaut des items créé doit être du type "scenari" :
- <nomEspace>.<type> pour les items de racine (nf17.module)
- <nomEspace>_01.<type> pour les items de niveau 2 (nf17_01.session)
- <nomEspace>_01_01.<type> pour niveau 3 ? (nf17_01_01.etape)
- Evitez d'utiliser des images PNG transparentes en élément de stylage (les PNG sans transparence ne semblent pas poser de problème) :
- Générateurs OO : Elles sont sources d'une très grande lenteur et lourdeur lors de l'export PDF si utilisées en tant que grande image de fond haute résolution ;
- Générateurs HTML : IE6 ne supporte pas les PNG avec chan alpha.
- Attention au polices de caractères utilisées : évitez certaines polices windows qui occasionnent des problèmes de compatibilité sur les autres systèmes d'exploitation (Arial Black...)
Questions / indéterminé
- Imaginons qu'un modèle comporte 2 compositions ("racine.model" qui contient des parts "feuille.model"), en publication html on souhaite faire une page par feuille :
- doit on créer la page au niveau de racine.transf ? <for code="*"><page...>
- doit on créer la page au niveau de feuille.transf ? racine.transf : <for code="*"><callSubModel> ; feuille.transf : <content><page>
- Même question que précédemment sur les Heading en HTML et en OD : au niveau du parent ou au niveau de l'item courant ?
Bonnes Pratiques pour les Auteurs
- Evitez de mettre des tableaux avec des cellules a hauteur variable/automatique : lors de la génération, il peut manquer des lignes si openoffice n'a pas calculé les bonnes dimensions. Pour évitez le problème, redimensionnez la hauteur des lignes du tableau à la main afin d'annuler la taille automatique.
Download in other formats: