Flash et HTML5, revue de presse

Depuis la sortie de l'iPad et sa non prise en charge de Flash, le web s'enflamme sur l'avenir de notre plugin preferé et les déclarations de Steve Jobs. A ce sujet, quelques articles intéréssants qui ont retenu mon attention :

Bref, pour donner succinctement mon avis, HTML5 n'ayant pas vocation à remplacer Flash mais bien à améliorer l'expérience utilisateur des sites HTML actuels, il ne me semble pas nécessaire d'opposer les deux technologies. En effet Flash gardera ses points forts dans le cadre d'applications riches ou de jeux, et perdra juste un peu plus d'intérêt pour des sites "de contenu" (intérêt déjà quasi nul, hormis pour la vidéo et le choix des polices de caractères). Si HTML5 permet ainsi de restreindre l'utilisation de Flash aux applications qui le nécessitent vraiment, alors ce sera une bonne chose, y compris pour Flash.

Flash et bugs : switch/case et variables de type XML

Bonjour les amis, aujourd'hui un bug tout en subtilité sur lequel je suis tombé hier :

Conditions :

  • Vous êtes à l'intérieur d'une clause switch/case
  • Vous voulez déclarer une variable de type XML ou XMLList et lui affecter une valeur sur une même ligne

Bingo, le contenu de la variable sera null ...

Exemple :

switch(condition)
{	
  case 0:
  var content:XML = xmlListObject.node.(@id == id)[0]; // l'expression renvoie bien un noeud XML
  trace(content); // -> null
  break;

  case 1:
  ...
}

Solution :

Très simple à résoudre, il suffit de déclarer puis affecter la valeur en 2 temps :

switch(condition)
{	
  case 0:
  var content:XML;
  content = xmlListObject.node.(@id == id)[0];
  trace(content);
  break;

  case 1:
  ...
}

Voilà, simple et efficace. Merci à ce billet pour avoir trouvé la solution, à Fred pour avoir trouvé ce billet, et visiblement à Adobe pour avoir corrigé le souci dans la dernière version du player (la page du bug sur Jira est ici).

Flash et bugs : Mozilla, wmode et champs de saisie

J'inaugure aujourd'hui une nouvelle rubrique consacrée aux bugs de Flash (oui ça mérite bien une rubrique à part entière).

Pour commencer, un bug malheureusement assez connu et très ennuyeux, qui perdure depuis Flash 6 et toujours pas vraiment résolu à ce jour : le bug "du wmode". Pour les chanceux qui ne seraient pas encore tombés dessus, voici une démonstration.

Conditions :

  • Vous êtes sur Firefox, Safari ou Opera, sur Windows uniquement
  • Vous n'êtes pas américain et votre clavier n'est pas en configuration qwerty US
  • Vous avez une animation flash avec le paramètre wmode reglé sur "transparent" (pour pouvoir superposer des éléments html)
  • Vous avez un champ de saisie

Si vous réunissez ces conditions, bravo, vous vous rendez compte que vous ne pouvez pas taper le caractère "@", "?" ou bien un chiffre de la rangée haute (les chiffres du pavé numériques fonctionnent). Plutôt gênant par exemple quand vous devez saisir une adresse email.

Solutions possibles :

  • Attendre la saint glinglin qu'Adobe se bouge les fesses (le rapport de bug est ici)
  • Prévenir votre client du souci le plus en amont possible (ne vous inquietez pas, votre client adore entendre ce genre de justification technique)
  • Essayer un des hacks proposés ici, ici, ou encore , principalement à base de javascript à la rescousse.

Pour aller plus loin...

Le souci vient en fait des deux cotés, Adobe et Mozilla, comme on peut le voir dans cette discussion. Voir notamment les messages de Masayuki Nakano pour Mozilla, et Jeff Mott pour Adobe.

En résumé, un correctif vient d'être intégré récemment dans le lecteur Flash pour qu'il supporte correctement les entrées clavier unicode, et on attend maintenant la prochaine release de Firefox pour les corrections coté Mozilla. Je viens de tester avec Firefox 3.5 et ça fonctionne effectivement mais seulement à partir du deuxième caractère saisi (!). Bref, c'est pas encore trop ça mais ils y travaillent. À suivre donc...

Le futur de Flash : Javascript

Pour promouvoir leur moteur Javascript ultra performant, l'equipe de Google Chrome a rassemblé un bon nombre de démos techniques sur ce site : Chrome Experiments.

Certaines sont vraiment impressionantes, ceux qui pensaient que Javascript ne servait qu'a ouvrir des popups vont être surpris (évidemment pour en profiter munissez-vous d'un navigateur à la pointe : Chrome, Safari 3+, Firefox 3.1, ... oubliez IE)

Alors après avoir vu tout ça, Flash a t'il encore sa raison d'être ? Faut-il laisser tomber Actionscript et rejoindre Javascript et ses potes Ajax et jQuery ? De mon point de vue, Flash possède encore quelques atouts incontournables... pour le moment :

L'audio et la vidéo

Les nouvelles balises audio et video, prévues par HTML5, arrivent au loin et sont actuellement supportées par Safari 3, Chrome et Firefox 3.1. Mais comme d'habitude, leur démocratisation ne pourra se faire sans leur prise en charge par Internet Explorer... encore un peu de patience donc mais pouvoir intégrer une vidéo dans une page aussi simplement qu'une image reste un vrai besoin à l'heure actuelle.

Les animations vectorielles

Flash propose un outil puissant et complet pour créer des animations vectorielles, et surtout avec une interface accessible aux non-développeurs. Coté HTML, l'element Canvas, introduit par Apple dans Safari, puis repris par Firefox et Opera, permet de dessiner via une API 2D, mais aucun outil WYSIWYG équivalent à Flash avec sa timeline et ses images clés n'existe encore, les animations doivent être codées, donc réservées aux développeurs.

La typographie

Pouvoir utiliser n'importe quelle police sur le web reste un des gros points forts de Flash, et coté CSS c'est pas encore ça pour le moment... Outre le problème des droits de diffusion sur les polices, la technique des polices téléchargables arrive timidement et seuls Safari et Firefox 3.1 la supporte actuellement. La propriété font-face est néanmoins prévue dans CSS3 mais comme pour la video, seul un support par IE permettra véritablement son usage.

De ce coté donc, les techniques telles que sIFR ont encore quelques jours devant elles...

3D isométrique et pathfinding

Voici quelques temps que je voulais me mettre au développement de jeux en Flash, je me suis donc confronté récemment à la réalisation d'un moteur 3D isométrique. Je me suis notamment intéressé à la génération et au positionnement des "tiles" et des différents objets de la carte, ainsi qu'à la gestion du pathfinding, c'est à dire le déplacement des objets sur la carte en tenant compte des obstacles.

Lire la suite...

Se passer de maquette Photoshop?

J'aime bien 37 signals, et j'aime assez souvent leur prises de position assez radicales sur la manière de travailler un site web. Dans cet article en l'occurrence, ils expliquent qu'ils se passent totalement de maquette Photoshop lorsqu'ils designent une interface, et passent directement du crayon et de la feuille de papier au prototype HTML/CSS.

En fait je suis assez d'accord avec eux, même si leur billet peut laisser croire que le prototype HTML/CSS peut remplacer totalement l'étape Photoshop/Illustrator/... (entourez votre logiciel préféré). Ce sont à mon avis deux étapes différentes, et qui ont deux buts bien différents.

Effectivement aujourd'hui, la maquette Photoshop est bien mal utilisée. Elle sert malheureusement de référence et d'étape de validation pour des chose qu'elle ne peut pourtant pas ou mal montrer :

  • Le zoning, la taille et le placement des blocs, qui sont souvent fastidieux à modifier sur Photoshop, on perd beaucoup de temps à chaque itération (et le designer s'énerve...)
  • Quid de l'interaction ? Comment voir le comportement d'un lien au survol ? L'apparition d'un bloc AJAX ? Ce sont pourtant des éléments clés d'un design interactif.
  • A la différence d'un travail print, le design interactif doit également prendre en compte les comportements. Par exemple le comportement d'une page lorsqu'on agrandit le texte FAIT parti de la démarche design, et Photoshop ne le montre pas non plus.
  • Enfin la déclinaison de toutes les maquettes d'un site est également une étape extrêmement fastidieuse et peu valorisante. Voir 50 images jpeg avec le même site et le contenu central qui change n'a absolument aucun intérêt. Cette déclinaison pourra se faire bien plus rapidement en HTML ensuite.

Pour tout ça, un prototype HTML/CSS est un document de travail extrêmement souple pour affiner des problématique de zoning, de placement et de taille de blocs, bien plus que Photoshop. Déplacer un bloc en HTML/CSS prend environ 5 secondes, et le résultat est montrable immédiatement. Modifier un texte idem, etc...

En revanche, une maquette Photoshop pourra clairement permettre de travailler la charte graphique globale. Mais il ne sert à rien d'y consacrer trop de temps au calage au pixel près ou à au positionnement des blocs entre eux, c'est simplement long, fastidieux et inutile. Bref, amis Photoshopeurs, arrêtez de passer des heures sur des détails sans importances et concentrez-vous sur votre coeur de métier : la création graphique.

Maintenant, se passer de Photoshop conduit à mon avis à un excès inverse, c'est à dire que le code CSS se met à conduire l'ensemble de la charte graphique. Dans cette démarche, on aboutit souvent à une "pauvreté" graphique et on se surprend à faire des choix graphiques non plus en fonction d'un concept créatif mais d'un simplicité à produire tel effet en CSS rapidement. C'est sûrement quelque chose qui peut convenir à 37 Signals, qui ont des designs très "dépouillés", mais sûrement pas applicables à tous.

Bref pour résumer :

  • Un prototype HTML/CSS pour valider les placements, les tailles, l'interaction et d'une manière générale ce qu'on peut appeler "l'expérience utilisateur".
  • Une maquette Photoshop pour la charte graphique, les illustrations, le travail sur les couleurs, etc...

Et à chaque outil sa fonction :)

Conventions de codage pour AS3

Depuis que notre meilleur ami Adobe se met à l'Open Source, ça rigole plus. Voici donc une page très intéressante qui regroupe tout un tas de conventions et bonnes pratique pour coder en Actionscript 3. A lire bien attentivement et à garder sous le coude ensuite pour tout développeur digne de ce nom :)

EDIT : Comme le précise Tek dans les commentaires, il s'agit de conventions spécifiques pour le SDK Flex, mais qui peuvent vous inspirer comme "bonnes pratiques" dans vos projets.

Nouveau site, nouveau métier...

Hop, un nouveau site tout beau, un nouveau thème tout neuf, et un nouveau métier puisque à partir du 29 mars je commence une nouvelle carrière en freelance :)

Donc n'hésitez pas à me contacter si vous recherchez un développeur Flash (ou Flex) AS2/AS3 qui n'aime pas le code spaghetti, ou un concepteur html/css qui n'aime pas la tag soup :)

- page 1 de 6