search

remipichon / manifmaker

MIT License
1 stars 1 forks source link

design assignment #199

Open remipichon opened 8 years ago

remipichon commented 8 years ago
PtiLuky commented 8 years ago

Pour le choix de la période, on laisse un select list, ou quelque chose de plus visuel comme un calendrier sur lequel on peut choisir une période ?

Je me demande surtout si le second est plus efficace pour l'utilisateur ? Ca me parait assez compliqué techniquement pour une option qui n’apparaît pour pas beaucoup d'utilisateurs

remipichon commented 8 years ago

Les périodes d'affectations sont définies à l'avance, ça reste donc des select (mais avec le Custom select).

On Aug 8, 2016 18:47, "PtiLuky" notifications@github.com wrote:

Pour le choix de la période, on laisse un select list, ou quelque chose de plus visuel comme un calendrier sur lequel on peut choisir une période ?

Je me demande surtout si le second est plus efficace pour l'utilisateur ? Ca me parait assez compliqué techniquement pour une option qui n’apparaît pour pas beaucoup d'utilisateurs

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/assomaker/manifmaker/issues/199#issuecomment-238297011, or mute the thread https://github.com/notifications/unsubscribe-auth/ADuJ-oMsp3d84bUZ789Dz-NydMya8Brsks5qd12IgaJpZM4JTJO0 .

remipichon commented 8 years ago

Les périodes d'affectation correspondront à "collage", "pré manif", "manif" et ce genre de truc pour les 24.

Le 8 août 2016 19:09, "Rémi Pichon" pichon.remi.pr@gmail.com a écrit :

Les périodes d'affectations sont définies à l'avance, ça reste donc des select (mais avec le Custom select).

On Aug 8, 2016 18:47, "PtiLuky" notifications@github.com wrote:

Pour le choix de la période, on laisse un select list, ou quelque chose de plus visuel comme un calendrier sur lequel on peut choisir une période ?

Je me demande surtout si le second est plus efficace pour l'utilisateur ? Ca me parait assez compliqué techniquement pour une option qui n’apparaît pour pas beaucoup d'utilisateurs

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/assomaker/manifmaker/issues/199#issuecomment-238297011, or mute the thread https://github.com/notifications/unsubscribe-auth/ADuJ-oMsp3d84bUZ789Dz-NydMya8Brsks5qd12IgaJpZM4JTJO0 .

PtiLuky commented 8 years ago

First design preview : https://app.moqups.com/Remip2/TCwTCzfxUD/view/page/a7c50f082

PtiLuky commented 8 years ago

Ajouter une seconde partie sous la TopNavBar (comme sur la preview ici) dans le template, qui peut servir aussi pour afficher les erreurs ou notifications ?

Aussi faut que je le "vide" par défaut, dans Router.onAfterAction dans route-common ?

remipichon commented 8 years ago

Pour les erreurs et notifications nous devrons mettre en place un système générique applicable à toutes les pages.

Pour la deuxième ligne de la TopBar, elle est "yield" par IronRouter dans le AssignmentController dont hérite toutes les routes de de assignement.

Pour le moment le reset de TopNavBar est fait n'importe comment dans Router.onAfterAction (_route-_common.js) où je rends du vide dans le "yield". Je vais mettre en place un système de contrôleur IronRouter plus intelligent mais je dois lire pas mal de doc pour savoir comment faire proprement.

Si ça ne te bloque pas, concentre toi sur sur la page d'affectation sans te soucier du workflow de changement de page.

On Aug 9, 2016 6:18 PM, "PtiLuky" notifications@github.com wrote:

Ajouter une seconde partie sous la TopNavBar (comme sur la preview ici) dans le template, qui peut servir aussi pour afficher les erreurs ou notifications ?

Aussi faut que je le "vide" par défaut, dans Router.onAfterAction dans route-common ?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/assomaker/manifmaker/issues/199#issuecomment-238606097, or mute the thread https://github.com/notifications/unsubscribe-auth/ADuJ-hGCVGIMzVMduCipkcWxgkp-Tvg9ks5qeKhAgaJpZM4JTJO0 .

PtiLuky commented 8 years ago

Oui oui, justement, à la manière de la navbar, j'ai mis un complément de navbar (sur les deux derniers commits) (pour mettre les boutons de mode d'assignement), qui peut être mise sur toutes les pages du coup, d'où l'idée qu'on peut récupérer cette complement de nav-bar pour afficher les notifs par exemple.

A voir si ça sera à refaire plus proprement, y a pas de soucis.

remipichon commented 8 years ago

Je vois ce que tu as fais avec le "topNavBarComplement", c'est l'idée ça fonctionne. Il faut juste factoriser les deux "topNavBar" pour en avoir qu'un seul à "yield". Le comportement spécifique résidant à un niveau en dessous.

Pour le moment reste comme ça, nous ferons différemment si nécessaire en fonction de ce que nous déciderons pour la gestion des erreurs et l'affichage des notifications.

Le 10 août 2016 19:23, "PtiLuky" notifications@github.com a écrit :

Oui oui, justement, à la manière de la navbar, j'ai mis un complément de navbar (sur les deux derniers commits) (pour mettre les boutons de mode d'assignement), qui peut être mise sur toutes les pages du coup, d'où l'idée qu'on peut récupérer cette complement de nav-bar pour afficher les notifs par exemple.

A voir si ça sera à refaire plus proprement, y a pas de soucis.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/assomaker/manifmaker/issues/199#issuecomment-238939078, or mute the thread https://github.com/notifications/unsubscribe-auth/ADuJ-ueocca68hBnU5O0cpZUNfDbcKGtks5qegkBgaJpZM4JTJO0 .

PtiLuky commented 8 years ago

Qu'est ce que tu entends par "design de la popup", je vois pas de quelle partie tu parles.

ToDo :

remipichon commented 8 years ago

Le design du calendrier concerne l'affichage des besoins orga sur les créneaux dans le calendrier.

Le design de la popup concerne la popup de la liste des besoins orga exhaustif (nom affectés et affectés) qui s'affiche au hover d'un créneau.

Les deux ont besoin de passer par un Mockup car ce sont des éléments compliqués auxquels un fonctionnel fort est lié. En effet, ces deux éléments permettent l'affectation et la désaffectation.

On Aug 13, 2016 12:59 PM, "PtiLuky" notifications@github.com wrote:

Qu'est ce que tu entends par "design de la popup", je vois pas de quelle partie tu parles.

ToDo :

  • design de la popup
  • design du calendrier

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/assomaker/manifmaker/issues/199#issuecomment-239615368, or mute the thread https://github.com/notifications/unsubscribe-auth/ADuJ-kIQOP2Yk3vGrOIDGT0VyVfctxecks5qfaOXgaJpZM4JTJO0 .

remipichon commented 7 years ago

@PtiLuky gogogogo, derniere ligne droite pour valider toute la partie affectation !

remipichon commented 7 years ago

timeslot on calendar

popover people needed

remipichon commented 7 years ago

Est ce que tu as avancé cette tache ? As tu besoin d'aide ? As tu une idée de quand pourras tu la livrer ?

PtiLuky commented 7 years ago

J'ai à peine avancé cette tache,

J'aurais juste une question au niveau des clics : je comprends pas bien tout le comportement au clic, j'arrive pas à avoir la différence coté code d'un clic sur un créneau de UserToTask (qui ne répond pas) et d'un clic sur TaskToUser qui lui répond bien, mais laisse passer le clic à travers (donc il considère un clic sur le créneau + sur le calendrier.

Je pourrais bosser dessus ce WE, si j'arrive à gérer la galère niveau clics, ça devrait être bon, sinon ça peut me prendre un peu plus.

remipichon commented 7 years ago

Je crois que j'ai compris ton problème.

En mode userToTask, un clic sur un le créneau laisse passer l'event qui atteint la calendrier afin de pouvoir sélectionner l'heure du clic. En effet, si l'event s'arrête sur le créneau la seule heure à récupérer est l'heure du début du créneau (qui est en fait une disponibilité)

En mode taskToUser, le clic n'atteint pas le calendrier puisque les informations d'horaire dont nous avons besoin sont le début et la fin du créneau. Ces informations se trouvent sur le créneau sur lequel a lieu le clic.

Actuellement, en mode taskToUser un click sur le créneau est capturé pour pouvoir sélectionner le timeSlot ET le peopleNeed (s'il y a). C'est ici que tu dois travailler n'est ce pas ?

Le 2 nov. 2016 14:21, "PtiLuky" notifications@github.com a écrit :

J'ai à peine avancé cette tache,

J'aurais juste une question au niveau des clics : je comprends pas bien tout le comportement au clic, j'arrive pas à avoir la différence coté code d'un clic sur un créneau de UserToTask (qui ne répond pas) et d'un clic sur TaskToUser qui lui répond bien, mais laisse passer le clic à travers (donc il considère un clic sur le créneau + sur le calendrier.

Je pourrais bosser dessus ce WE, si j'arrive à gérer la galère niveau clics, ça devrait être bon, sinon ça peut me prendre un peu plus.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/assomaker/manifmaker/issues/199#issuecomment-257861925, or mute the thread https://github.com/notifications/unsubscribe-auth/ADuJ-iVKHvV3BBleFMmE5eLSsVDogdDbks5q6I5NgaJpZM4JTJO0 .

PtiLuky commented 7 years ago

Ouais c'est ça,

Du coup en UserToTask, on reste bien en mode clic sur l'heure, et juste du pop-up pour taskToUser (bon, et tous les clics dans le pop-up) c'est ça ?

remipichon commented 7 years ago

En UserToTask on ne change rien non ?

En TaskToUser, effectivement on ne garde que les clics sur le popup.

Si tu as du mal à gerer les events (c'est un peu compliqué, les noms des classes sont tres mal choisis), on peut se faire un petit call en journée vendredi ou vendredi soir.

Remi Pichon

Le 2 novembre 2016 à 23:22, PtiLuky notifications@github.com a écrit :

Ouais c'est ça,

Du coup en UserToTask, on reste bien en mode clic sur l'heure, et juste du pop-up pour taskToUser (bon, et tous les clics dans le pop-up) c'est ça ?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/assomaker/manifmaker/issues/199#issuecomment-258017549, or mute the thread https://github.com/notifications/unsubscribe-auth/ADuJ-jOZG3beE_iQ5SKmkDwo3QBJSS-Yks5q6Q0ZgaJpZM4JTJO0 .

remipichon commented 7 years ago

Est ce que tu t'en sors ?

PtiLuky commented 7 years ago

Ouais ça devrait aller, today j'ai pas trop de temps, je te dis ça dan les deux jours qui arrivent !

PtiLuky commented 7 years ago

Du coup j'ai pas mal avancé là dessus,

Normalement il ne reste plus qu'à organiser le contenue de la pop-up en 2 colonnes et c'est bon.

@remipichon Par contre au niveau de l'affectation, quand on doit choisir un User pour l'affecter, si on clique dans le cadre ça l'affecte bien, mais si on clique sur son nom, ça change de mode vers UserToTask, c'est un peu galère nan ?

remipichon commented 7 years ago

Excellent !

Tu as commit/push pour que je vois ca ?

Je suis d'accord que ca fasse étrange, j'avais vu ca comme un moyen rapide de switcher d'un mode à l'autre mais je doute de sa pertinence. Penses tu qu'il faille totalement enlever ce "raccourcis" ?

Remi Pichon

Le 6 novembre 2016 à 21:41, PtiLuky notifications@github.com a écrit :

Du coup j'ai pas mal avancé là dessus,

Normalement il ne reste plus qu'à organiser le contenue de la pop-up en 2 colonnes et c'est bon.

@remipichon https://github.com/remipichon Par contre au niveau de l'affectation, quand on doit choisir un User pour l'affecter, si on clique dans le cadre ça l'affecte bien, mais si on clique sur son nom, ça change de mode vers UserToTask, c'est un peu galère nan ?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/assomaker/manifmaker/issues/199#issuecomment-258709015, or mute the thread https://github.com/notifications/unsubscribe-auth/ADuJ-qNhjgZUjHTvqb41JlJ5uQX3XvLWks5q7jt0gaJpZM4JTJO0 .

PtiLuky commented 7 years ago

Commit https://github.com/assomaker/manifmaker/commit/e2ec804013c18b552e9f2d1af692d176daeee481

A voir, pour peser le pour et le contre comme quoi il n'y a que des utilisateurs "avancés" qui ont accès à cette page donc ils pourraient savoir ? Après moi je suis vraiment pas fan du fait qu'on puisse "annuler" tout le procédé de sélection qu'on vient de faire en cliquant sur le texte, je serais plutôt pour l'enlever perso (ou qu'il ne soit plus actif quand on a sélectionné un créneau, mais c'est p-e un peu chiant à gérer)

remipichon commented 7 years ago

Pas mal la popup. En revanche as tu terminé de travailler sur son positionnement su la page ?

A voir effectivement, nous demanderons aux testeurs ce qu'ils en pensent. Il s'agit de ne pas ajouter le "href" sur les names pour ne conserver que le clic sur l'ensemble du cadre pour poursuivre le workflow d'affectation. Le "href"

Remi Pichon

Le 6 novembre 2016 à 21:52, PtiLuky notifications@github.com a écrit :

Commit e2ec804 https://github.com/assomaker/manifmaker/commit/e2ec804013c18b552e9f2d1af692d176daeee481

A voir, pour peser le pour et le contre comme quoi il n'y a que des utilisateurs "avancés" qui ont accès à cette page donc ils pourraient savoir ? Après moi je suis vraiment pas fan du fait qu'on puisse "annuler" tout le procédé de sélection qu'on vient de faire en cliquant sur le texte, je serais plutôt pour l'enlever perso (ou qu'il ne soit plus actif quand on a sélectionné un créneau, mais c'est p-e un peu chiant à gérer)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/assomaker/manifmaker/issues/199#issuecomment-258709683, or mute the thread https://github.com/notifications/unsubscribe-auth/ADuJ-mgkZ70ZPguYhylpDyC1v-Gqyb6nks5q7j3zgaJpZM4JTJO0 .

PtiLuky commented 7 years ago

Voilà j'ai push le design de la popover en elle-même,

Le placement j'en suis pas trop satisfait, je ne sais plus si on avait dit qu'elle s'affichait toujours à une hauteur fixée (ici c'est le cas, juste sous les titres), ou quelque chose comme 100px au dessus de créneau (je crois qu'on avait dit ça). Aussi là elle occupe pas toute la largeur, et je pense que ça fait moche, qu'en penses-tu ? Une sorte d'ombre portée aiderait à la différencier du fond ? J'ai peur que ça fasse trop effet web 2000 l'ombre.

Je teste tout ça, dis-moi ce que t'en penses aussi ;)

remipichon commented 7 years ago

Je vois les listes, en revanche il faut bien différencier chaque besoin orga différent (par un cadre, un trait...) car les besoins orga ne feront pas toujours le meme nombre de ligne (ce n'est pas 1 ligne = 1 besoin orga).

Pour le placement, ce qui est sur c'est qu'il faut la placer sur l'écran, visible par le user directement apres un clic sur un des creneaux. L'idée de la hauteur fixe ne va pas car le calendrier ne rentrera pas forcément completement sur l'écran du user (j'avais oublié ce 'détail').

Je suis aussi d'avis de dire que ce sera plus homogene si la popover occupe toute la largeur du calendrier.

Pour l'ombre je suis aussi contre, pas besoin d'en faire plus je trouve qu'elle se démarque bien assez bien. A la limite une petite bordure pour accentuer l'effet popover.

Remi Pichon

Le 6 novembre 2016 à 22:13, PtiLuky notifications@github.com a écrit :

Voilà j'ai push le design de la popover en elle-même,

Le placement j'en suis pas trop satisfait, je ne sais plus si on avait dit qu'elle s'affichait toujours à une hauteur fixée (ici c'est le cas, juste sous les titres), ou quelque chose comme 100px au dessus de créneau (je crois qu'on avait dit ça). Aussi là elle occupe pas toute la largeur, et je pense que ça fait moche, qu'en penses-tu ? Une sorte d'ombre portée aiderait à la différencier du fond ? J'ai peur que ça fasse trop effet web 2000 l'ombre.

Je teste tout ça, dis-moi ce que t'en penses aussi ;)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/assomaker/manifmaker/issues/199#issuecomment-258711128, or mute the thread https://github.com/notifications/unsubscribe-auth/ADuJ-gCvLBMClyRo3bSbFQ6az81gH0Msks5q7kLqgaJpZM4JTJO0 .

PtiLuky commented 7 years ago

https://github.com/assomaker/manifmaker/commit/61218552e95c017d5a94fb30d6b0ad42f5965bfa

Du coup, largeur plus cohérente avec le calendrier, hauteur qui s'adapte au contenu, et l'ombre...

Ahhhh, j'avais pas encore eu ton retour, du coup je l'enleve pour le prochain commit ;)

Et en position:fixed sur la page ça va, ou ça risque de poser problème s'il y a trop de besoins (et donc dépasser vers le bas) non ?

PtiLuky commented 7 years ago

https://github.com/assomaker/manifmaker/commit/e5f97fe4eb99b28538f0b6b566bb59198209a9f8

Hop, les modifs indiquées sont faites

SAUF le placement vertical, pour l'instant il est fixé sur le calendrier, l'autre alternative "facile" serait de le fixer à la page.

La galère pour l'afficher juste au dessus du créneau est de l'avoir centré par rapport à la page (placement absolu) et juste au dessus de son élément parent (placement relatif), du coup si tu vois une astuce pour contourner ça...

remipichon commented 7 years ago

Okay, on peut réflechir differement et si dire que le calendrier dans son ensemble est un panneau qui peut afficher soit le calendrier, soit le détail du creneau selectionné. C'est un peu dommage de generer la totalité du calendrier a chaque fois, il est assez lourd à charger lorsque le term est long. Du coup on garde cette idée de panneau mais en l'adaptant à ta popover. La popover vient donc prendre toute la largeur du calendrier et toute la hauteur visible de sorte à pouvoir etre lue sans scroller. D'un point de vue technique (pour le placement sur tout ce qui est visible), ca se fait en CSS, j'ai su faire ca il y a un temps dans ma jeunesse. As tu une idée ? Répondre à la problématique du placement de la popover repondra aussi à la question du déplacement vertical des listes afin qu'elles soit toujours visible lorsque l'utilisateur descend dans la page (scroll sur le calendrier).

Remi Pichon

Le 6 novembre 2016 à 22:57, PtiLuky notifications@github.com a écrit :

e5f97fe https://github.com/assomaker/manifmaker/commit/e5f97fe4eb99b28538f0b6b566bb59198209a9f8

Hop, les modifs indiquées sont faire

SAUF le placement vertical, pour l'instant il est fixé sur le calendrier, l'autre alternative "facile" serait de le fixer à la page.

La galère pour l'afficher juste au dessus du créneau est de l'avoir centré par rapport à la page (placement absolu) et juste au dessus de son élément parent (placement relatif), du coup si tu vois une astuce pour contourner ça...

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/assomaker/manifmaker/issues/199#issuecomment-258714026, or mute the thread https://github.com/notifications/unsubscribe-auth/ADuJ-g3cLXp3RGtIOdLB4M4Gm5wOD49Bks5q7k1MgaJpZM4JTJO0 .

remipichon commented 7 years ago

En fait je viens de penser à un truc, pourquoi ne pas faire que le calendrier et la liste scrollable. Plus précisement, les heures du calendrier sont scrollables mais le header avec les jours restent visible. De plus, les listes users et tasks sont scrollables mais les headers de filtre reste visible. En revanche la liste des taches (en bas) peut etre masquée si la liste des users (en haut) est grande. Mais en scrollant la liste des users on retombe sur le header de la liste des task. Et de toute facon le workflow devra etre fait pour reduire et aggrandir les listes en fonction de ce qui est pertinent (ce sera lié au helper dans le header de la page).

Capiche ?

remipichon commented 7 years ago

Ho shit, Trump president

279

PtiLuky commented 7 years ago

Ouais, cette solution me parle bien !

remipichon commented 7 years ago

Je ne sais pas si tu as eu mon commentaire sur un autre moyen de gérer ça.

Au lieu que toute la page soit scrollable, juste les heures du calendrier le sont (ainsi, le header des jours restent naturellement fixé en haut).

De même, seules les listes Users et Tasks sont scrollables (ainsi, le header de filtre de chaque liste sont toujours visible lorsqu'on scroll la liste correspondante).

Il s'agit d'avoir 3 zone de scrolling

Si la liste des Users (celle du dessus) est longue, la liste des Tasks sera masquée. En scrollant la liste des Users, on finit sir le header de la liste des Tasks pour pouvoir interagir avec.

A nous d'aider l'utilisateur est affichant et masquant les listes en fonction de ce qui est pertinent dans le worklow. Ceci pourra être fait ou inspiré par le code du breadcrumb d'aide (header de la page).

Est ce clair ?

Le 10 nov. 2016 18:35, "PtiLuky" notifications@github.com a écrit :

Ouais, cette solution me parle bien !

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/assomaker/manifmaker/issues/199#issuecomment-259755047, or mute the thread https://github.com/notifications/unsubscribe-auth/ADuJ-s_Z8YQQQTfHx-0Yi2VgQHiht8YCks5q81XTgaJpZM4JTJO0 .

PtiLuky commented 7 years ago

Yep je vois, après pour implémenter ça j'ai juste une petite indétermination sur les hauteurs du coup, Pour avoir à scroller il faut donner une hauteur max, et à ce niveau là je ne sais pas quoi choisir :

Le plus simple (enfin surtout le moins bricolé) c'est de fixer une hauteur max des éléments au dessus de laquelle on scroll, mais si cette hauteur max dépasse déjà de notre écran, ou au contraire est beaucoup plus petite que l'écran, ça fera moche.

Bref, les placement verticaux c'est ma petite hantise en CSS et il faut avouer que j'ai un peu de mal ><

remipichon commented 7 years ago

Okay, je pensais en mode Android où on peut facilement mettre des listes. Il faut donc compter sur le scroll de la page pour gérer nos deux scrolls. Disons que le scroll de la page agit sur le calendrier comme actuellement sauf que le header des jours est fixé sur la page. Concernant les deux listes, elles sont fixées sur la page, comme le header des jours du calendrier pour suivre le scrolling. Leur affichage/masquage reste le même. Mais si on scroll l'une de ses listes, ça fera scroller le calendrier...

Hum, je bloque

Le 11 nov. 2016 14:53, "PtiLuky" notifications@github.com a écrit :

Yep je vois, après pour implémenter ça j'ai juste une petite indétermination sur les hauteurs du coup, Pour avoir à scroller il faut donner une hauteur max, et à ce niveau là je ne sais pas quoi choisir :

  • en fonction de l'écran ? (mais attention ça prend la taille de l'écran et pas de la fenêtre... ça peut toujours être utile mais peu précis)
  • en CSS on fixe une hauteur max arbitraire (qui peut être en fonction de la device-size)
  • trouver une solution propre en CSS pour remplir 100% de la hauteur et ensuite passer en scrolling (j'ai passé quelques temps à bidouiller pour essayer de faire ça, mais j'arrive pas ; attention à ne pas casser les autres pages en fixant des hauteurs sur des éléments d'autres pages, et compter que si on met juste hauteur = 100% pour le bloc il ne prend pas en compte les margins/padding, donc du coup ça déborde quand même de la valeur des margins/paddings)

Le plus simple (enfin surtout le moins bricolé) c'est de fixer une hauteur max des éléments au dessus de laquelle on scroll, mais si cette hauteur max dépasse déjà de notre écran, ou au contraire est beaucoup plus petite que l'écran, ça fera moche.

Bref, les placement verticaux c'est ma petite hantise en CSS et il faut avouer que j'ai un peu de mal ><

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/assomaker/manifmaker/issues/199#issuecomment-259961547, or mute the thread https://github.com/notifications/unsubscribe-auth/ADuJ-rXdR_e_oCJslX22Q9IOlI7Zm6afks5q9HNlgaJpZM4JTJO0 .

remipichon commented 7 years ago

J'ai trouvé ça

http://stackoverflow.com/questions/15453410/independent-column-scroll-in-html-page

Ca agit sur le body mais on peut peut-être trouvé un endroit où mettre les bonnes classes pour obtenir le résultat voulu sans casser le reste.

Qu'en penses-tu ?

Le 12 nov. 2016 22:47, "Rémi Pichon" pichon.remi.pr@gmail.com a écrit :

Okay, je pensais en mode Android où on peut facilement mettre des listes. Il faut donc compter sur le scroll de la page pour gérer nos deux scrolls. Disons que le scroll de la page agit sur le calendrier comme actuellement sauf que le header des jours est fixé sur la page. Concernant les deux listes, elles sont fixées sur la page, comme le header des jours du calendrier pour suivre le scrolling. Leur affichage/masquage reste le même. Mais si on scroll l'une de ses listes, ça fera scroller le calendrier...

Hum, je bloque

Le 11 nov. 2016 14:53, "PtiLuky" notifications@github.com a écrit :

Yep je vois, après pour implémenter ça j'ai juste une petite indétermination sur les hauteurs du coup, Pour avoir à scroller il faut donner une hauteur max, et à ce niveau là je ne sais pas quoi choisir :

  • en fonction de l'écran ? (mais attention ça prend la taille de l'écran et pas de la fenêtre... ça peut toujours être utile mais peu précis)
  • en CSS on fixe une hauteur max arbitraire (qui peut être en fonction de la device-size)
  • trouver une solution propre en CSS pour remplir 100% de la hauteur et ensuite passer en scrolling (j'ai passé quelques temps à bidouiller pour essayer de faire ça, mais j'arrive pas ; attention à ne pas casser les autres pages en fixant des hauteurs sur des éléments d'autres pages, et compter que si on met juste hauteur = 100% pour le bloc il ne prend pas en compte les margins/padding, donc du coup ça déborde quand même de la valeur des margins/paddings)

Le plus simple (enfin surtout le moins bricolé) c'est de fixer une hauteur max des éléments au dessus de laquelle on scroll, mais si cette hauteur max dépasse déjà de notre écran, ou au contraire est beaucoup plus petite que l'écran, ça fera moche.

Bref, les placement verticaux c'est ma petite hantise en CSS et il faut avouer que j'ai un peu de mal ><

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/assomaker/manifmaker/issues/199#issuecomment-259961547, or mute the thread https://github.com/notifications/unsubscribe-auth/ADuJ-rXdR_e_oCJslX22Q9IOlI7Zm6afks5q9HNlgaJpZM4JTJO0 .

remipichon commented 7 years ago

Je viens de voir tes commits sur la popover, c'est excellent !

Il reste plus qu'à s'occuper de la position et du scrolling. A ce propos, est ce que tu sais fixer des elements en CSS à un endroit précis dans la page ? Précis en pixel par rapport au haut ? C'est pas un genre de float ca ? Je connais pas bien les bases du CSS tu sais ...

Pour notre page, il s'agit de fixer le header des jours du calendrier juste sous la top bar. On connait la hauteur de la top bar (on peut mettre ca dans une var en less), donc on peut positionner en absolu de la page le header. Et connaissant la hauteur du header de jour (pareil, une var), on peut calculer la position de la popover en absolu sur la page. Ainsi, quoiqu'il se passe en scrolling alentour, les deux reste "bloqué" en haut.

Est ce posible ca ? Est ce possible de faire ce comportement avec un jeu de classes CSS qu'on peut enlever et ajouter pour controler le comportement ? Typiquement pouvoir a nouveau "fixer" le header sur la page pour scroller quand meme ? Je pense à ca pour la page d'update des tasks. Nous pourrions avoir le header des jours du calendrier d'ajout de timeslot qui reste affiché au scrolling tant que les heures du calendriers sont visibles. Il se fait ensuite a nouveau prendre par le scrolling.

Est ce que tu comprends la moitié de ce que je dis ?

PtiLuky commented 7 years ago

Fixer, ça y a pas de problème (position : fixed, top : XXX px, right/left : XXX px).

" on peut calculer la position de la popover en absolu sur la page. " Là je suis pas d'accord ou alors je vois pas de la même façon. Parce que à moins qu'on veuille le mettre juste sous le header de jour, on va chercher à le centrer, donc ça va dépendre de la taille de l'écran nan ? Pareil pour son placement en abscisse : dans l'idée pour moi c'était à 50% de la page et qui remplaçait tout jusqu'à la droite, donc à bidouiller pour la fluidité.

Pour ce que tu décris après dans le task update, tu veux que les heures soient en scrolling et le header toujours là ? si c'est le cas, avec juste : 

<div> header</div>
<div style="max-height : XXX ; overflow-y : scroll"> heures </div>

ça devrait avoir un comportement similaire.

En fait le placement en lui-même ne me pose pas forcément problème, c'est la combinaison placement en dimensionnement qui est plus problématique : Si je fais un header de 100px, et que je veux que en dessous mon bloc remplisse le reste de la page, je ne peux pas faire height : 100% - 100px. Il faut soit qu'on choisisse une taille max (en px) pour l'affichage des calendriers, soit essayer avec des hauteurs de 80% pour que ça remplisse, mais pas tout.

PS : les height = 100% ça a souvent le bon gout de déconner puisqu'il considère 100% de son container et non de l'écran, du coup si on a pas fixé la hauteur d'un container à un moment, les height:100% sur ses élements-fils ne prendront jamais toute la taille de l'écran.

PtiLuky commented 7 years ago

Et là typiquement ce qui me bloque de pouvoir faire comme l'autre post sur stackoverflow c'est ce dernier problème de height:100% des containers.

Ici lui son body est bien en height : 98% (fixé), donc on peut mettre height:100% sur ses fils sans problème, Moi j'arrive pas à choisir de hauteur pour le container du code, qui est soit une taille en px pas adaptable à l'écran, soit une taille en % donc foireuse pour le header qui est %.

Bref, je vais essayer de bidouiller avec des padding pour avoir l'info en px et la height en %.

PtiLuky commented 7 years ago

Et en regardant ce qui est fait par exemple ici sur githut (le bandeau à droite qui scoll), c'est visiblement du .js qui prend le relais et qui change lui-même le css quand il arrive en haut de l'écran. Je suis pas fan de cette solution qui complique pas mal j'ai l'impression, à voir si on trouve pas autre chose

PtiLuky commented 7 years ago

En voie d'avoir une bonne solution :

Pour la navigateurs "récents", on a height : 100vh qui marche bien pour avoir 100% du viewport height !

PtiLuky commented 7 years ago

Voilà, pour le scroll ça semble bon, j'ai plus qu'à fixer les éléments voulus

PtiLuky commented 7 years ago

Bon, du coup le fait de pas avoir codé pendant quelques jours m'a aidé à voir autrement apparemment x)

Du coup ça semble bien fonctionner, Juste par rapport à ce que tu m'as dit, les header de listes ne sont pas fixés (car si je les mets en fixed, il perd la largeur de son parent et du coup les jours sont décalés c'est moche).

remipichon commented 7 years ago

Beau travail, en revanche peux tu "fermer" la popover sur le coté droit et gauche ?

J'ai testé le header des jours du calendrier et je dois avoir le meme problemes pour le header des listes, on perd la largeur du parent. Il n'y a pas moyen d'appliquer la meme largeur que la parent d'un autre moyen ?

PtiLuky commented 7 years ago

"Normalement" avec width : inherit, on récupère la taille des parents. Sur un exemple alacon, avec un petit bout de code fait pour tester, ça le fait, sur code appliqué ici, j'ai pas réussi et j'ai pas trouvé quel conflit de CSS il pouvait y avoir à l'origine de ça.

Comment ça fermer ? Si j'ai pas tout cassé, normalement ça se ferme au clic sur le reste du calendrier et sur sa petite croix.

remipichon commented 7 years ago

Est ce que tu peux me montrer le code alacon que tu as fait ?

Il y a pas mal de CSS que je connais pas sur le calendrier, j'ai tout repris de Assomaker. Il va falloir fouiller un peu

Le 18 nov. 2016 00:29, "PtiLuky" notifications@github.com a écrit :

"Normalement" avec width : inherit, on récupère la taille des parents. Sur un exemple alacon, avec un petit bout de code fait pour tester, ça le fait, sur code appliqué ici, j'ai pas réussi et j'ai pas trouvé quel conflit de CSS il pouvait y avoir à l'origine de ça.

Comment ça fermer ? Si j'ai pas tout cassé, normalement ça se ferme au clic sur le reste du calendrier et sur sa petite croix.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/assomaker/manifmaker/issues/199#issuecomment-261403141, or mute the thread https://github.com/notifications/unsubscribe-auth/ADuJ-h6vELuRXTaDc0yCT5uya65k5oQAks5q_ONHgaJpZM4JTJO0 .

PtiLuky commented 7 years ago

html : `

Sitename

blaat

`

CSS : 

#container {
    border: 1px solid red;
    width : 80%;
}

#test {
 border: 1px solid yellow;
 width: inherit;
 //width : 80% // Ici ne fonctionne pas, et c'est ce qui nous emmerde, 
 //Si on fait ça, fixed prend "80%" lui aussi... mais du total et pas du container :/
}

#fixed {
    height : 200px;
    position: fixed;
    top : 20px;
    width: inherit;
    border: 1px solid green;
}
remipichon commented 7 years ago

Et cet exemple fonctionne ?

As tu essayé de mettre des width inherit aux parents du header à fixed ?

Le 18 nov. 2016 20:29, "PtiLuky" notifications@github.com a écrit :

html :

Sitename

blaat

CSS : `#container { border: 1px solid red; width : 80%; }

test {

border: 1px solid yellow; width: inherit; //width : 80% // Ici ne fonctionne pas, et c'est ce qui nous emmerde, //Si on fait ça, fixed prend "80%" lui aussi... mais du total et pas du container :/ }

fixed {

height : 200px; position: fixed; top : 20px; width: inherit; border: 1px solid green; }`

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/assomaker/manifmaker/issues/199#issuecomment-261620157, or mute the thread https://github.com/notifications/unsubscribe-auth/ADuJ-jlswVwiDnMkmBAeVSN8g5gKhGpoks5q_fyagaJpZM4JTJO0 .

remipichon commented 7 years ago

Une idée saugrenue

Tu mets le header à fixed dans une div (um wrap encore). A la div "wrapping" tu mets width inherit mais pas de fixed. Au header tu mets fixed and width inherit. Est ce que ca marche ?

Le 18 nov. 2016 20:42, "Rémi Pichon" pichon.remi.pr@gmail.com a écrit :

Et cet exemple fonctionne ?

As tu essayé de mettre des width inherit aux parents du header à fixed ?

Le 18 nov. 2016 20:29, "PtiLuky" notifications@github.com a écrit :

html :

Sitename

blaat

CSS : `#container { border: 1px solid red; width : 80%; }

test {

border: 1px solid yellow; width: inherit; //width : 80% // Ici ne fonctionne pas, et c'est ce qui nous emmerde, //Si on fait ça, fixed prend "80%" lui aussi... mais du total et pas du container :/ }

fixed {

height : 200px; position: fixed; top : 20px; width: inherit; border: 1px solid green; }`

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/assomaker/manifmaker/issues/199#issuecomment-261620157, or mute the thread https://github.com/notifications/unsubscribe-auth/ADuJ-jlswVwiDnMkmBAeVSN8g5gKhGpoks5q_fyagaJpZM4JTJO0 .

PtiLuky commented 7 years ago

Nope, dans ce cas ça fait exactement comme s'il n'y avait pas de div.

En fait le problème c'est que quand il hérite de "100%" il garde l'info "100%" et non "100% du parent", ce qu'on aurait voulu. Du coup généralement quand c'est en %, même s'il hérite du bon pourcentage, c'est pas la même largeur effective parce qu'il va prendre xx% de l'écran, et le parent est rarement donné en fonction du parent.

Du coup pour le CSS je bloque un peu, je vais regarder si on peu corriger ça en js

PtiLuky commented 7 years ago

Bon, du coup j'arrive à avoir un truc crédible en repartant du 50% global + les margins pour recaler.