Web Designer vs Web Developer: η διαφορά στην ευθύνη ενός έργου
«Web Designer vs Web Developer: Ξέρετε τη διαφορά;» είναι ουσιαστικά ερώτηση για το ποιος αναλαμβάνει τι όταν κατασκευάζεται μια ιστοσελίδα. Ο σχεδιαστής επικεντρώνεται στη δομή της εμπειρίας, στην οπτική επικοινωνία και στη χρήση. Ο προγραμματιστής αναλαμβάνει να μετατρέψει τις απαιτήσεις σε λειτουργικό σύστημα με κώδικα και κατάλληλες συνδέσεις. Στην πράξη οι δεξιότητες μπορούν να επικαλύπτονται, γι’ αυτό ο τίτλος στην επαγγελματική κάρτα δεν αρκεί. Σημασία έχει ποιος ευθύνεται για κάθε παραδοτέο, ποιος το ελέγχει και πώς συνεργάζονται οι δύο πλευρές.
Δύο οπτικές στην ίδια ιστοσελίδα
Ο σχεδιαστής ξεκινά από το ερώτημα «τι πρέπει να βλέπει και να καταλαβαίνει ο επισκέπτης;». Οργανώνει περιεχόμενο, οπτική ιεραρχία, πλοήγηση, καταστάσεις φόρμας και διάταξη σε διαφορετικές οθόνες. Το αποτέλεσμα είναι ένα τεκμηριωμένο σχέδιο που εκφράζει πώς θα βιώνεται η ιστοσελίδα, όχι απαραιτήτως ο τελικός κώδικας.
Ο προγραμματιστής διερευνά «πώς θα λειτουργήσει αυτό με αξιοπιστία;». Υλοποιεί την προβολή, τον χειρισμό εισόδων, τις συνδέσεις με αποθήκευση δεδομένων και τη λογική των ενεργειών. Δεν περιορίζεται στο να αντιγράψει ένα στιγμιότυπο: πρέπει να χειριστεί τις πραγματικές καταστάσεις που εμφανίζονται όταν οι χρήστες αλληλεπιδρούν.
Πώς μοιράζεται η αρχιτεκτονική πληροφοριών
Οι κατηγορίες μενού, η σειρά υπηρεσιών και οι τρόποι εύρεσης περιεχομένου αποτελούν συνήθως κοινό πεδίο συνεργασίας. Ο σχεδιαστής οργανώνει την πλοήγηση σύμφωνα με τις ανάγκες του χρήστη. Ο προγραμματιστής ελέγχει αν η προτεινόμενη δομή μπορεί να παραχθεί από τα υπάρχοντα δεδομένα και να λειτουργήσει στις απαιτούμενες σελίδες.
Για παράδειγμα, μια μακέτα με φίλτρο ανά περιοχή απαιτεί πραγματικές διαθέσιμες περιοχές, κανόνες επιλογής και σαφή συμπεριφορά όταν δεν υπάρχουν αποτελέσματα. Χωρίς συντονισμό, η ελκυστική σχεδίαση μπορεί να υπόσχεται δυνατότητες που δεν έχουν προϋπολογιστεί για υλοποίηση.
Οι μακέτες και η τεχνική προδιαγραφή είναι διαφορετικά πράγματα
Μια οθόνη δείχνει πού βρίσκεται το κουμπί αλλά δεν περιγράφει πάντα τι συμβαίνει όταν αποτυγχάνει η σύνδεση ή έχει λήξει μια περίοδος σύνδεσης. Το σχεδιαστικό πρωτότυπο πρέπει να καλύπτει καταστάσεις, ενώ η τεχνική προδιαγραφή ορίζει δεδομένα, δικαιώματα πρόσβασης, ελέγχους εγκυρότητας και ενδεχόμενα σφάλματα.
Αν παραδίδεται μόνο στατική εικόνα, ο προγραμματιστής καλείται να πάρει πολλές μη συμφωνημένες αποφάσεις. Αν υπάρχει μόνο κώδικας χωρίς σχεδιαστική καθοδήγηση, η εμπειρία μπορεί να καταλήξει ασυνεπής. Η σωστή ανάθεση προβλέπει και τα δύο όπου χρειάζονται.
Ποιος φροντίζει την προσβασιμότητα;
Η ευθύνη μοιράζεται. Ο σχεδιαστής επιλέγει αναγνώσιμη τυπογραφία, αντίθεση, ορατές καταστάσεις εστίασης και σαφή σειρά πληροφοριών. Ο προγραμματιστής χρησιμοποιεί σωστή σήμανση, ενεργά στοιχεία και χειρισμό πληκτρολογίου. Οι οδηγίες W3C για την ιεραρχία επικεφαλίδων δείχνουν χαρακτηριστικά πώς η δομή βοηθά την πλοήγηση.
Αν το σχέδιο προβλέπει μόνο εικονίδιο χωρίς όνομα, είναι δύσκολο να προστεθεί αργότερα κατανοητή εμπειρία. Αντίστοιχα, ένα σωστά ονομασμένο κουμπί που υλοποιείται ως μη λειτουργικό διακοσμητικό στοιχείο δεν πετυχαίνει τον σκοπό του. Επομένως ο έλεγχος προσβασιμότητας χρειάζεται κοινά κριτήρια και πραγματική δοκιμή.
Παράδειγμα: μια φόρμα ζήτησης προσφοράς
Ο σχεδιαστής αποφασίζει ποια πεδία εμφανίζονται, πού τοποθετείται η βοήθεια, πώς δηλώνεται ένα λάθος και τι μήνυμα βλέπει ο χρήστης μετά την αποστολή. Ο προγραμματιστής υλοποιεί ελέγχους εισόδου, ασφαλή μεταφορά στοιχείων, αποθήκευση όπου απαιτείται και αξιόπιστη επιβεβαίωση της ενέργειας.
Και οι δύο πρέπει να συμφωνήσουν πώς αντιμετωπίζονται λανθασμένα δεδομένα ή προσωρινή αποτυχία του συστήματος. Μια φόρμα που φαίνεται σωστή αλλά χάνει αιτήματα είναι αποτυχημένη λειτουργία. Αντίστροφα, μια τεχνικά σωστή φόρμα που μπερδεύει τον επισκέπτη δεν υπηρετεί την επιχείρηση.
Παράδειγμα: κατάλογος προϊόντων ή υπηρεσιών
Σε κατάλογο, ο σχεδιαστής οργανώνει τις κάρτες και την εμπειρία σύγκρισης. Ο προγραμματιστής εξασφαλίζει ότι τα στοιχεία αντλούνται σωστά, τα φίλτρα δίνουν αναμενόμενα αποτελέσματα και οι επιλογές παραμένουν συνεπείς. Η ασάφεια εμφανίζεται όταν λείπει κοινή απόφαση για το τι θεωρείται επιτυχημένη αναζήτηση.
Η εργασία του προγραμματιστή ιστοσελίδων συνδέεται άμεσα με δεδομένα, ενώ το αντικείμενο του σχεδιαστή καθορίζει πώς θα γίνουν κατανοητά. Η συνεργασία τους ελέγχεται πάνω σε πραγματικά παραδείγματα προϊόντων και όχι σε ανώνυμες κάρτες.
Μπορεί το ίδιο πρόσωπο να καλύπτει και τους δύο ρόλους;
Ναι, υπάρχουν επαγγελματίες με ισχυρές δεξιότητες τόσο στον σχεδιασμό όσο και στην ανάπτυξη. Αυτό όμως χρειάζεται να αποδεικνύεται από τα αντίστοιχα παραδοτέα και όχι να θεωρείται δεδομένο από έναν γενικό τίτλο. Σε μικρά έργα η ενιαία ευθύνη μπορεί να μειώνει τον συντονισμό, αν διατηρούνται ποιοτικές διαδικασίες.
Σε πιο σύνθετες εφαρμογές μπορεί να χρειάζεται εξειδίκευση σε σχεδιασμό, ανάπτυξη διεπαφής, υποδομή και δεδομένα. Δεν υπάρχει σταθερός αριθμός ατόμων κατάλληλος για κάθε περίπτωση. Ξεκινήστε από τις λειτουργίες, τους κινδύνους και τα όρια εμπειρίας όσων θα τις υλοποιήσουν.
Πίνακας ευθυνών πριν υπογραφεί η ανάθεση
Καταγράψτε κάθε κρίσιμη εργασία σε μία γραμμή: δομή σελίδων, πρότυπα, σύνταξη κειμένων, διαδραστικές καταστάσεις, φόρμες, εξωτερικές συνδέσεις, δοκιμές και δημοσίευση. Δίπλα βάλτε υπεύθυνο υλοποίησης, υπεύθυνο ελέγχου και αποδεικτικό ολοκλήρωσης. Η ίδια εργασία μπορεί να απαιτεί συμμετοχή δύο ρόλων, αλλά ένας πρέπει να οδηγεί την παράδοσή της.
Για μια φόρμα, το σχέδιο αποδεικνύεται με εγκεκριμένες καταστάσεις και η υλοποίηση με επιτυχή και αποτυχημένα σενάρια δοκιμής. Για το περιεχόμενο, ορίστε ποιος εγκρίνει την ακρίβεια. Αυτός ο απλός πίνακας αποτρέπει το συνηθισμένο κενό όπου όλοι θεωρούν ότι το έκανε κάποιος άλλος.
Συνεννόηση όταν αλλάζουν οι επιχειρηματικοί κανόνες
Μια νέα απαίτηση μπορεί να αλλάξει ταυτόχρονα την εμφάνιση και τη λογική. Αν μια υπηρεσία αποκτήσει διαφορετικές επιλογές, ο σχεδιαστής πρέπει να αποφασίσει πώς παρουσιάζονται και ο προγραμματιστής να ελέγξει πώς αποθηκεύονται και επαληθεύονται. Αν συμμετέχει μόνο η μία ειδικότητα, το έργο μπορεί να καταλήξει με δυνατότητα που εμφανίζεται αλλά δεν λειτουργεί σωστά.
Οι αλλαγές αυτές καταγράφονται σε κοινό αίτημα με το επιθυμητό αποτέλεσμα, τον υπεύθυνο απόφασης και τα σενάρια ελέγχου. Έτσι περιορίζονται οι παρεξηγήσεις και οι διορθώσεις δεν υπονομεύουν προηγούμενη λειτουργία.
Πότε ελέγχονται οι αποκλίσεις από το σχέδιο
Μια υλοποίηση μπορεί να διαφέρει από τη μακέτα για τεκμηριωμένο λόγο: πραγματικά δεδομένα, μικρότερο πλάτος ή απαραίτητη συμπεριφορά σε σφάλμα. Κάθε ουσιαστική απόκλιση πρέπει να αξιολογείται ως προς τη χρησιμότητα και να εγκρίνεται, όχι να κρύβεται μέχρι την τελευταία παρουσίαση.
Ο έλεγχος δεν πρέπει να περιορίζεται στην ομοιότητα χρωμάτων. Ρωτήστε αν διατηρήθηκε η σωστή ιεραρχία, αν λειτουργούν οι ενέργειες με πληκτρολόγιο και αφή και αν το περιεχόμενο παραμένει κατανοητό όταν αλλάζει. Έτσι η ποιότητα αποκτά κοινό ορισμό για σχεδιαστή και προγραμματιστή.
Πώς αξιολογούμε προσφορές διαφορετικών ομάδων
Μη συγκρίνετε την προσφορά ενός σχεδιαστή για λίγες μακέτες με πλήρη πρόταση ανάπτυξης σαν να περιλαμβάνουν το ίδιο προϊόν. Διαβάστε αναλυτικά τα παραδοτέα, το εύρος δοκιμών, την ευθύνη για σφάλματα και τις διαδικασίες αλλαγών. Ζητήστε απλή εξήγηση των εξαρτήσεων, ώστε να ξέρετε πότε μπορεί να ξεκινήσει κάθε επόμενο στάδιο.
Πριν αποφασίσετε, βεβαιωθείτε ότι υπάρχει πραγματικός τρόπος συντονισμού. Αν αναθέσετε τους δύο ρόλους χωριστά, ορίστε κοινή συνάντηση ανασκόπησης και ενιαίο σημείο αποδοχής. Το ζητούμενο δεν είναι να ξεχωρίσετε ποιος είναι «πιο σημαντικός», αλλά να μην αφήσετε καμία βασική λειτουργία χωρίς υπεύθυνο.
Παραλαβή που τεκμηριώνει και τους δύο ρόλους
Από τον σχεδιαστή παραλαμβάνετε πρότυπα, οδηγίες στοιχείων και συμπεριφορές. Από τον προγραμματιστή παραλαμβάνετε λειτουργική ιστοσελίδα, ελέγχους και τις συμφωνημένες τεχνικές οδηγίες. Εάν ένας επαγγελματίας καλύπτει και τα δύο, τα δύο είδη απόδειξης εξακολουθούν να είναι αναγκαία.
Δοκιμάστε μαζί τις βασικές διαδρομές και καταγράψτε εκκρεμότητες χωρίς γενικές δηλώσεις «όλα έτοιμα». Η σωστή κατανομή των ευθυνών φαίνεται ιδιαίτερα όταν παρουσιαστεί πρόβλημα: είναι ξεκάθαρο ποιος το αξιολογεί, ποιος το διορθώνει και πώς αποδεικνύεται ότι λύθηκε.