Pour savoir où on va, il faut savoir d'où l'on vient

Vous avez
une question ?
Un projet ?

Contactez nous !
 

Contactez-nous

Vous avez une question ? un projet ? 
Vous souhaitez plus d'informations sur un produit ? sur notre offre ? 
Contactez-nous, on vous répond sous 4H.

retour

Démarche: comment faire ?

Démarche: comment faire ?

Conception fonctionnelle,ergonomique et graphique

Trois approches – Démarche projet
Screenshot from 2015-04-23 09:45:32
Prendre le sujet dans le bon sens
Screenshot from 2015-04-23 09:47:24

Focus sur la conception fonctionnelle

Typologie des u sages en mobilité
  • Le choix des informations et fonctionnalités à mettre à disposition de l’utilisateur de smartphone est à déterminer en fonction de ses besoins. Ceux-ci sont pourront être catégorisés en 3 à 4 grands groupes, en répondant à la question:

           Pourquoi, quand, où et comment un utilisateur a-t-il besoin d’accéder à mon site / service ?

  • La typologie de Google ...
    • « Urgent now », « repetitive now », « bored now »
  • ... Que Luke Wroblewski (auteur de « Mobile first » chez Eyrolles) reprend en :
    • Consulter / Rechercher:
      • « J’ai besoin d’une réponse maintenant - et ici »
      • Exemple: Où est ce restaurant ? A quelle heure est la séance ?
      • Enjeu : proposer des modalités de recherche rapide
    • Explorer / Jouer
      • « J’ai du temps et je m’occupe / je m’amuse »
      • Exemple : Y a-t-il de nouvelles images du robot de la NASA ?
      • Enjeu : Être ludique / proposer des poursuites de lecture
    • Vérifier / Checker
      • « Un contenu est continuellement actualisé et je veux être tenu au courant des changements »
      • Exemple : Roger Federrer est-il en train de gagner son match ?
      • Enjeu : alerter, montrer les contenus chauds tout de suite
    • Editer / Créer
      • « Je dois faire quelque chose qui ne peut pas attendre »
      • Exemple : J’ai oublié de réserver ma place de concert!
      • Enjeu : faciliter la saisie, les choix (formulaires)

Exemple de site mobile dédié : Krys – Des fonctionnalités clés

Screenshot from 2015-04-23 09:59:00

Le site web de Krys est très riche et présente notamment les collections. Lors de la conception du

Screenshot from 2015-04-23 10:00:21

site mobile, seules trois rubriques ont été mises en avant, mais celle-ci répondent précisément à des besoins en situation de mobilité:

- Mes commandes – Suivre ses commandes:
« Je ne suis pas loin de la boutique Krys, je vais vérifier si mes lunettes sont arrivées avant de m’y rendre »

-Informations – Informations pratiques:
« Mon fils vient de casser ses lunettes, étaient-elles garanties ? »

- Trouver un magasin – Store Locator:
« En vacances, où est le magasin le plus proche dans lequel Krys me réparera ma monture »

Focus sur la conception ergonomique

A garder en tête
Screenshot from 2015-04-23 10:02:45
Privilégier le contenu aux liens 1/3
Screenshot from 2015-04-23 10:03:55

Les liens prennent trop de place. Laissez d’abord vos utilisateurs lire, regarder, écouter.

Ils approfondiront s’ils le souhaitent.



Pousser immédiatement les contenus chauds, et laisser les liens et options de navigation accessibles à la demande

Ne pas obliger l’utilisateur à passer par un écran intermédiaire







Privilégier le contenu aux liens 2/3


Screenshot from 2015-04-23 10:08:18


Evitez les barres de navigation sandwich car elles occupent un espace de visibilité précieux sans que leur utilité soit garantie 

Un accès à l’ensemble des catégories / rubriques depuis toutes les pages n’est pas utile
















Screenshot from 2015-04-23 10:10:23
Privilégier le contenu aux liens 3/3


Facilitez les poursuites de lecture là où elles sont pertinentes (dans leur contexte), via des liens intelligemment placés après le contenu

 Laisser toujours le choix à l’utilisateur de poursuivre ou d’interrompre sa lecture









Concevoir une charte de navigation simple 1/4
Screenshot from 2015-04-23 10:12:35
Concevoir une charte de navigation simple 2/4
Screenshot from 2015-04-23 10:13:45

Le bouton « Retour » (back de l’historique) est inutile sur les terminaux autres que iOS, en revanche, le bouton de retour à

la page mère est pertinent (en indiquant quelle est cette page)

(Sur iOS, un bouton est disponible au  niveau de la barre d’adresse du navigateur Safari, et donc également
inutile sur les sites web-mobile)

Concevoir une charte de navigation simple 3/4
Screenshot from 2015-04-23 10:18:52


Concevoir une charte de navigation simple 4/4
Screenshot from 2015-04-23 10:21:33

Utiliser la barre fixe dans le cas d’applications :
• En haut (Android) qui a déjà des boutons natifs en bas...
• Ou en bas (iPhone)

Même si cette règle n’est pas universelle, il faut garder en tête ces potentiels réflexes
d’utilisation





Assurer la lisibilité
  • Rendre les textes lisibles avec des tailles de caractères suffisamment grandes
  • Proposer des zones activesde taille suffisante pour un pouce d’homme adulte
    Screenshot from 2015-04-23 10:24:01
  • Adopter une organisation unitaire en ligne par ligne afin que la lecture et la manipulation soit simple et ne conduise pas l’utilisateur à commettre des erreurs de « tap »
Tactile - Choisir les bons gestes

Les smartphones sont caractérisés par leurs interfaces tactiles. Cette manière d’interagir est certes très intuitive, mais elle reste nouvelle pour le grand public. De nombreux types de gestes existent et peuvent encore être inventés ; mais l’ergonomie ayant pour vocation de simplifier et fluidifier l’usage, il faut les utiliser à bon escient.

Les utilisateurs d’aujourd’hui ne connaissent pas encore toutes les subtilités possibles et aucune norme universelle ne s’est encore installée comme par exemple:
- Le clic droit de la souris pour accéder à des options avancées
- La croix qui indique la fonction de fermeture d’une fenêtre

Ainsi, dans la liste des principaux gestes ci-dessous (issue de « Touch Gesture Reference Guide » www.lukew.com) nous conseillons de n’utiliser que ceux encadrés :
Screenshot from 2015-04-23 10:45:20
Tactile - comment utiliser les gestes

Même parmi les gestes simples, certains ne sont pas totalement intuitifs, il faudra les rendre lisibles...

  •  C’est pourquoi nous avons encore besoin de boutons affichés dans l’écran et explicitement visibles pour les utilisateurs
  •  Mais cela ne doit pas nous empêcher d’utiliser les gestes pour l’activation de raccourcis ou d’actions avancées pour un usage expert, en doublon des boutons disponibles à l’écran
  •  Les gestes avancés deviennent donc des raccourcis au même titre que les raccourcis claviers ont envahis nos applications de bureautique
Screenshot from 2015-04-23 10:47:26
Tactile - gérer l’absence de pointeur

Pas de pointeur = pas de survol (roll-over)

Les interactions disponibles via le survol dans les sites classiques doivent être totalement repensées sur le smartphone et sur les tablettes:

Point d’attention: Les tablettes tactiles sont très majoritairement utilisées (>90%) à domicile, en remplacement du PC portable et très souvent pour naviguer sur Internet. La taille des écrans, puissance des appareils et des navigateurs permettent de consulter la plupart des sites sans problème technique particulier. Néanmoins, les ergonomies bâties sur des roll-overs ne pouvant être rendues, les sites sont parfois totalement inutilisables à cause de ce point de détail.

Quelques approches:

  •  Afficher directement les contenus dans l’écran car ces contenus sont jugés bien trop importants pour l’utilisateur
  •  Les insérer dans l’écran par un geste (tap, press, flick) permet de conserver leur affichage contextuel au coté des contenus de l’écran (le plus simple étant généralement d’autoriser un tap pour activer l’effet du roll-over)
  •  Les afficher sur un écran séparé car la quantité de contenu est trop importante et ces contenus ne peuvent pas être tronqués
  •  Ne rien faire car les contenus sont secondaires et que l’utilisateur peut aisément s’en passer

En règle générale: sur un site grand-public, l’utilisateur doit pouvoir se passer de l’interaction de survol à moins de n’avoir développé une version dédiée aux tablettes. Cette remarque est d’autant plus importante pour les sites de e-commerce!

Saisie sur mobile
Screenshot from 2015-04-23 10:50:52
Sélection de données
Screenshot from 2015-04-23 10:53:40

Autant que possible, remplacer la saisie d’une donnée par la sélection

  • Créer des contrôles spécifiques pour remplacer efficacement les contrôles standards : slider, boutons +/-, calendrier, ...


Plus facile de faire glisser son doigts, de taper rapidement au même endroit, ou de choisir directement une valeur que de taper une zone de saisie, puis taper sur son clavier

Screenshot from 2015-04-23 10:54:11

... En plus des adaptations déjà prédéfinies par les plateformes





Site mobile

Les étapes de création d’un site mobile débutent par les écrans
Screenshot from 2015-04-23 10:57:17
Création des écrans : options et contraintes
  • La méthode de création des écrans d’un site mobile dépend de l’outil utilisé pour gérer les contenus (CMS) du site web classique. Selon l’outil et ce qu’il propose, mais aussi selon l’ergonomie, les contenus et le design ciblés, on se portera plus ou moins vers des fonctionnalités standards de création voire de duplication du site web:
    • Thèmes / vues standards:
      • L’outil propose en standard une version mobile avec des gabarits ou vues utilisées pour le site web classique (implique un site web classique construit sur ces mêmes standards)
      • L’arborescence du site mobile sera donc identique à celle du site web classique
      • L’ergonomie et le design sont imposés par les thèmes
        Screenshot from 2015-04-23 11:02:02
    • Gabarits dédiés:
      • On développe dans la logique de l’outil un nouveau jeu de « gabarits »
      • L’ arborescence du site mobile sera donc identique à celle du site web classique
    • Ecrans totalement spécifiques:
      • On construit les écrans de bout en bout et on peut donc sélectionner les contenus à mettre en avant ou non
      • Dans tous les cas, le montage des écrans devra idéalement se faire en
  • « adaptatif », les écrans étant adapté en largeur à la taille de l’écran:
    • Toutes les tailles et proportions d’écrans différents
    • Les deux orientations (paysage / portrait)
    • Potentiellement les nouveaux et futurs appareils
Création des écrans : problématique de compatibilité des navigateurs
  • Même si on parle de Web, et donc théoriquement de technologies universellement  interprétées par les navigateurs, des écarts subsistent.
  • Interface tactile:
    • La détection des « événements » tactiles n’est pas homogène d’un navigateur à l’autre
    • Chaque navigateur (i.e. ~chaque OS) nécessitera donc un développement spécifique sur la partie IHM (Interface Homme Machine) tactile
  • Interprétation du code HTML5 / CSS3:
    • L’HTML5/CSS3 permet d’enrichir les rendus, de proposer des animations et des interfaces riches et esthétiques
    • La future norme n’étant pas encore validée, le niveau de compatibilité est variable d’un navigateur à l’autre
    • Des ajustements seront donc également nécessaires, notamment en vue d’éventuelles versions dégradées
Screenshot from 2015-04-23 11:05:27
Screenshot from 2015-04-23 11:06:24

Zoom sur le Responsive Design

Principe du Responsive Design
  • Définition (wiki): la notion de Responsive Web Design regroupe différents principes et technologies permettant de concevoir un site pour qu’il s'adapte aux différentes tailles d'écran et aux différents terminaux
  • Il s’agit donc:
    • 1 page unique pour l’ensemble des terminaux (une seule contribution, administration, hébergement, URl, etc.)
    • 2 à 3 ergonomies différentes par page : [desktop-souris / tablette] / smartphone
  • Exemple www.sony.com:
    • Construit sur la base d’une image de fond, puis de 4 colonnes de contenus (dont une double), le site s’adapte passant à 3 colonnes puis 2 en fonction des versions
    • Le point intéressant étant ici les éléments de navigation qui se regroupent dans des menus déroulants de navigation
Screenshot from 2015-04-23 11:09:35
Création des écrans avec le Responsive Design
Screenshot from 2015-04-23 11:10:43
Le Responsive Design : avantages / inconvénients

Screenshot from 2015-04-23 11:12:06
Applications

Les étapes de création d’une application débutent par les écrans
Screenshot from 2015-04-23 11:22:14
Screenshot from 2015-04-23 11:23:25
Screenshot from 2015-04-23 11:24:22
Conception : le fonctionnel avant tout
  • Une évidence parfois oubliée:
    • Une belle appli qui ne sert à rien ou ne fonctionne pas bien sera désinstallée...
    • Une appli utile mais moche sera critiquée mais utilisée... puis applaudie le jour de son lifting!
  • Votre application sera en concurrence avec 500 000 autres et les places sur la page de raccourcis de l’utilisateur sont chères, donc:
    • Pensez simple, efficace, intuitif
    • Préparez vous à la faire évoluer, à riposter...
    • Offrez des possibilités de personnalisation c’est-à-dire permettre d’adapter l’application aux usages individuels
    • N’utilisez une fonctionnalité que si elle apporte vraiment quelque chose (accéléromètre, facebook connect, son,
    • caméra, géolocalisation...), l’époque des « gadgets » est révolue
    • Pensez aux situations d’usage et aux « objets / services » concurrents
  • Si vous ne rendez pas un service très spécifique voire unique, vous devrez faire mieux que les autres, notamment les acteurs couvrant un périmètre plus large:
    • Une application de news sera concurrencée par les agrégateurs de flux dont c’est le cœur de métier (ex: Pulse)
    • Une application donnant les séances de cinéma pour une enseigne ou une ville sera concurrencée par
    • l’incontestable leader: Allociné
    • De même pour un agent immobilier avec SeLoger.com
Développements : les spécificités du mobile
  • Multiplicité des OS: un développement par OS ou une solution cross-platform ?
    • A moins de vouloir faire un Angry Birds (jeu phare sur smartphone le plus vendu)...
    • ... le cross-platform est une bonne idée (cf. partie suivante)
  • Nouvelles fonctionnalités dites « natives » à prendre en main:
    • APN, gyroscope, vibreur, GPS...
    • Type de connexion, mise en veille, tâche de fond, réveil, stockage local, synchronisation, consommation...
    • API externes (Google Maps, Facebook, etc.)
  • L’impact du réseau:
    • Toute application connectée sera dépendante du réseau mais devra être capable de fonctionner dans des conditions dégradées
    • La conception technique d’une application mobile implique de gérer une multitude de cas à la marge:
      • J’ai lancé une synchro, qui s’est arrêtée en route...
      • Pas de réseau et des infos non à jour, que dois-je afficher ?
      • Connexion en EDGE, comment optimiser l’expérience utilisateur...
      • Je dois afficher une carte, mais je ne capte pas le signal du GPS...
      • Le webservice ne répond pas...
      • Etc.
Tests et recette : rester pragmatique
  • Développements sur simulateurs:
    • Les développements étant réalisés dans des simulateurs et le fonctionnel d’une appli mobile étant souvent découpé en écran/fonction, les premiers tests unitaires peuvent être menés tout au long du projet
    • Certains outils de développements (PhoneGap par exemple) sont ancrés dans une logique très web et permettent également de tester l’application comme une application web classique dans un navigateur, ce qui permet assez rapidement de multiplier les OS (IE -> Windows; Safari -> iOS; Chrome -> Android)
  • Mener une recette sur l’exhaustivité des terminaux est impossible:
    • Les émulateurs ne sont pas forcément une approche valable notamment de part l’absence des fonctionnalités natives, l’absence des aléas réseau et une puissance de calcul non équivalente
    • Des solutions de tests à distance (terminaux physiques mis à dispositions et pilotés à distance) existent mais les contraintes de disponibilité, l’absence d’informations sur les réelles conditions d’usage et le manque de flexibilité n’en font pas une réponse adaptée à la problématique de la recette sur mobiles
    • La seule approche valable reste donc le test de bout-en-bout sur des terminaux grand public:
      • Un pool de terminaux (15 – 20) permet de couvrir une grande majorité du parc
      • L’absence de fonctions trop exotiques limite également les mauvaises surprises
      • Les conditions de tests doivent être le plus proche possible des situations d’usage escomptées:
        • Terminaux non jailbreakés (dévérouillage de l’OS)
        • Niveau du réseau qu’il s’agisse d’une application ayant vocation à être utilisée en extérieur ou dans les transports
        • Prise en compte du soleil pour le design, de l’usage à une main, d’une utilisation en public
  • Quelque soit la solution et le temps passé en recette, il y aura toujours des surprises! Celles-ci seront l’occasion de faire évoluer l’application et de tenir compte des différents retours!
Validation et distribution
  • Validation par les « stores »:
    • Selon les OS, le process de validation est plus ou moins opaque, long, complexe, changeant et incertain
    • Certaines conditions peuvent avoir un impact majeur dès la phase de conception de l’application
    • Sur iOS, process le plus long, il faut compter jusqu’à 3 semaines
  • Anticiper la distribution:
    • Créer les comptes en avance...
    • Trouver un titre, identifier la catégorie, les concurrents directs
    • Préparer les descriptifs (captures d’écran, descriptions)
    • Benchmarker les mots clés et les recherches
  • Référencement et tops:
    • La présence sur les stores ne garantit en rien la visibilité d’une appli, son indexation est donc primordiale
    • Mais les moteurs de recherche des stores sont encore en évolution et les critères restent très opaques, néanmoins, quelques idées :
      • Mentionner des applis complémentaires et populaires
      • Intégrer des mots clefs dans le titre de l’application
      • Eviter les noms trop « conceptuels »
    • Une présence prolongée dans les tops 50 dominés par les jeux et les pure players est globalement inespérable mais connaître les règles reste utile:
      • iOS: règles opaques, basées à priori sur les téléchargements (sur une période donnée) et sur les notes des utilisateurs
      • Android: tout aussi opaque mais prenant en compte le nombre et la qualité des notes, le nombre d’installations ET des désinstallations, les statistiques d’usage, la croissance du nombre de téléchargements et la pérennité de ces volumes
      • Effectuer des mises à jour permet de remonter l’application dans les « nouvelles applications »
Un effort dans la durée...
Screenshot from 2015-04-23 13:16:38
  • Un projet d’application mobile ne s’arrête pas lors du lancement sur les stores. L’ecosystème mobile permet et impose de faire évoluer ses projets:
    • Exposition forte à la critique
    • Evolution constante du paysage
  • Quelle que soit la cible: tenir compte des retours et faire évoluer:
    • Recueillir et suivre les feedbacks des utilisateurs (notamment commentaires sur les stores)
    • Tracker et analyser l’utilisation (construire en amont un plan de tagage)
    • Enrichir, faire évoluer, se remettre en question (veille active des applications concurrentes)
    • Communiquer sur ses mises à jour
  • Veille technologique et suivi des évolutions du paysage:
    • Les applications sont reliées à tout un écosystème (Facebook, Google Maps...) qui évolue constamment
    • Les OS sont aussi régulièrement mis à jour et à chaque fois des tests s’imposent

WebApp

Screenshot from 2015-04-23 13:23:04
Les technologies utilisées
Screenshot from 2015-04-23 13:25:25
  • HTML5
    • Stockage local
      • session storage / local storage
      • base de donnée locale
      • App Cache
    • Web sémantique avec de nouvelles balises: section, article, aside, header, footer, nav...
    • Balises video, audio, canvas...
  • CSS3
    • Effets
    • Transitions
    • Styles poussés sans image
  • JavaScript
    • Cœur de l’application
Les limites
  • Techno non encore standardisée
    Screenshot from 2015-04-23 13:34:52
    • Nécessite un navigateur récent...
    • ... et tous les navigateurs ne réagissent pas encore de la même façon
    • Un paysage évoluant constamment, cf. niveau de compatibilités sur http://caniuse.com/
  • Des adaptations de style à prévoir selon les navigateurs et OS
    • Pour IE et Windows Phone notamment...
  • Mais des « Polyfills » (contournements) sont utilisables
    • Des bibliothèques pour amener le futur dans le passé !
    • En apportant un support partiel ou un mode dégradé des fonctionnalités HTML5 non supportées par des navigateurs anciens
Une solution pour demain ?
Screenshot from 2015-04-23 13:38:46
  • Un exemple: le Financal Times qui a quitté l’appstore (en mettant en place sa webapp accessible depuis le web):
    • Pourquoi fuir l’Appstore
      • 30% de commissions Apple
      • Pas d’accès direct au client (ni à ses données)
    • Est-ce efficace ?
      • Deux millions d’utilisateurs
      • 12% des abonnement payants,
      • 19% du trafic
      • 1⁄2 des utilisateurs ont ajouté l’icône au bureau
  • L’option webapp et donc la sortie du business model des stores permet :
    • D’éviter la « taxation » en cas de monétisation de contenus
    • D’offrir des contenus plus évolutifs sans avoir à passer par des mises à jour
    • Une compatibilité théorique avec tous les OS
  • Pour demain:
    • Logique de client « léger local » moderne et particulièrement adaptée
    • Des fonctionnalités nouvelles tous les jours... bientôt l’accès aux API natives (Projet WebApi de Mozilla)
  • Mais:
    • Des performances encore inférieures à des applications « natives ».