Usabilità del social coding

Usabilità del social coding

Ci sono scelte di design a monte di piattaforme anche molto conosciute che sembrano ignorare la regola del "Don't make me think" individuata da Steve Krug. Sembra quasi che si faccia a gara per scegliere il percorso più lungo e contorto per giungere alla soluzione finale. È come se per aprire una lattina di Coca-Cola vi costringessero ad usare un bisturi, adducendo come motivo inesplicabili ed enigmatici protocolli di sicurezza. Le piattaforme di social coding sono un ottimo esempio di questa pessima pratica di usabilità. Per esempio, io ho scelto Bitbucket non per motivi di sviluppo, ma semplicemente perchè non sono riuscito ad usare GitHub. Come mai? La storia ha dell'incredibile.

In che anno siamo? 2011, se il nostro calendario non sbaglia. In che anno si cominciarono ad usare i primi terminali? Anni '60 del secolo scorso. Sono passati cinquant'anni ma il terminale non è ancora scomparso del tutto, anzi sembra acquistare nuova forza per merito di qualche mente illuminata che si diverte ancora ad usarlo.

Cos'ha il terminale di sbagliato? Una sola cosa: è del tutto inumano, almeno se vogliamo usare il termine "umano" così come lo intendeva Jef Raskin. Il terminale ti costringe a pensare dieci volte prima di digitare qualsiasi cosa: non c'è un modo per tornare indietro quando si è premuto Invio, e anche quando è possibile farlo bisogna ricordarsi a memoria la combinazione di tasti giusta per fare quello che in una GUI si fa con un clic del mouse.

Se avete provato ad installare un programma Linux usando una tarball sapete bene che quando digitate make comincia l'angoscioso dubbio: avrò installato tutte le dipendenze richieste dal programma? Molto spesso sul terminale appare una sequenza infinita di righe che scorrono così velocemente da lasciarvi senza fiato. E alla fine? Errore: nulla di fatto. Ricominciare da capo.

Ora, col social coding si passa quasi sempre per il terminale. Non c'è altro modo, almeno quando si crea la prima repository in assoluto. GitHub ha anche bisogno di una chiave pubblica per accedere al sistema. Una chiave GPG.

Non capisco: lo fate per preservare l'originalità del mio codice? Per evitare il plagio? Per motivi di sicurezza? Nessuna spiegazione ed una sola certezza: devi avere una chiave pubblica o non puoi usare la piattaforma. Penso: "Sicuramente è per un motivo di sicurezza". Ma poi ci ripenso e mi chiedo: "Qual'è questo motivo"?. C'è. Fidati.

Dopo essersi registrati bisogna scaricare il framework GitHub e installarlo. Nel mio caso devo installare un package per Mac. Noi utenti Mac in genere odiamo i package, perchè vanno ad installarti i file nelle directory Unix, che non sono accessibili se non con la digitazione (bel termine!) di un comando da Terminale (di nuovo il terminale). E per rimuovere i file è un problema, perchè non sai dove vanno a finire. Per fortuna questo framework ha anche uno script per la disinstallazione. Ottimo.

Prima di digitare i comandi per la creazione delle repository (una locale, una remota), devo impostare una chiave pubblica. E per farlo devo comunque accedere alle directory Unix per trovare quella in cui risiede il file da editare. Le directory sono nascoste, all'epoca non conoscevo il comando da Terminale per mostrarle, quindi ho dovuto usare un editor di testo per aprire il file.

Altrettanto ovviamente ho dovuto loggarmi come utente root per modificare il file. Lo modifico, lo salvo, riapro il terminale e comincio a digitare i comandi di GitHub. Errore. Vedi Help. Correggo l'errore. Errore. Rivedi Help. Ricorreggo l'errore. Errore. Ririvedi Help. Errore corretto? Piano: altro errore! Riririvedi Help. Anzi, l'Help non aveva più argomenti, quindi torno sul sito ma mi dicono di vedere l'Help. Problema con la chiave pubblica? Cerco in giro ma non trovo nulla.

Provo allora Mercurial e Bitbucket. Sempre il caro vecchio terminale, ma almeno stavolta non ho dovuto ririririvedere l'Help e correggere. E per il momento funziona.

Torna su