Share
Enten du leter til høyre eller venstre, er det liten tvil om at hvis du er en Nettuts + leser, vil du trolig være enig i at teknologien raskt utvikler politikk. I USAs presidentkampanjer var nettverket en viktig plattform for frontforwarding av en melding, men det var også en sentral del av hver enkelt sides interne prosesser.
Nylig hadde vi muligheten til å intervjue Daniel Ryan - direktøren for Frontend Development for "Obama for Amerika" - om strategier, teknologier og erfaringer som var en del av rase til 6. november.
Den største skalautfordringen var ikke et enkelt prosjekt; Det var det store antallet forespørsler vi fikk hver dag. Våre dev team ble delt mellom tre områder: innsamling, overtalelse og få velgere til avstemningene. Omdirigering av nye design gjennom godkjenninger ved melding, politikk, forskning, lovlig mv., Og deretter lansering av prosjektene innen få dager eller ofte noen få timer, var den største utfordringen. Både Design og Dev hadde et team av Produsenter som klarte disse forespørslene, tildelt dem til relevant personale og så dem gjennom gjennomføring.
Den største utfordringen [...] var skjærvolumet av forespørsler vi fikk hver dag.
En av tingene som har blitt sagt ofte om kampanjen er at vi var datadedrevne. Dette kan ikke være mer sant. Min stedfortreder Kyle Rush overvåker en optimaliseringsgruppe som består av utviklere, designere, brukeropplevelsesingeniører, dataanalytikere, online annonsespesialister og innholdsforfattere. Vi brukte en blanding av tilnærminger, hovedsakelig fokusert på Optimizely for A / B testing for å bevise (og disprove, ofte) teser om hvordan sider kan utføre bedre.
Våre trafikknivåer betydde at vi kunne kjøre flere tester per dag til betydelige nivåer. En ukentlig rapport ble utarbeidet med oppdaterte beste praksis og anbefalinger basert på disse funnene. Vi anslår at vi oppnådde ca 125 millioner dollar i trinnvise forbedringer på våre innsamlingssider alene.
Det var ikke en enkelt stabel. En av de smarteste tingene vi gjorde var å drive dusinvis avkoblede systemer knyttet sammen med JavaScript og Akamai-tjenester. Bredt stakk vår stabling på Amazon Web Services, inkludert tusenvis av EC2-forekomster, flere store databaseklynger og S3-hosting. Vårt hovedsted, www.barackobama.com, var en Expression Engine installasjon støttet av EC2 og RDS og fronted av Akamai caching.
Akamai avlastet omtrent 98% av all vår trafikk. I tillegg brukte vi Jekyll, flere tilpassede apper bygget på Django, Flask, Rails og Magento. Vårt mest brukte språk var Python.
En av de smarteste tingene vi gjorde var å drive dusinvis avkoblede systemer knyttet sammen med JavaScript og Akamai-tjenester.
På klientsiden rullet vi vårt eget CSS-nett og kjernestiler sammen med jQuery, Modernizr og et kjerne-JavaScript-bibliotek som lazy loaded moduler etter behov. Vi brukte Mustache.js maler ganske mye for nettleserbaserte apps. Som det første responsive nettstedet for en nasjonal kampanje, prøvde vi mange åpen kildekodeverktøy for å gjøre mobile opplevelser bedre. Fitvids.js var en av de mest brukte. Internt jobbet vi i LESS CSS, utarbeidet av CodeKit. En av devs viste meg MINDRE mens vi overhørte nettstedet i oktober 2011; ved slutten av dagen hadde hele nettstedet byttet til det. Dette er bare et eksempel på hvordan vi ble åpne for bedre tilnærminger hver dag og var ikke redd for å omfavne en ny metode eller system hvis det var fornuftig.
Vi kjørte git som vår VCS av valg, for alle de åpenbare årsakene. All vår kode gikk gjennom Github, som også fungerte som vår hovedkodestyringsflyt. Vi var tungt styrt av prinsippene "How Github bruker Github å bygge Github". Hvor det var fornuftig, var flyten vår:
Vi fikk ikke bruke denne flytningen overalt vi ville ha likt, fordi vi kom inn i et arbeidssystem, i stedet for å starte fra bunnen av. Da jeg ankom i august 2011, var det for eksempel ingen dev eller staging miljøer for vårt hovedsted. Vi oppnådde et internasjonalt system ganske raskt, men kjempet alltid for å ha lokale dev-miljøer for Expression Engine.
Design ideer kom stort sett fra designteamet direkte. Josh Higgins, designdirektør, og jeg jobbet veldig hardt for å sikre at våre lag samarbeidet kontinuerlig. Vi satt i vår egen del av kontoret sammen med program- / prosjektledere, slik at vi kunne holde de to lagene fysisk nær hverandre. Mange av designene vi rullet ut startet av en designer eller utvikler å finne en kul ide et sted og sende det til de to lagene. Disse ideene ble da den vernacular vi ville snakke om når vi forsøkte å komme opp med et bestemt konsept. Som med alt annet, var data vår guide. Uansett hvor kul vi trodde noe var, hvis dataene viste at det ikke var de resultatene vi ønsket, ville vi prøve en annen tilnærming.
Mange av designene vi rullet ut startet av en designer eller utvikler å finne en kul ide et sted og sende det til de to lagene. Disse ideene ble da den vernacular vi ville snakke om når vi forsøkte å komme opp med et bestemt konsept.
Prosessen var som en god digital byrå. Vi hadde et kickoff-møte med PM, Produsenter, Leads, etc. for å finne frem til omfanget av et prosjekt. Noen ville sende rundt notatene fra det, og vi ville alle tilpasse dem litt og deretter sende opp til vårt lederskap for å få signatur av den retningen vi ønsket å gå inn. Etter å ha inkorporert tilbakemelding, ville en designer begynne comps eller, For mer kompliserte prosjekter, ville en utvikler starte prototyper. Den tildelte utvikleren og designeren ville iterere gjennom disse inntil prosjektet var levende og klar for testing. Normalt vil vi sende staging-versjonen for godkjenninger samtidig som QA-teamet gjorde kryssleser testing. Teamet ville iterere på notatene fra begge og da ville vi starte. Husk at i slutten av sommeren gjorde vi dette på et dusin prosjekter eller mer samtidig. Mange ganger vil vi gjøre hele denne syklusen på en enkelt dag.
Jeg tror at vår tilnærming i utgangspunktet kokte ned til pragmatisk paranoia.
Dette var min første kampanje som en medarbeider, men vi hadde mange alumni fra '08 med oss. Jeg tror jeg hadde vært i Chicago mindre enn en uke før jeg hadde hørt om feilen til Houdini, som var Obama '08-systemet som var relatert til Romney's Orca. På grunn av den institusjonelle opplevelsen med dette voters overvåkingssystemets feil, setter vi oss aldri på et sted der en enkelt systemfeil kan gjøre reell skade. Vi hadde luksusen av tid, som vi delvis brukte til å bygge oppløsninger. Vår betalingsprosessor, for eksempel, var faktisk et internt system og ett leverandørsystem som Akamai vendte mellom automatisk hvis den ene siden gikk ned. Det systemet fungerte så bra vi repliserte det til valglokaler. Vi hadde to APIer, en intern og en drevet av Google, med en tynn PHP-app for å gjøre utdataene det samme. Ikke bare kan Akamai mislykkes mellom dem uten sluttbrukeren, men vi hadde et system på plass der vi kunne velge hvilke stater som brukte systemet som proaktivt. Dette gjør at vi hindrer en trafikkspikeutbrudd. Systemene vi stolte på spesielt for valgdagen, hadde alle to backup-systemer: en drevet av Google Doc-regneark og en som bestod av trykte kopier av kritiske data. Jeg tror at vår tilnærming i utgangspunktet kokte ned til pragmatisk paranoia.
I begynnelsen prøvde kampanjen å lage et jQuery Mobile-drevet nettsted, men å opprettholde to maler for alt var ikke bare å skalere. Vi så 25% av trafikken vår kommer fra mobile enheter, men nesten ingen av våre donasjoner. Når vi satte opp for å gjøre et nettsted ettersyn i høsten 2011, var det en foregone konklusjon vi ville gjøre mobil-først, lydhør / adaptiv. Det var en læringsprosess for oss alle. Hvis det er en takeaway jeg virkelig ville stress, betyr mobil-først ikke å starte med en 320 pixel bred design, det betyr å starte med en lav båndbredde opplevelse. Vi lærte denne leksjonen om og om i løpet av kampanjen. Mobile først er en omfattende tilnærming, inkludert innholdsskaping som er mobilvennlig, design som er fleksibelt og kode som er så mager som mulig.
Mobil-først betyr ikke å starte med en 320 piksler bred design, det betyr å starte med en lav båndbredde opplevelse.
Den største leksjonen jeg lærte om storstilt distribusjon er å leie smarte mennesker. Når du prøver å tune på skalaen, spesielt i hockeypinnekurven, visste vi at vi skulle ha, du trenger folk på hver del av stabelen og tenker på hvordan du skal være mer effektiv. De fleste av teamet mitt hadde ingen erfaring på den skalaen vi likte å jobbe med, men vi lærte raskt og tilpasset.
Jeg tror virkelig at dette er den siste presidentkampanjen der "Internett-folkene" vil bli skilt i sin egen gruppe.
Strukturen varierte etter prosjekt, men vår overordnede struktur var i utgangspunktet delt inn i de tre skuffene jeg nevnte tidligere: innsamling, overtalelse og utvilsing av velgere. Internt var det en digital avdeling, som teamet mitt var med i sammen med Design, Online Annonser, Sosialt, Email, Innhold, Digital Analytics, Programledere, Video, Online Organisering, Rapid Response og Administrasjonsteamet. Vanligvis håndterte vi all kampanjenes offentliggjorte arbeid på nettet. I tillegg var teknisk avdeling ansvarlig for infrastrukturen (vårt DevOps-team) og server-side-koden for praktisk talt alt vi gjorde. Det var også noen overgang mellom de to avdelingene. En stor del av min rolle var koordinering med Tech og DevOps da vi kontinuerlig distribuerte flere og flere systemer.
Jeg tror virkelig at dette er den siste presidentkampanjen der "Internett-folkene" vil bli skilt i sin egen gruppe. Vårt arbeid dekket hvert område av kampanjen på et tidspunkt. 2016 bør være mye mer av et matrise org diagram enn en hierarkisk.
Takk igjen til Daniel for å godta å snakke med oss. For å holde deg oppdatert, vær sikker på å følge ham på Twitter, og hold øye med hans nettside.
Accentsconagua