-
Notifications
You must be signed in to change notification settings - Fork 1
design assignment #199
Comments
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 ? |
Les périodes d'affectations sont définies à l'avance, ça reste donc des On Aug 8, 2016 18:47, "PtiLuky" notifications@github.com wrote:
|
Les périodes d'affectation correspondront à "collage", "pré manif", "manif" Le 8 août 2016 19:09, "Rémi Pichon" pichon.remi.pr@gmail.com a écrit :
|
First design preview : https://app.moqups.com/Remip2/TCwTCzfxUD/view/page/a7c50f082 |
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 ? |
Pour les erreurs et notifications nous devrons mettre en place un système Pour la deuxième ligne de la TopBar, elle est "yield" par IronRouter dans Pour le moment le reset de TopNavBar est fait n'importe comment dans Si ça ne te bloque pas, concentre toi sur sur la page d'affectation sans te On Aug 9, 2016 6:18 PM, "PtiLuky" notifications@github.com wrote:
|
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. |
Je vois ce que tu as fais avec le "topNavBarComplement", c'est l'idée ça Pour le moment reste comme ça, nous ferons différemment si nécessaire en Le 10 août 2016 19:23, "PtiLuky" notifications@github.com a écrit :
|
Qu'est ce que tu entends par "design de la popup", je vois pas de quelle partie tu parles. ToDo :
|
Le design du calendrier concerne l'affichage des besoins orga sur les Le design de la popup concerne la popup de la liste des besoins orga Les deux ont besoin de passer par un Mockup car ce sont des éléments On Aug 13, 2016 12:59 PM, "PtiLuky" notifications@github.com wrote:
|
@PtiLuky gogogogo, derniere ligne droite pour valider toute la partie affectation ! |
timeslot on calendar
popover people needed
|
Est ce que tu as avancé cette tache ? As tu besoin d'aide ? As tu une idée de quand pourras tu la livrer ? |
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. |
Je crois que j'ai compris ton problème. En mode userToTask, un clic sur un le créneau laisse passer l'event qui En mode taskToUser, le clic n'atteint pas le calendrier puisque les Actuellement, en mode taskToUser un click sur le créneau est capturé pour Le 2 nov. 2016 14:21, "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 ? |
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 Remi Pichon Le 2 novembre 2016 à 23:22, PtiLuky notifications@github.com a écrit :
|
Est ce que tu t'en sors ? |
Ouais ça devrait aller, today j'ai pas trop de temps, je te dis ça dan les deux jours qui arrivent ! |
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 ? |
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 Remi Pichon Le 6 novembre 2016 à 21:41, PtiLuky notifications@github.com a écrit :
|
Commit e2ec804 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 ? |
Pas mal la popup. En revanche as tu terminé de travailler sur son A voir effectivement, nous demanderons aux testeurs ce qu'ils en pensent. Remi Pichon Le 6 novembre 2016 à 21:52, 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). Je teste tout ça, dis-moi ce que t'en penses aussi ;) |
Je vois les listes, en revanche il faut bien différencier chaque besoin Pour le placement, ce qui est sur c'est qu'il faut la placer sur l'écran, Je suis aussi d'avis de dire que ce sera plus homogene si la popover occupe Pour l'ombre je suis aussi contre, pas besoin d'en faire plus je trouve Remi Pichon Le 6 novembre 2016 à 22:13, PtiLuky notifications@github.com a écrit :
|
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 ? |
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... |
Okay, on peut réflechir differement et si dire que le calendrier dans son Remi Pichon Le 6 novembre 2016 à 22:57, PtiLuky notifications@github.com a écrit :
|
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 ? |
Ho shit, Trump president |
Ouais, cette solution me parle bien ! |
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 De même, seules les listes Users et Tasks sont scrollables (ainsi, le Il s'agit d'avoir 3 zone de scrolling
Si la liste des Users (celle du dessus) est longue, la liste des Tasks sera A nous d'aider l'utilisateur est affichant et masquant les listes en Est ce clair ? Le 10 nov. 2016 18:35, "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,
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 >< |
Okay, je pensais en mode Android où on peut facilement mettre des listes. Hum, je bloque Le 11 nov. 2016 14:53, "PtiLuky" notifications@github.com a écrit :
|
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 Qu'en penses-tu ? Le 12 nov. 2016 22:47, "Rémi Pichon" pichon.remi.pr@gmail.com a écrit :
|
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 ? |
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. " Pour ce que tu décris après dans le task update,
ç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 : 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. |
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, Bref, je vais essayer de bidouiller avec des padding pour avoir l'info en px et la height en %. |
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. |
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 ! |
Voilà, pour le scroll ça semble bon, j'ai plus qu'à fixer les éléments voulus |
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, |
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 ? |
"Normalement" avec width : inherit, on récupère la taille des parents. Comment ça fermer ? |
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 Le 18 nov. 2016 00:29, "PtiLuky" notifications@github.com a écrit :
|
html : Sitename
CSS :
|
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 :
|
Une idée saugrenue Tu mets le header à fixed dans une div (um wrap encore). A la div Le 18 nov. 2016 20:42, "Rémi Pichon" pichon.remi.pr@gmail.com a écrit :
|
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 |
Bon, du coup j'arrive à avoir un truc crédible en repartant du 50% global + les margins pour recaler. |
Du coup j'ai commit 21bdbb0 ce que ça donne avec les titres fixés, mais je sais pas si c'est beau x) |
J'ai pas accès à un ordi avant mardi, je regarde ça rapidement et je te dis A part les headers, la popover est complètement OK ? Le 18 nov. 2016 22:29, "PtiLuky" notifications@github.com a écrit :
|
Je pense oui, Juste : "Beau travail, en revanche peux tu "fermer" la popover sur le coté droit et gauche ?" |
Ca me paraît bien comme ça, nous adapterons en fonction du feedback des Si tu considères que cette issue est terminée (au moins pour le moment), tu Le 19 nov. 2016 10:46, "PtiLuky" notifications@github.com a écrit :
|
The text was updated successfully, but these errors were encountered: