Argumentaire marketing et étude de cas (groupe de travail suite DrupalCamp)
Edit by Inéation : la coordination de l'écriture et des discussion étant très difficile via groupes.drupal.org, un wiki a été mis en place afin de centraliser toutes les délivrables du groupes. Merci de bien vouloir utiliser http://wiki.ineation.com pour vos contributions, c'est beaucoup plus efficace. La discussion engagée ici peut bien sur continuer sur ce post.
Comme promis, suite à notre rapide session du DrupalCamp Paris, je crée ce fil de discussion comme support à notre travail sur le "marketing" de Drupal en France.
L'objectif est donc de créer un certain nombre d'outils qui vont valoriser Drupal et différentier cette solution par rapport aux nombreux CMS concurrents.
A court terme nous avons décider de nous concentrer sur les deux aspects suivants:
- Un argumentaire Marketing qui permettra d'expliquer pourquoi Drupal est plus qu'un (très) bon CMS mais qu'il comporte des caractéristiques spéciales qui le met au dessus de la mêlée
- Des étude de cas qui permettront aux personnes moins initiées de percevoir la puissance et la flexibilité de Drupal au travers d'exemples d'applications variées et de qualité.
Ils seront intégrés dans le site drupalfr.org et à disposition de tous pour vendre la technologie Drupal dans le cadre de vos activités pro.
L'argumentaire Marketing
Lors de la discussion nous décidé de donner "une couleur" à Drupal, c-a-d de mettre l'accent sur certains points spécifiques qui vont faire la différence (plutôt que de vouloir en faire un CMS généraliste bon à tout donc bon à rien). Nous avons donc passé en revue les différentes applications types qui constituent 80% des projets.
De ce brainstorming il en ressort une approche sur deux axes qui pourrait être intéressante :
- Axe 1 : Drupal comme une Social Publishing Platfom (traduction à trouver) ou comme une plateforme pour sites communautaires. L'intérêt de cet axe c'est qu'en disant cela on dit que 1) Drupal est un bon CMS mais que 2) En plus, il comporte un certain nombre de fonctionalités (modules) qui permette de créer, avec un investissement en ressource faible, une application communautaire complexe.
- Axe 2 : Drupal en tant que framework. Ici on dit que Drupal ne ce restreint pas à un type d'application donnée et que grâce à la robustesse, la puissance et la qualité de son API il possible de créer une application complexe sur mesure.
Bien entendu tout cela n'est qu'une ébauche à challenger et à travailler en profondeur. Mais l'argument me parait intéressant dans le sens que les deux axes sont complémentaires et que il touche à la fois le décisionnaire business (axe1) et le développeur (axe2).
Des étude de cas
La seule décision prise a été de ce concentrer sur des études de cas limitées (pas d'annuaire de site Drupal) mais de grande qualité. Les critères de sélection des cas seront entre autre : la complexité des sites, la popularité de la marque, la variété dans le type des sites (pas que des sites du secteur de l'édition par exemple). Nous ferons aussi attention à ce que la rédaction soit impartiale afin de ne pas privilégier un webshop par rapport à un autre.
Plan d'action pour la semaine prochaine:
Récupérer tous les argumentaires développés en anglais et en faire une synthèse sur une page wiki : Jean-Baptiste I.
Commencer à lister tous les projets potentiels pour les études de cas sur une page wiki : Christophe L.
Ical feed
"Social Publishing Platfom
"Social Publishing Platfom (traduction à trouver)"
"Drupal est un Gestionnaire de communauté orienté contenu"
C'est pas de moi, mais j'ai trouvé cette phrase en ligne, et sur le coup je l'ai trouvé pertinente face aux autres CMS/CPS/Blog engine.
C'est dans cet axe qu'il
C'est dans cet axe qu'il faut creuser.
A mon humble avis la tournure est encore un peu lourde et pas assez percutante...
Alex
www.ineation.com
Par ailleurs, les études de
Par ailleurs, les études de cas sont effectivement très intéressantes à lire, et font comprendre ce qu'il est possible de faire.
Mais, pour s'adresser à des non-avertis, il est parfois plus simple de piocher dans un liste de possibilités celles qui correspondent aux besoins qui se révèle dans la discussion, et de les mettre sous le nez d'un client / ami / patron / militant associatif qui n'y avait pas pensé (car tout simplement il ne pensait pas que c'était possible), puis, enfin, de lui montrer concrètement une implémentation / case study
Je distingue en tout cas possibilités et fonctionnalités techniques, qui n'intéressent que... nous ?
Exemples, très basiques :
[feedAPI, Views]
[Blog]
[CCK, Fields CCK, Views, Taxonomy]
Une fois une première liste d'étude de cas arrêté (lien ??) je décortiquerais les sites en question en possibilités plus petites et plus "digérables", qui seront toutes reliées à l'étude complète.
Est-ce que d'autres ont cette approche en terme de multiples "possibilités" basiques ?
Yes bonne idée, tu peux
Yes bonne idée, tu peux maintenant voir la liste des sites. Ils sont regroupés par thèmes ce qui est déjà une première étape...
Alex
www.ineation.com
j'y ai ajouté mes + Il en
j'y ai ajouté mes +
Il en faut d'autres !!
L'idée me semble excellente
L'idée me semble excellente. En plus, il y a possibilité de la rendre très graphique, en la mettant en page de manière attrayante !
Damien Tournoud
http://drupalfr.org
bonjour, je suis très
bonjour, je suis très intéressé par cette "démarche marketing". je voulais savoir comment on s'organise pour la centralisation des infos ? qui participe ? date buttoir pour rassembler les infos ? ... etc.
=> Plan d'action pour la semaine prochaine:
Récupérer tous les argumentaires développés en anglais et en faire une synthèse sur une page wiki : Jean-Baptiste I.
Commencer à lister tous les projets potentiels pour les études de cas sur une page wiki : Christophe L.
ou en sont ses démarches ? page de wiki ?
bref, l'intention est bonne mais iol manque pas mal d'infos pour participer..
cordialement
Good, pour montrer son
Good, pour montrer son intérêt il suffit de faire ce que tu as fait, commenter ce post... Peux tu m'envoyer ton email via le formulaire de contact ?
Christophe a avancé sur la liste pour les études de cas mais n'a pas du avoir le temps de publier le wiki. comme tu le demandes, Je vais le faire juste après...
Par contre pas encore de nouvelles sur la partie recherche des argumentaires existants. Je vais voir avec Jean-Baptiste.
Etude de cas dans argumentaire marketing
J'ai pris un peu de retard pour cette collecte d'argumentaires existants. Je m'y met rapidement.
Mais j'aimerai intervenir dans ce débat sur l'argumentaire marketing et étude de cas.
J'aime les études de cas en anglais. Elle m'apprennent beaucoup et elle me semble bien incarner l'esprit de partage de la communauté. Cependant il me semble qu'elle s'adresse à des professionnels d'internet. Ce sont plus ou moins des recettes de site.
Il me semble qu'il y a aussi un publique de décideur qui en aucun cas ne vas en priorité s'intéresser à l'utilisation de tel ou tel module. Mais penser à des questions les compétences francophones disponible , l'avenir du CMS, ces performance, son adéquation à tel ou tel marché.
Il me semble très important donc de définir des personna et réponses différentes selon la cible.
Je me lance :
1.-consultant en système d'information
2.-membre d'un conseil d'administration d'une entreprise ou une organisation à qui on propose Drupal
3.-directeur de service informatique d'une entreprise
4.-une webagency
5.-un responsable des éditions électroniques d'un groupe média
6.-développeur se posant la question d'un formation ou d'une spécialisation
7.-un particulier souhaitant créer un blog
8.-journaliste à priori technique
Pour les études de cas tel que publié sur drupal.org je dirai que la cible plus ou moins dans l'ordre.
est 4/5/3/1/6
Dites moi ce que vous en pensez et si pour vous ca la liste doit être affinée ou au contraire réduite ?
Tout à fait d'accord
Tout à fait d'accord !
J'ajouterais
9.-les membres et/ou responsables de structures à but non lucratif
qui pour le moment par défaut se jettent toutes sur SPIP, qui ne leur convient pas toujours, et limite les interactions communautaires entre membres. (On en connait les raisons : c'est un projet francophone, avec la doc de référence en français-- moyenne, IMHO, mais aisément parcourable)
+1 pour ta segmentation de
+1 pour ta segmentation de nos futurs interlocuteurs. Elle me semble bien détaillée pour le moment, d'autant plus qu'il va falloir se concentrer sur les cibles essentiels pour commencer.
Si mes souvenirs sont bons on avait décidé que les études de cas s'adresserait en premier lieu a des décideurs "non techniques". Donc si je reprends ta classification à des 2 - 3 - 5. En effet nos études de cas seront des histoires illustrées par des exemples concrets qui ne rentrent pas dans le détail de la technique. Notre conception d'une étude de cas est donc différente de celle de d.org que tu mentionnes car elles s'adressent à la communauté Drupal. Ici on veut faire une étude de cas qui démontre à des décideurs que Drupal est crédible, puissant, flexible et qu'ils en auront pour leur argent...
A l'inverse, une partie de l'argumentaire que l'on doit aussi réaliser lui s'adressera a des techniciens, des 4 et 6 par ex. Effectivement, une fois rédigé les axes de valeurs de Drupal, Il faudra que l'on aille jusqu'au détail des fonctionnalités afin de démontrer la puissance fonctionnelle de Drupal.
a+
Alex
www.ineation.com
Je simplifierais un peu en
Je simplifierais un peu en fusionnant.
Du plus "lointain" au plus "dans le camboui"
Grand public
7.-un particulier souhaitant créer un blog
Relais d'opinion
8.-journaliste à priori technique
10.-Bloggers
Décideur non-technique
2.-membre d'un conseil d'administration d'une entreprise ou une organisation à qui on propose Drupal
5.-un responsable des éditions électroniques d'un groupe média
9.-les membres et/ou responsables de structures à but non lucratif
Décideur technique
1.-consultant en système d'information
3.-directeur de service informatique d'une entreprise
4.-une webagency -- ou plutôt : un directeur technique en web agency
Implémenteurs
6.-développeur se posant la question d'un formation ou d'une spécialisation
11.-Concepteur et administrateurs techniciens, mais non codeurs au sens propre -- Ma propre position, possible justement grâce à la direction prise par Drupal (CCK, Views, Actions, PHPTemplate...)
Voilà, ça me parait plus simple à gérer, en tout cas je vois assez bien comme re-writer la même étude de cas en 5 versions correspondants à chacun de ces "niveaux".
Super boulot, là pour moi
Super boulot, là pour moi c'est parfait !
Alex
www.ineation.com
Un peu de matière pour l'argumentaire marketing ciblé "décideur"
Le site suivant http://www.softfluent.com peut être une très bonne source d'inspiration pour développer notre argumentaire marketing ciblé "décideurs".
Il y a en effet bcp de points communs à exploiter entre l'argumentaire marketing d'un générateur de code tel que Softfluent et un logiciel tel que Drupal, framework spécialisé dans la construction de systèmes de publication sociaux (ou gestionnaire de communauté orienté contenu).
J'attire en particulier votre attention sur la présentation : http://www.codefluent.com/fr-FR/Presentation.aspx
Alors que Softfluent prétend pouvoir amener un projet à 60% de sa réalisation avant d'entamer la phase des développements spécifiques et ce pour n'importe quelle type d'application, Drupal peut prétendre amener un projet à 80 ou 90 % de sa réalisation sur des projets impliquant une gestion de contenus et une communauté de contributeurs. (et donc diviser par 4 le cout d'un projet)
Autour de cet argument phare et différentiant par rapport aux autres types de framework, CMS ou générateur de code, il est également important de bien rassurer notre cible de décideurs avec tous les arguments classiques qu'elle est en droit d'attendre... et pour cela pas la peine de réinventer la poudre, il suffit en grande partie de s'inspirer d'argumentaires existants...
Par exemple, si je reprend le petit encadré de bas de page de softfluent cela donne :
"Pour vos projets de plateforme web ayant une forte composante gestion de communauté et gestion de contenu, l'utilisation de Drupal procure les bénéfices suivants :
etc... "
Enfin le deuxième argument réellement différentiant surlequel je jouerais dans notre argumentaire marketing est le potentiel humain de la communauté drupal (plus de 200 000 utilisateurs sur drupal.org, chiffre en pleine croissance, le momentum, les conférences géantes qui doublent de taille tous les 6 mois etc...). Bien formulé et bien tourné c'est à mon avis exactement le type d'argument qui peut achever de convaincre un décideur.
Qu'en pensez vous ?
Voulez vous que je rédige un premier draft d'une page qui suivrait la logique enoncée ci dessus ?
(en résumé : 1er argument différentiant + enrobages d'arguments classiques + deuxième argument différentiant pour finir de convaincre)
Préférez vous autre chose ?
Est ce qu'il y aurait moyen de trouver un financement pour faire réaliser une petite animation flash du même style que celle de codefluent pour drupal ?
@julma : sauf erreur nous
@julma : sauf erreur nous sommes dans ta proposition dans un argumentaire à destination des cibles :
Décideurs technique
&
Implémenteurs
Personnellement, je ne trouve pas les argumentaires classiques très convaincants. Et le site de Softfluent me donne l'impression de déjà-vu. Tous le monde promet des miracles, plus vite, moins cher.
Là où je te suis totalement, par contre, c'est que je trouve très vrai et très pertinent de dire que 80 à 90% du projet est déjà en place. Nous pouvons d'ailleurs détailler un peu :
C'est déjà dedans :
- Authentification
- Moteur de recherche
- Outil de définition des contenus (CCK)
etc.
Ensuite, le potentiel humain, la communauté, est effectivement quelque chose que ne peut apporter une solution commerciale par exemple, (ou même IMHO -- et pour reprendre des comparaisons qui n'ont pas lieu d'être -- Joomla dont je trouve la communauté moins pointu, moins généreuse même au premier abord.)
Et surtout n'oublions pas de rappeler ce point, qui pour nous tous ici est devenu naturel comme de l'air que l'ont respire -- mais ne l'est pas encore pour de nombreux, très nombreux, décideurs et administrateurs (non-dev) :
"Open source, en licence GPL, la plus protectrice pour les utilisateurs -- votre prestataire disparait ? Vous voulez faire auditer votre code ? Vous voulez à terme modifier ou récupérer la maintenance en interne ? Vous ne pouvez pas atteindre pour ajouter une fonctionnalité ?
Drupal est un projet Open Souce / Logiciel libre en GPL, ce qui signifie que vous ne serez jamais bloqué par une solution propriétaire et que vous êtes totalement au commande de l'évolution de votre projet.
En cas de développement additionnels, assurez-vous d'obtenir la même licence."
De manière plus générale, je viens créer une page wiki par cible marketing (donc 5), et nous pouvons commencer à y jeter plan et brouillons, et idées, et modeler ça au fur et à mesure. J'ai ajouté mes idées, ajoute les votre aussi, on fera le tri plus tard !
Je suppose que les révisions sont activées automatiquement sur les pages wiki de groups.drupal.org (??), ce qui sera/serait utile.
EDIT : apparemment pas de révision. C'est donc pas du wiki au sens strict :-(
Ma petite contribution
Bonjour,
Bravo pour cette initiative. Je me présente rapidement, je suis account manager dans une agence web. Je vous parlerais donc plus des cibles Décideur non-technique (+ directeur de service informatique d'une entreprise) et plutôt PME. Je ne vais pas entrer vraiment dans le détail mais voici quelques mots sur ma facon de vendre Drupal à mes clients.
L'argument le plus percutant est d'avoir une vision à moyen terme ou LT dans ses développements. En effet beaucoup de sociétés ont mis en place des systèmes (couteux) souvent solutions développées sur mesure ... Aujourd'hui elles se trouvent devant de gros problèmes :
1) Faire évoluer les outils est bien souvent synonyme de lourds développements voir de tout refaire (budgets conséquents)
2) Bon nombre de prestataires ont mis la clé sous la porte (suite au crash web) et il est quasiment impossible de reprendre la main sur des outils "fait maison"
Vous voyez aiséments les arguments pour répondre à ces deux problématiques :
1) Avantage des modules (évolutivité ...), possibilité d'anticiper les développement futurs (ex penser un catalogue produit déjà optimisé pour le e-commerce ...)
2) Possibilité qu'un autre développeur (ou autre prestataire) puisse prendre la suite ...
C'est assez simple, mais pour cette cible, outre l'aspect financier que je ne développerai pas ici, ce sont deux points importants ..
Autre fonctionnalité très appreciée par les "annonceurs", le tracking marketing (pages visitées, chemins, actions ...), je n'ai pas encore testé le module de tracking d'emailing ... mais là encore je sais que c'est argument fort, notamment car il peut être intégré en début de projet ou tout simplement ajouté sans tout "repenser" l'appli ..
Donc en bref et désolé de ne pas pouvoir creuser plus, mon argument fort réside en une vision à MT voir LT des projets clients (coût, fiabilité, retour sur investissement ...) ...et là Drupal reste un outil très intéressant, très pertinent.
A plus
@dams74 : merci, c'est
@dams74 : merci, c'est intéressant d'avoir la vision de professionnels "vendeurs" de drupal , il en faudrait d'autres d'ailleurs
@jlndrr : merci d'avoir créé les pages pour les différentes cibles. par contre il faut faire attention : chaque contributeur (je pense) se doit de faire un travail de synthèse de ses infos, et de ne rajouter ( = insérer avec pertinence, on va dire) que des éléments nouveaux.
ayant une certaines expérience du travail collabo via des plateformes wiki, je sait que cela peut devenir rapidement le foutoir (il faudrait qu'on ai un "vrai" wiki => révisions des pages ??)
un autres exemple (pour l'organisation) : le post de dams74 ci dessus est intéressant : qui ce charge de l'intégrer dans l'argumentaire correspondant... il faudrait un mini "redacteur en chef" pour chaque argumentaire, qui se chargerai de la mise en forme et "de la bonne intégration des contributions" ..
[ps: je vais avoir bcp de taff pendant quatre semaines mais je suit avec attention les discussions, de juin à septembre, je vais pouvoir mettre le "paquet" sur ce groupe de travail.. ]
Oui, tu as tout à fait
Oui, tu as tout à fait raison Robby, sans révisions c'est un problème.
Pour le Post de Dams74, chacun peut l'ajouter, vu que pour l'instant c'est assez vide. On append, on se répète, et on rewritera après. Comme pour l'instant il n'y a pas encore foule, à moins de 5 ou 6 ça devait être gérable.
Comptons sur le bon sens et le "principe de précaution" -- ne pas effacer comme une brute le texte des autres, mais plutôt ajouter des commentaires, ajouter un autre manière de le dire.
Dans tout les cas, comme ce sont des argumentaires "open source", il faut donc mieux qu'il y ait a retirer, plutôt qu'à ajouter pour que chacun puisse les récupérer pour son propre site, voire une plaquette.. papier !
Si on arrive à 3 ou 4 versions TRÈS PROCHES, mais avec des tournures différentes, toutes à la suite dans la même page, on peut ainsi choisir celle que l'on préfère, selon le ton à adopter face à son interlocuteur.
J'ai mis un version
J'ai mis un version rewritée de ce post sur la page http://groups.drupal.org/node/11214 - Argumentaire Décideur non-technique
N'hésite pas à la relire et à y ajouter des remarques ou des addenda (par exemple entre [ ] )
re
Hello,
Merci pour le rewriting ... j'ai pas trop structuré et laché qq idées. Une remarque sur "par exemple, penser un catalogue produit déjà optimisé pour le e-commerce, lui ajouter un caddie plus tard", je pense plus que le caddie doit être ajouté de suite (création de wish list, conservation des choix des utilisateurs ... print pour aller en magasin ...), le e-com venant ultérieurement ou non (la est la soupleese de l'outil car il colle aux décisions stratégique de l'entreprise ..) bref c'est un détail.
Un autre point non exposé dans mon précédent post, c'est la facilité d'utilisation pour le responsbale d'un site, webmaster ou autre, car bien souvent en face de nous, ce ne sont pas des développeurs, codeurs ... mais des spécialistes en mkting, comm ... (donc sans aucune connaissance technique et surtout allérgique à cela !!!) et la Drupal si bien sûr il est bien utilisé (pensé) devient plus que simple d'utilisation (niveau word lol, c mon argument choc ...). De ce que j'ai vu pour d'autre CMS parfois il faut entièrement former le client (pas seulement à l'utilisation mias quasiement à de la prog ou du code .. Typo3 par ex peut s'avérer super lourd ...)
A plus messieurs ..
Un petit point sur l'avancement du travail
Voila une discussion particulièrement riche et intéressante. Merci à tous pour votre énergie et vos idées.
En tant qu'animateur de cette discussion je me permet de faire quelques remarques :
1) Sur la forme : je ne pense pas qu'il faille créer une page wiki par type d'argumentaire. Comme le dit robby le site n'est pas vraiment adapté pour faire cela. En effet si nous devons créer une page wiki pour chaque sujet de notre travail on va vite être perdu dans une jungle d'articles non structurés. Ce n'est pas idéal, mais je crois qu'il nous faut qu'une seule page qui va regrouper l'ensemble des contributions. Si chaque rubrique est séparée par un titre de chapitre clair cela sera lisible et il sera plus facile de créer un ensemble cohérent. Votre avis ?
2) Sur le fond : Drupal fait partie de la catégorie des CMS en open Source. L'open source a des avantages importants (coûts, productivité, communauté, liberté...) qu'il faut effectivement citer mais à mon avis cela ne doit pas être le coeur de notre argumentaire. En effet, dans la plupart des cas Drupal sera évalué à côté de Joomla, Ez publish et autres consorts... Dans ce cas notre challenge est de trouver ce que Drupal offre de plus que les autres projets en open source. Par exemple : avec Drupal, 100% des modules sont en licence GPL, ce n'est pas le cas de Joomla ni de Ez Publish. Ainsi lorsque l'on commence un projet avec Drupal on a pas de mauvaise surprise et on est sur de pouvoir utiliser l'intégralité des modules sans débourser un centime. Autre exemple : avec Drupal + CCK on peut créer des modèles de données structurées complexes sans une ligne de programmation, chose qu'il est impossible de faire avec Joomla... en bref l'idée c'est de dire que Drupal offre tous les avantages du monde open source et surtout bien plus...
Qu'en pensez vous ?
Alex
www.ineation.com
Merci du retour !1) Sur la
Merci du retour !
J'ai en effet hésité, et si je me souviens bien de ce qui m'est passé par la tête je me suis dit que cela permettrais de bien distinguer, et de ne pas glisser vers un seul argumentaire fourre-tout.
Cela permettait aussi, dans mon esprit, de donner une visibilité au travail à faire.
Mais bien sur je n'ai rien contre une seule page chapitrée, même si personnellement dans ce cas et vu l'interface de groups.drupal.org sur l'édition des pages (pas de d'éditeur riche, pas de révisions) je bosserais dans google docs et je ferais des copier coller.
Car la page va vite devenir... longue !
Oui, c'est vrai que pour les "Implémenteurs" par exemple, le choix sera, souvent, Drupal contre autre CMS libre / plus ou moins ouvert.
Et je suis dans ce cas 100% d'accord pour enfoncer le clou sur "100% des modules sur drupal.org en GPL, ce n'est pas le cas ailleurs" (bien qu'il me semble que Joomla a viré les modules non-libre de son annuaire?). Il existe aussi des projets ouverts mais dans une licence moins protectrice pour l'utilisateur final que la GPL -- peut-être pas dans l'univers des CMS pur, mais en e-commerce par exemple. La GPL obligatoire est un vrai atout de Drupal.
Mais je discute avec des gens qui sont chefs de projets dans des grandes structures, ou à l'opposé qui sont "grand public", et la méconnaissance du libre est encore gigantesque. Ne parlons pas de agences de pub, où c'est la globalement catastrophe du full-flash. Vous seriez étonné de ce que je dois expliquer sur le libre, la GPL, à des professionnels -- en gros, le B-A BA. Le commercial a encore une puissance énorme dans la tête des gens.
Mesurer Drupal à Joomla, ou SPIP en france, pourquoi pas. Je pense même que cela permettra à certain de choisir SPIP pour ce qu'il fait, et non par défaut.
Mais se mesurer à Microsoft, aux CMS commerciaux, à Blogger ou Google Site/groups/apps pour le "grand public" et les petits groupes de travail, et aux autres solutions propriétaires, ça me parait, très concrètement un marché réel et énorme.
Finalement, dans mon esprit, ce qui me plairait se serait de voir l'argumentaire comme un "kit". Je choisis celui qui convient à mon interlocuteur, je retire ce qui est redondant (pas besoin d'expliquer les bases du libre à des sys admin linux !!) et voilà !
Bon, c'est pas tout ça de m'étendre, il faut aussi que je fasse ce que je dis, hein, et que je remplisse ces pages blanches :-)
PS : En plus en me relisant je me dis que je pense que l'on dit en fait la même chose... Je me trompe ??
1) je suis d'accord avec
1) je suis d'accord avec jlndrr sur le fait que les outils sur groups.drupal.org ne "semble" pas idéal pour la mise en œuvre de nos documents (de type rédactionnel), on peut commencer part une seule page , c'est en effet peut être mieux pour le début...
2) d'accord avec tous les deux. je pense que dans la tête de beaucoup de chef d'entreprise, "open source" ne rime pas avec "qualité", il y a parfois un amalgame sur le sens "open source"
juste un petit post
je tombe à l'instant sur ce site : http://www.io1.biz
il y a beaucoup d'éléments "marketing drupal" que je trouve très bien faits
à noter ce post : http://www.io1.biz/blogs/joomla-v-drupal-v-others-why-we-chose-drupal
On est effectivement tous
On est effectivement tous d'accord.
Donc :
* une partie de l'argumentaire tournera autour de la notion d'open source et ses aspects positifs.
* d'autres parties de l'argumentaire seront consacrée aux autres aspects positifs plus spécifiquement Drupaliens
En fait je pense qu'une bonne façon d'avancer, bien structurée serait de lister, en mode brainstorming, tous les arguments en faveur de Drupal puis pour chacun d'entre eux de dire quelles cibles cela touche selon la très bonne segmentation qui a été faite. Ensuite on aura un canevas pour écrire les argumentaires.
Exemple :
...
argument XX : CCK permet de créer des modèles de données complexes en un clin d'oeil --> Decideurs techniques / Implémenteur
argument XX+1 : Modèle de licence GPL = Liberté de choix par rapport à l'agence web, --> Decideurs techniques et non techniques
...
On fait une grande liste exhaustive, on hiérarchise puis on rédige nos argumentaires...
PS : plus on travaille ensemble sur le sujet, plus je suis frustré par les limites de notre outil de collaboration. Qu'est qu'on fait ? On continue comme cela sinon, si vous voulez, j'installe mediawiki sur mon serveur et on travaille avec un vrai bon wiki...
Alex
www.ineation.com
lister, en mode
En relisant ton post, je me dis qu'il y a juste une chose auquel il faut faire attention dans le processus d'écriture des argumentaires : ne pas renverser les choses.
Trouver des solutions, et seulement ensuite les problèmes et les users pour ces solutions risque IMHO de mener aux textes marketing classiques qui listent des dizaines de fonctionnalités -- marketing orienté produit.
Ces textes sont inefficaces, car ils partent du principe que les cibles ont connaissance de leurs problèmes, et cherchent activement à se renseigner sur le produit en question. Ce n'est généralement pas le cas, ni pour la connaissance, ni pour l'action !
Prenons soin de rester sur du marketing orienté utilisateur, c'est à dire :
Identifier pour chaque catégorie de personne, les problèmatiques courantes -- et que les users n'ont pas nécessairement identifiés eux-même, d'ailleurs.
Pour ces problématiques, identifier les solutions et points fort de Drupal.
(Perso, je suis de toute façon incapable de dresser une liste des arguments en faveur de Drupal in abstracto, je ne peux que dire que pour tel problème dans tel cas, Drupal apporte tel solution)
D'après moi il faut donc que :
chacun apporte des exemples de problèmes/besoins réels d'utilisateurs de chaque catégorie -- les petites histoires réel ont plus d'impact à lire, en plus.
pour chaque problème, nous expliquons la réponse de Drupal -- et parfois il n'y en aura pas, et dan ce cas, nous devrions le dire -- esprit communautaire d'abord
On rewrite et on lisse :-)
Donc je ferais un "appel à problème", du genre : merci de signaler les besoins et problèmes que rencontre vos amis, prospects, clients, boss, etc.
J'ai installé un wiki sur mon serveur
Il est dispo à l'adresse http://wiki.ineation.com/
Dites moi si cela vous convient ou si vous préférez travailler autrement.
Alex
www.ineation.com
liste pour les études de cas...
Petit quiproquo, en fait j'attendais la suite des évènements... je vois que ce post s'est bien rempli, bravo !
Je peux la publier effectivement ici ou sur le Wiki mentionné...
Je précise que c'est une première approche d'une liste de sites professionnels réalisé sous Drupal, représentatifs de différents type de marchés,
Ce ne sera pas of course la liste de TOUTES les études de cas qui seront (ou pourraient être) réalisées ;-)
C'est une liste (open) pour servir de base de travail, dans lequel le groupe de réflexion pourrait choisir démocratiquement les exemples les plus représentatifs.
christophe
http://www.interfaces-enrichies.fr/
liste de site pros
Bonjour,
Voici une liste avec des réf de grands groupes ou organisations utilisant Drupal
http://buytaert.net/tag/drupal-sites
J'ajouterai :
www.france24.com
www.femina.ch (connus ici en Suisse ...)
A plus
Merci, Tu peux compléter la
Merci, Tu peux compléter la liste en cours d'élaboration sur le wiki du groupe marketing : http://wiki.ineation.com/index.php/Les_%C3%A9tudes_de_cas
Alex
www.ineation.com
done
qq ajouts ...
A plus
Merci d'utilisier le wiki pour vos contributions...
La coordination de l'écriture étant très difficile via groupes.drupal.org, un wiki a été mis en place afin de centraliser toutes les délivrables du groupe. Merci de bien vouloir utiliser http://wiki.ineation.com pour vos contributions, c'est beaucoup plus efficace. La discussion engagée ici peut bien sur continuer sur ce post.
Alex
www.ineation.com
C'est une bonne idée, mais
C'est une bonne idée, mais j'avoue que je meurt d'envie de travailler sur un éditeur riche.... Et avec l'éditeur wiki, je ne peux même pas copier/coller du HTML (pour les gras, italique)
si, si tu peux regarde la
si, si tu peux regarde la liste des tags autorisés ici http://meta.wikimedia.org/wiki/Help:HTML_in_wikitext.
Sinon le wiki a sa propre syntaxe bien plus rapide à écrire que le html. Exemple pour du gras il suffit d'encadrer le texte avec 3 apostrophes, regarde le mode d'emploi ici : http://meta.wikimedia.org/wiki/Help:Wikitext.
Honnêtement c'est l'outil parfait pour ce que l'on veut faire...
Alex
www.ineation.com
ok, je retire ce que j'ai
ok, je retire ce que j'ai dit ! Sorry, sorry.
De toute façon, si c'est bon pour wikipedia, c'est bon pour moi !
On repart quand même sur 5 pages, un pour chaque cible ? Pour moi c'est plus aisé, je vais avoir du mal avec une seule page.
Et on fera une page de récap qui pointe vers chacune des 5.
PS : peux-tu agrandir la zone de saisie ? J'ai perso tendance à préférer les zones de saisie exagérément grande !
suis d'accord
je pense que l'intérêt du vrai wiki et de pouvoir faire une arborescence avec comme pièce maitresse la page d'accueil. comme le dit jlndrr, la création de plusieurs pages (une pour chaque cible) me paraît vraiment plus simple. lors d'une relecture finale, on pourra toujours corriger/déplacement/supprimer des éléments d'argumentaires redondants ou ne se trouvant pas à la bonne place. d'ou mon idée d'un "rédacteur en chef" pour chaque argumentaire (ou pour la totalité).. à voir
++
Méthodologie
je viens d'ajouter sur le wiki ce que je disais sur mon post "prenons soin de rester sur du marketing orienté utilisateur" sous une rubrique méthodologie.
Modifs welcome !
J'ai supprimé les
J'ai supprimé les argumentaires ici.
retrouvez-les sur
http://wiki.ineation.com/index.php/L%27argumentaire
Super, on commence à
Super, on commence à avancer maintenant.
Alors pas si mal que cela le wiki non ?
Alex
www.ineation.com
oui, une fois dépassé
oui, une fois dépassé l'angoisse de la page blanche, c'est vrai que ça marche très bien !!
Argument : la rapidité de mise en œuvre de maquette/benchmark
Bonjour,
j'ai mis du temps à réagir, occupé justement à rédiger un argumentaire de plus pour un client,
donc je suis "chaud" !
je me redirige vers le wiki
Christian Artin
www.mainparty.net
www.femmes-emploi.fr
www.webaram.com
J'ai rédigé un argumentaire généraliste
J'ai rédigé un argumentaire généraliste en m'inspirant de celui du site d'Acquia, je l'ai placé dans la rubrique Argumentaire pour les relais d'opinion.
http://wiki.ineation.com/index.php/L%27argumentaire#Argumentaire_Relais_...
Merci de votre avis...
Alex
www.ineation.com
Super ! Bonne base de
Super ! Bonne base de travail...
Comme les relais d'opinion n'ont pas de problème précis à résoudre, c'est vrai que dans ce cas il est plus difficile de passer par la méthodo classique du "Votre problème ? Solution par Drupal"
Je vais me permettre de changer quelques termes par des termes plus génériques, moins geek, genre framework par "boite à outil". Si vous trouvez que ça diminue la précision du texte, dites le moi.
première réécriture
Je viens de finir une première réécriture de "Argumentaire pour les relais d'opinion"
Je fais un appel à l'aide pour une partie :
Historique de Drupal
(expliquer le nom, donner des anecdotes qui rendent le truc moins froid et plus humain : car ce qui donne cette dynamique à drupal c'est quand même ça, des humains généreux et talentueux !!! Parler de http://drupal.org/user/1, au minimum
Qui peut écrire là dessus ?)
Toute participation, même une ligne ou deux bienvenue sur :
http://wiki.ineation.com/index.php?title=L%27argumentaire&action=edit&se...
je suppose que tu as déjà
je suppose que tu as déjà regardé ici : peut être quelques élément (vidéo) :
http://drupal.org/node/769
OK, merci du lien. N'hésite
OK, merci du lien.
N'hésite pas à aller écrire sur le sujet, même une phrase ou deux, sur le wiki.
IMHO, Il y a pour l'instant trop peu de contributeurs pour assurer une validation croisée et des idées variées. J'espère que cela va évoluer dans les prochaines semaines.
Proposition de squelette pour les études de cas
en prévision de la réunion de lundi J'ai mis en place une proposition d'un premier draft pour créer des modèles d'étude de cas et ainsi avoir des présentation de structure identique. J'ai sorti la partie module de la partie développement, car je pense qu'il serait intéressant de bien mettre en avant les modules utilisés dans un projet Drupal.
draft étude de cas,
http://www.interfaces-enrichies.fr/