Σχεδιάζοντας Friendly GUI (Graphical User Interface)
Πριν λίγο καιρό, είχα μια συζήτηση με μερικά μέλη του DNZ περι GUI και κατα πόσο είναι εφικτό να σχεδιάσουμε όμορφα και λειτουργικά GUI.
Τα τελευταία χρόνια ασχολήθηκα πάρα πολύ με το κομμάτι αυτό, ψάχνοτας απο εδώ, ψάχνοντας απο εκεί, τελικά κατέληξα σε ορισμένα συμπεράσματα, τα οποία θα τα μοιραστώ μαζί σας.
Δυστυχώς, όχι μόνο στην Ελλάδα, αλλά περισσότερο σ’ αυτήν, θεωρούμε το GUI ως ενα κομμάτι το οποίο πρέπει να απλά να "γίνει" για να μπορέσουμε να παραδώσουμε την εφαρμογή μας στον πελάτη, κάτι δηλαδή σαν μια αγγαρεία. Εδώ ακριβώς βρίσκεται και το λάθος, μια και οδηγούμαστε έτσι στον σχεδιασμό πολύ πρόχειρων GUI, δύσκολων στην χρήση, με πάρα πολλά στοιχεία (elements) μαζεμένα και σε κακές διατάξεις, λανθασμένες χρωματικές κωδικοποιήσεις (color codes) και μπάρες εργασίας που αντι να βοηθούν τον χρήστη τον μπερδεύουν ακόμα περισσότερο.
Το GUI είναι αυτό που βλέπει ο πελάτης, είναι αυτό το οποίο θα κάνει τον πελάτη να εντυπωσιαστεί, είτε ευχάριστα , είτε δυσάρεστα. Τι να το κάνει ο πελάτης αν το πρόγραμμά μας είναι το καλύτερο στον κόσμο και κάνει και καφέ εάν δεν μπορεί να το κάνει εύκολα ,γρήγορα και απλά. Δεν μας νοιάζει όμως να μπορεί να το κάνει μόνο εύκολα, γρήγορα και απλά, αλλα μας νοιάζει και το πριν απο αυτό. Εννοώ, ότι εάν ειναι να αναγκάσουμε τον πελάτη, να μπλέξει σε λεπτομέριες, πχ να ορίσει ο ίδιος εαν η σύνδεση με την καφετέρια είναι σε USB ή σε RS232, τότε πάλι είμαστε λάθος. Σκοπός είναι να δίνουμε ναι μεν στον χρήστη την επιλογή προτείνοντας όμως ταυτόχρονα το σωστό. Όσο καλό και να είναι το back end engine μας, εάν το GUI είναι λάνθασμένα σχεδιασμένο, τότε δυστυχώς, όχι μόνο δεν θα επιλέξουν το προίον μας, εαν έχουν κάποια άλλα εναλλακτική, αλλά και όσοι το έχουν, δεν θα μπορέσουν ποτέ να το χρησιμοποιήσουν στο 100% εξαιτίας της πολυπλοκότητάς του.
Ο χρήστης είναι αυτός ο οποίος έρχεται κάθε μέρα σε επαφή με το GUI μας. Οι χρήστες χωρίζονται σε 4 κατηγορίες (οχι σε 3 όπως νομίζετε):
- Αυτοί που δεν ξέρουν καθόλου (αρχάριοι)
- Αυτοί που ξέρουν (μέσοι)
- Αυτοί που ξέρουν πολύ καλά (προχωρημένοι)
- Αυτοί που νομίζουν ότι ξέρουν (kiddies).
Σκοπός μας είναι να καλύψουμε τις «ανάγκες» και τις ιδιαιτερότητες όλων. Πχ δεν θέλουμε ο προχωρημένος χρήστης να περνάει απο 15 wizard screens για να μπορέσει να κάνει μια απλή εκτύπωση.
Πολλές φορές δεχόμαστε βελτιώσεις απο τους καθημερινούς χρήστες, οι οποίοι δίνοντας μια απλή για εμάς υπόδειξη προσθήκης ενός element στην φόρμα (πχ ενα dropdown menu εαν ο πελάτης είναι ενεργός), γι αυτούς είναι σωτήρας (χρόνου, χρήματος κλπ).
Εν κατακλείδι , ενα GUI πρέπει να είναι:
- Εύκολο στην χρήση και λειτουργικό (και για τον αρχάριο και για τον προχωρημένο χρήστη)
- Να μην είναι πολυ φορτωμένο, αλλά ούτε πολύ λειψό
- Να μην χρειάζεται πολλά resources για να λειτουργήσει
- Να μην χρησιμοποιεί μηνύματα του στυλ «Κρίσιμο λάθος» κλπ, τα οποία φοβίζουν τον χρήστη
- Να προσφέρει φιλικά χρώματα στον χρήστη (σωστό color coding)
- Να έχει όμορφα εικονίδια διεπαφής
- Να ακολουθεί τα standards της Microsoft για τον τρόπο γραφής των μηνυμάτων που εμφανίζονται στο χρήστη
Στα υπόλοιπα κομμάτια του οδηγού, θα μιλήσω για θέματα που περιλαμβάνουν, μεταξύ άλλων, τα εξής:
- Color coding, error/information messages representation and tips
- Σωστή διάταξη των στοιχείων μιας φόρμας
-Πως να ξεχωρίζετε τις advanced λειτουργίες απο τις απλές
- Validation.
- Σωστή περιγραφή των εικονιδίων της εφαρμογής στον γραφίστα και χρήση έτοιμων βιβλιοθηκών (τι πρέπει να προσέξουμε,πως επιλέγουμε κλπ)
- Δημιουργία μιας φόρμας με custom border
- Skinning libraries and techniques
- Δημιουργία δυναμικού GUI με βάση role based security
- GUIs in multi tier applications
Color coding, error/information messages representation and tips.
Ενα πολύ σημαντικό κομμάτι στον σχεδιασμό του GUI είναι οι χρωματικοί συνδυασμοί οι οποίοι θα χρησιμοποιηθούν. Ο χρωματικός συνδυασμός μπορεί είτε να επηρεαστεί απο το είδος της εφαρμογής (π.χ. σε μια εφαρμογή κρατήσεων εισιτηρίων για την ακτοπλοία, σε μπλε κλπ). Ποτέ δεν χρησιμοποιούμε έντονα χρώματα, π.χ. το «Navy Blue» για background color σε textbox element και «White» για text color, αλλά το «Light Steel Blue» για Form Background color, το «Alice Blue» για background color στα textbox elements και «Black» για text color.
Σε μια εφαρμογή θα πρέπει να έχουμε υπόψιν μας διάφορες καταστάσεις των elements, πχ disabled, enabled, focused, not focused, error state, correct state. Για όλες τις προηγούμενες καταστάσεις πρέπει να χρησιμοποιήσουμε κάποιο χρώμα το οποίο δηλώνει την κατάσταση του element (περισσότερο για τα text elements).
Εάν σε κάποιο πεδίο text υπάρχει λάθος τιμή, τότε δεν θα αλλάξουμε το χρώμα του background του text element αλλά το border color του, πχ σε κόκκινο, το οποίο σε συνδιασμό με τον error provider (ή και χωρίς αυτόν) θα τραβήξει την προσοχή του χρήστη. Καλό θα ήταν τα ανενεργά elements να έχουν ένα χρώμα ελάχιστα πιο σκούρο απο το ήδη υπάρχον. Αυτό βοηθάει τον χρήστη να εντοπίσει γρήγορα το ενεργό πεδίο και να συνεχίσει την δουλειά του, χωρίς να χάνει χρόνο "ψάχνοντας" μέσα στη φόρμα. Επίσης πολύ καλό θα ήταν να δίνουμε διάφορα tips σε balloons στο OnFocus του element, όπως πχ τι πιθανές τιμές περιμένει η εφαρμογή (δεν θα μιλήσουμε ακόμα για masked input, για να αποφύγουμε τα λάθη), απλά κάποια συμβουλή ή ακόμα κάποιο παράδειγμα.
Ας υποθέσουμε όμως οτι παρ’όλαυτά, ο χρήστης μας κάνει λάθος.
Όταν ανακαλύψουμε το λάθος κατα το validation δεν θα πρέπει να το δείξουμε σε MessageBox αλλά στο Statusbar της φόρμας. Σε περίπτωση που τα λάθη είναι παραπάνω απο ένα, τότε καλό είναι να τα «συγκεντρώσουμε» και να τα εμφανίσουμε όλα σε ένα custom form (το οποίο θα έχει το ρόλο του MessageBox). O καλύτερος τρόπος να εμφανίσουμε πολλά μηνύματα στον χρήστη χωρίς να τον τρομάξουμε, είναι να τα εμφανίσουμε σε μορφή ερωτοαπαντήσεων, δηλαδή το κάθε λάθος να αποτελεί ένα τίτλο σε bullets (μια dynamic builded webpage), τα οποία θα κάνουν expand στο OnClick και θα δείχνουν την περιγραφή του λάθους, ενώ απο κάτω θα υπάρχει ενα link ή μία πολύ σύντομη περιγραφή της διαδικασίας διόρθωσης του λάθους ή τον λόγο τον οποίο το προκαλεί.
Κατα την περιγραφή του λάθους προσπαθούμε να αποφύγουμε τεχνικούς όρους ενώ δεν μιλάμε ποτέ στην προστακτική στον χρήστη. Σκοπός μας είναι να τον κάνουμε να νιώσει άνετα ώστε να διορθώσει το λάθος του.Χρησιμοποιούμε καθημερινές λέξεις για να τον οδηγήσουμε εκεί που θέλουμε. Σε περίπτωση που το λάθος μας είναι “critical” δίνουμε στον χρήστη να καταλάβει την κρισιμότητα του λάθους και την διαδικασία με την οποία θα πρέπει να αναφέρει το λάθος στην όμαδα τεχνικής υποστήριξης του προιόντος, ώστε να διορθωθεί σε επερχόμενες εκδόσεις του προιόντος (bug fixing).
-----------------
Εδώ τελειώνει το πρώτο κομμάτι της εισαγωγής μου στο Friendly GUI, στο επόμενο άρθρο θα δημοσιεύσω και κάποια sample forms τα οποία κάνουν demonstrate αυτά τα οποία γράφω εδώ, αλλά και ότι θα αναφέρω στο επόμενο («Σωστή διάταξη των elements μιας φόρμας και πως να ξεχωρίζεται τις advanced λειτουργίες απο τις απλές καθώς και validation»), καθώς το ένα εξαρτάται απο το άλλο και δεν ήθελα να τα σπάσω σε δύο διαφορετικά κομμάτια. Μέχρι στιγμής οι συμβουλές είναι γενικές, ίσως αρκετά απο αυτά κάποιοι να τα γνωρίζετε ήδη, αλλά ακόμα είναι η αρχή έχω πάρα πολλά να γράψω, οπότε συγχωρήστε την όποια ανία μπορεί να σας προκάλεσα για αρχή.