När PostgreSQL Elephant fortsätter
sin marsch mot ännu en utgåva, har jag funderat en del
på vilken roll användare av programvara ska ha i dess användargränssnitt
design. Idag föreslog jag något som gör att en databasparameter
folk behövde oroa sig för, och det var inte alls uppenbart
hur man ställer in, och gör dess värde i stort sett automatiskt. Det är en ganska
otvetydig förändring framåt; användare var irriterade, bra standardbeteende
etablerades och det standardbeteendet föreslogs som en patch. Om det tillämpas skulle jag bli chockad över att hitta någon som anser att det är ett dåligt
beslut.
Det har förekommit en liknande diskussion om
hur man omarbetar användargränssnittet kring databaskontrollpunkter. Just
nu påverkas hastigheten med vilken data skrivs till disk av en kontrollpunkt
av tre värden som användaren kan ange. Interaktionen
mellan dessa är tillräckligt väl dokumenterad, om än på ett sätt som
speglar komplexiteten, och vissa användare tycker att beteendet det ger
presterar bra. Det är fullt möjligt att för att göra saker
bättre för den typiska användaren, kommer det att ske en prestanda
regression i vissa fall i förhållande till den aktuella koden. Att använda en
annan implementering som ändrar den effektiva skalan för
parametrarna kommer att resultera i subtila tidsförändringar, och de kommer inte
nödvändigtvis att vara positiva. I den här situationen är det bästa vi kan göra
som utvecklingsgemenskap att samla in tillräckligt med benchmarkdata för att göra
det samtalet. Det kan vara så att en förbättring av de värsta scenarierna
förvränger saker något i förhållande till den tidigare implementeringen. Om
nettoresultatet visar sig vara lättare att justera – att ersätta flera
komplicerade inställningar med en enda, som jag föreslog kan det vara
rätt riktning här – i genomsnitt borde det vara bättre. Vid vissa
tillfällen är det nödvändigt att släppa den gamla metoden för att få
en som är bättre.
Men det är så här mycket vi är oroliga
om att bryta beteenden som användare litar på. Det finns ett stort fokus på
bakåtkompatibilitet och att bara lägga till saker på ett sätt som inte
tar bort det gamla tillvägagångssättet i PostgreSQL-utveckling. Ibland finns det dock
inget val:du måste driva mot ett nytt tillvägagångssätt. I de fall
där både gammalt och nytt beteende är helt legitimt är det svårt att nå ens en tydlig majoritetsuppfattning. Så är ofta
fallet vid design av användargränssnitt. Även om du kan jämföra det med
rätt verktyg och proffs, men det görs sällan i
gemenskapen med öppen källkod. Det är svårt att få till en gemenskapskonsensus ur den blandningen
av mycket personliga åsikter.
Jag blev återigen påmind om hur man inte
hanterar feedback från användare som utvecklare genom att få några uppdateringar idag
om en länge irriterande regression i hur gnome- terminal, min nominella
föredragna kommandoradsterminal, hanterar tangentbordsinmatning. Problemet
gällde först in i en felrapport för nästan exakt två år sedan, på en
Ubuntu-spårare, bara för att migrera till den underliggande
källan till regressionen:en avsiktlig förändring av en av GNOME
utvecklare för att eliminera beteende de fann olämpligt. Det öppnades en biljett som begärde en åtgärd, men den var aldrig mer än förolämpande för alla inblandade.
Jag har varit tillräckligt aktiv i den senare
biljettens historia att jag inte behöver upprepa mitt argument här.
I huvudsak var allt jag ville ha var en kryssruta konfigurationsalternativ för att
göra det möjligt att återgå till det gamla beteendet. Jag började till och med arbeta
med att göra just det, grävde i koden för att föreslå lösningar,
bara för att inse att det inte fanns något sätt att detta någonsin skulle slås samman. Mina
förslag var inriktade på att försöka hitta en gemensam grund som skulle
tillfredsställa alla. Det är väldigt tydligt att utvecklarna bara inte bryr sig
om det. De gör som de vill, och
alla andra spelar ingen roll. Att jag fick höra att det skulle ta "några hundra" klagomål innan detta skulle anses vara viktigt
förvirrar mig, med tanke på att kontrollnyckelanvändning i terminalen inte precis är det mest populära . Det kom tiotals rapporter,
varje enskilt klagomål som mottogs förenades i den föredragna
upplösningen, och den enda personen som inte höll med var en av deras
utvecklare.
Vi får några klagomål från människor om att
PostgreSQL-communityt är fyllt med utvecklare som föredrar
tekniskt rena lösningar framför att bara ge användarna vad de vill ha.
Det stämmer i viss mån, som det fortsatta motståndet mot att
lägga till visa tabeller som ett alternativt sätt att hitta
databasen i din databas. Men all den diskussionen har handlat om
ämnen där diskussionen ger väldigt blandade åsikter; många människor
har starka åsikter på båda sidor. Om alla användare är överens om en
design, vilket är fallet med det här problemet med gnome-terminalen, är det höjden av utvecklar
arrogans att avvisa
dessa åsikter som fortfarande inte är rätt.
Ett av de mer intressanta exemplen på
den här typen av saker innebär att utvecklarna av Pidgin IM-programvaran
ändrar hur chattfönstrets textstorlek fungerar i deras program.
Användarna revolterade. Det finns ett bra exempel på det gamla och nya beteendet med en del
analys på CodingHorror.
Alla var uppmärksammade av hur
utvecklarna verkade ignorera sin feedback. Deras uppfattning var
att community-feedbacken var irrelevant för utvecklarna, eftersom
de tyckte att deras design var bättre än den gamla oavsett vad
användarna tyckte. Någon skrev ett plugin-program för att återställa det gamla
beteendet. Och så blev det en officiell splittring. Uppdraget
uttalandet
om den resulterande gaffeln, som ursprungligen hette "Fun Pidgin" och nu
kallad "Carrier Instant Messenger", är en intressant läsning om hur
de känner sig användarcentrerade utveckling bör fungera.
Jeff Atwoods CodingHorror-diskussion
av detta föreslog fyra sätt en sådan gaffel skulle kunna bli. Han utelämnade
en mycket viktig sådan:möjligheten att genom att dela
gemenskapsinsatserna skulle båda gaffeln dö, utan att någon av dem hade tillräckligt med
resurser för att konkurrera mot alternativen. Även om Pidgin inte är
död än – det är en bit från att ”springa ner för gardinen och gick med i
the bleedin' choir invisibile” – är de mindre viktiga än de
förr, och Hela detta debacle hjälpte inte deras sak. Från och med
Ubuntu 9.10 ersatte Canonical Pidgin som den primära IM-klienten
med den mycket populära Linux-distributionen. Istället sätter de
GNOME Empathy i dess ställe. Skulle det fortfarande ha hänt om
Pidgin-gemenskapen inte hade spruckit och blivit förknippad med så dålig
PR? Möjligen, men det hjälpte verkligen inte deras fall.
Att samma sorts användarokunniga
beslut fattas när det gäller ett populärt GNOME-projekt som
gnome-terminal är underhållande (jag skrattar snarare än gråta) på väg mot
en liknande situation. För två månader sedan tillkännagavs att Ubuntu
förflyttade sig avsevärt från att använda hela GNOME-mjukvarustacken i sin nästa utgåva. Notera mycket noggrant vad som hände där.
Mark Shuttleworth säger att de anlitade professionella UI-designers, satte
dem i arbete för att räkna ut skulle fungera bättre för skrivbordsanvändarens
upplevelse, och sedan presenterade resultaten för GNOME-gemenskapen.
Istället för att acceptera detta extremt värdefulla arbete och tacka Canonical
för den forskningen, avvisade de tillräckligt många grundläggande idéer för att
det inte fanns någon mellanväg möjlig. Ubuntu går nu på en stor
väg mot Unity-projektet, som den enda vägen kvar för att "göra vad våra
användare vill". Baserat på min egen interaktion som jag har haft med GNOME
utvecklarna under åren sedan jag stötte på detta irriterande, förvånar inte den
reaktionen som Mark fick mig ett dugg.
Vi är fortfarande vid den punkt där det inte är
klart hur denna Unity-uppdelning kommer att sluta. Vad jag förväntar mig är
att det hela kommer att leda till ett slags dubbelt misslyckande
också. Det kommer att finnas ett gäng duplicerade utvecklingar som
inte ensamma ger något användbart till en början. De första
utgåvorna kommer att ha en fruktansvärd kvalitetskontroll – det här tar
en evighet att bli rätt. Och genom att dela upp utvecklarbasen är det
möjligt att ingen av grupperna kommer att ha tillräckligt många människor kvar för att någonsin göra ett bra jobb, vilket ger oss alla med flera dåliga Linux-skrivbordsalternativ
(igen) snarare än en enad en står alla i rad för att
förbättra. Jag hoppades vid det här laget att det sätt som Nokia har förbättrat
licensen till Qt äntligen kunde göra med tanke på hur man skulle eliminera
att ha både Qt+GNOME. Att istället Linux håller på att utvecklas
projekt ovanpå mixen, och att döpa det till Unity of all things, är ett
hemskt skämt.
Men jag pratade om databaser...en
av de intressanta sakerna med PostgreSQL är hur många gafflar den har
genererat. Den generösa BSD-licensen hade lett till flera
sluten källa kommersiella gafflar; Jag jobbade tidigare på ett företag som tillverkade
en. Netezza var den första av dessa som till slut gelerade till en seriös
kommersiell produktion. Och Greenplum-databasen köptes nyligen
av EMC, det är en mycket framgångsrik produkt. Vad som inte
har hänt är att någon av gafflarna med öppen källkod blir livskraftiga ersättare
för huvuddistributionen. Såvida du inte har den sortens stora
resurser som ett stort företag kan använda för teknik, är det
lättare att få samhället att acceptera dina idéer än att försöka
och göra en oberoende implementering av dem. Rätt community
PostgreSQL fortsätter att vara det rätta valet.
PostgreSQL-communityt argumenterar mycket,
och är fientligt inställda till många saker som folk ber om; vi har till och med en
lista som vi inte vill göra.
Det här är för det mesta saker som helt enkelt inte är tekniskt
genomförbara att bygga utan nackdelar som inte alltid är uppenbara för
de som efterfrågar dem. Om en användare argumenterar för varför en ändring skulle
göra ett bättre användargränssnitt för något i databasen och
det inte finns några tekniska invändningar mot varför det kommer att orsaka problem,
den förändringen övervägs. Vad jag aldrig har sett i communityn är
någon av utvecklarna som ställer upp mot en enig, entydig användare
inställning – där alternativet skulle kunna göras tillgängligt utan
nackdelar – helt enkelt för att de gillar inte det så. Om du är en
utvecklare av ett projekt med öppen källkod som vandrar dit hybris har
övertrumfat ödmjukhet så illa, bli inte förvånad om dina användare blir
arga nog att dela. Och en av dessa dagar kanske du upptäcker att
gafflarna eller omimplementeringarna som uppmärksammar vad folk
verkligen vill ha kommer att förskjuta dig.