Adobe Max 2009 – Jour 3

Troisième et dernier jour de conférences à l’édition 2009 de l’Adobe Max.

From Sketch to Click-Through HTML Prototype with Fireworks

Enfin une session sur le protoypage avec Fireworks avec Dave Hogue de l’agence Fluid :

  • Il est tout à fait possible de se servir de Fireworks pour créer des prototypes et les tester avec des utilisateurs ;
  • Tout commence avec des croquis qui sont importés dans l’outil (Fireworks CS4) ;

    Première étape du prototypage
    Première étape du prototypage
  • La Master Page est utile pour “poser” les éléments immuables (header, nav…) ;
  • La grille et les règles permettent de structurer les pages ;

    Deuxième étape
    Deuxième étape
  • Des éléments sont ensuite superposés sur le croquis ;
    Troisième étape
    Troisième étape

    Quatrième étape
    Quatrième étape
  • Les outils “Slices” et “Hotspots” servent à rajouter de l’interactivité ;
  • Possibilité d’encapsuler du code HTML (pour une carte Google Maps par exemple) ;

    Encapsulation d'éléments HTML dans la maquette
    Encapsulation d'éléments HTML dans la maquette
  • La dernière étape est l’export en HTML mais cela génère un code source de très mauvaise qualité (suffisant pour faire des tests avec des utilisateurs mais inacceptables en production) ;
  • Il y a également la possibilité d’exporter ce travail dans Dreamwaver (pour retravailler le code source) ou Flash Catalyst (pour en faire une RIA).

Une session intéressante mais qui n’a pas réellement mis en valeur les synergies possibles entre les outils de la gamme pour faire du prototypage rapide ET réutilisable. Car il faut bien admettre que tout ce qu’il a montré peut être fait dans Powerpoint, avec en plus la très précieuse possibilité de faire des tableaux (ce que ne permet pas Fireworks).

Augmented Reality within the Flash Player

Enfin une session qui aborde le potentiel (et les contraintes) de la réalité augmentée dans Flash avec Jesse Freeman :

  • FLARToolkit est une librairie open source qui gère l’affichage de contenus 3D en surimpression d’un flux vidéo de la webcam ;
  • Retour d’expérience sur des expérimentations pour la Nasa et la mission Juno ;

    Exemple d'application de réalité augmentée à la NASA
    Exemple d'application de réalité augmentée à la NASA
  • L’intérêt n’est plus d’afficher du contenu 3D en réalité augmentée mais de faire interagir différents contenus (selon la position des marqueurs) ;
  • Problème = autoriser l’accès à la webcam à chaque fois ;
  • Il existe un émulateur pour gagner du temps et faciliter le debugging ;
  • Le Virtual Physical Computing est un domaine d’application prometteur = manipulation d’objets et de contenus 3D sans clavier ni souris ;
  • Les limitations de FLAR = très gourmand en CPU, pas de gestion native de la 3D dans Flash (nécessite des librairies 3D comme Papervision3D ou Away3D, le flux vidéo de la webcam est plutôt lent) ;
  • Les évolutions = utilisation d’Alchemy pour mieux exploiter les capacités hardware, support 3D natif et plus performant, réalité augmentée en dehors de Flash (smartphones…).

Vient ensuite au micro James Aliban pour des retours d’expériences plus expérimentales / créatives :

  • Utilisations plus artistiques avec de la gestion des particules (AR Particle Bean) ou des expérimentations musicales (Augmented Reality Drum Kit) ;

    Réalité augmentée et gestino des particules
    Réalité augmentée et gestion des particules
  • Implémentation facilitée avec FLARManager ;
  • Une communauté existe depuis l’année dernière (FLARToolkitDocs.org) ;
  • Très intéressante expérimentation avec les cartes de visite augmentées ;
  • Il existe de nombreuses applications commerciales (GE, BMW, Nissan, Toyota, Ikea…) ;
  • Autres exemples = 5Gum, Living Sasquatch, Julian Perretta’s “Ride My Star”… ;
  • Flash est clairement un facteur limitatif car il utilise le processeur pour faire le rendu 3D et non la carte 3D (600 polygones maximum pour limiter l’effet stroboscope, lié au faible taux de rafraichissement en cas de mouvements du modèle 3D ou de la webcam) ;
  • Entre 20% et 25% des ordinateurs domestiques sont équipés d’une webcam ;
  • La prise en main est délicate pour les concepteurs et développeurs d’applications car l’image est inversée (vue depuis la webcam).

Wow ! Non seulement nous n’en sommes qu’au début de cette nouvelle forme d’expression mais en plus la communauté est très active (de nombreuses choses sont disponibles en open source).

Building Browser-Based Casual MMOs

Campfu, un casual MMO qui n'existe plus
Campfu, un casual MMO qui n'existe plus

Encore une session très prometteuse avec l’intervention de Nick Fortugno concepteur en chef chez Rebel Monkey qui nous propose son retour d’expérience sur Campfu, un casual MMO qui n’existe malheureusement plus :

  • Le projet a nécessité 18 mois de développement et 2M$ d’investissements (le site n’a été en ligne pour 6 mois) ;
  • Pas besoin d’avoir de très beau graphismes comme Runescape (ex : Kingdom of Loathing qui est quasi-textuel) ;
  • La notion d’engagement est clé car la grosse majorité des causal MMO sont gratuits ;
  • Le fait de ne pas avoir à télécharger ou installer quelque chose est un levier concurrentiel très puissant (vis à vis des MMORPG traditionnels) Puzzle Pirates a commencé en version téléchargeable et est maintenant accessible en ligne ;
  • Les plus grosses difficultés techniques sont du côté du serveur (il existe des solutions middleware comme SmartFoxServer, ElectroServer ou Project Darkstar) ;
  • Avec une solution middleware comme SmartFoxServer, le temps de développement peut être réduit à 1 mois (mais cela induit de fortes limitations en terme d’évolutivité et de montée en charge) ;
  • Les difficulté auxquelles il faut faire face = sécurité (qui a un impact direct sur les performances), disponibilité, stabilité (surtout pour du code interprété), intégrité (via à vis des possibilité de hacking de la partie “client”) ;
  • Les jeux en temps réel sont un vrai défi technologique, voilà pourquoi il est très sceptique vis à vis des solutions de cloud gaming comme OnLive ;
  • Les outils d’automation (débug…) permettent de gagner beaucoup de temps lors de la phase de développement ;
  • La phase de beta est indispensable car de toute façon il y aura des bugs majeurs (quelque soit le temps de préparation et de conception) ;
  • La visibilité est clé dès le début du projet car il faut impérativement recruter très vite un grand nombre de testeurs ;
  • Les revenus générés par la publicité ne deviennent significatifs qu’avec plusieurs millions de joueurs ;
  • Les modèles économiques fondés sur l’abonnement sont particulièrement adaptés pour la cible des plus jeunes (Tween) ;
  • La vente d’items virtuels est intéressant mais demande de gros efforts de surveillance (pou éviter la fraude ou les trafics parallèles) ;
  • Tout comme pour les sites web et boutiques en ligne, les solutions de surveillance des échanges comme celle de TwoFish sont indispensables pour comprendre les flux économiques et éviter les déséquilibres (il est tout à fait possible de faire de l’A/B testing sur le prix de vente d’accessoires virtuels).

Voici une session extrêmement riche en enseignements et surtout un discours qui n’était pas que technique mais qui abordait aussi les problématiques organisationnelles et business.

2 commentaires sur “Adobe Max 2009 – Jour 3

    1. @ bab > Il me semble que c'est à cause d'un manque de liquidités, ils n'ont visiblement pas trouvé leur audience à temps.

      /Fred

Les commentaires sont fermés.