L’actualité autour d’Apollo est assez riche en ce moment. Voici donc quelques news :

Apollo Camp

Les équipes d’Adobe ont décidé d’organiser un premier événement Apollo le 16 mars à San Francisco : ApolloCamp. Une « longue » soirée, avec au programme :

• Présentation d’Apollo
• Votre première application Apollo avec Flex
• Utiliser le HTML avec Apollo
• Des exemples : yourminis, eBay
• Utiliser l’API File d’Apollo
• Etc.

Pour les américains, désolé mais l'Apollo Camp est déjà complet... les places sont très vite parties.

Le programme est donc très technique, et s’adresse avant tout aux développeurs qui veulent avoir une avant-première ! En effet, la date de sortie d’une version alpha sur le Labs d’Adobe n’est pas encore à l’ordre du jour. Néanmoins...

Apollo pocketguide annoncé !

Néanmoins un premier livre sur Apollo est annoncé : Apollo for Adobe Flex Developers pocket guide ! On peut donc supposer la date de sortie du livre en même temps qu’une première version publique.

Disponible en anglais aux éditions O’Reilly, apparemment fin mars, ce livre va traiter notamment des nouveautés d’Apollo :

• Les fichiers
• L’HTML
• Un mini cookbook

Pour 10$ donc, il est disponible sur Amazon. Pas vraiment un guide de référence, il s’agit ici d’un premier ouvrage pour lancer les premiers développements sur Apollo et ce sans attendre une documentation « finale ».

Apollo changera de nom !

Difficile à croire vu qu’Apollo est le nom officiel de l’environnement d’exécution d’Adobe depuis maintenant au moins un an. Néanmoins, Apollo ne sera pas le nom définitif ! C’est ce que révèle Mike Chambers au sein de la mailing list apollocoders et sur son blog. Les raisons ? Peut-être un problème de droit... il n’y a pas vraiment eu de déclaration officielle.

Tout de monde peut chercher le nouveau nom, mais la vraie question demeure plutôt : est-ce une bonne affaire de changer de nom quelques mois avant une première sortie publique ? Depuis quelques mois maintenant, Adobe s’efforce à faire parler de son environnement en multipliant les présences en conférence ou en présentant des démonstrations. Ce retournement pourra t’il porter préjudice au travail déjà effectué ? Espérons juste que le nouveau nom sera à la hauteur.

Certains le connaissent surement déjà mais je ne peux résister à vous présenter Web Design From Scratch. En effet, ce site réalisé par Ben Hunt est une mine d’informations pour tout développeur web. Au programme :

• Des catégories variées comme les bases, l’architecture de l’information, l’accessibilité, le design graphique, etc.
• Des exemples concrets, bien illustrés (heureusement pour un site de design)
• Des guides, comme celui réservé au Web 2.0
• Des études de cas
• Et surtout des conseils avisés

Quelques extraits (en VO) :

"Everything that goes into your web site must have a purpose. Every single element and decision must help users achieve their goals and support the site's goals."

"Use as few features as are necessary to achieve what you need to achieve."

"Friends trust each other. If a site is going to be friendly, it's good to trust the user."

Chaque chapitre est illustré d'exemples de sites variés

Je n’ai pas encore eu le temps de tout lire mais pour avoir parcouru ce site quelques heures, j’en fais un guide de référence dans le domaine du design web. Et j’espère en faire bonne utilisation très prochainement !

Voilà une pure tuerie que j'ai découvert récemment via RIApedia : Tour Tracker 2.0.

Il s'agit là d'une application riche permettant de suivre une course cycliste américaine (vous pouvez faire un comparatif avec le Tour de France) : l'Amgen Tour of California. L'application a été réalisée avec la technologie Flex par les équipes d'Adobe.


Au niveau des fonctionnalités, on retrouve notamment :

• La Yahoo map du tracé des étapes, avec zoom, point pour les cols, etc.
• Le profil de l'étape
• Des statistiques
• Les commentaires en direct
• La vidéo de la course en direct (!)
• Les images du jour postées et récupérées via Flickr

Que dire donc si ce n'est que c'est une application riche très complète que nous offre là les équipes d'Adobe. Je suis impressionné de la bonne utilisation de tous les éléments (on a tout de même droit à un mash-up Yahoo maps, flickr, avec vidéo, son et graphiques !) car on ne s'y perd pas et la prise en main est très facile. Coup de chapeau, surtout lorsque l'on sait que l'application à demandé 4 semaines de développement. On se rend alors bien compte des nombreux avantages que procurent une technologie riche comme Flex.

Dernièrement apparraissent de plus en plus d'applications riches de qualité, notamment autour de Flex. Serait-ce un signe de maturité de cette technologie ? En tout cas, 2007 s'annonce réellement comme l'année des applications riches.

L’année 2006 a été celle de l’explosion des services Web à la sauce 2.0. Et pourtant je me rends compte que pour écrire des articles sur ce blog, j’ai une méthode assez veillotte. Jugez vous-même :

1. Tout d’abord, je cherche une idée. Et parfois, elles arrivent ! Soit en surfant, soit en réfléchissant (oui, ça m’arrive) sur des sujets qui m’intéresse. Ce n’est pas vraiment ce qui me manque : j’écris peut-être un peu moins qu’auparavant mais j’ai toujours beaucoup de sujets sous la main, mais un peu moins de temps à y consacrer.
2. Ensuite vient la partie certainement la plus intéressante mais également la plus longue (la plupart du temps) : celle de la recherche d’informations. Dans le cas d’une veille comme sur les microformats, je passe quelques heures à m’informer, à laisser dans un coin de ma tête les choses intéressantes, l’intérêt, etc. Dans le cas d’une application riche, je teste, je compare, je creuse, etc.
3. Vient la phase de prise de notes. Et là je la joue vieux jeu : je prends mon carnet (déjà bien rempli) et je dresse une sorte de mini-plan de l’article que je souhaite écrire. Surtout pas de phrases, que des notes : au maximum deux pages sur un carnet à spirale format moitié d’A4. J’apprécie énormément ce passage au stylo et au papier : cela m’éloigne de l’ordinateur, me permet de mettre un peu mes idées à plat et surtout d’écrire où je veux : dans le métro, au bureau, bref quand je le veux. C’est souvent mal écrit, avec beaucoup d’abréviations et de rayures, mais c’est pour moi un outil quasiment indispensable !
4. Il n’y a plus qu’à rédiger ! En m’appuyant sur mon mini-plan, je rédige mon article d’une façon assez parallèle : d’un coté j’avance dans mon plan en rédigeant les phrases qui me viennent, et de l’autre je vérifie mes informations sur Internet, en reprenant la plupart du temps les sources que j’avais déjà parcourues lors de la phase 2. J’y recherche également mes images pour illustrer le contenu : cette partie prend du temps même si je commence à trouver quelques astuces et automatismes qui m’aident à ne pas trop y perdre de temps. Je rédige mes articles directement dans DotClear via le plugin FCKEditor. D’un coté il est assez pratique car c’est un éditeur WYSIWYG (what you see is what you get) donc qui offre un gain de temps. De l’autre, dès que je fouille un peu le code, j’y vois un gros bordel quand on fait un minimum de retouches de mise en forme comme c’est mon cas.
5. Enfin, la phase de relecture. C’est la partie qui me permet de vérifier la cohérence de mes propos et surtout les fautes d’orthographe. Je me laisse parfois quelques heures avant de relire un article pour être certain d’avoir assez de recul vis-à-vis de ce que je veux exprimer. Mais je dois avouer, c’est la phase que je saute le plus souvent. J’ai la mauvaise habitude de ne pas relire ce que je fais et j’espère que ça n’est pas préjudiciable.

Rien ne vaut le carnet et le stylo...

Alors maintenant, comment améliorer la rédaction d’articles sur un blog ? Vous avez des astuces, des conseils, des bonnes pratiques ?

• Personnellement j’apprécie énormément mon petit carnet qui me permet une vraie réflexion que je n’obtiendrais pas via l’ordinateur. Ca fait vieux jeu, mais ça marche : j’emporte très souvent ce carnet avec moi.

• Je suis peu satisfait de l’outil de mise en page FCKEditor que j’ai ajouté en plugin à DotClear. Je gagne du temps mais j’ai peur de perdre en « qualité de code », ce qui me gêne assez. Mais tout taper à la main demande vraiment trop de temps. Vous autres utilisateurs de DotClear, vous faites comment ?

• Je pense peut-être utiliser Google NoteBook pour gagner du temps : lors de la phase 2, je remplis mon notebook avec les liens et phrases les plus intéressantes. Je n’ai pas à repasser par cette phase de recherche lors de la phase 4 qui peut paraître redondante. J’ai été séduit par l’outil de Google mais n’ai pas encore les automatismes pour l’utiliser à bon escient. Cela pourrait permettre un gain de temps et un moyen simple de concision. A tester !

D’autres conseils ? Quand se relire ? Où noter toutes les idées qui nous passent par la tête genre « oh oui il faut que je blog sur ce sujet ! » et qu’on oublie dix minutes après ? Comment mettre en forme de façon efficace et propre ? Beaucoup de questions qui m’aideraient bien si j’y trouvais des réponses... Je compte sur vous !