Retour : page principale > sommaire gestion des photos

Cahier des charges


Objectifs


  • Ajouter une gestion des images pour le carnet en ligne, afin de compléter les différentes observations entrées par l'utilisateur par
  • ses propres images (ou photographies), et permettre leur organisation hiérarchique et logique.
  • On voudrait aussi permettre à terme de faire une détermination collaborative de plantes qu'un utilisateur n'a pu identifier par lui même
  • par l'intermédiaire des images.
  • Cette application serait intégrée à l'ancien carnet qui lui-même profitera d'une refonte d'interface et de l'ajout de certaines fonctionnalités.

Ce qui ne sera pas réalisé dans le cadre de ce projet :
  • Pas de stockage des images originales
  • Pas de lien avec les applications de stockage en ligne existante

Choix ergonomiques


Etant donné que l'application sera amenée à être utilisée par des botanistes qui ne sont pas forcément experts en informatique, l'application se doit d'être la plus accessible possible et suivre pour cela, les conventions élémentaires de l'ergonomie.

  • Applications existantes

La plupart des choix ergonomiques faits pour l'application, sont issus de l'étude de plusieurs logiciels et sites web existants.
  • La disposition de l'interface (volets de consultation, différentes vues des photos etc...) est surtout inspirée des logiciels Digikam et IView Media Pro et sera décrite dans la partie suivante.
  • La partie upload des photos s'est inspirée de clients comme The Commonist, qui permet d'uploader du contenu vers Wikimedia Commons, en ce qui concerne l'upload massif d'images et des galeries PHP comme Coppermine ou bien PHPWebGallery pour l'ajout unitaire.
  • Les techniques de classement des photos et d'organisation sont reprises de Digikam, IViewMedia Pro, Picasa, et des sites de partages de photo comme
  •  SmugMug, Flickr et Picasaweb.

  • On peut trouver un tableau détaillant leur fonction intéressantes et des captures d'écran de ceux-ci sur cette page :
  •  Applications existantes

  • Refonte de l'interface :

  • L'interface de l'ancien carnet en ligne étant plutôt statique, il a été décidé de la rendre plus malléable et intuitive.
  • Le design général sera commun aussi bien à la partie image qu'à la partie observations, à savoir un volet de recherche à gauche
  • permettant de filtrer le contenu, qui lui sera affiché et organisé dans la partie droite de l'interface.

  • Voici des dessins préliminaires désignant grossièrement sa forme :


  • La nouvelle interface devra remplir plusieurs objectifs importants :
    • Être facilement appréhensible aussi bien par des néophytes que par des utilisateurs de l'ancien carnet en ligne.
    • On devra pouvoir associer des images à des observations ou bien uploader des images à associer ou à déterminer plus tard.
    • La gestion des images (upload et organisation) devra être facile et permettre le taggage avec des mots clés, organisable de
      • manière hiérarchique. Aussi, on devra pouvoir passer d'une observation aux images qui lui sont associées, le plus rapidement possible.
    • On devra pouvoir localiser les images sur une carte, soit à partir des coordonnées GPS entrées ou extraites de l'image, ou par
      • positionnement manuel de l'utilisateur.
    • Chaque élément de l'interface doit être prévu pour pouvoir être consulté indépendamment des autres, en vue d'une future implémentation du logiciel sur PDA.

  • Etant donné que le carnet est conçu comme une application bureau, ce qui est inhabituel sur le web pour le moment, il faudra veiller à donner
  • le plus d'informations possibles à l'utilisateur lors des changements et modifications des données (alertes, couleurs qui changent etc...).

  • Interface de manipulation des photos :

  • L'interface de consultation et de manipulation des photos devra permettre d'avoir plusieurs vues de celles-ci, à savoir :
    • Une galerie sous forme de vignettes
    • Une vue détaillée de l'image
    • Une liste reliant les observations aux images

  • Dans chacune de ces vues, on devra avoir accès aux fonctions suivantes :
    • Ajout de mots-clés associés aux images
    • Sélection d'une ou plusieurs images en vue de les associer à une observation donnée
    • Upload d'images par petites quantités
    • Gestion des métadonnées (ex: EXIF, IPTC, mots clés...)

Gestion des utilisateurs


  • Concernant la gestion des utilisateurs, la partie carnet en ligne suit les principes suivants :

Le premier critère pour les utilisateurs est que l'enregistrement ne sera jamais obligatoire.
Un botaniste pourra saisir ses données sans forcément s'enregistrer et celles-ci seront conservées dans un cookie ou dans le cache du navigateur, ce qui permettra une utilisation en mode brouillon, car nous estimons que l'inscription est un frein à l'utilisation.
Dans la pratique un utilisateur sera tout de même encouragé à s'inscrire car ceci lui permettra de partager ses données avec la communauté (ce qui est le leitmotiv de l'application), et aussi d'accéder à l'identification de ses images indéterminées. De plus, l'import des données ajoutées avant l'inscription est possible, ce qui permet de franchir le pas sans subir aucune perte de données, tout en accédant aux fonctions supplémentaires.
Ce principe suit le mode de fonctionnement en vigueur à Tela Botanica et dans les logiciels de types wiki, à savoir que la contribution est toujours encouragée, sans pour autant qu'elle impose de déposer des données personnelles, et ceci assure une communauté toujours pérenne et favorable à l'expansion.

  • La partie images possède ses propres principes qui ne sont pas tous compatibles avec ceux de la partie carnet.

L'identification d'un membre est nécessaire dans la mesure où la photo sera déposée sur le serveur et que cet accès requiert certaines informations (car les déposer en local sur sa propre machine n'aurait pas de sens et serait perdu en cas de perte de la session ou d'effacement du cookie). De plus, les images doivent être liées à l'utilisateur pour que celui-ci puisse les retrouver et les modifier et pour cela, une forme d'identifiant indépendante de la machine est indispensable.

Ainsi, dans l'interface, ceci se traduira par le fait que l'onglet "Images" (ou "Photos" pour les images du dessus) sera grisé pour l'utilisateur anonyme ou bien qu'un clic sur cet onglet invitera à s'enregistrer
ou bien s'inscrire sur le site afin de pouvoir profiter de cette fonctionnalité.

Choix techniques

  • Nous allons exposer ici les choix techniques faits et à faire sur la réalisation de l'application.

  • Interface client :

  • L'interface de gestion des photos devra s'intégrer le plus naturellement possible à la nouvelle interface du carnet en ligne, en conservant
  • les mêmes règle de fonctionnement et une disposition similaire des composants. On pourra donc continuer à utiliser le carnet en ligne pour saisir
  • ses données sans pour autant être obligé de se servir de la partie photo.

  • L'interface de l'ancien carnet en ligne utilisait l'API GWT et son extension MyGWT.
  • Cette technologie mise au point par Google, permet de programmer une application web dynamique, utilisant la technologie AJAX, en langage Java, qui sera automatiquement convertie en une page HTML et en code javascript. On crée donc la page en assemblant des composants (widgets) qui remplissent chacun une tache particulière.
  • Ceci simplifie considérablement la création d'applications exécutables en ligne et permet des possibilités difficilement approchables en utilisant le HTML et le Javascript classique.
  • Nous avons fait le choix de continuer à utiliser GWT, pour des raisons très simples :
    • Facilité à reprendre l'ancien code du carnet
    • Efficacité et simplicité de cette technologie
    • Nous pensons que GWT est promis à un très bon avenir (notamment couplé à la technologie Gears de Google permettant une utilisation en mode déconnecté).

  • Cette technologie et ses extensions ayant évoluées depuis, nous avons désormais plusieurs choix :
    • Conserver l'extension  MyGWT
    • Utiliser GWT-EXT, son concurrent direct

  • Les différences entres ces 2 technologies se situent à deux niveaux, le fonctionnement et les composants disponibles.

  • Tous deux utilisent la librairie Javascript Extjs mais d'une manière différente :
    •  MyGWT est supporté officiellement par Extjs et est mieux intégré à GWT
    • GWT-EXT est un wrapper vers la librairie Extjs et donc moins rapide que  MyGWT

  • Les composants et la manière de les utiliser différent :
    • GWT-EXT Possède beaucoup de composants et il existe différentes extensions développées par les utilisateurs
      • qui en augmentent encore le nombre.
    •  MyGWT possède un nombre plus réduit de composants et un "look and feel" moins élaboré

  • Après moult discussions sur le sujet, le choix final se porte sur GWT-EXT qui, même s'il n'est pas officiellement supporté par extjs se révèle plus pratique au niveau du développement et plus adapté à ce que nous faire.
  • Les deux applications ayant un résultat final similaire, ce choix n'aura que peu d'incidence sur l'utilisateur final.
  • Il n'est pas exclu toutefois, que nous migrions vers  MyGWT si les composants manquants deviennent disponibles et si celui-ci devient plus pratique d'utilisation. Ceci est facilité par le fait que les deux librairies
  • possèdent un fonctionnement extrêmement semblable.

  • Voici (à titre indicatif) des captures d'écran issues de l'ancienne version (Utilisant  MyGWT) et de la maquette du nouveau carnet en ligne
  • (Utilisant GWT-EXT)


  • Ancien carnet en ligne :

  • Nouveau carnet en ligne (maquette non définitive) :


A tester compatibilité!!

  • Gestion des données :

  • La gestion des données dans l'application devra être effectuée coté serveur, celui-ci fournissant les ressources demandées
  • par l'application. Nous conserverons le même principe de fonctionnement que pour le carnet en ligne classique, à savoir l'implémentation
  • personnalisée de l'architecture REST (Representational state transfer) programmée par David Delon.
  • Ceci pour des raisons de réutilisation de code (le serveur est programmé en PHP), de choix de developpement (nous ne voulons pas utiliser
  • Java sur le serveur), et d'efficacité.
  • En effet, cette dernière est accrue par rapport à une architecture plus classique et ce, grâce à plusieurs éléments :
    • la quasi-absence d'états facilite la maintenance et assure l'auto-suffisance de chaque opération
    • toutes les ressources nécessaires à une opération sont contenues dans l'url et donc faciles à identifier
    • une faible consommation de mémoire due à l'absence d'états
    • REST s'accorde bien avec le développement de Web Services et la communication
    • d'informations à travers des objets JSON ou XML

  • Cette implémentation sera donc améliorée (et au besoin remaniée) afin de permettre d'y ajouter les services d'accès aux images
  • Elle est capitale dans la mesure où l'architecture répond au besoin de rapidité de transfert des requêtes (la technologie Ajax envoie
  • beaucoup de petites requêtes asynchrones), et de chargement des images (chargements et ajout doivent s'effectuer le plus rapidement possible).

  • L'ajout des photos sera traité par un Web Service en PHP sur le serveur. Celui-ci organisera les photos dans différents dossiers numérotés,
  • tout en créant différents formats de l'image uploadée.
  • Les petites images destinées à être affichées dans la galerie seront stockées sur un disque dur rapide (15000 tours/min) car leur accès sera
  • très fréquent) tandis que les images destinées à être consultées en grande taille seront stockées sur un disque plus lent mais de plus grande capacité
  • (7200 tours/min).
  • Ceci se fera sous réserve de la disponibilité des disque dur, dans la cas contraire, les images seront stockées sur deux disques dur de vitesse moyenne
  • (10000 tours/min) déjà installés à tela botanica.
  • L'image sera aussi nommée en fonction de sa localisation sur les disques du serveur.


  • Le lien entre les observations et les image sera fera en ajoutant un champ à la table contenant les observations. Celui-ci contiendra la liste des identifiants des images associées
  • à l'observation.

  • Voici un schéma de l'architecture de stockage (stockage sur serveur + base de données) :

  • Modèle de la table dans la base de données :

  • table cel_images :


  • stockage sur le disque du serveur :

  • L'application client qui permettra l'upload massif de photo utilisera une partie du code source de The Commonist
  • qui est un client permettant l'upload de contenu vers différents wiki.
  • Méthodes de test

  • Nous partageons la philosophie de programmation qui stipule que les tests doivent être réalisés tout au long du développement et en parallèle avec celui-ci.
  • L'application sera donc testée deux deux manière différentes :
    • Test unitaires des fonctions (avec xUnit) dans le but de vérifier la validité du code et l'absence de bugs.
    • Test utilisateurs (avec des testeurs extérieurs)
Les tests de non-régression ne pourront se faire que par petits morceaux et devront rester très simples car l'étude préliminaire révèle que la plupart des outils spécialisés dans les tests d'application web s'accordent très mal avec le code généré par gwt, de par sa complexité et le nombre important d'imbrications de balises.
Des tests pourraient tout de même être implémentés mais ils seraient beaucoup trop dépendants d'une version donnée de gwt ou de extjs.

Enfin, le test d'une fonction ou d'un bout de code doit être écrit (ou au moins décidé dans son concept) avant de coder, afin de définir clairement l'objectif de chaque partie de ce que l'on programme. Ainsi, le code est considéré comme valide au moment où il réussira le test programmé en amont (sous réserve que le test ait été correctement effectué).


Ajout, organisation et administration des images


  • Ajout des images

  • L'ajout d'image pourra se faire de deux manières différentes, unitairement, ou massivement.
    • L'ajout unitaire se fera à partir de l'interface grâce à des boutons prévu à cet effet et se fera donc directement dans l'application.
    • L'ajout massif d'images requerra l'identification dans la mesure ou cela fera appel à un client externe (même si son lancement se fera à partir de l'interface du carnet et sera donc transparent pour l'utilisateur) et permettra de sélectionner plusieurs images ou plusieurs dossiers et de les transmettre directement sur le serveur.

  • Ceci à cause d'une limitation de navigateurs, qui ne permettent pas de sélectionner plus d'un fichier à la fois lors de l'ouverture d'une fenêtre de sélection.

  • Organisation des images

  • Une fois associées à un utilisateur, les images pourront être modifiées et organisées :

  • Les images ainsi ajoutées seront tout d'abord organisées automatiquement à l'aide de l'extraction des métadonnées EXIF et IPTC qui permettra une évaluation automatique de la date du lieu, du nom de l'appareil etc... Ceci constituera les premiers critères de tri des photos pour l'utilisateur.
  • Ensuite l'utilisateur pourra, à sa guise définir des mots-clés (tags) associés à une image qui pourra organiser hiérarchiquement, ce qui lui permettra de faire une recherche sur ces mêmes mots-clés et donc sur les observations associées aux images.
  • Chaque image pourra être associée à une ou plusieurs observations, et donc être liée à celles-ci dans la galerie.
  • A partir d'une ou plusieurs images données on pourra choisir de créer une observation qui sera remplie avec le maximum d'informations communes aux images sélectionnées.
  • Enfin, tout comme les observations peuvent être transmises ou pas à Tela, les utilisateurs pourront choisir de transmettre ou non les images à Tela Botanica pour une utilisation dans eflore,
  • ceci afin d'éviter que les utilisateurs doivent envoyer l'intégralité des images associées à une observation. Ainsi un utilisateur pourra choisir de ne transmettre que la ou les meilleure(s) image(s) pour une plante donnée
  • plutôt que de toutes les partager.

  • Géolocalisation

  • Une observation ou une image possédant des coordonnées GPS pourra être localisée sur une carte satellite, à l'aide du widget Google Maps.
  • Celle-ci permettra de consulter l'emplacement précis, et pourra être déplacée sur la carte elle même, dans le cas où les coordonnées
  • ne correspondraient pas exactement à la localisation voulue.
  • Une localisation "a minima" pourra se faire en utilisant le nom de la commune dans le cas où les coordonnées GPS seraient indisponibles.
  • Celle-ci fournira une base au placement qui pourra être précisé sur la carte elle même.

  • Capture d'écran d'une géolocalisation par coordonnées sur la maquette du nouveau carnet en ligne :

  • capture d'écran du nouveau carnet en ligne : géolocalisation


  • Qualités des photos et identification d'une plante

  • Cette section est à mettre au conditionnel et ne se fera que sous réserve que le reste de l'application ait été développée dans les temps.

  • Les photos visibles par les autres membres du site pourront être, à terme, évaluées à l'aide d'un système de vote
  • qui permettra de donner un avis sur la qualité de la photo.
  • Une photo de grande qualité apparaîtra donc comme illustration pour un taxon donné dans la base de données eflore.
  • Ainsi un utilisateur ayant contribué à l'aide de bonnes photographies sera donc récompensé par leur mise en valeur lors de la recherche d'une plante.
  • En outre, un botaniste inscrit sur le site pourra déposer une photo qui sera considérée comme "à déterminer" et celle-ci sera donc soumise
  • aux membres qui voudront donner un avis qui pourra être accepté ou refusé par le dépositaire de l'image. Ceci fonctionne dans la mesure
  • où l'avis sur la détermination s'affinera petit à petit lors de votes successifs des membres. Ce fonctionnement mettra donc en place un
  • système de détermination collaboratif et sera d'autant plus intéressant qu'une photo de bonne qualité sera d'autant plus digne d'être déterminée
  • de par la contribution qu'elle pourrait apporter à la base de données botanique du site.

  • Ce système de participation permet la maintenance d'un contenu de qualité et la sensation que les membres contribuent réellement à l'élaboration
  • de la base de données eflore, tout en ne nécessitant que peu de validation, dans la mesure où elle est effectuée par la communauté d'utilisateurs.


  • Administration des images

  • Même si l'ajout de photos sera libre et gratuit, il est tout de même prévu que les administrateurs du site de téla botanica puissent accéder aux photos déposées par les membres via une interface d'administration appropriée.
  • Ceci servira dans le cas ou des photos de mauvaises qualités et/ou non appropriées seraient signalées par les utilisateurs du site. Celles-ci pourraient donc être effacées ou au moins mises "hors ligne" en attendant que l'on décide ce qu'il convient d'en faire.
  • Il n'y aura donc pas de validation par Tela des photos avant leur mise en ligne (cette tâche sera réalisée par l'utilisateur lui même lors du choix des photos dans une certaine mesure), ce qui demanderait beaucoup trop de moyens et serait contraire aux principes de fonctionnement de l'association, mais plutôt des possibilités de contrôle à posteriori, qui permettront de surveiller tout de même le contenu déposé sur les disques du serveur, et ce à l'aide de flux rss...
  • On pourra aussi disposer d'une liste d'utilisateurs pour lesquels on pourra automatiquement refuser les photos (blacklists), ceci afin d'éviter des abus répétés qui pourraient se produire.

Différents types d'utilisateurs :
  • standard : peut utiliser l'application avec son propre carnet
  • admin : comme un utilisateur standard mais peut accéder à toutes les images et les trier selon l'utilisateur, les modifier, les bloquer, et les supprimer.
  • Il peut en outre nommer d'autres administrateurs, accéder à la liste des utilisateurs, et en bloquer voire en supprimer certains.

Droits et licence


  • Dans la mesure où le service proposé est entièrement gratuit, les photos stockées sur le serveur de tela botanica seront implicitement
  • considérées comme étant sous licence libre Creative Commons (by-sa), à l'image des autres images situées sur le site de tela botanica.
  • Le code source de l'application sera placé sur licence CeCILL, similaire à la licence GPL, adaptée au organisme publics, de recherche etc...


Redesign


Voici un aide mémoire pour les différentes correspondances entre les images à changer pour l'application et l'emplacement qu'elles occupent :


Pages ayant un lien vers la page courante :
CelV2GestionPhotos