Share
Sia che ti appoggi a destra o a sinistra, non c'è dubbio che, se sei un lettore di Nettuts +, probabilmente sarai d'accordo sul fatto che la tecnologia sta rapidamente plasmando la politica. Nelle campagne presidenziali degli Stati Uniti, il web era una piattaforma importante per l'unificazione frontale di un messaggio, ma era anche una parte fondamentale dei processi interni di ciascuna parte.
Recentemente, abbiamo avuto l'opportunità di intervistare Daniel Ryan - il direttore di Frontend Development per "Obama per l'America" - sulle strategie, le tecnologie e le esperienze che facevano parte della corsa al 6 novembre.
La sfida più grande non era un singolo progetto; era il volume di richieste che ricevevamo ogni giorno. La nostra squadra di sviluppo è stata divisa in tre aree: raccolta fondi, persuasione e partecipazione agli elettori. Trasformare nuovi progetti attraverso le approvazioni tramite messaggistica, policy, ricerca, legale, ecc., Quindi lanciare quei progetti in pochi giorni o spesso poche ore è stata la sfida più grande. Sia Design che Dev avevano una squadra di produttori che gestiva quelle richieste, le assegnava allo staff pertinente e le vedeva attraverso il completamento.
La più grande sfida [...] è stata il volume di richieste che abbiamo ricevuto ogni giorno.
Una delle cose che sono state dette spesso riguardo alla campagna è che eravamo guidati dai dati. Questo non potrebbe essere più vero. Il mio vice Kyle Rush ha supervisionato un gruppo di lavoro di ottimizzazione composto da sviluppatori, progettisti, ingegneri di esperienza utente, analisti di dati, specialisti di annunci online e scrittori di contenuti. Abbiamo usato un mix di approcci, principalmente focalizzati su Optimizely per il test A / B per dimostrare (e smentire, spesso) tesi su come le pagine potrebbero funzionare meglio.
I nostri livelli di traffico ci permettevano di eseguire più test al giorno a livelli significativi. Un rapporto settimanale è stato compilato con le migliori pratiche e raccomandazioni aggiornate basate su tali risultati. Stimiamo di aver raggiunto circa 125 milioni di dollari in miglioramenti incrementali solo per le nostre pagine di raccolta fondi.
Non c'era una singola pila. Una delle cose più intelligenti che abbiamo fatto è stata eseguire dozzine di sistemi disaccoppiati collegati con i servizi JavaScript e Akamai. In generale, il nostro stack è stato eseguito su Amazon Web Services, incluse migliaia di istanze EC2, numerosi cluster di database di grandi dimensioni e hosting S3. Il nostro sito principale, www.barackobama.com, era un'installazione di Expression Engine supportata da EC2 e RDS e preceduta dalla memorizzazione nella cache di Akamai.
Akamai ha scaricato circa il 98% di tutto il nostro traffico. Inoltre abbiamo utilizzato Jekyll, più app personalizzate create su Django, Flask, Rails e Magento. Il nostro linguaggio più usato era Python.
Una delle cose più intelligenti che abbiamo fatto è stata eseguire dozzine di sistemi disaccoppiati collegati con i servizi JavaScript e Akamai.
Sul lato client, abbiamo laminato la nostra griglia CSS e gli stili core insieme a jQuery, Modernizr e una libreria JavaScript principale che ha caricato i moduli pigri secondo necessità. Abbiamo utilizzato i modelli Mustache.js un po 'per le app basate su browser. Come primo sito web reattivo per una campagna nazionale, abbiamo provato molti strumenti open source per migliorare le esperienze mobili. Fitvids.js è stato uno dei più pesanti utilizzati. Internamente, abbiamo lavorato in LESS CSS, compilato da CodeKit. Uno degli sviluppatori mi ha mostrato MENO mentre stavamo revisionando il sito nell'ottobre 2011; alla fine della giornata, l'intero sito era passato ad esso. Questo è solo un esempio di come siamo rimasti aperti ad approcci migliori ogni giorno e non avevamo paura di adottare un nuovo metodo o sistema se avesse avuto senso.
Abbiamo gestito git come VCS di scelta, per tutte le ovvie ragioni. Tutto il nostro codice passò attraverso Github, che servì anche da nostro principale flusso di gestione del codice. Siamo stati guidati pesantemente dai principi di "Come Github usa Github per costruire Github". Ovunque avesse senso, il nostro flusso era:
Non abbiamo usato questo flusso ovunque avremmo voluto, perché siamo entrati in un sistema funzionante, piuttosto che partire da zero. Quando sono arrivato ad agosto 2011, non c'erano ambienti di sviluppo o di messa in scena per il nostro sito principale, ad esempio. Abbiamo implementato un sistema di gestione temporanea abbastanza rapidamente, ma abbiamo sempre avuto difficoltà ad avere ambienti di sviluppo locali per Expression Engine.
Le idee di progettazione provenivano in gran parte direttamente dal team di progettazione. Josh Higgins, il nostro Design Director, e ho lavorato molto duramente per assicurarci che i nostri team collaborassero continuamente. Ci siamo seduti nella nostra sezione dell'ufficio, insieme ai responsabili del programma / progetto, così da poter tenere i due team fisicamente vicini l'uno all'altro. Molti dei progetti che abbiamo lanciato sono stati avviati da un designer o sviluppatore che ha trovato un'idea interessante da qualche parte e l'ha inviata via email ai due team. Queste idee divennero quindi il vernacolo di cui parleremo quando tenteremo di elaborare un concetto specifico. Come per tutto il resto, però, i dati sono stati la nostra guida. Non importa quanto fico pensavamo che qualcosa fosse, se i dati mostrassero che non stavamo ottenendo i risultati che volevamo, avremmo provato un altro approccio.
Molti dei progetti che abbiamo lanciato sono stati avviati da un designer o sviluppatore che ha trovato un'idea interessante da qualche parte e l'ha inviata via email ai due team. Queste idee divennero quindi il vernacolo di cui parleremo quando tenteremo di elaborare un concetto specifico.
Il processo era molto simile a qualsiasi buona agenzia digitale. Avremmo una riunione preliminare con PM, produttori, lead, ecc. Per capire lo scopo di un progetto. Qualcuno manderebbe gli appunti da questo e li faremmo tutti per un po 'e poi manderemmo alla nostra leadership per ottenere l'approvazione sulla direzione in cui volevamo entrare. Dopo aver incorporato il feedback, uno stilista avrebbe iniziato a comps o, per progetti più complicati, uno sviluppatore avrebbe iniziato i prototipi. Lo sviluppatore e il progettista assegnati continueranno a scorrere fino a quando il progetto non sarà pronto per essere testato. Normalmente, inviamo la versione di staging in giro per le approvazioni contemporaneamente al team di controllo qualità che eseguiva test cross-browser. Il team avrebbe iterato sugli appunti di entrambi e poi avremmo lanciato. Tieni presente che verso la fine dell'estate, stavamo facendo questo su una dozzina di progetti o più contemporaneamente. Molte volte, faremo l'intero ciclo in un solo giorno.
Penso che il nostro approccio fondamentalmente si sia ridotto alla paranoia pragmatica.
Questa è stata la mia prima campagna come membro dello staff, ma abbiamo avuto molti ex alunni dal '08 con noi. Penso di essere stato a Chicago meno di una settimana prima di aver saputo del fallimento di Houdini, che era il sistema di Obama del 2008 simile all'Orca di Romney. A causa dell'esperienza istituzionale con questo fallimento del sistema di monitoraggio degli elettori, non ci siamo mai posti in un punto in cui un singolo guasto del sistema poteva arrecare un danno reale. Abbiamo avuto il lusso del tempo, che abbiamo usato in parte per costruire licenziamenti. Il nostro processore di pagamento, ad esempio, era in realtà un sistema interno e un sistema di un fornitore che Akamai si spostava automaticamente da una parte all'altra se una delle due parti andava giù. Quel sistema ha funzionato così bene che l'abbiamo replicato per i seggi elettorali. Avevamo due API, una interna e l'altra alimentata da Google, con una sottile app per PHP per rendere l'output uguale. Akamai non solo potrebbe fallire automaticamente tra di loro senza che l'utente finale se ne accorga, ma disponevamo di un sistema in cui poter scegliere quali stati utilizzavano il sistema in modo proattivo. Questo ci permette di prevenire un'interruzione del traffico. I sistemi su cui ci siamo basati in particolare per Election Day avevano tutti due sistemi di backup: uno alimentato da fogli di lavoro di Google Doc e uno costituito da copie cartacee stampate di dati critici. Penso che il nostro approccio fondamentalmente si sia ridotto alla paranoia pragmatica.
All'inizio, la campagna ha provato a creare un sito basato su jQuery Mobile, ma il mantenimento di due modelli per tutto semplicemente non stava andando in scala. Stavamo vedendo il 25% del nostro traffico proveniente da dispositivi mobili, ma quasi nessuna delle nostre donazioni. Quando abbiamo deciso di fare una revisione del sito nell'autunno del 2011, era una conclusione scontata che avremmo fatto prima mobile, reattivo / adattivo. È stato un processo di apprendimento per tutti noi. Se c'è un take-away che vorrei sottolineare, mobile-first non significa iniziare con un design di 320 pixel, significa iniziare con un'esperienza di larghezza di banda bassa. Abbiamo imparato questa lezione più e più volte nel corso della campagna. Il primo mobile è un approccio completo che include la creazione di contenuti che è mobile friendly, un design flessibile e un codice il più possibile snello.
Mobile-first non significa iniziare con un design a 320 pixel, significa iniziare con un'esperienza a bassa larghezza di banda.
La lezione più grande che ho imparato sull'implementazione su larga scala è quella di assumere persone intelligenti. Quando stai provando a sintonizzarti su scala, specialmente nella curva del bastone da hockey che sapevamo di avere, hai bisogno che le persone in ogni parte della pila pensino a come essere più efficienti. La maggior parte della mia squadra non aveva esperienza sul tipo di scala in cui lavoravamo, ma abbiamo imparato rapidamente e adattato.
Credo davvero che questa sia l'ultima campagna presidenziale in cui le "persone di Internet" saranno separate nel proprio gruppo.
La struttura variava in base al progetto, ma la nostra struttura complessiva era fondamentalmente divisa in quei tre secchi che ho menzionato prima: raccolta di fondi, persuasione e risultato degli elettori. Internamente, c'era un dipartimento digitale di cui il mio team faceva parte insieme a Design, annunci online, social, email, contenuti, analisi digitali, gestori di programmi, video, organizzazione online, risposta rapida e il nostro team di gestione. In generale, gestivamo online tutte le attività pubbliche della campagna. Inoltre, il dipartimento tecnico era responsabile dell'infrastruttura (il nostro team DevOps) e del codice lato server per praticamente tutto ciò che facevamo. C'era anche qualche incrocio tra i due dipartimenti. Gran parte del mio ruolo era il coordinamento con Tech e DevOps in quanto abbiamo costantemente implementato sempre più sistemi.
Credo davvero che questa sia l'ultima campagna presidenziale in cui le "persone di Internet" saranno separate nel proprio gruppo. Il nostro lavoro copriva ogni area della campagna ad un certo punto. Il 2016 dovrebbe essere molto più di un organigramma a matrice che di uno gerarchico.
Grazie ancora a Daniel per aver accettato di parlare con noi. Per rimanere aggiornato, assicurati di seguirlo su Twitter e tieni d'occhio il suo sito web.
Accentsconagua