Produits Entr'ouvert » Chrono

Maintenant qu'il y a une échéance et un responsable, ajouter dans la description les détails ?

sur chaque demi-journée un indicateur du taux de remplissage des guichets

La suite propose quelque chose de très binaire dans un cas (mono-guichet), moins dans l'autre (multi-guichets); je suggérerais plutôt quelque chose d'uniforme, on a un nombre de créneaux possibles et un nombre de créneaux occupés, ça fait un taux, de là on découpe en quelques zones, genre 5, 0-20, 20-40, etc. et on affiche une couleur en rapport. (lire https://matplotlib.org/users/colormaps.html et inclure une légende sur la page)

Tu peux isoler le s/day-picker/date-picker/ dans un patch isolé ? Là ça rend le début du commit inutilement sans rapport. (et pareil la fin, sortir un "AgendaDateView"du "AgendaDayView", ça ferait partie d'un premier patch préliminaire, de refactoring avant ajout de fonctionnalité).

Mais je me rends compte que ce n'est peut-être en fait pas encore proposé à la relecture, que c'était juste une annonce. ok.

Il y a encore pas mal de trucs à corriger dans le code est les feuilles de style.

Et il faut absolument utiliser Publik en local, je ne regarderai rien sinon.

Ça imite mais la première colonne est inutilement large et il y a des bordures de colonnes moches.

Je comprends mais trouve curieux d'avoir l'emplacement pour la fin/début du mois précédent/suivant, c'est à mon avis le même prix de remplir ces semaines complètement. (parce que sinon pour marquer que ces jours ne sont pas représentés il faudrait dégager le libellé du jour et aussi l'alternance de couleurs de lignes, que ça soit juste du blanc, plutôt qu'un jour pas rempli).

Il faudrait une capture avec un agenda quasi plein, comme ça arrive dans la réalité.

Je préférerais commencer sans inclure les numéros de semaine, ce qui aura comme bénéfice de marquer les coupures dans la première colonne.

Comme les créneaux sont in fine remplis avec les réservations plutôt que contenir un taux (pas plus mal), il ne me semble rien y avoir qui empêche les créneaux de s'agrandir pour afficher le détail, sans devoir quitter cette page. (?)

Frédéric Péters a écrit :

Ça imite mais la première colonne est inutilement large et il y a des bordures de colonnes moches.

Pépin dans Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=688556, c'est réglé.

Je comprends mais trouve curieux d'avoir l'emplacement pour la fin/début du mois précédent/suivant, c'est à mon avis le même prix de remplir ces semaines complètement. (parce que sinon pour marquer que ces jours ne sont pas représentés il faudrait dégager le libellé du jour et aussi l'alternance de couleurs de lignes, que ça soit juste du blanc, plutôt qu'un jour pas rempli).

Ok, j'affiche les jours des mois précedent/suivant (EGW fait pareil), mais je préfère garder les titres un peu plus opaques pour mettre en évidence les jours du mois courant.

Il faudrait une capture avec un agenda quasi plein, comme ça arrive dans la réalité.

Ok, ça arrive.

Comme les créneaux sont in fine remplis avec les réservations plutôt que contenir un taux (pas plus mal), il ne me semble rien y avoir qui empêche les créneaux de s'agrandir pour afficher le détail, sans devoir quitter cette page. (?)

Les blocs sont déjà assez petits, y mettre des infos va surcharger plus la page (je pense notamment à beaucoup de guichet, ce que donnerait beaucoup de petits blocs.

Les blocs sont déjà assez petits, y mettre des infos va surcharger plus la page (je pense notamment à beaucoup de guichet, ce que donnerait beaucoup de petits blocs.

Peut-être que tu as mal compris "de s'agrandir", je propose qu'il puisse s'agrandir, parce que dans leur présentation actuelle, l'agent sera incité à essayer de voir ce à quoi le bloc correspond. Du coup, avoir une réaction genre au clic, permettant d'afficher l'info d'un bloc, ça me semble plutôt nécessaire. Sinon il faut revenir à la description du ticket, qui parlait de demi-journées et de taux, réduire la similarité de l'affichage.

Je me disais que pour voir les détails il y a le lien vers la vue journalière.

Oui bien sûr, mais plutôt que juste pouvoir glisser sa souris pour voir à quelle demande correspond ce rendez-vous isolé vendredi dans deux semaines, il doit cliquer sur le jour puis à nouveau glisser vers le rendez-vous et cliquer dessus pour arriver sur la demande à l'origine; bref ça me semble une économie de clic plutôt immédiate et utile, et à laquelle l'agent s'attendra.

Comme l'info utile que chercherait un agent serait le nom du guichet, je me dis qu'il serait suffisant de l'afficher au survol sur la zone de la réservation (comme dans la capture).

Le nom du guichet c'est vraiment une information peu intéressante, parce que de tes captures j'avais l'impression qu'ils étaient toujours posés pour correspondre à leur ordre (le guichet A sur lequel tu es dans la capture étant le premier guichet, et deux heures plus tôt, je devine visuellement que c'est A et C). Par contre du coup je ne pige pas le cas du jeudi 12, où il y a à la fois une barre unique (ok pour dire "tous les guichets", mais réunir l'info dans une barre me semble inutile, on a la même avec trois barres, comme mardi 10 où tu es en survol (et bizarre comportement différent); et puis il y a aussi l'après-midi du jeudi 12 où il y a deux zones mais séparées).

Pour qu'un scan visuel soit possible, je m'en tiendrais à toujours tenir compte de tous les guichets, et afficher pour chacun d'eux la barre, sur la largeur et la position correspondante.

(ta capture continue à montrer des bordures autour des cellules)

Frédéric Péters a écrit :

Oui bien sûr, mais plutôt que juste pouvoir glisser sa souris pour voir à quelle demande correspond ce rendez-vous isolé vendredi dans deux semaines, il doit cliquer sur le jour puis à nouveau glisser vers le rendez-vous et cliquer dessus pour arriver sur la demande à l'origine; bref ça me semble une économie de clic plutôt immédiate et utile, et à laquelle l'agent s'attendra.

Le résultat attendu, décrit par Brice, est plutôt de voir les guichets réservés (ou libres) pour les affecter à d'autres types de rendez-vous, accorder des congés. Afficher les détails des rendez-vous ici me paraît inutile. Je voyais un interet d'afficher le nom du guichet, mais pas plus.

Par contre du coup je ne pige pas le cas du jeudi 12, où il y a à la fois une barre unique (ok pour dire "tous les guichets", mais réunir l'info dans une barre me semble inutile, on a la même avec trois barres, comme mardi 10 où tu es en survol (et bizarre comportement différent); et puis il y a aussi l'après-midi du jeudi 12 où il y a deux zones mais séparées).

Pour jeudi 12, le matin il n'y a qu'un seul guichet proposant des rendez-vous, d'ou la barre qui prend tout la largeur. Dans l'après midi il y a 2 guichets proposant des rendez-vous. Mardi 10 juillet: 2 guichets le matin, 3 guichets dans l'après-midi.
Si un guichet ne propose pas de rendez-vous pour un creneau donné de la journée, je ne le prend pas en compte dans le calcul des blocs avec les rendez-vous. Mais je n'y tiens pas spécialement, on peut tout à fait afficher le ratio en fonction du nombre total des guichets de l'agenda, et non du nombre de guichets actifs.

Le résultat attendu, décrit par Brice

Mais comme je le notais, ce patch s'éloigne déjà fortement de ça, Brice parlait de demi-journée et d'indicateur de taux. Et je disais que pas de problème pour quitter ça et plutôt s'approcher de la vue d'une journée mais il faut faire ça complètement; ce truc hybride ne marche pas.

Bon ok.
Alors les barres d'occupation s'afficheront en fonction du nombre total de guichets et non nombre actifs. Et au clic on affiche les détails de la résa.

Les résas sont des liens, ouvrant des popups avec les infos du rendez-vous (repris le même principe que sur la vue journalière).

Euh, j'ai quand même vérifié mais il n'y a pas de popup dans cette vue.

Sur cette vue, au hover sur un créneau, il se passe en CSS z-index: 3; height: auto !important; pour assurer une hauteur au bloc permettant d'en visualiser l'entièreté, et passer au-dessus des autres. Le même principe repris dans la vue mensuelle, ce serait vraisemblablement en plus y ajouter une modification sur le width (, pas ajouter une popup).

(je note qu'il y a toujours des bordures de cellule sur la capture)

Frédéric Péters a écrit :

Sur cette vue, au hover sur un créneau, il se passe en CSS z-index: 3; height: auto !important; pour assurer une hauteur au bloc permettant d'en visualiser l'entièreté, et passer au-dessus des autres. Le même principe repris dans la vue mensuelle, ce serait vraisemblablement en plus y ajouter une modification sur le width (, pas ajouter une popup).

Vu la hauteur des blocs des réservations je ne vois pas comment on peut afficher les mêmes infos. Dans la capture que j'ajoutais dans le commentaire #19 la hauteur automatique s'applique au survol, et cela couvre le potentiel bloc de la résa suivante et je ne trouve pas ça clair.
Une autre idée que j'ai eue en re-discutant avec Brice et que la cellule de la journée soit un lien vers la vue journalière, qui afficherait les détails, donc pas d'infos sur les résas dans la vue mensuelle, juste une vue d'ensemble.

Dans la capture que j'ajoutais dans le commentaire #19 la hauteur automatique s'applique au survol, et cela couvre le potentiel bloc de la résa suivante et je ne trouve pas ça clair.

Mais c'est ce qu'on a comme fonctionnement pour la vue au quotidien, et il n'y a pas eu de retour négatif là-dessus.

pas d'infos sur les résas dans la vue mensuelle, juste une vue d'ensemble.

Mais si pas d'infos, quoi ?

La durée de l'animation est exagérée pour les besoins de la vidéo ?

Pour montrer l'exemple, oui.
Sinon ça sera plus rapide: 100ms.

(moins, mais il y a toujours des bordures)

(moins...

C'est-à-dire?

C'est-à-dire que je fais la remarque sur les bordures depuis longtemps et que petit à petit elles disparaissent et que je reconnaissais ça.

Il reste des bordures (joke). Ça imite la vue journalière, je trouve ça bien, l'impression qu'on voit simplement des miniatures des vues journalières, ça me semble très compréhensible ainsi.

Pas regardé le patch, donc je sais pas si c'est jouable, mais je serais pour ne rien afficher pour les jours qui ne sont pas du mois affiché ? Sur l'exemple on voit du vert sur les 30 et 31 juillet et les 1 et 2 septembre, mais comme si y'avait pas de rdv dessus. Ça serait mieux de rien voir du tout, carrément du vide (c'est mon avis).

Thomas Noël a écrit :

Pas regardé le patch, donc je sais pas si c'est jouable, mais je serais pour ne rien afficher pour les jours qui ne sont pas du mois affiché ? Sur l'exemple on voit du vert sur les 30 et 31 juillet et les 1 et 2 septembre, mais comme si y'avait pas de rdv dessus. Ça serait mieux de rien voir du tout, carrément du vide (c'est mon avis).

J'en rajoute une couche sur le style, je trouve qu'il y a trop de gras, les jours et les heures sont toutes grasses et bleues alors que j'attendrais que le gras et la couleur servent de moyen d'attirer l'attention sur qq chose de spécial, et voici ce que je propose comme évolution :
- heures et jours en noir et sans gras
- mettre en bleu (et gras ?) le jour d'aujourd'hui quand il est dans le mois affiché
- mettre en grisé léger les jours dans le passé par rapport à aujourd'hui.

J'ai appliqué les patchs, cliqué partout, regardé dans la console js, executé un tox, tout à l'air d'aller.

Serghei Mihai a écrit :

Ok pour ne rien afficher pour les jours des mois précedent et suivant, ainsi mettant en exergue visuellement le mois en cours.
Rétiré les gras sur les heures et les dates, sauf le jour courant.

Je joins la capture pour valdier, il me reste à adapter les tests.

D'accord, même si j'aurais préféré en plus les jours en noirs, sauf le jour du jour en bleu, pour encore mieux voir le jour courant.

Elias Showk a écrit :

D'accord, même si j'aurais préféré en plus les jours en noirs, sauf le jour du jour en bleu, pour encore mieux voir le jour courant.

Garder le bleu permet à l'usager de comprendre que c'est un lien vers la vue journalière, mais je peux souligner le texte aussi. Je vais une variante comme ça aussi, puis j'inviterai les CPF se prononcer :)

(Le guichet 1 est bien en premier, les rendez-vous ne sont pas posés en commençant par le premier guichet)

Avoir les jours encadrés pourrait peut-être apporter plus de lisibilité (bordure latérale entre les jours et horizontales manquantes, peut-être plus foncée aussi).

Avoir les numéros des semaines pourrait être sympa (première colonne, lignes des jours).

Peut-être enlever aussi les pointillés oranges sous les jours ?

je verrais bien une couleur un peu plus foncée pour la ligne initiale jours consécutifs d'une semaine, et non pas la même couleur que les lignes des heures impaires.

Dans la bulle du hover, il manque peut-être un peu de padding vertical, qui pourrait être le même qu'à l'horizontal.

Faut arrêter avec les bordures. Ce patch ne passera pas avec les bordures.

Ce patch passera uniquement avec un visuel identique à la vue par jour.

Ça veut aussi dire garder en gras les heures, en blanc le fond des lignes de titre, etc.

De l'uniformité ainsi gagnée, on pourra alors discuter des évolutions communes.

(et faut dégager ici le double souligné + bordure bas des liens sur les jours)

Ne pas toucher au style de la vue journalière dans ce ticket; s'il y a des changements souhaités, faire un autre ticket.

#26003 en tant que commentaire sur les CSS.

Il y a une modification à tox.ini qui ne relève pas de ce ticket.

Il faut utiliser le nouveau balisage pour l'appbar.

Du côté du code, j'aurais plutôt tendance à préférer un ordre get_timetable_infos / get_week_timetable_infos / get_day_timetable_infos, que l'ordre de lecture corresponde à l'ordre d'exécution.

Je trouve curieux d'avoir dans get_timetable_infos un yield, mais pas dans les autres, passons.

        for i, week_number in enumerate(range(first_week_number, last_week_number + 1)):
            yield self.get_week_timetable_infos(i, timeperiods)

Une longue ligne pour lancer la boucle alors qu'il y a juste i qui est utilisé.

        self.min_timeperiod = min([x.start_time for x in timeperiods])
        self.max_timeperiod = max([x.end_time for x in timeperiods])
        self.interval = datetime.timedelta(minutes=60)

Pas bon de passer des infos d'une méthode à l'autre en tapant ça en attribut de l'objet, plutôt ajouter en paramètres ce qu'attend get_day_timetable_infos().

qui pourrait aller dans un autre ticket,

Oui, pas ici.

0003 sans rapport.

Sans la dependance de pytz les tests en django18 explosent:

Tu n'inclus pas le test qui échoue; est-ce un nouveau ? Et il n'y a pour la peine plus cette modification, je n'arrive pas à suivre. Soit elle est nécessaire pour le nouveau test_agenda_month_view et ça doit aller dans le patch correspondant. Soit pour une raison particulière tu en as besoin en local déjà avant, et alors ça doit aller dans son propre ticket.

Il s'agit bien du test test_agenda_month_view.
J'avais retiré le dependance pour voir les relecteurs ont le même échec en executant les tests.

Je vais essayer de piger ce que cloche, car je surpris que les tests de la vue journalière n'échouent pas.

Tu expliques pourquoi ne pas en avoir besoin en 1.11, pas pourquoi tu en as besoin. La documentation que tu pointes parle d'un "datetimes" que je ne vois pas dans les patchs. Ma supposition maintenant c'est que c'est caché derrière MonthArchiveView.

"add agenda's month and booking view" ça ne me semble pas très correct comme sujet. Mentionner ce ticket en référence pour les deux autres.

Je ne suis pas assez explicite.
Effectivement datetimes est appelée par la mécanique la CBV MonthArchiveView, qui fait appel au backend la base des données pour rendre aware les champs start_datetime du modèle Event.
SQLite ne sachant pas le faire il fait appel à pytz.

pytz est une dépendance de django-1.11 mais pas django-1.8. Donc il est nécessaire pour que les tests passent en 1.8.

                    # don't consider cancelled bookings 
                    bookings = [x for x in event.booking_set.all() if not x.cancellation_datetime] 
                    if not bookings: 
                        continue

La situation "if not bookings" n'est pas testée.

J'écrivais : il faut utiliser le nouveau balisage pour l'appbar.

Toujours d'application.

Et à tester, alors que je pensais qu'il s'agissait de modifier un existant, je vois que non, côté vue mensuelle, il n'y a actuellement pas du tout de séparation entre jours.

Comme pour la vue par jour, il faudrait un espace, et ça se gère du côté du code, "height:333.0%;top:66.0%;width:33.3%;left:0.0%;" etc. qui ne devrait pas coller les éléments. Simplement je ferais les calcul sur une base de 5 + (9/10 * ton pourcentage), pour assurer une séparation entre jours.

Et pour la séparation entre guichet je "tricherais" avec un box-sizing: border-box (s'il n'est déjà là) + border-left/right: 3px quelque chose.

La séparation entre les jours je la vois en rajoutant une "bordure" entre les colonnes du tableau.

Discussion pour l'autre ticket. (mais non, pas de bordures, même avec dex faux guillemets).

Ok pour ce patch.

On remarquera le (+14) dans les lignes notées par pylint sur https://jenkins.entrouvert.org/job/chrono/948/ , dont quelques-unes qui redisent :

        self.min_timeperiod = min([x.start_time for x in timeperiods])
        self.max_timeperiod = max([x.end_time for x in timeperiods])
        self.interval = datetime.timedelta(minutes=60)

Pas bon de passer des infos d'une méthode à l'autre en tapant ça en attribut de l'objet, plutôt ajouter en paramètres ce qu'attend get_day_timetable_infos().

que j'ai laissé pisser…