Projet : Webmail Mobile Polytech'Nice-Sophia
←
→
Transcription du contenu de la page
Si votre navigateur ne rend pas la page correctement, lisez s'il vous plaît le contenu de la page ci-dessous
Projet :
Webmail Mobile
Polytech’Nice-Sophia
Equipe du projet : Encadrants :
BOURDIN Alexandre
CHANDELIER Cyril DERY Anne-Marie
SANDER Peter
FIFRE Sébastien
GRIMAUD Quentin
04/02/2001
1
Sommaire
I. Cahier des charges ………………………………………………………………………….3
1. Présentation du projet ………………………………………………………………………3
2. Identification du besoin …………………………………………………………………….4
3. Besoins fonctionnels ………………………………………………………………………….6
4. Besoins non-fonctionnels ………………………………………………………………….6
II. Utilisation …………………………………………………………………………………………….8
1. Notice d’utilisation …………………………………………………………………………….8
2. Scénarios d’utilisation ……………………………………………………………………….9
III. Travail sur l’ergonomie ………………………………………………………………….21
1. Analyse comparative des webmails mobiles existants ………………….21
2. Choix de développement de l’interface ………………………………………….23
IV. Problèmes connus …………………………………………………………………………..25
V. Extensions du projet ………………………………………………………………………26
1. Extensions nécessaires ……………………………………………………………………26
2. Extensions possibles ……………………………………………………………………….26
Annexes …………………………………………………………………………………………….27
2
I. Cahier des charges
1. Présentation du projet
Le projet de mise en place d’une version mobile du webmail consiste à la réalisation
d’une nouvelle interface de messagerie adaptée aux appareils portables de type smartphone.
a. Contexte
Le service webmail, interne à l’école Polytech’Nice-Sophia, est un outil indispensable
pour les étudiants, enseignants et personnel administratif en tant que plate-forme de
communication essentielle.
Le webmail mobile est un projet réalisé au sein de l’école, prévu pour s’ajouter comme
alternative au webmail adaptée aux appareils mobiles et permettant d’accéder et de consulter
les comptes déjà existants de la même manière qu’au moyen du webmail actuel.
b. Objectifs
Cette interface, ayant pour but de rendre le webmail beaucoup plus accessible sur le
plan ergonomique et facilité d’utilisation, devra être utilisable sur tout smartphone équipé d’un
navigateur internet, tactile ou non.
Elle devra aussi implémenter les fonctionnalités actuellement manquantes et adaptées à
une utilisation mobile.
c. Description de l’existant
Actuellement, le webmail de Polytech’Nice-Sophia, accessible à l’adresse
https://webmail.polytech.unice.fr, n’est développé que pour navigateur standard non-mobile
(PC) et n’est pourvu d’aucune adaptabilité à une plate-forme mobile.
d. Motivations du projet
Le choix du développement d'un webmail mobile est également motivé par le fait que les
utilisateurs non avertis n'ont pas le réflexe ou éprouvent souvent des difficultés à configurer
l'application email native de leur téléphone avec les paramètres du serveur mail de l'école.
En effet, cela demande de connaître les différentes informations à fournir pour pouvoir
recevoir et envoyer des emails via le serveur de Polytech : l'adresse du serveur unice.fr, le type
d'authentification, le login, le mot de passe à utiliser qui est celui de l'ENT et non leur mot de
passe classique à Polytech, etc. De plus, l'envoi d'emails via le protocole SMTP n'est autorisé
que depuis l'enceinte de l'école, l'étudiant doit donc de lui-même passer par un second serveur
email pour effectuer ses envois. Ces manipulations ne sont à la portée que des étudiants
informés, les autres basculent vers une autre solution telle que l'utilisation du webmail ou de
GMail vers lequel ils redirigent les mails de leur boîte Polytech’.
3
Version actuelle du webmail vue dans Google Chrome
2. Identification du besoin
Le webmail est couramment utilisé par les étudiants, professeurs et personnel
administratif de Polytech’Nice-Sophia.
Nous avons mené une étude au moyen d’un sondage auprès de toute la population
concernée, qui a révélé que dans la majorité des cas les utilisateurs se plaignent de l’ergonomie
du webmail existant, et ce principalement lorsqu’il est consulté sur un appareil mobile. Une
partie des utilisateurs ont remplacé la consultation du webmail par une redirection de
messagerie ou l’utilisation d’une application de mail, mais un pourcentage non négligeable
(54,5%) utilise encore le webmail lui-même via leur navigateur mobile malgré l’inconfort qu’il
présente.
4
286 étudiants, enseignants et personnel administratif ont répondu à notre étude.
Voici quelques diagrammes clés des résultats obtenus :
5
Notre étude a révélé que pour la très grande majorité, les attentes concernant une version
mobile du webmail sont les suivantes :
○ adaptabilité à la résolution des écrans de smartphones
○ ergonomie adaptée au tactile
○ clarté de l’affichage, accessibilité rapide aux nouveaux mails
○ simplicité d’utilisation
○ légèreté de l’interface (tant sur le plan visuel qu’en terme de bande passante)
○ retrouver les fonctionnalités des applications mobiles
Une partie des réponses montrent aussi une attente d’une application exécutable sur
smartphone substituant la nécessité d’ouvrir un navigateur. Cependant, à cause de la
multiplicité des plates-formes mobiles (les principales étant l’iOS, Android, Windows Phone,
Symbian et RIM), nous nous restreindrons à une version consultable via navigateur par soucis
d’efficacité en termes de temps de développement et d’accessibilité non exclusive.
3. Besoins fonctionnels
Fonction principale :
● envoi et réception de mails sur appareil mobile
Fonctions secondaires :
● possibilité de mémorisation des identifiants de connexion et connexion
automatique
● réception et affichage de la liste des mails
● possibilité d’afficher les mails suivants dans la liste
● possibilité d’afficher mails lus et non lus séparément
● marquage d’un, plusieurs ou tous les mails comme lus
● rédaction de nouveaux mails
● sélection d’adresses parmi le carnet à l’envoi d’un mail
● envoi de pièces jointes
● ajout d’adresses en CC, BCC
● suppression des mails
● organisation des mails par dossiers
● gestion de favoris (distinction dans les mails reçus)
● gestion du carnet d’adresses
4. Besoins non fonctionnels
● accessibilité par navigateur internet (mobile)
● ergonomie exploitant les possibilités tactiles
● interface légère au chargement
6
● développement de la partie accès serveur en PHP
● développement de l’interface client en HTML, CSS, Javascript (jQuery mobile)
● limitation la longueur de la liste des mails chargés et affichables, allongeable sur
action de l’utilisateur
7II. Utilisation
1. Notice d’utilisation
Le webmail mobile est en ligne à l’adresse : https://m.webmail.polytech.unice.fr/
Pré-requis
● Serveur PHP5
● Installer l’extension php5-imap avec support SSL
● Activer le module mcrypt de PHP
Installation
1. Positionner l’arborescence de fichier de l’application sur le serveur
2. Remplir les données dans le fichier config/global.php
3. Configurer le domaine afin qu’il pointe vers le dossier web/ de l’application
Désinstallation
1. Supprimer le virtual host créé pour le webmail mobile
2. Supprimer l’application du serveur
Fonctionnalités du webmail mobile
● option de connexion automatique (se souvenir des identifiants pour la prochaine
ouverture du navigateur)
● menu principal avec boite de réception, messages non lus, envoyés, brouillons, corbeille
et dossiers, avec pour chacun une indication du nombre de messages non-lus sur le
coté
● recherche d’emails par dossier
● depuis une liste d’emails, distinction des emails non-lus, possibilité pour un email de le
déplacer dans un dossier, le supprimer, le marquer comme lu ou non-lu (via un swipe ou
un clic sur l’engrenage)
● pagination via un bouton “afficher les messages suivants”
● rafraîchissement automatique des emails après 1 minute d’inactivité
● rédiger et envoyer un email, avec champs cc et bcc, et possibilité de le sauvegarder
dans les brouillons
● brouillons : éditer un message enregistré dans les brouillons, le sauvegarder et l’envoyer
● détection et création des liens adéquats sur les adresses email et les adresses web que
comporte l’email
● affichage “correct” du contenu de l’email en tenant compte de son encodage
● téléchargement des pièces jointes
● bandeau rétractable qui affiche les détails du message (de, à, cc, date)
● actions répondre, répondre à tous et transférer
82. Scénarios d’utilisation
Diagramme de haut niveau
Utiliser le webmail
Acteur primaire : utilisateur
Acteur secondaire : serveur mail
Précondition : l’utilisateur est sur la page de connexion, non connecté
Scénario primaire :
1. L’utilisateur se connecte
2. L’utilisateur gère sa messagerie
3. L’utilisateur se déconnecte
Postcondition : l’utilisateur est déconnecté
Variantes :
2a. L’utilisateur n’a pas terminé ses opérations. Aller en 2.
9Se connecter
Acteur primaire : utilisateur
Acteur secondaire : serveur mail
Précondition : l’utilisateur n’est pas connecté
Scénario primaire :
1. L’utilisateur entre ses identifiants
2. L’utilisateur clique sur “Connexion”
3. Le serveur crée la session de l’utilisateur
4. L’utilisateur est redirigé vers sa page de messagerie
Postcondition : l’utilisateur est connecté
Variantes :
1a. Les identifiants de l’utilisateur sont mémorisés, il est connecté automatiquement
: succès du scénario
2a. L’utilisateur coche “Connexion automatique”. Aller en 2.
3a. Les informations sont fausses ou incomplètes, une erreur est retournée. Aller en
1
10Se déconnecter
Acteur primaire : utilisateur
Acteur secondaire : serveur mail
Précondition : l’utilisateur est connecté
Scénario primaire :
1. L’utilisateur clique sur le bouton “Déconnexion”
2. Le serveur ouvre une fenêtre de confirmation
3. L’utilisateur confirme la déconnexion
4. Le serveur clos la session de l’utilisateur
5. L’utilisateur est redirigé vers la page de connexion
Postcondition : l’utilisateur est déconnecté
Variantes :
3a. L’utilisateur annule la déconnexion : fin du scénario
4a. La session a déjà expiré, aller en 5
11Gérer sa messagerie
Acteur primaire : utilisateur
Acteur secondaire : serveur mail
Précondition : l’utilisateur est sur sa page de messagerie
Scénario primaire :
1. L’utilisateur choisit de gérer ses mails
2. Le serveur exécute l’opération
Postcondition : l’utilisateur a réalisé toutes ses actions
Gérer les mails
Acteur primaire : utilisateur
Acteur secondaire : serveur mail
Précondition : l’utilisateur est sur sa page de mails
Scénario primaire :
1. L’utilisateur choisit une opération à réaliser
2. Le serveur exécute l’opération
3. Le serveur redirige l’utilisateur vers la page correspondante
Postcondition : l’utilisateur a réalisé toutes ses actions
12Envoyer un mail
Acteur primaire : utilisateur
Acteur secondaire : serveur mail
Précondition : l’utilisateur est sur sa page de messagerie
Scénario primaire :
1. L’utilisateur choisit un mode d’envoi (nouveau message, répondre, répondre à tous,
transférer)
2. L’utilisateur remplit le formulaire d’envoi. Aller en 2.
3. L’utilisateur clique sur le bouton d’envoi
4. Le serveur effectue la requête d’envoi
5. Le serveur confirme l’envoi
6. Le serveur redirige l’utilisateur sur sa page de messagerie
Postcondition : l’utilisateur est sur sa page de messagerie
Variantes :
2a. L’utilisateur choisit d’attacher une pièce jointe. Aller en 2.
2b. L’utilisateur a terminé de remplir le formulaire et d’attaquer les pièces jointes.
Aller en 3.
5a. La requête échoue. Le serveur retourne une erreur. Aller en 6
13Afficher la liste des mails
Acteur primaire : utilisateur
Acteur secondaire : serveur mail
Précondition : l’utilisateur est sur sa page de messagerie
Scénario primaire :
1. L’utilisateur choisit une liste de mails à afficher
2. Le serveur interroge le serveur de mails
3. Le serveur affiche la liste des mails correspondant à la liste choisie
Postcondition : l’utilisateur est sur une page de liste de mails
Variantes :
3a. Le serveur de mails est inaccessible ou ne répond pas. Le serveur retourne une
erreur et affiche une liste vide.
14Supprimer un mail
Acteur primaire : utilisateur
Acteur secondaire : serveur mail
Précondition : l’utilisateur est sur une page de liste de mails ou sur la page de consultation
d’un mail
Scénario primaire :
1. L’utilisateur choisit un mail à supprimer
2. L’utilisateur clique sur l’icône de suppression
3. Le serveur demande une confirmation de la suppression de ce mail
4. Le serveur effectue la requête de suppression du mail
5. Le serveur actualise la liste de mails
Postcondition : l’utilisateur est sur une page de liste de mails
Variantes :
1a. L’utilisateur est sur la page de consultation. Aller en 2.
3a. L’utilisateur annule sa demande de suppression.
3a. La requête échoue. Le serveur retourne une erreur. Aller en 3.
15Marquer les mails comme lus
Acteur primaire : utilisateur
Acteur secondaire : serveur mail
Précondition : l’utilisateur est sur une page de liste de mails
Scénario primaire :
1. L’utilisateur choisit un mail non-lu à marquer comme lu
2. L’utilisateur clique sur l’icône “Lu”
3. Le serveur effectue la requête de marquage du mail comme lu
4. Le serveur actualise la liste de mails
Postcondition : l’utilisateur est sur une page de liste de mails
Variantes :
3a. La requête échoue. Le serveur retourne une erreur. Aller en 1
16Marquer les mails comme non-lus
Acteur primaire : utilisateur
Acteur secondaire : serveur mail
Précondition : l’utilisateur est sur une page de liste de mails ou sur la page de consultation
d’un mail
Scénario primaire :
1. L’utilisateur choisit un mail lu à marquer comme non-lu
2. L’utilisateur clique sur l’icône “Non-Lu”
3. Le serveur effectue la requête de marquage du mail comme non-lu
4. Le serveur actualise la liste de mails
Postcondition : l’utilisateur est sur une page de liste de mails
Variantes :
1a. L’utilisateur est sur la page de consultation. Aller en 2.
3a. L’utilisateur annule sa demande de suppression.
3a. La requête échoue. Le serveur retourne une erreur. Aller en 3.
17Déplacer un mail dans un dossier
Acteur primaire : utilisateur
Acteur secondaire : serveur mail
Précondition : l’utilisateur est sur une page de liste de mails ou sur la page de consultation
d’un mail
Scénario primaire :
1. L’utilisateur choisit un mail à déplacer
2. L’utilisateur clique sur l’icône “dossier”
3. Le serveur ouvre une fenêtre recensant les dossiers possibles de déplacement
4. L’utilisateur clique sur le dossier de son choix
5. Le serveur effectue la requête de déplacement
6. Le serveur ferme la fenêtre d’affichage des dossiers possibles
Postcondition : L’utilisateur est sur une page de liste de mails
Variantes :
1a. L’utilisateur est sur la page de consultation. Aller en 2.
5a. La requête échoue. Le serveur retourne une erreur. Aller en 3.
18III. Travail sur l’ergonomie
Nous avons tout d’abord commencé par étudier les webmails mobiles existants
(Hotmail Mobile, Yahoo! Mail Mobile, GMail Mobile) ainsi que différentes applications
présentes nativement sur les smartphones (application mail sur Iphone et sur Androïd).
D’après le tableau suivant et d’un point de vue ergonomique, seul le webmail Hotmail Mobile
a été exclu de nos choix de références car présentant trop de défauts.
Aussi, la conception de notre webmail s’est basée sur les choix de reprendre et
adapter les différents points forts retenus dans chacun des webmails et applications étudiés.
Par exemple, nous avons choisi de s’inspirer de Yahoo! pour l’option “Rechercher” présente
au-dessus de la liste des mails, ainsi que la fonction “swipe” (action de glisser le doigt vers
la gauche ou la droite sur un mail pour faire apparaître une liste d’options). A l’instar de
GMail, nous avons disposé les différentes fonctionnalités de sorte à ce qu’elles soient
facilement accessibles.
191. Analyse comparative des webmails mobiles existants
Hotmail Mobile
Points + :
● Rapidité de chargement des messages
Points - :
● Un bandeau de pub
● Sa lenteur (redirection d’adresse permanente,
demande d’authentification à répétition)
● Des commandes placées en bas de page
Yahoo! Mail Mobile
Points +:
● Son interface
● Sa rapidité (n’affiche pas systématiquement les
mails au format html)
● L’option rechercher présente au-dessus de la
boîte de réception
● Possibilités de masquer les sous-dossiers
Points - :
● Présence d’un bandeau de publicité
● Manque certaines options présentes dans leur
webmail d’origine (pas de champ Cci, ...)
● Un nombre de messages par page très réduit
20GMail Mobile
Points +:
● Interface mobile proposant le plus d’options
● Absence de publicité
● Possibilités de faire une sélection de plusieurs
mails dès la boîte de réception.
● Propose à peu près toutes les options présentes
sur le webmail normal.
Points -:
● Une lenteur de chargement
● Option rechercher plus difficile d’accès
Application Mail native iPhone
Points + :
● Une ergonomie étudiée et efficace
● Des options facilement utilisables
● L’option rechercher présente au-dessus de la
boîte de réception
Points - :
● Options difficiles à trouver, parfois manquantes
(sélection de plusieurs mails)
212. Choix de développement de l’interface
Nous allons à présent détailler nos différents choix concernant l’optimisation de
l’interface pour une utilisation adaptée aux résolutions d’écrans de smartphones.
Interfaces proportionnelles à la taille de l’écran
Les petits écrans tactiles ne permettent pas toujours à l’utilisateur de savoir
précisément ce sur quoi il clique, c’est pourquoi nous avons choisi d’implémenter des
boutons et des barres plutôt que des liens, dimensionnés de taille idéale (par exemple pour
ouvrir un message ou encore pour ouvrir un dossier).
Placement des éléments
Pour faciliter l’accès à nos différentes options, nous les
avons placées dans deux barres situées en haut et en bas de
la page, distinguant ainsi le contenu des options
Boutons images
Nous avons préféré l’utilisation des icônes au texte
pour la conception des boutons de l’interface, par soucis de
gain de place et de visibilité.
Grands champs de texte
Les champs de texte que nous avons mis en place sont d’une
taille suffisante pour être facilement atteints.
Contenus rétractables
Afin de factoriser au mieux les informations présentes sur les
pages, nous avons mis en place des contenus rétractables, comme la
liste des dossiers sur le menu, les champs facultatifs du formulaire
d’envoi de mail ou encore les détails d’un mail reçu.
22Utilisation du tactile
Nous avons utilisé les différentes possibilités du tactile, comme
le défilement vertical dans une liste de messages, ou encore le “swipe”
permettant l’affichage d’options pour chacun des messages.
23IV. Problèmes connus
Encodage
Nous rencontrons un bug aléatoire des encodages de caractères dans certains emails
(environ 1/50), bien que tous les encodages soient traités de la même façon. Deux emails
encodés selon le même “charset” ne réagissent pas forcement de la même façon. Nous
n’avons pas trouvé à ce jour de solution à ce problème.
En-tête et barre d’outils non fixables sur iPhone
En raison d’une implémentation spéciale du navigateur Safari iPhone, la propriété
CSS position:fixed; ne réagit pas correctement et empêche les barres situées en en-tête et
en pied de page d’être fixées. De plus, l’immaturité du framework jQuery-mobile ne permet
pas de résoudre ce problème. Nous avons pour cette raison choisi de ne pas fixer ces barres
quelque soit le navigateur utilisé.
24VI. Extensions du projet
1. Extensions nécessaires
Audit complet de sécurité
Avant que le webmail puisse être mis en ligne et utilisé, il est nécessaire qu’un audit
de sécurité soit réalisé afin de vérifier qu’aucune faille n’est présente, qui mettrait en péril
les données contenues par les boîtes mails des utilisateurs, et bien entendu les corriger le
cas échéant.
Meilleure prise en charge du HTML
Actuellement, le style contenu dans les mails HTML n’est pas filtré et peut altérer
l’affichage des mails en contenant. Ainsi, la structure de la page elle-même peut-être
détériorée, et les mails trop larges (débordant de l’écran à droite) sont coupés, et le
défilement horizontal étant désactivé, il est impossible d’afficher le mail dans son intégralité.
2. Extensions possibles
Gestion du carnet d’adresses
Une première extension intégrable au webmail serait la gestion du carnet d’adresses,
à savoir l’ajout, la suppression et l’édition de contacts directement sur l’application
smartphone sans avoir à passer par la version existante du webmail.
De plus, il serait intéressant d’ajouter un système d'auto-complétion des
destinataires lors de la rédaction d’un mail, à partir du carnet d’adresses et éventuellement
des derniers destinataires de mails envoyés.
Attachement de pièces jointes
Il n’est pour l’instant pas possible d’attacher des pièces jointes aux mails envoyés.
Cela ne sera jamais implémentable sur iPhone à moins d’une modification radicale de l’iOS,
mais pourrait être une fonctionnalité intéressante pour les utilisateurs d’autres OS mobiles.
Actions groupées sur les listes de messages
Les actions groupées comme “déplacer tous vers un dossier” ou “supprimer tous” ne
sont actuellement pas implémentées.
Gestion des favoris dans les mails
A l’instar de GMail, nous avons pensé à intégrer au webmail un système de favoris,
permettant la mise en valeur de mails jugés importants par l’utilisateur.
25Annexes
Carnet de bord
● Jeudi 6/01/2011
○ Recherches sur le webmail existant et SquirrelMail
○ Début de rédaction d’une étude comparative des applications et webmails
mobiles, en mettant en avant les points positifs et négatifs de chacun
● Vendredi 7/01/2011
○ Poursuite de la rédaction de l’étude comparative
○ Mise en place d’un sondage pour réunir les avis des utilisateurs du webmail et
leurs habitudes concernant la lecture des mails sur smartphone
○ Mise en place de graphes pour traiter les résultats
○ Première écriture du cahier des charges avec les réponses obtenues (plus de
160 dans l’après-midi, inespéré !)
● Lundi 10/01/2011
○ 280 réponses au questionnaire obtenues
○ Recherches sur le framework javascript jQuery mobile
○ Ecriture d’un script PHP pour récupérer les mails sur un serveur
● Mardi 11/01/2011
○ Analyse UML
○ Mise en place d’une architecture MVC avec PHP
○ Premier jet sur papier des futures interfaces
○ développement d’un module gérant l’affichage d’un contenu par défaut dans
un champ de texte (placeholder, par exemple écrire “À” dans le champ
destinataire au lieu d’en dehors, pour économiser de la place dans le
formulaire)
● Mercredi 12/01/2011
○ Début de l’implémentation des premières interfaces (apprentissage à
l’utilisation de jQueryMobile)
○ Implémentation de code pour récupérer les emails en PHP
○ mise en place d’un virtual host sur le serveur apache local avec url rewriting,
et en utilisant comme nom de serveur une fausse adresse web, que l’on
ajoute dans notre fichier hosts pour pouvoir tester en local l’affichage du
webmail mobile
● Jeudi 13/01/2011
○ RDV avec Christophe Couroyer
○ Implémentation de la fonctionnalité “Connexion automatique” demandée par
les utilisateurs, par l’utilisation de cookies
26○ Avancement de l’architecture MVC : classe Email gérant la récupération des
mails via Imap et méthodes de traitement des informations contenues,
décodage du texte,...
○ Implémentation des interfaces (suite)
● Vendredi 14/01/2011
○ Analyse UML : suite de l’écriture des scénarios cockburn, diagrammes use-
case
○ Avancement des interfaces
○ Intégration de jQuery-mobile dans les vues de l’architecture MVC
○ continuation de l’implémentation de la fonctionnalité “Connexion
automatique”
○ début du développement d’un hack CSS pour passer outre un bug des
navigateurs iphone qui ne permettent pas d’avoir des toolbars de position
fixée
● Lundi 24/01/2011
○ Debugging "Connexion automatique"
○ Recherches sur la gestion des pièces jointes
○ implémentation du cryptage/décryptage des informations de login dans les
cookies
● Mardi 25/01/2011
○ Mise en place du téléchargement des pièces jointes
○ Début de l’insertion de l’interface de lecture d’un message à l’application
finale
○ établissement d’une première liste des fonctionnalités du webmail mobile qu’il
nous faudra implémenter
○ début d’implémentation de la fonctionnalité de recherche d’emails
○ nouvelle version de la fonctionnalité de placeholder pour les champs de texte,
utilisant cette fois-ci une nouvelle propriété du standard HTML5
● Mercredi 26/01/2011
○ Chargement des messages suivants dans une boîte
○ Réception des pièces jointes (suite)
○ Fin de l’insertion de l’interface de lecture d’un message
○ réalisation d’une page PHP qui teste la présence sur le serveur de l’ensemble
des paquets nécessaires au bon fonctionnement de notre application (php5,
php-imap, module mcrypt de php)
○ développement d’un module qui parse le contenu des emails, détecte les
adresses emails qu’ils contiennent, et en crée des liens vers la page de
rédaction d’email en pré-remplissant le champ destinataire
○ recherche de l’ensemble des lignes de commande à écrire pour déployer les
fichiers de l’application sur un serveur, rédaction de ces dernières dans le
README
○ correction de l’affichage des entêtes d’un email
27● Jeudi 27/01/2011
○ Insertion des autres vues dans l’application
○ affichage du contenu du champ Cc dans les détails d’un email
○ début d’implémentation des fonctionnalités répondre, répondre à tous,
transférer, qui redirigent vers la composition d’un email, en pré-remplissant
correctement les champs
● Vendredi 28/01/2011
○ Déplacement des mails dans la corbeille
○ Marquage des mails comme lus ou non-lus
○ correction de nombreux warnings que certaines de nos lignes de PHP
généraient dans les logs d’Apache
○ détection du support de la propriété placeholder du HTML5, et si ce n’est pas
le cas, affichage de labels au-dessus des champs correspondants
○ améliorations diverses de l’IHM (boutons, gestion du dépassement du texte
dans la liste des emails)
○ début d’implémentation de l’envoi d’emails via le protocole SMTP
● Lundi 31/01/2011
○ Réalisation du swipe (les paramètres pour un message dans la liste des
messages)
○ Ajout du rafraîchissement automatique dans la boîte de réception
○ Continuation du développement de l’envoi d’email, de l’ajout du message
dans le dossier Sent (sauf s’il n’a pas pu être envoyé), et avec plusieurs
destinataires (to, cc, bcc)
● Mardi 1/02/2011
○ Réalisation du code pour l’envoi d’un message
○ Réflexion sur le plan à faire pour le powerpoint
○ Déplacement des mails dans des dossiers
○ Terminaison de l’envoi d’email et tests
○ Début d’implémentation des fonctionnalités liées aux brouillons (sauvegarder
un email en cours de rédaction dans les brouillons; ouvrir, modifier et
envoyer un brouillon)
● Mercredi 2/02/2011
○ Préparation du Powerpoint pour la présentation
○ Finalisation du code pour l’envoi d’un message
○ Complétion du développement des fonctionnalités liées aux brouillons
○ Correction de bugs
● Jeudi 3/02/2011
○ Préparation de la présentation (suite)
○ Rédaction du rapport
○ Correction de bugs
28Vous pouvez aussi lire
