Carnet de route : Agile Tour Rennes en images (1/2)

C’était cette année ma première visite à l’Agile Tour Rennes. Venu en renfort du staff Zenika local, je ne présentais aucune session, au contraire de Géry Derbier, animateur d’un atelier l’après-midi. Une journée que l’on pourrait donc qualifier de relax pour moi. J’en ai profité pour prendre pas mal de photos, ça va donc être encore plus “en images” que d’habitude !
Pas d’autre choix que d’arriver la veille : les organisateurs de cet Agile Tour avaient prévu une journée particulièrement dense débutant à 8h30, pas moins !

Lever de rideau

Première conséquence : l’ouverture des portes alors que le soleil n’est pas encore levé !

AT Rennes 2013 : début des festivités (1)

Et pour nous, la nécessité d’arriver encore une demi-heure avant pour nous installer.

AT Rennes 2013 : début des festivités (3)

L’occasion aussi de voir le point central avant l’arrivée de “la horde”. Profitez-en, vous n’allez plus jamais le voir comme ça !

AT Rennes 2013 : début des festivités (2)

Le comité d’organisation ouvre les festivités, c’est l’occasion de saluer cette équipe sympathique et dynamique !

AT Rennes 2013 : accueil (3)

Le programme est dense, aucun doute. Jugez-en !

Programme Agile Tour Rennes 2013

Prélude (Keynote) : Ensemble c’est tout, par Aurelien Morvant

… Où l’on parle de sociocratie. Un petit rappel pour moi, certes, mais Aurélien aborde le sujet de manière intéressante.

Petit rappel historique

Donc, ça commence au Jurassique … euh non, là on est quand même remontés un peu loin !
Avançons dans le temps : les monarchies. Sociales, je ne sais pas, elles semblent plutôt autocratiques. Apparues avant ou après selon les cas, les dictatures revêtent les mêmes habits !
Les démocraties semblent se rapprocher d’un modèle participatif. Oui mais la concertation se fait surtout à l’élection, guère après. Sauf lorsque l’on fait des référendums et encore est-ce fait avec des questions fermées.
Et le monde de l’entreprise, alors ? Celui-ci parait en fait également se caler sur le mode autocratique.

AT Rennes 2013 : Keynote

Comment ça marche ?

Edenburg définit les 4 piliers de la sociocratie comme suit :

  • Le consentement
  • L’élection sans candidat
  • Le double lien
  • Le cercle

Le cercle est la base du dispositif. Il existe aux différents niveaux hiérarchiques.
Le consentement est le mécanisme de décision qui permet d’aller dans une direction sans nécessairement satisfaire tout le monde, mais sans insatisfaire personne, du moins de manière rationnelle. Le consentement, c’est accepter une proposition à laquelle on n’oppose pas d’objection valide (je peux vivre avec…). Au contraire du consensus qui doit satisfaire tout le monde est finit généralement par être vidé de sa substance !
Le double lien, c’est la hiérarchie classique qui descend les décisions, mais un délégué du cercle inférieur qui accompagne ce supérieur hiérarchique pour remonter ce qu’en pense le cercle d’en dessous.

Mais dans la vraie vie ?

Ce dispositif est déjà bien implémenté au sein de milieux associatifs. Il commence à l’être dans des environnements tels que des mairies, des hôpitaux..
Certaines entreprises commencent aussi à mettre en place la sociocratie, du moins dans une certaine mesure.

Entracte : une pause avant de poursuivre la matinée

La matinée est longue. Profitons des pauses, qu’elles soient prévues ou non pour se désaltérer et revoir de vieilles connaissances comme Emilie, c’est toujours un grand plaisir.

AT Rennes 2013 : Pause matinée (1)

Etant venu à Rennes pour soutenir l’équipe Zenika, il m’est difficile de me joindre à une session pour sa durée entière et je dois donc limiter mes choix à certaines salles. En fait, à l’amphithéâtre principale où l’on accède par les derniers gradins.

Acte premier : Comment devenir agile et surtout le rester, par Aurélien Morvant et Sylvie Le Bail

C’est de changement culturel dont nous parlent Aurélien et Sylvie. Mon “keep away” de cette session (que j’ai prise en cours de route) tient sur 5 points :

Le manager devient le garant des valeurs et de la culture

Le changement est quelque chose de paradoxal. C’est à la fois “je veux y aller” et “je ne veux pas y aller”. C’est la manager qui a pour rôle de rassurer en garantissant que certaines choses vont être stables.

Donner du sens

C’est répondre à 3 questions :

  • Pour quoi ?
  • Comment ?
  • Quoi ?

Le “pourquoi” nous amène fatalement au fameux Start with the why de Simon Sinek. Cela se décline pour une organisation en :

  • Vision
  • Valeur
  • Mission
AT Rennes 2013 : Aurélien Morvant (1)

Donner de l’autonomie

Il faut passer à “l’entreprise du pourquoi”. 4 étapes pour y arriver :

  1. La dépendance.
  2. La contre-dépendance. On s’oppose en répondant “non”.
  3. La confrontation avec la réalité : l’indépendance. Mais l’indépendant ne communique pas !
  4. L’interdépendance. Elle implique des relations d’égal à égal avec les autres.

L’autonomie, c’est la capacité à travailler avec les personnes de l’étape 4 !

Nourrir la démarche

Le constat sur l’entreprise d’aujourd’hui n’est pas glorieux:

  • 11% se sentent “engagés” dans l’entreprise.
  • 61% sont désengagés.
  • 28% sont activement désengagés. Ce qui veut dire qu’ils dénigrent l’entreprise !

L’objectif est de récupérer l’énergie des désengagés. Autant dire que cela ne se fait pas tout seul ! On peut agir sur l’environnement, mais on ne peut pas agir sur les motivations, car les motivations sont des facteurs intrinsèques.

Travailler sur les motivations

On retourne vers un vieux modèle, mais qui marche toujours : la pyramide de Maslow.

Pyramide de Maslow

Entracte : faisons une pause déjeuner

Nous sommes arrivés doucement à la pause déjeuner. On fait dans le style “snack”. L’avantage, c’est que l’on n’a pas de longues queues pour accéder à sa pitance.

AT Rennes 2013 : Lunch (3)

Et on peut en profiter pour discuter.

atrennes13-09pause-matin03

Au détour d’un buffet je croise Oana qui s’attaque aux organisateurs plutôt qu’au buffet.

AT Rennes 2013 : Oana (4)

Toutefois, il est bien clair qu’elle a ses préférences…

AT Rennes 2013 : Oana (3)

C’est tout pour aujourd’hui. Nous reprendrons les sessions de l’après-midi dans un prochain post !

Note de lecture : Service Oriented Java Business Integration, par Binildas C. A.

Note : 7 ; Du concret sur l’ESB, mais un texte qui accuse aussi son âge…

Pas facile de s’y retrouver au sein du concept technico-marketing qu’est l’ESB ! Ce dont on a surtout besoin, c’est du concret. Et c’est exactement ce que l’auteur nous propose ici. Malgré son titre généraliste, le livre se focalise presqu’exclusivement sur la mise en œuvre de l’ESB open-source d’Apache, ServiceMix et de la norme JBI qu’il dessert.

En fait, les 2 premiers chapitres sont consacrés à la vue générale des problématiques d’intégration. Le premier chapitre présente les banalités habituelles sur l’ESB (mais plutôt bien présentées) et le second se focalise sur l’aspect plus technique en introduisant JBI et les « integration patterns ». Ce n’est qu’au chapitre 3 (on est déjà page 57) que ServiceMix, ou plutôt la vue globale de son architecture, est introduit.

A partir du chapitre 4, on passe en revue les différents types de binding, selon une complexité croissante. Tout d’abord un binding simple, dit conventionnel (chapitre 4), puis un binding « contract last » avec XFire (chapitre 5). Un binding plus complexe à trois niveaux est abordé au chapitre 8, mettant en œuvre des EJB, tandis que le binding de POJO est enfin abordé au chapitre 9. Puis c’est le tour de l’approche « gateway » ou « contract first » avec Axis (chapitre 10).

Les chapitres 6 et 7 font figure d’interludes. Il était difficile d’aller bien loin sans aborder les concepts de packaging et de déploiement des services ServiceMix, c’est chose faite au chapitre 6. De même, il est parfois utile de compléter la panoplie de bindings proposés par l’ESB, c’est l’objet du chapitre 7.

La problématique du transport est aussi un domaine où l’ESB permet une certaine souplesse. Le chapitre 11 montre comment accéder un Web Service au travers de JMS. Au chapitre 12, on voit comment effectuer le binding entre Java et XML (le langage natif de l’ESB) en utilisant en autre XStream. Enfin le chapitre 13 aborde le point plus complexe mais aussi plus exotique des proxys JBI.

Les derniers chapitres peuvent être vus comme des aspects avancés, donc pas forcément indispensables de prime abord. Le chapitre 14 aborde la problématique de versioning des Web Services, utile dans le cadre d’un SI « évolutif ». Le très long chapitre 15 traduit en services ServiceMix de nombreux integration patterns. L’agrégation de services est abordée au chapitre 16. Il s’agit d’un sujet plutôt avancé et c’est tant mieux car le propos n’est pas des plus clairs. On finit en ordre dispersé par un chapitre fourre-tout, avec les transactions, la sécurité le clustering et la vie des bêtes au chapitre 17. J’espère qu’il y a mieux ailleurs car ce n’est pas la joie.

Comme on le voit, c’est un tour d’horizon plutôt complet qui nous est proposé sur 400 pages. Il s’adresse clairement aux architectes. On y aborde les concepts et le code. Si le code Java est clair, il est fort dommage (et c’est mon reproche principal) que les configurations ServiceMix pourtant complexes soient aussi peu décortiquées. Leur compréhension reste ardue.

Ce type d’ouvrage est hélas sujet à l’obsolescence. Ne nous voilons pas la face, c’est bien le cas ici. ServiceMix (pour ne parler que de lui) a déjà changé de version majeure depuis un moment. Il n’a plus nécessairement la pertinence qu’il avait au moment de sa sortie…

service-oriented-java-bi

Référence complète : Service Oriented Java Business Integration – Binildas C. A. – Packt Publishing 2008 – EAN : 978 1 847194 40 4

Service-Oriented Java Business Integration

http://www.goodreads.com/book/add_to_books_widget_frame/1847194400?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

A la conquête du Story Mapping

Il n’y a pas (encore) d’ouvrages traitant du Story Mapping, un technique développée par Jeff Patton. Elle comble une lacune de l’approche fonctionnelle agile basée sur les User Stories qui proposent une manière de cartographier ceux-ci sur des axes orthogonaux : le processus et la réalisation incrémentale.
Pour moi, il s’agit d’un outil supplémentaire à embarquer dans ma besace de pratiques agiles. Je ne vais pas les considérer comme un passage obligé des projets agiles, tout comme je ne suis pas prêt à accepter l’idée que les User Stories sont le moyen unique d’exprimer un besoin utilisateur (ce qui nous conduit par ailleurs à la notion de “story technique” que je rejette purement et simplement).
Le Story Mapping se situe au même niveau d’usage que les Cas d’Utilisation, une technique écartée par la plupart des agilistes, mais pas par moi (je reste en bonne compagnie sur ce point). Cette technique présente certains avantages par rapport aux cas d’utilisation, et ces derniers exhibent d’autres atouts. Nous reviendrons peut-être un autre jour là-dessus : Jean-Claude Grosjean et moi-même avions même évoqué l’idée de faire une présentation commune sur ce sujet un jour !
Pour le story mapping :

  • Structuration bottom-up des user stories.
  • Agencement des stories dans un processus (quand celui-ci reste simple)
  • Agencement par itération visible dans la map.
  • Un processus de travail collectif.

Pour les cas d’utilisation :

  • Une structuration “divide and conquer” top-down du besoin fonctionnel.
  • Une bonne structuration par unité fonctionnelle cohérente en lien avec des acteurs.
  • Un bonne structuration fonctionnelle intrinsèque avec l’articulation des scénarios.
  • Un niveau de structuration fonctionnel qui peut servir de charnière avec de nombreuses activités : UX, acceptante testing, etc…

A défaut d’avoir la référence ultime, j’ai essayé de collecter ici des ressources sur le sujet. Notons d’ailleurs au passage que la 3ème édition du livre de Claude Aubry évoque cette technique.

L’article de référence de Jeff Patton

Il décrit les étapes de la technique. Il n’a pas simplement un “intérêt historique”. Il reste tout à fait pertinent. En fait, je conseille de commencer par lire cet article !

Jeff Patton présente également son approche sur son site.

Pour ceux qui préfèrent le format “slides”, c’est juste ici:

La présentation de Steve Rogalsky

C’est un peu le “Story Mapping from the Trenches” : une présentation très visuelle sur la façon de faire du story mapping, où le présentateur montre comment lui-même opère concrètement. Une bonne illustration de l’article de Jeff Patton !

Par ailleurs, Steve Rogalsky a développé la matière de cette présentation via une série de posts :

Laurence Hanot : construisez votre produit en racontant des histoires !

J’avais assisté à la présentation de Laurence à Agile France, c’est une occasion de mettre en avant sa présentation qui est une introduction à la technique

De l’impact mapping au Story Mapping

Cette présentation m’a été indiquée par Gojko Adzic. A voir et revoir car elle fait le lien avec l’impact Mapping

Autres ressources

Facile à bien utiliser, difficile à mal utiliser, la présentation

En attendant que j’ai le courage de la terminer sous forme d’article, voici les slides de ma présentation à l’Agile Tour Bruxelles.
Cette présentation est directement inspirée d’un conseil de conception de Scott Meyers : “Make your interfaces easy to use correctly and hard to use incorrectly”. Sur ce, je vous laisse vous essayer aux quizz contenus dans cette présentation !

Worshop Running Lean, avec Ash Maurya (2/2)

Alors que la première journée s’appuyait en grande partie sur Running Lean, cette seconde journée sera d’avantage centrée sur les techniques récemment développées par Ash Maurya.

User cycle

Act 1 : Est-ce un problème qui vaut la peine d’être résolu ?

Nous l’avons évoqué dans le post précédent : la clé est de se concentrer sur l’utilisateur, de rechercher quels sont ses sources de souffrance :

  • Son workflow (il ne faut pas l’ignorer, en fait on doit même s’y insérer)
  • Ses craintes, ses frustrations
  • Ses buts et aspirations.

L’approche à adopter est une alternance de recherche et d’interviews : La recherche permet d’établir des hypothèses et l’interview permet de valider ou invalider ces hypothèses. Il s’agit de “problem interviews” permettant de valider l’identification du problème.

Ash Maurya durant le workshop

Deux mesure de succès du “problem interview” permettant de vérifier ‘intérêt que l’on suscite:

  • L’acceptation d’un “follow up”
  • L’obtention d’autres référents avec lesquels travailler.

Deux points que l’on n’obtient pas si l’on a eu qu’un intérêt de politesse.

Acte 2 : Tester la Vision

On n’a pas nécessairement besoin de code pour tester sa Vision. Il faut surtout être capable de faire une démo qui raconte une histoire. On peut utiliser un outil de prototype comme Keynotopia ou Balsamiq .

Là encore la validation passe par une interview, cette fois c’est une Solution Interview, qui s’articule comme suit:

  • Attention : En cernant correctement et précisément le problème de départ.
  • Intérêt : Avec une démo qui déchire.
  • Désire
  • Action

L’objectif est de produire un engagement :

  • “soft” : c’est obtenir un “oui”. ça vaut ce que ça vaut…
  • “dur”: c’est déclencher un pré-vente !

Bien sûr, on a toutes les possibilités intermédiaires…
A propos de la pré-vente : l’ancrage du prix fait partie du solution interview. Il faut le justifier par rapport aux alternatives et bien entendu pouvoir montrer qu’on abaisse en fait le coût avec notre solution, donc changer la perception du client potentiel. Quelques références sur ce sujet :

Positionner le MVP

La première étape consiste, nous l’avons déjà dit, à se concentrer sur un petit nombre de clients, une dizaine peut-être, guère plus, souvent même moins ! On ne cherche pas à collecter d’informations quantitatives, mais qualitatives.
C’est pourquoi on va chercher à rendre ces clients très heureux, pas simplement satisfaits. Adresser le risque marché consiste précisément à identifier si la solution permet ce haut niveau de satisfaction chez des clients. On ne va pas chercher à abaisser le “signup friction” de ces early adopters, on doit cibler des clients pour qui la proposition de valeur représente un besoin important. Autant augmenter ce “signup friction”, au contraire !
Plus tard dans le cycle utilisateurs, on cherchera à élargir la base d’utilisateurs, en s’appuyant de plus en plus sur du self-service. A ce niveau, c’est le risque technique lié à la scalabilité que l’on adressera.
Et le prix ?
Cela semble malin de prime abord de proposer 2, 3 ou 5 “plans”. Mais en réalité, il est préférable de ne pas s’amuser avec ces plans, même s’ils ont pour but de guider le client vers un “plan préféré”. La présence de ces plans multiples peut être un obstacle pour apprendre des choses sur l’adéquation prix-service, car il introduit une dimension supplémentaire.
Le prix est une partie intégrante du MVP. Tant que la proposition de valeur n’est pas payante, sa validité n’est pas établie.

Nous sommes tous dans le “manufacturing business”

… Et ce que nous construisons, ce sont des clients heureux, dont on améliore la chaine de valeur !
En Lean, l’amélioration de la chaine de valeur passer par l’élimination du gaspillage à l’échelle de la totalité de la chaine de valeur. Celle-ci est formée d’un ensemble de processus interconnectés sur lequel il faut identifier la contrainte principale … sans perdre de vue qu’une fois cette contrainte levée, celle-ci se sera déplacée ailleurs dans le système !

Exercice pratique

Dans le principe, ça parait simple. Dans la pratique il faut prendre en compte la dimension irrationnelle des clients, bien que cette irrationalité soit en fait prédictible (voir Predictably irrationnal)
Ash Maurya gradue le niveau d’engagement des clients ainsi :
1. Acquisition
2. Activation
3. Rétention
4. Revenue
5. Référent
Cette échelle nous permet d’aborder le sujet suivant : la customer factory !

The customer factory

C’est le sujet du prochain livre d’Ash Maurya. Il représente cette Customer Factory ainsi :

The Customer Factory

Le principe est finalement assez simple :

  • L’étape initiale est l’acquisition : les prospects viennent chez vous. Mais attention ! ce doit être plus qu’un simple rebond !
  • La rétention : elle est matérialisée par le signoff (activation). C’est l’étape “usine”.
  • Le revenu : quand on parvient à faire payer le souscripteur.
  • Le référent : quand on parvient à acquérir de nouveaux clients grâce à ces clients existants.

Et le moteur de croissance ?

  • Le “paid engine” doit favoriser l’acquisition.
  • Le “sticky engine” doit permettre la rétention.
  • Le “viral engine” doit engendrer l’acquisition par référent.

Ash Maurya nous recommande pour le “paid engine” : une “life time value” = 3 x le coût d’acquisition.
Pour observer si les moteurs de croissances donnent le résultat escompter, il faut passer par des métriques de cohortes, mais surtout se livrer à de nombreuses expérimentations !

Le validation board

Le Lean Startup Machine a mis au point le “validation board” qui permet de suivre les expérimentations à faire et en cours (c’est une sorte de kanban, si on veut bien…) par rapport à des hypothèses.

The Validation Board

Les clés :

  • Identifier les expérimentations capables de valider les hypothèses.
  • Trouver la mesure adéquate. Ash recommande à ce sujet la lecture de How To Measure Anything.
  • Construire une offre.

L’auteur de Running Lean nous propose 3 types d’offres :

  • La “Maffia Offer” : comme son nom l’indique, c’est l’offre que l’on ne peut pas refuser !
  • Le “Smoke Test Offer” : Une offre dont la complétude s’arrête à ce qu’il faut pour tester une hypothèse de marché.
  • Le “Pré-order offer” qui serf à lever des fonds, à la façon Kickstarter.

Les idées clés sont de faire de petites expérimentations (2 semaines maximum) ne testant qu’une seule hypothèse, pour lesquelles on définit les objectifs avant les critères de satisfaction avant, afin d’éviter la rationalisation après coup.

Chaque expérimentation doit être documentée. Mais pas trop, car on est lean…

L’experiment report

L’experiment report est une déclinaison du A3 du Lean. Il va nous permettre de garder la mémoire des expérimentations déjà opérer : faire des erreurs, c’est apprendre. Refaire les mêmes, c’est bien dommage…

Experiment Report

La partie du haut nous permet de figurer les mesures, et la partie du bas résume ce que l’on a appris

This is the end…
Nous arrivons au terme de ces 2 jours. Ils furent bien remplis, même si la partie pratique pêche un peu. De toute façon, c’est bien sur du réel qu’il faut mettre tout cela en pratique, et sans trop tarder !
Il me faut remercier non seulement notre orateur, mais aussi Sebastien Saccard qui a rendu ce workshop possible.

Ash Maurya et Sébastien Saccar

Et bien entendu Zenika qui fut l’un des sponsors de cet évènement.

Ressources

Pour compléter ce que nous avons vu, voici 2 présentations. La première est d’Ash Maurya et reprend les éléments de son workshop.

Le seconde est de Camille Roux (qui était aussi présent au workshop) et reprend de manière très synthétique et percutante la démarche Running Lean.

Note de lecture : PostgreSQL, A comprehensive guide par Korry Douglas & Susan Douglas

Note : 7 ; PostgreSQL de haut en bas!

750 pages sur 21 chapitres, voici un livre que l’on ne peut accuser d’être léger ! Les deux premiers chapitres servent surtout à introduire le SQL à la mode PostgreSQL avec ses spécificités. Le tout est plutôt pédagogique et couvre 130 pages. Pour terminer cette première partie, les chapitres 3 et 4 nous emmènent plus loin sur la structure des bases de données, des clusters et des transactions, ainsi que sur les modèles physiques sous-jacent de PostgreSQL pour comprendre comment en optimiser les performances. Du bon boulot !

Avec la seconde partie, fini de rire! On attaque les API en C pour écrire des fonctions permettant d’étendre PostrgreSQL au chapitre 6. Le retour au SQL (PL/pgSQL pour être exact) est bizarre au chapitre 7, surtout que c’est pour retourner à l’API C au chapitre 8 ! Le propos n’est pas très ais à suivre, il se poursuit au chapitre 9, tandis que le chapitre 10 nous en livre la variante C++. Il ne s’agit ni plus ni moins que de la reprise de ce qui est déjà vu au chapitre 8. Et désolé pour ceux qui espéraient du grand C++ ! Le chapitre 11 nous montre une autre variante de l’interfaçage PostgreSQL en C, via le préprocesseur ecpg qui permet d’écrire directement du SQL dans le code source. Je vous le dit: c’est déroutant! Moins déroutant est le chapitre 12 qui traite de cet interfaçage via le désormais classique ODBC. D’ODBC à JDBC il n’y a qu’un pas, ou un chapitre en l’occurrence, car c’est le chapitre 13 qui traite de l’interfaçage Java. Et l’on a donc la joie de voir la même approche se dérouler pour la 6ème fois ! De Java, on passé à Perl au chapitre 14, toujours avec la même structure de chapitre et le mêle exemple (pour la 7ème fois, donc). Au chapitre 15, c’est au tour de PHP, puis de Tcl/Tk au chapitre 16 (je croyais celui-ci mort et enterré). Enfin Python ferme la marche au chapitre 17.

Après la phase “comique de répétition” des interfaçages, la 3ème partie traite de l’administration. Il est assez curieux que l’on doive attendre le chapitre 19 pour voir traité l’installation du serveur ! Ce chapitre traite par ailleurs des très classiques gestion des utilisateurs, créations de bases avec sauvegarde et restauration de celles-ci. On y traite par ailleurs plutôt efficacement de tout ce qui a trait au paramètres d’exécution du serveur. Enfin le chapitre 20 traite de la localisation (pas seulement la langue, mais aussi les unités de mesure, de monnaie, etc…) tandis que les aspect sécurité ferment la marche au chapitre 21.

Dans ce livre, les aspects interfaçage avec différents langage tienne la plus grande part du livre. Aussi celui-ci vous sera surtout utile si vous utilisez la base de données de manière programmatique, surtout en C. Mais j’ai aussi trouvé plutôt bien traité les aspects lies à l’usage interactif, à la configuration et à la maintenance de PostgreSQL.

postgresql-comprehensive-guide

Référence complète : PostgreSQL, A comprehensive guide to building, programming and administering PostgreSQL databases – Korry Douglas & Susan Douglas – Developer’s Library 2003 – ISBN: 978-0-7357-1257-7

PostgreSQL


https://www.goodreads.com/book/add_to_books_widget_frame/0735712573?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on