[problematique]couper une page trop longue

rog · 5 Décembre 2007

bon je prepare un site autobiographique (oui c'est sur moi-même - lol)

je narre certains episodes qui font souvent 2 ou 3 pages word

comme je n'aime pas les pages avec des scroll interminables, je ne veux pas les imposer à mes visiteurs

donc il faut que je coupe le texte à hauteur d'ecran

j'ai pensé à une multitude de solutions et je me suis arrêté à celle-ci

le texte serait decoupé en plusieurs partie representées par des variables dans une fonction javascript style

var ini = 1ere partie
var suite1 = la suite
var suite2 = encore la suite
var fin = la fin

ce serait plutot un array mais c'est pour l'exemple

j'aurai une fonction display_div(index,div_name)

qui placerait le contenu dans la div, me permettant de placer des liens suite ou precedent noir meme des index de navigation

sans avoir fait de tests je presume que c'est la methode qui chargera le texte le plus vite dans la page

mais mes questions sont :

- est-ce la meilleure solution
- et google dans tout ça ?

rog

SpeedAirMan · 5 Décembre 2007

Bonjour rog,

personnellement, je te déconseille de procéder de cette manière ;-)

Je lis actuellement beaucoup d'articles et un livre sur l'utilisabilité. C'est très très interressant et on en apprends beaucoup sur le comportement des internautes.
Par exemple, même si JavaScript est très souvent supporté (+ de 90%), il arrive qu'il soit désactivé. De plus, le JavaScript s'execute côté client et peut parfois être mal interprété ou faire ralentir la machine. Puis pourquoi cacher du texte... ?

Concernant les textes écrits pour le web, une bonne pratique est de faire court et concis. Les internautes n'aiment pas lire, ils ont tendance à scanner la page à la recherche d'informations qu'ils cherchent. Il faut donc bien structurer le texte, mettre les termes importants en gras, faire des titres et sous-titres, faciliter la lecture des énumérations en créant des listes etc.

Il faut également veiller à ce que les lignes de textes ne soient pas trop longues. 60 - 70 caractères par ligne est optimal j'ai lu, mais ça me parait peu...
Les lignes de textes trop longues (largeur de la page) sont plus difficiles à lire.
Il faut également faire des phrases courtes, et accessibles au plus grand nombre, à part si ton site est très spécialisé et que ton public est connaisseur.
Il faut utiliser un langage et des mots qu'un homme d'un niveau de 4ème pourrait comprendre.

sans avoir fait de tests je presume que c'est la methode qui chargera le texte le plus vite dans la page

Encore une fois : quel est l'interêt de charger du texte que personne ne lira ?
Si tu le cache, sache que peu de personnes cliqueront pour dévoiler le texte.
Je te suggère plutôt de travailler tes textes afin qu'ils soient divisés en parties distinctes, et de séparer ces parties en pages différentes.
Exemple : chapitre 1 = page 1, chapitre 2 = page 2 etc.
De cette manière il n'y aura pas de page interminable à scroller.

à réfléchir... ;-)

dop20vt · 5 Décembre 2007

Au plus simple, tu divises tes textes en plusieurs pages html avec un lien vers la page suivante sur chacune d'elles ... non ?? :roll:

SpeedAirMan · 5 Décembre 2007

dop20vt a dit:
Au plus simple, tu divises tes textes en plusieurs pages html avec un lien vers la page suivante sur chacune d'elles ... non ?? :roll:

merci de résumer ce que j'ai dit :lol:

rog · 5 Décembre 2007

oui mais on va dire que tout est fait pour mettre une pression sur le lecteur pour qu'il lise tout le texte

comme je veux absolument éviter le scroll, je dois trouver la methode la plus rapide possible pour afficher la suite du contenu et maintenir la pression

hors afficher un texte deja present dans le navigateur va générer un flux client/client qui sera toujours plus rapide qu'un echange de flux client/server

je pensais aussi à les insérer toutes en display:none et coller un javascript qui modifierait la propriété de la methode display mais je crain les foudres de google

la question principale est quand même est-ce que google va référencer le texte contenu dans mes variables javascript (je ne pense pas mais je vous consulte)

rog

ybet · 5 Décembre 2007

C'est une vision, mais si quelqu'un est intéressé par un article, il va jusqu'au bout. Sinon, que le texte soit coupé en petit morceau ou non, il quitte de toute façon.

Avantage des petites pages, plus facile à monter sur une grosse requête. Avantage des grosses pages, plus de visiteurs sur des requêtes moins généralistes. Et par expérience, c'est souvent le deuxième type qui ammène plus de visiteurs.

rog · 5 Décembre 2007

et oui

mon but est de faire intégrer la totalité du texte au moteur

rog

nickargall · 5 Décembre 2007

rog a dit:
je pensais aussi à les insérer toutes en display:none et coller un javascript qui modifierait la propriété de la methode display mais je crain les foudres de google

Disons que normalement, un inspecteur Google humain pas trop bête verra que ce contenu peut être rendu visible facilement sur la page, et ne devrait pas sanctionner le site.

rog a dit:
la question principale est quand même est-ce que google va référencer le texte contenu dans mes variables javascript (je ne pense pas mais je vous consulte)
rog

Là c'est vraiment pas sûr du tout. La seule façon totalement sûr de pas être sanctionné et de pouvoir déclarer tout ton contenu sera de le découper en plusieurs pages HTML, avec pagination, et des éléments d'entête (title et meta desc) différents

SpeedAirMan · 5 Décembre 2007

C'est une vision, mais si quelqu'un est intéressé par un article, il va jusqu'au bout. Sinon, que le texte soit coupé en petit morceau ou non, il quitte de toute façon.

Pas une vision, une observation partie de constatations et qui donnent des statistiques. Ce n'est pas juste un avis

Mais je suis tout à fait d'accord que quand on est interressé par un article : on le lit jusqu'au bout. Mais les statistiques sont là. On écrit pour attirer du monde via les moteurs, mais aussi pour informer les visiteurs. Donc quand ils arrivent, il faut qu'ils soient attirer par le texte et ai envi de le lire, pour rester plus longtemps par exemple.
Donc : ne pas donner des blocs de textes impossible à digérer.

Ok, admettons que Google référence ta page entière, même les parties cachées. Si quelqu'un tombe sur ton site après avoir tapé un mot clé dans un moteur de recherche, et que ce mot clé se réfère à une partie cachée : ton visiteur se sentira perdu et aura eu l'impression de se faire avoir. Il ne reviendra pas.
Prends donc soin que ton site soit très facilement utilisable et que les visiteurs comprennent tout de suite comment afficher les parties cachées, et ce qu'ils y trouveront.
à partir du moment où on doit expliquer comment fonctionne un menu, on peut se dire que ce menu n'est pas facilement utilisable / intuitif.

julienr · 5 Décembre 2007

pas de variable js pour le ref c'est évident mais par contre des divisions + css c'est mieux

<div>premiere<p style="display:none">deuxieme<p style="display:none">troiseme</p></p></div>

j'ai fait un truc comme cela uniquement en css avec le :hover et le hack qui va bien pour ie, je pense et j'espère que ce n'est pas sanctionnable, puisque qu'en effet sur le onmouseover le contenu apparait

Florent V. · 5 Décembre 2007

rog a dit:
la question principale est quand même est-ce que google va référencer le texte contenu dans mes variables javascript

Non (du moins pas à l'heure actuelle). Ce texte ne sera accessible ni aux moteurs, ni aux internautes qui ne disposent pas de Javascript (pour diverses raisons sur lesquelles je ne reviens pas).

rog a dit:
je pensais aussi à les insérer toutes en display:none et coller un javascript qui modifierait la propriété de la methode display mais je crain les foudres de google

C'est déjà mieux, mais pour les utilisateurs qui n'ont pas Javascript il y a une partie du contenu qui sera toujours cachée, donc inaccessible.

En général, si on veut faire de l'unobtrusive javascript tip top, on cachera les éléments à cacher via Javascript.

On peut avoir une structure comme suit:

Code:

<h1>Titre de mon article</h1>

<h2>Sommaire:</h2>
<ul>
	<li><a href="#partie1">Première partie</a></li>
	<li><a href="#partie2">Deuxième partie</a></li>
	<li><a href="#partie3">Troisième partie</a></li>
</ul>

<div id="partie1">
	<h2>Titre de la première partie</h2>
	<p>Contenu de la première partie</p>
</div>

<div id="partie2">
	<h2>Titre de la deuxième partie</h2>
	<p>Contenu de la deuxième partie</p>
</div>

<div id="partie3">
	<h2>Titre de la troisième partie</h2>
	<p>Contenu de la troisième partie</p>
</div>

En Javascript, au chargement de la page, tu:
- cache les parties 2 à N;
- intercepte le clic sur les liens du sommaire;
- lors du clic sur un lien du sommaire, afficher le bloc correspondant et cacher les autres blocs.

Mode "enhanced" avec Javascript: tu obtiens l'effet voulu.
Mode "basic" sans Javascript: tu as tout ton contenu, correctement structuré, avec des liens d'accès rapide aux différentes parties de l'article pour faciliter la navigation interne.

Que demande le peuple? :wink:

Elvis · 5 Décembre 2007

Il faut utiliser un langage et des mots qu'un homme d'un niveau de 4ème pourrait comprendre.

Je trouve débile d'utiliser volontairement un langage appauvri quand on a les possibilités de rédiger quelque chose de riche, sur Internet, le monde de l'information... Quand on cherche des infos sur le net on veut se renseigner, apprendre, progresser. Je pense pas que des mots et des structures soutenues puissent être un frein qui passe l'envie aux gens de lire une page. Bien au contraire !

'fin bon, si c'est une étude qui le dit :wink: Le but poursuivi par le webmaster doit y être pour beaucoup.

Sinon pour en revenir au sujet, je pense que tu n'as pas à t'inquiéter pour l'indexation d'un contenu masqué en javascript.
Si je cherche sur google du texte qui est masqué en javascript sur mon forum, google m'affiche les pages en question et le texte originellement masqué dans la description.

Florent V. · 5 Décembre 2007

julienr a dit:
j'ai fait un truc comme cela uniquement en css avec le :hover et le hack qui va bien pour ie, je pense et j'espère que ce n'est pas sanctionnable, puisque qu'en effet sur le onmouseover le contenu apparait

Plutôt que de détourner CSS de son usage «normal», on peut sans doute utiliser Javascript qui est fait pour ça... :wink:

dop20vt · 5 Décembre 2007

Je plussoie florent pour l'utilisation du javascript !!

C'est d'ailleurs ce que je fais pour le menu de mon www entre autre !! Le seul "problème" est que pendant le chargement de la page, tout le texte est visible et les parties à cacher disparaisse après !! Ce n'est pas très sexy !! C'est pour cela que j'utilise un preloader !!

julienr · 5 Décembre 2007

c'est quoi çà, c'est sale maintenant d'utiliser le css ?!

nickargall · 5 Décembre 2007

[HS]Ne déviez pas du topic sinon Rog va vous killer avec sa pétoire

[/HS]

dop20vt · 5 Décembre 2007

julienr a dit:
c'est quoi çà, c'est sale maintenant d'utiliser le css ?!

Bah ca n'a rien de sal ... ton corps change c'est normal :!:

A part que d'utiliser un hack soit plus discutable et surtout laisser la souris en survole du lien pour garder le texte en display: block n'est pas ce qui se fait de plus convivial ... et si il faut scroller même un minimum le texte afiiché ... c'est mort

En java les robots d'indexation verront tout le contenu !!

nickargall · 5 Décembre 2007

C'est le but, que les robots voient tout le contenu.

julienr · 5 Décembre 2007

pour ce qui est du sujet de ce post, c'est claire qu'il ne faut pas le contenu dans une structuration javascript quelconque pour qu'il soit indexable

je "déviais" à propos de ton site et de ton "loader" : pourquoi ne pas générer ton menu en gérant du css ?!

serval2a · 5 Décembre 2007

Et pourquoi pas Ajax + cloaking ?

nickargall · 5 Décembre 2007

Parce que l'Ajax ne convient pas au référencement et que le cloacking encore moins ...

MirageDemonAsh · 5 Décembre 2007

Ou bien utiliser les ancres (c'est old school mais ça fonctionne bien) vu que ton but premier était de soulager l'index :

Première partie : Suite

Seconde partie : Suite - Retour

Troisième partie : Retour

On passe d'une partie à l'autre instantanément puisque la page est chargée depuis longtemps.

Le tout est de savoir si c'est bon ou pas pour le ref.

Sinon un avis perso d'utilisateur : le miens : j'aime pas scroller et j'aime pas attendre quand je clique pour la page suivante. Le système d'ancre est un bon compromis.

rog a dit:
edit :
les ancres impliqueraient le scrool qui fait 3 pages word

Non, pas de roulette puisque c'est la même chose, sauf que c'est en une page. Tu cliques et ça monte ou descend tout seul pour se cadrer là où tu veux, en fonction de comment tu organises ceci. Cependant, niveau accessibilité je sais pas si c'est une bonne chose (à tester avec lynx)

nickargall · 5 Décembre 2007

Les ancres ne sont pas interprétées par le ref, donc yaura pas de souci.
Pas bête, on pense jamais aux choses les plus simples

Ca peut même être un contenu entier dans une div avec overflow auto et en effet un système d'ancre à l'intérieur pour arriver de suite au contenu. Avec un menu reprenant les titres des chapitres de ton contenu, hop on clique dessus et la div se positionne au chapitre voulu.

rog · 5 Décembre 2007

@nickargall

Ne déviez pas du topic sinon Rog va vous killer avec sa pétoire

lol - hier j'etais un peu enervé mais ça y est je me suis calmé

pour ce qui est des conseils, c'est très interessant

pour le css on depend de toutes façons du javascript et d'un evennemet OnQuelquechose

j'entrevoi la possibilité de le faire en js/css du style au chargement j'ai mon texte en clair

Code:

<div id="t1" style="display:inline">premiere</div>
<div id="t2" style="display:inline">deuxième</div>
<div id="t3" style="display:inline">troisième</div>

ensuite j'appelle un js onload qui va faire une boucle pour cacher les div sauf le premier

Code:

getElementById(t2).style.display = "none"
getElementById(t3).style.display = "none"

je n'aurai plus qu'à mettre mes liens avec un onclick sur une autre fonction qui met tous les display à none sauf celui concervé par le lien auquel on attribuera inline ou autre (faut que je vois les propriétés possibles)

lol

qu'est ce que vous en pensez ?

edit :
les ancres impliqueraient le scrool qui fait 3 pages word

julienr · 5 Décembre 2007

ok le seul soucis c'est le onload qui peut etre long si la page est lourde et qui provoquera un clignottement...

rog · 5 Décembre 2007

lol - la c'est plus qu'un soucis

je pense de plus en plus à une solution html differente pour les navigateurs avec js activé et les autres

auquel cas la page chargerait avec le premier div visible et les autres cachées

et les liens passeraient les divs non cachées en cachées et ouvriraient une visibilité pour la div concernée par le lien

est ce que ça clignotera encore ?

rog

Florent V. · 5 Décembre 2007

julienr a dit:
c'est quoi çà, c'est sale maintenant d'utiliser le css ?!

Non, il s'agit d'utiliser chaque langage en fonction de ses caractéristiques propres.

Ça fait des années que le principe suivant est expliqué en long, en large et en travers:
- contenu = HTML;
- comportement = JavaScript;
- mise en forme = CSS.
Ce n'est donc pas très nouveau...

Mais il est vrai que ce principe est mieux établi dans le web anglophone que dans le web francophone (ou du moins français).

Quant au fait de ne pas conditionner l'accès à un contenu à la disponibilité de JavaScript ou de CSS, c'est un principe d'accessibilité au sens large (c'est à dire ne touchant pas que les handicapés, mais potentiellement tous les utilisateurs, ainsi que les moteurs de recherche en l'occurrence).

julienr · 5 Décembre 2007

la question c'est, est-ce qu'au niveau réf, c'est mal vu de faire ceci ?

Code:

<div id="t1" style="display:inline">premiere</div>
<div id="t2" style="display:none">deuxième</div>
<div id="t3" style="display:none">troisième</div>

Florent V. · 5 Décembre 2007

rog a dit:
lol - la c'est plus qu'un soucis

Sur une page bien écrite et correctement optimisée, ça peut être invisible. Mais il est vrai qu'on a pas toujours le contrôle sur tout (et que optimiser c'est pas toujours facile).

Pour une solution intéressante, on peut sans doute se référer à ceci:
http://forum.alsacreations.com/topic-5- ... ctive.html

C'est moins fiable que d'utiliser uniquement une fonction JavaScript pour masquer les éléments à masquer, mais c'est un bon compromis.

julienr · 5 Décembre 2007

Florent V. a dit:
Sur une page bien écrite et correctement optimisée, ça peut être invisible.

bande passante faible, serveur surchargé plutot :roll:

rog · 5 Décembre 2007

@julienr

c'est certainement mal vu mais je vais cloacker,

la fonction get_browser m'indiquera si le navigateur a le js activé et le fichier browscap.ini est si je me souviens bien assez facile à installer

du coup, je renverrai une page avec mon texte en entier vers les clients qui n'interpretent pas le js

et une autre avec les div N+ en display=none vers les clients qui interpretent le js

ensuite je mettrai une fonction js avec surcharge de la classe css de la div à afficher

ça m'a l'air d'être un bon compromi sauf si ça clignotte

lol

rog

Elvis · 5 Décembre 2007

J'ai encore vérifié sur d'autres sites dont le contenu d'une page est masqué avec CSS puis affiché en javascript, et le contenu masqué est bel et bien référencé.
Donc google référence le texte, peu importe qu'à l'écran on le voit ou pas...

SpeedAirMan · 6 Décembre 2007

Un exemple de ce que tu veux faire : http://www.pkto.ca/parkour.php
(je n'ai pas regardé ni CSS ni JavaScript de la page)

Szarah · 6 Décembre 2007

Et des onglets bien propres en Ajax ?

rog · 6 Décembre 2007

excuses moi szarah, ton post est arrivé après ma reponse

le probleme est qu'ajax n'est pas pris en compte par les moteurs

@elvis
cool comme nouvelle

@spiderman

la c'est vraiment de la balle, un peu du style 100% ce que je recherchais

lol

rog

SpeedAirMan · 6 Décembre 2007

rog a dit:
@spiderman

la c'est vraiment de la balle, un peu du style 100% ce que je recherchais

lol

Cool, content d'avoir pu t'aider, mais au passage c'est SpeedAirMan , ou bien Jerome (au choix)

C'est le site d'un ami. ça fait des heures que je m'inspire du contenu de cette page pour construire ma propre FAQ (en Français) également sur parkour.net , puis d'un coup j'me suis dit : "tiens, c'est exactement le sujet d'un topic de WRI !", alors voilà, hop ^^

Bon, j'arrête de raconter ma vie lol , je sors :arrow: [ ]

rog · 7 Décembre 2007

ok SpeedAirMan je pensais que ton nick avait un lien avec spiderman

en fait le system vient d'ici

* DOMcollapse
* Version 3.0
* released 06.12.2005
* Not for commercial reselling or use, unless consent given by the author
* Check for updates on http://onlinetools.org and http://wait-till-i.com
*

je vais aller faire un tour sur le site de l'editeur

rog

SpeedAirMan · 7 Décembre 2007

rog a dit:
ok SpeedAirMan je pensais que ton nick avait un lien avec spiderman

Mon pseudo vient de cette video : http://parkour-videos.com/speed-air-man-david-belle/
C'est la première vidéo de parkour que j'ai vu, et ça a été un choc 8O
Il y'a un lien avec SpiderMan : la façon de se déplacer qui est assez particulière

en fait le system vient d'ici

* DOMcollapse
* Version 3.0
* released 06.12.2005
* Not for commercial reselling or use, unless consent given by the author
* Check for updates on http://onlinetools.org and http://wait-till-i.com
*

Cliquez pour agrandir...

je vais aller faire un tour sur le site de l'editeur

Je serai curieux de voir le résultat, donc quand tu auras pondu quelque chose, n'hésite pas à nous faire partager/montrer ^^

rog · 7 Décembre 2007

la nouvelle version c'est de la balle

http://onlinetools.org/tools/yuidomcollapse/

rog

SpeedAirMan · 7 Décembre 2007

rog a dit:
la nouvelle version c'est de la balle

http://onlinetools.org/tools/yuidomcollapse/

rog

ça rox, rog ! :-D

Bon ok je sors :arrow: [ ]

(... mais il est très bien en effet !)

Vap · 8 Décembre 2007

SpeedAirMan a dit:
Il faut également veiller à ce que les lignes de textes ne soient pas trop longues. 60 - 70 caractères par ligne est optimal j'ai lu, mais ça me parait peu...

C'est pour qu'elles s'impriment correctement. Plus longues elles seraient tronquées à l'impression.

Mais si on fait un style différent pour l'impression et l'écran, la lnguer des ligens à l'écran n'est pas nécessairement limitée.

Vap

rog · 8 Décembre 2007

lnguer des ligens

diner un peu trop arrosé ?

j'ai testé les libs avec opera et js desactivé, c'est nickel

rog

Audiofeeline · 10 Décembre 2007

julienr a dit:
c'est quoi çà, c'est sale maintenant d'utiliser le css ?!

c'est clair ! lol

Sinon, je vais peut être dire une connerie mais pourquoi ne pas faire un chapeau à tes articles, c'est généralement ce qui se passe sur les blog quand on fait un article très long.

rog · 13 Décembre 2007

edit :
j'ai telechargé ses codes, le mec les obfusqué à mort et ça a l'air d'une usine à gaz

je vais donc coder quelques fonctions pour surcharger les classes css

rog