Rédiger un compte-rendu

[bj0rge]

Summary of required features

• Create a memo.
• Edit a memo.
  • Memo includes Markdown Layout.
  • Link to online pictures (thanks to Markdown)
  • Upload a picture to a memo.
    • Same as above (with drag and drop).
• Delete the picture attached to a memo.
• Delete a memo.

Discussion

Issue created with @Yeahger & @valentinlefevre

We try and synthesized the scenario 'writing a memo'. The different steps we were able to identify are the following:

• Writing the date
• Writing the place & context
• Writing down the first impressions & notes
• Transcribe the interview
• Labeling the interview
• Naming the hole memo for referencing it
• Join meeting review & own notes
• Transcribe the decisions taken during the meeting

We also understood the need about anchors which is a central feature in the activity of writing a memo.

[edwil13x]

Pour la conception, on peut distinguer deux approches:

• Un seul formulaire avec différentes rubriques pour chaque type de mémo.
  Avantages : faciliter à gérer les bugs
  Inconvénients : trop général, oriente moins l'utilisateur
• Plusieurs formulaires, chaque type de mémo ayant un formulaire.
  Avantages : plus en accord avec la méthode, avoir des formulaires personnalisés
  Inconvénients : plus de travail pour les développeurs

Quel approche vous conviendrez?

Ci-joint, les différents types de comptes rendus :

[pixel-3092189]

According to the feature #41, we think about including some additionnal features during writing a memo

• We can associate a piece of text to a tag (For instance : "Personnal notes" or "Behaviour manifestation")
• These tags can be created by two differents ways
  • With a specific syntax (For instance "\PersonnalNotes{I think he is trying to explain that it was a hard part of his life}")
  • With a WYSIWYG editor

[AndreMarvell]

@christophe-lejeune, pour rebondir sur la question des types de formulaires lors de la création d'un mémo : Les informations fournies dans les types de comptes rendu sont elles differentes au point d'avoir besoin de formulaires distincts pour chacun d'eux ?

[christophe-lejeune]

If you refers to the page 30 of the Handbook for Qualitative Analysis, you can see that every memo has the same structure and attributes. This advocates for same (or similar) forms.

Every memo requires :

• the name of the project : could be the name of the project, or the content of another (theoretical) memo
• a type : to be picked in a closed list
• a date : could be automatically inserted
• an author : the name/id of the user that writes the memo (in some case, multiple authors could be allowed).
• a title
• a grounding : the reference of a memo previously written.
• a body : the content (text or schema) written by the user.

[AndreMarvell]

Thanks @christophe-lejeune. Knowing that every memo has the same structure, so we will choose the first approach : Only one form with different headings for each type of the memo.

[christophe-lejeune]

Some precisions :

• Be sure not to confuse headers (mentioning "fixed" information such as author and date) and tags (which contains interpretation different from one user to another).
• Hereunder is the English version of the diagram mentioned above
  

[mchidaine]

Here we have 2 mockups :

• one showing the field note with its tags on one side with the option to add a code note related to this field note;
• one showing the creation of a new code note once we've clicked on the "add a code note" button

We chose to link the different types of memos by directly having the option to create a memo from another memo; since they're all created in a logical order, it seemed more interesting to link them this way.

[christophe-lejeune]

It took me a little time to understand the mock-ups. Now it is becoming clear.

Here are some comments, to stimulate our discussion:

• The content of the field note (on the first mock-up) looks a bit strange. A field note contains usually observation notes or an interview transcript.
• The GUI of the second mock-up assumes that code notes have something to do with LaSuli. Well, this makes sense given that LaSuli is a coding add-on and that code notes are related to coding. However, don't you think that some users could be willing to fill some code notes without going through LaSuli?
• When I hit "add a code note", is the created code note linked directly to the original field note, or to the highlighted text, or to one of the code featured in LaSuli ? What if I do not select any element before hitting the button?
• The second mock-up is a creation panel. Will the same panel be used to edit the memo? If it is the case, how can the user see the link with other memos? In such a case, will the creation date be replaced by the edit date? For instance, Weft-QDA keeps two dates (creation and last edit).

[pixel-3092189]

As we said during the meeting this morning between Aurelien Benel and the friday TP's group, we finally concluded that it would be a good idea to build a software which includes the functionnalities of LaSuli but doesn't require the Firefox extension itself.
On the basis of @mchidaine's mock-up, we tried to complete it in adding some functionnalities previously mentionned by @christophe-lejeune in #40 (comment).
We have begun two mock-ups, and we need to know if its represent more respectively the work of writing a coding memo.

Writing a memo

Writing a coding memo

These two mock-ups need to be continued and completed. The second one about writing a coding memo isn't finished yet. We invite anyone to continue the mock-up.

#EDIT : 17/04/2015 -> The 2 mock-ups has been updated, especially the second one.

[valentin-bonino]

@salamata and I worked on a form to create memos. In the mock up we made, we create a new field note, where we can fill in the authors, the title of the memo and the body. But the same type of form can be used for other types of note. There is no selection of type, because "create a new memo" button will be on the previous memo.

[pixel-3092189]

@valentin-bonino, you obviously didn't see what we said in #40 (comment). Indeed we made a check-up with @benel the last friday (April, 10th), and we talked about two main things :

• The functionnalities of LaSuli have to be included in cassandre 2, and cassandre doesn't have to require the "LaSuli" firefox extension anymore. In your mock-up, it's appear that you didn't consider the LaSuli functionnalities.
• The second point is the coding memo that doesn't appear too in your mock-up.
  Please, if there are some points to clarify (mock-ups, the way we see things, etc..), please post a comment before creating a new mock-up.

[salamata]

OK! It was just the first mockup version 1.0. We are going to change it and considerer your comment. I didn't know that we have to use lasuli with the memo.

[christophe-lejeune]

Not allowing to pick the memo type is a good idea. I see at least two benefits.

• It "forces" the user to choose a type when hitting the button.
• By doing so, we also avoid untyped memos.

However, when rethinking about your mock-ups, be aware of the following :

• Both a code note and a theoretical note can be grounded in a code note, for instance. Thus, more than one button have to be provided from the memo page (depending on its type). Check the diagram above, to review all possible follow-up type (and, thus, all needed buttons).
• While a code note is basically grounded in only one memo (either a field note or a code note), theoretical notes are mainly based on more than one memo (theoretical notes are used for comparison). The theoretical note could also be created through a button, but the interface need to allow to add additional groundings.

NB: Perhaps another issue could be dedicated on mock-ups to read memo, given the edit window will be slightly different.

[edwil13x]

Un mémo pouvant pointer vers plusieurs types de mémos (ex: compte-rendu théorique vers compte-rendu opérationnel, analytique et schématisation), l'ajout de nouveaux mémos à partir d'un précédent doit permettre de choisir le type. Je propose d'illustrer ce cas particulier par la maquette suivante.

[ConstantSIDJUI]

L'affichage de mémos se faisant en parallèle comme précisé dans le ticket #41, lors de la navigation de mémo en mémo nous devons avoirs des alternatives lorsqu'un mémo est ancré sous plusieurs autres mémos. L'exemple de la figure ci-dessous illustre un cas de navigation lorsque nous sommes au niveau du mémo Compte rendu théorique (Th), nous pouvons naviguer soit vers le mémo Compte-rendu Opérationnel (O) soit vers le mémo Schématisation (S). Dans l'exemple de la figure nous avons choisi de faire une navigation sur la schématisation (à droite de la figure) et l'affichage précise les deux compte-rendus Théoriques sous lesquels la schématisation est ancrée.

Légende:
C = Compte-rendu de codage
Th = Compte-rendu de Théorique
O = Compte-rendu de opérationnel
S = Shématisation

[ConstantSIDJUI]

La figure ci-dessus représente une maquette pour l'ajout d'un mémo. Cela devient ambigu lorsqu'on se situe au niveau du compte-rendu Théorique (Th) et de la schématisation (S). Étant sur un compte-rendu Théorique (Th) on doit pouvoir ajouter une schématisation. Une fois la schématisation ajoutée et étant donnée qu'une schématisation est ancrée sur deux comptes-rendus Théoriques, on doit pouvoir ajouter le second compte-rendu théorique sur lequel la schématisation est ancrée. Ce qui explique le module en dessous du compte-rendu Théorique après l'ajout d'une schématisation.
Légende:
C = Compte-rendu de codage
Th = Compte-rendu de Théorique
S = Shématisation

[christophe-lejeune]

Si je comprends bien,

• Rédiger un compte-rendu #40 (comment) concerne la navigation
• Rédiger un compte-rendu #40 (comment) concerne la création d'un compte-rendu.

Si c'est bien cela, alors la première maquette relèverait plutôt du #47 (et n'a donc pas sa place ici). Corrigez-moi si je me trompe.

Je ne suis pas certain de mesurer l'apport de la partie gauche de cette première maquette, pour deux raisons.

• La liste des comptes-rendus sur lesquels s'appuie un compte-rendu est présente dans l'entête. Ne suffit-il pas de cliquer sur celui qui nous intéresse pour s'y rendre ?
• Afficher les comptes-rendus sur lesquels s'appuie un compte-rendu est certes aisé, dans cet exemple, où 2 comptes-rendus sont concernés. Lorsqu'il seront 10, cet affichage ne risque-t-il pas de devenir plus compliqué ?

En ce qui concerne la deuxième maquette, le module sous le compte-rendu théorique de la partie gauche me semble effectivement constituer une bonne solution. On peut cependant se demander, à nouveau, s'il ne suffirait pas, de permettre les ajouts dans le champ "Ancrage" de l'entête, grâce à un bouton [ + ](comme on le ferait pour les auteurs).

[Yeahger]

Synthèse de la rédaction d'une entrée dans le journal de bord

Cette synthèse a pour but de faire un point sur ce qui a été dit depuis la création de cette issue. C'est également l'occasion de voir si nos réflexions vont dans le bon sens.

Le mot "mémo" entraîne des confusions. On devrait donc plutôt parler "d'entrée du journal de bord". Une entrée est typée (cf schéma #40 (comment) )

À l'exception de la première entrée du journal qui sera un compte-rendu de terrain indépendant, les autres entrées seront ancrées à une ou plusieurs autres entrées.

Au niveau de l'affichage, l'écran sera divisé en deux :

• à gauche : une vision des documents sur lequel est ancrée l'entrée (vide pour le premier compte-rendu de terrain)
• à droite : la nouvelle entrée à rédiger

La rédaction d'un compte-rendu sera dépendante du type d'entrée que l'on souhaite rédiger.

• Une saisie de texte : pour la plupart des compte-rendus
• Un système de "questions / réponses" : pour le compte-rendu de terrain
• Un système de marqueurs "Lasuli" : pour l’étiquetage
• Des diagrammes / schémas (par upload d'images ou éditeur de diagrammes) : pour la schématisation

@christophe-lejeune : Nous attendons vos remarques avant de progresser sur cette issue.

Rédigé avec @valentinlefevre

[christophe-lejeune]

Merci pour cette très bonne synthèse qui va à l'essentiel. Je ne vois rien à objecter à ce qu'elle contient.

Je me permets juste de compléter la liste des modalités de rédaction des comptes-rendus :

• Les schématisations (ou diagrammes) requièrent un mode de saisie graphique (Tracer une schématisation #49).
• La table des propriétés requiert un mode de saisie tabulaire (Dresser une table des propriétés #50).

N'hésitez pas à me relancer si quelque chose n'était pas clair. Je suis bien conscient que les schématisations et la table des propriétés nécessitent plus de travail que la "simple" saisie de texte. Elles jouent néanmoins un rôle important dans le travail de conceptualisation en recherche qualitative.

Le projet avance bien. Merci de vos contributions et bon courage pour la suite !

[ConstantSIDJUI]

Test de recette pour la création d'un compte rendu opérationnel à partir d'un compte rendu théorique.

1- vérifier que le background (tout ce qui c'est fait avant) du compte rendu opérationnel à été bien réaliser si non on doit au préalable:

• Créer un Projet;
• créer un compte rendu de terrain;
• faire un étiquetage;
• créer un compte rendu de codage;
• créer un compte rendu théorique;

2- étape de création du compte rendu opérationnel

• sur la page du compte rendu théorique, cliquer sur le type: compte rendu opérationnel;
• vérifiez que le compte rendu de coda n'est plus visible;
• vérifier que le compte rendu opérationnel est visible;
• renseigner les différent champs (Auteur, Type, etc)
• cliquer sur enregistrer.

Rédigé avec @salamata

[salamata]

Test de recette pour la création d'un compte rendu opérationnel à partir d'un compte rendu théorique avec RSpec syntax :

require 'spec_helper'
feature 'Créer un compte rendu' do
scenario 'for a published article' do
visit '/'
click_on 'Compte rendu théorique'
click_on 'Créer compte rendu opérationnel'
fill_in 'Titre', :with => 'Échantillonnage des dimensions de se motiver'
click_on 'Type', :with => 'compte rendu opérationnel'
fill_in 'Date', :with => '05/05/2015'
fill_in 'ancrage', :with => 'Compte rendu théorique'
fill_in 'URL', :with => [GitHub](https://github.com/Hypertopic/Cassandre/issues)
fill_in 'Memo', :with => 'L''analyse consigne les pistes à suivre dans des comptes-rendus opérationnels. Cela peut impliquer des passages en bibliothèque, orienter la suite du terrain ou suggérer des pistes de conceptualisation à venir.
Dans l''exemple de la construction de maison, les propriétés articulées (à savoir, les "difficultés imprévus" et "se motiver" méritant un approfondissement.
-Se motiver est un processus doté d''une historicité propre: les conditions pour amorcer ce processus différent de celles contribuant à le poursuivre ou à l''arreter. Ces différentes conditions méritent d''être explorées.
-Le rôle que jouent les imprévus dans ce processus dépend de leur nature, de leur nombre, de leur répétition et de leur sévérité. Par ailleurs, les imprévu ne sont évidemment pas seuls à intervenir dans le processus. '
click_on 'Enregistrer'
visit '/'
expect(page).to have_content 'compte rendu opérationnel'
end
end

Rédigé avec @ConstantSIDJUI

[christophe-lejeune]

Waow. Les choses se concrétisent.

Quelques remarques :

• Pour être consistante, l'interface ne devrait pas passer de "mémo" à "compte-rendu". Je préconise d'utiliser "compte-rendu" du début à la fin.
• Le titre devrait toujours différer du type. Le titre d'un compte-rendu opérationnel pourrait être "Échantillonnage des dimensions de se motiver"
• Dans la mesure où l'utilisateur clique sur un bouton mentionnant le type de compte-rendu, il ne me semble pas utile de lui demander de préciser le type (le système comme l'utilisateur savent de quel type il s'agit). Nous en avions discuté : Rédiger un compte-rendu #40 (comment)
• De la même manière, dans la mesure où l'utilisateur est identifié, il ne me semble pas non plus utile de lui demander de déclarer qui il est (le système le sait déjà).
• Enfin, c'est sans doute du détail, mais le contenu proposé ici ne correspond pas vraiment à celui d'un compte-rendu opérationnel.

Voilà, je peux évidemment me tromper. N'hésitez pas à me le signaler le cas échéant.

[supertinou]

Note : @salamata, tu peux utiliser le formatage Markdown sous forme de code : https://help.github.com/articles/markdown-basics/#code-formatting afin améliorer la visibilitée du test de recette.

[ConstantSIDJUI]

@supertinou est-il nécéssaire d'utiliser le formatage Markdown?

[valentinlefevre]

@christophe-lejeune un gros travail homogénéisation a été réalisé pendant le séance de ce vendredi, nous ouvrirons prochainement une issue relative à cela, elle devrait répondre à un certain nombre de problématiques posées concernant la cohérence entre les différentes fonctionnalités du projet.

[ltosi]

Si les fenêtres de consultation et d'édition sont les mêmes, nous avons besoin de deux boutons différents, l'un permettant d'enregistrer le compte-rendu courant et l'autre de créer le compte-rendu suivant.
Si les fenêtres de consultation et d'édition sont distinctes, le bouton d'enregistrement n'est nécessaire qu'en édition. Celui permettant de créer le compte-rendu suivant qu'en consultation.

Je reprends ces remarques : l'utilisateur a besoin de contexte, et un bouton d'enregistrement ne doit pas nécessiter de choix de la part de l'utilisateur, sous peine de perte de données.

Le travail fait vendredi intègre-t-il des modifications de ce côté?

[valentinlefevre]

@ltosi oui le travail effectué avec @SlaAls intègre ces remarques

[christophe-lejeune]

Pourriez-vous publier dans ce ticket les maquettes mises à jour montrant :

1. La fenêtre de consultation d'un compte-rendu, à partir de laquelle on peut créer un nouveau compte-rendu
2. La fenêtre de modification comportant le bouton "Enregistrer" du compte-rendu courant.

[valentinlefevre]

Consulter un compte-rendu

Rédaction d'un compte-rendu

Les maquettes ci-dessus viennent du ticket d'unification, cela fait un peu doublon non?

[christophe-lejeune]

L'idée n'est évidemment pas de dédoubler la discussion mais d'éventuellement la reprendre ici pour ne pas surcharger le ticket d'unification (#56).

[christophe-lejeune]

Lors de notre dernière réunion, nous avons parlé d'ajouter à la fenêtre de rédaction d'un compte-rendu de terrain la possibilité de joindre des photographies. Prendre des photos des lieux fait en effet partie des pratiques de terrain en recherche qualitative.

[Slals]

👍 Je pense que c'est nécessaire de discuter sur les fonctionnalités une à une via les tickets qui les correspond. La ticket unification ( #56 ) servira juste à centraliser les retouches et ajustements, ainsi que décrire les scenarii.

Lors de notre dernière réunion, nous avons parlé d'ajouter à la fenêtre de rédaction d'un compte-rendu de terrain la possibilité de joindre des photographies

Vous faites bien de le rappeler ! Une proposition sera certainement faite d'ici vendredi !

[christophe-lejeune]

Dans le cas particulier du compte-rendu de terrain, il faut également prévoir le cas des transcriptions d'entretiens, qui sont structurées en tours de parole (comme c'est le cas actuellement dans Cassandre).

[valentinlefevre]

Vous faites bien de le rappeler ! Une proposition sera certainement faite d'ici vendredi !

Concernant les photographies peut-on envisager qu'elles soient intégrer au texte du compte-rendu via un simple copier-coller ou glisser-déposer?

Dans le cas particulier du compte-rendu de terrain, il faut également prévoir le cas des transcriptions d'entretiens, qui sont structurées en tours de parole (comme c'est le cas actuellement dans Cassandre).

Effectivement les maquettes ne présentent pas une configuration permettant la saisie d'un échange, peut-on se baser sur ce qui est pour l'instant proposé par Cassandre ?

[christophe-lejeune]

Concernant les photographies peut-on envisager qu'elles soient intégrer au texte du compte-rendu via un simple copier-coller ou glisser-déposer?

Plus c'est simple, mieux c'est. Un glisser-déposer serait parfait.

Effectivement les maquettes ne présentent pas une configuration permettant la saisie d'un échange, peut-on se baser sur ce qui est pour l'instant proposé par Cassandre ?

Bien entendu.

Le système actuel est cependant perfectible, comme me l'ont fait récemment remarquer mes étudiants :

• Actuellement, vu que l'ajout d'un tour de parole rafraîchit la page, l'utilisateur se retrouve en haut de page alors qu'il est en train de transcrire (en bas de page). C'est particulièrement gênant.
• Les croix de suppression d'un tour de parole étant d'effet immédiat, il n'y est pas possibilité de revenir en arrière. Certains étudiants ont témoigné avoir dû relire l'ensemble de leur entretien après avoir cliqué par erreur sur une de ces croix.

Ces deux derniers commentaires concernent cependant peut-être moins la maquette que le comportement du formulaire.

[valentinlefevre]

Ces deux derniers commentaires concernent cependant peut-être moins la maquette que le comportement du formulaire.

Effectivement mais mieux vaut poser les choses maintenant :

• Ajout dynamique des éléments sans rafraîchissement de page,
• Ajout d'une étape de validation dans le processus de suppression d'un ou plusieurs tours de parole.

[AndreMarvell]

@christophe-lejeune conformément à votre retour sur le commentaire d'un membre collaborateur, voici une proposition de maquette gérant ce cas :

Comme on peut le voir, le collaborateur connecté, Olivier Ménard, peut créer un compte-rendu s'appuyant sur le compte-rendu consulté en cliquant sur le bouton dédié.

[AndreMarvell]

Conformément aux évolutions des maquettes dans l'issue #56, voici la nouvelle maquette :