Aller au contenu

aspeum

Hubmaster
  • Compteur de contenus

    112
  • Inscrit(e) le

  • Dernière visite

Messages postés par aspeum

  1. Bonjour,

    Je travaille sur un site qui est divisé en plusieurs univers. Mettons qu'ils s'appellent ECOLE, FAMILLE et SANTE. Dans chaque univers, j'ai des articles appelés "En savoir plus", qui ont un contenu différent.

    Du coup, j'ai les URL suivantes :

    - www.adresse-du-site.com/ecole/en-savoir-plus.html

    - www.adresse-du-site.com/famille/en-savoir-plus.html

    - www.adresse-du-site.com/sante/en-savoir-plus.html

    Y a-t-il un risque de duplicate content ?

    Si oui, est-ce qu'insérer le nom de l'univers dans l'alias de l'article résoudrait le problème ?

    - www.adresse-du-site.com/ecole/en-savoir-plus-ecole.html

    - www.adresse-du-site.com/famille/en-savoir-plus-famille.html

    - www.adresse-du-site.com/sante/en-savoir-plus-sante.html

    Dans ce cas, je risque d'avoir des URL très longues (surtout que la situation se répète parfois sur plusieurs niveaux). Est-ce que cela peut avoir des conséquences néfastes ?

    Merci d'avance pour vos avis/expériences sur la question...

  2. Une petite question aspeum, pourquoi souhaites tu changer le nom des news que tu as déjà écrites ?

    Bonne question ! Je viens d'ailleurs d'y répondre sur le forum de MODx (en anglais).

    En fait, je suis en phase de finalisation d'un site, et j'essaye encore beaucoup de choses, en ce qui concerne le contenu et son organisation. Du coup, je change tout le temps les titres, pour essayer différentes longueurs, différents tons, différents reformulations, etc.

    Mais - et c'est une question de davidm qui m'en a fait prendre conscience - ce n'est pas vraiment le reflet de ce qui se passera une fois que le site sera en ligne. Peut-être que ça arrivera que j'ai à reformuler un titre, mais ça sera extrêmement rare, en fait. Du coup, mon problème de départ disparait, je crois :blush:

  3. :wacko: Et moi qui espérais naïvement trouver une réponse simple !

    Merci à tous pour vos interventions. J'avoue que j'ai, du coup, du mal à y voir clair... Connaissez-vous des exemples de sites qui, à vos yeux, ont magistralement réglé cette question ? (j'entends par là des sites chargés en contenus, contraints de gérer proprement leurs pages d'archives)

    Toute fois, davidm soulève un point intéressant : peut-être qu'il s'agit de beaucoup de complications pour quelque chose qui arrive peu (à savoir changer le titre d'un article).

  4. Je suis actuellement entrain de construire un site sous MODx. Le module de rewriting réécrit entièrement l'URL, c'est-à-dire qu'il ne s'appuie QUE sur le titre de l'article (et pas sur l'id de l'article).

    Par exemple, prenons un article : id = 214 / titre = "Il fait beau en mai"

    => L'URL sera : il-fait-beau-en-mai.html

    Intuitivement, je pensais que ça serait quelque chose comme 214-il-fait-beau-en-mai.html (histoire de récupérer l'id de l'article, peu importe la suite). Parce que sinon, le risque, c'est que si je change le titre de mon article, tous les liens qui pointent vers cette page soient obsolètes.

    Qu'en pensez-vous ? Quelle est la pratique courante, en matière d'URL ?

    Merci pour vos avis.

  5. Je me suis posé la même question, il y a quelques temps, en étudiant notamment les questions de conception, de référencement, de développement, etc.

    Ma décision finale a été de ne faire qu'un site. Je ne peux rien montrer pour le moment, car nous en en cours de réalisation.

    Les grandes rubriques (qui correspondent au différents mini-sites qui auraient pu exister) sont carrément des univers à part entière, avec une couleur dominante forte à chaque fois. Graphiquement, le site est cohérent dans son ensemble, mais chaque univers à sa particularité, et ses propres menus.

    Un lecteur intéressé par un seul univers trouvera tout ce qu'il lui faut sans en sortir, mais un système d'articles liés et de bannières inter-sites lui donne des portes pour découvrir le reste du site.

  6. Il faut parfois être un peu patient :) .

    Mais je le suis ! :smartass: Merci beaucoup pour cette information. Quand ils parlent d'abonnement "sur un site spécialisé", c'est des sites comme Netvibes ?

    Le grand public ne sait pas qu'il utilise les rss, mais ce n'est pas génant, l'essentiel étant que les éditeurs eux sachent comment s'en servir et qu'ils le proposent

    Tu fais allusion au fait que le grand public navigue sur des sites qui eux-mêmes agrègent des flux RSS ?

    C'est même la façon la plus simple de se faire du contenu sans écrire une ligne. Ceci dit, il faut tempérer cette impression négative, car il y a quand même une justice : un site qui ne fait que proposer cela sans apporter quelque chose qui lui est propre aura beaucoup de mal à se constituer une audience suivie.

    Je n'ai aucun a priori négatif sur l'agrégation de flux RSS dans un site. Au contraire, je pense que ça peut-être un atout supplémentaire dans un site de contenu bien étoffé. Le tout est effectivement de ne pas en abuser.

  7. Suite à un BTS en communication, j'ai fait une licence professionnelle en communication électronique. Ca ressemble beaucoup à ce que tu sembles chercher. C'était à Lyon (université Lyon II).

    Jette un coup d'oeil sur le site de l'ONISEP, dans la rubrique "S'orienter". Tu sélectionnes les critères que tu souhaites, et ça te sort toutes les formations qui correspondent.

  8. Tu as raison, je vais opter pour cette méthode (remonter le fils des annonceurs)

    Tu as un site lié à l'environnement ou au développement durable ?

    Non, pas exactement. Il s'agit du site de l'association Sécurité Solaire (centre collaborateur de l'OMS pour la prévention solaire). Il s'agit d'un site d'information sur le thème du soleil, de ses effets et de ses risques pour la santé.

    Le thème n'est donc pas directement l'environnement, mais les thèmes sont partiellement liés, et les visiteurs sont susceptibles d'être sensibles aux deux sujets. Or, il n'est pas envisageable (pour des questions d'images) d'avoir un contenu publicitaire éloigné de la philosophie du site...

    A propos des Google AdSense (ou assimilés) : on est bien d'accord qu'il n'est pas possible de générer ces publicités contextuelles à partir de mot-clé défini indépendamment du contenu de la page ?

  9. Histoire de donner suite aux personnes qui ont participé à cette discussion, que je remercie de nouveau...

    Sur les conseils avisés de davidm/Nodeo, nous avons choisi d'opter pour MODx. Le lancement du site est prévu pour dans quelques semaines. Une fois que je l'aurais pris en main au quotidien, j'essaierai de décrire en détail mon sentiment sur ce CMS.

    PS : pour info, voici notre site actuel, traitant du soleil et de ses risques

  10. Cependant, si j'essaye sur site avec frame, ça plante. La faq explique qu'il faut faire pointer sur le frame et choisir des item dans ce frame, oui mais si d'une part le frame est élaboré en php on peut pas vraiment l'afficher seul, ensuite c'est le frame lui-même qui doit être en lien... enfin bref le moteur de ponyfish s'y retrouve pas.

    Oui, le système ne doit probablement supporter que des sites correspondant à certains standards...

    J'en profite pour préciser qu'ils sont extrêmement réactifs : j'ai essayé de créer un flux sur un site, le flux semblait se casser sur un élément, j'envoie un mail pour demander de l'aide ; j'ai eu une réponse sympa dans la journée, et l'outil était adapté dans la semaine (un caractère spécial semblait poser problème).

  11. Bah forcement vu qu'il faut être sur le web pour les utiliser (à moins d'acheter le lapin qui lis les flux RSS) ;o)

    Je présume qu'il s'agit d'une boutade, mais dans le doute, je donne un exemple : ma grand-mère utilise le web, mais elle n'est pas webophile :)

    Eh bien, un exemple d'utilisation pour les non "webophiles".

    Ayant interviewé Laurent BINARD, co-fondateur de wikio (que je ne te présente pas), il nous a confirmé que la majorité de leurs visiteurs ne sont pas "webophiles".

    Et Wikio syndique le contenu en se basant sur le flux rss :)

    De même, un outil comme Netvibes, qui permet également de syndiquer des flux rss sur sa page d'accueil n'est pas réservé à des webophiles, et utilisé par d'autres que des webophiles.

    Pour Wikio (que je ne connaissais pas), ça peut être une première approche du rss effectivement, même si, quelque part, c'est en partie invisible pour l'utilisateur...

    Pour Netvibes, que cela ne soit pas volontairement réservé à des webophiles, je veux bien le croire, mais je serais justement très curieux de connaitre le profil-type du site... Mais disons que c'est la statistique inverse qui m'intéresserait encore plus : sur un site de contenu, quel pourcentage de visiteurs est abonné au flux rss proposé...

    Mais cela représente une très faible part de la population. Part qui a, qui plus est, tendance à diminuer.

    Tu parles des personnes utilisant des rss, ou des personnes n'en utilisant pas ? :unsure:

  12. il existe des outils pour faire des statistiques sur tes flux personnels.

    En fait, je ne cherche pas à évaluer des flux existants, mais simplement à estimer la pertinence d'un tel outil.

    Sur le papier, je trouve le principe de la syndication/agrégation convaincant, mais j'ai le sentiment que ça reste cantonné à une population très webophile, et que c'est amené à le rester.

    D'où cette recherche d'indicateurs plus objectifs que ma simple perception...

    Merci pour ta réponse, en tous cas.

  13. Les fils RSS semblent se multiplier sur tous les sites où je passe, mais je me pose quelques questions à ce sujet :

    - Qui en sont les utilisateurs ? Existe-t-il des statistiques là-dessus ?

    - Est-ce que beaucoup de webmasters utilisent des fils RSS externes pour alimenter en contenu leurs propres sites ?

    - Quel est le défaut de cette technologie ? Ses limites ? Ses contre-exemples d'une utilisation intelligente ?

    Merci d'avance pour vos réponses :)

  14. Ta question me fait penser au bouquin des gars de 37 signals qui parle exactement de ça.

    Je viens de lire un passage au hasard, et ça commence déjà à battre en brèche un paquet de conseils habituellement donnés... Bon, c'est en plein dans le sujet, en tous cas, merci pour le lien !

    J'en profite pour tous (davidm, NiCoS, vincedo, dotweb, etc.) vous remercier de votre contribution à cette discussion, c'est très enrichissant. Même si je passe du temps sur le web, je ne suis pas un expert en ressources documentaires, et cet échange me permet d'aborder plein de sujets sur lesquels je peine à y voir clair... Merci pour ça.

  15. Attention toutefois à ce que je disais, si le web semble "facile", il ne l'est pas forcémment... un projet web est un projet complexe, et une application web n'est pas moins complexe qu'une application traditionnelle (le fait de devoir gérer des environnements clients hétérogène -> i.e plusieurs plateforme + navigateurs, n'y est pas étranger).

    Pas de doute là-dessus : le web est un média complexe... Je me souviens de propos d'un graphiste, expert du print passé au web, qui trouvait extrêmement difficile de créer une mise en page efficace quand tant de paramètres pouvaient entre en ligne de compte...

    En fait, ma petite expérience du web m'a appris une chose : plus tu cherches à creuser, plus le trou te parait grand :)

    Le lien, c'est qu'un système de navigation (menu) par exemple, qui est une des pièces maîtresse de l'interactivité sur un site, ne peut pas se permettre d'être inaccessible. Si il est mal conçu, ou inacessible à certains visiteurs, ceux-ci ne reviendront pas... Exemple type : menu en Flash, menu en javascript (si une alternative n'est pas prévue...). Mais il ne s'agit pas seulement de la technique utilisée pour le menu (full CSS est préférable toutefois), mais aussi de la réflexion initiale sur la façon dont on va structurer le site et penser la logique de la navigation...

    D'accord, de ce point de vue, je comprends... Même si, dans ma tête, j'aurais classé cet aspect dans la recherche-abilité : un bon menu permet de trouver rapidement l'information... L'interactivité, pour moi, ça fait référence à la "marge d'action" de l'utilisateur, telle que prévue par le site...

    En fait, je met souvent en garde contre les espoirs vis à vis d'un site web. Que cela soit d'un point de vue des retombées commerciales ou des conditions de réussites pour la mise en oeuvre des outils collaboratifs (et comme tu le soulignes, cela signifie investir du temps et effectuer des choix en terme de management des ressources humaines).

    Pour un site "plaquette" par exemple, les bénéfices ne sont pas "directs", et dépendent largement de l'intégration de la stratégie web avec la stratégie de com (curieusement, c'est assez rare !), la stratégie commerciale, l'attitude de la société vis à vis de ses clients d'une manière générale... etc. C'est d'ailleurs la raison pour laquelle je passe du temps au début à bien comprendre l'activité de mes clients, et ensuite pour laquelle j'insiste sur la nécessité de ne pas envisager le site web comme une extension "désarticulée". Donc bon point oui : un site web, qu'il comprenne des outils permettant l'interactivité ou pas, est un projet qui ne doit pas être envisagé comme indépendant du reste de l'activité et de la stratégie...

    J'avoue qu'un des points qui m'inquiète le plus, c'est bien celui-ci : comment anticiper l'utilisation réelle d'une fonctionnalité ? Je lis partout qu'il faut se concentrer sur l'essentiel, que beaucoup de demandes de futurs utilisateurs sont superflus, etc. Mais, concrètement, comment distinguer au cas par cas ce qui va être utile ou non ? Si vous avez des astuces, je suis tout ouïe :whistling:

  16. Possibilité 3 : à éviter pour le référencement (risque de duplication de contenu).

    Je ne comprends pas le risque de duplication de contenu.

    Dans la solution 3, l'adresse www.airmax.com pointe directement vers www.nike.com/airmax. Concrètement, il n'y a pas de contenu sur www.airmax.com.

    Ai-je mal compris ? Est-ce qu'un moteur peut néanmoins considérer www.nike.com/airmax et www.airmax.com (qui pourtant n'"existe" pas) comme deux sites distincts) ?

  17. Pour conclure, je pense qu'il faut laisser le prestataire présenter sa méthodologie et l'ajuster le cas échéant si certains sujéts sont maitrisés ou si la réflexion est mature / a déjà été menée proprement. ;)

    Ok, je vois... Et ton paragraphe sur les responsables informatiques qui peuvent être des freins dans le développement d'un projet m'interpellent, j'espère que je ne correspond pas trop à cette description... Je vais y travailler, en tous cas !

    En quoi la solution dAtelierPHP est-elle plus personnalisée quun CMS standard ? A moins que tu compares dun côté AtelierPHP qui vend son CMS obligatoirement avec de la personnalisation, et dun autre côté lutilisation dun CMS « out of the box », je ne comprends pas cette question.

    Un site comme http://www.projectopus.com/ te fait-il penser à un site Drupal « standard » ?

    Prestation plus personnalisée, car en effet développement spécifique compris dans la prestation si besoin... Mais tu as raison, ça revient au même avec un CMS open source...

    Pourrais-tu expliquer en quoi lintervention dune web agency compromettrait la réussite de ton projet par rapport à une réalisation « en solo » ? A part certains cas que jespère exceptionnels (escrocs, incompétents, tarifs exorbitants...), je ne vois pas.

    Disons que ma logique ne se présente pas exactement en ces termes : je me doute bien qu'une collaboration avec un prestataire externe compétent a toutes les raisons d'être constructive.

    Mais cela représente aussi un coût, non-négligeable. Et mon boulot consiste aussi à choisir entre :

    - faire appel au prestataire qui me semble le plus adapté, en allouant au projet un budget

    ou

    - mener moi-même le projet, en y consacrant davantage de temps

    [*]l'interactivité : si votre interface n'est pas accessible, vous rendez difficile la navigation sur votre site, vos pages ne seront pas consultées, vos visiteurs ne reviendront plus (ou peu).

    Je n'ai pas bien compris le lien entre interactivité et accessibilité...

    Et pour revenir sur l'aspect interactif des sites web... Je perçois bien tout ce que cela a de séduisant dans l'idée (interaction directe, partage des connaissances, prise en compte de l'avis de chacun, valorisation de l'utilisateur, etc.), mais est-ce qu'il vous est déjà arrivé de conseiller à un client de ne pas trop miser là-dessus, tout simplement parce qu'un site interactif, ça consomme plus en ressources humaines ?

    Moi aussi j'ai des lunettes de soleil sur mon avatar !

    Elles font cheap ? ;)

    Ta photo me fait penser à l'agent Smith, dans Matrix ! :cool:

  18. - le coût du support (c'est souvent là qu'on va te dire que l'open source n'est pas forcémment économique parcequ'il faut passer par un prestataire au lieu de s'adresser à l'éditeur du logiciel, supposémment moins cher. Mais franchement, ça reste à voir...)

    Qu'est-ce que tu entends pas support ?

    Ce qu'on oublie parfois de souligner, c'est que choisir une application "propriétaire" demande de faire attention :

    - au format des données : s'agit-il d'un format "ouvert" dont les spécifications sont publiques ? Si ce n'est pas le cas (comme pour Office) tu te retrouve captif de ton fournisseur parceque tu n'est pas vraiment totalement propriétaire de tes données (!).

    - à la pérennité du fournisseur : dans le monde du propriétaire, on a pas accès au code source de l'application, si l'éditeur fait faillite on se retrouve dans une situation assez désagréable car on ne maîtrise plus son application...

    Et dans le cas où l'application propriétaire est entièrement codée en PHP, et que le client a entièrement accès à ce code, on se retrouve ni plus ni moins dans la même situation que si on avait travaillé avec un développeur indépendant qui avait tout créé pour l'ocassion, non ?

    Avec d'autres applications, comme MODx, l'imbrication n'a aucune limite de niveaux (quoique, d'un point de vue de l'utlisabilité, faire ce genre de choix est discutable...)

    C'est vrai... là, je suis sur 4 niveaux... 3 niveaux sont incompressibles... le quatrième, je planche sur mon arborescence pour le faire disparaitre :)

    je suis persuadé que la combinaison "open source + cms + prestataire" a de l'avenir (et je dis pas seulement ça parce que c'est mon gagne-pain :)). En termes d'efficacité, de coût, de logique (ne pas réinventer la roue...), etc.

    Et vu que tu occupes précisément ce poste de prestataire, peux-tu me dire à quoi correspond ton rôle ? (dans les grandes lignes, hein) T'arrive-t-il de sentir que ton apport est minime, par exemple dans le cas où ton interlocuteur a de solides connaissances du web, voire en matière de programmation ?

    Pour en finir, je te dirais effectivement de bien définir ce que tu veux d'un point de vue fonctionnel (voir les propos de davidm que je rejoinds totalement) et ensuite de proposer ton cahier des charges à des prestataires qui ont des compétences multiples pour avoir la meilleure réponse possible... Il est à mon avis pas/peu souhaitable que tu te focalises déjà sur un outil (mais avoir un aperçu des fonctionnalités des cms existants peut t'aider bien sur dans ta réflexion...). Je te demande parce que je ne voudrais faire appel à un prestataire qui ne ferait que faire ce que je pourrais faire moi...

    Hope it helps... ;)

    Ca m'aide, sans aucun doute. Et si je cherche à me faire une idée sur les outils disponibles, c'est parce que je ne sais pas encore si je passe par un prestataire ou non :?: (cf. le paragraphe juste au-dessus)

    Ceci dit, si le client passe d'abord par un prestataire uniquement pour définir son besoin et obtenir une matrice de correspondance entre besoin/fonctionnalités alors oui tu peux être bien placé. Mais par expérience, c'est rarement le cas pour des petits/moyens projets (et c'est bien dommage :( ).

    En ce qui me concerne, je n'aurais même jamais pensé que c'était possible ! Mais ça a peut-être plus de sens pour un client qui ne connait pas grand chose au web, non ?

  19. Effectivement, cela semble assez optimal en terme de référencement.

    Toutefois, cela présente un inconvénient : celui de faire apparait dans l'url le nom de domaine principal. Or, parfois, c'est utile de pouvoir donner une url focaliée sur un projet.

    Pour reprendre mon exemple : si Nike veut toucher les radios avec un morceau de musique, une stratégie peut être de ne pas vouloir que "nike" apparaisse dans l'url... c'est pour cela que ça m'intéresse de savoir si la proposition 3 fonctionne...

    <Modérateur : Inutile de citer le message précédent>

×
×
  • Créer...