Problemet med D3

For nylig var der et par tråde på Twitter, der diskuterede vanskelighederne ved at lære d3.js. Jeg har også set dette komme op i mange lignende samtaler, jeg har haft på møder, konferencer, workshops, mailinglistetråde og slappe chats. Selvom jeg er enig i, at mange af vanskelighederne er reelle, fremhæver trådene en almindelig misforståelse, der skal ryddes, hvis vi vil hjælpe folk med at komme ind i datavisualisering.

Misforståelsen i hjertet af disse tråde er, at d3 og datavisualisering er den samme ting. At man skal udføre datavisualisering, man skal lære og bruge hele d3, og for at bruge d3 skal man lære alt af datavisualisering. I stedet vil jeg gerne understrege, at d3 er et værktøjssæt til at kommunikere komplekse datadrevne koncepter på nettet.

Hvad jeg ønsker at komme over her, er, hvordan vi kan få et mere holistisk overblik over d3's rolle i webbaseret datavisualisering. Lad os bruge en metafor inspireret af Miles McCrocklin, hvor datavisualisering sammenlignes med bygningsmøbler. Alle slags mennesker kan komme ind i bygningsmøbler af alle slags grunde, især når de ser de smukke ting, andre mennesker laver:

Eames-stolen betragtes som en mesterligt designet stolDer er mange aspirationsdata visualiseringer foretaget med d3

Folk ser det imponerende output og ønsker naturligvis evnen til at fremstille det selv, de spørger hvordan det gøres og hører ofte ”det blev lavet med d3.” Dette er starten på problemet, fordi når nogen hører, at det blev lavet med d3. , de tænker "åh, jeg burde lære d3". De går over til dokumentationen og ser noget lignende:

d3s API

Mange af disse værktøjer virker forvirrende, de kræver viden om træbearbejdning og processer, som vi aldrig har tænkt på før, eller endda vidste, at vi muligvis skulle tænke på. Vi føler os overvældede og modløse, det ser ud til, at stien til noget, der syntes inden for rækkevidde, er lang og forræderisk.

Det er her, jeg tror, ​​vi kan ændre ting til det bedre, snarere end at ændre værktøjssættet, som vi kan vejlede mennesker ud fra deres mål langs mere egnede stier for dem. Lad os undersøge et par almindelige situationer, hvor folk finder sig selv ønsker at gøre interaktiv datavisualisering, og hvordan vi måske planlægger et bedre kursus for hver enkelt.

Designeren

Vores designer er allerede komfortabel med at kommunikere ideer visuelt, de ved, hvordan man nedbryder komplekse problemer og kortlægger dem til relatable koncepter. De har en pakke værktøjer, der forbedrer deres evne til at udtrykke hvad der er i deres sind. De er ofte ikke særlig fortrolige med programmering, måske har de en vis erfaring med grundlæggende HTML og CSS til at sammensætte statiske websider. De har set, hvad folk kan lave med d3 og er drevet til at være i stand til at gøre det samme. Når de prøver at forstå, hvad der ligner en meget lille mængde kode i en bl.ock, bliver de meget forvirrede.

Hvilken del af dette er JavaScript? Hvilken del er specifik for d3? Hvad er en asynkron anmodning? Hvad er denne DOM, jeg stadig hører om?

For disse mennesker tilbyder d3 stor kraft og fleksibilitet, men først skal de lære nogle grundlæggende tekniske færdigheder til at fungere i dette miljø. Jeg anbefaler ofte Scott Murrays fremragende d3-tutorial (og bog), der dækker grundlæggende HTML-, CSS- og JavaScript-koncepter. Jeg anbefaler også at eksperimentere med at eksportere SVG fra designværktøjer som Illustrator og Sketch og imbuing dem med interaktivitet og datamagi i browseren.

Når jeg starter, opfordrer jeg ofte designere til ikke at fokusere på enter / update / exit mønster, genanvendelighed eller ydeevne. Det er meget mere nyttigt at fokusere på at få det ønskede output, når du først har noget tæt på der, er der masser af venlige mennesker, der kan hjælpe dig med at gøre det mere performant eller robust.

Analytikeren

Vores analytiker er allerede komfortabel med at arbejde med data, skrive forespørgsler og kalde kraftfulde funktioner med komplekse API'er. De har en arbejdsgang i et kraftfuldt miljø som R Studio eller Jupyter Notebooks. Mest sandsynligt kommer de til d3, fordi de ønsker at offentliggøre deres analyse på en eller anden måde. Mens analytikeren typisk er mere behagelig at programmere end designeren, er de sandsynligvis ikke bekendt med de identiske synkrasier ved programmering i et webbrowser-miljø.

Hvad er forskellen mellem SVG og lærred? Hvad svarer JavaScript til Pandas / Tidy? Hvorfor kan jeg ikke tegne et linjediagram med en SVG-linje? Hvad er denne "d" -attribut på en sti?

Til disse mennesker anbefaler jeg også en grundbegynder inden for webudvikling for at gøre sig bekendt med koncepter som DOM. Igen er mit yndlings udgangspunkt Scott Murrays d3-tutorial (og bog). Jeg vil også anbefale et crashkursus i JavaScript og JSON, der eksporterer data fra deres normale miljø som JSON til visualisering i browseren.

Når jeg starter, opfordrer jeg ofte analytikere til at ignorere en masse d3s hjælpefunktioner, da de sandsynligvis er mere fortrolige med de magtfulde funktioner i deres egne miljøer. I stedet for synes jeg det er bedst at fokusere på at eksportere dataene til et let at forbruge JSON- eller CSV-format, der matcher eksisterende eksempler.

Softwareingeniøren

Vores softwareingeniør er en interessant sag, for selv om de har en masse grundlæggende færdigheder og viden omkring webudvikling, kræver nogle af d3s værktøjer en fremmed tankegang. I vores metafor er ingeniøren ligeglad med at fremstille møbler, de arbejder på hele bygningen. Der er rammer og infrastruktur, som møblerne skal passe indefra.

Hvad er denne enter / update / exit forretning? Hvorfor har du rod med min DOM? Overgange ... Hvordan tester jeg enhederne?

Mange udviklere vil allerede være tæt kendte med DOM og JavaScript, så mit råd er faktisk at forsøge at ignorere de dele af d3, der fokuserer på DOM. Bliv i stedet bekendt med nogle nøgleværktøjer til datavisualiseringer som d3-skala. D3 er opdelt i mange mindre moduler, så det er temmelig let at kirsebær vælge den funktionalitet, du vil bruge.

Jeg understreger også at adskille layoutet af data fra visualiseringen, så ved hjælp af et modul som d3-hierarki kan du generere en datastruktur med d3 og derefter gengive dem til DOM ved hjælp af din valgte ramme.

Sølvkugler

Disse situationer er løse arketyper, mange mennesker falder et sted mellem dem, og det er også helt fint. Ideen er at adskille målene og begrænsningerne, så vi bedre kan vejlede de forskellige mennesker, der kommer ind i vores samfund.

Jeg personligt tænker på webstandarder som den laveste fællesnævner for global kommunikation. Grafik-API'erne er ikke ideelle, men hvis du med det samme vil distribuere din datadrevne oplevelse til milliarder af mennesker, synes jeg det er rimeligt at betale prisen for en relativt stejl indlæringskurve. De underliggende koncepter med 2D-grafik, visuel design, brugeroplevelsesdesign, informationsarkitektur og programmering overføres alle direkte til mange andre bestræbelser udover datavisualisering.

Men nogle gange er en stol bare et sted at sidde, vi har ikke tid eller penge til at pleje så meget, og IKEA klarer sig fint! I disse tilfælde er der masser af kortbiblioteker, der kun har brug for en lille smule konfiguration for at komme i gang.

Nogle gange er dette det eneste værktøj, du har brug for.

Elijah Meeks har lavet et fantastisk kort over d3 API, der opdeler værktøjskassen i nyttige kategorier i sin nylige artikel.

fra Elijahs D3 er ikke en Data Visualization Library-artikel.

Jeg har også forsøgt at kortlægge d3-læringslandskabet i min artikel The Hitchhiker's Guide to D3, som giver nogle links og udgangspunkt for det, som jeg mener er nogle af de mere essentielle begreber.

Rejsen er ikke let, men det kan bestemt være et eventyr!

For et stykke tid tilbage interviewede jeg en håndfuld datavisualisatorer, der lærte d3 i processen med at udtrykke sig selv og datasættene, de var interesserede i. Det fælles tema var, at de var startet med mål. De lærte, hvad de havde brug for fra d3 undervejs til at nå disse mål.

Så tag et kort og plot dit eget kursus gennem den enorme verden af ​​datavisualisering. Du kan finde nogle stier, som andre har blæst med Blockbuilder-søgning, prøv JavaScripts meget eget Notebook-miljø Observerbart, og slutte sig til over 3.000 ligesindede stoleproducenter, jeg mener datavisualisatorer på d3 slakke kanalen.

Held og lykke, jeg ser frem til at se dine visualiseringer!

Jeg vil gerne takke Erik Hazzard, Kerry Rodden, Zan Armstrong, Yannick Assogba, Adam Pearce og Nadieh Bremer for deres feedback på denne artikel.