Grupa docelowa Ansel

Ponieważ poznanie odbiorców jest pierwszym krokiem projektowania, warto ich zdefiniować.

Ankieta Darktable  z 2020 roku ujawniła nietypowe odchylenie wśród użytkowników, faworyzujące dobrze wykształconych mężczyzn z zapleczem technicznym i naukowym oraz o wyższych umiejętnościach programistycznych niż przeciętna populacja. Jest to problematyczne, ponieważ nie pokrywa się to z socjologią fotografów w ogóle (zarówno pod względem umiejętności komputerowych, jak i proporcji mężczyzn do kobiet), lecz stanowi przefiltrowany podzbiór tej grupy społecznej.

Ansel oczekuje od swoich użytkowników posiadania

• średniozaawansowanej lub zaawansowanej wiedzy z zakresu teorii koloru (jasność postrzegana vs. jasność vs. luminancja, chroma vs. nasycenie, modele addytywne, delta E itd.), ¹
• średniozaawansowanej lub zaawansowanej wiedzy o aparatach (ISO, zakres dynamiki, korekta ekspozycji itd.),²
• średniozaawansowanej lub zaawansowanej wiedzy o oświetleniu scenicznym (iluminant, CRI, cienie rzucane, prawo odwrotności kwadratu odległości w oświetleniu itd.)

W związku z tym Ansel nie jest skierowany do początkujących i będzie bardziej (pod względem fotograficznym) techniczny niż zamknięci konkurenci, których zaawansowanych użytkowników frustruje ich obsługa. To zwiększone zakorzenienie techniczne ma na celu odblokowanie dokładniejszej i bardziej precyzyjnej kontroli nad manipulacjami obrazu (zwłaszcza koloru); w żadnym razie nie jest to technika dla samej techniki.

Ansel oczekuje jednak użytkowników przeciętnie obeznanych z komputerem, bez umiejętności skryptowania czy programowania. W związku z tym zadania realizowane przez interfejs wiersza poleceń lub bezpośrednią edycję plików konfiguracyjnych powinny pozostać czymś wyjątkowym, alternatywą wobec metod z poziomu GUI, i ograniczonym do zadań zaawansowanych.

Ansel nie ma na celu konkurowania z komercyjnymi alternatywami, takimi jak Adobe Lightroom czy Capture One. Przede wszystkim konkurowanie z wartymi miliony dolarów firmami przy obecnych zasobach byłoby bezcelowe. Ale ponadto dokonały one wyborów technicznych, by być atrakcyjne dla mas, tylko po to, aby zapewnić sobie duży udział w rynku: są one w rzeczywistości dość ograniczone, gdy wiesz, co robisz. I to jest w porządku, ponieważ użytkownicy, którzy są najbardziej skłonni zapłacić wysoką cenę, tego nie wiedzą.

Wartości

Użytkownicy nie powinni być zmuszeni do czytania instrukcji

(Obowiązują pewne ograniczenia)

Przetwarzanie obrazu jest trudne. Wykorzystuje pojęcia z optyki i „nauki" o kolorze. Niezależnie od tego, czy fotografujesz cyfrowo, czy analogowo, iluminant, zakres dynamiki, gamut i chroma wpłyną na Twój proces w sposób, którego być może nie przewidziałeś, i dobrym pomysłem może być zrozumienie, co one oznaczają i gdzie wchodzą w grę. Cyfra ma swój własny zestaw problemów, od przestrzeni barwnych i zarządzania kolorami po komponowanie z kanałem alfa. Niewiele możemy tu zrobić, poza dostarczeniem dokumentacji: potrzebujesz tych umiejętności. Ale to są przynajmniej podstawy wszystkiego, co robimy, niezależnie od użytego oprogramowania.

Zarządzanie plikami i poruszanie się w interfejsie graficznym to czynności, które użytkownicy komputerów wykonują od dziesięcioleci, korzystając z powszechnie znanych paradygmatów, które zbiegły się do dość ujednoliconej semantyki. Użytkownicy nie powinni być zmuszeni do czytania instrukcji, aby odkryć, dlaczego przewijanie myszą jest zablokowane, na przykład, albo jak zwiększyć krycie maski, czy nawet co oznaczają wszystkie te niedorzeczne, ręcznie rysowane ikony.

Użytkownicy nie powinni być zmuszeni do czytania instrukcji, ponieważ i tak tego nie zrobią. Zamiast tego będą nękać deweloperów pytaniami, na które gdzieś w obszernej dokumentacji już udzielono odpowiedzi — dokumentacji zbyt długiej do przeczytania, bo musi tłumaczyć, dlaczego zbyt wiele standardowych rzeczy nie jest obsługiwanych w standardowy sposób.

Uznając to, zły projekt marnuje czas zarówno użytkowników, jak i deweloperów, i najwyższy czas ograniczyć te straty, dla dobra wszystkich.

Otóż próba podążania za typowymi paradygmatami desktopowego GUI jest w porządku w przypadku wszechobecnych zadań, dopóki nie wejdziesz w podstawowe specyficzne cechy Twojej konkretnej aplikacji. Tam próba ślepego podążania za paradygmatami narzuconymi przez wiodące w branży oprogramowanie, działające na innych założeniach i w innym kontekście, jest po prostu kultem cargo , który będzie przeszkadzał w rzeczywistej produktywności. Nie jest to przyzwolenie na głupie odtwarzanie istniejącego projektu bez zrozumienia założeń, na których jest on oparty.

Upraszczanie to nie ułatwianie

Skrzypce to prosty instrument: 4 struny, trochę drewna i konstrukcja, która niemal się nie zmieniła od XVIII wieku. Fortepian to instrument skomplikowany, który doczekał się niedawnych innowacji: 88 klawiszy, 230 strun, żeliwna rama na wierzchu drewnianej płyty, wełniany filc wszędzie, 3 pedały. Otóż Twoje pierwsze lata nauki gry na fortepianie będą znacznie łatwiejsze niż pierwsza dekada nauki gry na skrzypcach. Dopóki nie dojdziesz do momentu, w którym fugi Bacha mają 4 głosy do zagrania jednocześnie, albo etiudy Chopina każą Ci grać akordy w zakresie 3 oktaw przy 120 BPM, a wciąż masz tylko 2 ręce i jedną klawiaturę, ale nieważne…

Rzecz w tym: pozorna prostota Twojego instrumentu (czyli liczba organów, z którymi się wchodzi w interakcję) ma niewiele wspólnego z rzeczywistą łatwością gry na nim. A oprogramowanie do edycji zdjęć jest bardzo podobne do instrumentu muzycznego: pozwala technicznie manipulować „materialnym" medium w celach artystycznych. Nacisk na dychotomię między używaniem techniki do osiągnięcia sztuki na głupim medium, które nieustannie staje na drodze Twoim zamiarom i możliwościom.

Tak więc upraszczanie bez ogłupiania ma na celu zmniejszenie liczby kroków potrzebnych do wykonania z góry określonego zadania. Albo głębokości bałaganu wprawiającego Cię w przeciążenie poznawcze podczas owego zadania. Nie ma to nic wspólnego z umożliwieniem Ci opuszczania lekcji i używania instrumentu bez uprzedniej wiedzy.

Umożliwienie użytkownikom korzystania z instrumentu bez wiedzy ani treningu to zamiana narzędzia w zabawkę: usuń wszystko, co potencjalnie szkodliwe lub przerażające, zredukuj funkcje do absolutnego minimum i postaw zabawę ponad zdolność rozwiązywania problemów. Robisz tak, gdy chcesz sprzedać wiele kopii swojego oprogramowania, powiększając udziały w rynku o wszystkich chętnych, by pozować na fotografa bez najmniejszego pojęcia o tym, co robią. Później zmusisz ich do przechowywania swoich zdjęć w chmurze, tylko po to, by je pobrać i wytrenować swoje AI-owe automagiczne czary, i sprzedać im edycje z puszki pod etykietą „profesjonalne rezultaty".

Zdolność uczenia się jest ważniejsza niż przyjazność dla początkujących

Nazwy techniczne, takie jak nazwy metod czy algorytmów, są zachowywane w takiej postaci, w jakiej publikują je ich autorzy w literaturze technicznej i naukowej. Pozwala to skorzystać z dowolnej wyszukiwarki, aby dowiedzieć się więcej o tych metodach, na przykład o ich mocnych i słabych stronach, albo o innych dostępnych, konkurencyjnych metodach. Pozwala to również uczyć się trików edycji obrazu z książek napisanych o innym oprogramowaniu, pod warunkiem że to oprogramowanie przestrzega tej samej zasady używania oryginalnych nazw.

Jest to niepopularny wybór projektowy, ponieważ Adobe Lightroom celowo zdecydował się ukrywać nazwy techniczne, blokując tym samym użytkownikom głębsze zrozumienie… ale też uniemożliwiając wszelkie próby inżynierii wstecznej. Zaawansowani użytkownicy Lightrooma często próbują wywnioskować, co tak naprawdę robią kontrolki i ustawienia — często błędnie, na podstawie wizualnej informacji zwrotnej i ograniczonej wiedzy teoretycznej, którą posiadają — tylko po to, by nauczać, głosić i rozpowszechniać błędną wiedzę.

Wierzę, że utrzymywanie otwartych drzwi do pogłębiania rozumienia przez użytkownika zagadnień przetwarzania obrazu to cnotliwe i wzmacniające koło, mimo że ma to swoją poznawczą cenę. Dlatego techniki nie będą ukrywane ani przemianowywane w GUI po to tylko, by być mniej przerażające.