Fonctions de planification

Projet éditorial

  1. Le système permet à un éditeur-auteur de créer un item de scénarisation[1] (plan) et de déléguer la production à d'autres auteurs

    • fonction "transparente", directement héritée du système de droit préconisé

    • l'item de scénarisation est situé dans un espace sur lequel l'éditeur est auteur ; il référence des items situés dans des sous-espaces ; il délègue des droits en écriture sur des sous-espaces de son espace

    • correspond au modèle collaboratif : Modèle "Orchestration" : Production collective sous contrôle éditorial

  2. Le système permet aux éditeurs et aux auteurs d'associer des notes aux espace

    • équivalent à des post-it visibles sur la home page de l'espace

Tâches

  1. Le système permet au coordinateur d'attribuer des tâches aux collaborateurs

    • une tâche est une information attachée à un utilisateur et à un item, avec éventuellement une dead-line et un status cible

    • exemple : (Bob, rapport.paper, Relire et corriger ce rapport, 18/02/2010, corrigé)

    • la réalisation de la tâche permet de changer le status de l'item (il devient corrigé dans l'exemple ci-dessous), le status peut être associé à une icône ou une couleur permettant une identification rapide dans le système

    • une tâche peut-être associée à un statut (fait, en cours, abandonnée, etc.)

    • l'on peut s'inspirer d'un système de ticket (comme Trac par exemple)

    • la tâche peut être associée à un groupe d'utilisateurs, plutôt qu'à un seul utilisateur

    • exemple simple : une fonction contextuelle à un item permet de sélectionner un utilisateur A et de déclencher une demande de validation par cet utilisateur ; l'item passe en statut "en cours de validation" et une icône particulière est associée à l'item ; A a alors accès à une fonction de validation, lorsqu'il valide l'item retrouve un statut initial neutre, avec en plus l'information "validé par A le ..."

  2. Le système permet aux collaborateurs de s'auto-attribuer des tâches

  3. Le système permet aux collaborateurs de changer le statut d'une tâche

  4. Le système permet aux collaborateurs d'accéder à un tableau de bord de leurs tâches

    • principe d'une todo list

    • principe d'avertissement en push : lorsqu'une tâche est attribuée par le coordinateur, à l'approche d'une dead line, etc.

  5. Le système permet au coordinateur d'accéder à un tableau de bord de toutes les tâches de tous les utilisateurs

    • peut-être à l'exclusion des tâches auto-attribuée (paramètre du système ou de la tâche)

    • principe d'avertissement en push lors du changement de statut d'une tâche

  6. Le système permet au coordinateur d'associer une macro à une tâche

    • lors du changement d'état de la tâche, par exemple lors que la tâche est finalisée

    • que le collaborateur en charge de la tâche active au changement d'état (la macro est rendue disponible en fonction du statut de la tâche) ; ou que le coordinateur active au changement d'état ; ou qui s'active automatiquement au changement d'état

Macros

  1. Le système permet au modélisateur[2] (voire au coordinateur) de définir des macros sous la forme de lots d'actions afin d'automatiser un processus éditorial

    • lots d'actions : déplacer, copier, versionner, supprimer, créer un espace, donner des droits, etc.

    • similaire aux "règles de worflow simple" d'Alfresco par exemple

    • exemple : partager un réseau d'item avec un autre auteur = déplacement d'un espace (en lecture) à un autre (en lecture/écriture) + poser une alerte pour informer du partage ; rendre public un réseau d'item = déplacer dans un autre atelier auquel sont abonnés tous les autres ateliers + déclarer l'item racine comme porte d'entrée ; finaliser un DD = générer le DD + copier le DD dans une bibliothèque + supprimer la version courante dans l'atelier ; etc.

    • les macros peuvent être paramétrées par le modélisateur et activées par le coordinateur

  2. Le système permet au modélisateur (voire au coordinateur) d'associer des macros à des types d'item

    • la macro est disponible (sous la forme d'un bouton ou d'un accès dans un menu) pour tous les items de ce modèle

  3. Le système permet au coordinateur d'associer des macros à des espaces, des items, des utilisateurs

    • la macro est disponible pour tel ou tel espace ou item pour tous les utilisateurs, ou pour tous les items et espaces de tel utilisateur

    • on peut envisager la combinaison tel item ou espace pour tel utilisateur

    • NB : il y a un problème de cohérence potentiel, certaines macros n'ayant pas de sens pour certains items, le rôle du coordinateur pourrait se limiter à associer les macros à certains items dans un cadre préalablement prévu par le modélisateur (le modélisateur pourrait accrocher une macro à un modèle d'item avec le paramètre de disponibilité always ou coordinatorDependant)

Workflow

  1. Le système permet de pré-définir une séquence de tâches impliquant plusieurs items et utilisateurs sous la forme d'une liste chaînée

    • le changement d'état d'une tâche déclenchant automatiquement la tâche suivante

    • le coordinateur peut ainsi planifier un enchaînement de tâches à l'avance

  2. Le système permet de pré-définir une séquence de tâches impliquant plusieurs items et utilisateurs sous la forme d'un réseau

    • même principe que la liste, mais sous la forme plus complexe d'un réseau : possibilité de parallélisation de tâches, de boucles de rétro-action, de branchements, etc.

    • voir standard eBMP et approche classique du domaine

    • la fonction pourrait être restreinte à des DD[3] dans la bibliothèque, le comportement de réseaux[4] dans des ateliers étant plus difficile à imaginer

Temporalisation des accès

  1. Le système permet de préciser une période de validité pour un accès en écriture

    • (pas en lecture, principe de permanence des accès en lecture)

    • exemple : un auteur donne le rôle de coauteur à une utilisateur de T1 à T2 ; un coordinateur donne le rôle d'éditeur de T1 à T2 pour une tâche de relecture ; etc.