Nommage à revoir pour les document du Store
Bonjour,
Sur la 10SP5 ou Workplace5, le nommage des contenus a changé (wiki, documents, etc) pour cibler ce qui est stocké en base de données.
Pour ce qui est stocké sur le store, l'indication apparait de façon différente (front ou back office, option de menu ajouter sur service document) :
Exemple : "Wiki (Store)" ou "Jstore document" ou "Jstore Web page".
Je peux comprendre cette volonté de recentrer/unifier les affichages mais l'indication JStore ne parle pas à nos membres et elle est plutôt confusante.
Pourquoi ne pas avoir mis systématiquement "(Store)" entre parenthèses derrière le type contenu, comme pour les pages wiki, ça resterait acceptable pour tous.
Note : Au passage, impossible de retrouver l'article qui parlait de ça, j'ai cherché partout (surement mal), donc si quelqu'un le retrouve merci d'avance.
Bonjour Dominique RIC
Je suis bien d'accord, il n'y a aucun intérêt à ce changement.
Je n'avais effectivement pas encore vu ce changement lors de mes tests, mais je n'en vois nullement l'intérêt. Ce type de document a déjà changé de noms récemment.
On ne peut pas redemander à nos usagers de ce réhabituer à ce changement.
Absolument ! l'utilisateur n'a pas à connaitre le vocabulaire technique ni même la solution utilisée (ces J partout ne parlent pas à l'utilisateur).
Plutôt d'accord même s'il fallait bien distinguer le type de contenu, les deux solutions jstore XML et DB cohabitant. J'ai d'ailleurs demandé à notre intégrateur s'il fallait qu'on migre nos documents stockés sur le store dans la base de données, histoire de simplifier. Mais à priori ce n'est pas possible et il y a des comportements/options différentes entre les deux types de toutes façons donc certainement des impacts forts si c'était faisable.
Donc on va reste sur le store.
Pour info, j'ai constaté que sur la démo Jalios, le menu Ajouter/Document (Store)" était déjà écrit comme ça. De notre coté sur Workplace5 c'est "Ajouter/JStore document".
Bonjour,
J'irais encore plus loin : c'est totalement inutile et contreproductif d'avoir deux types de documents sous couvert de contraintes ou possibilités techniques différentes. Quand est-ce l'approche utilisateur et l'UX seront pris en compte ?
Sylvain