tsevdos.com

Web design, internet news and blogging tips

CSS : Κληρονομικότητα (inheritance) και cascade

| Filed under articles css

Εάν θα μπορούσα να δηλώσω expert σε κάτι, αυτό θα ήταν σίγουρα το CSS. Δουλεύω με αυτό από την πρώτη του version και γενικά είναι μέρος της καθημερινότητας μου. Έχω γράψει άπειρες γραμμές σε πολύ μεγάλα αλλά και πολύ μικρά sites, και με ενθουσιάζει το γεγονός πως ένα τόσο φαινομενικά απλό πρότυπο, ζωντανεύει την markup μας. Στην προηγούμενη πρόταση γράφω “φαινομενικά απλό” γιατί το “γράφω CSS” από το “γνωρίζω CSS” έχει τεράστια διαφορά. Ένας γνώστης μπορεί να γράψει μέσα σε ελάχιστες γραμμές, αυτό που κάποιος newbie γράφει και ξαναγράφει! Το όλο μυστικό κρύβεται σε 2 χαρακτηριστικά του CSS που θέλουν λίγο χρόνο για να εξοικειωθείτε, η κληρονομικότητα (inheritance) και το cascade.

Στο παρακάτω αρθράκι λοιπόν, θα προσπαθήσω να εξηγήσω όσο καλύτερα γίνεται αυτά τα δύο χαρακτηριστικά του CSS, τα οποία ποτέ δεν μου εξήγησε κανείς και τελικά τα έμαθα με τον δύσκολο τρόπο (hard way που λένε και οι Εγγλέζοι). Το περίεργο είναι πως και ολόκληρα βιβλία αφιερωμένα στο θέμα, αποφεύγουν να τα εξηγήσουν αναλυτικά – μάλλον δεν θέλουν να γίνουν όλοι experts ;-) . Ας ξεκινήσουμε λοιπόν.

Κληρονομικότητα (Inheritance)

Γενικά δουλεύει όπως μπορείτε να φανταστείτε και όπως έχετε συνηθίσει και σε γλώσσες προγραμματισμού (αν έχετε ασχοληθεί τέλος πάντων). Είναι ο μηχανισμός με τον οποίο συγκεκριμένες ιδιότητες (properties) μεταφέρονται από το parent element στα “παιδιά” του. Είναι αρκετά εύκολο στην κατανόηση, και στην ουσία το μόνο πράγμα που προκαλεί μπέρδεμα είναι ποιες ιδιότητες (properties) κληρονομούνται τελικά, μιας και δεν κληρονομούνται όλες. Σε αυτόν τον πίνακα (κοιτάξτε την 5η στήλη) μπορείτε να δείτε ποιες από αυτές κληρονομούνται και ποιες όχι. Προσωπικά δεν τον θυμάμαι απέξω, άλλωστε δεν έχει και πολύ νόημα μιας και γιαυτό υπάρχουν οι DOM inspectros (όπως πχ. το firebug), ωστόσο κρατήστε πως ότι έχει να κάνει με fonts κληρονομείτε (γι’ αυτό και το declaration του font στο body είναι ο πιο σημαντικός CSS κανόνας ενός site).

Cascade

Η κληρονομικότητα όπως είδατε είναι αρκετά εύκολη στην κατανόηση. Ας εξηγήσουμε όμως και το Cascade το οποίο είναι κάπως πιο πολύπλοκο. Το Cascade (δεν νομίζω να μπορεί μεταφραστεί κάπως αξιόλογα στα ελληνικά) είναι ίσως το πιο δυσνόητο κομμάτι του CSS γιατί κρύβει αρκετή θεωρία από πίσω του, ωστόσο είναι και το πιο σημαντικό και γι αυτόν τον λόγο αποτελεί και την πρώτη λέξη του ακρώνυμου CSS (Cascading Style Sheets). To Casade λοιπόν αποτελείται από 3 βασικές έννοιες οι οποίες καθορίζουν πως το CSS θα εφαρμόσει τελικά τους κανόνες των style sheets μας. Οι 3 έννοιες είναι οι παρακάτω :

  • Importance (σπουδαιότητα)
  • Specificity (ειδικότητα)
  • Η σειρά που εμφανίζονται μέσα στον κώδικα

Και για να μην μπερδευτούμε ας τα πάρουμε ένα-ένα.

Importance (Σπουδαιότητα)

Η σπουδαιότητα έχει να κάνει με το που δηλώθηκε ο CSS κανόνας. Οι κανόνες που θα κάνουν conflict μεταξύ τους θα εφαρμοστούν με την παρακάτω σειρά, με τις νεότερες να υπερισχύσουν :

  1. User agent style sheets
  2. Κανονικοί style sheet κανόνες συγγραφέα (author)
  3. Κανονικοί style sheet κανόνες χρήστη (user)
  4. Σημαντικοί style sheet κανόνες συγγραφέα (author)
  5. Σημαντικοί style sheet κανόνες χρήστη (user)

Αλλά ας εξηγήσουμε λίγο τι είναι τα παραπάνω style sheets και από που έρχονται!

Λέγοντας user agent style sheets εννοούμε όλα τα ενσωματωμένα (default) style sheet του browser (πχ. margin/padding σε headers, παραγράφους, λίστες, χρώματα link, κτλ.).

Οι style sheet κανόνες συγγραφέα (author), είναι τα κλασικά style sheets που γράφουν οι web designers του εκάστοτε site.

Οι style sheet κανόνες χρήστη (user), είναι κάποιοι ειδικοί κανόνες που μπορεί να θέσει ο ίδιος ο χρήστης. Οι περισσότεροι browsers δεν επιτρέπουν τέτοιου είδους κανόνες, ωστόσο πιο ειδικοί browsers (πχ. για δυσλεκτικούς ή screen readers οι οποίοι επιτρέπουν κυρίως aural style sheets) δίνουν αρκετές επιλογές και δυνατότητες στον ίδιο χρήστη (και μάλιστα υπερτερούν!).

Τέλος, τα δύο τελευταία είδη style sheet, μπορούν να εφαρμοστούν είτε ως κανονικοί (normal) κανόνες, είτε ως σημαντικοί (important) κανόνες (πχ. p { font-size: 1em !important; }), με τους δεύτερους να είναι ισχυρότεροι από τους πρώτους.

Γενικότερα εμείς που ασχολούμαστε με την κατασκευή web sites δεν έχουμε να κάνουμε και πολλά πράγματα με την σπουδαιότητα, γιατί πολύ απλά δεν είναι στο χέρι μας, ωστόσο θα πρέπει να έχουμε στο μυαλό μας τι style sheets δέχεται ένα document, τι είναι τα user agent style sheets, ή πως λειτουργεί ο !important κανόνας.

Specificity (ειδικότητα)

Η ειδικότητα είναι το πιο σημαντικό κομμάτι του cascade, και αυτό που πρέπει να κατανοήσει ο κάθε web designer. Ο γενικός κανόνας είναι σχετικά απλός, όσο πιο συγκεκριμένος (ειδικός) είναι o selector ενός κανόνα, ο συγκεκριμένος κανόνας υπερισχύει! Αν και είναι εύκολο και λογικό, κάποιος νέος στον χώρο μπορεί να χάσει πολύ εύκολα την μπάλα σε ένα πολύπλοκο έγγραφο (document), και να καταντήσει να γράφει ξανά και ξανά τα ίδια πράγματα.

Ο πιο συγκεκριμένος selector, ο οποίος αναιρεί όλους τους άλλους, αλλά δεν πρέπει να χρησιμοποιούμε ποτέ, είναι το style attribute σε οποιοδήποτε element. Δεν το χρησιμοποιούμε για να μην μπλέκουμε την markup με τα styles, και για πολλούς άλλους λόγους που έχουμε εξηγήσει σε άλλα posts. Από εκεί και πέρα έχουμε ένα περίεργο point system για το κάθε selector, το οποίο παίζει ως εξής:

  • Το κάθε element (ή pseudo-element) που εμφανίζεται στον selector μας παίρνει 1 βαθμό
  • Η κάθε κλάση (class) που που εμφανίζεται στον selector μας παίρνει 10 βαθμούς
  • Το κάθε id που εμφανίζεται στον selector μας παίρνει 100 βαθμούς

Εδώ μπορείτε να βρείτε και μια πιο χιουμοριστική εξήγηση του point system που περιγράφω, ωστόσο με τα παρακάτω παραδείγματα του πίνακα, πιστεύω πως θα καταλάβετε καλύτερα το πως δουλεύει.

Το Point system της ειδικότητας (specificity)
Selector id class element Specificity
p 0 0 1 001
.class 0 1 0 010
p.class 0 1 1 011
#id 1 0 0 100
#id .class 1 1 0 110
#id p.class 1 1 1 111
p a 0 0 1+1 002
.classa .classb 0 1+1 0 020

Κάπως έτσι υπολογίζεται το specificity και ο selector με τον μεγαλύτερο αριθμό υπερτερεί.

Η σειρά που εμφανίζονται μέσα στον κώδικα

Τι γίνεται όμως όταν 2 κανόνες έχουν ακριβώς το ίδιο specifity; Για παράδειγμα :

.nav a { color:green; }
.nav a { color:red; }

Και οι 2 παραπάνω selectors έχουν 011, ωστόσο όλοι οι browsers θα κάνουν rendering τα links με κόκκινο χρώμα για τον πολύ απλό λόγο πως ήταν ο πιο πρόσφατος κανόνας που συναντήθηκε. Το μόνο που πρέπει να έχουμε υπόψη μας εδώ είναι πως εάν έχουμε πολλά style sheets η σειρά που φορτώνονται έχει σημασία, οπότε το προσέχουμε και αυτό.

Αυτά τα λίγα για την κληρονομικότητα (inheritance) και το cascade. Ελπίζω να ξεκαθαρίσατε κάποια πράγματα που έχουν να κάνουν με την θεωρία που κρύβεται πίσω από το CSS, η οποία πολλές φορές δεν αναφέρεται και δεν εξηγείτε όπως θα έπρεπε.

HTML5 σκέψεις

| Filed under articles inspiration markup opinions

Αυτό το καλοκαίρι το έριξα – όπως και πολλοί άλλοι φαντάζομαι – στην HTML5 η οποία έχει ήδη αρχίσει να κάνει δειλά-δειλά την εμφάνιση σε αρκετά sites, σε μικρότερο ή μεγαλύτερο βαθμό. Τα βιβλία που διάβασα ήταν το “HTML5 for web designers” του Jeremy Keith και το “Introducing HTML5” των Bruce Lawson και Remy Sharp. Καταρχάς όποιος σκέφτεται να αγοράσει κάποιο βιβλίο αυτήν την στιγμή, του προτείνω το δεύτερο (Introducing HTML5), μιας και το πρώτο με απογοήτευσε αρκετά για “A book apart” βιβλίο. Γενικότερα δεν θα το περιέγραφα καν ως βιβλίο, αλλά σαν μια γενική, θεωρητική εισαγωγή για το τι είναι η HTML5. Αντίθετα, το Introducing HTML5 με ξάφνιασε ευχάριστα τόσο με τα πολλά θέματα που καλύπτει όσο και με τον τρόπο που τα καλύπτει, μιας και δεν μένει μόνο στην θεωρία, αλλά προχωράει και στην πράξη (ρίξτε οπωσδήποτε και μια ματιά στα παραδείγματα του βιβλίου).

Μετά από αυτήν την μικρή εισαγωγή λοιπόν, και με την ελάχιστη εμπειρία που έχω στο θέμα, θέλω να καταγράψω κάποιες σκέψεις, προβληματισμούς, και γενικότερα να ξεκινήσω μια συζήτηση με τα πιο ανήσυχα μυαλά… Θα προσπαθήσω να είμαι σαφής και γρήγορος, έτσι ώστε να μην μπερδέψω  και να μην κουράσω. Επίσης σε αυτό το post γράφοντας HTML5 εννοώ και τα APIs ή τις τεχνολογίες οι οποίες δεν είναι μέρος του επίσημου HTML5 specification (είναι από μόνα τους ξεχωριστά specifications), ωστόσο θα χρησιμοποιηθούν κυρίως με αυτήν την markup και την ίδια περίοδο. Ας δούμε λοιπόν τι μας επιφυλάσσει το μέλλον, ε, το παρόν ήθελα να πω!

Markup

Ας ξεκινήσουμε με το πιο απλό μέρος της HTML5 – θεωρητικά πάντα – την markup και τα semantics. Τα semantics λοιπόν έχουν αλλάξει αρκετά και πλέον γίνεται ακόμα πιο δύσκολο το να γράψεις σημασιολογική markup. Παρακάτω περιγράφω αυτά που μου φάνηκαν πιο περίεργα, σημαντικά ή παράξενα!

  • Το outline – το οποίο δεν έχει υλοποιηθεί ακόμα από κανέναν browser (!!!) – αλλάζει τελείως τον νόημα των headings (h1-h6). Πλέον ένα h3 heading μπορεί να είναι πιο σημαντικό από ένα h1 heading! Στην ουσία στην HTML5 θα μπορούσαμε να είχαμε ένα και μοναδικό τύπο heading (h για παράδειγμα), ωστόσο υπάρχουν ακόμα έξι (h1-6) για compatibility θέματα. Μένει να δούμε πως θα επηρεάσει και το SEO αυτό το θέμα.
  • Τα sections και τα articles είναι αρκετά δύσκολα στην κατανόηση, μιας και το ένα μπορεί να υπάρχει μέσα στο άλλο αρκετές φορές! Θέλει αρκετή μελέτη έτσι ώστε να τα χρησιμοποιήσει κάποιος σωστά.
  • Τέλος είμαι πραγματικά περίεργος να δω πως θα φτιάξουν τους WYSIWYG web editors (Dreamweaver για παράδειγμα) έτσι ώστε να γράφουν semantic HTML5. Παλιότερα τα πράγματα ήταν πανεύκολα, απλά πετούσαν παντού ένα div και το θέμα τελείωνε, τώρα τι λύση θα βρουν άραγε;

Φόρμες (forms)

Οι φόρμες επιτέλους δεν θα σπάνε τα νεύρα σε αυτούς που τις φτιάχνουν. Μερικά attributes στην markup μας και θα αφήνουμε τον browser να κάνει όλη την “βρόμικη” δουλειά. Οι περισσότεροι browsers υποστηρίζουν λίγα πράγματα προς το παρόν (ο πιο ολοκληρωμένος browser στο θέμα είναι ο Opera) ωστόσο σιγά-σιγά θα τον φτάσουν και οι υπόλοιποι.

  • Πολύ έξυπνο compatibility μιας και όλες οι φόρμες εμφανίζονται σαν απλά text inputs σε παλιότερους browsers που δεν καταλαβαίνουν τα νέα HTML5 attributes.
  • Δυστυχώς θα γράφουμε για πολύ καιρό ακόμα Javascript validation scripts (ιδιαίτερα στην Ελλάδα, με τους αρχαιοελληνικούς browsers που κυκλοφορούν)!
  • Πρέπει οπωσδήποτε να υπάρξει μια επίσημη γραμμή για το πως θα εμφανίζονται/φαίνονται τα διάφορα widgets (πχ. επιλογή ημερομηνίας) και τα λάθη (validation errors), καθώς και για το πως θα διαγράφουμε αυτά τα default browser styles, γιατί προβλέπω να γίνεται χαμός σε αυτό το θέμα.
  • Ακόμα λιγότερη Javascript χάρις τα autofocus, placeholder, autocomplete και required attributes.
  • Το pattern attribute απλά τα σπάει! Ελέγχει κατευθείαν στον browser το regular expression που έχει δηλωθεί στο pattern!

Video και Audio

Εδώ πέρα τα πράγματα ξεκίνησαν καλά και απλά, αλλά μια (τραγική;) παράληψη στο specification έκανε τα εύκολα δύσκολα! Όπως όλοι ξέρουμε ο κάθε κατασκευαστής browser αποφάσισε (ή θα αποφασίσει) να υποστηρίξει τον video codec που τον συμφέρει.

  • Χρησιμοποιώντας πολλαπλά source elements μπορούμε να φορτώσουμε πολλά διαφορετικά φορμάτ. Πολύ χρήσιμο για την κατάσταση που θα επικρατήσει.
  • Χρησιμοποιώντας το video element με codec Ogg Theora (.ogg), H.264 (mp4) και webM (βασισμένο στον VP8 codec της Google), είμαστε καλυμμένοι στους μοντέρνους browsers, ωστόσο 3 διαφορετικές κωδικοποιήσεις είναι πολλές για το ίδιο video.
  • Και μην ξεχνάτε πως πρέπει να το κωδικοποιήσουμε και σε Flash video για να παίζει σε παλιότερους browsers!
  • Στο audio τα πράγματα είναι αρκετά πιο απλά, μιας και με ένα mp3 έχουμε τελειώσει.
  • Στα θετικά είναι πως το API του video και audio tag είναι ακριβώς το ίδιο (αν θυμάμαι καλά το audio element έχει κανα-δυο λιγότερες methods και attributes – όπως πχ. width και height).

Canvas

Με το Canvas API μπορείς να κάνεις πραγματικά τρελά πράγματα, ωστόσο το θέμα accessibility είναι τεράστιο! Στην ουσία ότι “ζωγραφίζεται” πάνω στον καμβά, δεν μπορεί να διαβαστεί από screen readers. Είναι δηλαδή (προς το παρόν) ένα καθαρά οπτικό (visual) element/API, χωρίς μάλιστα να έχει προβλεφθεί κάποια εναλλακτική λύση για την προβολή περιεχομένου (όπως στο video tag για παράδειγμα)!

Client-side Data storage

Και εδώ δεν γνώριζα αρκετά πράγματα. Οι 2 σοβαρές τεχνολογίες ονομάζονται Web Storage και Web SQL Database (υπάρχει και μια τρίτη από την Mozilla η οποία μάλλον θα σβήσει – δεν θυμάμαι καν το όνομα της), με αρκετή υποστήριξη από τους browsers.

  • Το Web Storage είναι κάτι σαν cookies on steroids. Επίσης η τεχνολογία υποστηρίζετε από όλους (!!!) τους μοντέρνους browsers.
  • H Web SQL υποστηρίζεται σε Opera, Chrome και Safari ενώ η SQL μηχανή που χρησιμοποιούν είναι η SQLite (δεν γνωρίζω εάν το αναφέρει πουθενά το specification, ωστόσο αυτή την έκδοση SQL έχουν οι παραπάνω browsers).
  • Και πάλι θα συνεχίσουμε να γράφουμε για πολύ καιρό cookies για να υποστηρίξουμε τους παλιότερους browsers (fallback κώδικας).

Offline Application Caching

Μια τεχνολογία που δεν είχα ιδέα πως λειτουργούσε, η οποία αν και εντυπωσιακή για κάποιο λόγο δεν μου αρέσει ο τρόπος λειτουργίας της (ωστόσο θα ενθουσιάσει αυτούς που ασχολούνται με web servers, .htaccess files κτλ.). Πολύ απλά δηλώνουμε σε ένα “μανιφέστο” ποια αρχεία θέλουμε να cachαριστούν (αλήθεια πως θα το μεταφράζατε αυτό;) στον browser, έτσι ώστε το site/web app μας να συνεχίζει να λειτουργεί ακόμα και εάν πάψει να λειτουργεί η σύνδεση μας.

  • Η χρήση είναι σχετικά απλή, απλά δημιουργούμε ένα .manifest αρχείο στο οποίο αναφέρουμε τα αρχεία που θέλουμε να cashaρηστούν, και το δηλώνουμε στην markup μας (<html manifest="demo.manifest">). Για κάποιο λόγο ωστόσο δεν μου αρέσει αυτός ο τρόπος λειτουργίας… Με κάνει να αισθάνομαι κάπως έξω από τα νερά μου, μιας και όπως εξήγησα και πιο πάνω μοιάζει πιο πολύ με την δημιουργία κάποιου .htaccess αρχείου, κάτι που δεν κάνει συχνά κάποιος web designer (ή έστω front-end developer).

Geolocation

Ένα από τα πιο εύκολα και αγαπημένα μου χαρακτηριστικά. Το Geolocation API δεν είναι μέρος της HTML5, ωστόσο το αναφέρω για τους λόγους που εξήγησα στην εισαγωγή. Είναι σχετικά απλό (με 2 methods έχετε καθαρίσει – getCurrentPosition και watchPosition), και πιστεύω πως όλο και περισσότερα sites θα το χρησιμοποιούν για να μας δείχνουν πιο “ντόπια” προϊόντα, διαφημίσεις, νέα, προσφορές, κτλ. κτλ. Με λίγα λόγια, “θα φορεθεί πολύ”…

Web Messaging API, Web Workers API και Web Sockets API

Τα παραπάνω APIs τα αναφέρω και τα 3 μαζί μιας και είναι φτιαγμένα για καθαρά Web εφαρμογές (δεν είναι ούτε και αυτά μέρος της HTML5). Με τα παραπάνω APIs μας δίνονται οι παρακάτω δυνατότητες:

  • Το Web Messanging υποστηρίζεται από πολλούς browsers (και IE) και μας επιτρέπει να κάνουμε διάφορα ωραία, όπως να στέλνουμε μηνύματα σε άλλα domains κτλ. Φανταστείτε το κάτι σαν AJAX on steroids και αυτό.
  • Χρησιμοποιώντας Web Workers μπορούμε να κάνουμε την web εφαρμογή μας να τρέχει την Javascript σε διαφορετικά threads! Από μια γρήγορη ματιά που έριξα, η λογική είναι αρκετά πολύπλοκη και πιστεύω πως αυτήν την στιγμή είναι πολύ κακό για το τίποτα, ωστόσο οφείλω να ομολογήσω πως σε μια πολύπλοκη web εφαρμογή (φανταστείτε κάτι σε Photoshop στο web) μπορεί να κάνει τρελή διαφορά (πχ. να χρησιμοποιεί ένα φίλτρο, και ενώ ο web worker κάνει τους υπολογισμούς του, ο χρήστης να συνεχίζει να χρησιμοποιεί την εφαρμογή, χωρίς αυτή να φαίνεται σαν να έχει κολλήσει).
  • Τα Web Sockets ανοίγουν μια αμφίδρομη επικοινωνία μεταξύ του server και του client χρησιμοποιώντας τον browser σαν “μεσάζοντα”. Αρκετά βολικό και χρήσιμο…
Αυτές είναι οι πρώτες εντυπώσεις/σκέψεις μου για την HTML και όλα τα άλλα ωραία καλούδια που έρχονται μαζί της. Έχετε στο μυαλό σας πως  υπολογίζουν πως η HTML5 θα είναι 100% ολοκληρωμένη (σε browser επίπεδο τουλάχιστον) γύρω στο 2020 (!!!) ωστόσο δεν χάνουμε τίποτα με το να χρησιμοποιούμε και να μαθαίνουμε τα νέα χαρακτηριστικά της. Πολλά από αυτά άλλωστε υποστηρίζονται και από τους σημερινούς μοντέρνους browsers ενώ λογικά με την έλευση του IE9 θα δούμε ακόμα πιο πολλές HTML5-based εφαρμογές. Μην φοβάστε λοιπόν να την χρησιμοποιήσετε εδώ και τώρα, απλή HTML είναι άλλωστε ;-) Τα υπόλοιπα τα λέμε στα σχόλια!

CSS frameworks : Αξίζουν ή όχι

| Filed under articles css opinions

Τώρα τελευταία τα CSS frameworks γίνονται όλο και περισσότερο της μόδας, με αρκετούς φανατικούς θαυμαστές αλλά και εξίσου φανατικούς επικριτές. Προσωπικά δεν είμαι και πολύ fun των περισσότερων framework (εξηγώ παρακάτω το γιατί), ωστόσο κατά καιρούς έχω χρησιμοποιήσει και μάλιστα με μεγάλη επιτυχία κάποια από αυτά. Στο παρακάτω αρθράκι λοιπόν, εξηγώ ποια ιδέα κρύβεται πίσω από τα framework, τα πλεονεκτήματα και μειονεκτήματα τους και τέλος ποια ξεχωρίζω και γιατί.

Η ιδέα πίσω από τα CSS frameworks είναι πως σε κάθε site/project που αναλαμβάνουμε, χρησιμοποιούμε πολλά κοινά στοιχεία, όπως για παράδειγμα το κλασικό CSS reset file (πάντα του Eric Meyer), κάποια default styles για τα σημαντικότερα elements (όπως headings, tables, φόρμες κτλ.), κάποια styles μόνο για print, ενώ πολλοί πάνε τα πράγματα ακόμα παραπέρα, χρησιμοποιώντας styles για να καθορίσουν την διάταξη του site (columns και rows), να χρησιμοποιήσουν εφέ στις λίστες/μενού τους, και πολλά άλλα. Η ιδέα λοιπόν που κρύβεται πίσω από ένα framework είναι πολύ απλή. Γιατί να ξαναγράφουμε όλους αυτούς τους κανόνες και κώδικα από την αρχή για κάθε site, όταν μπορούμε να τα γράψουμε μόνο μία φορά και να τα χρησιμοποιούμε ξανά και ξανά σε όλα μας τα project? Με τον παραπάνω τρόπο, θα γλιτώνουμε πολύ κόπο και χρόνο!

Φυσικά τα πράγματα δεν είναι και τόσο ρόδινα όπως ακούγονται. Και εγώ χρησιμοποιώ επαναλαμβανόμενο CSS κώδικα στα site μου, όμως προσπαθώ να αποφεύγω τα έτοιμα CSS frameworks, για τους παρακάτω λόγους :

  • Σε αναγκάζουν να χρησιμοποιείς κάποιο συγκεκριμένο, και πολλές φορές όχι semantic και accessible, στυλ στην markup, τις κλάσεις και τα id σου (πχ. class=”div-xyz”).
  • Συνήθως χρειάζεσαι πολύ λιγότερα πράγματα απ’ ότι σου προσφέρει ένα framework, με αποτέλεσμα να αναγκάζεις τον χρήστη να κατεβάζει άσκοπα κώδικα, που δεν χρησιμοποιεί!
  • Ακόμα και εάν είσαι έμπειρος στην CSS, αρκετά frameworks είναι πολύπλοκα στην εκμάθηση τους. Επίσης εάν δημιουργηθεί κάποιο πρόβλημα/bug είναι πολύ πιο δύσκολο να εντοπίσεις τι φταίει.

Από εκεί και πέρα δέχομαι πως τα CSS frameworks σου προσφέρουν αρκετά πράγματα σχετικά εύκολα και γρήγορα, μιας και δεν κάθεσαι να γράψεις από την αρχή όλους τους CSS κανόνες, ενώ τα περισσότερα υποστηρίζουν αμέσως τους περισσότερους browsers που υπάρχουν. Για όσους θέλουν να ρίξουν μια ματιά σε αυτά, η παρακάτω λίστα αναφέρει όλα τα frameworks που υπάρχουν διαθέσιμα αυτήν την στιγμή (αναφέρομαι στα γνωστά και αυτά που μπορεί να χρησιμοποιήσει κάποιος εδώ και τώρα, και όχι σε αυτά που είναι υπό development ή που βρίσκονται σε beta στάδιο).

Όπως ανέφερα και παραπάνω λοιπόν, έχω δοκιμάσει τα περισσότερα από αυτά, και λογικό είναι να έχω ξεχωρίσει κάποια από αυτά. Γενικότερα, απορρίπτω αμέσως 2 κατηγορίες framework. Αυτά που είναι πολύ μεγάλα σε μέγεθος και κώδικα, με αποτέλεσμα να αναγκάζουν τον χρήστη να περιμένει να φορτωθούν χίλια-δυο άχρηστα πράγματα, και σε αυτά που σε αναγκάζουν να χρησιμοποιείς non-semantic markup, κλάσεις και ids στον κώδικα σου. Με το παραπάνω σκεπτικό λοιπόν, έχω απορρίψει πολλά διάσημα frameworks, όπως YUI Grids CSS, 960, YAML, και πολλά άλλα, ενώ αντιθέτως έχω χρησιμοποιήσει αρκετές φορές το Boilerplate το οποίο δεν αντιμετωπίζει τα παραπάνω προβλήματα, ενώ το σκεπτικό του βασίζεται στην απλότητα τόσο του κώδικα του, όσο και της λειτουργίας του.

To Boilerplate λοιπόν είναι ένα πολύ απλό framework, το οποίο δεν περιέχει περίεργες κλάσεις και ids, αλλά προσφέρει μια πολύ ολοκληρωμένη βάση για τον CSS κώδικα σας. Έτσι κάθε φορά που το χρησιμοποιήτε σε κάποιο project, έχετε τον βασικό CSS κορμό έτοιμο, όπως για παράδειγμα ένα reset file, default styles για όλα τα elements (headings, παραγράφους, λίστες, κτλ.), ένα βασικό print-only style και κάποιες πάρα πολύ βασικές κλάσεις. Το δεύτερο χαρακτηριστικό που μου αρέσει στο συγκεκριμένο framework, είναι πως έχει χωρισμένα τα CSS αρχεία με έξυπνο τρόπο, όπως για παράδειγμα ένα αρχείο για την τυπογραφία (typography.css), άλλο για τις φόρμες (forms.css), άλλο για το UI της οθόνης (screen.css) κτλ., οργανώνοντας έτσι προκαταβολικά τον κώδικα σας! Από εκεί και πέρα, ότι extra θέλετε, το γράφεται μόνοι σας! Προσωπικά με έχει κερδίσει αυτή η μινιμαλιστική προσέγγιση που έχει, γιατί μέσα σε πολύ λίγη ώρα μπορώ να στίσω τον βασικό κορμό CSS ενός project, ενώ ταυτόχρονα για οτιδήποτε θέλω να προσθέσω ή να αλλάξω, γίνεται πολύ εύκολα και γρήγορα λόγο της έξυπνης κατηγοριοποίησης και ονοματολογίας των αρχείων του.

Αυτά τα λίγα λοιπόν για τα CSS Frameworks. Γενικότερα δοκιμάστε όσα περισσότερα γίνεται (όπως βλέπεται είναι πάρα πολλά) και προσπαθείστε να βρείτε αυτό που σας ταιριάζει! Εάν ξέχασα κάποιο framework που χρησιμοποιείτε ή που νομίζεται πως αξήζει να αναφερθεί, αφήστε μου ένα σχόλιο, για το κοιτάξω κι αυτό…

Accessibility test σε 10′ λεπτά

| Filed under accessibility and usability articles

Είναι άπειρες οι φορές όπου φίλοι, γνωστοί ή ακόμα και άγνωστοι ζητάνε την γνώμη μου για το πόσο προσβάσιμο (accessible) είναι site τους. Οι περισσότεροι έχουν την αίσθηση πως εμείς (οι web designers/developers) είμαστε μάγοι ή έχουμε πολύ εξειδικευμένο εξοπλισμό και software για να κάνουμε κάτι τέτοιο. Στην πραγματικότητα το μόνο που χρειάζεται κάποιος, είναι ένας σύγχρονος browser (κατά προτίμηση Firefox με το web developer toolbar) και κάποιες εναλλακτικές ρυθμίσεις, έτσι ώστε να εντοπίσει γρήγορα τα διάφορα accessibility προβλήματα που πιθανόν να υπάρχουν. Στο παρακάτω post λοιπόν περιγράφω πολύ συνοπτικά πως μπορεί κάποιος, να κάνει ένα αξιόλογο web accessibility τεστ μέσα σε 10 μόλις λεπτά (όχι δεν σας κοροϊδεύω!). Για να μπορεί το post να διαβαστεί από όλους (και όχι μόνο από ειδικούς του χώρου), θα παρακάμψω την πολύ θεωρία πίσω από κάθε test, και θα εστιάσω την προσοχή στα παραδείγματα. Έχουμε και λέμε λοιπόν :

Απενεργοποιήστε τα images και δείτε πως φαίνεται το site σας χωρίς αυτά

Προσπαθείστε το site σας να δείχνει αξιοπρεπέστατο ακόμα και εάν δεν έχουν φορτωθεί τα γραφικά του (είτε γιατί ο χρήστης τα έχει απενεργοποιήσει, είτε επειδή κάποιο πρόβλημα στον server δεν τα αφήνει να κατέβουν, είτε επειδή ο χρήστης δεν έχει καλό bandwidth, κτλ.). Όποιος και να είναι ο λόγος το site σας θα πρέπει να δείχνει σωστά και χωρίς γραφικά. Απλό και κατανοητό νομίζω, και για τον λόγο αυτό δεν θα μακρηγορήσω περισσότερο, αλλά θα περάσω κατευθείαν σε 2 παραδείγματα.

Στο παρακάτω παράδειγμα λοιπόν, το blog του Γιάννη δεν “αλλοιώνεται” ούτε “χαλάει” όταν του απενεργοποιήσουμε τα images. Επίσης χρησιμοποιεί σωστά το alternative text περιγράφοντας τα γραφικά που δεν εμφανίζονται…

Porcupine blog - images on

Porcupine blog - images off

Αντιθέτως, το site Avopolis, δείχνει αρκετά άσχημο όταν απενεργοποιούμε τα images. Το χειρότερο από όλα είναι πως το κεντρικό μενού του site εξαφανίζετε, μιας και είναι όλο φτιαγμένο σε ένα image map!

Avopolis site - images on

Avopolis site - images off

Απενεργοποιείστε την Javascript

Ο κανόνας που ισχύει είναι αρκετά απλός : Δεν πρέπει να θεωρούμε πως ο χρήστης του site μας έχει την Javascript ενεργοποιημένη!

Στο blog το οποίο βρίσκεστε εάν απενεργοποιείστε την Javascript (η οποία χρησιμοποιείτε στην sidabar για τα διάφορα AJAX-like εφεδάκια), δεν θα χάσετε τίποτα από το περιεχόμενο του blog! Η τεχνική αυτή ονομάζεται Progressive enhancement, και το σκεπτικό πίσω από την τεχνική, είναι πως το site πρέπει να γίνεται σταδιακά πιο δυναμικό (interactive). Έτσι πρέπει πρώτα να έχουμε ένα καθαρό, σωστά δομημένο και σημασιολογικό (semantic) document (ή αλλιώς markup), μετά να τo εμπλουτίζουμε και να το παρουσιάσουμε κατάλληλα με τους ανάλογους styling κανόνες (CSS) και τέλος ότι extra interactivity θα θέλαμε να υπάρχει να κατασκευαστεί με σωστή χρήση της Javascript.

Tsevdos.com - Javascript on

Tsevdos.com - Javascript off

Αντίθετα στο site του Pop+Rock εάν δεν έχετε την Javascript ενεργοποιήμένη δεν δουλεύει το κεντρικό μενού του site! Το συγκεκριμένο λάθος προκαλεί και πολλά SEO προβλήματα που έχω αναφέρει σε παλιότερο post (Ποτέ μην χρησιμοποιείτε μενού φτιαγμένα από Flash ή Javascript).

Pop+Rock - Javascript on

Pop+Rock - Javascript off

Απενεργοποιείστε την CSS

Με αυτόν τον τρόπο θα καταλάβενετε πως φαίνεται πραγματικά το document σας, τόσο στους text-only browsers και στους screen readers, όσο και στα bots των μηχανών αναζήτησης! H παρακάτω εικόνα παρουσιάζει το blog μου, χωρίς καθόλου styles. Όπως παρατηρείτε, το document δεν έχει χάσει απολύτως τίποτα ούτε σε περιεχόμενο ούτε σε δομή, ενώ συνεχίζει να είναι προσβάσιμο σε όλους! Το μόνο που έχει χάσει είναι τα styles του, τα οποία του δίνουν την τελική μορφή του…

Tsevdos.com - CSS off

Αυξήστε το text-size από τον browser σας

Απλό αλλά σημαντικό τεστ. Απλά αυξήστε το text-size στον browser σας τουλάχιστον δύο φορές (πατώντας Ctrl + +). Εάν το site δεν αλλοιώνεται πολύ και γενικότερα το αποτέλεσμα είναι ικανοποιητικό τότε δεν υπάρχει κανένα πρόβλημα. Εάν το site παραμορφώνεται αρκετά, χάνεται κείμενο πίσω από άλλα elements, κτλ., τότε θα πρέπει να ξανασκεφτούμε κάποιες αποφάσεις που πήραμε κατά την δημιουργία του design μας…

Κάντε validate τον κώδικα σας

Σαν τελικό τεστ, και γενικότερα όποτε τελειώνετε κάποιο site ή template, όσο μεγάλο ή μικρό και να είναι, κάντε μια επίσκεψη στους (X)HTML και CSS validators, και διορθώστε τα προβλήματα που μπορεί να εμφανιστούν κατά το validation… Όσο πιο γρήγορα αποφασίσετε να το κάνετε, τόσο πιο εύκολα και γρήγορα θα επιλύσετε αυτά τα προβλήματα! Και μην ξεχνάτε, valid κώδικας σημαίνει πιο σταθερά και ποιοτικά site, τα οποία θα αντέχουν στον χρόνο!

Η παραπάνω διαδικασία θα σας βοηθήσει να εντοπίσετε πάρα πολύ γρήγορα σχεδόν όλα accessibility προβλήματα που μπορεί να έχει το site σας! Καθόλου άσχημα δηλαδή για τα μόλις 10 λεπτά χρόνου που θα ξοδέψετε! Από εκεί και πέρα μένει να επιλύσετε τα προβλήματα που εντοπίσατε, όπου φυσικά είναι και το δύσκολο αλλά απαραίτητο βήμα έτσι ώστε να κάνετε προσβάσιμο (accessible) το site σας. Ελπίζω τα παραδείγματα οπού ανέφερα να ήταν σαφή και κατανοητά, μιας και ο ελληνικός κυβερνοχώρος χρειάζεται αρκετή δουλειά ακόμα στο θέμα accessibility… Μείνετε συντονισμένοι λοιπόν για να κάνουμε το internet μια πιο σταθερή και λειτουργική πλατφόρμα!

Styling comments : Tsevdos.com way

| Filed under articles tutorials

Είχα υποσχεθεί πως θα παρουσιάσω μερικά features του νέου μου theme για τα οποία αισθάνομαι περήφανος, όχι επειδή είναι πολύπλοκα, αλλά ακριβώς επειδή δεν είναι ;-) . Μάλλον μπέρδεψα αρκετούς ήδη, οπότε ας ρίξουμε μια ματιά στα σχόλια/comments του blog που διαβάζεται, αλλά και τους στόχους που ήθελα να πετύχω.

Τα σχόλια/comments στο blog μου λοιπόν, ήθελα να είναι απλά, μινιμαλιστικά (όπως και το υπόλοιπο design άλλωστε), ευανάγνωστα και σημασιολογικά σωστά! Ας ξεκινήσουμε από το τελευταίο λοιπόν, το οποίο έχει να κάνει μόνο με την ταπεινή μας markup (XHTML). Για να βάλουμε τα πράγματα σε μία σειρά λοιπόν, τα σχόλια δεν είναι τίποτα παραπάνω από μια (μεγάλη πολλές φορές) λίστα. Επειδή η συγκεκριμένη λίστα λοιπόν, έχει και κάποια σειρά (1ο σχόλιο, 2ο σχόλιο, κτλ.), αποφάσισα να χρησιμοποιήσω σαν βάση της markup μια αριθμημένη λίστα (ή αλλιώς ordered list)! Από εκεί και πέρα το κάθε στοιχείο της λίστας (list item) μπορεί να χωριστεί σε περαιτέρω κομμάτια όπως το όνομα του σχολιαστή, το κείμενο/σχόλιο του καθώς και οποιαδήποτε extra πληροφορία θέλουμε να συμπεριλάβουμε, όπως πχ. ημερομηνία και ώρα. Στο παρακάτω markup snippet λοιπόν, μπορείτε να δείτε την λίστα των σχολίων/comments σε όλο της το μεγαλείο! Όπως βλέπετε το κάθε list item είναι και ένα σχόλιο, ενώ μέσα σε αυτό υπάρχουν divisions (divs) με συγκεκριμένες κλάσεις (classes), για τον σχολιαστή (author_meta), το κείμενο του σχολίου (comment_body) καθώς και κάποιες extra πληροφορίες για το σχόλιο όπως ημερομηνία και ώρα ανάρτησης του (comment_meta). Τέλος, όλα αυτά είναι τοποθετημένα μέσα σε ένα div με το γενικό id “comments”.

  1. Comment body goes here.
  2. Comment body goes here.

Εφόσον λοιπόν έχουμε την βάση μας (markup) έτοιμη και σημασιολογικά σωστή, θα προσπαθήσουμε να παρουσιάσουμε το περιεχόμενο της όσο καλύτερα γίνεται, έτσι ώστε να ταιριάζει με το υπάρχον design μας, αλλά και χωρίς να αναγκαστούμε να χαλάσουμε την markup μας για χάρη του design… Έτσι με μερικούς απλούς και κατανοητούς CSS κανόνες, μπορούμε πολύ εύκολα να πετύχουμε τον στόχο μας.


a { font-size: 0.8em; font-family: Tahoma, Verdana,  sans-serif; }
a:link { color: #2EA0C6; }
a:visited { color: #7d7f81; text-decoration: underline; }
a:hover, a:active { color: #ff6d1e; text-decoration: none; }

#comments {
margin: 2em 1em 1em;
}

#comments ol {
padding: 0;
list-style-type: none;
}

#comments ol li {
margin: 1em 0 0;
padding: 1em;
list-style-type: none;
border: 1px solid #ccc;
}

#comments ol li:hover {
border: 1px solid #333;
}

#comments ol li.alt {
background: #f0f0f0;
}

#comments ol li .author_meta {
font-size: 1.1em;
font-weight: bold;
}

#comments ol li .comment_body {
clear: right;
}

#comments ol li .comment_meta {
text-align: right;
}

Ο CSS κώδικας που μόλις παρουσίασα είναι πανεύκολος, ωστόσο θα ήθελα να σταθώ σε 2 σημεία.

  • Το πρώτο είναι το hover state του list item (#comments ol li:hover). Όπως ξέρουμε τα επήσιμα standards διατυπώνουν πως οποιοδήποτε element μπορεί να έχει hover state (και γενικότερα οποιαδήποτε ψευδό-κλάση), ωστόσο ο Internet Explorer 6 (και οι παλιότερες εκδόσεις του), υποστηρίζουν την συγκεκριμένη ψευδό-κλάση μόνο στα anchor (a) elements. Το εφέ μας λοιπόν θα παίξει σε όλους τους browsers κανονικά, εκτός από τον ΙΕ6 και τις παλιότερες εκδόσεις του, κάτι που προσωπικά δεν με ενοχλεί και τόσο, μιας και οι συγκεκριμένοι χρήστες το μόνο που θα χάσουν είναι ένα απλό εφεδάκι και τίποτα παραπάνω.
  • Το δεύτερο σημείο που θέλω να εστιάσω λίγο την προσοχή σας, είναι η κλάση alt (#comments ol li.alt) η οποία δίνει σε κάθε δεύτερο list item ένα διαφορετικό background color. Την συγκεκριμένη κλάση την προσθέτει εύκολα το WordPress, ωστόσο είναι πολύ εύκολο να κάνετε το ίδιο με οποιαδήποτε πλατφόρμα αλλά και server-side τεχνολογία.

Όπως μπορείτε να δείτε και από το παρακάτω screenshot, η λίστα με τα comments μας δεν είναι καθόλου άσχημη για τον κώδικα που γράψαμε, ωστόσο κάτι της λείπει…

comments screenshot 1

Αυτό που έχασε η λίστα μας κατά το styling, ήταν η αριθμητική αίσθηση των comments (list-style-type: none;), κάτι που θα αρέσει σε πολλούς, ωστόσο προσωπικά θα ήθελα να δημιουργήσω κάτι ανάλογο. Γι’ αυτόν ακριβώς τον λόγο θα χρησιμοποιήσω το jQuery, την αγαπημένη μου Javascript library, έτσι ώστε να δώσω πίσω στην λίστα των comments μας αυτό που έχασε, την αριθμητική συνέχεια! Φορτώνουμε λοιπόν το jQuery (σημείωση στο παράδειγμα μας χρησιμοποιώ την έκδοση 1.2.6, ωστόσο δεν θα έχετε πρόβλημα ούτε με παλιότερες, ούτε με νεότερες εκδόσεις του) στην σελίδα μας και ξεκινάμε!




Ο παραπάνω Javascript κώδικας (λέμε τώρα), αν και θα παραξενέψει ακόμα και έμπειρους developers της Javascript στην πραγματικότητα είναι πανεύκολος, αρκεί να καταλάβεται λίγο πως λειτουργεί το jQuery. Όλος ο κώδικας του jQuery λοιπόν ξεκινάει όταν το DOM (Document Object Model) της web σελίδας μας είναι έτοιμο :


$(document).ready(function (){
//code goes here...
});

Μόλις ο browser φορτώσει όλο το DOM λοιπόν, πολύ απλά επιλέγω όλα τα list items ($(‘#comments ol li’).each) και εκτελώ σε όλα, μία function. Αρχικά αυξάνω τον counter με το όνομα i (i++;) έτσι ώστε το πρώτο list item να έχει τον αριθμό 1, το δεύτερο τον αριθμό 2 κοκ., και στην συνέχεια δημιουργώ μία variable με το όνομα node, η οποία είναι ένα απλό string το οποίο περιέχει HTML κώδικα, και πιο συγκεκριμένα περιέχει τον αριθμό του counter μέσα σε ένα span element με την κλάση (class) “comment_number”. Τέλος και με την βοήθεια του jQuery απλά προσθέτω το node που μόλις δημιουργήσα στην αρχή κάθε list item.


i++;
var node = '' + i + '<\/span>';
$(this).prepend(node);

Αυτές οι 3 γραμμές κώδικα θα αναλάβουν να ζωντανέψουν κι άλλο την λίστα μας! Η συγκεκριμένη web τεχνική ονομάζεται DOM injection, μιας και το νέο element που προσθέσαμε στην σελίδα μας, δεν υπάρχει πουθενά στην markup μας, αλλά το προσθέσαμε με την βοήθεια της Javascript και του DOM (DOM scripting).

Styling comments screenshot 2

Σαν τελική πινελιά, απλά θα δώσουμε κάποιους styling κανόνες και στα nodes που μόλις προσθέσαμε έτσι ώστε να δείχνουν και αυτά όμορφα, όπως η υπόλοιπη λίστα μας.


#comments ol li .comment_number {
color: #ccc;
font-size: 2.5em;
font-weight: bold;
line-height: 1em;
float: right;
}

#comments ol li.alt .comment_number {
color: #fff;
}

Το τελικό αποτέλεσμα μπορείτε να το δείτε παρακάτω, ενώ φυσικά υπάρχει διαθέσιμος και ολόκληρος ο κώδικας (γι’ αυτούς που βαριούνται να τον γράφουν από την αρχή)! Μην ξεχάσετε μόνο να κατεβάσετε το jQuery και να το προσθέσετε στον παρακάτω κώδικα (line 06).

Styling comments screenshot 3












  1. Comment body goes here.
  2. Comment body goes here.
  3. Comment body goes here.
  4. Comment body goes here.

Όπως είδατε, τα comments στο blog μου δεν κάνουν χρήση μαγικών ή περίεργων τεχνολογιών, αλλά αντίθετα είναι ένας απλός συνδυασμός markup, CSS και Javascript. Τώρα θα με ρωτήσει κάποιος, γιατί είμαι περήφανος για το συγκεκριμένο κομμάτι του blog και γιατί διάλεξα να παρουσιάσω αυτό και όχι κάτι πιο πολύπλοκο. Η απάντηση, είναι πως ο παραπάνω κώδικας είναι σημασιολογικά σωστός, δηλαδή κάνει χρήση των σωστών markup tags καθώς επίσης χρησιμοποιεί σωστά ονόματα στα ids και τις κλάσεις (classes) που περιέχει, ενώ ταυτόχρονα κάνει και χρήση της τεχνικής progressive enhancement. Το τελευταίο, με απλά λόγια σημαίνει πως το περιεχόμενο είναι προσβάσιμο από όλους χρήστες με οποιονδήποτε browser, screen reader, κτλ., ενώ όσο πιο προηγμένο browser έχει στην διάθεση του ο χρήστης, τόσο πιο όμορφο θα είναι το τελικό αποτέλεσμα. Έτσι κάποιος χρήστης με screen reader ή text-only browser θα διαβάσει μια καθαρή και κατανοητή λίστα η οποία βγάζει νόημα, κάποιος χρήστης με επιπλέον δυνατότητα stylesheets θα δει ένα όμορφο αποτέλεσμα στον browser του (και όσο πιο σύγχρονο browser έχει, τόσο πιο πολλά style-based εφέ θα δει), ενώ τέλος εάν υπάρχει και η Javascript διαθέσιμη στην μηχανή rendering, ο χρήστης θα καταφέρει να δει και τον αριθμό του κάθε σχολίου που υπάρχει! Όλοι θα είναι χαρούμενοι και το σημαντικότερο φυσικά είναι πως όλοι θα έχουν πρόσβαση στο περιεχόμενο των comments!

Ελπίζω να εξήγησα καλά τόσο το παραπάνω (απλό?) παράδειγμα όσο και την θεωρεία που κρύβεται πίσω από κάθε επιλογή που έκανα. Καθημερινά ο κάθε web designer πρέπει να πάρει άπειρες τέτοιες αποφάσεις, και πραγματικά στην αρχή είναι πολύ δύσκολο να ξεχωρίσεις τι είναι σωστό και τι όχι, αλλά και να εξηγήσεις σε κάποιον γιατί επέλεξες την συγκεκριμένη λύση έναντι κάποιας άλλης. Σιγά-σιγά όμως τα πράγματα ξεκαθαρίζουν, και η παραπάνω διαδικασία γίνεται δεύτερη φύση! Όσοι θέλετε και άλλα ανάλογα παραδείγματα απλά μείνετε συντονισμένοι και δεν θα χάσετε ;-) .

Update : Το τελικό αποτέλεσμα μπορείτε να το δείτε ζωντανά εδώ.

Πως να κάνετε το site σας πιο γρήγορο : Ο απόλυτος οδηγός για site optimization

| Filed under articles

Από καιρό ήθελα να γράψω αυτό το αρθράκι, απλά ήθελα να κάνω περισσότερο και καλύτερο research πάνω στο θέμα, έτσι ώστε να δοκιμάσω περισσότερα εργαλεία και να συστήσω μόνο τα καλύτερα! Ας ξεκινήσουμε όμως από τα βασικά και να πάρουμε τα πράγματα από την αρχή… Όταν γράφουμε ένα URL στον browser μας έτσι ώστε να επισκεφθούμε κάποια σελίδα, αυτός συλλέγει πολλές πληροφορίες και εκτελεί διάφορες εργασίες πριν εμείς δούμε την τελική σελίδα (document). Φυσικά όσο πιο γρήγορη είναι η σύνδεση μας (σε επίπεδο download, μιας και το upload είναι ένα απλό http request) τόσο πιο γρήγορα ο browser θα καταφέρει να συλλέξει και να εκτελέσει τις εργασίες που θα αναλύσουμε πιο κάτω. Σε αυτό το σημείο πολλοί web experts δεν δίνουν την απαιτούμενη σημασία μιας και υποστηρίζουν πως οι γρήγορες συνδέσεις βρίσκονται παντού – πλέον και στην Ελλάδα – ωστόσο αυτό δεν σημαίνει πως δεν μπορούμε να κάνουμε κάτι καλό ακόμα καλύτερο ή στην περίπτωση μας κάτι γρήγορο ακόμα πιο γρήγορο! Τα δύο πολύ απλά επιχειρήματα που δίνω σε όσους μου προβάλουν το γρήγορο internet σαν δικαιολογία, είναι τα εξής :

  • Το να κάνεις ένα site να φορτώνει ακόμα πιο γρήγορα, χωρίς να του αλλάξεις τίποτα εμφανισιακά, δεν βλάπτει κανέναν (ούτε τους χρήστες με αργές, ούτε αυτούς με γρήγορες συνδέσεις)
  • Ξοδεύεις λιγότερα λεφτά σε web hosting μιας και αυτό που πληρώνεις (ακριβά) πλέον στο hosting είναι το transfered bandwidth, και όχι τα GB χώρου που χρησιμοποιείς (όπως ίσχυε κάποτε). Σε αυτό το επιχείρημα δείχνουν ακόμα περισσότερη προσοχή για κάποιο λόγο!

Ας εξηγήσουμε τώρα πως μπορούμε να κάνουμε το site μας πιο γρήγορο. Η πρώτη απάντηση σε αυτό το ερώτημα είναι η ελαχιστοποίηση των request στον server. Κάθε image, script, css αρχείο και γενικότερα όλα τα εξωτερικά αρχεία (flash, video, κτλ.) απαιτούν από τον browser να κάνει, για το καθένα ξεχωριστά, ένα request στον web server, να το κατεβάσει και τελικά να ενώσει όλα τα κομμάτια του παζλ και να κάνει render την web σελίδα! Τώρα θα μου πουν πολλοί, και με το δίκιο τους, καλέ ρε φίλε, δηλαδή να σταματήσουμε να βάζουμε images, css και scripts στο site μας? Και βέβαια όχι, αντιθέτως οι μοντέρνες web design τεχνικές το επιβάλουν, απλά να γνωρίζουμε τι και για ποιον λόγο το κάνουμε. Επίσης οι μοντέρνοι browser έχουν πολύ καλές caching τεχνικές έτσι ώστε εάν ένα image, script, stylesheet, κτλ. χρησιμοποιείται σε παραπάνω από μια σελίδα, χρησιμοποιούν το αρχείο που έχουν ήδη κατεβάσει (πχ. εάν έχει ήδη κατεβάσει το stylesheet του μενού και τα γραφικά/images του interface, δεν τα ξανακατεβάζει ξανά από την αρχή, αλλά χρησιμοποιεί τα ήδη υπάρχοντα από την cache memory του). Τι μπορούμε να κάνουμε εμείς, οι web experts, επιπλέον όμως? Πρώτα απ’ όλα optimization (βελτιστοποίηση) στον κώδικα μας! Code Optimization μπορεί να γίνει και στις δύο μεριές (server-side και client-side), ωστόσο στο συγκεκριμένο post δεν θα ασχοληθώ με server-side optimization (ο φίλος lexx έχει γράψει ένα ανάλογο άρθρο πάνω στο θέμα όπου περιγράφει και server-side optimization), μιας και εκτός από ότι αλλάζει ανάλογα με την server-side τεχνολογία που χρησιμοποιείται (πχ. PHP, Ruby, κτλ.), πρέπει αυτός που θα αναλάβει την συγκεκριμένη εργασία, να είναι πολύ έμπειρος και να γνωρίζει πάρα πολύ καλά το πώς δουλεύει η συγκεκριμένη τεχνολογία, ο server που την φιλοξενεί αλλά και η βάση δεδομένων που την στηρίζει!

Ερχόμαστε λοιπόν στην client-side μεριά όπου μπορούμε να κάνουμε πολλά και ενδιαφέροντα πράγματα… Πρώτα απ’ όλα μπορούμε να ελαχιστοποιήσουμε τα requests των style μας χρησιμοποιώντας όσο των δυνατών λιγότερα CSS αρχεία γίνεται, όπως για παράδειγμα ένα κεντρικό αρχείο που θα περιλαμβάνει όλα τα style μας, ή έστω 2 – 3 εάν υπάρχουν και styles μόνο για τον IE, για print, κτλ. Αυτό με ακόμα πιο απλά λόγια σημαίνει πως καλό θα είναι να περιορίσουμε στο ελάχιστο τα stylesheet που κάνουμε link στην markup μας χρησιμοποιώντας το

<link rel="stylesheet" href="stylesheets/screen.css" type="text/css" media="screen" charset="utf-8">

αλλά και στα ίδια τα styles χρησιμοποιώντας τον

@import "styles/typography.css";

κανόνα.

Οι ακόμα πιο σκληροπυρηνικοί μπορούν να χρησιμοποιήσουν και κάποιον από τους παρακάτω CSS optimizers, έτσι ώστε να συμπιέσουν τους CSS κανόνες τους ακόμα περισσότερο!

Από κάποια γρήγορα τεστ προτείνω τον πρώτο optimizer, μιας και σε μερικές περιπτώσεις μείωσε το file size των CSS αρχείων έως και 50% (!!!), ωστόσο αυτό το ποσοστό αλλάζει ανάλογα με το στυλ του κώδικα που γράφεται αλλά και με το πόσο επαναλαμβάνεστε στους CSS κανόνες σας. Όπως και να έχει ρίξτε τους μια ματιά. Σε αυτό το σημείο να σημειώσω πως χρησιμοποιώντας κάποιον CSS optimizer δεν θυσιάζουμε τίποτα, πέρα από την ευαναγνωστηκότητα (readability) του κώδικα σας.

Οι τεχνικές που ανέφερα στα CSS αρχεία, μπορούν να εφαρμοστούν και στα Javascript αρχεία μας! Περιορίζουμε δηλαδή τα πολλά requests κρατώντας σε όσο λιγότερα Javascript αρχεία γίνεται όλον τον Javascript κώδικα μας. Φυσικά εάν χρησιμοποιούμε κάποια Javascript library (όπως jQuery για παράδειγμα) linkάρουμε πάντα την compressed version της ενώ μπορούμε να κάνουμε optimized και τον δικό μας Javascript κώδικα, χρησιμοποιώντας κάποιον από τους παρακάτω Javascript optimizers.

Σε αυτό το σημείο θα ήθελα να σημειώσω πως όποιος ασχοληθεί με Javascript code optimization, πρέπει να είναι πάρα πολύ έμπειρος και προσεκτικός, μιας και πολλά script δεν έπαιζαν σωστά σε κάποιους browsers μετά το optimization! Εάν θα έπρεπε να διαλέξω κάποιον από τους παραπάνω optimizers, θα διάλεγα τον JSMin, του Douglas Crockford από το Yahoo!, ο οποίος απλά αφαιρεί το extra whitespace και τα comments αφήνοντας τα υπόλοιπα κομμάτια του κώδικα ανέπαφα.

Φυσικά για λόγους maintaining (συντήρησης) θα πρέπει να κρατάμε backup όλων των style και javascript αρχείων μας έτσι ώστε να μπορούμε εύκολα και γρήγορα να διαβάζουμε, ανανεώνουμε και γενικότερα να συντηρούμε τον κώδικα μας, οπότε πρέπει οπωσδήποτε να κρατάτε τα source αρχεία σας ανέπαφα, και να εφαρμόζουμε όλα τα παραπάνω μόνο σε επίπεδο παραγωγής, δηλαδή σε site που βρίσκονται στον αέρα (web server μας)!

Τέλος, εκτός από optimization στον CSS και Javascript κώδικα μας, μπορούμε χρησιμοποιήσουμε και HTTP Compression στον server μας, έτσι ώστε να κάνουμε το site μας ακόμα πιο γρήγορο! Η συγκεκριμένη τεχνική γίνεται σε επίπεδο web server (όπως πχ. Apache, IIS, κτλ.), όπου ο server κάνει compress τα δεδομένα (data) που στέλνει μέσω του HTTP πρωτοκόλλου. Έτσι εάν ο browser που χρησιμοποιεί ο client (χρήστης) επιτρέπει την συγκεκριμένη δυνατότητα – όλοι οι μοντέρνοι browsers μπορούν – ο server στέλνει τα δεδομένα συμπιεσμένα (συνήθως με το gzip), ενώ εάν ο client χρησιμοποιεί κάποιον παλιότερο σε browser ο οποίος δεν υποστηρίζει HTTP Compression, ο χρήστης λαμβάνει την κανονική μη συμπιεσμένη (uncompressed) version της σελίδας. Με την συγκεκριμένη τεχνική δεν πρόκειται να δημιουργήθει κανένα πρόβλημα ούτε στους παλιούς ούτε στους καινούργιους browsers, αφού οι χρήστες με καινούργιους browsers θα μπορούν να κατεβάζουν τις σελίδες έως και 40% γρηγορότερα, χωρίς να απορρίπτονται οι χρήστες με τους παλιότερους browsers, οι οποίοι θα συνεχίσουν να κατεβάζουν κανονικά (χωρίς compression) τις σελίδες σας!

Η τελευταία τεχνική ανήκει θεωρητικά στην server-side κατηγορία, μιας και γίνεται στον web server, ωστόσο επειδή είναι πολύ εύκολη στην υλοποίηση της (εάν έχουμε πρόσβαση στον server φυσικά), την αναφέρω σε αυτό το post. Όπως προανέφερα δεν επηρεάζει καθόλου την συμπεριφορά της client-side μεριάς (οι browser που υποστηρίζουν HTTP compression θα το χρησιμοποιούσουν, ενώ οι υπόλοιποι απλά θα το αγνοήσουν) ενώ η βελτίωση που βλέπουμε στην ταχύτητα φόρτωσης μιας σελίδας (document) είναι εμφανής!

Με τεχνικές που ανέφερα παραπάνω και φυσικά με τις κατάλληλες μοντέρνες και σύγχρονες web design τεχνικές μπορούμε να κάνουμε τα site μας να φορτώνουν πάρα μα πάρα πολύ πιο γρήγορα από το συνηθισμένο, και μάλιστα χωρίς να αλλάξουμε κάτι εμφανισιακά! Κανείς δεν θέλει να περιμένει μέχρι να φορτώσει η σελίδα που τον ενδιαφέρει, ενώ είναι γεγονός πως το αργό φόρτωμα των σελίδων είναι ο νούμερο ένα λόγος που κάνει τους χρήστες να εγκαταλείπουν κάποιο site! Οι παραπάνω τεχνικές είναι εύκολα υλοποιήσιμες ενώ όλα τα εργαλεία που περιγράφω προσφέρονται δωρεάν, οπότε δεν υπάρχει κάποια σοβαρή δικαιολογία στο να μην κάνετε το γρήγορο site σας ακόμα πιο γρήγορο!

Blogging και στατιστικά : Πώς να τα εκμεταλλευθείτε

| Filed under articles blogging tips

Πολλοί bloggers έχουν αλλεργία με τα στατιστικά (εγώ πάλι είμαι λίγο statistics junky), ωστόσο καλό θα είναι να τους ρίχνουμε και καμιά ματιά που και που, μιας και μπορούν να μας βοηθήσουν να πάρουμε καλύτερες και σωστότερες αποφάσεις για το blog μας. Οι δύο πιο διάσημες υπηρεσίες οι οποίες μπορούν να χρησιμοποιηθούν σε οποιοδήποτε site ή blog γι αυτόν τον λόγο, παρέχονται δωρεάν από την Google και δεν είναι άλλες από το Google Analytics και το FeedBurner (το οποίο και αγόρασε σχετικά πρόσφατα). Αφού λοιπόν τα πάντα παρέχονται δωρεάν, την στιγμή μάλιστα που άλλες εταιρείες χρεώνουν αρκετά δολάρια για τις ίδιες υπηρεσίες, γιατί να μην τις χρησιμοποιήσει κάποιος;

Από τις δύο παραπάνω must υπηρεσίες στατιστικών θα ξεκινήσω με το Google Analytics, το οποίο θα είναι η πιο κοινότυπη λύση για τους περισσότερους. Το Google Analytics δημιουργεί στατιστικά στοιχεία για διάφορα χαρακτηριστικά που έχει κάθε blog/site, όπως επισκέπτες (visitors), περιεχόμενο (content), traffic και traffic sources, τεχνολογικά στατιστικά και πολλά άλλα! Αφού λοιπόν ενεργοποιήσουμε έναν (δωρεάν) Google Analytics λογαριασμό το μόνο που έχουμε να κάνουμε είναι να δηλώσουμε τα URLs των blog/site μας, και να περάσουμε ένα javascript κώδικα που μας παρέχει το Analytics στο καθένα από αυτά. Αυτό είναι όλο το installation που πρέπει να γίνει, από εκεί και πέρα απλά περιμένουμε να δημιουργηθούν τα πρώτα στατιστικά μας! Τα στατιστικά στοιχεία που συλλέγει και αναλύει το Analytics για εμάς είναι αυτά που αναφέρω παραπάνω, καθώς και πολλά άλλα πιο εξειδικευμένα, τα οποία και θα αποφύγω να αναφέρω και να αναλύσω, μιας και παρά-είναι εξειδικευμένα. Οι τέσσερις μεγάλες κατηγορίες στατιστικών που πρέπει να προσέχει κάποιος, είναι οι επισκέπτες (visitors), το περιεχόμενο (content), το traffic και τα traffic sources, καθώς φυσικά και κάποια άλλα στατιστικά στοιχεία πιο τεχνολογικού ενδιαφέροντος… Παρακάτω αναλύω ποιες είναι οι πιο σημαντικές πληροφορίες από την κάθε κατηγορία και πως μπορούμε να βελτιώσουμε το blog μας “διαβάζοντας” τα στατιστικά της κάθε μιας!

Ας ξεκινήσουμε λοιπόν από τους επισκέπτες (visitors) του blog μας, μια σχετικά εύκολη και κατανοητή κατηγορία στατιστικών που μπορούμε να αντλήσουμε πολλές πληροφορίες για το blog μας. Σε αυτήν την κατηγορία στατιστικών μπορούμε :

  • Να δούμε πόσοι είναι οι επισκέπτες μας
  • Να δούμε που βρίσκονται γεωγραφικά
  • Να μετρήσουμε πόσα pageviews έχει το blog μας
  • Να δούμε πόσοι από τους χρήστες είναι καινούργιοι και πόσοι παλιοί χρήστες του blog μας
  • Να δούμε τι γλώσσα έχει ο browser που χρησιμοποιούν

Εξετάζοντας τα παραπάνω μπορούμε να πάρουμε καλύτερες αποφάσεις σε θέματα όπως :

  • Να προσπαθήσουμε να δημιουργήσουμε περιεχόμενο για κάποια συγκεκριμένη γεωγραφική περιοχή που βλέπουμε πως έχει έντονη κινητικότητα
  • Να εξετάσουμε εάν κερδίζουμε νέους χρήστες ή αν χάνουμε παλιούς και να προσπαθήσουμε να εντοπίσουμε τον λόγο για τον οποίο γίνεται κάτι τέτοιο
  • Να αποφασίσουμε εάν θα γράφουμε και σε κάποια άλλη γλώσσα (πχ. αγγλικά)

Tα στατιστικά τα οποία έχουν σχέση με το περιεχόμενο (content) του blog μας είναι εξίσου σημαντικά και οι πληροφορίες που μας δίνουν μπορούν να μας βοηθήσουν στο να καταλάβουμε καλύτερα που πρέπει να εστιάσει το blog μας από την μεριά του περιεχομένου μας. Τα πιο σημαντικά στατιστικά στην συγκεκριμένη κατηγορία είναι :

  • Ποιο είναι το περιεχόμενο με τα περισσότερα pageviews
  • Τι προτιμούν να διαβάζουν οι χρήστες μας
  • Ποιες είναι οι top landing και ποιες οι top exit pages (αυτές οι οποίες αποχωρούν οι χρήστες μας) του blog μας

Εξετάζοντας τα παραπάνω μπορούμε να πάρουμε καλύτερες αποφάσεις σε θέματα όπως :

  • Τι θέματα να συνεχίζουμε να γράφουμε και τι όχι (ανάλογα και με το θέμα του blog μας φυσικά)
  • Τι περιεχόμενο να προωθήσουμε ακόμα πιο πολύ (σε άλλα sites ή και στο δικό μας με ακόμα πιο σωστό SEO)
  • Αποφάσεις που έχουν να κάνουν με το navigation και το design του blog μας, όπως πχ. να προωθούμε σε post, post ανάλογης θεματολογίας, να χρησιμοποιούμε ή όχι read more links κτλ.

Τα στατιστικά τα οποία έχουν σχέση με το traffic, και γενικότερα με τα traffic sources του blog μας, είναι ίσως και τα πιο σημαντικά μιας και μας παραπέμπουν σε πληροφορίες για την διαδρομή που ακολούθησε ο χρήστης στο blog μας. Μερικά χρήσιμα στατιστικά που μπορούμε εύκολα να αναλύσουμε είναι :

  • Πόσοι χρήστες μπήκαν κατευθείαν στο site μας (χωρίς να πατήσουν κάποιο link δηλαδή)
  • Από ποιο blog/site ο χρήστης κατέληξε στο δικό μας (πατώντας κάποιο link)
  •  Πως κινήθηκε ο χρήστης στο blog μας
  • Ποιες λέξεις χρησιμοποιούν οι χρήστες μας στις μηχανές αναζήτησης για να ανακαλύψουν το blog μας
  • Πόση ώρα ξοδεύουν οι χρήστες στο blog μας
  • Σε ποιο site αποχώρισε ο χρήστης φεύγοντας από το δικό μας

Μελετώντας τα παραπάνω στοιχεία μπορούμε να να πάρουμε καλύτερες αποφάσεις σε θέματα όπως :

  • Σε ποια άλλα blog ή site να διαφημιστούμε, και με ποια να ανταλλάξουμε links (link exchange)
  • Να οργανώσουμε καλύτερα την SEO καμπάνια μας
  • Να δούμε ποια keywords χρησιμοποιούν στις αναζητήσεις τους οι χρήστες μας, και να προσπαθήσουμε να εστιάσουμε σε αυτά με ανάλογα posts

Τέλος τα στατιστικά τεχνολογικού ενδιαφέροντος μας παρουσιάζουν στοιχεία όπως :

  • Τι ανάλυση (screen resolution) χρησιμοποιούν οι χρήστες μας
  • Τι browsers και τι browser plug ins διαθέτουν
  • Τι λειτουργικά συστήματα χρησιμοποιούν
  • Πόσα χρώματα υποστηρίζει η οθόνη τους, κτλ.

Όπως είναι προφανές τα παραπάνω στατιστικά στοιχεία είναι φτιαγμένα για τους πιο έμπειρους bloggers, μπορούν ωστόσο να βοηθήσουν τον καθένα μας να πάρει αποφάσεις για :

  • Τι ανάλυση (screen resolution) να υποστηρίζει το blog
  • Ποιοι είναι οι browsers που πρέπει οπωσδήποτε να υποστηρίξουμε
  • Ποια plug ins μπορούμε να χρησιμοποιήσουμε αν και εφόσον το θέλουμε
  • Ποια λειτουργικά συστήματα πρέπει οπωσδήποτε να υποστηρίξουμε

Φυσικά όπως εύκολα μπορεί να καταλάβει κάποιος τα παραπάνω στατιστικά στοιχεία μιας κατηγορίας μπορούν να συνδυαστούν με αυτά κάποιας άλλης, έτσι ώστε να κάνουμε και ακόμα πιο περίπλοκες προβλέψεις. Για παράδειγμα, εάν έχουμε ένα τεχνολογικό blog το οποίο επισκέπτονται πάρα πολλοί χρήστες Linux, η πρόβλεψη του να δημιουργήσουμε περισσότερο περιεχόμενο (content) με θέμα το αντίστοιχο λειτουργικό είναι σωστή! Γενικότερα ο καθένας βγάζει τα συμπεράσματα του και τις προβλέψεις του μέσα από τα διάφορα στατιστικά, οπότε θα κλείσω σε αυτό το σημείο το θέμα Google Analytics.

To FeedBurner είναι η δεύτερη υπηρεσία στατιστικών της Google, η οποία αναλαμβάνει να συλλέξει στατιστικά στοιχεία τα οποία έχουν σχέση μόνο με τα feeds σας! Αν και λίγο πιο περίεργο στο installation του, κυρίως στους λιγότερο μυημένους χρήστες, είναι η καλύτερη λύση δημιουργίας στατιστικών αλλά και διαχείρισης (όπως θα δούμε παρακάτω) feeds. Το πρώτο πράγμα που πρέπει να κάνει κάποιος, μετά την δωρεάν δημιουργία λογαριασμού φυσικά, είναι να δηλώσει (η αλλιώς να “κάψει” – burn) το link του feed του (πχ. http://www.tsevdos.com/feed/rss2/), σε ένα FeedBurner feed, καθώς και να το ονομάσει όπως θέλει (πχ. RSS2feed). Το νέο feed που θα δημιουργήσει το FeedBurner θα έχει την μορφή “http://feeds.feedburner.com/RSS2feed”, και θα έχει σαν source το link που οδηγεί στο “κανονικό” feed που ορίσατε προηγουμένως (http://www.tsevdos.com/feed/rss2/). Από εκεί και πέρα απλά θα πρέπει να “μοιράζεται” από το blog σας, το feed που μόλις δημιουργήσατε στο FeedBurner, αντικαθιστώντας το default link του feed σας (πχ. http://www.tsevdos.com/feed/rss2/) με αυτό του FeedBurner (http://feeds.feedburner.com/RSS2feed). Έχετε υπόψη σας πως εάν το feed σας εμφανίζεται σε περισσότερα από ένα σημεία στο blog σας (πχ. στο δικό μου εκτός από το header section του blog μου εμφανίζεται και σε άλλα τρία σημεία, στην πάνω και κάτω navigation bar και στην κεντρική στήλη/column), θα πρέπει να αντικαταστήσετε και αυτά με το link του FeedBurner (http://feeds.feedburner.com/RSS2feed), γιατί πολύ απλά κάποιος χρήστης μπορεί να επιλέξει ένα από αυτά τα links για να εγγραφεί στο feed σας. Μόλις ολοκληρώσετε και αυτό το βήμα, το FeedBurner θα αναλάβει να δημιουργήσει τα στατιστικά του feed σας. Εκτός από τα ξεκάθαρα και σαφή στατιστικά στοιχεία που θα σας προσφέρει το FeedBurner, με πιο σημαντικό τον ακριβή αριθμό των εγγεγραμμένων χρηστών (subscribers) στο feed σας, θα αναλάβει να βοηθήσει και τους χρήστες του blog σας να κάνουν subscribe στο feed σας ευκολότερα, επιλέγοντας απλά τον feed reader που χρησιμοποιούν (η υπηρεσία υποστηρίζει όλους τους διάσημους on-line και off-line readers, οπότε κανένας χρήστης δεν θα αντιμετωπίσει πρόβλημα). Έτσι η διαδικασία εγγραφής στο feed σας αυτοματοποιείτε αρκετά, κάνοντας το blog σας ακόμα πιο εύχρηστο!

Τα στατιστικά των εγγεγραμμένων χρηστών (subscribers) στο feed σας μπορούν να σας βοηθήσουν να πάρετε αποφάσεις όπως :

  • Να βάλετε διαφημίσεις στο feed σας
  • Να διαφημίστε περιεχόμενο του blog σας μέσα στο feed σας
  • Να αποφασίσετε εάν θα προσφέρεται όλο ή κομμάτι του post σας στο feed σας. Εδώ να σημειώσω πως η πρώτη επιλογή (όλο το post) είναι η καλύτερη και σωστότερη λύση και ας χάνεται σε επισκέψεις στο blog/site σας. Θεωρώ απαράδεκτη συμπεριφορά ένα κομματιασμένο post μέσα στον reader μου!
  • Να υπολογίσετε με μεγαλύτερη ακρίβεια τους χρήστες του blog σας, μιας και ξέροντας τον ακριβή λογαριασμό των εγγεγραμμένων χρηστών στο feed σας μπορείτε να υποθέσετε πως πολλοί από αυτούς δεν επισκέπτονται ποτέ το blog σας, ωστόσο διαβάζουν τα post σας!

Το FeedBurner εκτός από την καταμέτρηση των εγγεγραμμένων χρηστών του feed σας, προσφέρει και επιπλέον ευκολίες στην διαχείριση των ίδιων των feeds. Έτσι εάν για παράδειγμα αλλάξετε κάποτε blog, πράγμα που σημαίνει πως θα αλλάξει αμέσως και το link του feed σας, μπορείτε να “ξανά-κάψετε” το νέο feed σας πάνω στο παλιό FeedBurner feed που μοιράζατε (με λίγα λόγια θα του αλλάξετε το παλιό source feed με το καινούργιο), έτσι ώστε οι χρήστες του feed σας να συνεχίσουν να παίρνουν και να διαβάζουν το feed σας κανονικά, χωρίς καν να προσέξουν την διαφορά, και φυσικά χωρίς να χρειαστεί να ξαναπεράσουν στον reader τους το νέο σας feed (μιας και ο reader τους θα έχει για source το FeedBurner feed το οποίο δεν θα αλλάξει)!

Όπως καταλαβαίνεται η στατιστική ανάλυση κάποιων στοιχείων του blog/site σας, σίγουρα θα σας βοηθήσει να πάρετε σωστότερες αποφάσεις σε πάρα πολλά θέματα, από την βελτίωση και προώθηση του περιεχόμενου σας, μέχρι τι screen resolution (ανάλυση) ή browser plug-in να χρησιμοποιήσετε! Για όλους τους παραπάνω λόγους θεωρώ πως όποιος ασχολείται έστω και ερασιτεχνικά με το blogging ή έχει κάποιο site (έστω και μικρό), καλό θα είναι να ρίχνει και μια ματιά στα στατιστικά του για να παίρνει σωστότερο και μετρήσιμο feedback, έτσι ώστε να κάνει όσο το δυνατόν καλύτερες επιλογές γίνεται σε όλα τα πεδία του blog/site του (από το template και design, μέχρι το περιεχόμενο και το marketing)! Η πρόσβαση σε όλες αυτές τις πληροφορίες γίνεται χρησιμοποιώντας δωρεάν εργαλεία, οπότε δεν υπάρχει κανένας λόγος μη χρησιμοποίησης τους. Ελπίζω να σας κόλλησα λίγο από το μικρόβιο που έχω με τα στατιστικά των blog/site μου (και μόνο με αυτά τα στατιστικά) και να σας έπεισα να δοκιμάσετε να εφαρμόσετε κάποιες συμβουλές στα δικά σας blogs.

HTML e-mails και πως πρέπει να σχεδιάζονται

| Filed under articles css markup

Αν και έχουν γίνει αρκετά βήματα μπροστά στο θέμα HTML e-mails/newsletters, όπως το Email Standards Project (όπως έχω αναφέρει και σε παλιότερο post), τα πράγματα για τους developers παραμένουν άσχημα, μιας και οι mail clients εκτός από από πολλοί, έχουν μείνει και αρκετά πίσω στο θέμα rendering HTML περιεχομένου. Οι περισσότεροι, για λόγους ασφαλείας κυρίως, κόβουν πολλά χαρακτηριστικά όπως Javascript, CSS και πολλές φορές ακόμα και εικόνες, οπότε η κατάσταση είναι δύσκολο να ελεγχθεί από τον developer/designer που έχει αναλάβει την δημιουργία του περιεχομένου! Επιπλέον πρόβλημα είναι και η ύπαρξη on-line αλλά και off-line (desktop) mail clients, όπου ο καθένας ακολουθεί τους δικούς του κανόνες στο τι θα κάνει render και με ποιον τρόπο! Το παρακάτω άρθρο θα προσπαθήσει να δώσει συμβουλές αλλά και να προβάλει τεχνικές έτσι ώστε να σχεδιάζετε καλύτερα και πιο συμβατά HTML mails.

Το πρώτο πράγμα που πρέπει να ασπαστείται είναι η inline CSS! Αν και στο web design η inline CSS θεωρείτε τόσο κακή πρακτική όσο και τα παλιομοδίτικα font tags, στην περίπτωση των HTML mails η inline CSS είναι το μόνο είδος CSS που λειτουργεί στους περισσότερους clients! Έτσι εάν θέλετε να χρησιμοποιήσετε σε κάποιο span element Arial font, σε γκρι χρώμα και bold, ο κανόνας που πρέπει να γράψετε (inline) είναι ο εξής :


Span element με Arial font, γκρι χρώμα και bold!

Από εκεί και πέρα προσπαθήστε να χρησιμοποιήσετε τις βασικές CSS properties οι οποίες υποστηρίζονται στους περισσότερους clients, και αποφύγετε τις πιο σπάνιες (όπως πχ list-style-image). Παρακάτω συγκέντρωσα μία λίστα η οποία εξηγεί τι εννοώ γράφοντας βασικές properties. Την λίστα την έφτιαξα μετά από μελέτη ενός καταπληκτικού άρθρου πάνω στο θέμα το οποίο έχει κάνει ολόκληρη μελέτη για το ποιες CSS properties υποστηρίζονται και ποιες όχι (γράφτηκε το 2006, αλλά υπάρχει και το 2007 review).

  • color
  • background-color
  • border
  • font-family
  • font-size
  • font-style
  • font-variant
  • font-weight
  • letter-spacing
  • line-height
  • margin
  • padding
  • text-align
  • text-decoration
  • text-transform

Κάποιοι παρατηρητικοί θα είδαν πως στις παραπάνω CSS properties δεν αναφέρω πουθενά positioning properties. Ο λόγος είναι πολύ απλός, για HTML e-mail (και μόνο για τον συγκεκριμένο λόγο) η καλύτερη λύση είναι να χρησιμοποιήσετε tables! Το ξέρω πως σε αυτό το blog γράφω πάντα κατά των tables και υποστηρίζω τις μοντέρνες web design τεχνικές, αλλά στην συγκεκριμένη περίπτωση όλα αυτά απλά δεν ισχύουν! Χρησιμοποιήστε tables λοιπόν και μάλιστα αποφύγετε τα πολλά tables μέσα σε tables (γνωστά και ως nested tables). Ένα απλό table-based layout, με λίγα rows και columns είναι το ιδανικότερο, μετά με την εισαγωγή κάποιων βασικών styles στο περιεχόμενο (content) του πίνακα και ακολουθώντας τις παραπάνω συμβουλές, μπορείτε εύκολα να δημιουργήσετε ένα πολύ ευανάγνωστο και εντυπωσιακό HTML e-mail/newsletter.

Άλλο ένα σημαντικό λάθος, που το κάνουν ακόμα και μεγάλες εταιρείες, είναι η αλόγιστη χρήση γραφικών (images) και το ακόμα χειρότερο, η χρήση γραφικών για την προβολή περιεχομένου (content). Ο λόγος που δεν πρέπει να χρησιμοποιούμε πολλά γραφικά, είναι πως πολλοί mail clients (on-line και off-line) δεν αφήνουν τα γραφικά να “περάσουν”, με αποτέλεσμα να μην εμφανίζονται! Όπως καταλαβαίνεται τα πράγματα γίνονται ακόμα χειρότερα εάν τα γραφικά περιέχουν και μέρος του περιεχόμενου μας, όπως για παράδειγμα κείμενο, γραφήματα κτλ. Καλό θα είναι το κείμενο (τίτλοι, παράγραφοι, κτλ.) να είναι κείμενο, και όχι γραφικά με περίεργα Photoshop fonts, γιατί εκτός από το κίνδυνο να μην τα δουν ποτέ οι παραλήπτες, υπάρχει και μεγάλο accessibility πρόβλημα όταν κάποιος θέλει να κάνει copy κάποιο κομμάτι του κειμένου σας!

Τέλος κάντε όσα πιο πολλά τεστ μπορείτε! Και για να γίνω πιο συγκεκριμένος εξετάστε τα HTML mails τουλάχιστον σε :

Αυτά τα βασικά και πιο τεχνικά πράγματα για τα HTML e-mails (προς το παρόν). Ελπίζω να με διαβάζουν και κάποιοι που δημιουργούν τέτοια mails, γιατί όπως πάντα η κατάσταση στην Ελλάδα είναι πάλι αρκετά πίσω από τον μέσο όρο, οπότε όσοι πιστοί νοιάζεστε, διορθώστε όσο μπορείτε την κατάσταση!

HTML 5 και XHTML 2: ο νέος πόλεμος στο web

| Filed under articles markup opinions

Έτσι όπως εξελίσσεται η κατάσταση, ο νέος πόλεμος στο web δεν θα γίνει ανάμεσα σε browsers αλλά σε τεχνολογίες (υπάρχει και η πιθανότητα να συνεχιστεί και στους browsers, αλλά το πρόβλημα θα προκύψει από τις τεχνολογίες που θα αποφασίσουν να υποστηρίξουν)! Αυτήν την στιγμή λοιπόν, οι αντικαταστάτες της κλασικής μας (X)HTML markup είναι δύο, και μάλιστα με αρκετές διαφορές τόσο στον κώδικα (elements, attributes, κτλ.) όσο και στην φιλοσοφία τους. Φυσικά κάνω λόγο για την HTML 5 και την XHTML 2 οι οποίες βρίσκονται αυτήν την στιγμή σε κατάσταση working drafts, πράγμα που σημαίνει ότι θα καθυστερήσουν αρκετά να ολοκληρωθούν και ακόμα πιο πολύ να τις υποστηρίξουν οι διάφοροι browsers, αλλά όπως και να έχει η ερώτηση είναι εξής : Πως προέκυψαν δύο web standards για την ίδια δουλεία?!?!

Καλύτερα να τα πάρουμε τα πράγματα από την αρχή. Στην αρχή λοιπόν τα πράγματα ήταν πολύ απλά με την HTML 1 να είναι η μοναδική markup στον internet, απόγονος της πολύ παλιάς αλλά και δοκιμασμένης SGML. Επειδή σιγά-σιγά το internet άρχισε να γίνεται πιο διάσημο και mainstream λοιπόν, κάποιοι, κατασκευαστές browser κυρίως, άρχισαν να προσθέτουν επιπλέον presentational (παρουσιαστικά) tags και ιδιότητες στην λιτή HTML και να χαλάνε την δομή της (structure) με αυτά, όπως font tags, nested tables, και πολλά άλλα, ενώ η κατάσταση είχε ξεφύγει τελείως από το W3C που δρούσε σαν απλός παρατηρητής. Μετά λοιπόν από τις HTML version 2 και 3, και τον πόλεμο τον browsers που υπήρχε μέχρι και εκείνη την στιγμή, κάποιοι developers όπως ο Jeffrey Zeldman, ο Eric Meyer, και πολλοί άλλοι, αποφάσισαν να πείσουν όλους τους υπόλοιπους, developers και κατασκευαστές browser να χρησιμοποιούν τα επίσημα standards του W3C για την δημιουργία web sites! Είναι η περίοδος που η HTML 4.01 είναι η νεότερη έκδοση της markup για το internet, ενώ έχει ήδη αρχίσει να χρησιμοποιείται από τους πιο σκληροπυρηνικούς και ψαγμένους η νέα XHTML όπου είναι στην ουσία η κλασική HTML 4 αναδιατυπωμένη σαν XML (δεν ήξερα πως αλλιώς να μεταφράσω το reformulation!). Η μεγάλη διαφορά της XHTML με την HTML είναι πως προσπαθεί να συμμαζέψει το περιεχόμενο (content) σε μια ακόμα καθαρότερη δομή (structure), άλλοτε με πιο αυστηρούς κανόνες και άλλοτε όχι – ανάλογα με το doctype – και να αφήσει το παρουσιαστικό (presentation) κομμάτι σε άλλη τεχνολογία, την CSS. Με αυτόν τον τρόπο η markup θα ξαναχρησιμοποιηθεί για τον λόγο που είχε εφευρεθεί, την σωστή δομή του περιεχομένου δηλαδή!

Στην συνέχεια έρχεται μια μεταβατική περίοδος στο web, όπου τα μεγάλα site έχουν φτάσει τις συγκεκριμένες τεχνολογίες στα όρια τους και χρειάζονται κάτι πιο δυνατό για το Web 2.0 το οποίο έχει ήδη αρχίσει να δημιουργείται. Κάπου εδώ ξεκινάει και το μπέρδεμα. Το επίσημο W3C ξεκινάει λοιπόν το draft της XHTML 2, όμως κάποιοι ανεξάρτητοι – κατασκευαστές browser, web developers, ανεξάρτητοι οργανισμοί κτλ. – δημιουργούν την WHATWG community και ξεκινάνε το draft της HTML 5 (και των Web Forms 2.0), το οποίο μετά από κάποιο καιρό το παραδίδουν στο W3C και γίνεται και αυτό επίσημο standard! Έτσι αυτήν την στιγμή έχουμε δύο επίσημους διαδόχους τις (X)HTML οι οποίοι μάλιστα έχουν πάρει και αρκετά διαφορετικές κατευθύνσεις σε θέματα αρχιτεκτονικής και σχεδιασμού!

Αυτήν την στιγμή κανένα από τα δύο recomendations δεν είναι επίσημο ή έχει περισσότερη υποστήριξη, αλλά το μπέρδεμα έχει ήδη γίνει και μάλιστα είναι πολύ μεγάλο! Καταρχάς, τι θα γίνει εάν κάποιοι browsers επιλέξουν να υποστηρίξουν ένα από τα δύο standards (extreme σενάριο, αλλά ας μην ξεχνάμε πως ακόμα κάποιοι browsers προσπαθούν να υποστηρίξουν standards 7 χρόνων παλιά!). Επίσης τι θα γίνει σε development επίπεδο, όπου κάποια site θα υποστηρίξουν την μία markup και κάποια την άλλη? Όπως ανέφερα οι markup είναι πολύ διαφορετικές μεταξύ τους, ενώ η HTML 5 έρχεται και με διάφορα Javascript APIs για ευκολότερο development σε αυτήν, το οποίο όμως μπορεί να μπερδέψει πολλούς developers (ιδιαίτερα νέους), αλλά και κατασκευαστές browsers, οι οποίοι θα πρέπει να ενσωματώσουν στους καινούργιους browsers πολλά νέα APIs. Και σαν να μην έφταναν τα παραπάνω μπερδέματα, το θέμα μπορεί να γίνει και ακόμα πιο περίπλοκο μιας και η HTML 5 για παράδειγμα (στην οποία έχω ρίξει μια καλύτερη ματιά), έχει ήδη δύο parsing modes, ένα σαν HTML και ένα σαν XML, με το πρώτο να είναι πιο συμβατό με παλιότερους browsers ενώ το δεύτερο η αυστηρότερη έκδοση του και χρήση του σαν XML εφαρμογή! Υποθέτω πως και η XHTML 2 θα έχει ανάλογες επιλογές για parsing.

Όπως εύκολα μπορεί να καταλάβει ο μέσος web developer/designer, η κατάσταση είναι αρκετά μπερδεμένη, ενώ εντύπωση μου κάνει πως κανένας επίσημος φορέας, όπως το W3C ή άλλοι μεγάλοι οργανισμοί και guru, δεν έχουν κάνει κανένα σχόλιο πάνω σε αυτό το σημαντικότατο θέμα. Για την ακρίβεια δεν το έχουν θίξει καν! Ξέρω πως και οι δύο τεχνολογίες έχουν πολύ δρόμο ακόμα να διανύσουν, ο Lachlan Hunt στο άρθρο του A Preview of HTML 5 υπολογίζει πως η HTML 5 θα χρειαστεί περίπου άλλα 10 με 15 χρόνια (άρα άλλα τόσα θα χρειαστεί και η XHTML 2), αλλά γιατί να μην γινόντουσαν τα πράγματα πιο απλά για όλους μας ?!?! Ελπίζω η κατάσταση να αλλάξει σύντομα και το τοπίο να ξεκαθαρίσει στο συγκεκριμένο θέμα έτσι ώστε να βοηθηθούν όλοι και να παρθούν γρηγορότερα κάποιες αποφάσεις, γιατί η αλήθεια είναι πως όλοι μας χρειαζόμαστε μια νέα markup! Πολλές ενδιαφέρουσες απόψεις πάνω στο θέμα μπορεί κάποιος να βρει στο άρθρο της IBM, HTML V5 and XHTML V2, ενώ το καινούργιο άρθρο του A List Apart έχει ένα αναλυτικό preview στην HTML 5, και φυσικά για τους πιο σκληροπυρηνικούς υπάρχουν και τα επίσημα drafts.

Η απόλυτη λίστα ελέγχου ενός site

| Filed under articles blogging tips

Έστω ότι μόλις παραλάβατε κάποιο site από κάποια εταιρεία και θέλετε να ελέγξετε την ποιότητα του site που μόλις παραλάβατε ή απλά πως είστε ένας web designer / developer και θέλετε να ελέγξετε εάν το τελικό προϊόν σας (site) καλύπτει κάποια standards. Έχετε ήδη ρίξει λοιπόν μια καλή ματιά στο site με τον default browser σας, αλλά θα θέλατε να έχετε στην διάθεση σας και κάτι παραπάνω, κάτι πιο χειροπιαστό! Όποιος βρίσκεστε λοιπόν σε αυτήν την θέση καλό θα είναι να ρίξει μια ματιά στην παρακάτω λίστα και τις σημειώσεις της, μιας και θα μάθει να ελέγχει σχολαστικά οποιοδήποτε site και μάλιστα χρησιμοποιώντας δωρεάν εργαλεία και υπηρεσίες! Η παρακάτω λίστα είναι ένας πολύ καλός οδηγός για οποιονδήποτε θέλει να ελέγξει και να βελτιώσει το site του. Ας αρχίσουμε λοιπόν :

  • W3C Markup Validator : Σαφέστατα πρώτη κίνηση που πρέπει να γίνεται σε οποιοδήποτε site! Εάν η markup δεν είναι σωστή δεν έχει νόημα να προβούμε σε περαιτέρω tests και ελέγχους (όπως πχ. CSS validation). Εάν το site περάσει αυτό το τεστ, θα λειτουργεί στους περισσότερους υπάρχον browsers και συσκευές, αλλά και στις μελλοντικές υλοποιήσεις τους, χωρίς ιδιαίτερα προβλήματα.
  • W3C CSS Validator : Φυσικά μετά τον έλεγχο της markup ο δεύτερος πιο σημαντικός έλεγχος είναι αυτός της CSS. Και τα stylesheets μας πρέπει να είναι όσο πιο καθαρά και web standard γίνεται, ενώ εάν θα πρέπει να χρησιμοποιήσουμε hacks και μη standard τεχνικές, καλό θα είναι να τα κρατάμε σε κάποιο ξεχωριστό αρχείο και να τα φορτώνουμε μέσω του @import  κανόνα έτσι ώστε το βασικό stylesheet να παραμένει web standard valid! Μόλις περάσουμε και αυτό το τεστ είμαστε σε πάρα μα πάρα πολύ καλό δρόμο! Πολλοί designers χρησιμοποιούν πριν το τελικό CSS validation το Clean CSS το οποίο αναλαμβάνει να σας βοηθήσει στην επίλυση των CSS προβλημάτων, να σας δημιουργήσει ευκολοδιάβαστο κώδικα και γενικότερα να βελτιστοποιήσει (optimize) τον CSS κώδικα μειώνοντας ταυτόχρονα και το file size του. Προσωπικά δεν το χρησιμοποιώ απλά σε κάποιους μπορεί να λύσει τα χέρια.
  • WebXACT : Άλλη μία φανταστική υπηρεσία η οποία προσφέρει πληθώρα πληροφοριών για το site, από το file size και τον χρόνο που θα χρειαστεί κάποιος με 56αρι modem για να κατεβάσει την σελίδα σας μέχρι σε τι accessibility priority level έχει φτάσει το site και πόσα broken links έχει. Ρίχνοντας μια ματιά έχετε μια συγκεντρωτική ιδέα για το που κινείται το site και τι πρέπει να βελτιωθεί σε διάφορα σημεία.
  • Truwex Online 2.0 : Η καλύτερη επιλογή για εύκολο και γρήγορο accessibility test! Η υπηρεσία παρέχει πολλά εργαλεία και πληροφορίες για να λύσετε τα accessibility προβλήματα του site σας, ενώ η επιλογή “map” πραγματικά σας λύνει τα χέρια, δείχνοντας πάνω στο site που βρίσκονται τα accessibility προβλήματα με αναλυτική επεξήγηση του κάθε προβλήματος και φυσικά της λύσης του! Η υπηρεσία κάνει accessibility test σε όλα τα WCAG 1.0 levels αλλά και στον αμερικάνικο accessibility νόμο Section 508.
  • TAW Web Accessibility Test : Κάνει ότι λέει το όνομα του και είναι η δεύτερη υπηρεσία που επισκέπτομαι για accessibility tests! Πολύ καλό είναι και το feedback που δίνει, αφού σας ενημερώνει που βρίσκεται η κάθε παράληψη, σας εξηγεί τι είδους παράληψη είναι (priority level κτλ.) και φυσικά σας δίνει πληροφορίες για το πως μπορείτε να την διορθώσετε. Το μόνο tip που μπορώ να δώσω σε αυτό το σημείο είναι να προσπαθήσετε να καλύψετε το priority 1 αρχικά, και να μην απογοητευθείτε από τα πολλά accessibility warnings που θα δείτε, γιατί το TAW παραείναι αυστηρό!
  • WAVE 3.0 Accessibility Tool : Και αυτή η υπηρεσία έχει να κάνει με accessibility test παρουσιάζοντας κάπως διαφορετικά τα αποτελέσματα της. Η συγκεκριμένη υπηρεσία είναι λίγο πιο δυνατή στο να εντοπίζει και να παρουσιάζει τα κομμάτια του κώδικα σας όπως headers, divs, footers, Javascript, κτλ. και να προτείνει λύσεις στα διάφορα προβλήματα που πιθανόν έχουν. Έτσι με αυτόν τον τρόπο μπορεί πολύ γρήγορα κάποιος να διορθώσει τα accessibility προβλήματα σε themes και templates!
  • Browsershots : Αν και η καλύτερη λύση είναι να τεστάρετε το site σε όλα τα desktop λειτουργικά συστήματα, δηλαδή σε Windows, OSX και Linux, και σε όλους τους γνωστούς browsers γι αυτά (IE, Firefox, Opera, Safari, Konqueror κτλ.), η συγκεκριμένη λύση πολλές φορές δεν είναι και τόσο εφικτή. Έτσι καλό θα είναι να έχετε υπόψη σας την συγκεκριμένη υπηρεσία, η οποία αν και αργεί αρκετά (όπως οι περισσότερες αντίστοιχες άλλωστε) σας επιτρέπει να δείτε το site σε όλους του γνωστούς browsers αλλά και να επιλέξετε και συγκεκριμένες screen resolutions!
  • Ready.Mobi : H καλύτερη υπηρεσία που έχω ανακαλύψει για το τεστ ενός site σε κινητά τηλέφωνα! Η συγκεκριμένη υπηρεσία προσφέρει μια πολύ αναλυτική αναφορά για το πως φαίνεται το site σε κινητά τηλέφωνα, με λεπτομέρειες όπως πόση ώρα χρειάζεται το site για να κατέβει μέσω Wifi, 3G και GPRS, εάν έχετε κάνει σωστή χρήση των images για mobile συσκευές, πως φαίνονται τα stylesheets κτλ. Το κερασάκι στην τούρτα είναι και οι 4 (προς το παρόν) emulators κινητών τηλεφώνων που διαθέτει (Nokia N70, Samsung z105, Sony Ericsson k750i, Motorola v3i και Sharp GX-10)!
  • Website Grader : Τέλος θα ήθελα να κλείσω με την αγαπημένη μου SEO υπηρεσία. Εδώ μπορείτε να βρείτε πως τα πάει το site σας στις μηχανές αναζήτησης και στα περισσότερα ranking sites (όπως Technorati, Alexa, κτλ.) καθώς και πολλές άλλες χρήσιμες πληροφορίες όπως εάν έχει γίνει σωστή χρήση των τίλων/headings (h1, h2, ktl.). Εάν το site είναι ολοκαίνουργιο η χρήση της  συγκεκριμένης υπηρεσίας δεν έχει και πολύ νόημα, εάν όμως το site υπήρχε και έχει γίνει κάποιο redesign, καλό θα είναι να του ρίξετε μια ματιά.

Ελπίζω η παραπάνω λίστα να βοηθήσει όσους ενδιαφέρονται να κάνουν τα site τους ακόμα καλύτερα, πιο επαγγελματικά και τηρώντας κάποιες διεθνής προδιαγραφές! Οι εν λόγω υπηρεσίες και εργαλεία παρέχονται εντελώς δωρεάν και μπορούν να χρησιμοποιηθούν πανεύκολα, ενώ οι πληροφορίες που συλλέγουν θα ικανοποιήσουν και τους πιο απαιτητικούς! Φυσικά δεν είναι ανάγκη το κάθε site να περνάει με επιτυχία όλα τα παραπάνω test (ειδικά τα accessibility test είναι αρκετά δύσκολο να επιτευχθούν ενώ όπως είναι λογικό διαφορετικού τύπου site χρειάζονται και άλλου επίπεδου accessibility), αλλά καλό θα είναι να ρίχνουμε μια καλύτερη ματιά σε αυτά που είτε φτιάχνουμε είτε παραλαμβάνουμε, γιατί στην Ελλάδα το έχουμε παρακάνει το θέμα με τα μη valid και unaccessible sites!