Share
Que vous soyez incliné à droite ou à gauche, il ne fait aucun doute que, si vous êtes un lecteur Nettuts +, vous conviendrez probablement que la technologie façonne rapidement la politique. Dans les campagnes présidentielles aux États-Unis, le Web constituait une plate-forme majeure pour l’unification frontale d’un message, mais c’était également un élément essentiel des processus internes de chaque partie..
Récemment, nous avons eu l’occasion d’interviewer Daniel Ryan - directeur du développement frontend pour «Obama pour l’Amérique» - à propos des stratégies, des technologies et des expériences qui faisaient partie de la course au 6 novembre..
Le plus gros défi n'était pas un projet unique; c'était le volume de demandes que nous recevions chaque jour. Notre équipe de développement était divisée en trois domaines: la collecte de fonds, la persuasion et la participation des électeurs aux urnes. Conclure de nouvelles conceptions au moyen d'approbations par messagerie, stratégie, recherche, avis juridique, etc., puis lancer ces projets en quelques jours ou souvent en quelques heures était le principal défi à relever. Design et Dev ont tous deux une équipe de producteurs qui a géré ces demandes, les a affectées aux employés concernés et les a achevées..
Le plus gros défi […] était le volume de demandes reçues chaque jour.
Une des choses qui a souvent été dite à propos de la campagne est que nous étions basés sur des données. Cela ne pourrait pas être plus vrai. Mon adjoint, Kyle Rush, a supervisé un groupe de travail sur l'optimisation composé de développeurs, de concepteurs, d'ingénieurs en expérience utilisateur, d'analystes de données, de spécialistes de la publicité en ligne et de rédacteurs de contenu. Nous avons utilisé diverses approches, principalement axées sur Optimizely pour les tests A / B, afin de prouver (et de réfuter, souvent) l’argument selon lequel les pages pourraient améliorer les performances..
Nos niveaux de trafic signifiaient que nous pouvions effectuer plusieurs tests par jour à des niveaux significatifs. Un rapport hebdomadaire a été compilé avec les meilleures pratiques mises à jour et des recommandations basées sur ces résultats. Nous estimons que nous avons réalisé des améliorations supplémentaires d’environ 125 millions de dollars sur nos seules pages de collecte de fonds..
Il n'y avait pas une seule pile. L'une des choses les plus intelligentes que nous ayons faites a été de gérer des dizaines de systèmes découplés, liés aux services JavaScript et Akamai. Globalement, notre pile fonctionnait sur Amazon Web Services, y compris des milliers d'instances EC2, plusieurs grands clusters de bases de données et l'hébergement S3. Notre site principal, www.barackobama.com, est une installation d’Expression Engine reposant sur EC2 et RDS et mise en cache par Akamai..
Akamai a déchargé environ 98% de notre trafic. De plus, nous avons utilisé Jekyll, plusieurs applications personnalisées construites sur Django, Flask, Rails et Magento. Notre langage le plus utilisé était le python.
L’une des choses les plus intelligentes que nous ayons faites a été d’exécuter des dizaines de systèmes découplés liés aux services JavaScript et Akamai..
Du côté des clients, nous avons intégré nos propres styles de grille et principaux CSS, ainsi que jQuery, Modernizr et une bibliothèque JavaScript principale qui charge paresseux des modules selon les besoins. Nous avons utilisé un peu les modèles Mustache.js pour les applications basées sur un navigateur. En tant que premier site Web réactif pour une campagne nationale, nous avons testé de nombreux outils open source pour améliorer les expériences mobiles. Fitvids.js était l’un des plus lourds utilisés. En interne, nous travaillions dans LESS CSS, compilé par CodeKit. L'un des développeurs m'a montré MOINS pendant la refonte du site en octobre 2011; à la fin de la journée, tout le site était passé à l’écran. Ceci est juste un exemple de la façon dont nous sommes restés ouverts à de meilleures approches chaque jour et n’avions pas peur d’adopter une nouvelle méthode ou un nouveau système si cela avait du sens..
Nous avons utilisé git comme notre choix de VCS, pour toutes les raisons évidentes. Tout notre code est passé par Github, qui a également servi de principal flux de gestion de code. Nous avons été fortement guidés par les principes de "Comment Github utilise Github pour construire Github". Où que ce soit logique, notre flux était le suivant:
Nous n'avons pas pu utiliser ce flux partout où nous l'aurions souhaité, car nous sommes entrés dans un système opérationnel, plutôt que de partir de zéro. À mon arrivée en août 2011, par exemple, il n'y avait pas d'environnement de développement ou de transfert pour notre site principal. Nous avons rapidement mis en place un système de préparation, mais nous avons toujours eu du mal à créer des environnements de développement locaux pour Expression Engine..
Les idées de conception sont en grande partie venues directement de l'équipe de conception. Josh Higgins, notre directeur de la conception, et moi avons travaillé très fort pour nous assurer que nos équipes collaboraient en permanence. Nous nous sommes assis dans notre propre section du bureau, avec les responsables de programme / projet, afin que nous puissions garder les deux équipes travaillant physiquement l'une à côté de l'autre. La plupart des conceptions que nous avons déployées ont été créées par un concepteur ou un développeur, qui a trouvé une bonne idée quelque part et l'a envoyée par courrier électronique aux deux équipes. Ces idées sont ensuite devenues la langue parlée avec laquelle nous parlions lorsque nous essayions de trouver un concept spécifique. Comme pour tout le reste, les données ont été notre guide. Même si nous pensions que quelque chose était cool, si les données montraient qu'il n'obtenait pas les résultats escomptés, nous essayerions une autre approche..
La plupart des conceptions que nous avons déployées ont été créées par un concepteur ou un développeur, qui a trouvé une bonne idée quelque part et l'a envoyée par courrier électronique aux deux équipes. Ces idées sont ensuite devenues la langue parlée avec laquelle nous parlions lorsque nous essayions de trouver un concept spécifique..
Le processus ressemblait beaucoup à n'importe quelle bonne agence numérique. Nous aurions une réunion de lancement avec les chefs de projet, les producteurs, les chefs de file, etc., pour déterminer la portée d'un projet. Quelqu'un enverrait les notes de cela, et nous les modifierions tous un peu, puis nous contacterions nos dirigeants pour qu'ils signent la direction dans laquelle nous voulions aller. Après avoir incorporé les commentaires, un concepteur commencerait les comps ou, pour des projets plus complexes, un développeur commencerait des prototypes. Le développeur et le concepteur affectés parcourent ceux-ci jusqu'à ce que le projet soit opérationnel et prêt à être testés. Normalement, nous envoyions la version intermédiaire pour approbation au même moment où l'équipe d'assurance qualité effectuait des tests sur plusieurs navigateurs. L'équipe parcourait les notes des deux, puis nous lancions. N'oubliez pas que vers la fin de l'été, nous travaillions sur une douzaine de projets ou plus simultanément. Plusieurs fois, nous ferions tout ce cycle en une seule journée.
Je pense que notre approche s'est essentiellement résumée à une paranoïa pragmatique.
C'était ma première campagne en tant que membre du personnel, mais nous avions beaucoup d'anciens élèves de 2008 avec nous. Je pense que j'étais à Chicago moins d'une semaine avant que j'avais entendu parler de l'échec de Houdini, le système Obama 2008 apparenté à l'Orca de Romney. En raison de l'expérience institutionnelle de l'échec de ce système de surveillance des électeurs, nous ne nous sommes jamais placés dans un endroit où une défaillance d'un seul système pourrait causer des dommages réels. Nous avions le luxe du temps, que nous avons utilisé en partie pour créer des licenciements. Notre processeur de paiement, par exemple, était en fait un système interne et un système de fournisseur qu'Akamai basculait automatiquement entre les parties en cas de panne. Ce système a tellement bien fonctionné que nous l'avons reproduit pour les bureaux de vote. Nous avions deux API, une interne et une alimentée par Google, avec une application PHP mince pour que le résultat soit identique. Akamai pouvait non seulement échouer automatiquement entre eux sans que l’utilisateur final ne le remarque, mais nous avions également un système en place nous permettant de choisir les États qui utilisaient quel système de manière proactive. Cela nous a permis d'éviter une panne de trafic. Les systèmes sur lesquels nous nous sommes fondés spécifiquement pour le jour du scrutin disposaient tous de deux systèmes de sauvegarde: l'un fonctionnant avec des feuilles de calcul Google Doc et l'autre consistant en des copies imprimées de données critiques. Je pense que notre approche s'est essentiellement résumée à une paranoïa pragmatique.
Très tôt, la campagne a tenté de créer un site utilisant jQuery Mobile, mais la maintenance de deux modèles pour tout ne pouvait tout simplement pas être étendue. Nous constations que 25% de notre trafic provenait d'appareils mobiles, mais presque aucun de nos dons. Lorsque nous avons décidé de procéder à une refonte du site à l'automne 2011, nous étions convaincus que nous ferions d'abord mobile, réactif / adaptatif. C'était un processus d'apprentissage pour nous tous. Je tiens à souligner que s'il y a une vente à emporter, la technologie mobile d'abord ne signifie pas commencer par une conception d'une largeur de 320 pixels, mais bien par une expérience avec une bande passante réduite. Nous avons appris cette leçon encore et encore tout au long de la campagne. Mobile first est une approche globale comprenant la création de contenu compatible avec les appareils mobiles, une conception flexible et un code aussi léger que possible..
Mobile-first ne signifie pas commencer avec une conception large de 320 pixels, mais bien avec une expérience de bande passante réduite.
La plus grande leçon que j'ai apprise sur le déploiement à grande échelle est d'embaucher des personnes intelligentes. Lorsque vous essayez de vous adapter à l'échelle, en particulier dans la courbe du bâton de hockey, nous savions que nous allions en avoir, vous avez besoin de personnes de chaque niveau de la pile qui pensent à être plus efficaces. La plupart des membres de mon équipe n’avaient aucune expérience du niveau auquel nous avons fini par travailler, mais nous avons appris rapidement et nous nous sommes adaptés..
Je crois vraiment que c'est la dernière campagne présidentielle où les "internautes" seront séparés dans leur propre groupe.
La structure variait selon les projets, mais notre structure générale était essentiellement divisée en trois catégories que j'ai mentionnées précédemment: la collecte de fonds, la persuasion et la préparation des électeurs. En interne, mon équipe faisait partie du service numérique: conception, annonces en ligne, réseaux sociaux, messagerie électronique, contenu, analyse numérique, gestionnaires de programme, vidéo, organisation en ligne, réponse rapide et notre équipe de direction. De manière générale, nous avons traité en ligne tout le travail de la campagne destiné au public. De plus, le département technique était responsable de l'infrastructure (notre équipe DevOps) et du code côté serveur pour pratiquement tout ce que nous faisions. Il y avait aussi des recoupements entre les deux départements. Une grande partie de mon rôle consistait à coordonner avec Tech et DevOps, alors que nous déployions sans cesse de plus en plus de systèmes..
Je crois vraiment que c'est la dernière campagne présidentielle où les "internautes" seront séparés dans leur propre groupe. Notre travail a couvert tous les domaines de la campagne à un moment donné. 2016 devrait être bien plus un organigramme matriciel qu'un organigramme hiérarchique.
Merci encore à Daniel d'avoir accepté de parler avec nous. Pour rester à jour, assurez-vous de le suivre sur Twitter et gardez un œil sur son site.
Accentsconagua