Sites "mono-page"

[niahoo]

Oui mais non parce que tu peux te soucier de l'accessibilité sans passer forcément par une version jouable sans javascript. (Ce que je comprends via "progressif").

À moins que certains navigateurs adaptés ne gèrent toujours pas le javascript. Mais dans ce cas, en attendant que ça vienne, je chercherai plutôt à implémenter un jeu genre Space Chem plutôt que, vous savez, mon jeu préféré, Déclaration d'Impôts Simulator 2016.

[Xenos]

ça suit le comportement normal de html sauf qu'il faut une librairie javascript pour le faire, je pense que c'est ça qui gêne Xenos.

Ouep, car la notion de "le comportement normal de html" est relative au navigateur de l'utilisateur, et non absolue: impossible d'émuler le comportement habituel du navigateur individuel du visiteur avec un seul javascript unique pour tous les visiteurs.


@Sephi:
Là, je suis plus hésitant. Okay, ça fait joli d'avoir un simili-jeu-AAA dans son navigateur, mais j'y trouve tellement d'inconvénients que cela finit par en gâcher l'intérêt (re-téléchargement des données à chaque fois, sous-utilisation du matériel/de l'OS, perte de l'aspect "je peux y jouer partout avec n'importe quelle interface"...)

Sur un autre plan (soulevé par Sephi du coup), je ne parviens pas trop à saisir l'intérêt de vouloir développer un jeu AAA dans un navigateur si c'est pour repenser toute la notion de navigation et d'interface... Autant faire un jeu classique avec un bon SDK, non?

[Sephi-Chan]

Là, je suis plus hésitant. Okay, ça fait joli d'avoir un simili-jeu-AAA dans son navigateur, mais j'y trouve tellement d'inconvénients que cela finit par en gâcher l'intérêt (re-téléchargement des données à chaque fois, sous-utilisation du matériel/de l'OS, perte de l'aspect "je peux y jouer partout avec n'importe quelle interface"...)

Quels sont les inconvénients dont tu parles ?

Sur un autre plan (soulevé par Sephi du coup), je ne parviens pas trop à saisir l'intérêt de vouloir développer un jeu AAA dans un navigateur si c'est pour repenser toute la notion de navigation et d'interface... Autant faire un jeu classique avec un bon SDK, non?

Là on parle juste de ne pas changer de page quand tu cliques sur un bouton…

[Xenos]

Les inconvénients (dont j'ai cité 3 exemples) portaient sur le fait de vouloir faire du simili-AAA dans un navigateur, mais oublions ça pour le moment.

Si tu dis "sur la page de jeu, on se fout de l'expérience HTML, et on a tout intérêt à essayer de la gommer", alors que fait ton jeu dans un navigateur? Pour moi, y'a un second paradoxe ici (le premier était "simuler le comportement du navigateur est subjectif au client, alors que le javascript du site web est le même pour tous"): pourquoi vouloir développer son jeu pour un navigateur tout en voulant dicter soi-même la navigation?

Dans ce cas, autant faire des jeux à partir de SDK classiques (plug & play, sans installateur, avec juste un fichier qui va télécharger les composant du jeu à la demande et les stocker sur le PC).

[Sephi-Chan]

Le navigateur est un support comme un autre. Il vient avec des avantages (disponible partout, sans installation, avec des technologies simples…) et des inconvénients (moins performant). Je fais mon jeu dans un navigateur parce que les avantages de ce support valent largement les inconvénients.

Je ne comprends pas ce qui peut te pousser à rejeter ça : tu arrives sur une page de jeu "Risk online", la page de jeu t'affiche les continents, les pays se colorent au survol, des "fenêtres" s'affichent quand tu cliques sur un pays,, tu peux déplacer par drag'n'drop, etc.
En quoi ça te dérange d'avoir ces contrôles qui ne viennent pas nativement du navigateur ?

[niahoo]

ça suit le comportement normal de html sauf qu'il faut une librairie javascript pour le faire, je pense que c'est ça qui gêne Xenos.

Ouep, car la notion de "le comportement normal de html" est relative au navigateur de l'utilisateur, et non absolue: impossible d'émuler le comportement habituel du navigateur individuel du visiteur avec un seul javascript unique pour tous les visiteurs.

Non, ça suit le comportement normal de html car javascript génère une balise <a href="machin">truc</a> tout à fait standard !Un lien quoi.

pff ... et sinon personne n'a parlé de jeu triple a.

[Xenos]

En quoi ça te dérange d'avoir ces contrôles qui ne viennent pas nativement du navigateur ?
En sur-couche de ce qui existe, cela ne me dérange pas. En remplacement, il arrivera certainement une situation/un contexte où cela va me gonfler. Après, libre à chaque dev de vouloir se servir du navigateur comme d'un OS mal fagoté. Perso, moi, ça me déplait (en tant que dev, et en tant qu'utilisateur).


@niahoo
Heu, oui, si tu génères des balises HTML classiques par le JS, y'a rien de cassant dans la navigation. Là, on parlait d'un JS qui vient supprimer le comportement du navigateur face au clic (ou autre d'ailleurs) sur ce lien pour le remplacer par le comportement que le JS dicte.

[niahoo]

Dans ce cas ne généralise pas single-page app à la seule frange des apps qui ne respectent pas les conventions du web

[Sephi-Chan]

Effectivement tu fais plus un procès aux développeurs pénibles qu'aux single page apps. D'autant que ne pas casser le navigateur est au cœur des frameworks cités.

[@lucard]

J'ai fait un test récent avec un liseuse (wi-fi) Le mono-page affiche pas mal de problèmes de lien (peut-être la gestion des ancres et des "collapses", des "hidden" etc.. y est pour quelque chose) mais parfois les "cliques" sur les boutons ne fonctionne pas...
quand ça ouvre de nouvelle page (entièrement nouvelle donc) je n'ai pas vu de problème particulier.

Je précise que c'est un liseuse Monochrome, que la gestion du html5 est partiel, et que "flash" n'est pas supporté.

voilà c'tait un aparté.