Outil de travail

StoryTools : un outil d’aide à l’écriture interactive

Open Source et Libre

Toutes les versions de cet article : [English] [français]

Le 14 janvier dernier, dans une salle de l’Open Documentary Lab du MIT, nous sommes une bonne dizaine autour d’un projet fou, d’un projet simple : et si nous réfléchissions à la création d’un outil d’aide à l’écriture interactive. Un outil open source, ouvert à tous.

Sélectionnez un passage du texte et twittez-le directement

Dans la salle, des designers comme Jeff Soyk (UX architect sur Hollow), des étudiants comme Deniz Tortum, des fellows comme Isabelle Raynaud (auteure de « Lire et écrire un scénario », Armand Colin, des développeurs comme Cindy Bishop, des réalisateurs comme Thorsten Trimpop, Sarah Wolozin, la directrice du OpenDocLab. Notre désir : construire un outil d’aide à la conception interactive qui soit utile à tous les acteurs d’un projet non linéaire — réalisateurs, scénaristes, designers, développeurs et producteurs.

C’est la clé : s’assurer que chacun comprenne bien les besoins des autres membres de l’équipe, à tous les stades d’un projet.

Le constat, il est simple : nous avons besoin de nouveaux outils pour nos narrations non-linéaires.

Aujourd’hui, un traitement de texte semble mal adapté pour raisonner en termes de récits éclatés, de base de données, et recherches interactives. Word ou GooDoc sont trop linéaires. Excel trop ennuyeux et tout sauf inspirant. Scrivener est merveilleux, mais pour une utilisation solo. CeltX, trop tourné vers le cinéma. Il nous faut inventer le bon outil de production pour nos nouveaux récits.

Nom de code de notre outil : StoryTools.

Comme l’a résumé Isabelle Reynaud, l’idée de StoryTools serait de créer une conversation entre tous les membres d’une équipe de production non linéaire comme entre un réalisateur et son monteur : ce moment où tout le projet change.

A 10h, le café est chaud ; la salle remplie. C’est l’heure d’une présentation rapide de ce à quoi StoryTools pourrait répondre :

D’abord, un rappel comme une évidence : les outils ne font pas l’histoire. StoryTools ne remplacera jamais un bon scénario, des personnages forts, un concept innovant. Mais StoryTools pourrait vous aider à concevoir et à produire votre projet. Des les toutes premières phases de votre travail.

Dans les projets interactifs, on retrouve certaines caractéristiques communes. Ce sont sur celles-ci que StoryTools pourrait s’appuyer :

  • La Base de données (événements, médias) est l’histoire, comme les séquences le sont pour le cinéma.
  • Nous créons des événements d’histoires, des « blocs », un univers. La navigation est affaire d’espace autant, sinon plus, que de temporalité.
  • Nous procurons une expérience à l’utilisateur, en plus d’une émotion et/ou de l’information comme dans un film.
  • Un projet non linéaire est en perpétuelle évolution. StoryTools devra aider à réfléchir à comment l’interactivité nourrit l’histoire et inversement. Ceci est aussi valable en documentaire qu’en fiction.
  • Un développeur a besoin de savoir : quelles sont les fonctionnalités à mettre en place ? Et quel est le temps nécessaire pour les développer une à une ?
  • Nous manipulons un grand nombre de fichiers.

La suite vous appartient. Par email ou en commentaires.

Le groupe StoryTools a prévu de se réunir entre une à deux fois par mois d’ici fin mai. Ce blog est autant un lieu d’informations que d’échanges. Chacun est le bienvenue.

Vous embarquez ?


Voir en ligne : La première réunion


Vos commentaires

  1. Laurent

    Il me manque un outil pour collecter/structurer/tester/gérer :
    - Collecter : rassembler de manière très lisible les sources de chaque aspects/chapitres du sujet. Un peu comme le chuter d’un banc de montage
    - Structurer et organiser : le plan de montage des éléments précédents organisés en pages/scènes/chapitres, puis en arborescence et hiérarchie.
    - Tester : un moyen de naviguer à travers la structure créée et d’en tester les étapes point par point. Un peu comme Twine permet de le faire. Ca permet de se rendre compte du rythme de narration.
    - Gérer : rétro-planning, tâches principales et sous-tâches et leur état. Les infos apparaissent dans un document synthétique mais soient aussi visibles sur chaque partie du projet dans lesquelles interviennent les équipiers ainsi que l’état d’avancement de chacun.

    Des logiciels font ça chacun dans leur coin :
    - Omnigraffle : super pour les schémas logiques. Dans le genre, il y a aussi Grafio sur iPad (http://www.tentouchapps.com/grafio)
    - AppCooker : mockup interactif, budget et suivi de projet, fonction bloc note pour noter des idées. http://www.appcooker.com

    L’important pour moi reste la lisibilité générale de l’outil. Simple et dépouillé au niveau de l’interface. Comme cette appli de journal, Day One qui permet beaucoup avec peu de fonctions bien pensées (http://dayoneapp.com) ainsi qu’un outil de to-do-list/gestion de projet tout aussi dépouillé, Focus (http://www.mobeera.com/focus/).

  2. Florent Maurin

    Allez je me lance, avec mon modeste retour d’expérience d’écriture.

    - je commence par poser un game concept. Un doc word très simple, quelques lignes, qui comporte
    un pitch de l’histoire
    les principales mécaniques de gameplay
    les variables
    les conditions de victoire/défaite
    une reco (les sources d’inspiration)
    un embryon de budget.
    - une fois que j’ai ce "core doc", je le passe à la moulinette du chef-d’ouvre qu’est http://www.amazon.com/The-Art-Game-Design-Edition/dp/1466598646/ref=dp_ob_title_bk Ce livre propose une grille d’analyse de tout jeu, et je l’ai convertie en un google form, qui me donne un questionnaire auquel j’essaie de répondre de manière la plus détaillée possible. Je sais bien que ça ne sert à rien de trop écrire un objet interactif, que de toute façon il est appelé à changer, à évoluer au contact du public, mais je ne peux pas m’en empêcher. Ca me rassure, et je pense que si ça me prend du temps au début, au final, ça me permet d’en gagner pas mal plus tard.

  3. Florent Maurin

    Arf je suis trop long, obligé de scinder... Voilà la suite.

    - Mon game design écrit, quand la structure de mon jeu le permet, je fais un prototype avec Twine. La gestion des variables me permet d’avoir un premier feeling de l’expérience utilisateur, qui, même s’il est très sommaire, est assez utile pour commencer tôt à équilibrer l’expérience. C’est le seul vrai moyen que j’aie trouvé de me donner un feeling d’interactivité, mis à part certains logiciels de wireframing interactifs, mais l’avantage de twine est double :
    c’est extrêmement rapide d’obtenir quelque chose, pas besoin de graphiste ou de ressource tierce
    avec un petit brin de programmation, on peut avoir juste le degré de complexité nécessaire

    - Et ensuite, j’écris dans Excel. Certes, tu le dis très bien dans ta prez, Excel n’est pas l’outil le plus sexy du monde. Mais il a un gros, GROS avantage : les devs aiment bien. Comme tu le sais, un jeu vidéo, c’est beaucoup d’itérations. Et quand on propose un doc Excel à un dev, ça lui prend 5 minute d’écrire une petite mouilinette pour aller en extraire les données et les mettre dans un fichier à lui (genre .json ou .xml). Du coup, ensuite, tout au long de la prod, je peux faire toutes les modifs que je veux, et demander à mes dev de réimporter l’excel, pour avoir à très peu de frais un sacré paquet de versions du jeu. Et ça, c’est vraiment précieux.

    1. Florent Maurin

      - pour ce qui est des graphistes, je peuple mon game design doc de wireframes que je fais avec un logiciel adéquat (j’ai tendance à utiliser Cacoo mais franchement, il y en a un paquet qui font ça très bien), et ensuite, ça passe par beaucoup d’échanges en direct. Autant j’ai aucun mal à bosser avec un dev qui est loin, autant je n’apprécie rien plus que de pouvoir m’asseoir à coté d’un graphiste pour qu’on essaie des choses ensemble.
      - pour ce qui est des musiciens, ça se passe pratiquement 100% sans outil. Parfois, ils demandent à voir le game design doc ou une version proto du jeu, mais la plupart du temps c’est surtout des discussions sur l’intention, sur l’ambiance, sur l’état d’esprit... autrement dit, pas des choses très faciles à mettre à plat.
      - et pour tout ce qui est production et budget, encore une fois c’est beaucoup d’excel. Plus deux outils pour m’aider à tenir mes deadlines :
      - la fonction avertissement de Google Agenda (qui m’envoie des SMS parfois 1 mois à l’avance)
      - un gestionnaire de liste tout con pour les périodes de rush (j’utilise Workflowy mais c’est vraiment un exemple parmi d’autres)
      Ps : je trouve néanmoins que ce qu’il me manque actuellement, entre autres, serait un outil simple de versionning, pour garder la trace des évolutions de mon travail sans même avoir à m’en soucier. Je me dis parfois que je devrais bosser directement dans git, je vais peut-être m’y mettre d’ailleurs.

  4. Benjamin Hoguet

    Quelle belle initiative et quel immense chantier ! Il me semble qu’un tel outil ne peut se démocratiser s’il fait preuve d’une flexibilité extrême, à l’instar des auteurs interactifs qui s’adaptent et réinventent leur métier à chaque projet.

    Il est important qu’il puisse aussi servir d’outil de communication au sein de l’équipe et qu’il permette de mieux anticiper le processus de prototypage / production.

    J’imagine donc bien quelque chose comme ça :

    1/ Je crée un projet et je lui donne : ses paramètres de base, les plateformes mobilisées, sa temporalité. Il se crée automatiquement un dossier Dropbox ou Google Drive qui servira de réceptacle aux documents de travail.

    2/ Je construis ma structure interactive en ajoutant successivement des "mouvements" narratifs, sortes d’unités narratives caractérisées par : son ou ses mouvements "parents" et la plateforme sur laquelle il se déploie.

    3/ Pour chaque mouvement, je peux attacher des contenus divers (scénario ou synopsis, wireframe ou maquette graphique, contenus multimédia) et je détermine les modes d’interactions requis pour faire avancer l’histoire

    4/ Je poursuis et répète ainsi l’opération jusqu’à obtenir une arborescence complète, que je peux visualiser à tout moment. Je peux alors exporter plusieurs livrables comme une visualisation de la structure narrative, une cartographie d’expérience utilisateur, divers fichiers utiles à la production (liste du contenu à produire, etc.)

  5. Thierry Labro

    Super idée.
    A mon modeste niveau d’écrivaillon, ce qui m’intéresserait serait de pouvoir, à partir d’un texte, ajouter automatiquement une sorte de contextualisation à différentes échelles :
    - géographique,
    - historique et
    - "actualités", avec du son voire avec des images aussi pour donner du corps au texte à partir d’une trame.

  6. Rob Lahoda

    Sorry for my lack of French, but my comments on the MIT blog post are awating moderation still so I thought I’d comment here also...

    As I was working on my thesis i-doc project this afternoon, one thing that came to mind as a helpful feature would be the ability to attach or auto-generate the code that goes along with a part of what I’m working on.

    For instance : in Scrivener I can create a bunch of small documents that can be moved all around to reorganize or re-edit the flow of my project. It would be great to be able to insert the actual content for that part and so when I am re-arranging it, I can have a ready-to-go portion of my code in order. Yes, part of it would require cleanup and making sure that everything is flowing in order correctly on the code side, but if I can tell the program that this chunk is contained within a tag, i should be able to take all of that content and move it around while being somewhat self contained.

    If the program has an outline view, that outline could be set up to follow the structure of the project and when I compile the final version, it can spit out the completed code ready for debugging and cleanup.

    Another thing that I thought of is that by being open-source, it could be like the Atom text editor (https://atom.io/). That program out-of-the-box is very powerful but each user can customize it to their own preferences by adding and working with various packages that reflect their own needs and styles of working.

    1. davduf

      Merci à tous ! Thank you everybody !

      Je suis en train de faire la synthèse de tous les retours pour nos prochaines réunions au MIT.
      I am trying to synthesize all returns for our next meetings at MIT OpenDocLab.

      Vos commentaires sont précieux, your comments are very helpful, continuez ! Keep on !

  7. Yann

    Projet extrêmement prometteur, et je me permets donc d’y mettre mon petit grain de sel, désespérant de trouver l’outil idéal qui tourne sur ma plateforme Linux.
    Je pense d’ailleurs que c’est un aspect essentiel à prendre en compte : libérer l’outil des plateformes logicielle et des serveurs centralisés. J’ai vu plus haut un renvoi vers DropBox pour le Cloud. Personnellement je préfère des solutions où je garde le contrôle de mes données, donc un OwnCloud me conviendrait mieux. Et là je me suis dit qu’une architecture qui permette l’ajouts de plugins serait peut-être adaptée, pour permettre justement à chacun de trouver chaussure à son pied ou d’adapter à ses habitudes professionnelles, voire de s’insérer au mieux dans une organisation préalable sans devoir tout refonder.
    Par ailleurs, étant romancier, avec énormément de documentation, il me serait intéressant de pouvoir lier dynamiquement cette doc avec les récits, voire les sections. Je prends un exemple : imaginons que je puisse indexer la documentation classée dans une sorte de wiki avec des balises de type appels BibTex. Depuis ce wiki, je pourrais afficher une liste des rétroliens mais aussi faire apparaître en fin des documents rédigés une liste des appels documentaires, comme avec BibTex. Et pouvoir passer sous silence ces appels lors d’une exportation du produit final, par exemple en epub pour publication.

  8. Yann

    Les commentaires coupent au bout d’une certaine longueur, donc je finis ici. Quand je parlais d’une architecture de plugins, je trouve particulièrement intéressante celle de Blender par exemple : un noyau en C++ performant entouré d’une surcouche Python avec une API très bien documentée. Du coup les apports de la communauté sont très variés et extrêmement puissants.