Élément supprimés de cette discussion : http://scenari-platform.org/trac/scenari/wiki/OptimDesignArchives
Modèle
1/ Ajout de métadonnées
Il nous manque des métadonnées de base Je propose
- Métadonnées (ou Informations générales)
- Paternité ou copyright : sTxt
- Mots-clés : string
- (Licence CC) (abandonnée pour le moment)
SPI Ok pour moi. C'est probablement pertinent de les remonter dans la librairie Office. Sur quel modèle on ajoute ces meta-données : les items racines ou les objets réutilisables comme les sections etc. ?
STC Dans une logique on va au minimum et ensuite on augmente selon les usages, on peut commencer par les items racines (website, slideshow, report) La licence CC c'était du free, on laisse de côté pour le moment ? On peut autoriser le sTxt.model et ainsi avoir le droit de mettre une URL et donc pointer les licences CC à la main si on veut)
Chl Quel est l'objectif de ces métadonnées ? : - gestion - bonnes pratiques documentaires - pour la publication ? Le concept proposé dans Optim est une approche plus générique : l'auteur positionne ses métadonnées (servant en publication) dans les champs dédiés à cet usage : - entête et pied de page du rapport - mots clés du site web (champs absent qui serait à ajouter ? toujours utile ?), infos légales (+ crédits, etc - qui s'ouvre dans un tooltip, en bas de page)
2/ Ajout d'options de publication
Il nous manque un Logo / Image (pour le site, la page de garde du OD, etc. je pense qu'il faut différencier ?)
SPI Je suis ok, mais en ajout dans la dérivation d'optim, pas dans la lib Office.
Ainsi d'une date et une version de publication (qui je pense doit être mutualisée)
SPI Ok dans la lib Office : quelque soit la dérivation, c'est un premier champ qui devrait toujours pouvoir être utilisé quitte à ce qu'il soit légèrement affiné/modifié sémantiquement dans les dérivations.''
ANP coté paramétrage OD, j’ai positionné les champs « entete » et « pied de page » dans Optim laissant ainsi libre l’auteur d’ajouter l’information qu’il trouve pertinente. Rien n’empêche cependant dans une dérivation d’Office métier d’être moins permissif sur ce point et de construire ces champs avec des métas de l’item…
SPI Exact, ca me revient, c'est vrai qu'on s'était déjà pris la tête sur le sujet. Dans la logique Optim, appli générique, faute d'avoir un contexte d'usage maitrisé, on avait opté pour des paramètres de publications génériques s'appuyant sur la représentation graphique, donc notions d'entete et de pied de page. Inversement, dans une dérivation spécialisée de la lib Office, on pourrait construire ces entete et pieds en fonction de meta plus "métier". C'est pour ça que les options de publi "entete" et "pied" ne sont pas dans la lib Office. Et combiner les deux approches est impossible !
STC Pour ma part je serai plutôt pour supprimer ces 2 champs d'Optim, et on les rajoutera si besoin (politique du moins disant dans le doute) ? NB : pour les logos, le mieux est surement de proposer les 3 logos quelque soit la racine, vu que tous les supports sont toujours possibles.
Chl On sort d'une approche très générique. Entête/pied de page est plus souple. Logo : pour mémoire, dans showOrg,on avait conclu qu'il valait mieux les mettre dans la charte graphique. On ne considère pas que si tu as un logo à mettre, tu fais une déclinaison graphique par styler ? si non, il faut effectivement une zone "d'image". Pour le web, le logo figurerait sur toutes les pages ? Il est toujours possible de mettre le logo en marge (fait par Julie pour des sites projets Kelis) Pour le papier, l'img sur la page de garde pose un pb en publi : si elle n'est pas présente, on garde un espace vide (qui aurait pu être occupé par le titre). Ce n'est si simple...
- Options de publication
- Date de publication
- Version de publication
- Logo Web
- Logo Papier
- Logo Slideshow
Chl Question de Sam : ajoute-t-on une date de maj en meta de chaque page web, récupérée de la date de génération ? -> En free. En évolution ?
3/ Discussion extension
[chl : traité]
Fragment Galerie ListeÉvé Section ont la même extension .content Fragment ne peut être inséré que dans un Fragment Galerie ListeÉvé dans Galerie ListeÉvé Section Page Section dans Section Page
Chl ?? tu veux dire quoi ?
Proposition 1 : on laisse comme ça, tout est du .content, ça évite de multiplier les extentions Pro position 2 : on change juste pour fragment en .fragment (c'est un élément singulier) Proposition 3 : on change fragment en .fragment (singulier), section en .section (c'est un élément de structure) et on laisse les autres en .content (et ceux à venir du même type). L'intérêt d'isoler les sections c'est que ce sont les éléments structurants pour les .report et les .slideshow (qui contiennent directement des sections et pas des sections | galerie | listeévé par exemple).
SPI Je ne suis en effet pas convaincu par ce .content, trop vague / englobant. La proposition 3 me va bien, je renommerai même les .content qui restent (listes d'evt, galeries d'images, ...) en .object ou .bean ou .res ou .??? car ce sont des objets / grains de contenus / ressources très spéciaux qui collent mal à ".content" je trouve.
STC Le .object me va bien, c'est ce qui est utilisé dans la modélisation et que j'ai repris dans mon modèle UML
JUW Personnellement, je ne suis pas pour la multiplication des extensions, .content permet de regrouper logiquement les types de modèles entre eux non ? L'icône est là pour les différencier. Non ?
STC Je trouve justement qu'ils ne sont pas vraiment de même type, et les logos sont à mon sens assez peu utilisables, je vote pour la solution 3 avec object à la place de content
- les éléments structurants liés au support : report, website, webpage, etc.
- l'élément structurant générique : section .section
- les éléments de contenu générique : blocs, galeries, etc. (avec certains comme les galeries qui peuvent jouer le rôle de section) .object
- l'élément de réutilisation générique : fragment .fragment
4/ Texte
[ chl : traité]
Pour citation, plutôt mettre entre guillemets dans l'éditeur
Chl : déjà le cas, non ?
Pour "document" je suis pour ne garder que titre et références, et on adopte le terme unique de bibliographie ?
SPI Que fais-tu du code / identifiant ? Il faut réévaluer précisément les stratégies de publication actuelles. Si je me souviens bien l'idée était de faire quelquechose de plus général qu'une bibliographie, à savoir un référentiel de ressources au sens large, le document pouvant être un livre, une image, une video, etc. et que cette ressource soit présente sur le web, dans l'atelier de l'auteur ou dans une bibliothèque municipale... Le terme "bibliographie" me semble sémantiquement très restreint. Nous avions sorti les champs url et refItem plutôt que de les mettre en uLink dans le champs Référence. Toine, Sam, Julie, n'y avait-il pas des raisons techniques précises à cela en terme de stratégie de publication ? Il me semble que oui... mais j'ai oublié, ça date !
JUW Pas d'idées pour le "champs" url... Mais pour moi, il manque cruellement l'item url.model, que j'utilise beaucoup dans dokiel, et qui est utilisé comme refitem dans docM.model
Bataille avec Sylvain :) : Je ne suis pas pour le CTRL+B : c'est physique, c'est anglais, c'est différent d'Opale qui est le standard pour le moment. Je suis pour rester au CTRL+I (important, qui marche en anglais)
SPI Si Optim marche comme on l'espère, il faut acter que 95% des utilisateurs n'auront pas compris nos fondamentaux. Je crains les retours du genre : "dans toutes les suites bureautiques, ctrl+I = italique, pourquoi faire le contraire des autres..." et dans leur vision ils auront raison... De la même manière, si Optim ne marche pas comme on l'espère on s'en fout un peu, mais si Optim marche comme on l'espère, à peine quelques % des utilisateurs d'Optim seront aussi des utilisateurs d'Opale. Steph et Christelle mettent souvent en avant l'argument de la cohérence entre Opale et Optim. A mon avis, se contraindre à garder une cohérence forte avec Opale n'est pas une bonne chose. D'un point de vue Scenari, je trouve que c'est scier la branche sur laquelle on est en train de s'installer... Je m'explique : Commençons par un exemple : ce problème de cohérence se pose de façon encore plus nette avec les nouvelles possibilités de la textPrim : il est à présent possible de complètement "redessiner" le menu contextuel et la barre d'outils de la textPrim en déclarant des boutons dédiés, de comportements de type "toggle", etc. Si on personnalise ainsi l'ergonomie, il est évident que c'est nettement plus confortable / efficient / pertinent pour un pur utilisateur d'Optim, mais c'est peut-être plus chiant pour un utilisateur régulier d'Opale et d'Optim. Aujourd'hui Scenari est un eco-système. Projetons-nous à 5 ans : plus ça ira et plus Scenari sera vu comme une "infrastructure", un peu comme java peut l'être pour de nombreuses applications. Scenari sera le point d'entrée des modélisateurs. Le point d'entrées des utilisateurs sera des eco-systèmes d'applications plus verticales. Prenons Opale : aujourd'hui nous avons Opale et Topaze qui est une sur-scénarisation d'Opale pour mettre en oeuvre une pédagogie plus typée. Très prochainement, nous aurons probablement un autre modèle orienté autour de la video qui sera aussi une sur-scénarisation d'Opale. Nous sommes en train de constituer un eco-système d'applications propres à la pédagogie autour d'Opale. La librairie Office avec le produit Optim-Office en tête de pont à vocation de mon point de vue à devenir un nouvel eco-système. Se contraindre à une cohérence au sein d'un éco-système est indispensable, se contraindre à une cohérence inter-éco-système devient à mon avis un frein à l'innovation et à la spécialisation/adaptation des nos applications, ce qui fait notre force. En conclusion, pour un utilisateur, il ne devrait y avoir pas plus ni pas moins d'écarts entre l'éditeur openOffice et l'éditeur de mail de Thunderbird que entre l'éditeur d'Opale et l'éditeur d'Optim : ce sont 4 applications distinctes qui tournent dans un même OS, c'est tout. J'espère et je crois que ce discours tombera sous le sens dans 5 ans, cela signifiera que nous avons franchi une nouvelle étape. Il est peut-être aujourd'hui encore un peu prématuré, mais je pense que c'est important d'avoir ce scénario en tête.
JUW D'accord avec Sylvain + - les utilisateurs continuent de confondre Opale et Scenari. Ils arrivent (en formation) à faire la différence quand ils ont entre les mains une "autre" chaîne éditoriale. Donc pour moi pas de sens de créer une chaîne éditoriale cohérente avec une autre si elles ne font pas partie du même univers sémantique/fonctionnel. Optim et Opale sont clairement éloignés.
STC Tout ça vous un CTRL+B, comme quoi, à quoi ça tiens 10 ans de travail en commun :) Bon assez d'accord avec vous, pas forcément dans tous les coins : Ma demande de cohérence Opale / Optim porte juste sur les éléments identiques, si j'ai 2 fois "important" et que j'ai deux comportements différents je comprends pas pourquoi. Si on renomme Important en Exergue par exemple (voir après), ça ne me gêne plus. Pour différencier Opale / Optim, OK, mais dans ce cas on évite les homonymes / faux-amis (Laetitia, une mission pour toi, vérifier que rien d'autre de ce genre ne traîne...). Donc si on passe en Exergue, pas de problème pour... CTRL+E :) Sylvain, il te reste juste à trouver un mot qui commence par B !!
Remettre terme étranger à côté de important dans le menu (et mettre important en premier, donc : Important, puis Étranger, puis Citation) (et si on valide le point précédent, supprimer le raccourci pour ce balisage)
SPI Le "terme étranger" est un textLeaf dans le modèle (ie il ne peut contenir que du texte pur), c'est pour ça qu'il s'est "éloigné". La personnalisation des menus de la 3.7 permettrait de le rapprocher. La question est surtout de savoir si on le passe en phraseTag pour permettre un balisage à l'intérieur. Je suis sans avis !
SPI Important TODO : en 3.7, il faut passer la "citation" en phraseTag au lieu de inlineStyle. Il est à présent possible d'associer des metadonnées aux structures de la textPrim. Il est probable qu'on ajoute un jour des metas optionnelles avec l'auteur (...) pour la citation et la langue pour le terme étranger. Règle de la textPrim à retenir : même si on l'a permis pour des cas d'usages particuliers, il faut éviter d'associer des metas à un inlineStyle, car ceux-ci pourraient très vite se retrouver clonés et associés à différents fragments.
Imagette suffit comme intitulé (imagette dans le paragraphe trop long)
J'ai noté la /révolution/ "référence interne". Qu'est ce qui reste de mes théories ? :) Un autre comportement possible (plus "réutilisation-compliant" ?) aurait été de pointer l'élément référencé ssi il fait partie par ailleurs du scénario et de l'ignorer sinon (à discuter).
SPI Si l'item est dans l'arbre c'est un "goto" dans la navigation, sinon c'est une annexe en papier et une surfenetre en web. L'idée est donc bien un "cul de sac" et on retourne ensuite à la lecture principale. Cela est pour moi un design-pattern tout à fait correct : c'est plutôt le "goto" que je trouve discutable, mais je n'imagine pas offrir un outil qui se dit générique produisant des sites web qui ne propose pas l'hyper-lien...
STC : Ce comportement minimise en effet ma révolte :)
JUW En Web, ça casse complètement la navigation, je trouve ça perturbant pour ma part (même si je suis une adepte du CTRL Click/ Click du milieu / Pomme Click pour ouvrir les liens dans de nouveaux onglets, l'utilisateur de base lui n'a pas vraiment ce reflexe).
Pour Adresse Web => reprendre syntaxe Opale : Adresse web, email
STC Ou pas donc, mais dans ce cas se différencier nettement
SPI Avec la 3.7, je passerai le important en mode "toggle" (2 important imbriqués n'a pas de sens). Je personnaliserai aussi la toolbar avec des boutons d'accès direct pour important, terme étranger. Mais on ne sera probablement pas d'accord sur l'icone : pour moi, il faut les icones universelles "B en gras" et "I en italique".... ;) Une alternative : on renomme "Important" en "Exergue" ou "Emphase". D'ailleurs, dans le cadre d'Optim, je ne vois pas bien l'intérêt de multiplier le vocabulaire entre "Important" dans l'inline et le "Bloc exergue" (au dessus du texte). L'intentionnalité me semble la même : peut-on homogéniser en "Exergue" et "Bloc exergue" ou "Emphase" et "Bloc Emphase" ?''
JUW +42
STC Vu tout ce qu'on a dit, j'opte pour un renommage Emphasis / BlockEmphasis ou Focus / BlockFocus (ça commence pas par B...). Je sens que je vais lâcher (mais ça va coûter cher !).
Emphase/Focus/Exergue CRTL+? Terme étranger Citation
Adresse web, email Référence interne Définition Bibliographie
Imagette
5/ Autres modifs mineures
Je propose que les pages Web et dossier Web soient internalisable (ça permet d'ajuster plus facilement un site avec quelques contenus courts et ce sera plus facile pour OptimStarter)
SPI Bof, le userDependant est toujours plus lourd ergonomiquement et avec des pages web internalisées on s'approche du l'illisiblilté des éditeurs de showOrg, ce qu'on cherchait à éviter à tout prix.
Peut-on rendre les sous-sections invisibles par défaut (dans les sections donc) (plus simple dans l'éditeur)
SPI C'est un point à retravailler en effet, probablement en passant en freeXed malheureusement.''
STC Inutile dans ce cas, c'était juste si c'était trivial
JUW ou on peut mettre le terme "sous section" en tout petit et grisé quand il n'y en a pas ?
Problème avec "titre de la page" pour les site web :
- Pour un dossier, "titre de la page" est mal adapté, il faudrait seulement titre ou "titre du dossier"
- Pour une page on a (i) Page Web > Titre de la page ET (ii) Zone principale > Titre, avec en fait (ii) qui se comportent comme titre sur la page et (i) titre dans le menu.
Je pense que renommage "Titre de la page" par "Titre dans le menu" serait suffisant (voir si on trouve mieux) NB : À la publi Web ne pas répéter ce titre en grisé dans le menu à gauche pour les webfolders
SPI (i) est aussi et surtout le title de la page html qui est affiché dans la barre de titre du navigateur et qui est bien / mieux indexé par les moteurs de recherche (à moins que ça ait changé... ?).''
Il y a un problème avec le bloc complément : le titre n'est pas obligatoire, mais sans titre ça ne passe pas à la publi Web. Il faut obliger un titre ou publier différemment (ajouter un titre par défaut "Complément" ou bien une imagette pour qu'il y ait toujours quelque chose à cliquer). Je pense pour ma part que d'obliger un titre est cohérent pour un complément, ce qui assure d'en avoir une vision synthétique.
SPI ok pour moi
STC Sauf que (je ne l'avais pas vu au début) ça oblige à créer un nouveau .model, mais je pense que ça vaut le coup (on peut aussi imposer le titre pour le bloc exergue dans ce cas ?)
Si on veut être homogène entre les webpages et les websites, les En marge devraient être à la fin dans un website...
SPI C'était le cas et on les a remonté, justement parce qu'ils ont finalement des usages très différent par rapport aux "en marge" des pages. Les en marges des pages sont des "compléments à la page" et les "en marge permanente" du site sont au contraire des blocs d'informations structurels du site, comme si c'était des éléments du template général, une sorte de préalable constant par rapport à chaque page spécifique. Ce n'est pas un "complément à toutes les pages", "c'est un préalable à toutes les pages". Mais je suis d'accord pour dire que ce n'est pas satisfaisant dans l'état. Peut-etre est-ce d'avoir utilisé le mot "marge" pour les deux qui est une erreur et qu'il faut changer complètement de vocabulaire, même si dans les skins standards ca se publie de façon similaire :"Information permanente", "Bloc permanent"... ?''
STC En effet, une vengeance de la structuration logique :) Je propose donc de trouver des "noms sémantiques" : "Information permanente" et "Compléments de page" par exemple ?''
JUW Ok pour "Information permanente" qui souligne bien qu'on doit y mettre de préférence une information et pas n'importe quoi.
Question : WebSite et WebPage existent pour différencier les opt de publi (peut être idem pour les métas), mais ce n'est pas le cas pour SlideShow (pas homogène, se jusitifie peut être, problème potentiel à l'apparition des méta et des options de publi dans slideshow)
SPI La récursivité du slideshow est destiné à faire du foldering aisément et surtout à maximiser les possibilité de réutilisation de jeux de slides. Faudrait essayer de faire un SlideFolder, pour voir ce que ca donne. Le slideShow ne serait alors plus qu'un container d'un SlideFolder user-dependant ? A tester...
6/ Autre terminologie à discuter
.website > Accueil du site => renommer en "Accueil" ?
Liste évènements > Aspect => renommer en "Type" ? (plus "logique"...)
7/ Terminologie dans le modèle (noms des balises)
[chl : Traité]
info / warn / extra : blockInfo, blockEmphasis, blockComplement (ou information, emphasis, complement)
SPI info -> information : ca me semble quand même compréhensible ! warn -> emphasis : oui, c'est clair que warn est un oubli de renommage ! extra -> complement : j'ai un doute, il me semble qu'on avait mis extra à dessein pour faire du "bon anglais", Sam ?
Si on met un emphasis balise inline mieux vaut éviter le même terme en bloc ?
evtList : eventList (NB : corriger Événement dans les labels, plusieurs ) frag : fragment
SPI
un xml a toujours la gueule suivante :
<sp:evtList>
<of:eventList>
.....
</of:eventList>
</sp:evtList>
<sp:frag>
<of:fragment>
.....
</of:fragment>
</sp:frag>
Ca me semble compréhensible. En fait, c'est une technique pour bien distinguer la part de son modèle pointé dans les cas de relation 1-1.
Cette 2ème syntaxe abrégée pour la part permet en particulier d'avoir des noms de classes html ou de style od correspondant à l'un ou à l'autre sans confusion possible pour le modélisateur. Dans SCbuilder, je pense que la perte de temps la plus importante aujourd'hui est le temps passé à retrouver "ses petits" et refaire les connections entre le model, les transf et un résultat de publi, surtout quand on ne maitrise pas parfaitement le modèle : éviter d'utiliser 2 fois le même nom pour 2 choses différente me semble une règle saine.
Une autre piste : sp:eventListP, sp:fragmentP, dans le même esprit que le suffix M pour les meta d'un modèle.
A voir, mais si on veut après faire suivre le nom des classes dans les publi web, c'est toujours ca de plus en lourdeur des pages web.
STC Bien noté le problème du "double-nom", mais la solution actuelle me paraît bancale d'un point de vue modélisation. Il faudrait un truc plus systématique, je préfère vue de loin le xxxxP, voir avec les modélisateurs. On peut reporter ça à après Optim, même si c'est un peu dommage vu qu'il va servir d'exemple. On peut se le programmer pour Optim2 et faire le minimum en attendant ?
co : content
SPI
Là le problème est pire : sp:content est déjà utilisé dans section.model. L'utiliser aussi pour un autre niveau de profondeur, (en l'occurence ici block.model) est une mauvaise expérience vécue ;)
<of:section>
<of:sectionM>
<sp:title>Intro</sp:title>
</of:sectionM>
<sp:content>
<of:fragment>
<sp:info>
<of:block>
<of:blockM>
<sp:title>Bloc Intro</sp:title>
</of:blockM>
<sp:co>
<of:flow>
<sp:txt>
<of:txt>
<sc:para sc:id="t10">Ceci est l'intro</sc:para>
</of:txt>
</sp:txt>
</of:flow>
</sp:co>
</of:block>
</sp:info>
</of:fragment>
</sp:content>
</of:section>
je suis d'accord que "co" est peu signifiant, mais par contre il ne faut surtout pas l'appeler "content"
STC object dans ce cas ?
chap : chapter
SPI en effet
(on avait dit qu'on arrêtait les intitulé raccourcis et qu'on privilégiait la lisibilité humaine du XML, il faudrait tout revérifier : Todo LAL (pour vérifier et pour tout renommer dans les .model et .transf)
SPI A part warn qui me semble une erreur, je doute du reste, aussi aux vues de la charge que ca représente. Un exemple facile à évaluer : "evt" est présent 46 fois dans le modele sans compter les déclinaisons et le fait qu'il faut refaire les styles OD. Par ailleurs, je ne sais pas si l'UTC a déjà des "vrais" contenus, mais Kelis en a pas mal, et il faudra qu'on fasse une migration. Dernier point : attention à bien faire les modifs au bon endroit entre la lib Office et la dérivation Optim.
STC On arbitre en réunion et Laetitia s'occupe des renommage du model et du script de migration ?
OptimOfficeStarter
=> enlever :
- Fragment
- Externalisation (tout ou au moins aux niveaux les plus bas)
- Boutons d'exclusion de publication
- Option de publication ?
- Métadonnées ?
...
SPI Qui s'y colle ?
JUW Propositions pour Optim Starter, - 1 .pub = 1 publication (pas de publications alternatives) - les objets sont internalisés. - pas nécessité d'internaliser les pages web, cela permet de montrer que ce sont des items bien spécifiques contraitrement aux diapos et chapitres.
STC Je pense qu'il fait garder le multi-support, donc conserver les multiples publication pour les items de plus haut niveau, en plus ça ne complique pas l'utilisation C'est la réutilisation qui complique et les usersDependant, donc internalisation totale, sauf les pages Web en effet si on veut (on peut supprimer les webfolders par contre) et je pense aussi que pour les diapo, on peut laisser en 100% externalisés (comme dans SSS) pour la réutilisation (on sait faire ça dans ce sens en wspdef, je crois pas). Si on sait le faire avec avec un wspdef (mais je crois pas) ou qu'on opte pour un deriver (mais c'est mieux si on a pas besoin), on peut simplifier le modèle diapo (pas de diapo dans un diapo et/ou pas de sections dans un diapo)
Demandes d'évolution (à capitaliser ou programmer en extension)
- Format papier allégé (recto, verso, plus soft) pour des documents plus courts que les rapports (notes) et/ou modèle de note
[chl : traité]
SPI
En effet, on fait actuellement un modèle de note dans notre modèle dérivé "kelis-office" ;)
Pour Optim :
* je me demande si on n'a pas fait une erreur d'appeler "Rapport" le "document papier".
* Si on parlais de "Site web", "Document" et "Diaporama", ce serait tout aussi compréhensible.
* Dans les générateurs des "Document", on pourrait avoir "Rapport" (au sens du document long avec page de garde, sommaire, saut de page à chaque section principale, etc.) et "Note" pour des publi courtes où par exemple une page de garde et un saut de page avant chaque section principale est une aberration.
Ce besoin des 2 publis me semble de plus en plus évident, ce n'est pas très lourd à faire, je me dis qu'on aurait intérêt à l'intégrer dès maintenant.
ANP Parfaitement d’accord, ce besoin remonte très fréquemment et ça n’est pas lourd du tout à faire.
STC OK sur le principe... sauf pour le terme Document qui est trop générique. Pas mieux pour le moment. "Papier" au double sens de écrire un papier et de support papier ?
Publication autonome des sections en format note pour relecture notamment
objet supplémentaire de type programme de séminaire, colloque, etc.
objet supplémentaire de type contact
Publi de Flux RSS : par exemple, je suis utilisateur de Optim, je fais mon site avec Optim, le site généré propose aux internautes de s'abonner au flux RSS des actualités, j'ajoute une news dans mon site, je regénère, le RSS est modifié, l'internaute découvre la nouvelle news par le fil RSS. (idée Loic)
Notes pour mémoire (rien à faire)
Options de publication > Site Web => pas opérationnel (et masquent en marge et menu)
Bugs et mise en forme
ScBd3.7 - Checkout 8/9/9
Publi Livret Auditeur et Orateur : le titre du slide show est absent de la première page
(site web) Espace avant Bloc (2 blocs qui se suivent sans titre ne sont pas identifiés)
Todo pour mémoire (à gérer par Lal)
Stylage éditeur (Lal) Export SSS=>Optim (Lal) Export ShowOrg=>OPtim (abandonné ?) Contenu de test (voir contenu Christophe) Logo optim / packaging (Loa) Ouvrir la terminologie à la discussion sur les ml (dans l'éditeur surtout) (pas le modèle)
