Sites "mono-page"

[Xenos]

<<Ce topic est issu du hors-sujet sur L'île du Coeur >>


Perso, j'ai du mal avec cette notion de "c'est tout dans la même page donc c'est trop bien" (pour ma part, j'y vois surtout la perte de la fonctionnalité "Précédent" du navigateur & l'impossibilité de mettre quelque chose en favori). Mais bon, j'attends de voir

Et c'est normal d'avoir un truc "hyper basique" pour une première relase, pas de raison de s'affoler (voire même, tous ces "extras" autour pourraient attendre cette 1ere release, puisque son but est de présenter un jeu juste jouable, sans fioriture)

Bonne chance pour cette première sortie

[L'Omniscient]

En fait le coup de tout dans la même page, c'est parce que je voulais que ce soit hyper dynamique. Ya pas beaucoup d'onglets annexes, jamais 2 clics à faire pour accéder à une page, du coup je pense que ça posera pas trop de problème. Oui tu verras, ce sera la surprise !

En fait j'ai déjà des idées pour poursuivre le jeu. Hanlala j'ai hâte :p

Merci ^^

[Xenos]

c'est bien pour le mobile
Franchement, je ne serai pas aussi catégorique car sur mobile, tu n'as pas la place d'afficher 4 frames avec des données différentes (qu'elles viennent d'AJAX ou non), et comme sur PC, tu perds l'avantage des boutons de navigation précédent/suivant (qui ne rechargent pas forcément la page). Mais cela mériterait un topic séparé pour en cause (= je me tais, profitez-en )

[Thêta Tau Tau]

On peux très bien faire un site en une page qui gère différentes url et les boutons précédents/suivants.
Par exemple avec meteor et un package de router, c'est exactement ça : le site a l'air totalement "classique" mais en fait on est sur une seule page qui est modifiée via javascript.

[Dumbeldor]

c'est bien pour le mobile
Franchement, je ne serai pas aussi catégorique car sur mobile, tu n'as pas la place d'afficher 4 frames avec des données différentes (qu'elles viennent d'AJAX ou non), et comme sur PC, tu perds l'avantage des boutons de navigation précédent/suivant (qui ne rechargent pas forcément la page). Mais cela mériterait un topic séparé pour en cause (= je me tais, profitez-en )

C'est plus pratique si tu veux faire une application mobile par la suite avec un framework type cordova, t'as moins de chose à modifier pour permettre de faire une application mobile intéressante. Mais oui c'est pas le sujet

[Xenos]

Mouais, ce genre de "bricolage" du site qui émule des comportements de navigation fini souvent en mélasse... Genre le site s'étant dit "par défaut, les gens ont 'backspace' comme touche pour 'précédent', alors je vais émuler la fonction 'précédent' quand ils appuyent sur 'backspace'". Sauf que, d'une part, tous les supports n'ont pas forcément de backspace (à chaque nouveau support, genre les mobiles, il faut que le framework l'intègre donc on a toujours un temps de retard et une charge de sysadmin en plus) mais également, l'utilisateur n'a pas forcément laissé ces réglages par défaut.

Si tu veux faire une version "mobile", les brouettes de JS t'obligent à trouver des brouettes de framework. Si tu te forces à coller aux standards purs, t'as juste *rien* à faire de plus que d'aller sur le site avec ton mobile.

Je n'ai rien contre le JS, c'est parfois adapté pour certaines features, mais si c'est pour recoder en JS des comportements de navigateur (ou des composantes de base des standards), alors c'est une perte de temps (au mieux), voire un massacre de l'ergonomie (au pire).

Après, je dirai que le soucis de beaucoup de développeurs web réside dans la confiance accordée au navigateur: soit on lui fait confiance, et on fait du HTML/CSS/web, soit on ne lui fait pas confiance et on fait du JS à toute volée.

/pour le coup, je scinde le topic

---

Et perso, je pense que d'ici 10-15 ans, on se foutera de la gueule de jQuery (voire de Javascript) tout comme on se fout de Flash de nos jours. Somme toute, flash est au responsive ce que les tartines de javascript sont à la navigation.

[Dumbeldor]

Oui mais tu fais comment si tu veux rendre ton site le plus accessible aux mobiles ?
Car concrètement on va pas se mentir sur un jeu web le pourcentage de joueur sur mobile est de plus en plus important, et il est important de prendre ça en compte lors du développement.
Je pense qu'il est intéressant de rendre quelques trucs dynamique avec jquery/ajax mais c'est assez compliquer de faire une application web complète via à cette technologie à moins d'utiliser des framework js très lourd du type Angular.

Donc c'est compliquer, je pense que ça dépend vraiment de la cible visé, du gameplay.

Tu ferais comment pour rendre ton site accessible le plus facilement / rapidement aux mobiles Xenos ?

[niahoo]

Si tu veux faire une version "mobile", les brouettes de JS t'obligent à trouver des brouettes de framework. Si tu te forces à coller aux standards purs, t'as juste *rien* à faire de plus que d'aller sur le site avec ton mobile.

Je n'ai rien contre le JS, c'est parfois adapté pour certaines features, mais si c'est pour recoder en JS des comportements de navigateur (ou des composantes de base des standards), alors c'est une perte de temps (au mieux), voire un massacre de l'ergonomie (au pire).

Je te conseille, par curiosité, de tester l'implémentation d'une single page app avec un framework javascript. Par exemple Mithril[1] qui est un peu tout-en-un. L'idée n'est pas d'avoir quatre frames en simultané sur ton écran mais par exemple de pouvoir jongler entre les quatre facilement et instantanément, n'ayant besoin de charger que des données.

On ne pense pas forcément en forme de frames. Par exemple, pour un jeu tu vas avoir une barre de boutons que tu vas pouvoir modifier (enlever des boutons, rajouter un compteur de temps, rétrécir sa taille, etc.) selon le contexte du jeu, sans recharger de frame ou faire de requête AJAX. Du coup c'est beaucoup plus simple en pensant toute sa vue en javascript plutot qu'en écrivant du HTML pour ensuite venir se rajouter par dessus en JS. par exmple avec Mithril ou Flux tu vas simplement écrire du code qui décrit ta vue et les bindings JS en fonction de l'état de ta page, l'état étant une simple donnée.

En gros : vue = ƒ(état) où ƒ est une simple fonction, que tu peux choisir parmi un pool de fonctions.

Je ne crois pas vraiment en l'idée d'implémenter un jeu avec une interface riche sans partir directement sur du JS. A contrario, pour un site de contenu, je partirais sur du HTTP pur genre HTML et liens qui chargent d'autres pages, et je rajouterais une couche très fine de JS totalement facultative.

Quant à l'implémentation hasardeuse d'une fonctionnalité native, justement les navigateurs exposent une API très pratique pour ne pas avoir à le faire. Typiquement, lorsque une autre route est appelée, l'appel à la fonction history.pushState permet d'ajouter une entrée dans l'historique, et c'est ensuite au navigateur de gérer précédent/suivant normalement.

La touche backspace ou autres racourcis tant sur les navigateurs que sur les mobiles étant des raccourcis offerts par le navigateur pour jouer avec l'historique, ton code n'a donc pas à s'en soucier.


[1] http://mithril.js.org/

[Prélude]

Je mets mon petit grain de sel : et l'accessibilité dans tout ça ?!
D'ailleurs, est-ce que vous en tenez compte de l'accessibilité ou est-ce que vous vous dites "bin non, pas possible" ou "Ça concerne trop peu de personnes" ?!
Ou vous n'y avez pas pensez, tout simplement ?
Au passage, si vous souhaitez savoir un peu où vous en êtes des bonnes pratiques d'internet, tentez ce quizz très simple : https://demo.certified.opquast.com/
Alors ? Vous êtes proche de 10/10 ?

Et pour en revenir à la mon-page, par expérience, il est très difficile de maintenir un site mono-page. Est-ce que vous avez des astuces pour ça ?

[Xenos]

L'accessibilité mobile est déjà faite dans la spec HTML5. Le mobile est une terminal HTML. Le PC est un terminal HTML. La tablette est un terminal HTML. Le lecteur d'écran est un terminal HTML. C'est pour un terminal HTML que je préfère coder mes sites, et non pour un support précis.

Ainsi, sur mobile, eh bien le terminal agence tout seul le site (vive flex & autres media queries). Les préférences du navigateur & donc de l'utilisateur sont exploitées au maximum: elles seront surement plus adaptées que les bricolages du webmaster (qui sinon, code son site par rapport à son propre PC).

Si tu fais un site full-canvas tartiné de JS, oui, tu seras *obligé* de rajouter du framework pour compenser tous les effets de bords dus à la perte de la notion de page HTML. Le terminal mobile sait mieux que moi comment optimiser sa bande passante, à condition de lui déclarer les choses et non de les lui imposer. C'est le terminal mobile qui saura ne pas rafraichir automatiquement la page (par exemple) si le Wifi est désactivé. S'il ne sait pas le faire, c'est un bogue du *navigateur* et non du site (les deux rôles sont, je trouve, trop souvent mélangés).

@niahoo: Au fond, je n'ai pas l'intention de tester le codage d'un site mono-page à coup de framework, car du point de vue utilisateur, je n'aime pas cela. Jongler entre des frames, c'est de la navigation pour moi (utilisateur). Si elle ne te plait pas, c'est ton/le navigateur qu'il faut améliorer, pas le site, car ce n'est pas son rôle.
Tu fais surement la même description avec du HTML classique et du CSS. Le JS va juste servir à poser les éventuelles classes manquantes au bon moment.

D'accord pour ton exemple sur l'historique, mais maintenant, tu peux te prendre tout autant la tête pour la navigation dans un textarea, pour le scroll dans la page (flèches clavier, barre, tactile, molette quadri, bouton souris 4 enfoncé + déplacement, etc).

---

Et un quizz sur *l'accessibilité* qui nécessite justement du JS pour "Démarrer le quizz",ça commence bien!
"Chargement du quiz... " Non mais sérieux, vous allez faire comment pour me dire que ça, c'est de l'optimisation? Ce genre de truc, déjà, peut parfaitement être dans la page de base (c'est ce qui devrait d'ailleurs être fait: les "question suivante", ou "démarrer le quizz" ne sont que de la présentation). n'allez pas dire "ça optimise car on charge moins de trucs": mettre le formulaire sur 1 seule page, ça chargera moins et si on fait un quizz, c'est pas pour s'arrêter en route.
Quand bien même on pourrait s'arrêter, c'est quoi la différence ici avec une iframe? Mis à part que, en AJAX, vous allez mélanger tous les contextes de la page et rendre impossible l'affichage de deux frames identiques (car, par exemple, ces frames ont un élément avec le même ID car elle apparait 2x dans la page)?!

Bon, allez, crotte, désolé mais un quizz de "bonne pratique comme ça", juste non. Le lien pour agrandir l'image est un monceau de javascript: chez moi, un lien que tu cliques avec le bouton centrale s'ouvre dans un nouvel onglet, point. C'est pas une daube de frame JS mélangée au contenu de la page avec un bouton "Fermer" qui n'a rien à foutre ici.