Projet : Webmail Mobile Polytech'Nice-Sophia

 
Projet : Webmail Mobile Polytech'Nice-Sophia
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
Projet : Webmail Mobile Polytech'Nice-Sophia
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
Projet : Webmail Mobile Polytech'Nice-Sophia
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
Projet : Webmail Mobile Polytech'Nice-Sophia
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
Projet : Webmail Mobile Polytech'Nice-Sophia
286 étudiants, enseignants et personnel administratif ont répondu à notre étude.
Voici quelques diagrammes clés des résultats obtenus :

                                                                                   5
Projet : Webmail Mobile Polytech'Nice-Sophia
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
Projet : Webmail Mobile Polytech'Nice-Sophia
● 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

                                                                                    7
II. 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

                                                                                               8
2. 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.

                                                                          9
Se 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

                                                                                          10
Se 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

                                                                   11
Gé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

                                                                      12
Envoyer 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

                                                                                             13
Afficher 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.

                                                                                            14
Supprimer 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.

                                                                                             15
Marquer 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

                                                                           16
Marquer 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.

                                                                                             17
Dé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.

                                                                                             18
III. 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.

                                                                                            19
1. 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

                                                                               20
GMail 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)

                                                          21
2. 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.

                                                                                             22
Utilisation 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.

                                                                            23
IV. 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é.

                                                                                         24
VI. 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.

                                                                                              25
Annexes

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

                                                                                            28
Vous pouvez aussi lire
DIAPOSITIVES SUIVANTES ... Annuler