Front End development models

Panos Kontopoulos - 05/09/10

Τις προάλλες είχαμε μια πολύ ενδιαφέρουσα κουβέντα με τα παιδιά στην WEDIA, για τον τρόπο με τον οποίο υλοποιούμε τα web projects μας σε front end επίπεδο.

Από ότι καταλαβαίνω υπάρχουν 2 βασικές σχολές:

- Η πρώτη και νομίζω η πιο παλιά σχολή, λέει ότι ξεκινάω από τα PSD των templates του project τα οποία μετατρέπω σε HTML με τελείως sample δεδομένα, στήνω όμορφα και μαζεμένα το CSS μου και όταν τελειώσω τα συνδέω εγώ ή ο back end developer με το CMS που πρόκειται να χρησιμοποιήσω.

- Η άλλη σχολή ξεκινάει λίγο διαφορετικά: Από τα PSD στήνω στο CMS μου τα content types που θα χρησιμοποιήσω και κάνω ότι πρέπει για να βγάλω τα δεδομένα στο front end σε μια πολύ απλή μορφή για να έρθει μετά η ώρα του CSS theming. Αυτή η δεύτερη σχολή είναι πιο κοντά σε CMS όπως είναι το Drupal για το οποίο τα περισσότερα από τα modules που χρησιμοποιείς, πέρα από το functionality του module, εμπεριέχουν και κώδικα που παράγει theming, ασχολούνται δηλαδή και με την εμφάνιση της πληροφορίας.

Προφανώς και στην δεύτερη λύση υπάρχουν λύσεις να κάνεις override τον default τρόπο εμφάνισης είτε μεταβάλλοντας το template του module είτε γράφοντας το δικό σου συγκεκριμένο κώδικα στην κατάλληλη θέση μέσα στο theme, παρόλα αυτά εξακολουθούν να είναι δύο διαφορετικές προσεγγίσεις.

Φαίνεται ότι η πρώτη λύση είναι πιο καθαρή και δίνει το περιθώριο να προγραμματίσεις καλύτερα κοινά χαρακτηριστικά και λειτουργικότητα αλλά η δεύτερη είναι λίγο πιο γρήγορη στην υλοποίηση.

Έχετε κάποια παρόμοια εμπειρία ; Κάποια προτίμηση ;


Διαβάστε ακόμη :

5 Comments »

RSS feed for comments on this post.

  1. Υπάρχει και η άλλη μέθοδος την οποία προτιμώ:

    Σχεδιάζεις απευθείας σε HTML. Αυτό το στάδιο βέβαια έρχεται μετά το prototyping/wireframe.

    Ακριβώς επειδή το τελικό αποτέλεσμα θα είναι σελίδα στον browser κι όχι static εικόνα, το να ξεπεράσεις το Photoshop είναι μία νίκη του designer. Το να δώσεις στον πελάτη το πρώτο δείγμα σε HTML είναι μια επίσης μικρή νίκη του agency ολόκληρου. (Κι επειδή είναι βέβαιο ότι θα χρειαστείς γραφικά, το Photoshop θα είναι πάντα ανοιχτό. Όμως δε θα είναι ποτέ η αφετηρία σου.)

    Όλο αυτό σε βελτιώνει στο πως αντιμετωπίζεις το στήσιμο στο όποιο CMS. Δεν μπορώ να το περιγράψω με λόγια, αλλά ισχύει. Επιπλέον, σε κάνει content aware και σου βγάζει εντέλει και πιο καθαρό κώδικα. Κι όλα αυτά πιο γρήγορα.

    Comment by porcupine — September 5, 2010 #

  2. Προσωπικά, σε σχέση με το Drupal προτιμώ να δουλεύω με τον πελάτη σε αρχικό στάδιο με τα wireframes & το sitemap. Mε βάση αυτά, μπορείς να κάνεις αρκετή δουλειά σε σχέση με content types, regions, blocks κ.λ.π. , ενώ προχωράει και το development.

    Η δουλειά με το photoshop (ή fireworks), γίνεται στο επόμενο στάδιο, οπότε απλά γίνεται η προσαρμογή σε επίπεδο theme (κυρίως css). Με αυτό τον τρόπο χτίζεις το site γύρω από το περιεχόμενο και όχι γύρω από το design, ενώ συνήθως και ο πελάτης είναι πιο προσηλωμένος σε ζητήματα λειτουργικότητας και δομής του περιεχομένου στο αρχικό στάδιο σχεδιασμού του site.

    Σχετικές παρουσιάσεις από Drupalcon CPH:
    http://www.archive.org/details/DontDesignWebsites.DesignWebSystems
    http://www.archive.org/details/ThemingTheEnterprise
    http://www.archive.org/details/DesignForDrupalATemplateApproach-CutYourDesignTimeDownBy200

    Comment by Γιώργος Παπαδόγγονας — September 5, 2010 #

  3. Το να ξεκινήσεις από το PSD είναι το μεγαλύτερο λάθος που μπορείς να κάνεις. Και αυτό γιατί το PSD έρχεται από τον designer, που στο 99% των περιπτώσεων δεν έχει ούτε το 1/10 της επαφής με το web από αυτή που έχει ο developer και ίσως άλλοι εμπλεκόμενοι.

    Θα πρότεινα το εξής:

    1. Δίνεις ένα draft σε χαρτί (τόσο απλό) στον developer με τα βασικά περιεχόμενα της κάθε σελίδας (οκ, ίσως να αφήσεις και τον designer να ρίξει μια πρόχειρη ματιά στο χαρτί σου, nothing more).

    2. Αφήνεις τον designer να το ζωντανέψει, χρησιμοποιώντας στοιχειώδη εμφάνιση, ίσα να καταλαβαίνετε τι γίνεται. Αν ο developer είναι καλός, θα σου προτείνει την ώρα που το δουλεύει και διάφορα καλούδια για εμπλουτισμό. Σε αυτή τη φάση όλες οι αλλαγές είναι σχετικά εύκολες γιατί δεν ο developer δεν έχει να τραβολογάει μαζί και το design. Βλέπεις (ενδεχομένως και με τον πελάτη) λειτουργικότητα και content και κάνετε τις απαραίτητες αλλαγές.

    3. Δίνεις το ζωντανό πλέον (και άσχημο ενδεχομένως) site στον designer και του λες να κάνει τα μαγικά του με τα υπάρχοντα elements.

    4. Δίνεις το PSD στον developer για να φέρει το site στα ίσια του.

    How does it sound?

    PS. Θα έλεγα επίσης ότι το τι markup παράγει το CMS, απλά το αγνοείς. Το CMS, οι designers και οι developers θα πρέπει να είναι ευέλικτα/οι και να κάνουν ότι γουστάρουν/χρειάζεται.

    Comment by Chris Georgakopoulos — September 5, 2010 #

  4. @Γιάννη, σκεφτόμουνα το να ξεκινήσεις να δουλεύεις και να αλλάζεις πράγματα κατευθείαν σε HTML είναι πιο χρονοβόρο από το να αλλάζεις σχέδια, αλλά φαντάζομαι ότι έχει σχέση με την άνεση και την εμπειρία της ομάδας.

    @Chris, κατ’ αρχήν μου φαίνεται λίγο μπερδεμένο σαν μοντέλο. προφανώς μάλλον θέλει κουβέντα από κοντά :-) , ενώ το να αγνοείς το markup του CMS δεν είναι εύκολο, δεν ξέρω με τι εργαλεία δουλεύετε, αλλά όπως έγραψα και στο post σε κάποια από αυτά η markup παράγεται από τα ίδια τα modules.

    @Γιώργο, προφανώς λόγω κοινής πλατφόρμας (Drupal) αυτά που περιγράφεις μου φαίνονται οικεία, κρατάω κάποιους ενδοιασμούς για το αν μπορείς να συζητάς με τον πελάτη χωρίς να βλέπει το τελικό του site ζωγραφισμένο, αλλά φαντάζομαι ότι είναι και θέμα εκπαίδευσης κα ιψάχνω να βρω χρόνο για να δω τις παρουσιάσεις που συστήνεις

    Και φυσικά … σας ευχαριστώ όλους για τις παρεμβάσεις σας.

    Comment by Panos — September 6, 2010 #

  5. Επανέρχομαι:

    http://24ways.org/2009/make-your-mockup-in-markup

    Comment by Χρήστος Γεωργακόπουλος — October 25, 2010 #

Leave a comment

XHTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Powered by WordPress with GimpStyle Theme design by Horacio Bella.
Entries and comments feeds. Valid XHTML and CSS.