Protoshare et prototypage

Par Élie Sloïm, le 30 décembre 2010, dans .

Notre activité nous amène à produire beaucoup de wireframes (maquettes semi-fonctionnelles, story-boards). Jusqu’à présent, nous utilisions essentiellement le papier, Powerpoint ou Keynote pour produire nos maquettes (les gentils lecteurs sont priés de ne pas nous jeter des pierres). Le développement d’Opquast reporting et plus généralement du framework Opquast nous amène à passer un temps fou sur cette activité de prototypage. Il fallait donc sérieusement penser à industrialiser. Suite à la lecture d’un premier billet de Korben (mon idole) puis d’un autre billet par mon ami Jean-Marc Hardy, j’ai choisi de travailler quelques jours avec Mockflow. C’est très bon, Mockflow. Vraiment. Mais il me manquait vraiment des aspects fonctionnels avancés, avec notamment la possibilité de naviguer ou de faire rapidement et facilement des effets costauds, et là, tel Zorro, Aurélien Levy est arrivé et m’a proposé Protoshare.

Je l’utilise à fond depuis une bonne semaine, et je vais vous lister rapidement quelques fonctionnalités qui m’ont littéralement scotché. Certaines sont présentes dans d’autres outils (export, spécifications, partage en ligne), d’autres pas, en tous cas pas à ma connaissance.

Fonctionnalités de Protoshare

  • Templates hiérarchisés : je crée tout d’abord un template pour tous mes écrans et je relie des templates enfants à ce template parent. Cela me permet d’avoir par exemple un morceau d’en-tête (header) commun à toute l’architecture et un autre morceau présent uniquement dans certaines parties. Les templates enfants reprennent les templates parents, bien sûr.
  • Elements dynamiques : je crée tout d’abord un plan du site (une architecture), et je peux ensuite ajouter des menus navigables qui vont tenir compte de mon architecture. Si je modifie l’architecture, les menus se modifient automatiquement.
  • Comportements : si vous voulez créer une fenêtre modale, pas de souci, il est possible de faire des règles assez rusées à partir de systèmes d’états (states). Si je clique sur tel objet, tel autre objet s’affiche.
  • Bibliothèques de templates, d’images, de patterns (clippings) : tout est industrialisable, mutualisable, stockable. Vous faites vos objets, vous les utilisez directement dans vos écrans ou vous les détachez pour les personnaliser dans vos écrans.
  • Objets HTML avancés : vous pouvez mettre des conteneurs HTML dans vos écrans. Par exemple, l’outil ne contient pas d’objet fieldset. Mais vous pouvez en créer un au format HTML et le mettre dans vos pages.
  • Designs et wireframes alternatifs : chaque écran peut faire l’objet de designs ou de zonages alternatifs, sachant que cela est à mettre en regard de la fonctionnalité qui suit.
  • Commentaires et annotations : je n’ai pas encore vraiment testé, mais il est possible d’annoter les designs et d’échanger directement sur les objets.
  • Export HTML utilisable directement : je choisis d’exporter mon projet au format HTML, et je peux littéralement naviguer sur le site. Il est alors possible de faire du vrai test utilisateur. En poussant le principe un peu plus loin, on pourrait même imaginer de créer un vrai site statique à partir de l’outil 🙂

En conclusion

Seuls points faibles : je trouve les bibliothèques un peu légères pour l’instant et à moins de travailler avec un écran de wattmille pouces, l’espace de travail est un peu limité.

Les créateurs proposent de très bons tutoriels. Information importante : il est obligatoire de donner un N° de carte bleue à l’ouverture du compte. Je l’ai fait à reculons, mais je ne l’ai pas regretté.

Attention, je suis quelquefois exagérément enthousiaste, je me réserve le droit de dire n’importe quoi et celui de dire dans un mois ou dans deux ans que Protoshare, c’est tout moisi et que j’utilise un autre service ou logiciel. En attendant, que le nom d’Aurélien Levy soit loué (voire vendu) à travers les âges, qu’il soit béni pour douze générations et que ses brebis ne manquent jamais de lait.

P.S. : nous avons également testé Mockflow, Axure, Pencil, Balsamiq, Pidoco, et le célèbre et jamais en panne kit crayon de papier + gomme. Le seul qui nous a semblé également couvrir nos besoins fonctionnels est Axure mais qui nous a paru plus complexe d’utilisation et surtout plus cher.

14 commentaire(s)

  1. Par biou, le 30 décembre 2010 à 10 h 48 min :

    Attention le lien balsamiq pointe sur le site de pencil.

    Est-ce que tous ces outils font bien la même chose ? protoshare annonce la possibilité de faire des maquettes haute fidélité, alors que d’autres revendiquent la basse fidélité. Il ne faut pas que l’utilisateur mélange la maquette avec une version initiale du produit.

    Un problème que j’avais vu avec Axure était qu’on pouvait implémenter si on le souhaitait du comportement dynamique dans les maquettes. Pour moi c’est une erreur ou une perte de temps de faire ceci à l’étape du maquettage. S’il est bon d’avoir de bonnes maquettes et de solides spécifications, il faut probablement éviter la surqualité, et laisser un degré d’interprétation aux développeurs par la suite.

    Enfin tu parles de test utilisateur sur des maquettes, le terme est peut-être un peu extrême. On ne peut pas faire de réel test utilisateur sur des maquettes, même s’il est utile de leur montrer et de recueillir leurs impressions.

    En tout cas, content de voir que de nouveaux outils émergent et qu’il existe une alternative à Axure.

  2. Par Andrea at ProtoShare, le 30 décembre 2010 à 23 h 43 min :

    Elijah,

    Thank you for your review of ProtoShare! Granted, you mention that your enthusiasm may be due to the fact that it is a new and shiny application for you. 🙂 I will say that we always take in customer feedback and are continually updating ProtoShare to help teams during the wireframing and prototyping stages.

    In fact, we are finishing up development and testing of a new version of ProtoShare to be released at the end of January / start of February. Your workspace will then be easier to work with – and have more room.

    To address @biou above, teams can start by creating simple, gray-box wireframes (on the low-fidelity side) and evolve them into more complex, high-fidelity wireframes and prototypes, as the need arises.

    Be sure to contact our Support team if you have any questions or suggestions. Good luck with your projects!

    Best,
    Andrea
    @ProtoShare

  3. Par Christophe C, le 31 décembre 2010 à 11 h 18 min :

    Je ne connaissais pas Protoshare : merci de ce compte rendu ! Nous avions fait également notre petite recherche pour tenter d’éviter le coûteux mais néanmoins très bon Axure : http://www.neoma-interactive.com/20

    Aujourd’hui nous utilisons alternativement iPlotz et LovelyCharts, chacun ayant des points forts et des inconvénients.
    Sinon, nous utilisons quotidiennement tableau-blanc + feutres 😉

  4. Par Elie, le 31 décembre 2010 à 11 h 25 min :

    @biou : tu dis “il faut probablement éviter la surqualité, et laisser un degré d’interprétation aux développeurs par la suite.” Hé bien j’ai beau chercher, mais je ne vois aucune raison de confier aux développeurs le soin d’interpréter des maquettes au niveau des comportements. A de très rares exceptions près, ils n’ont pas la formation initiale ou continue pour le faire, et souvent ils ne le souhaitent pas. Comme dans le cas de l’intégrateur XHTML/CSS vs le graphiste web, on va encore me dire que tout le monde doit toucher à tout, et évidemment, je ne suis absolument pas d’accord. Les développeurs d’opquast reporting passent leur temps à me demander : comment veux tu que ça se comporte ? J”aimerais vraiment leur éviter ce type de questionnement, tout en les faisant participer à la conception de l’interface.

    Pour moi, la maquette statique est clairement insuffisante. Un prototype de voiture qui ne roule pas c’est joli, un prototype de voiture qui roule, c’est un truc qui permet de tester et de valider le lancement de la production. On ne lance pas de production de voiture sans avoir fait un prototype fonctionnel. Dans le web, pourquoi est-ce que ce serait différent ?

    @andrea : I’ve been quite impressed by protoshare, and it’s been very natural for me to write this first review. I’m using this tool three or four hours a day, and it’s already been improving my efficiency and my prototypes. So thanks a lot, and good luck for the next version.

  5. Par Nathalie, le 31 décembre 2010 à 11 h 41 min :

    Tiens je ne connaissais pas ProtoShare, je vais tester.
    J’utilise Axure (ma boite a acheté la licence, ils ont les moyens… 500$, pas la mort).
    Il faut effectivement quelques jours pour tout appréhender mais quel outil pratique. Ce que fait Axure mais pas encore ProtoShare (si j’ai bien suivi) c’est la génération d’un document Word à partir du prototype. Pas besoin de refaire de zéro, très pratique surtout lorsque le proto commence à être gros. En tout cas, j’ai gagné un temps fou lors de mon projet cette année et j’ai présenté l’outil à un collègue qui l’a également adopté pour réaliser ses maquettes fonctionnelles.
    Je plussoie avec Elie : les développeurs avec lesquels je travaille me le disent tout le temps “on fait ce que la MOA demande”. Ils ne souhaitent pas “deviner” les comportements. Ils peuvent, parfois, relever certaines incohérences, mais ils ne vont pas imaginer les éléments non fournis.

  6. Par Elie, le 31 décembre 2010 à 11 h 49 min :

    @Nathalie : en fait, Protoshare génère également le document word avec le plan du site, des captures d’écran et en option, les spécifications de chaque composant. C’est vraiment comparable à Axure. Moins robuste pour l’instant eu égard au travail en mode saas, mais axure a là un sérieux concurrent.

  7. Par biou, le 31 décembre 2010 à 13 h 30 min :

    @Elie disons qu’il y a déja la question de maquettage vs prototypage. Lorsque le prototypage va trop loin, si par exemple tu commences à mettre en place du comportement ou des règles métier dans ton prototype, ton client ou tes utilisateurs vont commencer à se demander à quoi sert le développement sachant que là c’est quasi terminé. C’est le problème de la maquette haute fidélité dans une moindre mesure. Autre chose, les outils actuels ne permettent pas de réutiliser ces comportements, ces règles métiers, ce plan du site directement dans la phase de développement.
    Dans une approche MDE ( http://en.wikipedia.org/wiki/Model-… ), tout ce qui est spécifié est réutilisable en phase de développement, les modèles sont dits “productifs”, ils peuvent produire du code. Ici ton outil produit du html qui n’est probablement pas réutilisable pour la constitution des templates de l’application.
    En résumé, je préfère les maquettes basse fidélité pour ces deux raisons : le prototype est “perdu” on ne peut le réutiliser comme une base pour le développement, et le client ou les utilisateurs ne comprennent pas pourquoi on doit perdre du temps à tout redévelopper alors que le prototype existe et a l’air fonctionnel.

    D’autre part, je suis assez fan des idées agiles. C’est probablement un tort, et c’est probablement aussi incompatible avec l’industrialisation si j’ai bien compris ce que tu dis (ah non on me dit dans l’oreillette que tu as publié un article sur l’accessibilité agile). En mode agile, on nous recommande de privilégier la communication sur la documentation. Pour moi, ici il est possible de communiquer dans l’équipe, entre le développeur et la personne en charge du maquettage. C’est ici que je parlais de surqualité, plus précisément de surspécification. Mais je conçois que cela dépend bien entendu des projets, tout le monde ne souhaite pas travailler en agile, etc.

    Mon autre cheval de bataille, c’est la conception centrée utilisateurs (chez Amélie Boucher : http://www.ergolab.net/articles/con… ) Eh bien cette CCU – dont le but est assez similaire à l’agile, c’est-à-dire fournir un produit satisfaisant pleinement les utilisateurs (le client pour l’agile) – nous suggère très fortement de pousser la multidisciplinarité dans le projet. Et c’est là que se situe le gros point d’incompatibilité avec l’industrialisation. Sans multidisciplinarité, pas de CCU, et donc un produit pas forcément optimal au niveau ergonomique. Je ne dis pas que l’industrialisation empêche d’obtenir un produit ergonomique, je dis juste que cela me semble plus complexe et plus aléatoire. Je suis donc pour le décloisonnement des compétences, et je trouve que cette multidisciplinarité favorise grandement les échanges de savoirs. Est-ce que votre développeur sera plus performant s’il comprend le métier qu’il cherche à outiller ? est-ce qu’il sera plus performant s’il a quelques notions d’ergonomie ? est-ce qu’il sera meilleur s’il connait les contraintes liées à l’infrastructure technique qui va héberger l’applicatif ? probablement oui. Alors quand je lis qu’un développeur doit rester à sa place, ou que j’entends que certains développeurs veulent juste qu’on leur dise quoi exécuter, je suis assez triste. Il doit y avoir moyen de concilier multidisciplinarité et industrialisation, non ?

  8. Par Frank Taillandier, le 31 décembre 2010 à 15 h 35 min :

    Entièrement d’accord avec @biou sur la vision multi-disciplinaire et la favorisation de l’échange entre les métiers avec des tests utilisateurs pour donner une ligne directrice au projet.

    Produire des sites à la chaîne où chaque intervenant est cantonné à un poste bien défini pour sortir toujours le même produit à quelques détails prêts non merci.

    Dans l’idéal je préférerais produire du sur-mesure adapté avec des processus de design collaboratif afin de mutualiser les connaissances de chacun.

    Déconnecter l’économie des sciences humaines, on sait où ça mène 😉

  9. Par Elie, le 31 décembre 2010 à 18 h 22 min :

    @biou et Frank : messieurs, vous ne m’aurez pas;-)

    A vous lire, on pourrait penser que l’équation suivante est toujours vraie :
    Industrialisation = sur-spécialisation = pas de multidisciplinarité = perte de créativité.
    Moi, ce que je vois, c’est que l’industrie innove et crée des choses très bien avec des métiers sur-spécialisés.

    Sinon, quand je vois qu’il y a peut-être un projet Web sur 500 qui mobilise un ergonome, je trouve que :

    1 L’économie du Web ferait bien de tenir compte des sciences humaines (pif)
    2 Ca serait bien que les webeux (surtout les développeurs et graphistes) arrêtent de dire, “ouais, ouais, moi je fais de l’ergonomie et de l’UX, ouais, je suis un peu touche-à-tout, tu vois, ouais” sans avoir la moindre formation dans ce domaine (paf).
    3 Bonne année. Bisous (pouf).

  10. Par Frank Taillandier, le 31 décembre 2010 à 19 h 01 min :

    1 Je n’ai pas dit qu’il ne fallait pas une chaîne avec de vrais spécialistes dedans, ni que les moutons à 5 pattes comme chez Temesis c’était la panacée (pim).
    2 J’ai simplement soulevé le fait qu’il ne fallait pas pour autant perdre de vue la spécificité du projet et que ça ne devait surtout pas être une excuse pour compartimenter chacun dans sa spécialité (pam).
    3 Le produit final ne peut pas être réduit à la somme des compétences de chacun (poum).

    Gros poutous 🙂

  11. Par biou, le 3 janvier 2011 à 10 h 47 min :

    Voilà qui fait plaisir à lire ! Tout à fait d’accord avec toi Elie, l’industrialisation n’est pas incompatible avec l’agilité. Il parait que chez Microsoft ils utilisent la méthode SCRUM. Il y a donc très certainement moyen de concilier multidisciplinarité telle que prônée par la CCU et industrialisation, il faudrait juste voir comment mettre tout cela en oeuvre dans un projet web. (si qq’un a des retours d’expérience là-dessus, ça serait sympa )

    Pour ma part je ne suis pas un webeux, donc je veux bien arrêter de dire des choses, mais comme je suis juste un troll de passage pour la nouvelle année, tout ceci n’est probablement pas très important ! 🙂

    bonne année à toi aussi !

  12. Par Andrea at ProtoShare, le 3 mars 2011 à 22 h 33 min :

    Hi all, I just want to follow up on my earlier comment.

    We finished development of our new product and ProtoShare 5 was launched this week: http://www.protoshare.com/5.

    It’s very different from previous versions – fast, streamlined interface, ability to import all assets from other ProtoShare projects, and a few extra pieces. We still offer a 30-day free trial on our website.

    Current customers can contact us at support at protoshare.com to request your account upgrade (no additional costs).

    Thanks!
    Andrea
    @ProtoShare

  13. Par Etienne, le 10 mars 2011 à 14 h 05 min :

    Vous devriez jeter un oeil à Justinmind, moins cher et plus puissant que Axure pour créer des prototypes dynamiques sans programmation, et ensuite les partager sur internet (avec possibilité de commenter directement sur les elements) et même de créer des tests d’utilisateurs puisque Justinmind intègre la plupart des outils de tests (UserZoom, Usabilla, ClickTale, et même Google Analytics).

    http://www.justinmind.com

  14. Par Elie, le 11 mars 2011 à 7 h 41 min :

    @Etienne : j’ai reçu un mail me parlant de Justinmind, peut-être de votre part, mais je n’ai pas eu le temps de tester le produit. Merci en tous cas pour l’information et si certains utilisateurs ont l’occasion de faire une revue de ce service, qu’ils n’hésitent pas à nous faire part de leurs impressions.

Les commentaires sont fermés.