Et oui, plus d’une semaine est passée, il est peut-être temps de faire un petit message pour clôturer cet été passé sur le campus de Microsoft France à développer sur Surface.

Pour faire simple, je dirais que ce fût un été magnifique sur le plan technique mais également humain.

J’ai énormément appris au fil des semaines, découvert des technologies qui m’étaient encore inconnues ou presque mais également perfectionné mes compétences dans le domaine de la création d’applications riches.

Surface oblige le développeur (et tout le reste de l’équipe) à penser différemment, la seule obligation ou presque est l’expérience utilisateur, nous ne sommes pas là pour faire un exploit technique sauf visuellement et cela demande une toute autre expérience que je commence à peine à voir.

Humainement, j’ai surtout appris à travailler dans un groupe composé de membres très différents, tous m’ont apporté d’une façon ou d’une autre quelque chose et je les remercie pour cela.

J’ai conscience que nos contacts en interne n’ont sans doute pas toujours été les meilleurs possibles, c’est normal car nous avons tous nos façons de faire et voir les choses mais au final…c’est cela travailler en groupe !

D’une part les membres du la Surface Academy mais également toutes les personnes qui nous ont entourées de près ou de loin, je ne vais pas les citer une par une, serait trop long mais elles pourront se reconnaitre sans soucis je pense.

Merci à vous tous pour votre apport sur le plan humain, professionnel et technique.

L’été est maintenant fini, retour à la vie « normale ».

Septembre 2009 sera (…est) le premier mois d’existence du nouveau laboratoire Microsoft au sein d’Epitech, John, moi et d’autres étudiants de l’école sommes en train de relancer une structure pour permettre aux étudiants du campus de mieux découvrir cet écosystème qui regorge de bonnes choses (et 2/3 trucs moins bonnes mais comme partout).

Et ensuite ? Et bien…trouver un boulot ! Et oui, au cours de ma quatrième et cinquième année d’étude, je cherche un emploi sur la base de 3 jours par semaine donc si un profil tel que le mien vous intéresse…vous savez où me contacter!

Niels Freier

Xna commence à être reconnue comme une technologie sympathique et pratique pour le développement de jeu, nous dirons amateur car peut-être pas encore assez mature et performante pour concurrencer une production reposant sur un langage natif tel que le C++ mais pour s’initier dans ce domaine si particulier qu’est le jeu vidéo cela reste une bonne porte d’entrée !

La force d’XNA repose en partie sur la puissance de .Net, une architecture composée de briques, de composants qui reliés par un peu de logique permettant d’avoir rapidement et facilement un résultat intéressant, ce n’est pas un moteur de jeu et encore moins un middleware, c’est vraiment un Framework permettant de s’abstraire de nombreuses taches classiques dans le développement multimédia et dans le cas présent sur plusieurs systèmes Microsoft.

Car oui cette technologie fonctionne sur Windows, Xbox360, Zune (malgré le fait qu’il est encore difficile d’en tirer parti en Europe mais prochainement réglé)  et Surface. Bien évidement c’est moins connu face à la difficulté de mettre la main sur cette « plateforme » mais cela reste un atout.

Le terme plateforme n’est peut-être pas le plus adapté car Surface fonctionne sur Vista et propose « seulement » un périphérique d’entrée en plus, encore une fois le terme « seulement » est sans doute un peu léger pour quelque chose offrant du tactile gérant plus de 50 points sans soucis mais l’idée est là.

Partant de ce constat, on peut effectivement dire que faire du XNA sur Surface ne tient pas du défi insurmontable surtout avec l’API du SDK Surface qui fournit vraiment tout le nécessaire pour tirer le maximum de cette nouvelle interface utilisateur.

Cette dernière permet par un simple appel de récupérer une collection de contacts à chaque cycle, ensuite libre au développeur de faire un petit manager permettant de savoir ou sont les nouveaux contacts, ceux en mouvement et pourquoi pas ceux n’existant plus. Une fois cette gestion effectuée, soyons honnête cela ne prend pas plus de quelques lignes, il ne reste plus qu’à trouver un gameplay adapté et c’est vraiment la difficulté au final :

Le reste pour Surface ? Déjà fournis dans le template XNA venant du SDK pouvant se résumer à « étirer » l’écran sur les bords de la Surface, activer la gestion des contacts, quelques événements permettant une bonne intégration de l’application dans l’environnement Surface (comprendre le menu de la table).

L’API fournit également quelques class pratiques pour gérer un ensemble de contact que l’on nomme un manipulator, cela consiste à rassembler un certain nombre de contacts persistants et qui nous informe de certaines choses parmi lesquels on retrouve les rotations, les translations et les changements de dimension.

Pour le reste, on reprend exactement XNA comme on le connait actuellement, seul le périphérique d’entré change et réclame une adaptation du jeu. La création d’un jeu multiplaforme n’est jamais facile car rendre la même expérience de jeu sur un clavier et une manette est difficile, imaginez avec une table tactile !

Il est temps de se poser ce genre de question, comment vont devoir évoluer nos créations multimédias pour coller avec ce type de support, Surface est un début mais l’arrivé de Windows 7 gérant nativement le multi-touch va obliger chacun d’en arriver à cette réflexion très rapidement.

Niels Freier

Voici ce que va faire votre designer industriel dans un projet d’interface, sachant que les designers industriels qui font de l’interface ne courent pas les rues, il va falloir lui laisser un peu de temps et répondre calmement à toutes ses interrogations qui peuvent vous paraître, à vous développeurs, quelque peu étranges, stupides voire dénuées de tout intérêt. Et oui ! n’oubliez pas que nous n’avons pas du tout la même formation, la moindre de vos conversations inter-développeurs ressemble à « gnznekjf kd,dooo lzoi s s» aux oreilles de votre designer.

Un designer c’est avant tout un créatif, c’est pour cela que son travail commencera par (essayer de) booster la créativité de toute l’équipe ; brainstorming, conversations autour de la machine à café avec les différents membres de l’équipe seront donc de rigueur. Au risque de piétiner au passage quelques idées reçues, votre designer ne sera pas là uniquement pour rendre votre projet jouuuliiii tout plein, ne vous étonnez donc pas qu’un beau matin votre designer vienne s’asseoir à coté de vous et vous aide à trouver des solutions à vos problèmes techniques. Notre approche différente du problème pourra vous amener à trouver une nouvelle solution en contournant sans encombre le problème de départ.

Mais à part ça, qu’est ce que ça peut faire un designer ? Ca crobarde¹, ça rough²… Ha ha ha et là c’est vous qui ne comprenez plus rien à mon langage n’est-ce pas ? Mais moi je suis gentille alors je vous explique. Vous nous verrez dessiner pendant des heures de façon plus ou moins soignée selon l’avancement du projet sachant que l’important pour un designer est de faire passer ses idées et de se faire comprendre par l’équipe ou le client au travers du dessin et de quelques mots clés.

¹ Croquis rapide ; ² Esquisse évolué avec mise en couleur

Mais oui nous, designers on vous aidera aussi à mettre en valeur vos projets, leur donner une valeur ajoutée en terme de look, d’ergonomie et d’expérience utilisateur. On apprend à penser un projet pour un utilisateur, on pense à l’usage qui en sera fais pour que le projet réponde au mieux à la demande et aux envies des personnes ciblées. Pendant que vous travaillerez sur la faisabilité et les performances de l’application, votre designer restera focalisé sur son utilisation par l’utilisateur final.

Quand je suis arrivé chez Microsoft, un grand nombre de personne disaient, en parlant de moi : la graphiste. On nous confond bien souvent avec les graphistes mais nous n’avons pas du tout la même formation. Nous, designers n’avons pas les compétences du graphiste et réciproquement, ils n’ont pas les compétences que nous avons. Nous n’intervenons pas au même moment dans le cycle de développement d’une application. Je pense pouvoir dire que nos deux métiers sont complémentaires.

Dans ce fameux cycle de développement votre designer interviendra dès le cahier des charges et jusqu’après la phase de développement. Il vous accompagnera donc, tout au long du projet.

Si cette petite annonce vous a convaincu(e), que vous êtes maintenant persuadé(e) que le designer est le meilleur ami du développeur (ou est ce l’inverse ? :D) et que vous désirez à présent adopter votre propre designer, en échange de bons traitements, vous pouvez me contacter par mail johanna.rowe@yahoo.fr

Johanna Rowe

“Depuis une petite semaine, j’ai pris un peu de temps pour m’amuser avec XNA sur la table Surface, l’API fournis avec le SDK marche tout aussi bien pour WPF que XNA donc de par mes « origines » je me sentais quelque peu….attiré.

Partant du constat que le temps est limité et les ressources tout autant(toujours LE soucis lors de la création multimédia quand on ne sait même pas faire un bonhomme en fil de fer), je suis partie sur une idée de jeu de hockey style arcade, ressemble a un pong sauf que chaque joueur peut bouger son « palet » dans les deux axes et non seulement le long de son mur.

J’ai décoré un peu l’ensemble en bricolant, c’est loin d’être magnifique mais reste une base de travail convenable.

Le jeu est utilisable pour deux joueurs, rien n’empêche techniquement d’en gérer beaucoup plus, juste une question de…pratique, il vous suffit de poser votre main(par exemple point fermé) pour interagir avec le palet et tenter de défendre votre planète, bête mais sympathique !

Petit plus, si on pose un objet sur la table, un café par exemple, le palet va rebondir dessus comme un obstacle (et le joueur se bruler la main si il tape dedans !)

Il reste deux points que je dois améliorer, ajout d’une simulation de l’inertie, un peu frustrant de jouer sans pouvoir donner une force au palet et meilleure détection des collisions pour avoir un rendu plus « réaliste » au niveau des contacts joueur/palet.

Je reste ouvert aux idées d’améliorations possibles :-) »

Niels Freier

Oui aujourd’hui la machine a café de l’étage a été réparée ! Depuis hier nous étions obligé de changer d’étage pour survivre, limite chômage technique !

Le café reste une source de vie pour tout dev…voir toute personne, la perte de productivité fut évidente pendant ces 24h, nous avons du nous soutenir mutuellement en priant chaque heure dans l’espoir de la venu d’un Héro maitrisant la réparation de machine a café.

On pense le séquestrer pour la prochaine fois, on ne va plus prendre de risque maintenant.

Nous avons réussi a recueillir de nombreux témoignage de personne ici, certaines ont même optées pour prendre un RTT aujourd’hui par manque de foi(e pour certains) dans la réparation miraculeuse !

Allez, on retourne prendre un petit cafay !

Niels Freier

Plus une application est facile et naturelle à utiliser, plus elle est difficile à concevoir et à développer. Derrière cette phrase se cache une réalité à laquelle sont confrontés à la fois les développeurs et les utilisateurs. Avoir l’interface la plus simple d’utilisation demande bien souvent beaucoup de temps et de ressources par rapport à ce qui est disponible. Inversement, utiliser une application à l’ergonomie désastreuse demande beaucoup de temps d’apprentissage et de formation ce qui est donc aussi coûteux en terme financier. Tout est donc toujours affaire de compromis entre les utilisateurs et les développeurs ce qui est bien plus souvent représenté par un compromis entre clients et fournisseurs.

Heureusement grâce aux outils fournis par le SDK de Microsoft Surface cette difficulté de développement est grandement atténuée. Le coût de développement d’une application bénéficiant d’une ergonomie naturelle est donc énormément réduit. Reste la difficulté de conception.

Dans le cadre du développement d’une application multi-utilisateurs et multi-touch comme dans Surface, la conception n’est pas beaucoup plus compliquée que dans celle d’une application Windows classique, c’est juste qu’elle est radicalement différente. Les problématiques d’interactions simultanées avec différents utilisateurs sont quasiment inexistantes avec des applications de bureaux standards, mais elles deviennent essentielles dans une application Surface. C’est ce changement qui est le plus difficile à intégrer, et c’est celui que nous avons réussi à surmonter la semaine passée.

Notre secret ?

Il n’y en pas en fait. Nous avons beaucoup échangé entre nous et avec d’autres. Le dialogue, les brainstormings, le côté ludique et amusant de s’imaginer l’application en fonctionnement en simulant les interactions sur une table basse ou un bureau aide à bien concevoir. Cela permet de couvrir tous les scenarii, et donc de poser les bases de l’architecture du logiciel.

Comment bien concevoir une application Surface alors ?

La réponse est : en échangeant beaucoup d’idées avec les autres.

Simple non ?

John Thiriet

“Après être tombé sur ce petit programme (merci a son auteur), je me suis pris d'une soudaine envie d'adapter son code pour WPF et donc dans la foulé pour Surface.
Sa base n'est pas super opti, réclame un peu de boulot encore et surtout ne gère pas le son mais cela reste une base pour découvrir l'émulation de cette vieille et chère console!
Après 2/3h a retoucher un peu le code, explorer un peu le comment l'émulation ce fait (et comment imaginer de futur amélioration), voici un petit screen d'un jeu pong libre de droit (homebrew amateur).
Bien sur on peut imaginer faire tourner bien d'autre roms mais...c'est a la limite de la légalité donc nous n'en parlerons pas!“

Niels Freier

Depuis notre arrivé à Issy-les-Moulineaux nous avions certes de magnifiques bureaux mais notre table Surface avait quant à elle subit quelques déboires pendant le déménagement. Microsoft a pu nous fournir une nouvelle table récemment et après avoir passé une semaine sans, nous étions heureux de pouvoir enfin tester nos applications ailleurs que dans le simulateur. Certains tests se sont bien passés et les applications marchaient comme prévu, d’autres en revanche nous ont obligés à les revoir.

Nous avons passé une bonne partie de ces derniers jours à réfléchir à notre sujet, à l’ergonomie, aux différentes manipulations possibles, à comment rendre tout cela le plus naturel possible pour l’utilisateur. Allant de brainstorming en brainstorming, de test en test, avec l’aide de Dick Lantim nous avons choisis de développer un jeu de cartes pour la table Surface et plus particulièrement un jeu de Poker.

Je pense que le bilan global de cette semaine est positif. Nous avons fait un choix quant à l’application à développer. Nous avons défini l’architecture globale du projet et nous savons que nous allons pouvoir réutiliser les composants que nous avions développés jusqu’alors.

Il ne reste plus qu’un mois maintenant et ça n’est pas le boulot qui va manquer !

John Thiriet

« Ce soir, avant de commencer le week-end en mode « projet de fin d’étude », j’ai voulu regarder d’un peu plus près les capacités 3D de WPF a l’heure actuelle.

Première constatation, le XAML fournis vraiment tout ce qu’il faut pour gérer la 3D facilement, viewport, camera, et de quoi tracer des formes primitives a partir d‘une liste de vertex, tout ce qu’il y a de plus classique donc mais étonnant pour quelque chose ayant pour vocation la description d’interface applicatif donc peu axé 3D par habitude.

Bref, après quelques essais très sympathique mais un peu…vide, 2 cubes qui tournent c’est sympa mais cela manque un peu de complexité, je me suis attaqué a faire un petit loader pour fichier .obj compatible WPF/XAML, face a la simplicité du format obj, après une dizaine de minute, le résultat est plutôt sympa sauf…en terme de chargement de l’application !

Avec un total de 10242 vertices (point dans l’espace 3D) et 20480 face (surface regroupant 3 a 4 vertices) donc un modèle 3D un peu gourmand mais on a vu pire, l’application est vraiment longue a se lancer dans le simulateur L.

Bon d’accord, les calculs sont un peu brut, pas opti et aucun opti graphique non plus ! mais c’est dommage, pour faire de petit truc 3D simpliste, un cube qui tourne, un petit carrousel, c’est top mais il faut pas en demander encore a WPF a ce niveau la, vive XNA ;)”

Niels Freier

Comme tout Microsoft, nous avons emménagé dans les nouveaux locaux d’Issy les Moulineaux. Après avoir sorti deux fois nos badges et pris des ascenseurs ultramodernes (on choisit l’étage et un programme nous dit quel ascenseur emprunter en fonction de la position de chaque ascenseur dans l’immeuble), on accède enfin à nos bureaux, situés dans un immense « open space » dans la pointe centrale du bâtiment.

Derrière le « curtain walling », au loin, le grand œil bleu de Secret Story (merci TF1 pour cette décoration ô combien design) nous regarde.

Grands bureaux blancs (dommage pour les souris optiques) et fauteuils ultra design faits à 54% avec des matériaux recyclés et recyclable à 95%, les fauteuils du designer Niels Diffrient ergonomiques et très développement durable nous ont conquis tous les cinq, dommage qu’à l’unité ils coûtent 660 euros (conversion effectuée à partir du dollar à la date du 16 juillet) !

Ajoutés aux classiques de Microsoft (boissons fraîches et chaudes gratuites) des petits récipients sont remplis de bonbons tous les jours dans le coin « pause café » qui comme chacun le sait est un endroit stratégique dans toute entreprise.

Alors, qui ne rêve pas encore de venir travailler chez Microsoft ?

La table Surface et son kit de développement proposent une gestion native des « tags ». Ces tags sont de petites images autocollantes qui servent d’identifiant pour un objet.

Voici une image représentant un tag :

Ce tag est unique et le kit de développement de surface est capable d’identifier :

• Sa position
• Son orientation
• Ses mouvements

Il est souvent fait l’amalgame, lorsque l’on regarde les vidéos montrant une table Surface, entre des objets qu’on pose et que le système est capable de reconnaître et d’identifier (téléphones, verres, etc.) et les tags collés sous l’objet.

La facilité d’utilisation de ces tags, autant lors de leur mise en place (simple autocollant) que lors du développement, apporte une grande valeur ajoutée lors de la création d’applications. Comme nous le verrons plus tard, écrire du code exploitant ces tags est extrêmement simple !

Avant cela, il nous faut différencier les deux types de tags.

Les byte tags

• Proposent 256 valeurs uniques
• Sont stockés sur un octet
• Sont de taille réduite (~ 2 cm de côté)

Ces tags sont généralement représentés par une valeur hexadécimale (d’ailleurs écrite sur le tag lui-même afin de faciliter son utilisation).

Grâce à leur reconnaissance facilitée, ces tags ont l’avantage de pouvoir être imprimés et le « tracking », consistant à suivre les mouvements de l’objet, est très fiable.

En revanche sa limitation à 256 valeurs uniques réduit ses possibilités d’utilisation.

Les identity tags

• Proposent à peu près 340 * 10³⁶ valeurs uniques
• Sont stockées sur 16 octets
• Taille plus conséquente : ~ 2.5 cm

L’avantage des ID tags est bien sûr de pouvoir leur assigner un identifiant unique suffisant dans les cas.

Malheureusement leur reconnaissance est plus efficace lorsque ceux-ci ne sont pas en mouvement.

Nous verrons dans la prochaine partie comment utiliser ces tags dans nos applications avec l’aide du SDK.

Remy Boyer

Sources images

“« Une approche composant », voila le concept qui m’a absorbé toute la journée.

Car oui nous ne développons pas réellement une application mais une bibliothèque de composant permettant ensuite de rapidement intégrer des fonctionnalités dans des applications diverses.

Cela demande de changer un peu sa façon de penser, en général en qualité de développeur on se dit :

« J’ai besoin de, donc je vais faire comme cela » mais la je me retrouve face a un « Les personnes utilisant mon composant auront sans doute besoin de… ? Comment leur fournir le plus simplement possible »

Dans mon cas, un contrôle de reconnaissance de gestuel permettant de relier une gestuel et une action, par exemple un gribouillage sur une image impliquant sa disparition a l’écran réclame déjà pas mal de boulot en terme de reconnaissance mais au final cela ce révèle pas le plus dur, le plus gros est déjà fait et a pris moins de quelques heures. Mais vient maintenant le « comment mettre cela en place pour un utilisateur lambda  du composant »

Pour prendre le cas le plus complexe sur Surface, un scatterview (John a très bien expliqué son utilité dans un post précédent) affichant de nombreuse image, comment pouvoir faire des gestuels sur chacune des images, sans que celle-ci se déplace mais tout en gardant ce mouvement naturel donné par le scatterview pour ne pas perturber l’utilisateur ?

C’est a mes yeux impossible donc actuellement j’en suis réduis à surveiller les gestuels sur la partie central de l’image et laisser les « contours » utilisables pour les déplacements, zoom,… de celle-ci.

L’ensemble marche pas trop mal mais reste encore à fournir une interface de communication avec le contrôle pouvant être facilement utilisable à grande échelle, à moi les joies des embouteillages d’event et autre petit plaisir ;).

Demain je m’attaque a modifier un peu la reconnaissance pour prendre en compte l’orientation de la table, oui on doit tout prévoir pour être utilisable a 360 dégrée et cela implique quelques modifications dans le calcul de mes vecteurs de direction, on va rendre cela un peu plus dynamique en fonction de l’angle d’approche au niveau du premier point de contact de ma « ligne de reconnaissance », sans doute pas parfait mais j’ai rien de mieux sur lequel me baser.“

Niels Freier

“Contrôle central dans l’API Surface le ScatterView est un conteneur  qui permet d’appliquer des rotations, translations, redimensionnements avec ou sans inertie sur les objets de type ScatterViewItem qu’il contient.  Ce contrôle va  appliquer les transformations les plus appropriées en fonction des manipulations qu’effectuent les utilisateurs sur la Surface.

Prenons cet exemple d’application :

L’image du koala ci-dessus est contenue dans un ScatterViewItem ce qui lui permet donc d’être sensible aux contacts sur la table et d’être transformée par ces derniers. Ainsi si je touche l’image avec un seul doigt vers son milieu cela me permet de déplacer l’image. Mais si je touche l’image dans un de ses coins et que je déplace mon doigt en faisant un arc de cercle l’image tourneras autour de mon doigt en utilisant pour centre de la rotation le centre du contact généré par mon doigt. Cela peut paraître complexe comme processus mais c’est très naturel pour l’utilisateur. Poser deux doigts et les écarter provoque un agrandissement de l’image alors que les rapprocher en provoque un rétrécissement. Toutes ces interactions complexes sont gérée par le ScatterView et n’importe quelle personne ayant eu l’occasion de manipuler la Surface vous le diras, on n’a pas besoin d’apprendre à utiliser ce contrôle, c’est juste naturel.

Il faut bien mettre l’accent sur le mot naturel car il vient au cœur même du concept des NUI (Natural User Interface qui se traduit par interface utilisateur naturelle en français). Lors du développement d’un contrôle ou d’une application Surface ce concept intervient toujours. Un autre article le décrira plus précisément plus tard.”

John Thiriet