Un buon approccio per programmare bene

Un buon approccio per programmare bene

Questo articolo nasce da un un commento che stavo per scrivere nel blog di un programmatore per sottolineare l'importanza di realizzare una buona interfaccia grafica fin dalle prime fasi della programmazione.

Visto che il commento conteneva qualche spunto interessante anche per i lettori di finex.org, ho deciso di riscriverlo ed estenderlo tramite questo breve inserimento.

L'articolo a cui stavo rispondendo tratta di un nuovo meccanismo di autenticazione implementato in KDE ed illustra lo stato attuale del sistema con un paio di video.

Ciò che mi ha motivato nel lasciare un commento non è però legato all'authentication framework, bensì ad un dettaglio che ho notato nell'interfaccia realizzata dall'autore.

Nel widget explorer (il pannello di Plasma/KDE che serve per aggiungere widget nel desktop) è stato aggiunto un pulsante a due stati per filtrare l'elenco dei widget. Questo pulsante ha una etichetta che cambia in base allo stato: quando il pulsante non è schiacciato viene visualizzata l'etichetta "Show scripted plasmoids only", mentre quando viene premuto la scritta cambia in "Show all plasmoids".

Il problema è che questo tipo di interfaccia, pulsante a due stati con etichetta che si modifica in base allo stato, è considerato come poco usabile.

L'utente infatti può facilmente chiedersi: «L'etichetta indica lo stato attuale o l'azione che verrà eseguita premendo il pulsante?».

Una situazione molto simile accade anche con i checkbox che cambiano etichetta in base allo stato.

Solitamente la soluzione più comune (implementata anche nell'interfaccia di KDE e suggerita dalle linee guida) è di non modificare l'etichetta che, come stringa, dovrà contenere la descrizione dell'effetto generato attivando il pulsante.

Un semplice consiglio per programmare

Mi permetto quindi di indicare un semplice consiglio ai programmatori: quando si comincia un qualunque progetto, come anche quando si crea un prototipo, è sempre buona regola pensare già da subito all'utente finale e quindi realizzare una interfaccia usabile. Non conviene affatto doverla ridisegnare in un secondo momento.

Inoltre in questo modo si evita di portarsi dietro eventuali "errori", o cattive abitudini, nelle successive implementazioni.

In generale, lo stesso consiglio si può estendere ad ogni altro aspetto della progettazione e realizzazione di un software e si riconduce al buon vecchio detto: «chi ben comincia è a metà dell'opera».

Il mio libro di informatica non fa che ripeterlo xD: "il 60%% del tempo si perde per progettare efficientemente il programma (GUI inclusa)"