Skriv : Partage de fichiers

AmaurySkrivLaissez un commentaire sur 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.

Skriv : Fonctionnalités

AmaurySkrivLaissez un commentaire sur Skriv : Fonctionnalités

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

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.

Skriv : Identification et prix

AmaurySkriv12 commentaires sur Skriv : Identification et prix

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

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, …