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 ?
Messages
2 février 2015, 21:55, par Laurent
Il me manque un outil pour collecter/structurer/tester/gérer :
Des logiciels font ça chacun dans leur coin :
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/).
3 février 2015, 19:00, par Florent Maurin
Allez je me lance, avec mon modeste retour d’expérience d’écriture.
Voir en ligne : http://www.thepixelhunt.com
3 février 2015, 19:01, par Florent Maurin
Arf je suis trop long, obligé de scinder... Voilà la suite.
Voir en ligne : http://www.thepixelhunt.com
3 février 2015, 19:03, par Florent Maurin
Voir en ligne : http://www.thepixelhunt.com
3 février 2015, 21:51, par 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.)
Voir en ligne : http://benhoguet.com
4 février 2015, 13:31, par 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 :
11 février 2015, 02:41, par 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.
Voir en ligne : http://usher_i-doc.roblahoda.com/blog/
11 février 2015, 13:52, par 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 !
9 juin 2015, 16:58, par 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.
Voir en ligne : http://www.hexagora.fr
9 juin 2015, 17:32, par 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.