Flash n'est pas toujours justifié

Hello,

J'passe par ici, je sais qu'il y a pas mal de codeurs dans le coin... Je viens vous présenter la nouvelle version de mon site, pour lequel j'ai décidé de mettre en application le concept que je clame souvent : Flash n'est pas toujours justifié, même quand il s'agit d'intéractivité et d'animations simples. J'ai donc fait le site entièrement sous forme d'intéractions et d'animations JavaScript.

Vos commentaires/remarques/suggestions sont les bienvenus

Le site en question : http://www.sebcreation.com/

Ce serait cool si vous pouviez prendre le temps de me donner vos impressions, le site n'est pas figé, je vais surement le faire évoluer encore un peu, pour le moment j'ai posé les bases

Merci !

Exemple : Le back navigateur du portfolio n'est pas (encore) géré

J'me sens seul sur le thread

meuh non t'es pas tout seul

Effectivement on est presque dans du" flash-like" sans les inconvénients majeurs... ça marche bien JS désactivé aussi. En revanche l'accueil supporte mal l'agrandissement manuel des polices (l'effet calque devrait suivre...) et CSS désactivées, l'omniprésence de ton image de fond chasse les infos utiles en bas de page.

Cette approche Dhtml (ouuuuuh le vilain mot diront certains) n'est pas nouvelle ; je lui reprocherais juste d'être au service du design et pas de l'utilisateur. Celui-ci n'y trouve aucun gain. Il y a certainement une réflexion à mener pour justifier la présence de ces effets autre qu'une (supposée) séduction visuelle.

Re,

Super intéressantes vos remarques merci

Pour la lib j'utilise déjà mootools mais j'ai pas pris le temps de l'optimiser en effet.

Arsene a écrit :
Cette approche Dhtml (ouuuuuh le vilain mot diront certains) n'est pas nouvelle ; je lui reprocherais juste d'être au service du design et pas de l'utilisateur. Celui-ci n'y trouve aucun gain. Il y a certainement une réflexion à mener pour justifier la présence de ces effets autre qu'une (supposée) séduction visuelle.

Très très juste en effet, je pense que je devrais plutôt travailler dans ce sens là, celà dit si ce travail me permet d'avoir ce type de réflexions sur des nouveaux projets je serais très satisfait

Ca marche très bien en JS désactivé et ça c'est une bonne chose, un peu plus embetant avec CSS desactivé, l'image de fond prends trop d'importance.

Sinon je trouve cela un peu trop long de changer de page, attendre que tout se referme, puis se réouvre, c'est joli mais rapidement j'ai désactivé JS pour pouvoir naviguer correctement. Pourquoi ne pas tout fermer d'un coup plutot que de fermer les uns après les autres ?

Et il faut attendre que tout soit chargé pour cliquer sur les liens, c'est dommage.

Ah et, sur pfizer.html

Warning: main(inc/navigation.inc) [function.main]: failed to open stream: No such file or directory in /homez.41/sebcreat/www/realisation-site-internet/index.php on line 91

Warning: main() [function.include]: Failed opening 'inc/navigation.inc' for inclusion (include_path='.:/usr/local/lib/php') in /homez.41/sebcreat/www/realisation-site-internet/index.php on line 91

Seoplayer a écrit :
Hello,

J'passe par ici, je sais qu'il y a pas mal de codeurs dans le coin... Je viens vous présenter la nouvelle version de mon site, pour lequel j'ai décidé de mettre en application le concept que je clame souvent : Flash n'est pas toujours justifié, même quand il s'agit d'intéractivité et d'animations simples. J'ai donc fait le site entièrement sous forme d'intéractions et d'animations JavaScript.

Vos commentaires/remarques/suggestions sont les bienvenus

Le site en question : http://www.sebcreation.com/

Ce serait cool si vous pouviez prendre le temps de me donner vos impressions, le site n'est pas figé, je vais surement le faire évoluer encore un peu, pour le moment j'ai posé les bases

Merci !

Félicitations, excellente démo technique.

matmat a écrit :

Tu as aussi jquery, question poid jquery c'est un peu de la triche parce sur le site il te disent 15k, alors que ça pèse jamais moins de 30 pour les versions récente et encore "packed" ce qui n'est pas forcement avantageux (20k de moins mais plus de travail pour le cpu). Bref tu peux compter sur un bon 40k ce qui reste correcte. Par contre ce n'est pas modulaire.

15Ko c'est pour la version gzipée

SolMJ a écrit :
15Ko c'est pour la version gzipée

Je ne sais pas si le gzipage à la volée est réellement super vue que l'opération est réalisé sur le coup, peut être que la microseconde de gzipage revient un peu au même que la microseconde de chargement, surtout pour des petits scripts, par contre j'avais fait des essais avec ce script http://farhadi.ir/works/smartoptimizer (hallucinant ) , c'est vraiment épatant, mais il n'y a t-il aucune contre indication par rapport à l'usage du cpu du visiteur? Ou est ce réellement la méthode magique?

A noter aussi que de mettre les scripts à la fin du html (avant </body>) assure une grande fluidité de chargement. Bien sûr dans ce cas on ne peut pas mettre de pré-chargement, mais de tout façon je ne crois pas que ce soit une bonne idée il vaut mieux laisser le html se charger naturellement, le javascript venant après.
Modifié par matmat (01 Oct 2008 - 17:10)

Wow désolé j'avais pas vu les réponses.

Tymlis a écrit :
Ca marche très bien en JS désactivé et ça c'est une bonne chose, un peu plus embetant avec CSS desactivé, l'image de fond prends trop d'importance.

L'image de fond prend trop d'importance avec js désactivé en effet, malheureusement techniquement j'étais obligé de la mettre de cette manière dans le code HTML.

Tymlis a écrit :
Sinon je trouve cela un peu trop long de changer de page, attendre que tout se referme, puis se réouvre, c'est joli mais rapidement j'ai désactivé JS pour pouvoir naviguer correctement. Pourquoi ne pas tout fermer d'un coup plutot que de fermer les uns après les autres ?

Ca c'est pour l'effet "Flashy" en fait, c'est pas nécessaire et même injustifé je reconnais...

Tymlis a écrit :
Et il faut attendre que tout soit chargé pour cliquer sur les liens, c'est dommage.

Je suis obligé de temporiser en fait, je désactive tout pour ne pas faire bugger le script pendant qu'il y a des exécutions.

Tymlis a écrit :
Ah et, sur pfizer.html

Warning: main(inc/navigation.inc) [function.main]: failed to open stream: No such file or directory in /homez.41/sebcreat/www/realisation-site-internet/index.php on line 91

Warning: main() [function.include]: Failed opening 'inc/navigation.inc' for inclusion (include_path='.:/usr/local/lib/php') in /homez.41/sebcreat/www/realisation-site-internet/index.php on line 91

Merci, j'ai réglé le problème, çà venait de ma réécriture d'url

SolMJ a écrit :


Félicitations, excellente démo technique.



15Ko c'est pour la version gzipée

J'me tate pour jquery en fait, je vais quand même prendre le temps de regarder comment il tourne

matmat a écrit :


Je ne sais pas si le gzipage à la volée est réellement super vue que l'opération est réalisé sur le coup, peut être que la microseconde de gzipage revient un peu au même que la microseconde de chargement, surtout pour des petits scripts, par contre j'avais fait des essais avec ce script http://farhadi.ir/works/smartoptimizer (hallucinant ) , c'est vraiment épatant, mais il n'y a t-il aucune contre indication par rapport à l'usage du cpu du visiteur? Ou est ce réellement la méthode magique?

A noter aussi que de mettre les scripts à la fin du html (avant </body>) assure une grande fluidité de chargement. Bien sûr dans ce cas on ne peut pas mettre de pré-chargement, mais de tout façon je ne crois pas que ce soit une bonne idée il vaut mieux laisser le html se charger naturellement, le javascript venant après.

En effet, j'ai choisis une méthode de compression appelé jsmin et je changerais, ni pour la methode packer (avec l'eval) ni pour le gzip, car comme tu l'indique on gagne surement en loading mais après faut que le nav' bosse et c'est du coup une optimisation pas nécessaire... sauf pour gagner en bande passante éventuellement*.

JSMIN dont je parle : http://code.google.com/p/jsmin-php/

EDIT : *Je préfère privilégier les utilisateurs que la bande passante.
Modifié par Seoplayer (03 Oct 2008 - 15:03)

Tymlis a écrit :
Rien ne t'empeches d'utiliser JSMin (fichier compressé sur le disque) et gzip (fichier compressé à l'envoi au client), et en plus avec un cache en ExpiresByType text/js "access plus 10 years", tu le garde dans le cache de tes utilisateurs longtemps, ne les obligeant pas à les recharger.

Un fois qu'un js est dans le cache qu'il soit envoyé zipper ou pas c'est un peu pareil. Par contre au premier envoie le fichier gziper et beaucoup plus léger (30/40% de l'original même déjà minifier).

La question est de donc de savoir combien de temps met le navigateur à dégziper le js à sa réception, je n'ai pas trouvé de benchmark sur le sujet, seulement quelques infos éparses qui expliquent que cela dépend du poid de fichier et de la vitesse de connexion. En gros si le fichier et lourd et la connexion lente le gain et très intéressant. Par contre ou est la limite (5k, 10k, 20k... ) aucune idée.

matmat a écrit :
Un fois qu'un js est dans le cache qu'il soit envoyé zipper ou pas c'est un peu pareil. Par contre au premier envoie le fichier gziper et beaucoup plus léger (30/40% de l'original même déjà minifier).

Hmm, je ne comprends pas ton point ?
Si j'envoie un fichier compressé avec JSMin, cela sera plus bénéfique pour l'utilisateur que si je lui envoi brut.
Si j'envoie un fichier gzippé à l'utilisateur (compressé ou non), cela sera plus bénéfique à l'utilisateur aussi.
Si l'utilisateur revient sur la page ultérieurement, il n'aura plus rien à télécharger.

Le cpu du serveur travaille un peu plus pour gzipper le fichier avant de l'envoyer mais c'est complétement négligeable. Le navigateur qui le recoit aussi j'imagine.

Tymlis a écrit :
Hmm, je ne comprends pas ton point ?

En fait il n'y a pas vraiment d'affirmation j'essaye juste de comprendre le gzippage.

Tymlis a écrit :
Le cpu du serveur travaille un peu plus pour gzipper le fichier avant de l'envoyer mais c'est complétement négligeable. Le navigateur qui le recoit aussi j'imagine.

Sur le premier point, c'est vrai que c'est négligeable, en plus cela peut être évité par une mise en cache du fichier gzipper. C'est sur le deuxième point que je me pose la question pour les petits fichiers. Mais comme je viens de voir par exemple Google gzippe quasi systématiquement leur js je crois que tu m'as convaincu pour gzippage.

Arsene a écrit :
Effectivement on est presque dans du" flash-like" sans les inconvénients majeurs...

J'ai trouvé deux inconvénients majeurs de beaucoup de sites en flash (mais pas inhérents à la technologie), qui sont les suivants:

1. Une URL qui n'est pas mise à jour. Depuis l'accueil, on peut charger chaque page du portfolio avec son URL propre, et c'est bien (notamment pour le référencement). Mais une fois sur une page de portfolio, le changement de page ne fait pas bouger l'URL. Donc problème pour bookmarquer, envoyer le lien, etc.

2. Les animations, le mouvement, c'est bien... quand ça a un sens. Un élément qui bouge avec à travers la page ou vibre, ça peut servir à attirer l'attention sur un contenu qui est modifié, par exemple. C'est ce que tu fais dans les pages portfolio. Par contre, sur la page d'accueil:
- pourquoi ça prend trois plombes à se mettre en place? ça veut dire quoi ce chargement progressif?
- pourquoi quand je charge un contenu ça replie tout, passe au noir, et déploie d'autres blocs? ça veut dire quoi tout ça?

Bon, c'est peut-être moi, mais ce genre de transition inutile (sauf pour en mettre plein la vue) m'insupporte. Et je pense que ça nuit à l'ergonomie des sites qui les emploient, qu'ils soient en Flash ou en HTML/CSS/JS.

(Sinon bien dans l'ensemble, techniquement réussi même si un peu gourmand en CPU sur mon iMac neuf..., design très sympa.)
Modifié par Florent V. (04 Oct 2008 - 19:25)

Seoplayer a écrit :
ni pour la methode packer (avec l'eval) ni pour le gzip, car comme tu l'indique on gagne surement en loading mais après faut que le nav' bosse et c'est du coup une optimisation pas nécessaire

Oui pour packer, qui demande pas mal de boulot au navigateur parait-il. Par contre, la décompression du gzip est gérée non pas par l'interpréteur javascript, mais par des parties bien plus performantes du navigateur (du code compilé qui va vite), donc c'est presque négligeable (parait-il, une fois de plus). Pour les scripts JS, JSMin + compression gzip, c'est bien (et c'est ce qui donne le chiffre de 15 Ko annoncé par jQuery).