1485 sujets
Web Mobile et responsive web design
petit up
j'ai peut être mal explicité ma question.
Par exemple, il y a yahoo!blueprint qui permet de créer des sites web en html et xhtml pour n'importe quel navigateur mobile :
http://www.generation-nt.com/yahoo-blueprint-environnement-developpement-plateforme-mobile-actualite-152341.html
Je voudrais savoir si quelqu'un l'a essayé et peut me fournir un retour de son expérience.
Ou si quelqu'un en utilise un autre et qui souhaite me le conseiller.
Merci d'avance
Modifié par soulmaster (13 Nov 2008 - 22:28)
j'ai peut être mal explicité ma question.
Par exemple, il y a yahoo!blueprint qui permet de créer des sites web en html et xhtml pour n'importe quel navigateur mobile :
http://www.generation-nt.com/yahoo-blueprint-environnement-developpement-plateforme-mobile-actualite-152341.html
Je voudrais savoir si quelqu'un l'a essayé et peut me fournir un retour de son expérience.
Ou si quelqu'un en utilise un autre et qui souhaite me le conseiller.
Merci d'avance
Modifié par soulmaster (13 Nov 2008 - 22:28)
En règle générale je me méfie des API. En règle particulière je me méfie de Yahoo (et Google aussi, mais pas que). Qu'on s'appuie sur une API pour obtenir un résultat spécifique sur l'une ou l'autre page web, oui ; qu'on construise un site complet à partir d'un outil dont on ne maîtrise ni la conception ni le développement me paraît casse-gueule. C'est pas que ça marche pas, c'est que ça peut devenir vite obsolète ou contraignant. On le voit dans le web "classique" où des développeurs basent tout leur projet sur Prototype ou Motools ou jQuery ou je ne sais quoi, et qui un moment ont besoin d'un truc non-prévu dans l'outil : c'est le début de la bidouille, de la bricole, du bout de code instable, et c'est toujours l'interopérabilité, l'utilisabilité ou l'accessibilité (donc l'utilisateur final) qui trinque.
Y!Blueprint s'appuie sur des objets préconçus écrits en XML. Outre la question des objets "non-prévus" se pose celle de la réutilisation très problématique de ces bouts de code dans des pages web "classique"... en gros Y!Blueprint produit du site uniquement mobile. Alors soit on développe un produit pour mobiles uniquement et ça peut (sous réserve) être intéressant de s'appuyer là-dessus, sûrement, soit on produit des contenus web pour tous. Y!Blueprint fait le pari que le développement du web mobile est un développement séparé, autonome, et donc qu'il existe "des webs" distincts évoluant concurremment en parallèle (pour mobiles, pour écrans, pour handicapés, pour ceci ou pour cela).
Alors qu'en respectant les conseils et recommandations du lien donné par Hermann dans le post précédent on obtient des résultats satisfaisants. Satisfaisant ça veut pas dire qu'on garantit grand'chose, ça veut juste dire que quel que soit l'orientation que prendra la conception/production de sites utilisables sur mobiles dans les années qui viennent (pour l'instant on balbutie encore et personne ne peut dire où tout ça ira, ça dépendra surtout des usages attendus/demandés par les utilisateurs) on sera à même de rendre nos sites rapidement compatibles et opérationnels. En s'appuyant sur ces genres d'API c'est pas aussi sûr. Sans parler du coût en énergie (humaine, technique, économique) et en temps que nécessite la production, la maintenance et la gestion de sites distincts.
Donc pour conclure ça ne produit pas des sites web en xhtml multi-supports, ça produit des objets XML préfabriqués à l'usage exclusif des mobiles.
Y!Blueprint s'appuie sur des objets préconçus écrits en XML. Outre la question des objets "non-prévus" se pose celle de la réutilisation très problématique de ces bouts de code dans des pages web "classique"... en gros Y!Blueprint produit du site uniquement mobile. Alors soit on développe un produit pour mobiles uniquement et ça peut (sous réserve) être intéressant de s'appuyer là-dessus, sûrement, soit on produit des contenus web pour tous. Y!Blueprint fait le pari que le développement du web mobile est un développement séparé, autonome, et donc qu'il existe "des webs" distincts évoluant concurremment en parallèle (pour mobiles, pour écrans, pour handicapés, pour ceci ou pour cela).
Alors qu'en respectant les conseils et recommandations du lien donné par Hermann dans le post précédent on obtient des résultats satisfaisants. Satisfaisant ça veut pas dire qu'on garantit grand'chose, ça veut juste dire que quel que soit l'orientation que prendra la conception/production de sites utilisables sur mobiles dans les années qui viennent (pour l'instant on balbutie encore et personne ne peut dire où tout ça ira, ça dépendra surtout des usages attendus/demandés par les utilisateurs) on sera à même de rendre nos sites rapidement compatibles et opérationnels. En s'appuyant sur ces genres d'API c'est pas aussi sûr. Sans parler du coût en énergie (humaine, technique, économique) et en temps que nécessite la production, la maintenance et la gestion de sites distincts.
Donc pour conclure ça ne produit pas des sites web en xhtml multi-supports, ça produit des objets XML préfabriqués à l'usage exclusif des mobiles.
Bonjour et merci Arsene pour toutes ces explications.
Je pensai qu'un outil comme yahoo!blueprint me permettais de concevoir des sites pour tous types de périphériques de restitution, et qu'il prenait en compte dans la conception des bonnes pratiques du W3C.
A priori ce n'est pas le cas donc je vais oublier ça et
je vais faire comme tu me le conseilles, c'est dire utiliser les standards et respecter les règles de bonnes pratiques du W3C.
Merci encore pour ces précisions.
Modifié par soulmaster (14 Nov 2008 - 13:12)
Je pensai qu'un outil comme yahoo!blueprint me permettais de concevoir des sites pour tous types de périphériques de restitution, et qu'il prenait en compte dans la conception des bonnes pratiques du W3C.
A priori ce n'est pas le cas donc je vais oublier ça et
je vais faire comme tu me le conseilles, c'est dire utiliser les standards et respecter les règles de bonnes pratiques du W3C.
Merci encore pour ces précisions.
Modifié par soulmaster (14 Nov 2008 - 13:12)