Poiché conoscere il pubblico è il primo passo della progettazione, è utile definirlo.
Il sondaggio su Darktable del 2020 ha mostrato una distorsione anomala tra gli utenti, a favore di uomini con un alto livello di istruzione, provenienti da un contesto tecnico e scientifico e con competenze di programmazione superiori a quelle della popolazione media. Questo è problematico perché non coincide con la sociologia dei fotografi in generale (sia per quanto riguarda le competenze informatiche sia per il rapporto uomini/donne), ma è un sottoinsieme filtrato di quel gruppo sociale.
Ansel si aspetta che i suoi utenti abbiano
- una conoscenza da intermedia ad avanzata della teoria del colore (brightness vs. lightness vs. luminanza, chroma vs. saturazione, modelli additivi, delta E, ecc.), 1
- una conoscenza da intermedia ad avanzata delle fotocamere (ISO, gamma dinamica, compensazione dell’esposizione, ecc.),2
- una conoscenza da intermedia ad avanzata dell’illuminazione di scena (illuminante, CRI, ombre proiettate, legge dell’inverso del quadrato dell’illuminazione, ecc.)
Di conseguenza, Ansel non si rivolge ai principianti e sarà più tecnico (dal punto di vista fotografico) rispetto ai concorrenti proprietari, che risultano frustranti da usare per gli utenti avanzati. Questo maggiore radicamento tecnico ha lo scopo di sbloccare un controllo più preciso e dettagliato sulle manipolazioni dell’immagine (specialmente del colore); non è in alcun modo tecnica fine a se stessa.
Tuttavia, Ansel si aspetta utenti con competenze informatiche medie, senza capacità di scripting o di programmazione. Di conseguenza, i compiti svolti tramite l’interfaccia a riga di comando o la modifica diretta dei file di configurazione dovrebbero restare eccezionali, alternativi ai metodi tramite GUI e limitati a compiti avanzati.
Ansel non mira a competere con alternative commerciali come Adobe Lightroom o Capture One. Prima di tutto, sarebbe inutile competere con aziende multimilionarie disponendo delle risorse attuali. Ma poi, queste hanno fatto scelte tecniche per risultare attraenti alle masse, al solo scopo di garantirsi un’ampia quota di mercato: in realtà sono piuttosto limitate, quando sai quello che stai facendo. Il che va bene, perché gli utenti più disposti a pagare prezzi elevati non lo sanno.
Valori
Gli utenti non dovrebbero essere costretti a leggere il manuale
(Si applicano alcune restrizioni)
L’elaborazione delle immagini è difficile. Utilizza nozioni di ottica e di “scienza” del colore. Non importa se scatti in digitale o in analogico: illuminante, gamma dinamica, gamut e chroma influenzeranno il tuo processo, in modi che potresti non aver previsto, e potrebbe essere una buona idea capire cosa significano e dove entrano in gioco. Il digitale ha la sua serie di problemi, dagli spazi colore e la gestione del colore al compositing alpha. Non possiamo farci molto qui, se non fornire documentazione: le competenze le devi avere tu. Ma questo è, quantomeno, il nucleo delle basi di tutto ciò che facciamo, indipendentemente dal software usato.
Gestire i file e navigare in un’interfaccia grafica sono cose che gli utenti di computer fanno da decenni, usando paradigmi ben noti che sono convergiti in una semantica piuttosto unificata. Gli utenti non dovrebbero essere costretti a leggere un manuale per scoprire, ad esempio, perché lo scorrimento del mouse è bloccato, o come aumentare l’opacità di una maschera, o persino cosa significhino tutte quelle sciocche icone disegnate su misura.
Gli utenti non dovrebbero essere costretti a leggere il manuale perché, tanto, non lo faranno. Piuttosto, assilleranno gli sviluppatori con domande a cui è già stata data risposta da qualche parte nella vasta documentazione, che è troppo lunga da leggere perché deve spiegare perché troppe cose standard non sono gestite in modo standard.
Riconosciuto ciò, una cattiva progettazione fa perdere tempo sia agli utenti sia agli sviluppatori, ed è ora di tagliare le perdite, per il bene di tutti.
Ora, cercare di seguire i tipici paradigmi delle GUI desktop va bene per i compiti onnipresenti, finché non si arriva alle specificità fondamentali della tua particolare applicazione. Lì, cercare di seguire ciecamente i paradigmi imposti da software leader del settore che operano su presupposti diversi e in un contesto diverso è semplicemente un culto del cargo che ostacolerà la produttività effettiva. Questa non è una licenza per riprodurre stupidamente il design esistente senza comprendere i presupposti su cui si fonda.
Semplificare non significa rendere le cose più facili
Un violino è uno strumento semplice: 4 corde, un po’ di legno e un design che è cambiato appena dal XVIII secolo. Un pianoforte è uno strumento complicato e ha ricevuto innovazioni recenti: 88 tasti, 230 corde, un telaio in ghisa sopra una tavola di legno, feltro di lana ovunque, 3 pedali. Ebbene, i tuoi primi anni di apprendimento del pianoforte saranno molto più facili del tuo primo decennio di apprendimento del violino. Finché non arrivi al punto in cui le fughe di Bach hanno 4 voci da suonare contemporaneamente, o gli studi di Chopin ti fanno suonare accordi su 3 ottave a 120 BPM, e hai ancora solo 2 mani e una tastiera, ma insomma…
Il punto è questo: l’apparente semplicità del tuo strumento (ovvero il numero di organi con cui interagire) ha poco a che fare con la reale facilità di suonarlo. E un software di fotoritocco è molto simile a uno strumento musicale: ti permette di manipolare tecnicamente un mezzo “materiale” per scopi artistici. Enfasi sulla dicotomia tra l’uso della tecnica per ottenere arte su un mezzo stupido che si mette costantemente di traverso rispetto alle tue intenzioni e capacità.
Quindi, semplificare senza rincretinire mira a ridurre il numero di passaggi necessari per portare a termine un compito predeterminato. O la profondità del disordine che ti mette in sovraccarico cognitivo durante tale compito. Non ha nulla a che fare con il permetterti di saltare le lezioni e usare lo strumento senza conoscenze pregresse.
Permettere agli utenti di usare lo strumento senza conoscenza né addestramento significa trasformare uno strumento in un giocattolo: rimuovi tutto ciò che è potenzialmente dannoso o spaventoso, riduci le funzioni al minimo indispensabile e metti la giocosità al di sopra della capacità di risolvere problemi. Lo fai quando vuoi vendere molte copie del tuo software, ampliando le tue quote di mercato a chiunque sia disposto a spacciarsi per fotografo senza avere la minima idea di cosa stia facendo. In seguito, li costringerai a ospitare le loro foto sul cloud, solo per recuperarle e addestrare la tua IA automagica, e vendere loro elaborazioni in scatola sotto l’etichetta “risultati professionali”.
La capacità di imparare è più importante dell’essere adatto ai principianti
I nomi tecnici, come quelli dei metodi o degli algoritmi, sono mantenuti così come sono pubblicati dai loro autori nella letteratura tecnica e scientifica. Questo permette di usare qualsiasi motore di ricerca per approfondire tali metodi, ad esempio i loro punti di forza e di debolezza, o gli altri metodi concorrenti disponibili. Permette inoltre di imparare trucchi di fotoritocco da libri scritti su altri software, a condizione che quei software rispettino la stessa regola di usare i nomi originali.
Questa è una scelta di design impopolare, poiché Adobe Lightroom ha deliberatamente scelto di nascondere i nomi tecnici, precludendo così agli utenti una comprensione più profonda… ma impedendo anche qualsiasi tentativo di reverse-engineering. Gli utenti avanzati di Lightroom cercheranno spesso di dedurre cosa facciano effettivamente i controlli e le impostazioni, spesso in modo errato a partire dal riscontro visivo e dalle limitate conoscenze teoriche che possiedono, solo per insegnare, predicare e diffondere conoscenze sbagliate.
Credo che tenere aperte le porte per approfondire la comprensione da parte dell’utente delle questioni di elaborazione delle immagini sia un circolo virtuoso e responsabilizzante, anche se ha un prezzo cognitivo da pagare. Pertanto, la tecnica non sarà nascosta o rinominata nella GUI al solo scopo di risultare meno spaventosa.
Translated from English by : Claude. In case of conflict, inconsistency or error, the English version shall prevail.
See Chris Brejon’s website for the scope of this knowledge, ↩︎
See DxO Mark website for the scope of this knowledge, ↩︎