Development #22959
Amélioration sélection créneau horaire sur mobile
0%
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
Révisions associées
Historique
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.
Mis à jour par Frédéric Péters il y a environ 4 ans
- Dupliqué par Development #24914: sélection de créneau horaire en mode mobile ajouté
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
Mis à jour par Frédéric Péters il y a environ 4 ans
- Dupliqué par Development #40980: rendre template-meetings responsive ajouté
Mis à jour par Frédéric Péters il y a presque 4 ans
- Fichier creneaux-mobile.png creneaux-mobile.png ajouté
- Fichier 0001-widgets-add-dedicated-mobile-mode-to-meetings-select.patch 0001-widgets-add-dedicated-mobile-mode-to-meetings-select.patch ajouté
- Statut changé de Nouveau à Solution proposée
- Patch proposed changé de Non à Oui
Patch qui s'applique après #41364.
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.
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.
Mis à jour par Frédéric Péters il y a presque 4 ans
- Fichier 0001-widgets-add-dedicated-mobile-mode-to-meetings-select.patch 0001-widgets-add-dedicated-mobile-mode-to-meetings-select.patch ajouté
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.
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.
Mis à jour par Frédéric Péters il y a presque 4 ans
- Fichier 0001-widgets-add-dedicated-mobile-mode-to-meetings-select.patch 0001-widgets-add-dedicated-mobile-mode-to-meetings-select.patch ajouté
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)
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.
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.
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.
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.
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
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).
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.
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.
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)
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
widgets: add dedicated mobile mode to meetings selection (#22959)