epnadmin-fr
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Epnadmin-fr] Travail du 26 / 29 / 30 Mars


From: Thomas Sechet
Subject: Re: [Epnadmin-fr] Travail du 26 / 29 / 30 Mars
Date: Tue, 30 Mar 2004 22:58:11 +0200

Le Wed, 31 Mar 2004 18:40:59 +0200
Marc Carlucci <address@hidden> écrivait peut-être :

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> > Attention, un CVS commit hier (lundi 29) soir avec des modifs un peu
> > partout.
> CVS update ok, pas de conflit majeur.
> 
> > C'est la traduction que j'avais trouvé la plus proche "d'animateur", mais
> > ce n'est pas moi l'expert. Si changement, il va y en avoir partout
> > (structure sql, noms et contenus de scripts, initiation.sql).
> Oui, les changements devront etre effectues partout...

J'ai une nette préférence pour "teacher" car, à ce que je sais, c'est le terme 
anglophone consacré à ce que nous appelons les "animateurs", tout du moins dans 
les musées scientifiques.
  
> 
> 
> 
> > > Calendrier, Planning :
> > > o Que pensez vous d'utiliser un bouton de type select pour definir si le
> > > creneau horaire est "Collectifs", "Individuels" ou "Inactif" pour la
> >
> > Pas de soucis, si ça rend plus facile les manipulations.
> > En revanche, il y a un soucis important : l'accessibilité. Un tableau comme
> > ça, c'est inaccessible pour un aveugle. Est-ce qu'un formulaire du genre de
> > celui de webcalendar (avec des créneaux horaires et des possibilités de
> > répétitions) pourrait rendre cela accessible ? Si c'est trop compliqué,
> > tant pis !
> Ok, je travail sur cet ecran en mettant en place des boutons de type select 
> et 
> j'essaye de valider un planning en utilisant uniquement le clavier.

C'est important pour la cité des sciences et de l'industrie qui accueuille des 
publics handicapés.
> 
> 
> > Je ne vois pas la différence entre disponible et occupé. A moins que cela
> > ne concerne les bénévoles qui peuvent être disponibles mais pas en poste.
> > Dans ce cas, je propose de passer "occupé" en "en poste".
> Ok j'ai mal relu mon message, desole pour la confusion, en fait la liste 
> comportera les elements  [accueil, initiation, maintenance, conception, 
> reunion, CP , CM] permettant de definir l'occupation de l'animateur.

il faut prévoir un staut différent d'animateur qui n'interferre pas avec la 
gestion du planning des animateurs en poste mais qui permette d'accueillir des 
animateurs invités (avec des droits à définir ?) --> inscription dans les 
calendriers d'activités. Droits à définir sur les systémes de partage et de 
ressources sur les serveurs. (un module de solution groupware est à l'étude). 
Je suis pour l'instant assez tenté par "phpprojekt" <http://www.phprojekt.com/> 
qui est très simple et fonctonnel. Les fonctions sont elles suffisantes ?
> 
> > Un autre soucis, c'est de savoir où est l'animateur. Lorsqu'il est en
> > poste, il peut être dans un espace ou dans un autre ou encore dans un
> > ville. Par exemple, à Dijon, il y a 4 espaces, mais 2 animateurs qui
> > tournent. Donc les animateurs sont disponibles dans un espace. Ou alors ce
> > problème est géré dans le temps de déplacement entre les sessions...
> Concernant les distances entre les salles, je vais creer une nouvelle table 
> room2room avec les champs r2r_id_from, r2r_id_to, r2r_distance et r2r_time.
> Cette table stockera donc les distances entre chaque salle. Afin de 
> simplifier 
> la saisie de ces informations il faudra au prealable saisir une structure.
> Le formulaire de saisie sera un tableau avec les salles en ordonnes et 
> abscisses. [a tester en pratique]

La Cyber-base de la cité des sciences ne sera pas un bon environnement de test. 
Toutefois, je considère cette préoccupation comme un module essentiel pour la 
gestion d'un réseau d'espaces publics dans une ville. C'est donc un 
développement important.

> 
> 
> > Remarque: il  faut mettre tout ça en anglais dans les tables.
> Ok, que penses tu de remplacer les textes par des identifiants et d'avoir un 
> tableau texte dans le fichier php.
> 
>  AVANT :
> - ---------
> SQL : lm_presence enum('disponible','affecté','absent')
> PHP : echo $row['lm_presence']
> 
>  APRES :
> - ---------
> SQL: lm_presence char(1)
> PHP: 
> $text_presence = array('D' => _('Available'), 'A'=> _('Placed'), 'N'=> _('Not 
> Available'))
> echo $text_presence[ $row['lm_presence'] ]
> 
> 
> > > o Ajouter un bouton sauver ce planning comme modele [template]
> >
> > Donc il n'y aurait plus de planning spécial modèle ? C'est une idée. Mais
> > il faut pouvoir vérifier quand même en quoi consiste le modèle quand on
> > l'applique.
> Je crois que je n'ai pas saisie la logique, quel etait le but des modeles et 
> comment sont ils geres ?
> 
> De mon point de vue, on definit les disponibilites pour une salle ou un 
> animateur pour une semaine donnee [normalement la semaine courante].
> Ensuite on recommence pour la semaine suivante et ainsi de suite...
> Afin d'eviter de recommencer cette operation, je pensais sauvegarder une 
> semaine, comme une semaine 'Modele'  pour 
> 1. toutes les salles ou tous les animateurs
> 2. cette salle ou cet animateur
> 
> 
> Facilitators [animateurs]
> Quel est le but de l'option "occupations" dans le menu animateur ?
> 
> Les 2 autres options etant :
> - - liste, permettant de rechercher, editer un animateur
> - - disponibilite, permettant de planifier l'emploi du temps de 
> l'administrateur
> 
> 
> 
> > Dis-moi si je continue à travailler sur les scripts ou bien si j'attends la
> > fin de ton (Marc) travail actuel.
> Tu peux continuer, mon travail ne devrait pas rentrer en conflit avec le tien.
> 
> > Par ailleurs, le travail d'intégration de la charte graphique est à faire.
> > Qui veut s'en charger ?
> Pour le moment je ne peux m'en charger.
> 
> Pour l'integration, est ce qu'emmanuel P. pourrait fournir les matieres 
> premieres :
> - - codes couleurs utilises sur chaque page
> - - nouveau logo [cad ancien + l'arrondi a droite]
> - - l'image a cote de deconnexion
> - - l'image a cote du titre de la rubrique selectionne
> - - l'image de fond de la  barre de menu
> 
> 
> > La réflexion sur les menus est à reprendre pour les 3 accès : usagers,
> > animateurs, administrateurs.
> C'est a dire reprendre ? continuer le fil de discussion sur le site, definir 
> une fois pour toute quel menu avec quels options ? 
> 
> Marc C
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
> 
> iD8DBQFAavSf+LFx62CIkzARAjoLAJ9tTOzCEbIfLm44lWFmqJ6JFY0glQCeOf1o
> Mn1nGVVbD3pPvlAfVJmFwIk=
> =zvk0
> -----END PGP SIGNATURE-----
> 
> 
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]