nous avons bien avancé un projet de jeu sérieux pour la visite d’un site patrimonial mobile : les étapes sont des vidéos plein écran pour mobiles ponctuées par les choix, avec un skin immersif. Les vidéos sont en autoplay pour fluidifier l’expérience utilisateur. Le cadre est de produire un jeu HTML qui sera hébergé sur site et appelé dans un iframe. Le jeu est bien avancé, voici un extrait ici.
Malheureusement, nous avons découvert que sur les dernières version iOS, les vidéos en autoplay avec du son sont bloquées ; impossible de résoudre cela avec du JS pour les déclencher.
La solution est d’abandonner le système d’iframe et pages html de topaze pour aller vers un système monopage (single-page application) : lorsqu’une interaction a eu lieu sur une même page, il devient possible d’afficher des vidéos en autoplay. Twine par exemple utilise ce système, nos tests ont montré que cela fonctionne.
D’où ma question : avez-vous des idées pour conserver l’architecture du jeu Topaze et le faire rentrer dans le cadre d’un système monopage qui pourrait faire appel aux différentes pages html déjà générées ? En effet nous avons déjà monté l’ensemble de l’architecture du jeu qui comprend principalement des vidéos, leurs scripts et des choix…
Je ne vois que 3 solutions :
modifier le modèle documentaire Topaze pour produire un fichier html monopage unique (mais je crains que cela soit trop éloigné de la philosophie actuelle de Scenari) ;
développer un convertisseur qui lise les fichiers html générés pour produire un fichier html monopage selon le modèle de Twine par exemple (en abandonnant certaines fonctionnalités comme les variables ou les quizz) ;
abandonner Topaze, remonter l’architecture et le skin du jeu dans Twine.
La solution 2 a ma préférence (pas testée cependant), mais j’ai une inquiétude sur le fait qu’il faille précharger 200 Mo de vidéos d’un coup au lieu de segmenter ces téléchargements au fur et à mesure des choix faits par l’utilisateur (ce qui n’est pas prévu dans Twine). Ou alors il faudrait produire plusieurs fichiers monopages, un par chapitre, mais cette notion de chapitre n’est pas prévue par Topaze ; à moins de jouer sur le nommage des étapes.
Qu’en pensez-vous ; avez-vous des remarques ou conseils ?
Bonjour,
bravo pour le jeu réalisé, c’est un beau travail.
La prochaine version de Topaze aura une étape qui permet de mettre une vidéo plein écran avant d’afficher l’enchaînement, qui pourrait peut-être répondre à votre besoin si celle-ci peut être lancée en autoplay. @sam pourra sans doute mieux répondre que moi.
Bien cordialement,
Katia
Les navigateurs ont instauré cette règle pour plusieurs raisons :
pour interdire les abus sérieux des annonceurs (pubs)
pour rendre le web inéligible pour les utilisateur de tout niveau de prouesse technique
pour respecter les directives en terme d’accessibilité (non voyants, epileptiques etc)
Je trouve qu’il y a plusieurs problèmes à vouloir aller à l’encontre de cette mouvance :
le problème risque à tout moment de revenir au grès des avancés des navigateurs en terme de sécurité,
vous laissez tomber les utilisateurs qui on besoin d’un web accessible.
Passer un parcours Topaze en mono-page pourrait être envisageable mais QUE pour des petits parcours, je connais des utilisateurs de Topaze qui en on des énormes. Ici on s’ouvre a de sérieux problèmes de perfs.
Passer Topaze en mono-page nécessite un générateur dédié, et un développement un peut lourd.
La nouvelle étape immersive ne résout pas le problème de l’auto-play que les navigateurs cherchent activement à interdire.
Merci @Katia ; le plein écran favorise l’immersion en effet.
Merci @Sam pour ces remarques intéressantes. La stratégie des OS et navigateurs de bloquer l’autoplay est censée et n’est pas systématique bien sûr ; il s’agit d’empêcher le démarrage d’une vidéo lorsque vous tombez sur une page, par ex. après avoir cliqué sur un lien Google. En revanche il n’y a aucune objection à ce qu’une fois que vous êtes sur une page, vous puissiez accéder à une playlist de vidéos, par exemple comme dans Youtube : mais on est sur une application et non pas sur de nouvelles pages web.
Si Topaze passait au mode monopage cela veut dire qu’il fonctionne en mode application : cela évite d’avoir à recharger une page une à une, cela augmente la fluidité et dans le cas de Topaze cela permet d’introduire des effets de transition plus immersifs.
Comme vous l’avez justement remarqué la contrepartie est que cela requiert de charger tous les éléments d’un coup. D’où la notion de chapitrage : un chapitre d’une séquence Topaze permettrait de relier entre elles plusieurs monopages ce qui permettrait de réduire le délai de chargement entre chapitres.
Ainsi cette approche de type « application » est plutôt dans les tendances actuelles du Web qui favorise le développement des applications en ligne. Côté standards (je ne vois pas de pb d’accessibilité en revance), le monopage privilégie des technologies de type framework js, json, ajax et xml, ce dernier format étant privilégié par Scenari : on est sur les grandes tendances actuelles du web qui visent à optimiser l’expérience utilisateur.
Pour résoudre le pb de la lourdeur des monopages, je vois deux approches différentes :
faire appel aux contenus progressivement via des appels ajax
charger tous les contenus depuis la balise body et ne les afficher que lorsqu’on y accède via un lien, mais sectionner le parcours en étapes (plusieurs monopages)
L’inconvénient de la première méthode est qu’il est difficile de référencer des pages qui vont être appelées sur le serveur par la monopage « client ». D’où l’intérêt de privilégier la seconde méthode sous réserve de l’approche par « chapitre » (ou section) expliquée précédemment, et que les contenus soient optimisés. Mais cela est vrai pour tout projet Web.
Si c’est trop lourd de travailler sur un générateur nous allons faire autrement pour ce projet. Mais il y a peut-être là une perspective de développement intéressante pour Scenari.
En effet, s’il existe une solution en js, ce sera de très loin le plus simple. On est en train de faire une doc du framework js de Scenari, elle sera disponible prochainement. En attendant, vous pouvez ajouter du code js dans le fichier js/skin.js du skin. Ce script est appelé en fin de chaque page.
Sinon, pour ce qui est de la forme mono/multipage de la publication, quelques éléments de réponses supplémentaires.
Topaze utilise une page html racine pour gérer le contexte de navigation et la mémorisation du parcours et des indicateurs. Cette page charge les pages de contenus dans une iframe au fur et à mesure de la navigation du lecteur. Si je comprend bien, c’est cette page qui vous pose un soucis. Présente pour des raisons historiques, il me semble que cette construction player avec frame qui appelle le contenu pourrait être recodé comme un site web plus basique ou chaque page de contenu est directement appelé par le navigateur et où le contexte est mémorisé par les APIs de stockage du navigateur. Il s’agirait d’un nouveau générateur massivement basé sur l’ancien.
Le passage en mono page avec chargement dynamique en ajax est encore autre chose. C’est le fonctionnement des diaporamas de différents modèles. Cela a 2 gros désavantages :
c’est moins accessible (en raison des changements continus du dom)
ça ne fonctionne plus du tout en protocole file://
et dernier inconvénient, ce serait un très gros chantier à réaliser…
merci @xaan ; nous connaissions cette page mais elle n’est valable que pour iOS 10. A partir d’iOS 11, les iphone détectent l’usage d’une fonction js pour activer la vidéo et bloquent la fonctionnalité. En revanche, le principe selon lequel un geste utilisateur est nécessaire pour que l’autoplay soit fonctionnel est toujours respecté .
Merci @tha ; une doc js/css serait bienvenue en effet, nous avons dû un peu tricoter pour faire notre skin. Je n’avais pas pensé au modèle diaporama qui fonctionne en monopage contrairement au support web ; Scenari est donc prêt pour cela… En jetant un œil au code html généré d’une présentation Opale, je vois qu’on a une page par module + une page pour l’ensemble du support, ce qui permettrait d’alléger le chargement sous réserve de prévoir des sections dans l’éditeur.
Enrichir le modèle pour ajouter un support de publication monopage est sans doute un trop gros chantier pour notre seul projet : l’intérêt de travailler sur le modèle est de produire plusieurs différents.
A mon avis le monopage répond à des besoins spécifiques : immersion, fluidité et effets modernes (on est pas dans une fac mais dans un lieu de médiation culturelle et patrimoniale), accessibilité prise en charge au niveau de l’affichage (les textes pourront être entendus, lus ou grossis), référencement inutile, mobile first (le jeu sera in situ).
Nous verrons à l’avenir si les utilisateurs de Topaze devront davantage répondre à ces besoins ?
Il y a quelque chose que je ne m’explique pas bien… (NB : je n’ai pas fait les recherches pour comprendre et je n’ai pas de périphérique Apple pour tester).
Quel est l’apport d’un mécanisme « mono-page » avec chargement dynamique par rapport au simple fait d’enlever la page de « player » et d’afficher directement le contenu sans iframe ?
Le monopage permet de démarrer automatiquement une vidéo après avoir fait un choix. Pas besoin de relancer la vidéo après avoir fait un choix. Comme notre jeu n’est fait que d’un enchaînement de choix et de vidéos, ce serait lassant de devoir les relancer à chaque fois. L’autoplay n’est possible que si l’utilisateur a interagit avec la page une première fois. L’iframe considère que chaque page est nouvelle, donc pas d’autoplay. Du coup le monopage offre une solution stable face à ce pb, ainsi qu’une panoplie d’effets de transition comme ceux qui appaissent dans les présentation Opale.
Les ressources étant déjà implantées dans Topaze, j’envisage de développer un convertisseur Topaze => Twine ; mais je note votre suggestion de faire ça côté Scenari Builder, je regarderai. Nous avons choisi Topaze afin de permettre à des non développeurs de faire le design du jeu et de le faire évoluer facilement lors des tests, ce que permet la séparation forme/contenu.
Merci pour le conseil d’aller voir côté générateur de site statique, ce sera très bien pour un futur projet en effet !
Bonjour,
En mai dernier, Katia évoquait l’autoplay sur l’étape média. Est-il possible aujourd’hui de proposer un autoplay à la vidéo dans une étape média ?
l’étape média permet plus d’immersion, mais pas l’autoplay. En effet l’autoplay ne peut fonctionner que si la page n’est pas rechargée. Par défaut topaze utilise plusieurs pages html, chacune correspondant à un rafraîchissement. Modifier le modèle topaze pour intégrer l’autoplay est un long travail, problablement plusieurs mois pour un stagiaire.
Cependant la solution que nous avons mis en place fonctionne, nous devrions d’ailleurs bientôt l’adapter à l’étape média. Si vous êtes intéressée par une collaboration sur ce sujet n’hésitez-pas à me contacter : nom.prenom@gmail.com
Il serait possible en effet de recoder Topaze pour produire une seule page mais ceci serait non soutenable pour les très gros cas, et je sais qu’il y en a !
