Planisphère Web Interactif présentant les écoles à l'étranger qui ...

École Polytechnique de l’Université de Tours64, Avenue Jean Portalis37200 TOURS, FRANCETél. (33)2-47-36-14-14Fax (33)2-47-36-14-22www.polytech.univ-tours.fr

Parcours des écoles d’ingénieurs Polytech

Rapport de projet S2

Planisphère Web Interactif présentantles écoles à l’étranger qui sont en

partenariat avec Polytech

Auteur(s)Antoine Fonfria

[[email protected]]Nicolas Gougeon

[[email protected]]

Encadrant(s)Mickael Rousseau

[[email protected]]

Polytech ToursDépartement Informatique

Version du 10 avril 2012

Table des matières

Introduction 1

1 Définition du cahier des charges 21.1 Le Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Technologies et outils utilisés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Design et ergonomie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Développement de l’application 52.1 Développement côté client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 Architecture de la page . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.1.2 L’interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.1.3 Les animations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2 Développement côté serveur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.2.1 Architecture client-serveur . . . . . . . . . . . . . . . . . . . . . . . . . . 122.2.2 Base de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.2.3 Le PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3 Entretien et améliorations 203.1 Page d’administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.1.1 Structure de la page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.1.2 Ajout d’une école . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.1.3 Suppression d’une école . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.1.4 Récupération du formulaire . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2 Améliorations envisagées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Conclusion 23

Annexes 23

A Liens utiles 24

B Fiche de suivi de projet PeiP 25

Introduction

Ce projet consiste à créer un planisphère interactif présentant les écoles partenaires avecPolytech. On nous a suggéré d’utiliser les technologies web pour réaliser ce planisphère. Celanous convenait car nous connaissons tous les deux des langages web et faisons régulièrementdes projets web.

Ce projet présente 2 contraintes :- le planisphère doit être utilisable sur une tablette tactile géante, avec un tactile peu réactif(un peu comme les écrans tactiles de la SNCF).- l’esthétique est un point important à ne pas négliger, le rendu final doit être présentable.

En effet, si ces contraintes sont là c’est parce que ce projet servira ensuite de carte deréférence pour les écoles partenaires de Polytech lors des rendez-vous ou des journées portesouvertes. il est donc important de réaliser une application propre et fonctionnelle.

Grâce à notre expérience, nous avons su directement dans quelle direction partir dès le dé-but du projet. Pour ce qui est du graphisme, nous avons tous les deux quelques compétencesqui nous ont été utiles. Nous verrons dans ce rapport qu’une application Web comme celle-ciest divisée en deux parties : une partie client (ce que l’utilisateur manipule, la page, l’interface,les animations...) et une partie serveur (les informations récupérées dans la base de données etenvoyées au client par le serveur lorsque l’utilisateur charge la page). Nicolas est plus à l’aiseen javascript tandis que Antoine est plus à l’aise avec PHP, il allait donc de soit que Nicolasallait s’occuper principalement de la partie client et Antoine de la partie serveur.Cela dit, l’application aurait pu être développée sans partie serveur (ce serait alors une applica-tion statique) si il n’y avait pas eu la partie "gestion" du site qui est très intéressante. En effet,nous avons développé, en plus de l’application du planisphère, une page d’administration quipermet à l’administrateur de manipuler les données existantes ou de créer de nouvelles écoles.

Il y a eu malgré tout des hauts et des bas, certains problèmes se sont montrés plus durs àrésoudre que d’autres mais nous sommes toujours parvenus à les surmonter.

Nous vous présenterons dans une première partie, le cahier des charges de cette applicationweb, puis dans une deuxième partie, nous verrons les étapes du développement du côté clientet du côté serveur, et enfin nous verrons dans une troisième partie, la gestion de l’applicationet les améliorations que l’on aurait pu ajouter à l’application.

1

CHAPITRE 1

Définition du cahier des charges

1.1 Le Web

Le web est le support de notre projet. En voyant l’intitulé du projet, il semblerait plusapproprié d’utiliser un support comme le flash pour réaliser un tel projet, mais cela avait déjàété fait les années précédentes et cela n’était pas pratique car l’application n’était pas portable,il fallait le logiciel qui va avec, et l’application était assez lourde au final.

En utilisant le web pour réaliser ce projet, on assure une grande compatibilité et portabilitépour notre application. De plus, le une application web est assez légère.

1.2 Technologies et outils utilisés

Concernant les outils et technologies que nous utilisons, ils sont bien connues : bien sûrnous utilisons les langages web tels que HTML5, CSS, javascript pour la partie client, et pourla partie serveur nous utilisons du PHP couplé à un SGBD (Système de Gestion de Base deDonnées) gratuit et libre : MySQL.Pour les graphismes, nous utilisons GIMP, qui est un logiciel d’édition d’image libre et perfor-mant. De plus, il est installé sur les machines virtuelles par défaut.

Afin d’améliorer notre productivité et notre efficacité, nous utilisons la bibliothèque jQueryqui est une bibliothèque javascript qui sert à réaliser des choses simples facilement. Elle va nousêtre d’une grande aide pour les animations !

Côté serveur, nous utilisons une extension spéciale pour la connexion au SGBD : il s’agit del’extension PDO. Elle sert à se connecter à la base de donnée de manière sécurisée et surtout,sans prendre en compte la base de données qu’il y a en face. Ceci est un point important pournous car nous comptons mettre notre projet sur le site web de Polytech, or nous ne savons parencore quelle SGBD le site utilise. Nous verrons tout cela dans la partie serveur.

Enfin pour ce qui est de l’environnement de développement, nous sommes habitués à tra-vailler sur Notepad++, qui est un éditeur de texte très léger avec coloration syntaxique, nousavons donc évidemment choisit de développer sur cet éditeur.

Pour l’organisation du projet, nous avons structuré le dossier du projet en plusieurs parties :- la racine du dossier contient les fichier php ainsi que la feuille de style CSS - un dossier binqui contient les scripts .js - un dossier img qui contient les images de l’interface - un dossiersrc qui contient les sources des images d’interface - un dossier data qui contient les images desécoles

2

1.3 Design et ergonomie 3

1.3 Design et ergonomie

Tout d’abord, lorsque nous avons démarré le projet de planisphère, il y a une chose dontnous avions absolument besoin : un planisphère qui respecte les contraintes du projet. C’est-à-dire qu’il doit être présentable tout en étant pas trop lourd, et, si possible, qui respecte lacharte des couleurs de Polytech. Alors nous avons cherché un tel planisphère sur des banquesd’images sur internet mais ces planisphères étaient souvent très cher, surtout pour de grandesrésolutions. Alors nous avons demandé de l’aide à notre encadrant qui nous a fournit le meilleurplanisphère qu’on puisse trouvé : il est en très grande résolution, sans être trop lourd et estbleu clair, comme le logo Polytech.

Une fois le planisphère intégré au projet, nous avons beaucoup réfléchis au design et àl’ergonomie du site. Nous avons élaboré plusieurs maquettes jusqu’à en obtenir deux qui noussemblait convenable. L’une des maquette présentait un panneau latéral où on pouvait voir lelogo Polytech et les informations sur les écoles, l’autre maquette présentait une interface plus"flottante", au-dessus de la carte.

Finalement, nous avons retenu la dernière maquette car la première présentait trop d’espacesblancs vides.

1.3 Design et ergonomie 4

Nous avons aussi souhaiter ajouter des animations à notre projet. Cela n’a pas été facilecar il a fallu trouver un bon rapport qualité / performance notamment pour le zoom : si onaugmentait la précision de la carte, elle devenait plus lourde et on perdait en performance, maissi on diminuait le performance, on augmentait la précision !Les animations sont très lourde dans une application web car elles demandent à modifier l’ar-chitecture de la page (la façon dont la page est affichée), à chaque image de l’animation. Celas’appelle un "repaint". Or les "repaints" requièrent un passage par le DOM, et la passerelle quirelie le javascript au DOM est assez lourde. C’est ce qui fait que les animations sont si lourdes.

Heureusement, le moteur javascript V8 de Google, installé sur Google Chrome est codé detelle sorte qu’il permet d’utiliser javascript de façon asynchrone. Ce qui augmente considéra-blement la qualité des animations.

Notre application sera donc à utiliser sur Google Chrome principalement.

CHAPITRE 2

Développement de l’application

2.1 Développement côté client

2.1.1 Architecture de la page

Une page web écrite en HTML est divisée en plusieurs "briques" nommées balises. Il existedifférents type de balise en HTML. Certaines servent à écrite du texte, sauter des lignes, incluredes vidéo, du sons ou des objets, créer des bloc, afficher une image etc... Chaque balises à sespropres attributs et ses propres propriétés d’affichages.

Pour notre planisphère, nous allons avoir besoin de plusieurs "couches" d’éléments pourassurer l’affichages de tous les éléments du planisphère. Nous parlons ici de plusieurs "couches"pour désigner plusieurs surfaces, plusieurs plans. En effet, 3 plans semblent évident pour dé-couper notre planisphère : - un plan pour la carte - un plan pour les points représentant lesécoles - un plan pour l’interface Par exemple, si on respecte cette configuration, cela signifieraitque, graphiquement, le plan de la carte serait situé au fond, tandis que l’interface serait situéeau premier plan et les points des écoles entre ces 2 plans.

Nous sommes donc partis sur cette configuration basique mais logique pour "découper"notre page.Puis, il nous a fallu choisir des balises appropriées pour chaque plan.

Tout d’abord, pour le plan de la carte, nous avons utilisé une balise image <img /> carcette balise nous permet d’afficher une grande image de façon réduite (ce qui nous sera utilepar la suite, notamment pour le zoom, pour ne pas perdre en qualité).Puis pour le plan de l’interface, nous avons choisit des balise block <div></div>, il nous suffirajuste de créer plusieurs divisions pour chaque élément qui composera l’interface.Enfin, pour le plan des points, nous avions prévu en premier lieu d’utiliser les balises <area></area>couplées à une balise <map></map>. Ces balises nous permettent de créer des zones cliquablesrespectant une certaine forme (rectangle, cercle, polygone...). En effet, le plan des école est unplan "interactif" car c’est là ou l’utilisateur va cliquer afin de sélectionner une école. Or nousdevons faire en sorte que notre application soit accessible sur une tablette tactile.Notre idée était donc de placer des balises <area> en forme de cercle qui permettraient à l’uti-lisateur de sélectionner une école avec un doigt.Mais cette idée s’est vite avérée mauvaise car le plan de l’interface étant placé par dessus, leclic de l’utilisateur se produisait sur l’interface et non sur le plan interactif. Nous en avons doncconclu que nous devions utiliser des balises block pour les points aussi.

5

2.1 Développement côté client 6

2.1.2 L’interface

L’interface concerne tous les outils et fonctions qui seront utilisables par l’utilisateur pournaviguer sur la carte, obtenir des informations... Dans notre projet, l’interface sert de lien entrel’utilisateur et le planisphère. Nous verrons, dans une première partie, la fenêtre d’informations,qui sert à obtenir une description et quelques images de l’école, puis dans une seconde partie,l’outil de navigation qui permet de se déplacer facilement sur la carte.

La fenêtre d’informations

La fenêtre d’information c’est la partie de l’interface où on affiche les informations que l’ona récupérées dans la base de données. Parmi ces informations on y trouve une description etquelques images (la description est aussi disponible en version anglaise).

Concernant l’agencement de l’interface, la fenêtre d’information est placée sur la droite, defaçon à laisser apparent le point de l’école sélectionnée, et occupe une surface fixée sur l’écrande l’écran de l’utilisateur. Au départ, cette fenêtre d’information était formée d’un seul bloc<div>. Or, en respectant la maquette posée lors de la définition du cahier des charges, cettefenêtre est composée d’un gros bloc texte et d’une petite flèche sur la gauche qui montre quelleécole est fixée.

Mais cela posait des problèmes pour sélectionner une école à proximité du point sélectionné.En effet, du fait que la fenêtre n’était formée que d’une seule <div>, il y avait une "bande"verticale (là où était placé la flèche) où il était impossible d’atteindre la calque interactif encliquant, on cliquait a la place sur la <div> correspondant à la fenêtre d’infos. Par conséquent,certains points n’était plus accessible une fois la fenêtre ouverte !


Pour résoudre ce problème nous avons alors créé 2 balises <div> : une pour la flèche et unepour le bloc texte. Ainsi le bloc de la flèche ne déborde pas sur les autres points.

Pour ce qui est de la mise en page de la fenêtre d’informations, nous souhaitions respecternotre maquette de base mais après plusieurs essais, cela ne nous convenait pas, surtout auniveau de la disposition des images alors nous avons imaginé un nouveau découpage pour lafenêtre d’informations :


Ce nouvelle fenêtre est composée de 2 blocs : un bloc pour la description et un bloc pourles photos. C’est la fenêtre que nous utilisons actuellement.

La navigation

La navigation interne de l’application est très importante car c’est elle qui va définir com-ment l’application web s’utilise. Ce point est primordial car l’application doit être pratique etintuitive.

Au départ, nous n’avions que le zoom (et le dézoom) de disponibles sur la carte. On avaitdonc un seul bouton : le bouton "retour" qui permet de retourner à la vue sur la carte entière(dézoom). Tout d’abord nous avions pensé à un système où l’utilisateur pouvait cliquer sur lepoint qu’il veut et le zoom se produirait de manière à mettre le point de l’école sélectionnée aucentre de la zone zoomée. Ainsi, seuls les points permettaient d’effectuer un grossissement surla carte.

C’est alors qu’on s’est rendu compte que l’on était obligé de zoomer et de dézoomer la carteà chaque fois que l’on désirait changer d’école... Ce n’était pas pratique, n’importe qui le dira !De plus, travaillant en mode tactile sur la tablette, ce n’était pas facile de cibler le bon pointdu premier coup... Les points sont petits et assez peu espacés, surtout en Europe ! Alors nousavons imaginé un nouveau système que l’on a nommé "zoom double couche". En fait, derrière


ce nom ambigüe se cache un principe simple : on clique sur la carte une première fois pour avoirune vue plus précise de la zone concernée, puis on reclique une seconde fois, sur un point cettefois-ci, afin d’ouvrir la fenêtre d’informations. Arrivé à ce niveau, l’utilisateur a deux choix :- soit il clique sur une autre école à proximité pour voir ses informations (la carte effectueraalors un mouvement de glissement afin de mettre ce nouveau point au centre de la zone visible.- soit il décide de retourner à la vue globale de la carte en cliquant sur "retour".Le processus est, certes plus lourd, mais il permet plus de possibilités et est plus accessible àl’utilisateur.

Malgré tout, cela ne nous plaisait toujours pas... En fait ce nouveau système présentait denouveaux défauts que nous n’avions pas perçus immédiatement : lorsqu’on vient de zoomer surune zone, et que l’on clique sur un point, on a alors une vue zoomée sur la zone et une fenêtred’information ouverte. Deux problèmes se posent :- Comment faire pour accéder aux écoles d’une autre zone sans dézoomer et re-zoomer ?- Comment faire pout accéder à une école dont le point est situé sous la fenêtre d’information ?On ne peut pas cliquer dessus...

Alors nous avons amélioré l’interface en y ajoutant un outil de navigation. Au départ c’étaitsupposé être une "croix" (Nord - Sud - Est - Ouest) qui, par exemple, lorsqu’on clique sur Nord,nous amène sur le point le plus au nord.Cela semblait intéressant mais cet outil s’est avéré trop compliqué à mettre en oeuvre. Alorson a inventé un système très similaire, mais plus simple à réaliser pour nous. Il s’agit en faitde deux boutons "suivant" et "précédent" qui permettent de naviguer à travers les écoles enrespectant une suite d’écoles rangées dans un ordre prédéfini. (ces écoles sont rangées par leurlocalisation de l’ouest vers l’est d’ailleurs, comme nous le verrons dans le développement côtéserveur).

Enfin, pour peauffiner cet outil de navigation nous l’avons doté d’un "détecteur" qui vachercher quelle est l’école la plus proche de l’endroit où l’utilisateur vient de cliquer. En effet,lorsque l’utilisateur zoome dans une zone précise, il est fort probable qu’il désire prendre lesinformations de l’école la plus proche de là où il a cliqué. Désormais, en cliquant sur un desdeux boutons de navigations juste après avoir effectué un zoom, l’outil de navigation emmèneradirectement l’utilisateur sur le point le plus proche, puis l’outil reprendra sa fonction normale(école suivante ou école précédente).

Comment ce "détecteur" fonctionne-t-il ?En fait, c’est très simple, lorsque l’utilisateur vient de zoomer, on récupère sa position (Px,Py)sur la carte, et on la compare à toutes les positions des écoles (x,y) en effectuant ce protocolepour chaque école :- calcul de la distance en abscisse Dx et en ordonnée Dy


- calcul du modulo Voilà ce que cela donne en javascript :

Dx = Px - x,Dy = Py - y,

d = Math.sqrt(Dx * Dx + Dy * Dy)

La plus petite valeur est retenue et l’id de l’école correspondante est mémorisé.

Finalement, on pourra dire que le développement de cet outil de navigation, bien qu’ilsemblait facile, nous aura donné du fil à retordre : nous avons été confronté à un "petit"problème qui faisait que l’outil de navigation ne permettait pas d’atteindre certains points (lepremier ou le dernier suivant le sens dans lequel on tournait). Néanmoins, ce système permetde se déplacer sans encombrements, même si l’on a zoomé sur un océan... (de plus, les pointssitués sous la fenêtre d’informations, si il y en a, sont accessibles, quoi qu’il arrive. Le seul défautde ce système, c’est qu’il est assez peu intuitif pour l’utilisateur : deux boutons "suivant" /"précédent" au milieu de plusieurs points repartis irrégulièrement, ça ne parle pas à tout lemonde... C’est alors que, quelques jours après le développement des boutons de navigation, lorsde la journée portes ouvertes, nous avons constaté que la plupart des utilisateurs essayaient envain de faire glisser la carte de manière tactile pour se déplacer (comme sur un iPhone). Nousavons alors tenté le coup en développant cette nouvelle caractéristique sur notre application.

2.1.3 Les animations

Les animations sont de plus en plus utilisées dans le web, cela donne un aspect esthétiqueet fluide à l’application. De plus, ces animations sont supportées par la plupart des navigateursde nos jours. Enfin, grâce à jQuery, leur utilisation est plus simple. Toutes ces raisons nous ontpoussées à mettre en place des animations dans notre application.

Fonctionnement

Une animation est une suite d’image successive. Dans notre projet web, nous n’affichonsqu’une seule "image" que l’on modifie rapidement en respectant un certain calcul. Par exemple,pour réaliser un fondu sur un texte, on utilisera la propriété CSS "opacity" (nombre entre 0et 1 définissant le degré de transparence) et une variable "t" qui définira la progression del’application (donc t varie en fonction du temps). Dans cet exemple, un calcul d’animationpourrait être : opacity = t * 0.01Dans ce cas, à t = 1, opacity = 0.01, à t = 50, opacity = 0.5, etc... Ici, on voit bien que, plusle temps passe, plus la valeur d’opacité augmente. Donc l’élément correspondant est de plus enplus visible.

C’est le principe de base d’une animation. Avec la bibliothèque jQuery, les animationss’utilisent comme ceci :


En plus d’utiliser jQuery pour nos animations, nous utiliserons une autre mini-bibliothèquenommée jQuery easying qui permet de gèrer l’accélération de l’animation.jQuery easying est en fait une "base" de fonctions mathématiques que l’on peut attacher à uneanimation pour la rendre encore plus fluide.Par exemple, si on prend une fonction en x2, l′animationvadmarrerdoucementpuisvatredeplusenplusrapide.C ′estcequenousutiliseronspourlezoom.

Le zoom et le dézoom

Dès le début du projet, nous avions déjà planifié de faire un zoom sur la carte à un momentou un autre. En effet, les points sont trop peu espacés et il n’est pas pratique de sélectionneravec un doigt du premier coup le point désiré.

Nous avons donc utilisé une animation jQuery pour faire un zoom sur la carte. Cela n’aurapas été facile, car il faut non seulement grossir la carte, mais en plus, il faut gérer le décale dela carte vers l’endroit où l’utilisateur a cliqué.

4 propriétés rentrent en jeu dans cette animation :- width- height- margin-left- margin-top

Il faut savoir que la carte est positionnée par rapport à coin supérieur gauche. C’est-à-direque lorsque margin-left et margin-top valent 0, le coin supérieur gauche est situé au centre dela page. Donc il centrer l’image, on a les propriétés suivantes :

margin-left = - width /2 ;margin-top = - height /2 ;

avec width et height la largeur et la hauteur de la carte.Pour le grossissement, après plusieurs tâtonnements, on en a déduit qu’un zoom x4 était ap-proprié.

Les calculs de l’image finale de l’animation sont les suivants :

width : 4 * BASE_WIDTH,height : 4 * BASE_HEIGHT,’margin-left’ : 4 * (parseInt(MAP.css(’margin-left’)) - (x - ($(document).width() / 2))),’margin-top’ : 4 * (parseInt(MAP.css(’margin-top’)) - (y - ($(document).height() / 2)))

BASE_WIDTH et BASE_HEIGHT sont les dimensions d’origine de la carte.MAP.css(’margin-left’) et MAP.css(’margin-top’) valent les valeurs des marges d’origines.$(document).width() et $(document).height() valent les valeurs de la taille de la page.

Pour ce qui est du dézoom, on revient simplement sur les valeurs d’origines :

width : BASE_WIDTH,height : BASE_HEIGHT,’margin-left’ : - BASE_WIDTH / 2,’margin-top’ : - BASE_HEIGHT / 2

2.2 Développement côté serveur 12

Le glissement

On distingue 2 types de glissements : le glissement requis et le glissement manuel. Le glis-sement requis se produit lorsque l’utilisateur clique sur un point quelque part sur la carte : lacarte va de décaler progressivement de manière à placer le point sélectionné au centre de lapage. Le glissement manuel est une amélioration que nous avons apporté à l’application aprèsnotre constat de la journée portes ouvertes. Il permet de se déplacer en faisant glisser le doigtsur la carte (ou la souris en pressant le clic gauche).

Pour le glissement requis, le code est le même que pour le zoom sauf que les dimensions nechangent pas. On effectue simplement un décalage.

Pour le glissement manuel, la mise en oeuvre semblait compliquée mais cela s’est en faitavéré très simple : Lorsque l’utilisateur clique sur la carte, on garde en mémoire la position oùil vient de cliquer (dx,dy), puis on active un écouteur d’évènement : à chaque fois que la sourisbouge on récupère la nouvelle position avec e.pageX et e.pageY et on modifie la position de lacarte en effectuant le calcul suivant :

’margin-left’ : Ml + (e.pageX - dx),’margin-top’ : Mt + (e.pageY - dy)

Avec Ml et Mt étant les marges gauche et haut de la carte. (En fait Mt et Ml sont les margesde bases auxquelles on rajoute les coordonnées que la souris a parcourues).

2.2 Développement côté serveur

2.2.1 Architecture client-serveur

Cet aspect de l’application aura été celle posant le moins de problèmes, chaque bug ayantété résolu assez rapidement, les quelques requêtes étant relativement simples

La partie serveur s’occupe de traiter le code écrit en langage php, et fait le lien grâce à cedernier entre l’application et la base de donnée. Le principe général de cette technologie suit cedéroulement :


Utilisant ce principe pour un site dynamique, voici en détail comment le serveur interprètela page du planisphère, dans l’ordre de lecture de la page par celui-ci :


2.2.2 Base de données

PhpMyAdmin et WAMP

Nous avons travaillé sur une base en MySQL grâce à l’application phpMyAdmin. Celle-ciétant intégrée à Wamp, il était plus simple pour nous de transférer le projet d’un post à unautre. L’interface de cette application étant très facile d’utilisation, nous avons créé la tableet les champs de celles-ci directement dans le navigateur, nous évitant ainsi de complexes etfastidieuses requêtes. La « table » désignant l’ensemble des écoles et les « champs » désignantchaque paramètres possibles d’une école, en quelques sorte les colonnes de la table. L’exportationet l’importation de la base est elle aussi simplifié par phpMyAdmin. De cette façon, nous avonspu travailler sur le projet depuis n’importe quel poste muni de Wamp, en important celle-ci. Lesrequêtes php récupérant les données étant comprises à l’intérieur de la page, il était essentiel quela connexion puisse être établie afin d’éviter les erreurs SQL et de pouvoir avancer. De plus nousavons pu importer la base sur notre serveur personnel, afin de rendre accessible la version dedémonstration que nous avions mis en ligne. Ce qu’il faudra faire lors d’une utilisation ultérieurdu planisphère !

Nous avons enfin très rapidement rempli la table des écoles avec quelques exemples, afind’afficher quelques points sur la carte.

Structure de la table

Nous avons déterminé en premier lieu quelles sont les données intéressantes pour une école,en tant que champs de la table. Puis il a fallut sélectionner les options de chaque champs,selon le type de donnée : un nombre ou une chaîne de caractère par exemple. Nous avonsdonc une table comprenant : ID : l’identifiant unique de l’école : un nombre entier « INT »,«UNSIGNED » pour exclure les nombres négatifs et en « AUTO_INCREMENT », c’est-à-direque chaque nouvelle entrée aura un ID généré automatiquement à partir du précédent +1.NAME : le nom de l’école. Une chaîne de caractère « VARCHAR », encodée en utf-8 pour lescaractères spéciaux.NAME_EN : le même champ mais en langue originale, qui s’affichera lorsque le site est enanglais.DESCRIPTION : la description de l’école : un texte « TEXT » encodé en utf-8.DESCRIPTION_EN : le même champ mais en anglais.WEBSITE : l’adresse du site web de l’école : une chaîne de caractère «VARCHAR », encodéeen utf-8.ARROW_POS_X : la coordonnée horizontale de l’école en pourcentage : un réel « FLOAT »,« UNSIGNED ».ARROW_POS_Y : le même champ mais pour la coordonnée verticale.

Sans oublier que le champ ID est la clé primaire de la table. Ce qui permet un meilleur triet une accessibilité améliorée de la table par la base de donnée.

2.2.3 Le PHP

Avant toute balise html puis incorporé au sein même de la page, le php est omniprésentdans le code. Pour toutes les portions concernées, il faudra toujours ouvrir une balise < ?php et


la refermer par ?> afin d’avertir le serveur ce qu’il doit interpréter. De ce fait, toute instructionou commentaire compris dans ces balises n’est visible que sur le fichier initial, ouvert avec unéditeur de texte : sitôt traduite par le serveur, la page n’affiche plus que du html.

Le choix de la langue

La première partie du code traitée en php concerne le choix de la langue. En effet avanttoute balise html, le php crée une variable « $language » qui vaut « _EN » si la variable globale$_GET[’page’] vaut « en », c’est-à-dire si « ?lang=en » suit l’adresse du site, ou au contrairevaut une chaîne vide dans tous les autres cas. De cette manière, il suffit d’ajouter la valeur dela variable $language à la requête appelant le nom et la description des écoles. Si la langue n’estpas définie, la requête appellera les champs NAME et DESCRIPTION, tandis que si la langueest définie sur anglais, la requête appellera les champs NAME_EN et DESCRIPTION_EN.

De plus, on n’affichera que le bouton avec le drapeau de l’autre langue. Soit le drapeauanglais lorsque le site est en français et inversement, dans le bloc correspondant de la pagehtml :

Connexion à la base de données

Avant même de pouvoir accéder aux données, il faut se connecter à la bonne base. Utilisantl’extension PDO pour l’interface des requêtes PHP, il a fallut écrire la connexion en conséquence.

Nous avons tout d’abord créé un fichier « db.php » contenant les lignes de codes nécessairesà la connexion. De cette manière, il nous suffit d’inclure ce fichier en début de chacune despages du projet. C’est-à-dire écrire en première ligne des pages index.php et admin.php le textesuivant :

En veillant à mettre ces trois fichiers dans le dossier racine du site. En effet, l’adresse écriteentre les apostrophes de la fonction require_once (qui tente dappeler le fichier une fois, etretourne une erreur en cas d’échec) étant relative, uniquement le nom du fichier suffit dans cecas.

Pour la connexion, nous avons pour le moment utilisé une base locale, grâce à Wamp. Toutd’abord, la connexion doit être sécurisée, et en cas d’erreur doit l’afficher :


La connexion est tentée, et en cas d’erreur (que ce soit une erreur de syntaxe, un problèmedans la base, etc.) elle est récupérée par le catch() et affichée par la fonction die().

Il ne reste plus qu’à utiliser la bonne syntaxe et à rentrer les identifiants de la base utilisée.Ici, notre base en locale (localhost) appelée polytechmap, est accessible grâce au login root etne nécessite pas de mot de passe. Une sécurité supplémentaire propre à PDO est ajoutée grâceà la variable $pdo_options définie juste avant la connexion.

De plus, on informe le serveur que nos données seront encodée en utf-8.

Lorsque nous avons mis en ligne notre version de démonstration, nous n’avons eu qu’àchanger les différentes valeurs de connexion dans la définition de l’objet $bdd décrite ci-dessus.Ce qu’il faudra également faire en cas d’utilisation ultérieure !

La récupération des données

La première partie du PHP incluse dans la page récupère les informations des écoles. L’objet$bdd alors créé dans la page de connexion à la base, il suffit d’en extraire les informations grâceaux requêtes PDO.

L’objet $req_partners extrait de l’objet $bdd toutes les données de la table school, où *désigne tous les champs. On ajoute également l’instruction ORDER BY ARROW_POS_X,de manière à ranger au sein même de $req_partners les écoles de la plus à gauche vers la plusà droite sur l’axe horizontal.

L’affichage des points

Après avoir récupéré et rangé les données, il faut maintenant afficher les points correspon-dants aux écoles partenaires. Pour cela, on a utilisé une boucle qui s’effectue tant qu’il reste aumoins une entrée dans l’objet $req_partners à l’aide d’un while :


La fonction fetch() recherche l’existence d’une entrée, et si elle existe, la transforme en ta-bleau (array) en PHP désigné par $partner. Afin d’informer le serveur qu’on n’utilisera plusl’objet $req_partners, on ajoute après la boucle l’instruction closeCursor(). On ajoute éga-lement l’instruction ORDER BY ARROW_POS_X, de manière à ranger au sein même de$req_partners les écoles de la plus à gauche vers la plus à droite sur l’axe horizontal.

Les instructions pour chacune des entrées s’effectuant à l’intérieur de la boucle sont incré-mentées par une variable $i initialisée à 0 juste avant le while(), et sera utilisée dans l’identifiantdes points dans le DOM (important pour la liaison avec le javaScript).

Ces instructions comprennent plusieurs choses : Récupération et transposition en pourcen-tage des coordonnées (variants dans la base de 0 à 1).

Affichage du point grâce à un echo. Celui-ci étant défini par un id (utilisant la variable d’in-crémentation), d’une classe css que nous avons nommée school et de sa position relative parrapport à la carte en pourcentage.

Ajout des données dans le tableau PHP (array) contenant toutes les valeurs. Ce tableau à deuxdimensions est structuré de sorte qu’un sous-tableau à deux dimensions spécifique à chaqueécole soit associé à une clé unique qui n’est autre que la variable d’incrémentation.

Incrémentation de la variable pour l’école suivante.

Une fois toutes les entrées de l’objet PDO trouvées et utilisées dans la boucle, tous les pointssont affichés sur la carte, avec leurs coordonnées correspondantes et le tableau $dots_data estcomplété et prêt à l’emploi.

Le transfert en javaScript

Une dernière chose doit être géré par le PHP : la transposition du tableau $dots_dataen tableau javaScript. Une fois dans les balises <script type="text/javascript"></script> oninsère le PHP de cette manière :


Pour respecter la syntaxe de javaScript, nous commençons par compter le nombre d’écolesdans le tableau php à l’aide d’une variable $j incrémentée pour chaque école dans une boucleforeach. En effet, une virgule sépare chaque valeur du tableau javaScript, mais il n’y en a pasau début ni à la fin du tableau. Pour palier ce problème, nous testons après chaque école sic’est la dernière en décrémentant $j et en le comparant à 0 : si ce n’est pas le cas, on echo lavirgule.

Concernant les valeurs du tableau lui-même, nous créons un seconde boucle foreach, quipermet, pour chaque entrée de $dots_data de créer deux sous-variables correspondants auxdeux dimensions du tableau.

Il suffit maintenant de respecter la syntaxe de javaScript en insérant les variables phpintroduites en paramètres dans le foreach dans un echo comme entrée du tableau :

Le tableau est alors généré et contient toutes les données nécessaires au script pour lesafficher dans l’interface d’informations : les fonctions principales étant incluses après dans leDOM, elles auront accès à celui-ci.

CHAPITRE 3

Entretien et améliorations

3.1 Page d’administration

Écrire les données dans l’interface de phpMyAdmin n’est pas compliqué, mais pas vraimentagréable ni optimisé. C’est pourquoi nous avons essayé de créer une page d’administration oùdes outils permettraient d’accéder à la base de données de manière intuitive.

Nous avons bien avancé cet fonctionnalité de la carte, mais ne faisant pas partie à proprementdit du sujet imposé, nous n’allons pas détailler ici la façon dont nous avons écrit le code. Eneffet, il nous tenais à cur de réaliser cette page, mais manquant de temps, il reste beaucoup dechoses à améliorer et nous verrons cela dans la sous-partie suivante.

3.1.1 Structure de la page

Composée de la carte en arrière plan, mais non zoomable, cette page possède en haut unepetite barre d’outils où chaque bouton déroule son panneau d’admnistration correspondant.Nous avons créé pour cela un fichier javaScript admin.js en conséquence, afin d’y intégrer toutce qui la concerne, en lieu et place du script zoom.js.

3.1.2 Ajout d’une école

Le premier outils que nous avons intégré fut un formulaire complet permettant d’insérerune nouvelle école sur la carte interactive.

La principale difficulté de cet outil était de trouver un moyen pour l’utilisateur d’entrer lesbonnes coordonnées de l’école, sans avoir à calculer quoique ce soit. Nous avons pour cela réaliséun cadre spécial, dans lequel une carte rétrécie permet, en la survolant avec la souris, de déplaceun curseur sur un second cadre où un fragment de la carte est visible telle que l’utilisateur lavoit en mode zoom.

20

3.2 Améliorations envisagées 21

Une fois l’utilisateur satisfait de la position du curseur, un simple clique ajoute un point surla carte et transfert les coordonnées en pourcentages (entre 0 et 1) à l’intérieur du formulaire,tel qu’elles apparaissent dans la base. Cette interface particulière est géré grâce à un scriptjavascript qui déplace les éléments au mouvement du curseur.

Le reste du formulaire concerne les informations générales et ne présentent aucune difficulté.

Toutefois, il a fallut par la suite gérer les images pouvant être insérées : trois champssupplémentaires permettent de sélectionner des images depuis l’ordinateur de l’utilisateur. Cestrois images sont récupérées par la suite et enregistrées sous un nom particulier dans un dossierdu projet, permettant de les retrouver facilement, sans encombrer la base de donnée.

3.1.3 Suppression d’une école

Bien que ce ne soit pas très important (un simple clic dans la base suffit, et rare seront lesécoles à supprimer), cette fonctionnalité était très rapide à installée, et est donc présente etfonctionnelle. Une boucle php créée une ligne pour chaque école avec son titre et son id dansune liste à dérouler. Un clic sur le bouton supprimer et l’école est définitivement supprimée dela base.

3.1.4 Récupération du formulaire

Utilisant la méthode POST des formulaires, du php est écrit au tout début de la pageadmin.php, juste après la connexion à la base de donnée. Ce script teste la présence ou non devariables $_POST et réalise les opérations correspondantes.

Dans le cas de l’ajout d’une école, les données sont ajoutées dans la base et chaque imageest formatée puis transférée dans le dossier associé. Si au contraire l’utilisateur a cliqué sur lebouton supprimer, une variable $_POST indiquera au php de supprimer de la base l’entréecorrespondant à l’id donnée en valeur de variable.

3.2 Améliorations envisagées

Malheureusement, certaines choses n’auront pas été réalisées au cours de ce projet. Unmanque de temps et une trop grande ambition en sont la cause. Nous souhaitons tout de mêmenoter les objectifs et les idées que nous avons eu :

- Ordre des écoles optimisé. A l’heure actuel, les écoles sont affichées et triées en fonction deleur position horizontale. Hors, lors de la navigation, cela n’est pas intuitive et le déplacementfait de grands détours entre deux écoles apparemment proches. Nous aurions aimé améliorercet aspect et pourquoi pas calculer la distance entre deux écoles avant même de les afficher,pour pouvoir les trier de cette manière.

- Animations des points lors du zoom / dézoom. Les poins lors du grossissement de la cartegardent leur taille et se déplace de manière à rester aux bonnes coordonnées. Nous aurionsvoulu leur donner une animation particulière, afin d’avoir un meilleur rendu graphique.

- Edition des données dans la page administrateur. Nous voulions réellement ajouter cetteoption, mais cela demandais un trop grand investissement en temps que nous ne pouvions

3.2 Améliorations envisagées 22

consacrer à autre chose. C’est pourquoi le bouton est présent sur la page d’administration maisn’affiche pour l’instant qu’un triste « en construction ».

Conclusion

C’est avec un grand enthousiasme que nous nous sommes investis dans ce projet. Possédantdéjà une certaines connaissance du web et de ses langages, nous avons réalisé des maquettes,fais le graphisme et écrit le code avec confiance en nos capacités et abordé chaque séance detravail avec l’envie d’améliorer ce que nous avions laissé derrière nous la fois précédente.Parfois découragé devant les problèmes, nous n’avons pas baissé les bras et avons du parfoisrecherché des solutions très longtemps, étalant les recherches sur plusieurs séances, continuantà y travailler chez nous.Parmi les difficultés, celle nous ayant donné le plus de soucis aura été la fonction javaScriptdes déplacements lors du zoom. Et d’une manière générale, c’est tout le javaScript qui nousaura demandé le plus de concentration et de réflexion : l’utilisation de jQuery faussement utileà certains endroits, les calculs des mouvements d’animations,

C’est avec une fierté sans prétention que nous présentons aujourd’hui l’aboutissement de 12séances de travail, en complément de quelques heures supplémentaires en dehors. L’apparencegénérale de l’application, pouvant être amélioré, nous satisfait pour le moment et nous pensonsque le fonctionnement au niveau de l’utilisateur est satisfaisant. Fort de notre observation lorsde la journée portes-ouvertes, nous avons pu l’améliorer en conséquence et le projet a soulevébeaucoup d’intérêt de la part des visiteurs.

Notre seul regret aura été de ne pas rendre une application totalement fonctionnelle, compre-nant sûrement quelques bugs que nous n’avons pas découvert et manquant surtout de plusieursfonctionnalités décrites dans la partie III de ce rapport. Cependant, n’ayant eu qu’un tempslimité pour le réaliser, nous sommes conscients des enjeux.Nos expériences personnelles dans le développement web nous a appris qu’une application esttoujours améliorable et n’est jamais tout à fait terminée.

Nous abordons à présent la préparation de notre soutenance orale avec le même enthousiasmeque nous avons eu tout au long du projet.

23

ANNEXE A

Liens utiles

Voici une petite liste d’url intéressantes au sujet de ce projet :

– www.polytech.univ-tours.fr– www.jquery.com

24

ANNEXE B

Fiche de suivi de projet PeiP

Séance no 1 du12/01/2012

Nous avons tout d’abord réfléchi à l’ergonomie de l’application :l’utilisateur clique sur une école, l’application zoom sur la zone quila contient, puis en affiche les informations. Nous avons donc réaliséplusieurs maquettes sur papier de l’affichage et de l’apparence gé-nérale. Ensuite, nous avons décidé quelle technologie utiliser pourla récupération des données : soit une requête AJAX lors de chaqueclic sur une nouvelle école, soit un script PHP qui charge toute lesdonnées au démarrage de l’application. La deuxième option étaitla plus intéressante ici puisqu’on ne chargera l’application qu’uneseule fois pour chaque utilisation.

Nous avons récupéré quelques planisphères grace à une banqued’images libre de droit sur internet en supplément de celles queM. Rousseau nous a fait parvenir afin d’avoir un choix plus vasteet d’en sélectionner la plus appropriée. En effet, cette décision déli-cate aura deux conséquences : l’esthétique générale et la fluidité duzoom, qui risque de mal fonctionner avec une image de trop granderésolution.

25

26


Après les différentes maquettes, nous avons finalement opté pourune version web en php grâce à des requêtes en PDO et à une in-terface entièrement gérée en javascript, avec l’aide de jQuery. Pourla carte, nous conservons pour l’instant l’une de celles que nousavions téléchargé avant de recevoir "l’officielle". La couleur et l’as-pect nous semble plus approprié. Cependant la résolution n’est pasoptimale.

Nous avons commencé nos lignes de code : une page index.php,une feuille de style style.css et le javascript zoom.js. Nous avonségalement importé la librairie jQuery dans un fichier jquery.min.js.- La carte est centrée sur la page, quelle que soit la configurationdu navigateur grâce au css. - Bien qu’elle ne soit pas terminé, lafonction zoom en javascript permet pour l’instant de zoomer auclic de la souris, mais de manière répétée (aggrandissement x4 àchaque clic, indéfiniment). - L’affichage des points correspondantsaux écoles partenaires se fait grâce à un calcul de pourcentage parrapport à la carte. Nous avons testé avec quelques exemples. - Unebase de donnée temporaire nous a permit de commencer à écrire lesrequêtes php. Les coordonnées en pourcentages nt dans une table,avec le nom et la description des écoles prises en exemple. Le PHPdans index.php récupère ces données et affiche les points sur lacarte, uniquement dézoomée pour le moment.

L’interface une fois la carte zoomée est encore à l’étude. Nous es-sayons de trouver une solution à la fois intuitive, complète et légère.

Une première version de démonstration a été publiée sur un de nosserveurs personnels, afin d’y avoir accès sur différentes machines.

27


Nous avons découvert la tablette sur laquelle nous chargeront leplanisphère web. De ce fait, nous avons pu tester la démode lafonction de zoom. Le résultat est assez positif même s’il en ressortun manque de fluidité.

D’autre part, nous avons progressé dans notre recherche et revul’ergonomie de l’application : le zoom s’effectue au centre du clic,et non plus par zones. Cela réduira l’espace entre les points à l’em-placement choisi par l’utilisateur grâce à un grandissement x4 de lacarte.

Nous avons donc établi clairement le fonctionnement futur de l’ap-plication : Chargement du planisphère -> (clic) zoom quelque partsur la carte -> apparition d’un bouton "retour" (et éventuellementdroite / gauche pour sélectionner les écoles plus rapidement) ->(clic) sélection d’une école -> mouvement de glissement afin decentrer le point de l’école -> apparition de la fenêtre avec les infos/ images de l’école -> (optionnellement) fenêtre de zoom pour lesimages

La fonction de zoom du script a donc été modifiée en conséquence.

Nous avons également rempli la base de données avec une dizained’écoles et mis de l’ordre dans le dossier du projet.

28


Nous avons travaillé sur le JavaScript et les requêtes PHP (avecPDO) :

Etant donné que nous sommes avons du modifier la fonction dezoom lors de la séance 3, celle-ci n’était pas tout à fait fonctionnelleet nous avons corrigé quelques erreurs d’écriture. De plus, le zoomn’est désormais effectuable qu’une seule fois et nous avons ajoutéun bouton de retour, qui permet de dézoomer.

L’affichage des points a été modifiée : plutôt que de récupérer unpourcentage et de le transposer en valeurs absolues, le PHP utilisedirectement les coordonnées en pourcentages pour déterminer laposition d’un point par rapport à l’image. Ce qui leur permet derester à leur emplacement géographique (en réalité sur un calqueintermédiaire) lors de l’aggrandissement de la carte. Un "point"est en fait une image de 24x24 pixels réalisée sur GIMP, décaléelégèrement de manière à ce que le centre de l’image soit au pointdéfini par les coordonnées.

Nous avons étudié à l’oral et sur papier l’affichage de l’interfaceet la possibilité d’intégrer une fonction de changement de languefrançais / anglais, ce qui nous semble plutôt pertinent pour unecarte représentant les liens internationnaux de Polytech.

Nous avons mis à jour la version de démonstration sur notre serveurpersonnel en ligne.

29


Nous avons réalisé une première maquette de l’interface, dessinéesous GIMP et intégrée dans le projet. Abandonnant l’idée d’en faireune de taille relative à son contenu, comprennant trop d’inconvé-nients du points de vus graphique, nous avons opté pour une fenêtrede taille fixée munie d’un arrière plan et adaptée à la plupart desécrans actuels (et surtout à l’écran de la tablette, qui a une résolu-tion de 1920*1200).

Nous avons revu le code du javascript en conséquence : la fonc-tion zoom étant jusqu’à présent seule pour tout gérer (animations,fondu, déplacement, etc.), cela permettait d’être plus léger maispas du tout adapté pour le manoeuvrage de l’interface. Nous avonsdonc scindé cette fonction en deux : zoom(x, y, z) et unzoom(). Lapremière s’occupant de zoomer et d’afficher l’interface, la secondede dézoomer et de la faire disparaitre.

Nous avons mis sur papier le fonctionnement de la liaison ser-veur/client : Les données seront récupérées en PHP puis restituéessous forme d’un tableau javascript, qui sera utilisé par le script pourles afficher dans l’interface.

Nous avons enfin fait une mise au point sur le travail accompli etsur ce qui nous reste à faire.

30


L’affichage de l’interface étant buguée (un clignotement anormal etun zoom à l’infini), nous l’avons retirée le temps de corriger le ja-vascript. Ce problème nous a occupé la plupart du temps car nousn’en trouvions pas l’origine. Nous avons finalement décidé d’aban-donner en partie l’utilisation de jQuery, dont certaines fonctionssemblait entrer en conflit avec notre script. Nous avons donc retra-vaillé les fonctions de zoom en replaçant le jQuery par du javaScripttraditionnel.

Nous avons également amélioré la base de donnée en y duplicantcertains champs en version anglaise : avec le préfixe "_EN" dansla base puis nous avons rempli l’entrée de l’université de Hamburgafin d’avoir une école d’exemple complète (excepté les images pourl’instant).

De plus, nous allons utiliser des variables $_GET, qui se trouventdans l’adresse de la page, au lieu de variables stockées dans descookies. Cela supprimera les problèmes de compatibilité avec cer-tains navigateurs. On aura par exemple, pour la page en anglais :http ://www.adresse_du_planisphere.com/index.php ?lang=en

Le code PHP génère désormais une balise <area> pour chaquepoint de la carte, qui serviront pour la sélection des écoles. Ellesétaient jusqu’à présent quelques unes codées à titre d’exemple.

Enfin, nous avons participé à la journée porte-ouvertes de samedi18/02 où nous avons présenté l’avancée de notre projet sur l’écrantactile.

31


Nous avons finalement achevé l’intégration de l’interface (les bou-ton et la fenêtre d’information), mais certaines choses ne sont pasencore opérationnelles : les boutons "suivant" et "précédent" nefonctionnent pas encore et la mise en page de la fenêtre d’informa-tions est à peine entamée. Après plusieurs essais, l’interface présentepeu de bugs, on peut l’utiliser normalement sans se retrouver coincé(en effet le bouton "retour" fonctionne à merveille). De plus, l’effetde glissement lorsqu’on clique sur une école fonctionne enfin.

En outre, nous avons ajouté une fonction "free-mode" qui permetde se déplacer manuellement sur la carte zoomée. Cette fonctionne devait pas être présente sur l’application à la base à cause del’absence du multi-touch sur la tablette ELO. Mais la JPO nous apermit de remarquer que la plupart des gens tentaient de déplacer lacarte en glissant avec le doigt. Nous l’avons donc codé de manière àce que le glissement se fasse avec un seul doigt, ou avec un "cliquer-glisser" de la souris.

Nous avons mis à jour la version de démonstration sur notre serveurpersonnel en ligne.

32


Concernant l’aspect graphique :

- Nous avons créé un bouton retour sous GIMP respectant la chartede couleur du site. Cette image est divisée en trois (précédent, re-tour et suivant), avec chaque fois deux étages en hauteur de manièreà ce qu’au passage de la souris (au contact du doigt sur la tablette),l’image en fond se déplace vers le haut de sorte à créer un effet debouton poussoir (grâce au css directement). De cette manière uneseule image est chargée pour chaque bouton en même temps quela page et il n’y a pas de décalage le temps qu’une autre image decharge au passage de la souris.

- Un prototype modulable de l’interface est en cours de réalisation(un cadre qui change de taille en fonction du contenu) car le systèmeactuel ne nous convient pas.

- Nous avons agrandi la zone cliquable (ou "touchable") pourchaque point, portant la taille de ceux-ci à 48x48 pixels.

Concernant le PHP et le javaScript :

- Nous avons perfectionné le code qui transpose les données du PHPau javaScript, de sorte que le script connaisse la localisation despoints sur la carte en plus du contenu à ajouter dans l’interface. Lapartie requête serveur est pour ainsi dire terminée puisque toutesles données sont récupérées et adaptées.

- L’utilisation de jQuery nous a encore posé problème. Lorsque nousavons souhaité ajouter les fonctions "suivant" et "précédent" auxboutons de navigation, le script s’exécutait deux fois au lieu d’uneseule. Nous avons passé beaucoup de temps à chercher l’origine duproblème et seul repasser en javascript pur nous semble convenir.

33


Le problème concernant les fonctions en jQuery (1 seul évènementse manifeste 2 fois) n’est toujours pas résolu, mais heureusement,grâce au gestionnaire d’évènement du framework, ce problème n’estpas visible par l’utilisateur. Il n’est donc pas très gênant. Nousavons donc décidé de poursuivre le développement et de revenir surce problème plus tard...

D’autre part, les boutons "suivant" et "précédent" sont maintenantgérés grâce au javascript, même si il reste quelques bugs lorsque l’onveut aller trop loin (cela est aussi du au fait que la base de donnéesn’est pas encore complète). De plus, dans un souci d’ergonomie,nous avons intégré à ces commandes un algorithme qui cherche lepoint le plus proche de la position actuelle. Cela permettra à l’uti-lisateur de se déplacer facilement même s’il a zoomé dans l’océan...

Le choix de la langue est maintenant intégrée : l’utilisateur peutcliquer sur des drapeaux anglais et français en haut à gauche dela page, et le PHP récupère la variable $_POST et récupère lesdonnées en conséquence.

Nous avons enfin réfléchis à l’intégration d’un panneau d’adminis-tration permettant d’ajouter, d’éditer et de supprimer une école dela base de donnée sans passer par mySQL.

34


Concernant le JavaScript principal, nous avons amélioré le systèmede sélection d’école suivante ou précédente, qui fera naviguer l’utili-sateur entre les écoles en fonction de la position sur l’axe horizontal.Cependant quelques soucis nous ont fait perdre du temps et celan’est pas encore terminé. L’algorithme qui calcule l’école la plusproche du point de zoom actuel a été ré-écris pour être fonctionnel.

De plus, le script PHP affichant les points a été corrigé pour fairecorrespondre les bons identifiants pour chaque point et trie désor-mais les écoles en fonction de leur position sur l’axe horizontal pourcorrespondre au javaScript.

Nous avons commencé à coder la page d’administration, avec ajout,édition et suppression d’écoles. Une petite barre d’outils contientles 3 boutons (fais sous GIMP) : chacun déroule un panneau corres-pondant, grâve à un petit script JavaScript (fichier propre à la pageadmin a été créé : admin.js). Le formulaire d’ajout tout simple estcréé et les données sont récupérées et intégrées à la base. Cependantles images ne sont pas encore gérées. Les formulaires d’édition et desuppression d’école ne sont pas encore fonctionnels mais les "blocs"correspondants (et leur affichage grâce au js) sont en place.

Nous avons revu notre manière d’aborder les images des écoles :elles seront enregistrées dans un dossier sous un nom contenant l’idde l’école correspondante et seront récupérées grâce à cela par lePHP.


Nous nous sommes concentrés sur la page d’administration qui,une fois achevée, nous permettra d’insérer les écoles dans la basede données de manière plus facile. Pour l’ajout des nouveau point,nous avons élaboré un système de "mini-carte" intuitive. Il s’agitd’un module composé de 2 bloc : un bloc, à gauche, qui montre lacarte entière réduite (c’est le bloc sur lequel on fait glisser la souris),et un bloc qui montre la carte telle que l’utilisateur la voit lorsqu’ilzoome dans l’application et composée d’un viseur. Ce dernier semet à jour à chaque fois qu’un mouvement sur la carte de gaucheest enregistré. Cela permet d’avoir un placement plus précis sur lacarte. Quelques problème sont apparus au long du code, que nousavons su résoudre au fur et à mesure. De plus, le formulaire poursupprimer une école est désormais fonctionnel.

D’autre part, nous avons modifé la résolution de la carte dans l’ap-plication générale, afin d’obtenir un rendu de meilleur qualité (l’an-cienne carte était très floue). Il en résulte une baisse de performancelors du zoom, mais la qualité de l’image zoomée en est grandementaméliorée. Quelques améliorations mineures ont aussi vu le jour,comme la réalisation de l’interface de navigation en anglais.

35


Nous avons effectué quelques petites corrections : Seul un drapeaude langue est visible à la fois, au lieu des deux (ce qui était inutile).Sur la page d’ajout d’école, le viseur et le zoom se replace sur laFrance lorsque la souris quitte le cadre.

Pour cette dernière scéance, nous avons clarifié certains passagesdu code et ajouté de nombreux commentaires.

De plus, nous nous sommes attelés activement à la rédaction durapport de projet.

Planisphère Web Interactif présentant les écoles àl’étranger qui sont en partenariat avec Polytech

Rapport de projet S2

Résumé : Pour ce premier projet Peip, nous avons utilisé les technologies Web afin de réaliserun planisphère interactif sur navigateur qui permet de visionner géographiquement les écolespartenaires de Polytech qui sont matérialisées par des points sur lesquels il est possible de cliquerpour obtenir des informations et des images de cette école. Cette application servira lors desrendez-vous ou lors des journées portes ouvertes Polytech en illustrant un point très importantpour une école d’ingénieur : "Polytech à l’étranger". Ce planisphère Web sera accessible sur lesite officiel de Polytech et visible sur une tablette tactile lors des évènements spéciaux.

Mots clé : planisphère, interactif, partenaires, polytech, projet, web, HTML5, CSS, javas-cript, jQuery, PHP, MySQL

Abstract : For this first Peip project, we have used Web technologies in order to make aninteractive planisphere that works on a web broswer and allows us to view Polytech partnersschools geographically. Those schools are represented by floating points on the map on whichwe can click to get informations and images of that school. This application will be usedfor appointments or Polytech’s open house illustrating an important point for an engineeringschool : "Polytech abroad". This Web planisphere will be accessible on the official website ofPolytech and visible on a touch pad during special events.

Keywords : planisphere, interactive, partners, polytech, project, web, HTML5, CSS, javas-cript, jQuery, PHP, MySQL

Auteur(s)Antoine Fonfria

[[email protected]]Nicolas Gougeon

[[email protected]]

Encadrant(s)Mickael Rousseau

[[email protected]]

Polytech ToursDépartement Informatique

Ce document a été formaté selon le format EPUProjetPeiP.cls (N. Monmarché)

École Polytechnique de l’Université de Tours64 Avenue Jean Portalis, 37200 Tours, Francehttp://www.polytech.univ-tours.fr

Planisphère Web Interactif présentant les écoles à l'étranger qui ...

Documents

Transcript of Planisphère Web Interactif présentant les écoles à l'étranger qui ...