Ebauche de spec

  • Le système devra être multi-utilisateur. Pour chaque utilisateur, il devra permettre d'établir un profil basique, des statistiques d'utilisation ainsi que le rôle de l'utilisateur (guest, student, moderator, professor, admin).

  • Les utilisateurs auraient la possibilité d'uploader des documents. Ces derniers seraient disponibles pour les étudiants authentifiés en format pdf (donc s'il s'agissait d'un autre format à l'origine, il y a conversion). La plateforme implémenterait un système de découpage de document par page, permettant de visualiser le document page par page online ou de n'en downloader qu'une partie (par exemple, de la page 10 à 100 d'un document de 300 pages).

  • Les utilisateurs auraient la possibilité d'annoter les pages des documents. Les annotations seraient de plusieurs types (par exemple question, erratum, remarque, explication…). Les utilisateurs auraient la possibilité de commenter les annotations des autres (→ ça formerait un thread). Il y aurait plusieurs moyens de visualiser les commentaires des utilisateurs (par exemple, voir les discussions comme si c'était une section d'un forum ou de voir les discussions relative à une page d'un cours).

  • Les utilisateurs auraient un karma, un nombre de points dans le système. En uploadant un bon résumer, en faisant des bonnes annotations ou réponses, un utilisateur pourrait voir son karma augmenter en recueillant les votes positifs d'autres utilisateurs. (reddit-style)

  • Toutes les ressources (documents, annotations, réponses…) seraient mise en avant proportionnellement aux votes positifs qu'elles ont reçu. L'objectif de se mécanisme est de faire de l'auto-classement et de l'auto-modération.

  • Les annotations pourraient aussi être un lien entre deux ressources (document, commentaires d'une autre annotation..). Par exemple, si dans un cours, il y a comme document un ancien examen et le syllabus de cours, il pourrait etre util de faire un lien entre chaque question de l'examen et la partie du cours qui le traite pour facilité la navigation des utilisateurs.

  • Il faudrait une fonction recherche éfficace. Dans toutes les ressources. Il faudrait aussi que la recherche soit disponible par lien et pas uniquement par un formulaire de recherche.

  • Certaines annotations/commentaires seraient éditables. Tout serait archivé. Une partie du contenu généré par les utilisateurs serait un wiki déguisé.

  • Chaque action utilisateur sauf le vote serait mise en avant dans un log public, un wall. L'objectif est de favoriser l'émulation.

  • Ce wall devra être accessible en RSS. Il devra être filtrable par l'url. Par exemple, feed.rss?cours=infof307+mathh404 devrait reprendre toutes les actions faites dans les deux cours.

  • En fonction du bon vouloir des autorités de l'ulb, l'authentification devrait ce faire sur le NetID. Sinon, le système devrait interdire l'usage d'email hors ULB.

  • En fonction du bon vouloir des autorités de l'ulb, le système devrait intégrer les horaires du cours.

  • En fonction de la disponibilité des données au BES, le système devrait intégrer les archives de candiULB.

Le groupe de personne derrière cette ébauche de spécifications proposent aussi les guidelines suivantes :

  • le site devrait être en python et employer django.

  • le développement devrait se faire sous git et demander régulièrement du feedback aux partenaires

  • la license du site devrait être agpl

  • le site ne devrait pas reprendre des features existants déjà. (par exemple, hors de question d'implémenter un système de messagerie interne, le système devrait mettre en avant l'usage de l'email).

La mise en oeuvre du projet se déroulerait en trois phases :

  • Jusqu'au 30 octobre, validation des spécifications avec les différents partenaires (CdS, CI, BES, CGeo, Agro, Foscup)

  • Novembre, décembre, février : implémentation d'un prototype fonctionnel.

  • Mars : Déployement du prototype et évolution en version finale.