Skriv : Partage de fichiers

(ce billet fait partie d'un ensemble consacré au projet Skriv)

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.