Ça fait un bout de temps que je n’ai pas parlé de Skriv, mais je continue à travailler dessus (c’est une des raisons de ma faible productivité sur ce blog).

J’avais écrit un article concernant l’organisation de l’information. C’était intéressant, mais j’étais parti dans une direction bien trop complexe pour être envisageable ; je m’empêtrais dans un système de tags tentaculaire. J’ai continué à réfléchir à tout ça, cette fois-ci en partant du besoin fonctionnel pour aller jusqu’aux droits d’accès des utilisateurs. L’air de rien il s’agit d’un point très important, qui influe directement sur la philosophie de l’outil.

Organisation de l’information

Pour commencer, parlons du découpage des données :

• Il existe des projets, auxquels les utilisateurs ont accès.
• Les utilisateurs possèdent des groupes de projets, dans lesquels ils peuvent placer leurs projets. Ainsi, j’imagine que je mettrai le projet «IT» dans le groupe «Professionnel», alors qu’un de mes collègues le mettra peut-être dans son groupe «Informatique».
• Les projets contiennent des sous-projets. Chaque sous-projet peut contenir un ensemble de listes, de fichiers, de documents écrits, etc. C’est LE moyen de regrouper des informations connexes (par exemple une spécification fonctionnelle, des maquettes graphiques, une spécification technique, une liste de tâche et une liste de bugs) au sein d’un même ensemble logique.

L’idée est de permettre à chacun d’organiser les données de la manière qui lui convient le mieux. Habituellement, les logiciels de gestion de projet sont assez binaires : Ils servent à gérer les projets de l’entreprise, et donc les projets qu’on y crée sont visibles par les membres de l’entreprise ; les systèmes de gestion des droits empêchent d’ailleurs souvent de créer des projets quand on n’est pas soi-même un administrateur ou un chef de projet. Pour ma part, j’ai une vision très différente des choses.

Les buts

Je veux pouvoir utiliser le même outil pour mes projets personnels et mes projets professionnels. Je veux pouvoir regrouper les projets en fonction de ce qui est le plus logique à mes yeux, sans que cela ne me soit imposé par quelqu’un d’autre, ni que mes changements ne se reflètent chez les autres.

Si j’ai accès à un projet, je veux pouvoir y ajouter des éléments (sous-projets, listes, documents, …) qui ne seront visibles que par moi. Par exemple, si j’ai besoin de faire des annotations personnelles sur une spécification, ou si je veux gérer une liste de tâches personnelle concernant un projet particulier, je dois pouvoir le faire. Si je le souhaite, je dois pouvoir ouvrir l’accès à ces élément, à une partie (ou la totalité) des utilisateurs ayant accès au projet lui-même.
Plutôt que d’être dans une démarche classique, selon laquelle l’organisation des données dans l’outil conditionne la manière dont on va y accéder, je préfère laisser à chacun la possibilité d’adapter l’outil sans contrainte.

Je n’ai pas envie de me prendre la tête quand je gère les droits d’accès aux projets et sous-projets. Quand je crée un élément, je dois pouvoir choisir simplement entre 3 possibilités :

1. Je suis le seul à y avoir accès.
2. Tous ceux qui avaient accès à l’élément parent bénéficient du même accès à l’élément enfant que je viens de créer.
3. Je donne un droit d’accès particulier à un utilisateur ou un groupe d’utilisateurs que j’aurai préalablement défini.

Tout autre gestion plus complexe, comme par exemple avoir une liste détaillée de chaque utilisateur ayant accès à l’élément, en choisissant des droits différents pour chacun, peut se faire dans une interface d’administration plus complète. L’essentiel est que l’opération de base la plus courante se fasse en toute fluidité.

Les droits

J’ai donc essayé de définir les droits que l’on pourrait affecter aux utilisateurs, pour retranscrire ces contraintes.

Il y a 4 types d’actions possibles :

• La lecture. Cela veut dire qu’on peut voir un élément et son contenu (sauf restriction sur des sous-éléments).
• L’ajout. Ajouter un sous-projet à un projet. Ajouter une liste ou un partage de fichiers à un sous-projet. Ajouter des items à une liste. Ajout des fichiers à un partage. Ajouter un document à un wiki. Ajouter des messages de micro-blogging sur un projet.
• La modification. Changer le nom d’un projet, d’un sous-projet ou d’une liste. Changer le contenu d’un document wiki. Modifier le contenu d’un item de liste.
• L’effacement. Détruire un projet ou un sous-projet, et tout son contenu. Effacer une liste et tous ses items.  Éliminer un partage et tous les fichiers qu’il contient.

On pourrait penser à une action supplémentaire, celle du déplacement. Par exemple pour déplacer un sous-projet, depuis un projet vers un autre. Ou sortir un item d’une liste pour le mettre dans une autre. Mais en fait, cela correspond à un ajout (dans la destination) et un effacement (dans la source).

J’en arrive à un points où je pense pouvoir tout gérer avec 4 niveaux de droits :

• Administrateur. Autorise tous les types d’action sur l’élément (lecture, ajout, modification, effacement). Autorise tous les types d’action sur les sous-éléments (sauf contre-indication).
• Lecture-écriture. Autorise la lecture de l’élément, ainsi que la lecture, l’ajout et la modification de ses sous-éléments (sauf contre-indication).
• Lecture seule. Autorise la lecture de l’élément et de ses sous-éléments (sauf contre-indication).
• Pas d’accès. Sert à «cacher» un sous-élément, pour le rendre invisible aux yeux d’un utilisateur qui a des droits d’accès à l’élément parent.

Cas particuliers : création et suppression

Par défaut, quand on crée un sous-élément, les droits d’accès sont les mêmes que pour l’élément parent. Il est toutefois possible de déclarer le nouvel élément comme «privé» ; seul son créateur peut alors y accéder (cela ne concerne pas les projets, qui ne sont accessibles que si on y a donné explicitement accès).

On ne peut créer un sous-élément que si on a des droits d’administrateur ou en lecture-écriture. On ne pourra donner accès à ce sous-élément qu’aux personnes ayant un accès (administrateur, lecture-écriture ou lecture seule) à l’élément parent. Par contre, il sera possible de sur-classer un utilisateur : quelqu’un ayant un accès en lecture seule sur l’élément parent pourra avoir un accès en lecture-écriture, ou même en tant qu’administrateur, sur le sous-élément.

La suppression est bien plus délicate. Imaginons que l’administrateur d’un projet décide de l’effacer. Que deviennent les sous-projets dont pour lesquels il n’a pas les droits d’administration ? Question identique pour les éléments placés à l’intérieur des sous-projets.
On pourrait imaginer que tous les sous-éléments en question rejoignent un “projet par défaut”  chez leurs créateurs. Mais ce n’est pas d’une folle évidence ergonomique.

Exemples d’utilisation

Voici quelques exemples d’utilisations concrètes que j’ai en tête.

Je crée un projet «Skriv». Je suis automatiquement administrateur du projet. Je crée des sous-projets «GUI» et «IT», chacun contenant une liste de tâches et un wiki.
Je donne accès à ce projet aux autres contributeurs en lecture-écriture. L’un d’eux veut écrire des notes concernant son travail ; mais tant qu’elles ne sont pas terminées, il ne veut pas qu’elles soient accessibles ; il crée donc une page de wiki en la marquant comme privée.
L’un des contributeurs étant chargé du design, il crée un partage de fichiers dans le sous-projet «GUI». Il en est automatiquement l’administrateur, et me donne l’accès en lecture-écriture. Quand les maquettes seront terminées, on y donnera accès en lecture aux autres contributeurs.

Ma femme crée un projet «Vacances» et me donne l’accès en tant qu’administrateur. Je le place dans mon groupe de projets «Personnel». Je crée le sous-projet «Été 2011», et comme ce sont des vacances en famille, je donne accès à mon frère (en lecture sur le projet, en lecture-écriture sur le sous-projet). Comme nous voulons faire une surprise à nos femmes, nous créons un wiki «Surprise» dans le sous-projet, dont nous sommes les seuls à avoir accès.

Edit : Un cas supplémentaire

En réfléchissant, il m’est apparu que les 4 niveaux de droits (admin, rw, ro, no) ne sont pas suffisants. Il faut ajouter un niveau supplémentaire, qui autorise la lecture de l’élément, ainsi que la lecture et l’ajout de ses sous-éléments (sauf contre-indication).

Le cas d’utilisation concret est une buglist. Il faut que certains utilisateurs puissent remonter des bugs, et donc créer des tickets, sans pour autant pouvoir modifier tous les tickets déjà existants.

Si je reformule, il y aurait donc 5 niveau :

• administrateur
• modification (correspond au “lecture-écriture” définit plus haut)
• ajout
• lecture (correspond au “lecture seule” définit plus haut)
• pas d’accès

Avec une spécificité concernant la création de sous-éléments :

• pas d’accès => On ne peut évidemment pas créer de sous-élément.
• lecture => On ne peut pas créer de sous-élément non plus.
• ajout => On n’est pas administrateur des sous-éléments que l’on crée. Les administrateurs de l’élément parent le sont automatiquement sur le sous-élément. On garde des droits en “ajout” sur le sous-élément créé (pour pouvoir commenter le sous-élément créé, par exemple).
• modification => On peut créer des sous-éléments, et on en est administrateur.
• administrateur => On est évidemment administrateur des sous-éléments que l’on crée.

Ça commence à être assez complet, tout ça. Reste à voir si ça reste facilement compréhensible, je ne veux surtout pas faire une usine à gaz. Le seul cas impossible à gérer, c’est l’utilisateur qui n’a accès à une buglist qu’en lecture, mais qui devrait pouvoir commenter les tickets. Enfin si, ce serait possible, mais il faudrait lui donner explicitement les droits en “ajout” sur tous les tickets de la buglist, au fur et à mesure qu’ils sont créés. Mais je suis certain qu’il n’y a aucune nécessité à gérer ce cas-là.

Cela fait longtemps que je n’ai pas écrit d’article au sujet du projet Skriv.
En ce moment, je cherche un moyen permettant de gérer les projets en autorisant 2 visions différentes :

• Une vision macro, pour suivre l’avancement global des projets et des sous-projets. Sans avoir le détail de toutes les tâches qui composent chaque sous -projet, il faut savoir quelles sont les deadlines des sous-projets, et éventuellement à quel pourcentage de complétion ils se situent.
• Une vision micro, pour accéder à toutes les informations liées aux différents sous-projets, les tâches, la documentation, etc.

La vision macro est absolument nécessaire pour prendre des décisions à moyen terme, ou simplement pour avoir une vision synthétique du travail. La vision micro est nécessaire pour tout le travail au quotidien : définir les priorités des tâches, accéder à la documentation, etc.

Découpage des projets

Je me creuse la tête depuis un moment au sujet de la meilleure manière de découper les projets. Avoir un seul niveau d’organisation n’est pas satisfaisant ; on se retrouve à avoir une liste de tâches interminable, sans pouvoir faire de regroupements logiques.

J’aime bien l’idée d’offrir un deuxième niveau d’organisation. Cela semble assez naturel de pouvoir découper un projet en plusieurs sous-projets. Dans ma tête, chaque sous-projet est un ensemble logique pouvant comporter :

• une ou plusieurs listes (par exemple une liste de tâches et une buglist)
• une collection de « pages » de wiki (spécifications du sous-projet, documentation technique, checklist, …)
• un espace de stockage pour des pièces-jointes, elles-mêmes éventuellement réparties dans des sous-dossiers
• une liste de messages portant sur le sous-projet

Si on suit cette vision, il faut proposer une vision complète au niveau du projet, qui rassemble toutes ces informations de manière agrégée (une liste avec les tâches de tous les sous-projets, toutes les pages de wiki, toutes les pièce-jointe, et ainsi de suite).

Faut-il proposer une organisation plus complexe ? Certain logiciels permettent de créer autant de niveaux de sous-sous-projets que l’on veut. Mais personnellement je trouve ça inutilement complexe ; on s’y perd et la productivité n’y gagne rien.

Informations liées aux sous-projets

Avec ce découpage en sous-projets, il m’est venu naturellement une idée : on pourrait donner une date de début et une date de fin à chaque sous-projet. De cette manière, il serait très facile de représenter graphiquement les sous-projets sur une ligne de temps, de manière à faire une sorte de diagramme de Gantt simplifié. C’est parfait pour la vision macro dont je parlais plus haut.
On aurait donc deux informations très synthétiques associées à chaque sous projet : ses dates de début et de fin, et son pourcentage de complétion (qui serait calculé à partir du statut des tâches faisant partie du sous-projet).

Imaginons que pour le projet « Mini-satellite en orbite », on aurait les sous-projets :

• Construction de l’espace de lancement – 28 fév. au 4 mars – 10%
• Étude de la fusée – 21 fév. au 11 mars – 25%
• Montage de la fusée – 14 mars au 1 avril – 0%
• Construction du satellite – 7 mars au 31 mars – 5%

Sauf que… tout dépend de la manière dont vous gérez vos projets. Dans mon entreprise, les sous-projets décrivent souvent une nouvelle fonctionnalité ; pour l’implémenter, on a besoin d’une spécification fonctionnelle, une spécification technique, de maquettes graphiques, de documentation technique ; pour en faire le suivi, on a besoin d’une liste de tâches qui va nous servir à découper précisément les différentes étapes de l’implémentation, et d’une buglist qui va servir durant les tests et la recette.

Mais bien souvent, un sous-projet va être segmenté en plusieurs unités fonctionnelles. Parce qu’on veut développer rapidement les aspects essentiels de cette nouvelle fonctionnalité, mais que certains détails peuvent être repoussés à plus tard. On ne peut alors pas considérer le sous-projet comme étant un bloc unique sur lequel on va travailler d’une seule traite et sur lequel on ne reviendra jamais.
Faut-il prévoir qu’un sous-projet puisse être découpé en plusieurs sous-unités ? Arg, non, on en reviendrait à une gestion de sous-sous-projets, que j’ai éliminé précédemment.

À cela s’ajoute une notion essentielle, celle de livraison. La plupart des projets, qu’ils soient informatiques ou non, prévoient que plusieurs sous-projet − appartenant à des projets différents − soient mis en production (ou l’équivalent) en même temps. Comme faire pour gérer ça correctement si la seule vision disponible est projet par projet (ou sous-projet par sous-projet) ?

Labels et assimilés

À partir de là, j’ai commencé à réfléchir à encore une autre notion : On peut tout à fait avoir un élément (tâche, wiki, pièce-jointe) qui soit commun à plusieurs sous-projets, voire même à plusieurs projets. Tout n’est pas aussi segmenté qu’on le voudrait parfois. Une maquette graphique peut contenir des informations pertinentes pour plusieurs réalisation finales différentes.

Est-ce que la solution ne serait pas d’appliquer des labels (ou tags, si vous préférez) ? Imaginons une tâche «Mettre à jour MySQL» ; elle peut être dans le projet « IT », sous-projet « Maintenance », mais aussi dans le projet « Site Web », sous-projet « Performances ». En fait, si on y réfléchit bien, la tâche doit être effectuée, et en ce sens elle a une existence propre. Qu’on veuille la voir dans les projets « IT/Maintenance » ou « Site Web/Performances » n’est qu’une question d’organisation de l’information. Suivant les personnes impactées, il faudra qu’elle soit visible dans l’un ou dans l’autre.
Habituellement, on contourne ce genre de considérations en dupliquant les informations, mais je ne suis pas certain que le gain en simplicité (relative) à la création vaille la peine au regard de la plus grande complexité dans le suivi.

J’en arrive donc à penser que les projets et les sous-projets deviendraient des tags. Quand on navigue dans les projets et les sous-projets, on se retrouve simplement à filtrer les contenus qui sont affichés, pour ne voir que ceux qui portent le tag correspondant.
Première chose importante : On peut appliquer autant de tag que l’on veut à n’importe quel élément.

Mais si on revient sur la notion de «livraison» dont je parlais tout à l’heure, le problème reste entier. Mais… est-ce qu’une livraison (ou un jalon, ou une deadline, ou une release, appelez ça comme vous voulez) ne serait pas là encore une sorte de filtre, qui sert à ne voir qu’un sous-ensemble des informations d’un projet ? Bien sûr que si ! Pour définir un jalon, il suffit de créer un label (avec une date de fin), et de l’appliquer à tous les éléments nécessaires. Ainsi, pas de modification sur le découpage projets/sous-projets, et on peut facilement retrouver tous les éléments qui portent ce label.La même logique pourrait s’appliquer pour affecter des tâches à une ou plusieurs personnes. Il suffirait de placer des tags idoines.

Tiens, je pense à autre chose : Je ne sais pas pour vous, mais il m’arrive souvent de vouloir regrouper des informations ensemble, parce que j’en ai besoin temporairement. Et je ne le fais pas, parce que cela voudrait dire que tous les autres utilisateurs verraient ces changement dans l’organisation des projets. On pourrait imaginer des tags privés, qui permettrait d’organiser les choses sans pour autant modifier ce que les autres peuvent voir.

Dernière chose qui me semble intéressante, la possibilité de créer des tags dynamiques. Cela voudrait dire qu’on pourrait créer un tag qui soit lié à un autre, mais en ajoutant des informations de filtrage supplémentaire. Par exemple, je pourrais créer un tag lié à un sous-projet donné, mais qui n’en afficherait que les entrées de buglist (filtre 1) qui me sont affectées (filtre 2).

Au final, quels seraient les caractéristiques d’un label ?

• Sa visibilité (privé ou public). Un label privé n’est visible que par son créateur. Un label public est attaché au projet et tout le monde le voit.
• Son projet. Ou plus exactement, l’information de projet qu’il va transmettre aux éléments auquel il sera appliqué.
• Son sous-projet. Ou plus exactement, l’information de sous-projet qu’il va transmettre aux éléments auquel il sera appliqué.
• Ses dates de début et de fin.
• Son filtrage, c’est-à-dire les types d’informations visibles lorsqu’on utilise le label comme filtre d’affichage.
• Le label auquel il est lié.
• L’utilisateur concerné.
• Un texte libre, pour créer des tags au sens habituel du terme.

Labels, filtres, droits utilisateurs

Ce dont je viens de parler au sujets des labels et des filtres est valable d’un point de vue technique uniquement. D’un point de vue ergonomique, il faut proposer des fonctionnalités claires, pas simplement laisser les utilisateurs jongler avec leurs tags, car cela peut facilement porter à confusion.

Il faut quand même éclaircir la différence entre un label et un filtre. Si techniquement cela représente une seule chose, la différence se fait suivant qu’on soit en lecture ou en écriture.

Prenons l’exemple du projet « Anniversaire ». Il contient un sous-projet « Cuisine ». J’ajoute une tâche à ce sous-projet, lui donnant le titre « Préparer gâteau ».
La tâche possède donc automatiquement le tag « Anniversaire/Cuisine ». C’est à la création de la tâche que le label a été ajouté.
Maintenant imaginons que je crée un sous-projet « Moi/À faire », que je paramètre pour (1) n’afficher que les tâches et (2) celles qui me sont affectées. Lorsque je vais voir ce sous-projet, il va m’afficher toutes mes tâches, c’est alors un filtre.

Bon, mais si on gère tous les aspects techniques à travers un tel système de tags, il faut se poser quelques questions concernant la gestion des droits utilisateurs.
Dans tous les logiciels de gestion de projet, les buglists, et même les blogs multi-utilisateurs, il y a la possibilité de gérer «qui peut voir quoi» et «qui peut faire quoi». Il faudrait donc spécifier la relation que chaque utilisateur entretient avec les labels. Il peut être :

• Administrateur. Il peut modifier à loisir la définition du label, ainsi que tous les contenus qui portent ce label.
• Accès en lecture. Il peut accéder au label et voir tous les contenus qui le portent.
• Accès en écriture. Il peut accéder au label et voir tous les contenus qui le portent, mais il ne peut pas modifier la définition du label.

Ainsi, l’administrateur peut décider que le sous-projet « Musique/Concert » contient une liste de tâche et un partage de fichier, mais rien d’autre (pas de wiki, pas de buglist). Une personne ayant les droits en écriture peut ajouter, modifier et effacer des tâches et des pièces-jointes ; il ne peut pas ajouter une buglist dans ce sous-projet. Une personne ayant les droits en lecture peut lire les tâches et les pièces-jointes.
Ce sont les administrateurs  qui déterminent les droits des utilisateurs. Bref, quelqu’un qui a les droits Administrateur sur un label décide des droits des autres utilisateurs pour ce label. Pour que cela ne devienne pas trop répétitif, il faudra proposer une option à la création d’un sous-projet, pour donner les mêmes droits que sur le projet.

Cette gestion des droits me paraît être celle qui offre le meilleur rapport entre simplicité et souplesse. En contrepartie, il sera impossible de donner des droits du genre : autoriser la lecture des pages wiki mais pas leur modification, tout en autorisant la création d’entrées dans la buglist mais pas leur effacement. Est-ce vraiment un soucis ?

Tags à l’ancienne

Avec tout ça, je n’ai quasiment pas parlé de l’utilisation de tags comme on a l’habitude de le faire… Pour tagguer les contenus, quoi. Ajouter une information sur certains contenus afin d’en faciliter la recherche.

J’avais en tête un système légèrement différent de ce qu’on trouve en temps normal. Je m’explique.
La plupart du temps, les systèmes de tag sont assez simples : on peut assigner des labels textuels à des contenus. Et c’est tout. Il n’y a pas de contexte (le tag « pouet » a la même signification quel que soit l’endroit où il a été placé). Il n’y a pas de suggestion réelle (éventuellement une liste des tags les plus utilisés, mais toujours hors contexte). Bref, je trouve personnellement que ces systèmes ne font pas gagner beaucoup de temps. Si on veut filtrer les données en utilisant les tags, c’est un peu galère. Si on veut faire une recherche, autant utiliser une recherche full text.

J’imaginais donc de pouvoir associer des listes de tags « préférentiels » aux différents éléments. Prenons un exemple :

• Le projet « Vacances » possède le tag « prix ».
  • Le sous-projet « Activités » possède les tags « enfants » et « adultes ».
    • Un groupe de pages de wiki possède les tags « proposition », « accepté » et « refusé ».
    • Une liste neutre (une liste simple, ni une liste de tâche, ni une buglist) possède les tags « réservé » et « à fuir ».

Ainsi, il serait possible de créer une page de wiki et de lui assigner les tags « enfant » et « proposition ». Ou un élément de liste avec les tags « prix », « enfants » et « réservé ». Ensuite, il serait possible de filtrer l’affichage pour ne faire apparaître que les éléments qui possèdent un ou plusieurs tags parmi ceux disponibles.

Mais… Si on peut appliquer des tags à un projet (pour que ceux-ci soient applicables aux éléments du projet, vous suivez ?), cela veut dire qu’on doit pouvoir tagguer un tag…

On va peut-être se calmer

Sauf que là je commence à imaginer une espèce d’usine à gaz où tout est fait à base de tags. Les projets sont des tags, les sous-projets sont des tags, l’assignation d’une tâche à quelqu’un se fait en ajoutant à la tâche un tag représentant la personne, les deadlines sont aussi des tags, ainsi que le « filtrage ».
On risque d’avoir même des tags sur plusieurs niveaux (des tags de tags). Et encore, je n’ai pas parlé de la gestion des groupes d’utilisateurs…

Tout ça semble bien beau d’un point de vue théorique, mais peut-être moins évident à implémenter qu’avec une base de données un peu plus relationnelle.

Pour conclure

Wow, cet article est quand même vachement long. J’ai mis plusieurs jours à l’écrire. Il m’a servi à éclaircir mes idées sur certaines choses, mais à force de pousser ma réflexion cela m’a amené à un point où tout s’écroule un peu. Voilà pourquoi j’ai du mal à faire avancer le projet Skriv, je cogite peut-être trop.

Je suis en train de réfléchir à la meilleure manière de gérer le partage de fichiers dans un projet.

Moyens de stockage

Pour commencer, je veux faire en sorte que chaque projet puisse stocker ses fichiers sur un espace géré (et payé) par l’utilisateur. Cela pourrait être un serveur FTP, un serveur WebDAV ou un espace sur Amazon S3.
Comme déjà dit auparavant, cela permet d’offrir des fonctionnalités complètes, sans avoir à se mettre dans une relation client/fournisseur. La plupart des entreprises ont déjà un serveur FTP ou WebDAV. Et plutôt que de faire payer pour « sous-louer » un espace sur Amazon S3, avec des paliers tarifaires en fonction de forfaits d’espace disque, autant laisser les gens s’abonner par eux-même et payer en fonction de leur utilisation.

Toutefois, je pense finalement offrir un tout petit espace disque (5 MO, par exemple) à ceux qui veulent découvrir le service sans se prendre la tête.

Principe général

Donc voilà en gros ce que j’imagine :

1. Quand on crée un projet, on spécifie les paramètres d’accès à un stockage distant de données (FTP, WebDAV ou S3).
2. Sur la page de projet, on peut créer plusieurs « groupes de fichiers ». Pour chaque groupe est créé un nouveau dossier sur le stockage distant.
3. On peut uploader des fichiers dans un groupe. Le fichier apparaîtra dans ce groupe avec toutes ses caractéristiques (miniature si c’est une image, nom du fichier, nom du créateur, date d’ajout, taille du fichier, commentaires éventuels), et son binaire sera ajouté dans le dossier dédié sur le stockage distant.

Je me pose une question : Faut-il se contenter d’afficher le nom du fichier tel qu’il a été uploadé ? Ne vaudrait-il pas mieux proposer un champ libre, pour décrire son contenu mieux que ne le fait son nom ?
Hum, je pense que si… mais cela doit rester optionnel. Si on ne remplit pas ce champ, le nom du fichier sera affiché tel quel.

Idéalement, il faudrait pouvoir créer une sous-organisation à l’intérieur des groupes de fichiers. Cela pourrait prendre la forme simple de sous-dossiers. Mais cela pourrait aussi être des tags (je préfère le terme “label”) que l’on affecterait aux fichiers. On pourrait ainsi trier par label, par date ou par nom.

Par contre, il n’y a rien de plus pénible que de devoir systématiquement taper les noms de labels au clavier. Même avec un système de complétion, c’est chiant.
Je pense donc qu’il faudrait, pour chaque groupe de fichiers, pouvoir créer des labels à l’avance. Ainsi, au moment d’ajouter un fichier, il n’y aurait qu’à cocher le ou les labels à lui affecter (et éventuellement la possibilité d’en ajouter à ce moment-là). Pour l’affichage des fichiers, cela simplifierait aussi les choses : il suffirait là encore de cocher le ou les labels qui nous intéressent pour voir la liste des fichiers qui y correspondent.

Version des fichiers

Je me demande s’il est vraiment utile de prévoir une gestion des versions des fichiers. En y réfléchissant rapidement, je ne pense pas avoir jamais eu besoin de ce genre de fonctionnalité. Sûrement parce que l’usage du partage de fichiers dans mon entreprise est spécial : On y stocke uniquement les documents « stables » ou historiques ; ceux qui sont en cours de modification sont édités dans un wiki (où l’historique est par contre très utile).

Mais je peux imaginer que dans certains cas, pour certaines personnes ou entreprises, ce soit absolument nécessaire. Dans ce cas-là, l’ergonomie de Basecamp me paraît pas mal, autant s’en inspirer.

Micro-blogging et upload en vrac

Il y a deux cas un peu spéciaux à mes yeux : Lorsqu’on joint un fichier avec un message de micro-blogging, et quand on veut uploader rapidement un fichier, sans trop se préoccuper de là où il va être stocké.

Je parlerai plus longuement du micro-blogging dans un autre post. Mais le fait est qu’on doit pouvoir joindre un ou plusieurs fichiers avec chaque micro-message. Que se passera-t-il dans ce cas ?
Première possibilité : On doit choisir le groupe de fichiers qui va l’accueillir. Ça a le mérite d’être clair, mais pas forcément très ergonomique.
Deuxième possibilité : Le fichier va dans un espace mystérieux (appelons-le «le warp») qui est en dehors des groupes de fichiers définis dans le projet.

Le cas de l’upload rapide est très similaire. En fait, j’imagine qu’on voudra pouvoir ajouter des fichiers à un projet à partir d’interfaces simplifiées. Cela pourrait être une application sur téléphone portable, ou une extension dans son navigateur web. L’idée est vraiment de se dire «Tiens, il faudrait que je regarde ça ; je l’ajoute au projet et je le regarderai plus tard».
Je pense que là encore le fichier partira dans «le warp».

Alors c’est quoi, ce Warp ? Une espèce de groupe de fichiers par défaut, qui contient tout ce qui n’est pas catégorisé. Quand il est vide, on ne sait même pas qu’il existe. Quand il y a des fichiers dedans, ils sont listés tout en bas de la page de projet, avec la possibilité de les déplacer vers un autre groupe de fichiers pour les classer proprement.

Modification directe des fichiers

Le fait de passer par un stockage distant présente un certain inconvénient. Il est possible d’y accéder sans passer par Skriv. N’importe qui pourrait accéder directement au serveur FTP, ou monter l’accès au WebDAV directement sur son bureau, et modifier les fichiers.

J’ai essayé un moment de réfléchir à une solution qui autorise cet usage et qui en fasse quelque chose d’utile. Mais au final je ne pense pas qu’on puisse s’en sortir correctement. Le risque est trop grand de rendre un fichier indisponible pour Skriv. Donc on va oublier cette idée.

Comme vu précédemment, l’une des fonctionnalités de base de Skriv sera la possibilité d’y ajouter des listes.

J’imagine globalement 3 types de listes (les éléments en italique sont optionnels) :

• minimales : La liste a juste un titre. Chaque entrée de liste ne contient qu’un titre et une description. Utile pour prendre des notes, ou pour faire une checklist.
• simples : La liste a un titre, une date de début et une date d’échéance. Chaque entrée de liste contient un titre, un état (à faire / fait) et une description. Utile pour lister rapidement les tâches d’un sous-projet.
• complètes : La liste a un titre, une date de début et une date d’échéance. Chaque entrée de liste contient un titre, un état (à faire / fait), une description, une importance (basse, moyenne, haute, critique), un responsable, une date d’échéance, un état d’avancement (en pourcentage). Utiles pour faire une vraie todo-list ou une buglist.

Quelques fonctionnalités sont générales à tous les types de listes :

• Les entrées de liste peuvent être déplacés les unes par rapport aux autres par drag and drop. Idéalement (en fonction de la complexité technique) une entrée de liste pourra être déplacée d’une liste à une autre par drag and drop ; elle s’adaptera alors aux caractéristiques de la liste qui la réceptionnera.
• On enregistre la date de création et le nom de l’utilisateur qui a créé l’entrée de liste. Ces informations seront disponibles (par exemple dans une infobulle).
• Les descriptions associées aux entrées de liste utilisent une syntaxe Wiki.
• Il est possible d’ajouter des commentaires aux entrées de liste. Le commentaires utilisent une syntaxe Wiki.
• Il est possible d’ajouter des pièces-jointes aux entrée de liste et aux commentaires. Les pièces-jointes peuvent être des fichiers déjà présents sur le partage, des fichiers que l’on uploade à ce moment-là, des emails, des URLs.
• Les entrées de liste avec un état (à faire/fait) ont une case à cocher devant leur titre. Quand on clique sur la case à cocher, le titre est barré, et l’entrée est déplacée en fin de liste. En décochant la case, le titre n’est plus barré, et l’entrée est déplacée à la fin des tâches « à faire » (au-dessus des tâches « faites »).
• Les entrées de liste ayant un responsable possèdent une fonctionnalité de «harcèlement», qui sert à envoyer un message au responsable.

Ma vision

La plupart des outils de gestion de projet proposent une liste de tâches ; certains y ajoutent une buglist en plus. Les logiciels orientés « diagramme de Gantt » découpent les projets en sous-projets, qui sont eux-mêmes constitués de tâches.

Dans l’outil que j’utilise actuellement dans mon entreprise, nous avons aussi une todo-list et une buglist séparées. La todo-list est linéaire, elle contient une suite de tâches dont on peu définir un certain nombre de paramètres (responsable, avancement, criticité, urgence, deadline, …). Malheureusement, le concept de “sous-projet” manque, ce qui oblige souvent à créer des tâches dont la description contient une liste de sous-tâches.

Pour Skriv, j’imagine que l’on créera plusieurs listes pour créer autant de sous-projets. Pourquoi alors ne pas directement appeler ça des «sous-projets» ? Parce que ça me semble peu flexible. Dans certains cas, on voudra gérer plusieurs listes, sans les associer à une notion de sous-projet.
Je veux que ce soit l’outil qui s’adapte à notre vision, et non l’inverse. Si on veut signifier des choses différentes, il suffira d’utiliser l’outil de manière différente. C’est quand même mieux que d’être obligé à faire tenir nos propres concepts à l’intérieur de ceux de l’outil.

Qu’en pensez-vous ?

Je sollicite maintenant l’aide des lecteurs de ce blog. Comme vous le savez, je travaille sur Skriv, un outil aux multiples facettes : gestion de projets, gestion de documentation, prise de notes, bookmarks, wiki, calendrier, micro-blogging, …

Je bute actuellement sur un truc tout bête : Comment appeler les choses ?
La solution la plus simple serait d’utiliser les termes habituellement utilisés par ce type de logiciel. On aurait ainsi des projets, des listes de tâches, des contacts, des (micro-)messages, des documents et ainsi de suite.

Mais je pense qu’on devrait pouvoir trouver une terminologie plus adaptée. Je vois plusieurs raisons à cela :

1. Des termes liés au cadre professionnel seront parfait pour une utilisation professionnelle. Par contre, pour une utilisation personnelle ou « alternative » (dans un cadre familial ou associatif, par exemple), c’est un peu trop formel à mon goût.
2. L’utilisation d’analogies facilite la prise en main. Ce n’est pas un hasard si les interfaces graphiques utilisent des termes comme « bureau », « dossier » ou « document » ; cela permet aux nouveaux utilisateurs de comprendre rapidement ces concepts en faisant le parallèle avec des notions bien connues.
3. Les noms des fonctionnalités ne doivent pas être obligatoirement descriptifs. On a l’habitude d’écrire des «tweets» (et non pas des micro-messages), par exemple.

L’idée serait de créer de nouveaux automatismes, compréhensibles immédiatement, originaux tout en restant logiques. Avez-vous des suggestions ? J’avoue avoir du mal à trouver de l’inspiration.

• Le logiciel Backpack gère des «pages». Cet outil reste une grande source d’inspiration pour moi. Mais j’ai peur que cette terminologie n’aide pas à faire la distinction entre les projets et les pages de wiki qu’ils contiennent.
• On peut imaginer de faire un rapprochement avec des éléments physiques. Un projet deviendrait un «casier», un micro-message serait un «mémo», le wiki serait un «bloc-notes»… Mais ce n’est pas terrible, hein.
• On pourrait aussi utiliser des noms abstraits. J’ai développé un outil de micro-blogging, utilisé en interne dans mon entreprise ; les messages sont des «blips» (pas super-original comme nom, mais j’aime bien). Mais j’ai du mal à trouver des noms corrects pour symboliser les projets.

Toute aide est la bienvenue !
Merci d’avance.

Alors, j’ai commencé par discuter de l’accès au service et de son prix. Maintenant il serait bon de s’attacher au cœur du problème : à quoi va-t-il servir exactement, quelles vont être ses fonctionnalités ?

Je voudrais définir un outil qui puisse servir aussi bien pour gérer des projets professionnels que personnels. Je dois avouer que la plupart de mes projets personnels ressemblent furieusement à des projets informatiques, mais ce n’est pas une règle absolue.
Comme je l’ai dit en commentaire du précédent billet, la vision que j’ai de Skriv est celle d’un outil de travail collaboratif plus que d’un outil de gestion de projet. Je ne souhaite pas faire un logiciel qui servira uniquement aux “décideurs” pour suivre le travail de leurs employés ; je veux faire le méga-tableau-de-bord qui servira tous les jours (et plusieurs fois par jour !) à l’ensemble de mes collaborateurs pour organiser leur travail, pour communiquer sur tous les aspects de leur travail.

Fonctions de base

On peut reprendre les 4 grands types de fonctionnalités habituelles :

• Un affichage “tableau de bord” qui affiche l’activité récente sur un projet ou sur tous les projets auxquels l’utilisateur a accès.
• Les listes. Il faut pouvoir créer autant de listes que nécessaires, avec la possibilité de les adapter aux besoins (buglist, todolist, checklist).
• Les pages de documentation textuelle. Appelons ça un « wiki », même si j’hésite entre l’utilisation d’une syntaxe de type wiki et l’utilisation d’un éditeur HTML WYSIWYG. Il faut pouvoir lier une page de wiki à une tâche.
• Le partage de fichiers. Chaque projet a bien souvent besoin de fichiers binaires, qu’il s’agisse de feuilles de calcul, d’images ou autres. Il faut pouvoir lier un fichier à une tâche.

Fonctions supplémentaires

Ce qu’on peut y ajouter :

• Des “vues” calendaires, mais je place ça plutôt dans la partie ergonomie/affichage. Cela reste important, surtout si on se sert de ces vues pour éditer les tâches (ce qui revient plus ou moins à avoir un diagramme de Gantt).
• Des rappels par email ou SMS, que ce soit pour nous rappeler des tâches (todolist/buglist de projet) ou définis personnellement.
• La connexion à un compte IMAP. Il y a toujours des informations importantes qui sont échangées par email (même si ce n’est pas une bonne pratique). On pourrait dédier un dossier IMAP à chaque projet, et y accéder via l’interface. On pourrait trouver un moyen pour créer des tâches à partir d’emails, et extraire les pièce-jointes des emails pour les ajouter au partage de fichiers.
• Un système de micro-blogging. Même si j’ai déjà fait part de mon scepticisme vis-à-vis de ce genre d’outil, il y a sûrement moyen de créer un canal de communication supplémentaire. Les micro-messages seraient affichés sur le “tableau de bord” au milieu des indications d’évolution du projet.

Concernant la «communication» :

• On pourrait imaginer que le logiciel pourrait envoyer des emails avec un résumé quotidien ou hebdomadaire des évolutions d’un ou plusieurs projets qu’on aurait décidé de « suivre ».
• Il faudrait proposer des flux RSS permettant aux utilisateurs de suivre leurs projets dans un outil externe. Un flux qui reprenne l’activité de tous les projets, un flux pour l’activité des projets “suivis”, et un flux par projet.
• Il faudrait aussi proposer un export au format ICS (iCalendar), pour permettre de suivre les tâches et les projets dans un outil externe comme iCal, Sunbird ou Google Calendar.

Fonctions à intégrer ?

J’hésite encore sur certaines fonctionnalités :

• Gestion des compte-rendus d’activité. Je sais que c’est vraiment nécessaire pour certaines entreprises, celles qui factures leurs clients en fonction du temps passé sur les projets. Et, de manière générale, il est toujours bon de savoir combien aura coûté un projet. Mais j’ai un peur peur de complexifier l’ensemble du logiciel pour une fonctionnalité qui n’est pas utile à tout le monde.
• Un forum de discussion propre à un projet peut parfois être très utile, surtout pour les équipes qui sont éclatées géographiquement. Mais je me dis que si le système de micro-blogging est bien fait, et qu’il autorise les vrais fils de discussion, il n’y aura pas besoin de faire un forum séparé du reste.
• Une édition collaborative simultanée en temps réel des pages de wiki. Un outil comme EtherPad permet de travailler à plusieurs sur le même document, en même temps. Mais c’est quand même un niveau de complexité bien supérieur, pour un usage qui reste encore à démontrer, je pense.
• Permettre de créer des dessins directement dans l’interface, par exemple en utilisant un outil comme FlockDraw. Un dessins vaut souvent mieux qu’un long discours. Alors c’est souvent intéressant d’ajouter des diagrammes explicatifs dans les fichiers d’un projet. Habituellement, il faut utiliser un logiciel de dessin, enregistrer l’image puis l’uploader sur le projet. Si on pouvait directement dessiner ”online”, ce serait plus pratique, non ?

Fonctions à ne pas intégrer

Ce que Skriv ne sera jamais :

• Un carnet d’adresse.
• Un calendrier complet pour gérer ses rendez-vous.
• Un CRM.
• Un outil de gestion de code source, d’édition de code, de profiling, de déploiement à distance, …
• Un serveur d’intégration continue.
• Un outil de facturation ou un ERP.

Avez-vous des idées de fonctionnalités qui vous semblent nécessaires, en plus de celles-ci ?

J’ai rassemblé sur ce billet deux sujets différents et au final pas très importants − par rapport aux fonctionnalités ou à l’ergonomie, par exemple − mais dont je voulais parler quand même. Comme ça on pourra ensuite se concentrer sur le plus important.

Création de compte et identification

Il faut évidemment permettre la création de compte directement sur le site. Mais ce serait une bonne idée d’autoriser l’identification par des procédés d’authentification centralisés. Le premier qui me vient à l’esprit est OpenID, qui est un protocole standard prévu exactement pour cela. On peut y ajouter le Google Federated Login (basé sur OpenID), Yahoo! OpenID, Windows Live ID (basé sur OpenID lui aussi), l’identification centralisée de Twitter (utilisant OAuth), ou encore Facebook Connect.

Ces systèmes permettent de créer un compte quasi-instantanément. Il suffit de cliquer sur le bouton « Google », on arrive sur une page chez Google qui nous demande si on veut continuer (pour peu qu’on soit déjà identifié chez Google), on clique sur « Oui », et hop ça y est. C’est assez séduisant.

Ensuite, il faut voir la complexité d’implémentation de chaque protocole. Google, Yahoo! et Windows Live ne supportent que l’OpenID version 2. Ça a l’air idiot, mais les bibliothèques de connexion OpenID ne sont pas si nombreuses en PHP. Il en existe une très simple, qui fonctionne très bien, mais uniquement pour OpenID 1. Il en existe une autre, très complète mais lourdingue à mettre en place, qui est censée être pleinement compatible avec OpenID 2 (mais qui ne semble quand même pas fonctionner avec Google ni Yahoo!).
Pour Google, ce n’est pas un problème : Le Google Federated Login est très bien documenté, et j’ai trouvé une librairie qui s’y connecte directement, sans assurer de compatibilité OpenID, et ça fonctionne très bien.

J’hésite beaucoup pour Facebook. Vu le nombre de personnes ayant un compte Facebook, ça semble intéressant. Mais Facebook Connect est quand même assez galère à mettre en œuvre. Il faut créer une application, et les utilisateurs doivent accepter que cette application accède à leur compte. Et il faut mettre en place du cross-site scripting, pour que la partie Javascript de l’identification puisse accéder aux deux sites sans perdre de cookie. Bref, c’est casse-bonbon.
Mais il reste un espoir : Facebook s’est rallié au protocole OpenID. Pour l’instant, il n’est pas possible d’utiliser Facebook comme serveur OpenID, mais cela pourrait arriver à l’avenir.

Concernant Windows Live… Bah si ça fonctionne, c’est tant mieux. Si ça ne marche pas, je ne vais pas pleurer, je n’ai pas l’impression que ce soit un besoin si important que cela.

Pour résumer, la priorité est pour moi d’offrir l’identification par OpenID 1.0, Google, et si possible Twitter. Bref, ceux qui peuvent être mis en place facilement, et pour lesquels il existe des librairies faciles à utiliser. Si c’est pour déployer des usines à gaz et perdre du temps qui serait utile au développement des vraies fonctionnalités, autant laisser tomber.

Coûts et prix

Comme je l’ai déjà dis auparavant, je suis attaché au fait de ne pas faire payer l’accès au service. Je suis toujours éberlué de voir des outils faire payer pour des choses qui n’ont aucun coût réel, comme l’encryption SSL, le nombre d’utilisateurs autorisés, le nombre de projets gérés, le nombre de pages, …

Évidemment, avoir un serveur qui tourne et qui héberge le service a un coût. Mais on va simplifier les choses à ce niveau. J’ai déjà un serveur qui fait tourner un certain nombre de sites. De la même manière, toutes les données textuelles sont stockées en base de données ; elles prennent de la place sur disque. Mais là aussi, on peut se dire que c’est assez négligeable.

Par contre, il y a des fonctionnalités qui peuvent avoir un coût direct en fonction de leur utilisation. Et dans ce cas, je préfère laisser aux utilisateur le contrôle de leurs dépenses. J’ai pour le moment 2 cas précis en tête :

• Le stockage de fichiers. Il y aura sûrement la possibilité d’associer des fichiers aux projets gérés dans Skriv. Et ça peut vite représenter des centaines de méga-octets, voire des giga-octets. Plutôt que de prévoir une gestion de l’espace disque sur le(s) serveur(s), et de facturer cet espace (à quel prix ?), il me semble plus simple de laisser chacun se créer un compte sur Amazon S3. Ainsi, chaque utilisateur paiera directement à Amazon en fonction de la taille des données stockées et de la quantité transférée.
• L’envoi de SMS. Je n’ai pas encore bien en tête la fonctionnalité qui irait derrière, mais on peut imaginer un « reminder » qui fonctionne aussi bien par email que par SMS. L’envoi de SMS a un coût directement lié au nombre de SMS envoyés. Là encore, les utilisateurs qui comptent utiliser cette fonction pourraient s’abonner à un service comme SMSMode ou Clickatel, puis enregistrer leurs paramètres.

Au sujet d’Amazon Web Services, on pourrait imaginer y stocker la base de données, et laisser ainsi chaque utilisateur payer en fonction de la quantité de données stockées (comme pour les fichiers stockés sur S3). Mais non seulement cela obligerait tous les utilisateurs à devoir se créer un compte sur Amazon − et le configurer correctement −, mais en plus cela ralentira l’ensemble du fonctionnement du service (quoi qu’on en dise, rien n’est plus rapide qu’une base de données qui tourne en local).

Pouvez-vous imaginer d’autres cas ? Quels peuvent être les coûts qui se cachent dans un web-logiciel de ce genre, et comment pouvons-nous les contourner intelligemment ?

Quasiment depuis que je travaille, j’ai développé des outils pour suivre les projets ou traiter les bugs. Comme j’ai souvent bossé dans des entreprises de petite taille, pour ne pas dire des start-ups, ces outils comblaient des manques évidents et étaient adoptés rapidement.

• Il y a maintenant un paquet d’années, j’avais fait un gestionnaire de buglist. Doté d’une interface web, il était écrit en C et stockait ses données dans un fichier XML. Technologiquement, ce n’était pas une très bonne idée, mais c’était l’occasion de tester des librairies XML et CGI que j’avais écrites en C. Au niveau des fonctionnalités, je ne me souviens plus trop. Je crois que c’était assez simple, avec pour chaque bug le niveau de criticité, une description, et le projet affecté.
• J’avais par la suite repris le même genre d’outil, mais écrit en PHP/MySQL. Pus facile à faire évoluer, je n’ai pas souvenir qu’on l’ait utilisé à son plein potentiel.
• Dans mon entreprise actuelle, j’ai dès le début mis en place des outils open-source, les plus important étant Flyspray pour la buglist et MediaWiki pour le wiki. Depuis, j’ai développé des extensions MediaWiki qui nous servent à gérer les projets. Ainsi, chaque projet a une page dédiée sur laquelle apparaissent : la liste des bugs du projet, une liste de tâches, des pages wiki liées au projet, et des fichiers en « pièce-jointe ».

Cette extension est clairement inspirée par Backpack. J’aime vraiment ce logiciel. Par rapport à d’autres outils plus orientés « projet », comme Basecamp par exemple (pour reprendre un autre logiciel développé par 37signals), j’apprécie le fait que toutes les informations soient regroupées sur une seule page.
Habituellement, les logiciels de gestion de projets offrent plusieurs vues différentes, chacune pour un type d’information. Il y a un onglet pour les tâches, un onglet pour le calendrier, un onglet pour les bugs (si l’outil les gère), un onglet pour les pages de wiki (si c’est disponible), un onglet pour les fichiers, et ainsi de suite.
Pour ma part, je préfère avoir la vue la plus « intégrée » possible. Cela implique de penser l’interface en conséquence, ce qui peut s’avérer plus délicat qu’il n’y paraît.

Je cherche donc maintenant à définir un outil que je pourrais utiliser aussi bien pour mes besoins en entreprise, que pour gérer mes projets personnels. Je vais donc m’intéresser à chaque aspect d’un tel logiciel dans une série de billets sur le blog. Je ferais appel aux avis des lecteurs du blog, en espérant réussir à dégager des principes clairs de fonctionnement. J’espère aussi trouver le temps de développer ce logiciel, pour que tout cela ne reste pas théorique (d’un autre côté, si un autre outil est développé à partir de spécifications dérivées de mes idées, je n’y verrais aucun problème, bien au contraire).

Ah, au fait, pourquoi appeler ce projet «Skriv» ? C’est un nom que j’affectionne, que j’ai donné par le passé à plusieurs logiciels que j’ai développé. Le plus important était une interface web qui intégrait un webmail, un gestionnaire de bookmarks, un bloc-notes, un carnet d’adresses, une gestion de compte bancaire. Je l’utilisais tous les jours pour centraliser ma vie numérique. De nos jours, c’est assez commun ; mais à l’époque où je l’ai développé (en 2002), c’était assez novateur.
Pour le nom lui-même, il signifie « écrire » dans plusieurs langues comme le breton et le suédois. Ça va bien dans l’idée d’un outil qui sert principalement à communiquer.