Introduction à OpenSocial – Les Expériences Embarquées

Quotidiennement nous recevons dans notre boite aux lettres ou dans notre flux d’activités de nombreuses notifications : celles des réseaux sociaux, celles des outils de CRM, celles des applications de gestion de tâches (approbation de demandes de congés, demandes d’achats, validation de voyages…). Toutes ces entrées remplissent nos boîtes courrier et encombrent notre flux d’activités. Et vous, que faites-vous de ces notifications ? Vous les supprimez ? Vous les déplacez dans un dossier de votre boite courrier ? Vous les lisez toutes ? Leur contenu est-il réellement utile ? Probablement non.

C’est là que les expériences embarquées (« Embedded Experience ») sauvent votre productivité et votre efficacité !

Une expérience embarquée est un modèle de diffusion de l'information dont le contenu d’une source externe est intégré dans un conteneur « OpenSocial » d’un flux d'activités ou boîte de réception. Le but des expériences embarquées est que les utilisateurs soient en mesure d'interagir dynamiquement avec le contenu externe directement dans le contexte (le mail ou l’entrée d’activité) sans avoir à basculer vers l’application externe.

Une expérience embarquée peut être simple comme une URL vers une page web ou plus riche comme une application à part entière, bien que la plupart des expériences embarquées se situent quelque part entre les deux modèles. Toutes les expériences embarquées sont définies par un modèle de données simple au format JSON ou au format XML. Le modèle de données comprend une URL d'un gadget et éventuellement quelques données de contexte que le gadget utilise lors du rendu. Le gadget est représenté comme un fichier XML qui contient du HTML, feuilles de style (CSS) et JavaScript.

Un cas concret :

La meilleure façon de décrire une expérience embarquée est d'utiliser un exemple bien connu : Très probablement, vous avez vu une vidéo YouTube intégrée dans une page Web ou une application. Vous pouvez lire la vidéo, régler le volume, voir la vidéo en mode plein écran, et plus encore. Toutefois, si vous voulez faire un commentaire sur la vidéo pour d’autres utilisateurs de YouTube, vous devez généralement quitter votre application, aller sur YouTube, vous connecter, et enfin poster des commentaires sur la vidéo.

Maintenant, imaginez que vous permettiez aux utilisateurs d'ajouter et d'afficher des commentaires sur la vidéo directement sur YouTube sans jamais quitter l'application. Les utilisateurs peuvent interagir avec la vidéo directement à partir de leur flux d'activité ou la boîte de réception - une riche interaction sociale se produit sur ​​YouTube, mais depuis le contexte de votre application.

Les Expériences intégrées s’appuient sur le protocole OAuth pour l'authentification de l'utilisateur. Dans le cadre de la spécification OpenSocial, OAuth permet à votre gadget d’accéder au contenu sécurisé une fois que les utilisateurs aient autorisé l'accès du gadget à votre application. Cette autorisation entre votre expérience intégrée et le fournisseur de services, YouTube, dans ce cas, est maintenu pour une durée de temps déterminée par le fournisseur. Après ce délai, l’autorisation est révoquée, les utilisateurs doivent s'authentifier à nouveau.

Bien sûr, YouTube est juste un exemple de la façon d'intégrer des applications avec des expériences embarquées. Les expériences intégrées peuvent être utilisées pour intégrer un service, consommateur ou entreprise liée, à partir du moment où il y a des API publiques disponibles à utiliser. Par exemple, dans l'entreprise, vous pouvez créer des expériences embarquées pour votre gestion de la relation client (CRM), pour vos solutions de gestion des processus au sein de votre entreprise (validation de congés, gestion de tickets dans une base de gestion d’incidents ...).

Mais entrons un peu plus dans le détail …

Schéma général

Si vous n’utilisez pas les expériences embarquées, le flux de notifications de votre application vers vos utilisateurs ressemble probablement à cela :

Schéma classique de notifications

Schéma classique de notifications

Le schéma est assez simple :

Certaines actions sont à effectuer dans votre application et vous souhaitez en informer vos utilisateurs. Peu importe l’action à faire, il se peut même qu’aucune action ne soit requise, il est probable que la personne ayant déclenché l’action souhaite informer les autres utilisateurs.

Pour cela, votre application va soit générer une entrée d’activité et la publier dans le flux d‘activité des autres utilisateurs, soit elle va envoyer une notification par mail, parfois même effectuer les 2 étapes. Et c’est ici que la frustration commence.

Les notifications ne sont, la plupart du temps, que de simples liens qui permettent à l’utilisateur notifié de revenir à l’application.

Il y a de fortes chances que votre application ne soit pas la seule à utiliser ce mécanisme, et vos utilisateurs passent leur temps à basculer d’une application à une autre, tout au long de la journée.

Avec la mise en place des expériences embarquées, le flux semble similaire mais l’impact sur la productivité est conséquent :

Schéma de notifications avec expériences intégrées

Schéma de notifications avec expériences intégrées

 

Il y a deux grandes différences dans ce schéma par rapport au schéma précédent. Tout d’abord, il y a l’étape identifiée « Modèle de données Expérience Embarquée » qui est ajoutée avant la notification par email ou la création de l’entrée d’activité. C’est essentiellement un pointeur vers votre « Expérience Embarquée ».

La seconde différence réside dans le fait que dans la notification, au lieu du lien basique vers votre application, c’est une expérience embarquée qui est intégrée, c’est-à-dire une partie de votre application qui est incluse dans la notification. Le contenu de la notification devient interactif. Ainsi, l’utilisateur peut remplir le formulaire depuis la notification, marquer la tâche assignée comme effectuée, le tout sans avoir à quitter le flux de notifications de la messagerie ou du flux d’activités.

Il n’y a pas besoin de basculer entre les différentes applications, les notifications deviennent utiles. Vos utilisateurs restent productifs et le plus important, continuent d’apprécier votre application.

Experience Embarquée dans IBM Notes

Experience Embarquée dans IBM Notes

 

Deux Types d’expériences embarquées

Vous pouvez choisir entre deux types d’expériences embarquées :

Le premier est appelé « URL Embedded Experience » pour « Expérience d’URL intégrée ». Ce type d’expérience embarquée utilise un lien URL pour fournir le rendu de l’expérience embarquée de votre application. La seule contrainte est que le retour de l’URL soit au format HTML. Cela signifie que vous pouvez utiliser n’importe quelle technologie pour fournir l’expérience embarquée, XPages, pages JSPs, PHP, Ruby on Rails, etc …. Toutes fonctionneront. La mise en place de cette pratique nécessite de s’appuyer sur un SSO pour effectuer l’authentification.

L’autre type d’expérience embarquée est basé sur les gadgets OpenSocial : Vous pouvez utiliser un gadget pour intégrer d’autres applications à l’intérieur du client Notes, comme la barre latérale de IBM Notes ou IBM iNotes, ou dans IBM Connections.

L’avantage d’utiliser un gadget, est que vous pouvez utiliser 0Auth (1.0a ou 2.0) pour autoriser l’expérience intégrée avec d’autres services.

 

Le modèle de données des expériences embarquées

La clé de toute notification de l’expérience intégrée est le modèle de données. C’est ce qui permet au flux d’activité ou au client de messagerie de connaitre l’expérience à utiliser. La bonne nouvelle est qu’en général, le modèle de donnés est très simple. Il peut être représenté selon une structure JSON ou XML.

 

Le modèle de données des « Expériences d’URL intégrées »

Le modèle de données des « Expériences d’URL intégrées » est extrêmement simple car tous les clients n’ont besoin de connaitre que l’URL à utiliser.

Ci-dessous, 2 exemples de description.

Exemple JSON

{"url" : "http://domino.com/myXpage.xsp"}

Exemple XML

<embed>
   <url>http://domino.com/myXpage.xsp</url>
</embed>

 

Le modèle de données des « gadgets intégrés »

Le modèle de données des « gadgets intégrés » est à peine plus complexe:

Exemple JSON

{
    "gadget" : "http://example.com/gadget.xml",
    "context" : {
        "id" : 123
    }
}

Exemple XML

<embed>
   <gadget>http://example.com/gadget.xml</gadget>
   <context>
      <id>123</id>
   </context>
</embed>

 

L'article suivant décrit sur un exemple concret comme mettre en place les expériences intégrées

 

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Captcha *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.