Agenda

[Xavier]

Agenda


L'agenda gèrera plusieurs sortes de données, désormais calquées sur les autres PIMs, dont voici le détail.

Tâches

• Validé :
  • La tâche est la donnée la plus simple, elle aura au minimum un titre, par exemple "Acheter des timbres" ou encore "Répondre au client".
  • Elle pourra avoir un statut, à priori parmi : "[ ] A faire", "[-] En cours", "[x] Fait", "[o] Annulé".
  • Elle pourra être classifiée via des dossiers.
  • Déplacer une tâche sur une journée du calendrier la transformera en évènement.
• A valider :
  • Il sera possible d'ajouter une description multiligne.
  • Il sera possible de saisir un état d'avancement.
  • Les tâches utiliseront les mêmes dossiers que les autres données de l'Agenda.
  • Une tâche pourrait avoir des sous-tâches.
  • Une tâche passant en statut "[x] Fait" sera automatiquement convertie en évènement (afin de libérer la liste des tâches et de marque la date de fin dans le calendrier).

Evènement

• Validé :
  • Un évènement sera une tâche positionnable dans le calendrier, donc datée, par exemple "Envoyer le document avant ce soir" ou "Réunion à 15h".
  • Il pourra avoir une heure de début et une heure de fin (ou une durée).
  • Il pourra avoir une Alerte (voir plus bas) s'il a une heure de début.
  • S'il n'a pas d'heures spécifiées, il sera possible de spécifier sa durée en demi-journées. (Cette fonction vise le besoin de Reporting hebdomaire.)
  • Un évènement pourra être récurrent, le paramétrage des répétitions devra être plus poussé qu'actuellement (définition de récurrences spéciales, dates de début et de fin).
• A valider :
  • Un évènement pourra couvrir plusieurs jours.
  • Le système des périodes (utilisé pour la gestion des congès) reposera sur des évènements.

Alerte

• Validé :
  • Une alerte est un objet secondaire, rattaché à un évènement uniquement.
  • Elle correspond à un rappel (reminder), donc un message et/ou un son qui se déclenche(nt) lors d'un évènement ou un peu avant, par exemple "Réunion dans 5 min".
  • Une alerte pourra être déclenchée lors de l'évènement ou avant selon un nombre de minutes / heures / jours librement définissables.
• A valider :
  • Il pourra être possible de créer plusieurs alertes pour un même évènement.
  • Le message d'alerte sera le titre de l'évènement par défaut mais sera surchargeable.

Afin de ne pas trop perturber les habitudes d'XT3 :

• La notion de Rappel continue de représenter le redéclenchement d'une alerte.
• La notion d'Alarme représente désormais un couple "Evènement + Alerte" mais garde le même fonctionnement d'un point de vue utilisateur.

J'espère avoir fait le tour de la concurrence, mais si quelque-chose manque, n'hésitez-pas, c'est le moment ou jamais.

[Frederik]

Pour les tâches, j'avoue utiliser le multiligne.

Pour les évènements, à étudier avec les autres la possibilité d'avoir les informations suivantes:
- lieu (pas forcément nécessaire, car peut être inclus dans la description, voir ci-dessous)
- description de l'évènement: assez utile pour ne pas trop charger le titre de l'évènement (c'est du multiligne)

Pour les alertes, pas de remarque particulière.

[Denis]

Idem que FBu.

"Déplacer une tâche sur une journée du calendrier la transformera en évènement." : donc si je la met dans le passé, ca la marque comme un événement "fait"??? Bof bof...

Etat d'avancement: genre pourcentage? Pas trop utile pour moi, mais je comprend le besoin, surtout si associé aux sous-taches (pas besoin non plus)

"Une tâche passant en statut "[x] Fait" sera automatiquement convertie en évènement (afin de libérer la liste des tâches et de marque la date de fin dans le calendrier).": si je la passe en fait ce jour, elle sera donc convertie en événement à ce jour. Pis-je ensuite la drag-dropper pour la mettre à la date à laquelle j'ai vraiment fait le truc? Genre pour faire mon reporting... après coup?


"Un évènement pourra couvrir plusieurs jours." Bof, si on peut facilement le recopier, ou lui donner une répétition jusqu'à telle date???


"Il pourra être possible de créer plusieurs alertes pour un même évènement." Une alerte répétitive suffit (comme les alarmes actuelles)

[Xavier]

FBu :
- OK pour avoir une descritpion multiligne pour les tâches et évènements.
- Lieu : sans doute un peu trop spécifique, donc à gérer via la description.

DMo :
- Passage de tâche en évènement : je pensais plutôt à un déplacement vers la date du jour ou une date du futur (quand une tâche "dormante" se réveille). Je ne vois pas de cas où une tâche serait à transformer en évènement passé, à part un oubli, mais alors le passage en "Fait" me semble correct, non ?
- Avancement : oui je pensais à un pourcentage, mais pas utile pour moi non plus, donc on élimine pour le moment.
- Idem pour les sous-tâches, ce sera implémentable dans le futur si besoin.
- Déplacement d'évènements : oui, l'idée du moment est que la liste des évènements (sous le calendrier) se limite à ceux du jour, et un drag-and-drop via une cellule du calendrier le déplacera à une autre date.

Merci pour vos remarques. Je ne suis pas encore arrivé dans les données, donc on peut encore affiner les specs si besoin.

[Denis]

- Passage de tâche en évènement : je pensais plutôt à un déplacement vers la date du jour ou une date du futur (quand une tâche "dormante" se réveille). Je ne vois pas de cas où une tâche serait à transformer en évènement passé, à part un oubli, mais alors le passage en "Fait" me semble correct, non ?

Oui, en déroulant un exemple, on voit que mon idée n'a pas de sens

[Xavier]

Données


La définition des champs nécessaires pour chaque type d'objet n'est pas très compliquée, d'autant que grâce aux Properties, il est possible d'en ajouter/enlever très rapidement sans se soucier des impacts, l'arbre de données étant automatiquement converti en fichier XML quelque soit son contenu.


Les sujets chauds du moment sont :

1) Hiérarchie des objets.

• On a des tâches et des évènements , qui appartiennent tous à un dossier. Les évènements appartiennent tous à une date.
• En supposant 10 évènements (tâches accomplies) par jour ouvré, cela produira 2000 évènement par an. Les données étant intégralement chargées en mémoire, on n'a pas de problème de lenteur de chargement comme à partir d'une DB, mais il y aura certainement des sous-dossiers qui agiront comme index pour réduire les temps de recherche. Pour le moment l'idée retenue est un regroupement des évènements par mois (12 dossiers de 200 objets) ou par semaine (52 dossiers de 50 objets), sans doute pas par année (2000 objets) ou par jour (300+ dossiers). Le groupage par semaine est très séduisant dans l'optique du service RefreshWeek travaillé ces derniers jours...
• Ce groupage des évènements sera effectué dans chaque dossier utilisateur. Il faudra sans doute séparer les tâches des évènements.

Edit : il faudra aussi pouvoir distinguer facilement les SuperEvents (voir sujet suivant).


2) Evènements récurrents

• Dans XT3, la répétition des alarmes était théorique puisque seule la prochaine instance de l'alarme existait : elle seule était stockée et pouvait être éditée. Cela ne posait pas de problème puisque les alarmes n'étaient pas visibles dans le calendrier. La non-existance des occurrences suivantes était donc acceptable.
• Dans XT4, les occurrences passées doivent être stockables, et les occurrences à venir doivent être visibles et individuellement modifiables.
• Une première idée a été d'imposer un nombre maximal d'occurrences (disons 100, ou le nombre nécessaire pour couvrir une année), de les créer à l'avance et d'en recréer des nouvelles au fur et à mesure. Mais la modification ou l'arrêt d'une "série" seraient compliquée à gérer, sans parler de la taille des exports.
• Le système qui est en train d'émerger est probablement utilisé par les autres logiciels, il consisterait à considérer un évènement récurrent comme un sorte de "super-évènement" fonctionnant selon ce principe :
  • A la création, seul le SuperEvent existerait, un seul objet serait créé.
  • A l'affichage dans le futur, le SuperEvent serait visible selon ses paramètres de répétition, comme une sorte d'héritage temporel ou d'ombre.
  • Lorsqu'une occurrence serait passée, même si non modifiée, elle serait créée comme objet séparé, le SuperEvent agissant ici comme une classe créant des instances.
  • La modification de la "série" modifierait le SuperEvent.
  • La modification d'une occurrence future déclencherait une instanciation de cette occurrence, un objet dédié serait créé pour cet évènement.
  • Il faudrait lier les instances futures au SuperEvent afin d'empêcher qu'elles ne se soient en conflit avec le SuperEvent. De même, il faudrait pouvoir supprimer toutes les instances futures si le SuperEvent est effacé ou modifié (dans une certaine mesure). Ce point est encore très flou.
• Le paramétrage des répétitions sera différent de celui d'XT3, qui propose 11 répétitions simples. En agglomérant tout ce que proposent les autres logiciels, XT4 utiliserait un paramétrage basé sur plusieurs "modèles", qui devrait couvrir la quasi-totalité des besoins :
  • Jour : chaque N jour. Exemple : "Arroser les plantes tous les 2 jours du 20/07 au 30/07".
  • Semaine : chaque XYZ de chaque N semaine. Exemples : "Arroser les plantes tous les mardis et jeudis en juillet", ou "Couper l'herbe tous les dimanches de chaque 2 semaines de mai septembre".
  • Mois : chaque Nème jour tous les N mois. Exemples : "Prendre le courrier le 1er de chaque mois" ou "Payer les charges le 10 tous les 3 mois".
  • Année : chaque DD/MM tous les N ans. Exemples : "Noël chaque 25/12" ou "Vérifier la clim le 01/05 tous les 3 ans".
  La notion de période serait assurée par des dates de début et de fin, mais à priori pas par un nombre d'occurrences.

Le sujet des alertes n'est pas encore vraiment étudié, mais à priori les évènements récurrents porteront toute la complexité donc cette partie devrait être assez simple.

[Xavier]

Tâches et évènements


A moins que quelqu'un s'en serve vraiment et ne puisse pas s'en passer, les fonctions suivantes ne seront pas implémentées dans XT4 :

• Association d'un programme ou d'une commande Windows à une alarme.
• Association d'un signal sonore à une alarme.

[Denis]

si possible, conserver les appli et fonctions windows liées aux alarme: permet de lancer un outil qui prend des ressources,à heure programmée, ou de fermer Windows par exemple a une certaine heure...

[Xavier]

si possible, conserver les appli et fonctions windows liées aux alarme: permet de lancer un outil qui prend des ressources,à heure programmée, ou de fermer Windows par exemple a une certaine heure...

Arf, en effet j'avais oublié la possibilité d'extinction programmée, c'est bien utile ça.

Bon, de toutes façons, il y a tellement de paramètres que ça ne tient déjà plus sur une seule page, donc allons-y.
C'est la version "XT4" qui va être intégrée, c'est à dire la possibilité d'associer une Commande de la bibliothèque ou un Raccourci défini dans le Gestionnaire de commandes.