+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38)
+--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51)
+--- Sujet : Sites "mono-page" (/showthread.php?tid=7594)
RE: Sites "mono-page" - niahoo - 19-02-2016
(19-02-2016, 10:40 AM)Xenos a écrit : 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).
Mais de quoi tu parles ? Que ton HTML ait été généré par JS ou PHP, en quoi ça change la navigation dans un textarea ?? Visiblement tu ne sais pas de quoi tu parles. Idem pour l'agencement responsive ou autre, le navigateur va tout autant être mis à profit. Faire du javascript ça ne veut pas dire réinventer le navigateur dans le navigateur, ça veut dire l'exploiter à son maximum.
Pour l'accessibilité, bah pareil (bon, faut bien sur que le navigateur gère le javascript), t'as du HTML, si tu respecte les bonnes pratiques ça ne change rien.
Le questionnaire est un peu pourri aussi. Il t'indique des mauvaises réponses, ensuite il t'envoie par mail des explications qui sont explicitement ce que tu as répondu, mais qui est considéré faux.
RE: Sites "mono-page" - Xenos - 19-02-2016
Faire du javascript ça ne veut pas dire réinventer le navigateur dans le navigateur
C'est pourtant souvent ce qu'il se passe, je te laisse reprendre l'exemple du quizz qui m'a passablement mis (un peu) sur les nerfs...
Je ne vois pas comment tu peux faire un site mono-page à coup de JS sans réinventer le navigateur dans cette même page. Si t'en as des exemples en ligne, n'hésite pas, je suis preneur.
RE: Sites "mono-page" - @lucard - 19-02-2016
Personnellement je préfère avoir 5 à 10 onglets ouverts (si si, ça m'arrive de ne pas avoir assez de place pour afficher tous les onglets en Dual-Screen) qu'une page "tout-en un".
Le clique-molette (ou clique-central) est constamment utilisé chez moi.
Pour mobile, je trouve qu'il y a plus de "lourdeur" dans les sites one-page, contrairement aux sites avec des pages dédiées.
RE: Sites "mono-page" - niahoo - 19-02-2016
Faut pas tout mélanger. J'ouvre moi aussi des dizaines d'onglets wikipedia, reddit, des sites de news, etc. Il n'y aurait pas vraiment d'intérêt à changer ça sur navigateur.
Mais ensuite, je sais pas moi, au hasard facebook, twitter, asana/targetprocess, certains jeux, google maps, certaines applis de carto sur lesquelles je bosse, je cherche même pas ce que ça donnerait à la sauce Xenos.
Genre google maps : recherche d'itinéraire -> entrer le lieu de départ -> valider le formulaire -> chargement de page -> ce lieu n'est pas connu, voici les suggestions -> sélection -> validation du formulaire -> [La même chose avec le lieu d'arrivée] -> afficher la carte globale -> zoomer (clic sur le zoom) -> chargement d'une page avec de nouvelles images. -> Ah non un peu plus à l'ouest ce serait mieux -> clic sur "gauche" -> chargement de page -> affichage des images.
C'est bon quoi, on est plus en 90. Le truc qui met 5 secondes pour l'utilisateur en JS avec une connexion de m*rde en prendrait 50 avec une connexion moyenne.
RE: Sites "mono-page" - Thêta Tau Tau - 19-02-2016
(19-02-2016, 02:08 PM)Xenos a écrit : Je ne vois pas comment tu peux faire un site mono-page à coup de JS sans réinventer le navigateur dans cette même page.
Avec les technologies que j'utilise dans mon projet (Meteor et le package flow.router), toutes les fonctionnalités des navigateurs sont conservées (clic du milieu, historique...)
Les liens ont l'air tout à fait normaux :
Code :
<a href:"/mapage">Ma page</a>Si on clique sur ce lien, au lieu d'envoyer une requête html pour charger une nouvelle page, ça appelle un script javascript qui va :
-modifier l'url de la page
-signaler à l'historique du navigateur qu'on a changé de page (donc toutes les fonctionnalités du navigateur comme les boutons précédent, les favoris etc. fonctionneront).
-charger les données nécessaire via websocket.
-mettre à jour le html
Au final le résultat est exactement le même qu'avec un lien classique, sauf que seules les données envoyées par le serveur sont celles nécessaires pour la page.
Par exemple pour un article de blog le serveur enverra un simple json du style :
Code :
{
title: "Test",
author: "Theta",
content: "Lorem ipsum...",
comments: [
{author: "bob", content: "Trop cool"},
{author: "luc", content: "+1"}
]
}L'avantage c'est qu'on n'a pas à ré-envoyer à chaque page, par exemple, le menu de navigation ou le footer. Du coup ça réduit pas mal le temps de chargement des pages.
Avec meteor il existe même des packages permettant de faire site accessible à ceux qui ont js désactivé (et donc aussi aux bots des moteurs de recherche) sans avoir rien à recoder.
Du point de vue du visiteur, un site mono-page en js s'utilise donc strictement de la même façon qu'un site web classique, hormis en allant voir le code source il n'y a aucun moyen de voir la différence (quand c'est bien fait, hein, c'est sur qu'avec de l'AJAX tout basique ce n'est pas le cas).
Et au niveau du temps de développement ou de la difficulté à apprendre à se servir d'un framework js, ce n'est pas vraiment différent de ce qu'on a avec un framework en php (ou autre).
RE: Sites "mono-page" - Xenos - 19-02-2016
Citation :Si on clique sur ce lien, au lieu d'envoyer une requête html pour charger une nouvelle page, ça appelle un script javascript qui va :
-modifier l'url de la page
-signaler à l'historique du navigateur qu'on a changé de page
-charger les données nécessaire via websocket.
-mettre à jour le html
Au final le résultat est exactement le même qu'avec un lien classique
Mis à part que cela revient effectivement à recoder le comportement de "ton" navigateur, comment se passe le clic central? Ou le "clic droit/ouvrir dans un nouvel onglet"? ou le "Ctrl+clic"? Ou la préférence utilisateur "ouvrir les liens dans de nouveaux onglets" (ou même de nouvelles fenêtres)?
Si vous ne voulez qu'envoyer le moins de données possibles, faites du XML/XSL: envoyez le XML avec une référence au XSL et laissez faire le navigateur. Je doute d'ailleurs de l'efficacité du "ça charge plus vite", car on génère des tas de JS qui demandent eux aussi du temps pour s'exécuter. Perso, j'ai déjà vu des sites (FB justement, ou dA) qui rament franchement à cause de ces JS.
Et heu, niahoo, je ne parle pas de dégager toute forme de JS: le sujet est l'ergonomie et la perception par les utilisateurs d'un site mono-pagé à coup de JS.
RE: Sites "mono-page" - niahoo - 19-02-2016
mais les liens ce sont des liens ... si tu cliques molette, ça ouvre un nouvel onglet. On l'a déjà dit plusieurs fois, ça suit le comportement normal du HTML.
RE: Sites "mono-page" - Ter Rowan - 22-02-2016
ç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.
maintenant, moi j'aime pas les "one page" perso et j'aime bien javascript, du coup j'ai pas d'amis dans cette discussion
hahaha
RE: Sites "mono-page" - niahoo - 22-02-2016
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.
RE: Sites "mono-page" - Sephi-Chan - 22-02-2016
Je pense que sur la page de jeu, on se fout de "l'expérience HTML", et qu'on a tout intérêt à essayer de la gommer : ça n'intéresse pas grand monde un jeu à tableau avec des formulaires. On a tout intérêt à enrichir l'expérience, de manière progressive si on se soucie de l'accessibilité.
Du coup, les React, Marionnette, Angular et compagnie deviennent intéressants.