Projet

Général

Profil

Development #22959

Amélioration sélection créneau horaire sur mobile

Ajouté par Brice Mallet il y a presque 6 ans. Mis à jour il y a presque 4 ans.

Statut:
Fermé
Priorité:
Normal
Assigné à:
Version cible:
-
Début:
03 avril 2018
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Oui
Planning:
Non

Description

Actuellement un champ de type liste avec le style "template-meetings" s'affiche sur 5 colonnes, que ce soit en vue desktop ou sur écran smartphone (cf. Chrono FO actuel.png).
Il serait intéressant d'améliorer la version responsive design, pê en diminuant le nombre de colonnes affichées (passer à 3 ?)
NB : questionnement du fait de la demande de la Ville d'Arles qui donne un exemple d'une vue responsive design dans son cahier des charges (cf. Exemple vue souhaitée par Arles.png).


Fichiers


Demandes liées

Dupliqué par Intégrations graphiques Publik - Development #24914: sélection de créneau horaire en mode mobileRejeté02 juillet 2018

Actions
Dupliqué par Intégrations graphiques Publik - Development #40980: rendre template-meetings responsiveRejeté24 mars 2020

Actions

Révisions associées

Révision cfcb26b1 (diff)
Ajouté par Frédéric Péters il y a presque 4 ans

widgets: add dedicated mobile mode to meetings selection (#22959)

Historique

#1

Mis à jour par Frédéric Péters il y a presque 6 ans

  • Projet changé de Combo à Intégrations graphiques Publik

C'est dans publik-base-theme que se trouve ce modèle de champ.

#2

Mis à jour par Frédéric Péters il y a environ 4 ans

#3

Mis à jour par Frédéric Péters il y a environ 4 ans

  • Sujet changé de Amélioration de la vue calendrier FO en responsive design à Amélioration sélection créneau horaire sur mobile
#4

Mis à jour par Frédéric Péters il y a environ 4 ans

#5

Mis à jour par Frédéric Péters il y a presque 4 ans

  • Assigné à mis à Frédéric Péters
#6

Mis à jour par Frédéric Péters il y a presque 4 ans

Patch qui s'applique après #41364.

#7

Mis à jour par Thomas Jund il y a presque 4 ans

Belle proposition Fred.
J'utiliserais quand même un debounce sur le resize, même si on pense que cet événement devrait se produire peu souvent.

#8

Mis à jour par Frédéric Péters il y a presque 4 ans

Pas la moindre idée.

#9

Mis à jour par Thomas Jund il y a presque 4 ans

C'est en rapport avec #41364, mais la position du `$select.trigger('wcs:options-change');` est étonnante non ? (elle est en dehors de la function 'DOM ready' de Jquery).

Un debounce est un fonction qui va permettre à la fonction passé dons l'event resize de ne s'executer qu'à la fin du resize et pas 1000x
https://eloquentjavascript.net/15_event.html#h_AOVmaqj10Ihttps://eloquentjavascript.net/15_event.html#h_AOVmaqj10I

Et côté CSS, j'ajouterais un `align-items: flex-start` à `meetings_table` pour que les boutons ne soient pas stetch en desktop.

#10

Mis à jour par Frédéric Péters il y a presque 4 ans

C'est en rapport avec #41364, mais la position du `$select.trigger('wcs:options-change');` est étonnante non ? (elle est en dehors de la function 'DOM ready' de Jquery).

Non c'est juste une indentation bizarre pour ne pas tout réindenter.

Un debounce est un fonction qui va permettre à la fonction passé dons l'event resize de ne s'executer qu'à la fin du resize et pas 1000x
https://eloquentjavascript.net/15_event.html#h_AOVmaqj10I

ok; il est pointé là 500ms mais à tester c'est énorme et du coup ici 50ms qui donne encore presque l'impression que ça se fait tout de suite.

Et côté CSS, j'ajouterais un `align-items: flex-start` à `meetings_table` pour que les boutons ne soient pas stetch en desktop.

Yep je pense qu'il y a des trucs à faire aussi pour la présentation desktop, mais pas dans ce ticket.

#11

Mis à jour par Thomas Jund il y a presque 4 ans

Yep je pense qu'il y a des trucs à faire aussi pour la présentation desktop, mais pas dans ce ticket.

Certe ça touche à la présentation desktop, mais ça évite aussi de mettre le `height: 3em` sur `.mobile button`. Et donc d'ajouter une spécificité inutile à ce patch.
Pour moi, soit on laisse les boutons en stretch sur mobile ET Desktop (parce que le design des boutons ne concerne pas ce patch), soit on les patch pour les 2 viewport avec 1 seule déclaration CSS pour être cohérent graphiquement. Mais pas ajouter une ligne de code spécifique avec une valeur pifométrique.

#12

Mis à jour par Frédéric Péters il y a presque 4 ans

Mais ça demanderait de chercher dans l'historique pourquoi les boutons sont comme ça actuellement (parce que je viens de voir dans la capture attachée initialement au ticket, ils ne le sont pas), de peut-être justifier un changement à rebours ou rendre spécifique une intégration, etc.

(ou d'ignorer tout ça, option prise)

#13

Mis à jour par Thomas Jund il y a presque 4 ans

  • Statut changé de Solution proposée à Solution validée

Je viens de tester le debounce. J'ai peur que 50ms soit une valeur inférieur à la valeur de répétition de la fonction par le navigateur. Ça ne joue pas son rôle.
chez moi 150 / 200 ms fonctionne bien.

Et pour le reste, je valide.

#14

Mis à jour par Frédéric Péters il y a presque 4 ans

Je viens de tester le debounce. J'ai peur que 50ms soit une valeur inférieur à la valeur de répétition de la fonction par le navigateur. Ça ne joue pas son rôle.

Je ne sais pas ce que c'est "valeur de répétition de la fonction". Tu veux dire qu'un timeout exécuté à 50ms serait en fait exécuté immédiatement ? Ça me semble bien curieux. Et dans mon idée, donc, 50ms, ça fait l'événement appelé au max une fois toutes les 50ms, et donc pas 1000× qui était la crainte d'un commentaire précédent.

#15

Mis à jour par Benjamin Dauvergne il y a presque 4 ans

Sinon il y a aussi https://developer.mozilla.org/fr/docs/Web/API/Window/requestAnimationFrame qui a l'air plus simple à gérer.

#16

Mis à jour par Thomas Jund il y a presque 4 ans

Je ne sais pas ce que c'est "valeur de répétition de la fonction". Tu veux dire qu'un timeout exécuté à 50ms serait en fait exécuté immédiatement ? Ça me semble bien curieux. Et dans mon idée, donc, 50ms, ça fait l'événement appelé au max une fois toutes les 50ms, et donc pas 1000× qui était la crainte d'un commentaire précédent.

1000x c'était clairement exagéré (et encore ça dépend). La vitesse de répétition d'une fonction est dépendante de pleins de facteurs, dont la durée d’exécution de la fonction elle même. Il y a aussi le facteur "resize" manuel d'une fenêtre par l'utilisateur (mon test). Dans un resize d'un point A vers un point B, s'arrêter + de 50ms en court de route arrive très très souvent avec une sourie et encore + souvent avec un trackpad. s'arrêter 100ms ou 200ms en court de route arrive moins souvent.

Mais même si elle n'est répétée que 20 ou 50x, entre explorer le DOM 50x en 1s pour vérifier la taille d'un élément ou le faire qu'une fois, utiliser un debounce dans ce cas reste une bonne pratique et est justifié à mon avis.

Sinon il y a aussi https://developer.mozilla.org/fr/docs/Web/API/Window/requestAnimationFrame qui a l'air plus simple à gérer.

Oui "requestAnimationFrame" peut être utilisé à la place de 'setTimeout'. RequestAnimationFrame est calé sur une execution de 60 frames par seconde (1x toutes les 16ms) par défaut. Mais je ne suis pas sûr de son intérêt au sein d'un debounce.

#17

Mis à jour par Benjamin Dauvergne il y a presque 4 ans

Thomas Jund a écrit :

Oui "requestAnimationFrame" peut être utilisé à la place de 'setTimeout'. RequestAnimationFrame est calé sur une execution de 60 frames par seconde (1x toutes les 16ms) par défaut. Mais je ne suis pas sûr de son intérêt au sein d'un debounce.

Je n'ai pas d'avis, j'ai juste vu ça conseillé là1 quand ça concerne du layout (mais ça parle aussi de debounce et throttle).

1 https://css-tricks.com/debouncing-throttling-explained-examples/#article-header-id-4

#18

Mis à jour par Frédéric Péters il y a presque 4 ans

Mais même si elle n'est répétée que 20 ou 50x, (...)

J'ai donc mesuré, avec Firefox et Chromium, en redimensionnant la fenêtre ou la vue en mode "responsive", lentement ou rapidement, 1/ le code de set_layout prend quelques millisecondes, souvent 2 ou 3, 2/ est bien sûr appelé plusieurs fois quand je redimensionne très lentement la fenêtre, mais ni 1000×, ni même 10×.

Alors ok pour la mécanique, mais le délai de 50ms que j'utilise, il fonctionne, et il me donne une impression d'immédiateté que les 200ms ne donnent pas.

(je pousserai néanmoins le patch avec 200ms).

#19

Mis à jour par Thomas Jund il y a presque 4 ans

Sans le debounce, en plaçant un

    console.log(performance.now());

dans la fonction set_layout() j'ai une 40e d’exécutions par seconde sur ma machine. Soit une toutes les 20 - 25 ms.

#20

Mis à jour par Frédéric Péters il y a presque 4 ans

Sans le debounce

Sans doute pas clair, mais j'écrivais "ok pour la mécanique" et "le délai de 50ms que j'utilise", pour pointer que mes mesures se faisaient dans ces conditions.

#21

Mis à jour par Frédéric Péters il y a presque 4 ans

  • Statut changé de Solution validée à Résolu (à déployer)
commit d87483fe6eeca9b27a6328fe474ae5dddb37e1a8
Author: Frédéric Péters <fpeters@entrouvert.com>
Date:   Mon Apr 6 15:22:00 2020 +0200

    templates: refresh meetings when live source changes (#41364)
#22

Mis à jour par Frédéric Péters il y a presque 4 ans

  • Statut changé de Résolu (à déployer) à Solution déployée

Formats disponibles : Atom PDF