Créer un journal de bord about cassandre HOT 24 CLOSED

Merci pour cette proposition.

Je tiens à préciser un point important, lorsque tu parles de projet il s'agit également de journal de bord.

À un projet est lié un journal de bord, c'est pourquoi un journal de bord et un projet, et inversement. Puis un journal de bord contient n comptes rendus, ou mémos.

from cassandre.

👍 @SlaAls Projet d'analyse qualitative, Jounal de bord, carnet de bord. A voir quel serait la terminologie préféré et la plus appropriée pour l'application ? (cc @christophe-lejeune )

from cassandre.

Je ne suis pas convaincu qu'il soit opportun de distinguer le "projet" du "journal de bord". Comme l'indique @SlaAls, l'ensemble des éléments affichés constituent, au final, un journal de bord.

Cette remarque s'applique sans doute aux intitulés de #55, voire de #52.

from cassandre.

@christophe-lejeune, @SlaAls J'ai donc modifié la terminologie "projet" par "journal de bord" dans les issues récentes.

from cassandre.

@supertinou la maquette ci-dessus présentant la création d'un nouveau projet suscite quelques remarques et questions

• les collaborateurs ici sont vus comme des utilisateurs qui ont accès en écriture. il serait important de représenter autres invités qui auront des accès en lectures uniquement
• comme le projet créé est vide, par quoi doit-on commencer? par un compte rendu théorique?
  je pense qu'il est judicieux de préciser le compte rendu sur lequel on va débuter lors de la création du projet.

from cassandre.

@ConstantSIDJUI Le projet/journal de bord, à sa création, est uniquement accessible à des membres inscrits à l'outil et conviés par le responsable du projet en question. Il a été convenu que les personnes extérieures n'auraient qu'un accès en lecture/commentaire sur une entrée du journal de bord en particulier. Voir issue #41

Concernant la première entrée du journal il s'agira d'après les schémas présentés dans le livre de @christophe-lejeune quasiment exclusivement d'un compte rendu terrain.

from cassandre.

Selon les sensibilités, un journal de bord devrait pouvoir être amorcé avec un des trois comptes-rendus suivants :

• Un compte-rendu théorique, précisant la question de recherche que l'analyste se pose;
• Un compte-rendu opérationnel, listant les éléments à explorer sur le terrain;
• Un compte-rendu de terrain, comportant des notes d'observation ou une transcription d'entretien.

from cassandre.

Donc il faudra ajouter une select box sur la maquette sous la liste des collaborateurs avec comme choix possibles les 3 CR que vous venez de citer. Avec ça on sera bon de ce côté non?

from cassandre.

Je ne vois en effet rien à ajouter ou à discuter de ce côté.

from cassandre.

Pour justifier cette possibilité : le compte-rendu théorique et le compte rendu opérationnel constituent ils donc, dans ce cas précis ( lorsqu'il n'ont pas de compte rendu de terrain sur lequel ils se basent) de documents de reflexion en amont de la récolte de matériaux empiriques afin de pourvoir définir quelques questions et points de recherche avant cette récolte d'information ?

from cassandre.

Pour reprendre l'ensemble des propositions qui ont été faites ci-dessous, voici une nouvelle maquette qui en regroupe la plupart.

• Tout d'abord concernant l'ajout d'invités à la création du projet, j'ai ajouté un champ dédié permettant de saisir l'email des invités (invités dont les droits sont précisés et gérés ailleurs).
• Ensuite, au sujet du CR qui sera amorcé avec la création du journal de bord, pour reprendre la proposition de @christophe-lejeune, j'ai placé des checkbox pour permettre à l'utilisateur de choisir quel CR sera initié avec le JB.

Tout ce qui est illustré dans la maquette ci-dessous.

from cassandre.

Cette maquette me semble correspondre à ce qui a été échangé plus haut. Elle soulève néanmoins deux commentaires et une question.

• Je me demande si "collaborateurs" ne gagnerait pas à être rebaptisé "participants" (à discuter).
• "Comptes-rendus" (au pluriel) me semble alambiqué. Je propose de supprimer les parenthèses et l'abréviation, et d'indiquer à la place "Amorcer le journal de bord avec un compte-rendu : théorique, opérationnel, de terrain".
• Je ne pense pas que nous ayons discuté de l'opportunité d'inviter des personnes n'ayant pas de compte sur la plateforme. Cela peut être éventuellement une manière de créer des comptes en même temps que l'on initie un projet, mais ce point n'a pas été discuté. Puis-je me permettre d'inviter celui/celle d'entre vous qui a pensé à cette fonctionnalité à en présenter les avantages et les inconvénients ?

from cassandre.

• Le panneau de gauche distingue tous les projets, mes projets et les projets auxquelles je participe. En fait, je ne vois pas bien la nécessité de distinguer mes projets de ceux auxquels je participe. Deux options au lieu de trois me semblent suffire.
• La maquette gagnerait également à tirer parti de ce que nous avons discuté plus haut au sujet de l'opportunité de parler de « projet ».

from cassandre.

Cela peut être éventuellement une manière de créer des comptes en même temps que l'on initie un projet, mais ce point n'a pas été discuté. Puis-je me permettre d'inviter celui/celle d'entre vous qui a pensé à cette fonctionnalité à en présenter les avantages et les inconvénients ?

Effectivement c'est un point à étudier. Personnellement, j'ai du mal avec ce principe d'invitation par un tier qui engendre l'inscription de l'invité à l'application, qui lui n'est pas maître de cette action.

En théorie

En revanche, l'invitation se faisant par adresse e-mail sur un journal de bord donné, il serait envisageable de procéder à un pseudo-enregistrement de cet utilisateur invité en l'inscrivant localement à un journal de bord. Ainsi son adresse serait liée à un journal de bord et non à Cassandre. Par extension il ne peut utiliser de Cassandre que ce qui est rattaché au journal de bord auquel il a été invité, donc inscrit.

Qui dit inscription dit mot de passe. Lors de l'invitation d'un invité un mot de passe pourrait être généré, invitant l'invité à le modifier directement pour plus d'aisance, exemple de mail :

Bonjour,

Nom de l'utilisateur qui invite (ou @ mail) vous a invité à collaborer au journal de bord nom du journal de bord.

Si cela ne vous concerne pas, veuillez vous délier ce projet via cette adresse : @url

Si vous êtes concerné, veuillez suivre ce lien afin d'activer votre collaboration : @url_modificationmdp

Votre mot de passe temporaire est : mdpgen

Bien cordialement,

Cassandre (or whatsoever)

En pratique

Les données seront obligatoirement persistés. Un journal de bord sera identifié par une valeur unique. Par ces principes on peut alors lier facilement une adresse invitée à un journal de bord.

C'est donc un système très facile à mettre en place :

• générer un mot de passe
• l'inviter cordialement à accepter l'invitation en allant modifier son mot de passe temporaire
• le lier au journal de bord une fois l'invitation acceptée

Bien sûr on peut imaginer un scénario un peu différent, par exemple on peut ne pas l'obliger à modifier le mot de passe pour accepter l'invation et proposer simplement un "click to accept".

from cassandre.

👍 @SlaAls. Je complète ta réflexion avec quelques idées :

Que pensez vous de pouvoir ajouter des collaborateurs et invités à travers une même interface d'ajout : On ajoute des membres au projets qui ont des rôles (des droits) particuliers. Voici une maquette pour cette proposition :

• Ainsi, si l'on souhaite modifier le droit d'un membre, il n'est pas nécessaire de copier l'adresse email d'un cadre à un autre.
• Il est indiqué lorsque une personne n'a pas encore répondu à l'invitation.
• 3 diférents accès :
  • Le propriétaire d'un journal peut : Ajouter/ supprimer des membres et changer les parametres du projet. (Souhaitons nous pouvoir avoir plusieurs propriétaires sur journal) ?
  • Un collaborateur peut ajouter des compte-rendus, les modifier, etc...
  • Un lecteur ( à la place de "invité) peut seulement lire les comptes-rendus et n'a aucune action possible de création / modification. En revanche il pourrait peut être en mesure de commenter les comptes-rendus (#45)
• Chaque ajout d'un membre au journal envoi un email "On vous a ajouté au journal [nom-du-journal]" avec un lien "Joindre le projet"
• Si la personne a déjà un compte sur cassandre avec cet email, ce lien dirige vers la page de connexion à Cassandre :

• Si la personne n'a pas de compte sur cassandre avec cet email, ce lien dirige vers la page d'inscription sur invitation de Cassandre :

@SlaAls Je pense qu'un simple lien d'invitation devrait suffire ? Comme on peut associer l'email d'une personne à un journal, la personne qui n'a pas de compte devra en créer après via le lien d'invitation reçu dans l'email d'ajout au projet et son email permet simplement de savoir lorsque son compte est crée, quels journaux de bord elle est membre.

D'autre part, comme il devrait, de toute façon, être possible de modifier les membres dans un second temps, que pensez vous de ne pas surcharger la popup et de proposer l'ajout/modification de membre dans un menu ? "Paramètre" > "Membres du journal".

from cassandre.

La dernière proposition ignore les précédentes discussions sur les droits d'accès (#41 et #45 ). Pour rappel, il en était ressorti qu'il n'était pas opportun de distinguer différents rôles (propriétaire, membre ou lecteur) mais que tous les membres sont des participants de plein droit.

Afin de ne pas surcharger le pop-up, je préconise donc de repartir de la maquette précédente et de la réviser en tenant compte des commentaires #53 (comment) et #53 (comment).

from cassandre.

En effet, le libellé "Invité" m'a rendu confu. Donc pas de différents rôles pour les participants.

• Lorque l'on ajoute des participants, Il est important d'afficher l'email avec le nom pour distinguer les homonymes et de choisir le bon compte. Il pourrait y avoir plusieurs "Jean Dupont" dans la plateforme.

Deux propositions (ça se joue sur des détails mais ce n'est pas inutile de voir différentes manière de maquetter la fonctionalité) :

1) Avec champ participants et invités

Dans cette version les participants qui sont inscrits dans la plateforme doivent être ajoutés dans le champs participants et les personnes que l'on n'a pas trouvé dans la liste des participants car ils n'ont pas encore de compte et que l'on souhaite donc inviter dans le champs "invités"

2) Avec seulement le champ participants

Dans cette version on ajoute des participants via son nom ou son email (la liste des propositions s'affichent en dessous comme dans l'exemple 1) les participant n'ayant pas encore de compte recoivent une invitation pour s'inscrire.

Une preférence ?

from cassandre.

Concernant les maquettes

Nous pensons que la deuxième maquette présentée ci-dessus correspondant le mieux aux attentes du projet. Si on se réfère à l'issue #41 Partager un compte-rendu, un invité est une personne ajoutée "au cas par cas" sur un compte-rendu particulier ; par exemple un acteur de terrain qu'on ne souhaite ajouter que sur le compte-rendu qui le concerne.

On ne parlera donc que de participants. Ces derniers ont tous les droits sur le journal de bord.
Au moment de l'ajout d'un participant, il y a 2 cas :

1. le participant a déjà un compte (retrouvé par son nom ou email), et le lien avec le journal de bord est fait
2. le participant n'a pas encore de compte, un mail d'invitation pour s'inscrire lui sera envoyé

Test de recette

En attendant la confirmation de @christophe-lejeune sur le choix de la maquette la plus adéquate, nous nous permettons de faire une première ébauche de test de recette.

feature 'Créer un journal de bord' do
scenario 'Créer un journal de bord avec trois participants, deux inscrits et un non-inscrit' do

visit '/'
click_on 'Nouveau projet'
fill_in 'Nom du journal', :with => 'Centre d'appel des urgences'
fill_in 'Participants', :with => 'lagrangemartin@gmail.com'
click_on '+'
fill_in 'Participants', :with => 'jeandupont@gmail.com'
click_on '+'
fill_in 'Participants', :with => 'rose@gmail.com'
click_on '+'
click_on 'terrain'
click_on 'Créer'
visit '/'
expect(page).to have_content 'Journal de bord créé'
end

end

Dans ce scénario, au moment de la création du journal de bord, le système remarque que "[email protected]" ne correspond pas à un utilisateur inscrit. Il va donc automatiquement lui envoyer un mail d'inscription.

Rédigé avec @AndreMarvell

from cassandre.

Je trouve aussi que la deuxième maquette convient mieux : la personne qui initie le projet ne sait peut-être pas qui dispose d'un compte. Saisir l'ensemble des participants via le même champ lui sera donc plus aisé.

Remarque concernant le test de recette : vu que l'on ne parle plus de «projet», il n'est pas vraisemblable qu'un bouton de création s'appelle «Nouveau projet».

from cassandre.

Voici le test de recette mis à jour, avec la modification du libellé du bouton

feature 'Créer un journal de bord' do
scenario 'Créer un journal de bord avec trois participants, deux inscrits et un non-inscrit' do

visit '/'
click_on 'Nouveau journal de bord'
fill_in 'Nom du journal', :with => 'Centre d'appel des urgences'
fill_in 'Participants', :with => 'lagrangemartin@gmail.com'
click_on '+'
fill_in 'Participants', :with => 'jeandupont@gmail.com'
click_on '+'
fill_in 'Participants', :with => 'rose@gmail.com'
click_on '+'
click_on 'terrain'
click_on 'Créer'
visit '/'
expect(page).to have_content 'Journal de bord créé'
end

end

from cassandre.

Modification du fond de la maquette en accord avec celle affichant la liste des journaux de bord :

from cassandre.

The page listing the diaries is a list generated thanks a GET request. Currently, all users (even unregistered) can see the complete list. If a user tries to browse a diary whose access is restricted, he will be asked a password.

The page listing the diaries includes the button permitting to create a new diary (in the bottom menu). Creating a new diary consists in creating a document that comprises the diary id and the diary name. Such a creation is made through a POST request. Because the body of the request is filled before the password is requested, all diaries are created by unregistered users.

I am unsure whether this behavior is smart. What do you think about the following options ?

• I can force authentication for the page listing all the diaries. This strategy however prevents people to have a look on existing projects, which is a good mean to check if we really have users. Deprived of "showcase", we could miss some partnerships.
• A better strategy would be to ask authentication only when a new diary is created. This is better. However, I do not see how to adapt the code in order for the body of the request to be adapted after the passwor is asked. Moreover, this would imply that we refuse that unregistered users test the service. Here again, testing the service without password is appreciated by candidate users.
• Finally, creating a diary perhaps should not be restricted to registered users. However, perhaps a session/log button could be convenient for existing users willing to create a new "private" diary. We then could create a rule saying that diary create after authentication are private, as a default.

What do you think of these different options ?

• Should I investigate the possibility of a log/session button ?
• Is it a good idea to assume that diary created by existing users are private, as a default ? Do you think such a behavior would be intuitive ?

from cassandre.

Hi Christophe,

Since I'm still subscribed to this issue, I'll give thougth to your questions.

I can force authentication for the page listing all the diaries. This strategy however prevents people to have a look on existing projects, which is a good mean to check if we really have users. Deprived of "showcase", we could miss some partnerships.

Regarding your needs, this is not an option, we want people to be able to see the showcase.

A better strategy would be to ask authentication only when a new diary is created. This is better. However, I do not see how to adapt the code in order for the body of the request to be adapted after the passwor is asked. Moreover, this would imply that we refuse that unregistered users test the service. Here again, testing the service without password is appreciated by candidate users.

I feel like this option would not fulfil your needs. Moreover, I find this one a bit counterintuitive, or I didn't really understand. Do you mean that a user has to be authenticated to create a diary? Or a user has to be authenticated to see freshly new diaries? The first one is of course intuitive, but still, it does not take your needs into account.

Finally, creating a diary perhaps should not be restricted to registered users. However, perhaps a session/log button could be convenient for existing users willing to create a new "private" diary. We then could create a rule saying that diary create after authentication are private, as a default.

I'd go for this one. This is the most intuitive, yet it fulfils your needs! This option implies that a diary has two status which are public and private. With that said, unregistered users will only see public diaries (the ones that has been created by unregistered users) and registered users will see all diaries. Although, I'd let the option for a registered/authenticated user to choose to create a public diary or a private one. Of course, this option will need a session/log button.

from cassandre.

It is good to hear from you @SlaAls . Thank you very much for your contribution! Your advise will be turned into code soon.

from cassandre.