Parcourir les comptes-rendus

[Slals]

According to the discussion I had with @benel, it would be interresting to make things clear about how the user would read his log book (i.e. Journal de bord).

The object of this issue is to outline the principal idea on how the log book's interface is shown.

I have heard that @benel drew a mock-up on a white board and @EdwardNjango photographed it, could you respond to this issue en share the picture?

As precisions, we know :

• A log book always starts with a "Compte rendu de terrain", so we could take this as an index when the user read his log book
• There is a dependence between each memo's type (e.g. "Compte rendu de codage" depends on "Compte rendu de terrain", "Compte rendu théorique" depends on "Compte rendu de terrain", and so on), so there is a logic and permanent sequence

Our idea :

• "Compte rendu de terrain" is always the first memo shown
• A viewport allows to consult all the different memos by sliding (left or right)
• The sequence of memo is made in reference to the diagram that you can see in issue https://github.com/Hypertopic/Cassandre/issues/40#issuecomment-89251867

I will post a mockup, this issue could give a principal view for those issues : #40, #45, #46, #41

For the moment, here is a mockup sample

Log book

[Slals]

Simplified mock-up

• There is a horizontal scroll to show that the user can slide to the right and to the left, the original idea is a viewport that the user can control. It could be anything else that allows to navigate through log book the way I mentionned
• To not overload the mockup I only show the memos type, obviously they are more complete than this and we must design the mock-up individualy since it is only pages like

For further details, please leave your questions here.

[pixel-3092189]

@Slaals, In continuation of your Simplified mockup, here is a bit more accurate one in which we describe the same viewport system as your (represented by a dashed rectangle), as @Slaals has explained in the previous comment, that simply move hozirontally for display another content (which is the basic scenario of a scrolling viewport system), but in the same web page (like a classical jQuery script of viewport).

Furthermore, I am wondering if we should not replace your scrolling bar by a cool navigation system (First button : Beginning of the page, Second button : Previous task, Third button : Next task) as suggested by @benel this morning (17/04/2015)

Here is the final mock-up suggestion :

[Slals]

So, I come back here to make a new proposition, as discussed with @benel on April 25th.

The mock-up

Why?

There is no viewport anymore. The main problem we have encountered with this idea was that the log book was sequentially static, that means the user had to follow the diagram strictly to make an analysis. Also it had been discussed during the meeting on April 24th about a dynamic sequencing, which our first idea does not allow. This is why I am suggesting a new idea.

How it works?

Now to replace the viewport solution we use different pages.

A page is sliced in two parts, so we have the left part and the right part

• Right part : always shows the memo which the user wants to consult. In this part there is always one and only one memo shown.
• Left part : shows all the memos which were used as supports to write the consulted memo (i.e. the memo shown in the right part).

In the mock-up above, the user is consulting all the memos related to the "Cas Olivier", which can be viewed as a project.

Every memo inside a project has an ID. For instance in the project "Cas Olivier" there are "CRTerrain 1st interview" id=1 and "Etiquetage Humeur" id=1. To identify a document we use his type "CRTerrain" or "Etiquetage" in those cases, and a specific ID relative to the type : "CRTerrain(ID=1)" => "CRTerrain 1st interview" and "Etiquetage(ID=1)" => "Etiquetage Humeur".

To identify which documents are used to set up a given memo, we use the memo ID and a list of ID. For instance, in the mock-up, the second page shows a document that has 2 support documents. First the document on the right part is "Etiquetage Humeur" and his ID is "Etiquetage(ID=1)". Then we can define his support references as :

Etiquetage(ID=1) referes to CRTerrain(ID=1)
Etiquetage(ID=1) referes to CRTerrain(ID=2)

The arrow button shows a menu. In this menu is listed every document which has as reference the document in the right part. For instance, in the mock-up, "CRTerrain 1st interview" is a support document to "Etiquetage Comportement", "Etiquetage Humeur" and "Etiquetage Expérience".

The button "voir" on the left corner of every support document is a link to the document itself. So, by clicking in, the user is redirected on the targeted document as consultation. Then the document appears in the right part and in the left part are shown all the support documents refered to the targeted document.

NOTE : There is one and only one case where the left part is empty. It is when the document is a "Compte rendu de terrain". The reason is that this type of memo does not require any support to be written, he is the source of an analysis.

Principe

To ouline the principe of this solution. Every document is a part of a graph. A document is a node and a reference is a edge, as simple as that. Here is a graph according to the mock-up above

As always, @christophe-lejeune, is there is any point to clarify, please ask your questions.

Also, could you give us your opinion about this idea?

[benel]

Let's discuss your mockup:

From an ergonomic point of view, it would be better to have 3 arrows instead of 1 arrow with a menu. Browsing is different from creation because:

1. On creation, there will be only one link created. The menu means that there are multiple potential types for the link. On the contrary, on browsing, the links are already there (all of them).
2. On creation, the menu includes types which are fixed values. On browsing, it would be names which are user generated (and therefore could be very long, empty, etc.).

[edwil13x]

Pour répondre aux points évoqués par @benel, la maquette suivante se distingue de l'ancienne par la suppression du menu "étiquetage". En effet le menu Etiquetage est remplacé par un ensemble de boutons, chaque bouton référençant un étiquetage, nous avons donc maintenant trois boutons (1,2,3) pour les trois étiquetages Humeur, Comportement, Expérience. Le nom de l'étiquetage est affiché au survol de la souris sur le bouton.

[bj0rge]

@christophe-lejeune we need your opinion to validate (or not) the previous mockups, so we will be able to write the tests. According to @Slaals, his comment here is the new start to clarify the issue, so we based our work on it.

After a talk with Lorraine Tosi we don't agree with @benel's point of view concerning the navigation with many arrows: she told us the easiest way to navigate is to click on an explicit content (ie. a hypertext title) rather than an image. It is less explicit, especially when they are all the same, and if you have to hover it to see the name of the associated document. Then, if a "Compte Rendu de Terrain" links to many other documents, there will be a moment when you'll have too many arrows on the screen & have to scroll to chose the right one. That's why we would chose the first solution with a list when you hover the arrow.

The second thing we thought about is that there is a lot of wasted space when the two sections are on the screen at the same time. We suggest the following solution: the first section should be in a removable component which could display on a click or a hover. The following mockup explains the idea:

This panel may be extended to other issues, we won't necessarily write a comment for each one.

Comment done w/ @yeahger

[valentin-bonino]

Lire un journal de bord à l'aide d'un graphe des comptes rendus liés

Voici une nouvelle proposition pour naviguer entre les comptes rendus du projet :

Description

• Sur la gauche il y a un volet (qui s'affiche et peut se cacher) avec un graphe qui montre le compte-rendu courant ainsi que ses compte-rendus père et fils. Un clic sur un compte rendu du graphe change le compte rendu courant et actualise ses pères et fils.
• Sur la droite est affiché le contenu du compte-rendu courant. Une navigation entre compte-rendus est donc disponible d'un simple clic sur un compte-rendu du graphe.

Maquette

(cc @supertinou)

[benel]

Vous remplacez de simples liens par un graphe... À combien évaluez-vous le surcoût de développement ? Est-ce que ça prendra le même temps de développement ? le double ? le triple ? le quadruple ?

[supertinou]

En effet, l'aspect budgétaire du projet est à prendre en considération pour le choix de la fonctionnalité. Au moins, cette alternative est présenté ici sans ce soucier des contraintes budgétaires. A savoir si elle est d'ailleurs plus intuitives que d'autres... Il faut aussi se demander si le temps supplémentaire investie dans son développement en vaudra le coup. Pour note, il existe la librairie D3.js qui sait bien gérer la génération d'arbre verticaux (et notamment à partir d'un flux json) : http://www.d3noob.org/2014/01/tree-diagrams-in-d3js_11.html qui pourrait aider à ne pas passer beaucoup plus d'heures avec cette implémentation de graphe des comptes rendus liés.

[ltosi]

On peut imaginer proposer ce type de vue en complément d'une navigation simple par lien, qui serait disponible par défaut. Visualisation par lien : les multiples flèches ne me paraissent pas être la solution, notamment en terme d'affichage du titre du prochain compte rendu. Vous avez travaillé sur une présentation des ancrage, pourquoi ne pas la reprendre pour afficher les comptes-rendus "fils" ? Autre variante, on peut afficher une page relai où les différents choix de "chemin" possible parmi les compte rendus sont affiché, sans perdre l'idée de fil que doit proposer la visualisation par défaut, ni la présentation jusque là proposée des compte-rendus.

Visualisation par graphe : cette visu pourrait être proposé en très petit, avec possibilité de zoom au passage de la souris ou au clic (en transparence, sans manger une partie énorme de l'écran), afin d'offrir à l'utilisateur un moyen de se repérer dans le graphe général. Cette réflexion va de paire avec la proposition #54

[pixel-3092189]

Je me permet de relancer @christophe-lejeune pour déterminer laquelle des deux approches (ancrage sous forme d'arbre ou de simple liste) est la plus pertinente selon sont point de vue.

[christophe-lejeune]

Il ne me semble pas utile d'ajouter une représentation arborée à celle déjà proposée dans le ticket #55. A condition de tenir compte des remarques de @ltosi, une liste fait l'affaire pour cette maquette.

[ChangruLU]

Test de recette pour "Parcourir les comptes-rendus" avec RSpec syntax :

require 'compte rendu'
feature 'Consulter un compte rendu do
scenario 'Ajouter un utilisateur' do  
visit '/'
click_on 'Flèche triangle
select '', :with => 'Etiquette Humour de la liste des étiquettages'
click_on 'Etiquette Humour'
visit '/'
expect(page).to have_content 'comptes-rendus parcourus'
end
end