Докато PostgreSQL Elephant продължава
похода си към поредната версия, аз доста мислех
за ролята, която потребителите на софтуера трябва да имат в неговия дизайн на потребителски интерфейс
. Днес предложих нещо, което прави параметър на база данни
за който хората трябваше да се притесняват, и това изобщо не беше очевидно
как да се зададе и прави стойността му до голяма степен автоматична. Това е доста
недвусмислена промяна напред; потребителите бяха раздразнени, добро поведение по подразбиране
установено и това поведение по подразбиране беше предложено като корекция. Ако се приложи, ще бъда шокиран да намеря някой, който смята, че това е лошо
решение.
Имаше подобна дискусия за
как да се преработи потребителският интерфейс около контролните точки на базата данни. Точно
сега скоростта, с която данните се записват на диск от контролна точка, е
влияна от три стойности, които потребителят може да посочи. Взаимодействието
между тях е документирано достатъчно добре, макар и по начин, който
отразява сложността и някои потребители намират, че поведението, което дава
е, се представя добре. Напълно възможно е, за да се направят нещата
по-добри за типичния потребител, в някои случаи ще има регресия на производителността в сравнение с текущия код. Използването на
различна реализация, която променя ефективната скала на
параметрите, ще доведе до фини промени във времето и те не
не е задължително всички да са положителни. В тази ситуация най-доброто, което можем да направим
като общност за разработчици, е да съберем достатъчно данни за сравнение, за да направим
това обаждане. Може да се окаже, че подобряването на най-лошите сценарии
леко разстройва нещата спрямо по-ранната реализация. Ако
нетният резултат се окаже по-лесен за коригиране – замяната на множество
сложни настройки с една, както предложих, може да е
правилната посока тук – средно би трябвало да е по-добре. Понякога е необходимо да се откажете от стария подход, за да получите
по-добър.
Но това е до каква степен сме загрижени
за поведението на нарушаване, на което потребителите разчитат. Има голям фокус върху
обратната съвместимост и само добавянето на неща по начин, който не
премахва стария подход в разработката на PostgreSQL. Понякога обаче
няма избор:трябва да се стремите към нов подход. В случаи,
в които и старото, и новото поведение са напълно легитимни, някога
достигането дори на ясно мнение на мнозинството е трудно. Това често е
случаят при дизайна на потребителски интерфейс. Въпреки че можете да сравните това с
правилните инструменти и професионалисти, но това рядко се прави в
общността с отворен код. Извличането на консенсус на общността от тази смесица
от много лични мнения е трудно.
Отново ми беше напомнено как да не
обработвам отзивите на потребителите като разработчик, като получавам някои актуализации днес
относно дълго досадната регресия в начина, по който gnome- терминал, моят номинален
предпочитан терминал на командния ред, обработва въвеждането от клавиатурата. Проблемът
за първи път се превърна в доклад за грешка преди почти точно две години, на
Ubuntu тракер, само за да мигрира към основния
източник на регресията:умишлена промяна от един от GNOME
разработчиците да премахнат поведението, което сметнат за неподходящо. Имаше отворен билет с искане за поправка, но никога повече не беше обидно за всички участници.
Бях достатъчно активен в историята на последния
тикет, че нямам нужда да повтарям аргумента си тук.
По същество всичко, което исках, беше опция за конфигуриране на квадратчета за отметка, която
да направи възможно връщането към старото поведение. Дори започнах да работя
да правя точно това, да ровя в кода, за да предложа заобиколни решения,
само за да разбера, че няма начин това някога да бъде обединено. Моите
предложения бяха насочени към това да се намери общ език, който да
удовлетвори всички. Много ясно е, че разработчиците просто не им пука
за това. Те правят нещата, както им харесва, и
всички останали нямат значение. Това, че ми казаха, че ще отнеме „
няколкостотин“ оплаквания, преди това да се счита за важно
ушава ми, като се има предвид, че използването на клавиш за управление в терминала
не е точно най-популярното нещо . Имаше десетки доклади,
всяка получена жалба беше обединена в предпочитаното
разрешение и единственият човек, който не беше съгласен, беше един от
разработчиците им.
Получаваме някои оплаквания от хора, че
общността на PostgreSQL е пълна с разработчици, които предпочитат
технически чисти решения, отколкото просто да дават на потребителите това, което искат.
Това е вярно до известна степен, като например продължаващата съпротива на
добавяне на покажи таблици като алтернативен начин за намиране на
базата данни във вашата база данни. Но цялата тази дискусия е била по
теми, където дискусията дава много смесени мнения; много хора
имат силни мнения и от двете страни. Ако всеки потребител е съгласен с
дизайн, какъвто е случаят с този проблем с терминала на gnome, отхвърлянето на
тези мнения като все още неправилни е върхът на
арогантността на разработчиците.
Един от най-интересните примери за
това нещо включва разработчиците на софтуера Pidgin IM
да променят начина, по който оразмеряването на текста на прозореца за чат работи в техните програма.
Потребителите се разбунтуваха. Има добър пример за старото и новото поведение с малко
анализ в CodingHorror.
Всички бяха отметнати от начина, по който
разработчиците изглежда игнорираха обратната им връзка. Тяхното схващане беше,
че обратната връзка на общността е без значение за разработчиците, тъй като
те смятаха, че дизайнът им е по-добър от стария, независимо какво
помислят потребителите. Някой написа добавка за възстановяване на старото
поведение. И тогава имаше официално разделение. Мисията
изявлението
на получения форк, първоначално наречен “Fun Pidgin”, а сега
наречен “Carrier Instant Messenger”, е интересно четиво за това как
те се чувстват насочени към потребителя разработката трябва да работи.
Дискусията за CodingHorror на Джеф Атууд
на това предложи четири начина, по които може да се окаже такъв разклон. Той изпусна
много важен един:възможността, че чрез разделяне на
усилията на общността и двата разклона ще умрат, като нито един от тях няма достатъчно
ресурси, за да се конкурира с алтернативите. Макар че Pidgin все още не е
мъртъв – това е на известно разстояние от „да спуснете завесата и да се присъедините
невидим към кървящия хор“ – те са по-малко важни, отколкото
бяха, и целият този провал не помогна на тяхната кауза. От
Ubuntu 9.10, Canonical замени Pidgin като основен клиент за IM
доставящ се с тази много популярна Linux дистрибуция. Вместо това те поставят
GNOME Empathy на нейно място. Дали това все пак щеше да се случи, ако
общността на Pidgin не се разпадна и не се асоциира с толкова лош
PR? Възможно е, но това със сигурност не помогна на техния случай.
Това, че се взимат същия вид невежи
потребителски решения по отношение на популярен проект на GNOME като
gnome-terminal е забавно (по-скоро се смея отколкото да плача) се насочва към
подобна ситуация. Преди два месеца беше обявено, че Ubuntu
се отдалечава значително от използването на пълния софтуерен стек на GNOME в следващата им версия. Отбележете много внимателно какво се е случило там.
Марк Сътълуърт казва, че са наели професионални дизайнери на потребителски интерфейс, накарали ги
да работят, за да разберат, че ще работи по-добре за изживяването на настолен компютър
и след това представили резултатите на Общност на GNOME.
Вместо да приемат тази изключително ценна работа и да благодарят на Canonical
за това изследване, те отхвърлиха достатъчно фундаментални идеи, че
не беше възможна средна позиция. Ubuntu сега се разклонява по голям
насочен път към проекта Unity, като единственият останал път да „правим това, което
нашите потребители искат“. Въз основа на моето собствено взаимодействие, което имах с разработчиците на GNOME
през годините, откакто се сблъсках с тази единствена досада,
реакцията на Марк не ме изненадва.
Все още сме в момента, в който не е
ясно как ще се окаже това разделяне на Unity. Очаквам
че цялото това нещо също ще доведе до нещо като двоен провал. Ще има куп дублирани разработки, които
отначало сами по себе си не произвеждат нищо полезно. Първоначалните
издания ще имат ужасен контрол на качеството – тези неща отнемат
вечно време, за да се оправят. И чрез разделянето на базата на разработчиците е
напълно възможно никоя група няма да има достатъчно хора, за да свърши някога
да свърши добра работа, оставяйки всички ни с множество лоши Linux настолни
опции (отново) вместо един единен, всички са подредени за
подобряване. Досега се надявах, че начинът, по който Nokia подобрява
лиценза за Qt, може най-накрая да обмисли как да премахнем
наличието на Qt+GNOME. Това, че вместо това Linux все още се развива
проект на върха на микса и го нарича Unity of all things, е
ужасна шега.
Но аз говорех за бази данни... едно
от интересните неща за PostgreSQL е колко разклонения
генерира. Щедрият BSD лиценз доведе до множество
комерсиални разклонения със затворен код; Работех във фирма, която направи
една. Netezza беше първата от тях, която в крайна сметка се превърна в сериозна
комерсиална продукция. И базата данни Greenplum наскоро беше закупена от EMC, това е много успешен продукт. Това, което не
не се е случило, е някой от разклоненията с отворен код, които се превръщат в жизнеспособни заместители
на основната дистрибуция. Освен ако не разполагате с такива големи
ресурси, които голяма компания може да използва за инженеринг, е
по-лесно да накарате общността да приеме вашите идеи, отколкото да опитате
и да извършите независимо изпълнение от тях. Направо общност
PostgreSQL продължава да бъде правилният избор.
Общността на PostgreSQL спори много,
и е враждебна към много неща, които хората искат; дори имаме
списък, който не искаме да правим.
Това са в по-голямата си част неща, които просто не са технически
осъществими за изграждане без недостатъци, които не винаги са очевидни за
тези, които ги искат. Ако потребител аргументира защо промяната би
довела до по-добър потребителски интерфейс на нещо в базата данни и
няма никакви технически възражения защо това ще причини проблем,
тази промяна се взема предвид. Това, което никога не съм виждал в общността, е
който от разработчиците се изправят срещу единодушно, недвусмислено потребителско
предпочитание – където тази опция може да бъде предоставена без
недостатъци – просто защото те не го харесвам така. Ако сте
разработчик на проект с отворен код, който се лута до мястото, където високомерието
надмина смирението толкова зле, не се учудвайте, ако потребителите ви ще
да се разгневят достатъчно, за да се разклонят. И някой от тези дни може да откриете, че
разклоненията или повторните реализации, които обръщат внимание на това, което хората
истина искат, ще ви изместят.
