Newsgroup: it.comp.lang.delphi
Titolo: Estetica dei programmi

Salve a tutti!
Fin da quando ho iniziato a programmare, ho sempre avuto un problema: quello
di riuscire
a presentare all'utente un'interfaccia gradevole e intuitiva. Sono uno di
quei programmatori
che si basano molto più sul codice che sull'impatto grafico anche se
probabilmente quello
che alla fine incide di più sull'opinione degli utenti è proprio
quest'ultimo.
Per questo chiedo a tutti i partecipanti del NG di indicare i propri
trucchetti (e magari le
VCL preferite) per rendere un programma bello ed accattivante. Credo che il
problema
di dover migliorare la GUI dei propri programmi non sia solo mio quindi
immagino che
il post possa interessare a molti.. o almeno spero ^^
-- 
Ciao,
Giulio "RedXIII"

 VCL preferite) per rendere un programma bello ed accattivante.
In effetti l'interfaccia è un aspetto dei programmi che quasi tutti i
programmatori "old-style" trascurano; penso che non lo facciano per
incapacità (non che fare una bella interfaccia sia facile, anzi), ma perché
sono le software house per cui lavorano che spesso non danno la giusta
importanza (e quindi il giusto budget) per questa parte dello sviluppo.
Io, come te, sono convinto che una buona interfaccia sia una cosa basilare
per un programma; ovviamente non è una condizione sufficiente a fare un buon
programma: è necessario che il programma stesso sia scritto bene, altrimenti
verrà usato una volta sola per vedere quant'è bello e poi stop.
Tornando al tuo post, è difficile definire delle regole base per fare una
buona interfaccia, anche perché dipende da tantissimi fattori: il genere del
programma, il target di utenza...
Io, come regola, cerco sempre di utilizzare i componenti standard di win,
perché di solito un utente ha già familiarità con essi e, in generale, prima
di sbizzarrirmi con colori/bevel/shapes et similia guardo sempre se esiste
qualcosa del genere in win e cerco di imitarla.
Altre regole che io seguo sempre (e che sono ovviamente sindacabili, ma fino
a un certo punto):
- Win 3.1 è morto. Tutte quelle belle cosine che c'erano sarebbe ora di
fucilarle, ossia: font in grassetto, pulsanti talmente 3d che uscivano dallo
schermo, scritte talmente 3d che anche un cieco, toccando lo schermo,
sarebbe riuscito a leggere, panel talmente incassati che quando spostavi il
mouse sul bordo non riusciva più a risalire...
- non usare controlli complicati dove non servono: ad esempio, TMainMenu e
Toolbar in un programma che fa 4 cose in croce
- non usare font non standard e di dimensioni/colori strambi: di solito uso
Tahoma 8px; qualche volta uso i colori per evidenziare, ma sempre che si
distinguano bene dallo sfondo, tipo Navy o Maroon, al più uso i colori di
sistema. clYellow e clLime per intenderci sono da ammazzare :)
- tenere conto che la maggior parte degli utenti non usa la 1600x1200 :)
- non lesinare le form, se servono; certo, è più comodo mettere tutto su
un'unica form gigantesca con 8000 edit, ma spesso il programma può essere
ugualmente funzionale (se non di più) se viene spezzettato su più form
- fare il programma in modo che possa essere utilizzabile *interamente* da
tastiera
- non usare i controlli per una funzione per cui non sono stati pensati: se
l'utente vede una label dove dovrebbe esserci una edit, al 99% ne vorrà
modificare il testo :)
- *non* usare i componenti db-aware. So che solleverò un polverone, ma io
odio i db-aware, in primis perché sono brutti, in secondis perché sono poco
funzionali (molti mancano di proprietà/metodi che ci si aspetterebbe di
avere), in terzis spesso danno all'utente una libertà che non si meritano ;)
In pratica, preferisco una bella ListView popolata a mano che una DBGrid.
- usare i thread; non è facile, ma poter usare un'applicazione mentre fa
un'elaborazione è una comodità non da poco
- progressbar a go-go! Sapere a che punto è un'elaborazione è comodissimo.
Ovviamente ho messo al bando TGauge e altri componenti di terze parti perché
IMHO non aggiungono molto alla progressbar e, obbiettivamente, la
ProgressBar è tutto ciò che un utente ha bisogno
- bitmap rigorosamente a 256 colori, se non di più: siamo nel 2003 ormai...
- le treeview spesso sono usate a sproposito: sono un controllo decisamente
ostico per un utente base e sono anche difficilotte da gestire. Se invece
sono "statiche", ossia non modificabili dall'utente, sono un'*ottima*
alternativa a 20000 tab (per esempio in word dovrebbero mettere una treeview
nelle opzioni...)
- *spaziare* i componenti: non c'è niente di più orrido che vedere tutto
attaccato in una form
- fare in modo che il ridimensionamento di una form non sia una cosa
terribile per il programma: in questo i Borland-men ci sono venuti parecchio
incontro introducendo gli anchors... ricordo benissimo gli 8000
matrioska-Panel con le combinazioni più assurde di Align che bisognava fare
per rendere un'app ridimensionabile *e* "ariosa" allo stesso tempo...
Ce ne sarebbero altre, ma adesso non mi vengono in mente. Magari poi...
--
Jax
====
"Si tratta di una vera rivoluzione informatica in quanto la struttura
passera' dagli attuali bit ai trit, cosi' i 32 e 64 bit che
caratterizzano i processori binari di oggi saranno sostituiti con 81
trit (ovvero 4 tryte)."


Open Delphi Manual (
http://groups.yahoo.com/group/delphi_open_manual/
)

 di dover migliorare la GUI dei propri programmi non sia solo mio quindi
Anche a me interessa poco l'aspetto grafico e "colorato" delle applicazioni, 
però reputo fondamentale che il programma non invogli l'utente ad andarsene 
e che sia il più funzionale possibile.
Provate a pensarci: quante volte avete installato un programma 
freeware/shareware e l'avete disinstallato dopo 10 minuti pensando "mamma 
mia quant'è scomodo"? Magari aveva tutte le funzionalità che vi servivano, 
ma il fatto di essere scomodo ve l'ha fatto scartare.
A me succede spesso per cui, per evitare questi problemi, sto leggendo un pò 
di testi sulla progettazione della GUI. Al momento sono a metà di Gui 
Blooper, di Jeff Gordon, testo che consiglio caldamente a tutti
-- 
Lis
Mercatino: 
http://snurl.com/sito_lis
Aiuta la ricerca contro il cancro: 
http://snurl.com/ida_team

 VCL preferite) per rendere un programma bello ed accattivante. [cut]
In poche parole tu vorresti che si parlasse di *accessibilità* e *usabilità*
legati al software.
Per il primo aspetto, cioè l'accessibilità:
. il software deve essere fruibile tramite mouse e tastiera. Con entrambe le
periferiche si deve poter fare tutto. L'una non esclude l'altra. Una
funzione fattibile con il mouse deve potersi fare anche da tastiera, e
viceversa.
. Gli elementi attivi di un form devono potersi raggiungere sia col mouse
sia con la tastiera.
. Gli elementi passivi, puramente estetici, falli come più ti pare e
piace... limitatamente al gusto dei potenziali utenti. Se il tuo talento
grafico coincide con quello degli altri, tanto di guadagnato. C'è da dire
che i programmi migliori non sono sempre quelli con più colori, più grafici,
più...
. Il software migliore è quello che mette meno azioni fra l'utente e il
servizio che quest'ultimo vuole ottenere.
E qui stiamo già parlando di Usabilità.
Cos'è che l'utente vuole dal tuo software? Bearsi dei supergrafici che gli
hai stampigliato sopra? Leggersi il manuale, scritto benissimo,
voluminosissimo, pienissimo di informazioni utili? Vuole deliziarsi ad
aprire mille form e formicine per scoprire i segreti del tuo prodotto? No.
Scordatelo. L'utente abbandonerà il tuo software dopo 5 minuti.
L'utente vuole ottenere il servizio per cui ha comprato il tuo software. Lo
vuole subito. Vuole che tutto sia il più intuibile possibile. Vuole che si
perda meno tempo possibile a leggere la documentazione che tu fornisci.
Vuole usare il tuo software senza troppi problemi.
Come ho scritto tante volte in altre liste e in altri gruppi:
Accessibilità e usabilità vanno a braccetto... ma non è detto che ci vadano
sempre. Un software può essere assolutamente accessibile, ma perfettamente
inusabile.
Accessibilità è tecnica... la tua tecnica. Usabilità è pratica... la tua
esperienza acquisita dal feedback dei tuoi utenti.
Ciao
Giuseppe

 ha scritto nel messaggio
news:GOJHb.19181$_P.8...@news4.tin.it...


 megaform :-)
Anche per te vale il mio consiglio: se i tabsheet diventano tanti, considera
l'uso di una treeview, che volendo vedere sono anche più intuitivi (due
sottonodi per descrivere due sezioni dello stesso gruppo sono molto meglio
che due tab *dentro* ad un tab).
Ah, quota, per favore.
http://lists.firenze.linux.it/pipermail/primipassi/2002-November/002450.html
--
Jax
====
Cerca di ottenere sempre ciò che ami o dovrai accontentarti di amare
ciò che ottieni.

 che due tab *dentro* ad un tab).
Esatto, e cerca di evitare il più possibile di avere dei tab multilinea. Se
vedi che i tab vanno su più linee...riprogetta l'interfaccia perchè c'è
qualcosa che non va ;)


 ha scritto nel messaggio
news:PARHb.16487$VW.8...@news3.tin.it...


 Ce ne sarebbero altre, ma adesso non mi vengono in mente. Magari poi...
Io insisto nel dire che la lettura di un libro a tema sia molto utile e
faccia aprire davvero gli occhi su certi aspetti che sembrano poco
importanti ma che, sommati, fanno la differenza tra usare o non usare un
programma.


> i programmi migliori non sono sempre quelli con più colori, più grafici,
più...
dipende dal tipo di software: se parliamo di un player multimediale, le
skin, colori, animazioni nei pulsanti, ecc. sono ben gradite; se parliamo di
un gestionale, piu' semplice, lineare, intuitivo e guidato e' (per "guidato"
intendo che un pulsante deve avere una funzione specifica per una form o
sezione specifica, quindi alla larga le toolbar general-purpose con decine
di pulsantini minuscoli che si abilitano/disabilitano a seconda della form
che e' aperta, e robaccia del genere), e meglio e'.
Ciao, Sandro

 Molto interessante Jax! Grazie dei consigli ^^
Figurati. Ma invece di ringraziarmi, impara a quotare, dai :)
http://lists.firenze.linux.it/pipermail/primipassi/2002-November/002450.html
Se usi Outlook Express, *devi* usare OE-QuoteFix.
--
Jax
====
Se il proprio treno è in ritardo, la coincidenza partirà in perfetto
orario .

Per quel che mi riguarda:
1) cercare di evitare componenti di terze parti a meno che non sia
strettamente necessario.
Ad esempio, ho usato in passato le quantumgrid e le trovo ottime anche xche
si risparmia un bel po di tempo.
Ad esempio, raggruppare i dati di una griglia in base al valore di una
colonna non lo fai in 5 minuti....
2) cercare di rispettare gli standard della maggior parte dei programmi
windows.
All'utente non fa piacere scoprire che il 99% dei sow windows hanno il
comando di stampa di quanto c'è a video nel menu file mentre io, furbo, l'ho
messo in un altro posto...
3) Evitare i pagecontrol multilinea e suddividere logicamente le
informazioni sulle varie pagine
Io, ad esempio, uso un tabsheet etichettato "dati di sistema" e dentro ci
metto info che servono a me ma non all'utente
4) accesso alle varie funzioni via mouse, tastiera, maimneu e, dove serve,
popup menu associati ai controlli
5) usare i colori della mappatura di windows e non direttamente i colori
offerti da windows
6) niente dblookupcombobox
7) accertarsi che ogni controllo abbia un hint significativo.
Che stress, in alcuni gestionali, andare su un dato e vedere un hint
"nessuna informazione disponibile...
8) a seguito di varie ricerche e di un po di studio di cio che si trova in
c#builder e di tiOpf, mi sono imposto un drastico cambiamento di rotta
riguardo i componenti dbaware di cui *ero* uno sfegatato sostenitore, ma che
dai prossimi progetti in poi conto di non usare piu'.
Bye
A

 "nessuna informazione disponibile...
Almeno lì vuol dire che c'è del codice sotto... è ancora più desolante
vedere certi hint *uguali* alla descrizione del pulsante...
--
Jax
====
Se dovessi scegliere tra tradire il mio paese e tradire il mio amico,
spero di avere il fegato di tradire il mio paese. (Edward Morgan
Forster)

 dipende dal tipo di software: se parliamo di un player[cut]
Certo. Intendevo programmi usati per lavoro, non per svago. Vedi anche i
videogiochi, piů ce n'č, meglio č.
Ciao
Giuseppe

 dai prossimi progetti in poi conto di non usare piu'.
Perché tanto accanimento contro i DbAware?
-- 
_________________________________________
Edmondo Di Tucci snar...@Ttin.it
guarda i miei lavori su: 
www.powernetsi.it/edmondo

Non č un accanimento contro i dbaware.
La tendenda ora č avere delle classi che fanno da interfaccia tra il db e la
applicazione.
Il modello eco, usato in c#builder lavora in questo modo.
Crei delle classi in modo visuale, sullo stile di modelmaker, setti la
property Persistent a True e indichi con apposite property nome della
tabella e nome fisico del campo. A quel punto uno strumento mappa queste
classi su un db usando un oggetto tipo tsqlconnection di dbx, creando le
tabelle corrispondenti alle classi (con qualche campo in + di
sistema......).
I limiti? Per prima cosa, ora non si puň fare il reverse engineering di un
db esistente; ciň vuol dire che sa hai un db gia in uso e lo vuoi usare come
base per creare qualcosa sfruttando eco, ti tocca ti ricrearti tutto a mano,
cosa che, se il tuo db č bello tosto, port avia un bel po di tempo.
Ancora, usa solo sql standard. Quindi, a prescindere dalle ottimizzazioni
lato server, lato client si usa un sql molto scarno.
Tornando a bomba, ho dato una veloce occhiata alla documentazione di tiOpf e
la cosa mi piace.
A