Finalisation des interfaces + choix dans les interactions à montrer + travail de publication
Plus que 2 jours pour présenter les fonctionnalités et rendre compte de la démarche de projet : tous les choix convergent vers la finalité de l'oral.
Les interactions sont toutes calées, malheureusement le temps va manquer en production pour démontrer ces interactions.
Va maintenant se dérouler la phase de post-projet en entier, c'est-à-dire produire tous les supports de communication qui vont soutenir mon discours à l'oral. La plupart des phases sont déjà anticipées, mais j'ai un gros travail de remise en forme à faire, en plus de préparer le discours.
Le gros point-clé fut de décider de retravailler des éléments de trace de travail dits "bruts" pour servir la présentation.
Autre chose, la structure de mes fichiers a été pendant la production modifiée et manque de discipline : urgence, workflow irrégulier. J'ai essayé de conserver un semblant d'ordre mais le versioning en a pris un coup, étant donné qu'il n'est pas automatisé.
Choix d'interactions + scénario d'usage en vue de la présentation
Plus que quelques jours pour finaliser le produit + les supports de la démarche de projet.
Analyse de cas d'usage : projet photo pour illustrer.
Mockups et choix graphiques + structures + réflexion sur la scéno
Poursuite du travail de mise en forme.
Les choix graphiques sont potentiellement finis, il faut maintenant que je déroule les écrans en fonction des wireframes.
Petite remise en question de l'interaction principale : d'un drag&drop du dossier PUBLIC au dossier PRIVÉ, on va passer à un simple choix d'état de fichiers. Bien que l'interaction de glisser vers le public était intéressante, cela compliquait la gestion de fichiers, les versionings.
Cependant, ça change aussi la structure des fonctionnalités, et donc les boutons, et donc les écrans à montrer. Concrètement, il faut donc que je repense un peu les principes avant de continuer.
J'ai aussi commencé à penser à la présentation de projet, et de la meilleure manière de faire comprendre les principes choisis. Par exemple, le CSS du blog changera en fonction des choix graphiques, et je vais avoir avant la présentation du 7 juillet un gros travail de mise en forme pour retranscrire les différentes phases du projet.
Cela confirme bien que la troisième phase du projet, de la conclusion à la mise en forme des supports de communication du projet est aussi à anticiper, et à retranscrire dans l'outil.
WF micro-interactions + tests graphiques
Grosses difficultés de mise en scène de contenu / choix dans la DA. Quelques choix ont été arrêtés.
Réflexion sur les média amenés à être utilisés le jour de l'oral : vidéos ? protos web ? papiers ? Comment présenter l'application ?
Délimitation aussi des fonctionnalités des trois clients : web, application desktop et APP.
Réflexion autour de la mise en forme graphique
Recherche de typographies autour des intentions graphiques.
Recherches de coloris, et premiers jets de mise en scène de contenu.
Mise en ligne - restructuration - sauvegarde
En triant les fichiers, suppression de la mauvaise branche du projet, celle qui était consacrée au moteur de documentation. Panique à bord, essai de récupération, j'ai du faire appel à l'aide d'un ami pour m'en sortir : je n'y connais rien en Git. Toujours est-il que cela montre que la techno impliquée dans l'outil que je créée doit être non seulement transparente, mais accessible.
J'ai aussi compris l'intérêt de Git, qui après 2h au téléphone à manipuler, m'a permis d'accéder à tous mes fichiers "disparus". En fait, Git stocke toutes les modifications de toutes les branches dans le système de l'ordinateur, ce qui en fait un outil très puissant si on sait s'en servir, et très délicat si non.
TL;DR : il faut toujours conserver des archives de tous les fichiers, y compris ceux du méta-projet. Ce qui correspond bien à l'architecture envisagée pour l'app.
Du coup la structure du projet se précise, demain je finirai le tri.
CSS en revanche peu convaincant, il faudra raccorder le journal avec l'axe de communication choisi en post-projet.
Mise à jour du moteur de blog - restructuration globale des fichiers - publication
GROSSE MAJ : Enfin réussi à faire marcher Metalsmith, réorganisé les fichiers pour avoir une version publiable assez vite. L'ancienne branche va être abandonnée pour mieux coller à la nouvelle.
Essai de mise en forme également, le fichier source en .ai sera en ligne, ainsi que des aperçus sur cette partie.
WF + récolte
Commencé la récolte de données annexes, relancé certains contacts. J'ai appris pas mal de choses sur les workflows, je vais essayer de faire que les fonctionnalités de la plate-forme s'ajuste au mieux au usages.
La structure et le core sont presque calés, à détaillés dans des scénarios.
Je penche pour une interface très engageante, très pop, au niveau du look&feel, avec des pictogrammes sympathiques (sans aller vers un truc style Headspace). Le nom pour l'instant tend à être ReadMe, aussi.
Il va falloir que j'engage un travail de traduction des termes liés aux fonctions tirées de Github, pour que l'approche de l'outil soit plus intuitive. Typiquement, forker, commit et pull request ne sont pas compréhensibles pour la plupart des gens.
Note : la récolte par le questionnaire a eu beaucoup plus de succès, le premier lancement était complètement opaque.
contacts + recherches + avancement
Ce matin, récolte des résultats du sondage et analyse. Envois de mail pour avoir des précisions sur les outils, notamment pour les corps de métier que je connais les moins. Poursuite demain.
Cet après-midi, échange : la structure du projet se stabilise, j'essaierai de la décrire quand j'aurai des documents montrant les workflows.
Le CSS du moteur de blog avance aussi, il commence à se rapprocher de la page de projet ?
Recherches + WF
Le sprint était une mauvaise idée, pas assez de matière pour faire des choix pertinents quand à l'interface.
J'ai néanmoins posé les bases de l'interface et les premières idées sur papier.
Lancé aussi un sondage google form pour avoir plus de matière, je vais essayer d'exploiter les contacts et les inputs la semaine qui vient.
Pour le blog, la gestion de site statique est délicate : je n'ai pas assez de bases en Handlebar.Les recherches se poursuivent, en attendant j'ai décidé de commencer le css (en Less).
Premières idées d'interface + recherches sur le moteur de blogging
Recherches sur les fonctions de metalsmith, la mise en place + CSS devrait commencer ce week-end.
J'ai encore des dossiers différents / du mal à organiser la structure des fichiers.
Commencé à scanner des planches de croquis, c'est un frein à la documentation (fastidieux)
premières idées d'interfaces, organisation de la visualisation des commits et interactions.
Abandon du sprint : pas assez d'inputs. j'essaie d'avoir une vision claire du soft pour demain, et je recommence lundi.
SPRINT JOUR 2 Idéation + identification des fonctionnalités + essai de workflow
Essai de réunir les différentes fonctionnalités. Post-it pour avoir de la liberté dans la disposition, clarté.
Listage des différentes fonctions dans le "core" ou en terme de plugins facultatifs. visibilité sur ce qui sera nécessaire à toutes les pratiques, et tous les projets (timeline : début - projet - fin)
Choix à faire : comment clarifier les deux niveaux de gestion de projet?
comment permettre un feedback synchrone avec la pratique? synthétiser le retour de projet? Laisser le choix?
demain : analyse et prototypage papier
SPRINT JOUR 1 Recherches + Analyse + identification des premières fonctionnalités
Mise en place du blog en pause : manque de ressource, obligation d'autoformation. En attendant je suis obligé de prendre des notes et de faire des pseudo-commits en md, en attendant de publier.
Je me suis rendu compte que mon processus de travail évolue aussi : m'obligeant à laisser des traces, je commence à être plus discipliné dans ma prise de note / classement de fichiers, de manière à offrir plus de clarté au témoignage. L'avantage, c'est que je conscientise la démarche, même si ça engendre un coût temporel. Le projet est donc justifié puisqu'il remplit le premier objectif, au moins pour moi.
Je me rends aussi compte que les fonctionnalités que je vais identifier vont dépendre des diffictultés que je rencontre dans la méta (que je dois apprendre à distinguer du processus design classique), qui constituent énormément de freins que je dois gommer pour éviter d'avoir un impact sur la pratique.
DÉBUT DE LA PHASE DE RECHERCHE.
Analyse de différents services : quelles fonctionnalités, quels workflows?
Étude de la théorie KM + prise de note sur les points communs que je trouve avec mon projet.
Questions : dois-je intervenir pendant le travail, quite à avoir une influence sur la pratique, ou seulement proposer un témoignage à posteriori, pour une prise de recul? Après chaque étape du projet?
Recherche d'une interface de publication
Après avoir tenté d'installer Jekyll comme moteur de publication pour suivre le projet, j'ai décidé de me tourner vers Metalsmith : plus simple, il fonctionne en Node et est plus flexible au niveau des plugins.
La mise en place est néanmoins fastidieuse : mon niveau n'est pas assez évolué pour que je puisse prendre des initiatives dans la structure.
J'ai par contre mieux cerné mes besoins et compris que le témoignage sous la forme de trace doit répondre à une problématique de simplicité (le markdown me paraît être ici de plus en plus pertinent).
Comme le projet doit être lui-même le témoin de ses besoins, je vais tenter d'inclure petit à petit les fonctionnalités sélectionnées à l'interface.
Matinée :
Table ronde autour du projet.
Redéfinition des termes. Mise à plat des problématiques liées aux interactions.
Évidence qu’une mise en contexte s’avérera nécessaire pour montrer l’interêt de l’outil.
Aprem :
Roadmap
W1 : Recherches (KM, existant, veille) + définition des fonctionnalités
Étude de la récolte
W2 : Premier sprint : mise en contexte + wireframing et workflow
W3 : Premier sprint : mise en contexte + wireframing et workflow
W4 : Choix de techno pour les protos + charte graphique
W5 : dev + micro-interactions + mockups?
W6 : supports de communication + construction de la soutenance
README.md / fichier de base du dossier Github.
DRAFT (nom provisoire)
Draft est un projet visant le partage et la collaboration autour de la notion de "projet".
Il vise deux objectifs :
La possibilité de construction d'une méthodologie de travail personnalisable et réfléchie.
Le partage de processus de travail dans le but de rapprocher différents usagers de la même pratique.
Pour ce faire, Draft se propose à construire une plate-forme de gestion de projets de toute sorte permettant le suivi et le partage des sources de ces projets.
J'ai donc dans ce processus de création besoin de la participation de praticiens de tous horizons capables et volontaires pour témoigner de leur démarche de travail ou de création.
Si vous souhaitez participer, vous pouvez simplement créer un nouveau fork depuis "Ressources", et l'intituler à votre guise (ex : "Ressources+Nom"). Toute trace me sera utile : croquis, photographie, scan de carnet de notes, brouillon, storyboard, code source, etc. L'organisation est toute aussi libre, le seul impératif étant de respecter les branches de tous les contributeurs.
Draft étant Open Source, et pour des raisons de droits dans des contextes professionels, quelques notes sur votre processus de travail pourraient suffire. Cela peut aussi être fait de manière anonyme, ou en m'envoyant un mail à vcent.ricard@gmail.com.
Ce projet étant aussi l'occasion pour moi d'expérimenter des processus de travail différents, un méta-fichier sur le suivi du projet sera tenu à jour (quotidiennement à partir du premier juin) où chaque commit tiendra informé de l'évolution du projet.
Pas trop eu le temps de poursuivre les écrans : l'échéance s'approche et il faut maintenant tout optimiser pour l'oral, dans l'optique de présentation. J'essaie d'éviter à les coups à blancs et de choisir exactement quoi montrer, avant de poursuivre l'application.
La scéno a commencé à prendre forme, elle suivra le déroulé du projet de manière chronologique, pour coller au mieux à l'esprit "méta".
Relecture du mémoire également pour articuler au mieux la transition.
Finalement le déroulé du projet dépend maintenant énormément de la présentation, ce qui signifie que la partie post-projet prend au final plus d'importance que prévu, en tout cas ici.
Autre constat : quand on est dans le rush, il est beaucoup plus difficile de s'atteler au journal, et donc de prendre du recul. J'ai par exemple quelques problèmes pour anticiper les temps de travail que va me demander chaque tâche, et je pense que je serai complètement débordé ce week-end.
