ZEP-07 : Champs personnalisés dans le profil

Pour partager/socialiser etc...

a marqué ce sujet comme résolu.

Cette ZEP est initialement un ticket GH (cf. Annexe). Cependant, la tache n'est pas si trivial/rapide donc une ZEP vaut probablement le coup d’être écrite.

Cartouche
ZEP 7
Titre Gestion de champs personnalise dans le profil
Révision 2
Date de création 17 juillet 2014
Dernière révision 19 juin 2015
Type Feature
Statut Rédaction

Contexte de la proposition

A l'heure du web social, les profils de membres pourrait surement afficher plus d'informations si ces derniers le souhaitent. Ainsi, des champs personnalise pourraient être ajoute a la volée dans les profils.

Objet de la proposition

Ajout de champs de texte dans le profil des membres. Ces derniers sont par défaut inexistant et peuvent être ajoute au fur et a mesure que le membre le souhaite. Un membre ajoute une adresse (Twitter, Facebook, GitHub, PSN, whatever…) puis cette dernière devient visible dans son profil public. L'affichage pourrait se faire de manière simple, avec un champ texte possédant une icone représentant le réseau et l'adresse intégrale.

Moyens mis en oeuvre

Cette opération se divise en deux parties, le back et le front.

Front
  • Il doit pouvoir afficher un formulaire simple (un input de texte uniquement) pour ajouter la nouvelle adresse.
  • Il doit pouvoir afficher sur la fiche de profil du membre la liste des champs perso
Back

Plusieurs choses sont a penser.

  • Le stockage de cette information est a rajouter dans les modèles
  • Selon l'adresse entrée, le réseau doit être détecté pour agrémenter le champ dans le front (parseur a faire)
  • Les icônes seront simplement les favicon des sites cibles

Annexe

Ticket initial GH : #538

+4 -0

La question qui va inévitablement se poser côté serveur (c'est le cas à CHAQUE fois qu'on traite de ce genre de trucs dans un projet) :

Une colonne par champ de réseau social (ajout d'un attribut au modèle "Membre") ou un seul champ pour tous les attributs de réseaux sociaux (sérialisation XML par exemple) ?

  1. Solution 1 : plus "normalisée", facilite la manipulation des données en lecture écriture. Quand il faut rajouter un nouveau réseau social (i.e. un champ) c'est casse-pied.

  2. Solution 2 : plus souple, quand on décide de rajouter des infos il n'y a rien à faire côté serveur. Pénible de sérialiser / désérialiser à chaque opération.

C'est un peu le serpent du mer de tout projet web avec page de profil…

+0 -0

Je voyais ca comme ca (excusez mes imprécisions si besoin) :

  • Ajout d'un model "Reseau"
    • pattern du reseau ?
    • nom/lien vers l'image illustration
    • Autres donnees descriptive du reseau (titre ?, description ?, url home ?)
  • Ajout d'un modèle "ReseauProfil"
    • FK sur le membre concerne
    • Adresse complète comme entrée par le membre
    • FK sur le "Reseau" concerné (le parseur passe avant l'enregistrement, c'est chiant le jour ou un nouveau réseau est ajoute cependant)
  • Ajout d'une variable "reseaux" dans le modele "Profil" qui pointe sur une collection de "ReseauProfil"

Mais apres tout cela ne sont que considération technique, je sais pas si ca doit avoir lieu maintenant ou pas…

+2 -0
  1. Ajouter autant de colonnes que d'info n'est pas normalisé …
    Si tu en arrive à ça, c'est qu'il te faut sans doute une nouvelle table

  2. Stocker plusieurs informations dans un seul champ est très mauvaise idée peu importe le contexte.

Je crois que je dis la même chose que Eskimon mais d'une autre manière :)

Est ce qu'on ne pourrait pas étendre cette zep à une refonte du profile ?

En effet la page actuel est très peu remplie et il y a probablement autre chose a ajouter que des liens vers les reseaux sociaux.

Si vous regardez certains profils vous remarquerez que certains y attachent beaucoup d'importance et complètent une longue bio et tout. Peut être il y a plus à faire ? Par exemple on peut imaginer permette l'ajout d'une photo de couverture comme cela se fait sur certains reseaux sociaux.

Est ce qu'on ne pourrait pas étendre cette zep à une refonte du profile ?

Autant refaire une zep entiere dans ce cas non ? (perso j'ai pas le courage ni l'overview suffisant pour le faire)

Si vous regardez certains profils vous remarquerez que certains y attachent beaucoup d'importance et complètent une longue bio et tout. Peut être il y a plus à faire ? Par exemple on peut imaginer permette l'ajout d'une photo de couverture comme cela se fait sur certains reseaux sociaux.

Soyons fous :) Perso moi ca me passionne pas puisque je suis pas sur que le site se place réellement sur une position de réseaux social, du coup mettre trop d'effort sur la page de profil me semble overkill, mais ce n'est qu'une opinion :)

+0 -0
  1. Stocker plusieurs informations dans un seul champ est très mauvaise idée peu importe le contexte.

Je crois que je dis la même chose que Eskimon mais d'une autre manière :)

Angelo

Euh, non ?

Evidemment, ce n'est pas le cas pour zds, mais les sites qui utilisent du NoSQL, c'est pas une mauvaise chose.

Je ne suis pas complètement convaincu que tout mettre dans un seul champ ne soit pas une si mauvaise idée pour les réseaux sociaux. Il y en a tellement qui se créent aujourd'hui.

Puis les deux fonctions pour faire la sérialisation/désérialisation ne seront pas lourdes et facile à utiliser.

Mais je n'ai certainement pas fait assez de SQL dans ma vie pour dire que ça ne me pose pas de problème de tout mettre dans un champs. Là je vois juste le côté pratique si on doit considérer une dizaine de réseaux sociaux.

Je ne suis pas complètement convaincu que tout mettre dans un seul champ ne soit pas une si mauvaise idée pour les réseaux sociaux.

Saroupille

C'est une pratique assez courante, même avec des bases SQL en fait.

J'ai pas dit que c'est ce qu'il fallait faire, et je n'aurais pas du dire un champ par réseau = approche normalisée c'est faux et c'est un abus de langage.

L'approche normalisée, la vraie, me paraît mal adaptée dans des cas comme celui-ci (et j'étends ça à tout ce qui touche au profil utilisateur en fait).

D'expérience avec les pages de profil, on finit par passer son temps à modifier le modèle car la page de profil est celle dont le modèle évolue le plus souvent quand on cherche à faire ce qui paraît propre de prime abord.

Avec tous les problèmes de scripts de migration qui vont avec.

Je ne prétends surtout pas détenir la vérité sur ce plan, et très clairement, je ne serai pas aussi catégorique qu'angelo en avançant "c'est une très mauvaise idée peu importe le contexte" rien que parce que je m'en sers tous les jours, et que ça me rend d'immenses services tous les jours.

En gros les questions que je me pose quand je suis face à ce genre de problématiques c'est :

  • est-ce-que ce que je veux stocker ressemble à de la config ? (préférences utilisateur, config personnalisée, …)

  • est-ce-que j'ai besoin de lister les informations contenues directement ? (i.e. dans ce cas, avoir la liste de tous les profils Google+ par exemple, ou rechercher par nom d'utilisateur Google+)

Oui/Non => je vais vers la sérialisation

Non/Oui => je normalise au maximum

Oui/Oui => je réfléchis.

EDIT : autre question qui entre en jeu également : faut-il prévoir des update en masse d'un des champs stockés ? qui "enlève des points" à la sérialisation.

+2 -0

D'habitude c'est à moi qu'on le dit, mais pour le coup : vous prenez le problème à l'envers. On ne sait pas encore ce qu'on veut mettre ni en faire, et vous réfléchissez à l'implémentation.

Selon moi, il faut :

  • Google+ : utilisation possible sur les tutoriels et articles pour un meilleur rendu dans Google (photo de l'auteur entre autres)
  • Twitter : pareil, mais pour les Twitter Cards (meilleur affichage sur Twitter avec l'icône du tutoriel, l'auteur et son compte Twitter)
  • Après, on peut laisser les champs libres pour que l'utilisateur rajoute ce qu'il veut.

Mon idée c'est d'avoir au maximum les liens vers les comptes G+ et Twitter des membres qui participent (les auteurs quoi).

C'est ma faute pour le coup et je fais amende honorable.

C'est vrai qu'il faudrait définir fonctionnellement le "nouveau profil" avant de se lancer dans des discussions d'implémentation technique.

D'ailleurs,est-ce-qu'on pourrait définir les champs réseaux sociaux "classiques" souhaitables ?

  • Facebook

  • Google+

  • Twitter

  • Github (dans notre contexte, evidemment)

  • Linkedin/Viadeo

  • Chaîne YouTube

Y aurait-il en dehors de ça (ou à partir de ça) certaines choses à envisager ? Quelques idées vraiment en vrac :

  • extrait de timeline Twitter (dernières activités)

  • mes dernières publications sur mon blog

  • pour me contacter personnellement (lien internet simple vers formulaire de contact)

  • MES sites webs (pour ceux qui en ont plusieurs)

  • mes contributions au code de ZdS (API Github)

  • mes vidéos mises en ligne (je pense aux tutoriels notamment)

Est-ce-qu'on pourrait trier / ajouter là-dedans ce qui relève de la page de profil vivante et qui donne envie qu'on la consulte et ce qui relève de la science-fiction ?

Alors effectivement, on pourra discuter implémentation (et je me tairai d'ailleurs sur ce plan) ?

Mes excuses pour la digression.

+2 -0

Note préalable : je n'y connais rien en développement web. Ce qui suit n'est donc qu'une liste de propositions, dont je n'ai aucune idée du degré de complexité ou non :

  • Prendre les réseaux sociaux classiques proposés par Javier. J'enlèverais la chaîne Youtube, mais c'est peut-être une appréciation personnelle.

  • Classer les réseaux en deux catégories : "professionnel" (Facebook, Google+, peut-être Twitter, Linkedin, Viadeo…) et plus "personnel" (Steam, PSN, Youtube, etc…) : ça évitera un mélange des genres pour ceux qui sont partout.

Sinon, je propose de conserver les champs supplémentaires proposés. Je suis pas fan des réseaux sociaux en général (la proposition de mettre la TL Twitter par exemple, je suis pas emballé) mais je n'ai rien contre non plus.

Par contre :

mes vidéos mises en ligne (je pense aux tutoriels notamment)

Dans ce cas, un lien vers une liste des tutoriels que le membre a publié ou auxquels il a participé peut suffire non ? Ou un lien avec : "Cette vidéo (voire "ce média", si je fais un truc audio uniquement par exemple) a été publié dans ce tutoriel/article" (avec un lien qui pointe dessus).

Ou même mieux en reprenant le champ "contributions au code" : mettre un champ "contributions à ZdS" avec un tri par type :

  • tutoriels

  • articles

  • code

Je propose aussi de n'afficher pour les visiteurs que les champs remplis par le membre. Autrement dit, si je ne remplis pas le champ "Youtube", le champ ne s'affiche pas, pour alléger la page vue par les visiteurs.

On peut aussi imaginer de renommer le champ "biographie" en "expression personnelle" (j'ai pas mieux comme terme là tout de suite) : un champ qui contient ce qu'on veut, vu que certains y mettent autre chose qu'une biographie.

Enfin, je me pose la question de la persistance des données : si j'efface le lien menant vers le réseau social X, y a-t-il une persistance des données, est-il possible et/ou souhaitable de pouvoir le retrouver (option d'annulation des changements par exemple ou de revenir à une version précédente ?)

Encore une fois il est possible que je me plante complètement dans ce que je propose, je le répète, je n'y connais rien. Mais si ça vous semble intéressant, je suis prêt à entendre vos critiques.

Petit rappel : La technique ne doit pas être un problème. Si une fonction semble intéressante, les dev se donneront les moyens de le faire. Donc on a le droit de rêver :D

Enfin, je me pose la question de la persistance des données : si j'efface le lien menant vers le réseau social X, y a-t-il une persistance des données, est-il possible et/ou souhaitable de pouvoir le retrouver (option d'annulation des changements par exemple ou de revenir à une version précédente ?)

A mon avis c'est overkill. Si on commence a versionner chaque donnée du profil (qui est consulte tout les 36 du mois) on s'en sort plus. Et ça ne reste qu'une info secondaire.

Je propose aussi de n'afficher pour les visiteurs que les champs remplis par le membre. Autrement dit, si je ne remplis pas le champ "Youtube", le champ ne s'affiche pas, pour alléger la page vue par les visiteurs.

C’était mon idée de base (que j'ai peut être mal émise alors). Les champs qui s'affiche ne sont que des champs remplis, le reste n’étant pas affiche puisque sans valeur.

mettre un champ "contributions à ZdS" avec un tri par type

Ça existe déjà dans la sidebar ;)

Pour la différenciation Pro/Perso je sais pas si c'est nécessaire. Ce qui est pro pour l'un peut-être perso pour l'autre. Et bon, le site n'est pas un CV non plus… Apres pourquoi l'administration devrait choisir ce qui est possible ou pas ? A mon sens rien ne devrait être interdit (dans les limites légales) et tout devrait être affiche avec la même sémantique (un champ ne devrait pas mériter plus d'attention que d'autres)

+0 -0

Ça existe déjà dans la sidebar ;)

Il manque les contributions au code je pense que c'est à ça qu'il faisait référence, ajouter une section "repo" à la sidebar existante. Avec les commits, PR, issues créées, … Je trouve l'idée intéressante.

A moins que ça pose un soucis qu'on puisse indirectement faire le lien entre compte GitHub et compte ZdS (compter le nombre de PR : "Ah tiens, Paul Bismuth c'est Eskimon en fait") ? A voir… Au pire laisser la possibilité de le masquer même si ça alourdit la page d'options du profil.

+0 -0

Pour information, si on va jusque là dans l'intégration de réseaux sociaux, il faudra enregistrer les tokens, pour éviter que les gens ne reseigne des profils qui ne leur appartiennent pas.

Car on peut imaginer le phénomène vicieux ou un mec crée un compte, l'associe a mon profil twitter et commence a raconter des histoires sur le forums. Pour éviter ça, il faut que chaque réseaux soit vérifié.

il faut que chaque réseaux soit vérifié

Tu veux vérifier ça comment ? Tous les services que je connais, aussi gros soient-il, ne vérifient pas tant que ça n'est qu'un lien.

Ca changerait quoi par rapport au fait que je mette ton profil Twitter et Facebook dans ma signature ? T'aurait aucun contrôle, ça ne changerait donc rien.

Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte