Mens PostgreSQL Elephant fortsætter
sin march mod endnu en udgivelse, har jeg tænkt en del
over den rolle, som brugere af software skal have i dens brugergrænseflade
design. I dag foreslog jeg noget, der gør, at en databaseparameter
folk plejede at skulle bekymre sig om, og det var slet ikke indlysende
hvordan man indstiller, og som gør dens værdi stort set automatisk. Det er en ret
utvetydig fremadrettet ændring; brugere var irriterede, god standardadfærd
etableret, og denne standardadfærd blev foreslået som en patch. Hvis det bliver anvendt, ville jeg blive chokeret over at finde nogen, der anser det for en dårlig
beslutning.
Der har været en lignende diskussion om
hvordan man omarbejder brugergrænsefladen omkring databasekontrolpunkter. Lige
nu er den hastighed, hvormed data skrives til disken af et kontrolpunkt,
påvirket af tre værdier, som brugeren kan angive. Interaktionen
mellem disse er dokumenteret godt nok, dog på en måde, der
afspejler kompleksiteten, og nogle brugere oplever, at den adfærd den giver
fungerer godt. Det er meget muligt, at for at gøre tingene
bedre for den typiske bruger, vil der i nogle tilfælde være en præstationsregression i forhold til den aktuelle kode. Brug af en
anden implementering, der ændrer den effektive skala af
parametrene, vil resultere i subtile timingændringer, og de vil ikke
nødvendigvis alle være positive. I denne situation er det bedste, vi kan gøre
som et udviklingsfællesskab, at indsamle nok benchmarkdata til at foretage
det opkald. Det kan være, at forbedring af de værst tænkelige scenarier
fjerner tingene lidt i forhold til den tidligere implementering. Hvis
nettoresultatet viser sig at være lettere at justere – at erstatte flere
komplicerede indstillinger med en enkelt, som jeg foreslog, kunne det være den
rigtige retning her – det burde i gennemsnit være bedre. På nogle
tider er det nødvendigt at give slip på den gamle tilgang for at få
en, der er bedre.
Men det er så meget, vi er bekymrede
om at bryde adfærd, som brugere stoler på. Der er stort fokus på
bagudkompatibilitet og kun at tilføje ting på en måde, der ikke
fjerner den gamle tilgang i PostgreSQL-udvikling. Nogle gange er der
ikke noget valg dog:du er nødt til at skubbe mod en ny tilgang. I tilfælde
hvor både gammel og ny adfærd er helt legitim, er det svært at nå frem til selv en klar flertalsopinion. Det er ofte
tilfældet i design af brugergrænseflader. Selvom du kan benchmarke det med
de rigtige værktøjer og fagfolk, men det bliver sjældent gjort i
open source-fællesskabet. Det er svært at få en fællesskabskonsensus ud af den blanding
af meget personlige meninger.
Jeg blev igen mindet om, hvordan man ikke skal
håndtere brugerfeedback som udvikler ved at få nogle opdateringer i dag
om en længe irriterende regression i, hvordan gnome- terminal, min nominelle
foretrukne kommandolinjeterminal, håndterer tastaturinput. Problemet
forstod først i en fejlrapport for næsten nøjagtigt to år siden, på en
Ubuntu-tracker, kun for at migrere til den underliggende
kilde til regression:en bevidst ændring af en af GNOME'erne
udviklere for at eliminere adfærd, de fandt upassende. Der blev åbnet en billet, der anmodede om en rettelse, men det var aldrig mere end at være fornærmende for alle involverede.
Jeg har været aktiv nok i sidstnævnte
billets historie til, at jeg ikke behøver at gentage mit argument her.
I bund og grund var alt, hvad jeg ønskede, en afkrydsningsboks-konfigurationsmulighed for at
gøre det muligt at vende tilbage til den gamle adfærd. Jeg begyndte endda at arbejde
på at gøre netop det, grave i koden for at foreslå løsninger,
kun for at indse, at der ikke var nogen måde, dette nogensinde ville blive flettet sammen. Mine
forslag var fokuseret på at forsøge at finde et fælles grundlag, som ville behage alle. Det er meget tydeligt, at udviklerne bare er ligeglade
med det. De gør tingene, som de vil, og
alle andre er lige meget. At jeg fik at vide, at det ville tage "et
et par hundrede" klager, før dette ville blive betragtet som vigtigt
forvirrer mit sind, i betragtning af at kontrolnøglebrug i terminalen ikke ligefrem er den mest populære ting . Der var snesevis af rapporter,
hver modtagne klage blev samlet i den foretrukne
opløsning, og den eneste person, der var uenig, var en af deres
udviklere.
Vi får nogle klager fra folk over, at
PostgreSQL-fællesskabet er fyldt med udviklere, der foretrækker
teknisk rene løsninger frem for bare at give brugerne det, de vil have.
Det er til en vis grad sandt, såsom den fortsatte modstand mod at
tilføje vis tabeller som en alternativ måde at finde
databasen i din database. Men al den diskussion har været om
emner, hvor diskussionen giver meget blandede meninger; mange mennesker
har stærke meninger på begge sider. Hvis alle brugere er enige om et
design, hvilket er tilfældet med dette problem med gnome-terminalen, er det højdepunktet af udvikler
arrogance at afvise
disse meninger som stadig ikke rigtige.
Et af de mere interessante eksempler på
denne slags ting involverer udviklerne af Pidgin IM-softwaren
ændre, hvordan chatvinduets tekststørrelse fungerer i deres program.
Brugerne gjorde oprør. Der er et godt eksempel på gammel og ny adfærd med nogle
analyser hos CodingHorror.
Alle blev markeret af den måde,
udviklerne så ud til at ignorere deres feedback. Deres opfattelse var
at community-feedbacken var irrelevant for udviklerne, fordi
de følte, at deres design var bedre end det gamle, uanset hvad
brugerne syntes. Nogen skrev et plug-in for at gendanne den gamle
adfærd. Og så var der en officiel splittelse. Missionen
erklæringen
af den resulterende gaffel, oprindeligt kaldet "Fun Pidgin" og nu
kaldet "Carrier Instant Messenger", er en interessant læsning om, hvordan
de føles brugercentreret udvikling skal fungere.
Jeff Atwoods CodingHorror-diskussion
af dette foreslog fire måder, sådan en gaffel kunne blive til. Han udelod
en meget vigtig en:muligheden for, at ved at splitte
samfundets indsats ville begge gafler dø, uden at nogen af dem havde nok
ressourcer til at konkurrere mod alternativerne. Selvom Pidgin ikke er
død endnu – det er et stykke fra at "løbe ned for gardinet og sluttede sig til
det blødende kor usynligt" – er de mindre vigtige, end de
plejede at være, og Hele denne debacle hjalp ikke deres sag. Fra
Ubuntu 9.10 erstattede Canonical Pidgin som den primære IM-klient
forsendelse med den meget populære Linux-distribution. I stedet satte de
GNOME Empathy i stedet. Ville det stadig være sket, hvis
Pidgin-samfundet ikke var gået i stykker og blev forbundet med så dårlig
PR? Muligvis, men det hjalp bestemt ikke deres sag.
At den samme slags brugeruvidende
beslutninger bliver truffet i forbindelse med et populært GNOME-projekt som
gnome-terminal er underholdende (jeg griner temmeligt end at græde) på vej mod
en lignende situation. For to måneder siden blev det annonceret, at Ubuntu
bevæger sig markant væk fra at bruge hele GNOME-softwarestak i deres næste udgivelse. Bemærk meget omhyggeligt, hvad der skete der.
Mark Shuttleworth siger, at de hyrede professionelle UI-designere, satte
dem i gang med at finde ud af, at det ville fungere bedre for desktopbrugerens
oplevelse, og derefter præsenterede resultaterne for GNOME-fællesskabet.
I stedet for at acceptere dette ekstremt værdifulde arbejde og takke Canonical
for den forskning, afviste de nok grundlæggende ideer til, at
der ikke var nogen mellemvej mulig. Ubuntu går nu på en stor
vej mod Unity-projektet, som den eneste vej tilbage til at "gøre, hvad vores
brugere vil". Baseret på min egen interaktion, jeg har haft med GNOME
udviklerne i årene, siden jeg stødte på denne ene irritation, overrasker den
reaktion Mark fik mig ikke en smule.
Vi er stadig på det punkt, hvor det ikke er
klart, hvordan denne Unity-opdeling ender med at blive. Det, jeg forventer, er
at det hele også vil føre til en slags dobbelt fiasko
situation. Der vil være en masse duplikeret udvikling, som
ikke i sig selv giver noget nyttigt i starten. De første
udgivelser vil have en forfærdelig kvalitetskontrol – det tager
en evighed at komme i orden. Og ved at opdele udviklerbasen er det
temmelig muligt, at ingen af grupperne vil have nok folk tilbage til nogensinde at
ende med at gøre et godt stykke arbejde, hvilket efterlader os alle med flere dårlige Linux-desktop
indstillinger (igen) i stedet for én samlet én, står alle i kø for at
forbedre. Jeg håbede på nuværende tidspunkt, at den måde, Nokia har forbedret
licensen til Qt på, endelig kunne overveje, hvordan man kunne fjerne
at have både Qt+GNOME. At Linux i stedet for stadig er ved at udvikle et
projekt oven i blandingen, og at navngive det Unity of all things, er en
forfærdelig joke.
Men jeg talte om databaser...en
af de interessante ting ved PostgreSQL er, hvor mange gafler den har
genereret. Den generøse BSD-licens havde ført til adskillige
closed source kommercielle gafler; Jeg plejede at arbejde i en virksomhed, der lavede
en. Netezza var den første af disse, der i sidste ende forvandlede sig til en seriøs
kommerciel produktion. Og Greenplum-databasen blev for nylig
købt af EMC, det er et meget vellykket produkt. Hvad der ikke er sket
er, at nogen af open source-gaflerne er blevet levedygtige erstatninger
for hoveddistributionen. Medmindre du har den slags store
ressourcer, som en større virksomhed kan bruge til ingeniørarbejde, er det
lettere at få samfundet til at acceptere dine ideer, end det er at prøve
og udføre en uafhængig implementering af dem. Lige fællesskab
PostgreSQL bliver bare ved med at være det rigtige valg.
PostgreSQL-fællesskabet skændes meget
og er fjendtligt indstillet over for mange ting, folk beder om; vi har endda en
liste, vi ikke ønsker at lave.
Dette er for det meste ting, der bare ikke er teknisk
gennemførlige at bygge uden ulemper, som ikke altid er indlysende for
dem, der anmoder om dem. Hvis en bruger argumenterer for, hvorfor en ændring ville
føre en bedre brugergrænseflade til noget i databasen, og
der ikke er nogen tekniske indvendinger mod, hvorfor det vil forårsage et problem,
den ændring tages i betragtning. Hvad jeg aldrig har set i fællesskabet, er
enhver af udviklerne, der står i kø mod en enstemmig, utvetydig bruger
præference – hvor denne mulighed kunne gøres tilgængelig uden
ulemper – simpelthen fordi de kan ikke lide det på den måde. Hvis du er en
udvikler af et open source-projekt, der vandrer hen til, hvor hybris har
overtrumfet ydmyghed så dårligt, skal du ikke blive overrasket, hvis dine brugere vil
vrede nok til at give sig. Og en af disse dage vil du måske opdage, at
gaflerne eller re-implementeringerne, der gør opmærksom på, hvad folk
virkelig ønsker, vil fortrænge dig.