Toujours à la recherche de nouveaux process, outils et pratiques, je me suis penchée sur l’idée de ne plus passer par Photoshop pour la création graphique de sites, mais de passer tout de suite à l’intégration. Francis Chouquet (fran6art) parle de « maquettes interactives« .

Le sujet fait un peu de bruit depuis quelques mois, certains voient les avantages de cette manière de travailler, d’autres ne sont pas prêt d’abandonner Photoshop de ci-tôt. Et bien sûr il y a ceux qui se situent au milieu.

Pourquoi une idée aussi farfelue ?

Tout Designer Web soucieux des meilleures pratiques en matière d’ergonomie, de référencement et d’accessibilité, saura que le contenu d’un site est primordial. Alors pourquoi ne pas structurer le contenu d’une page avant de passer à la couche design ? Voilà d’où est née l’idée du « designing in the browser », ou en français, du design dans le navigateur.

Cette manière de travailler n’est pas nouvelle, mais la naissance de CSS3 lui donne un intérêt nouveau. En effet, il est maintenant possible de créer de nombreux effet tels que des ombres, des rotations, des transparences et des dégradés, avec CSS3.

Vous me direz, CSS3 ne marchera pas dans de nombreux navigateurs populaires, alors pourquoi compter dessus ? Il y a plusieurs réponses possibles à cette question ;

1. On pourrait dire que justement, cette méthode va permettre de concevoir un site avec les principes de « dégradation gracieuse » en tête. Peut-être que IE n’aura pas de coins arrondis ni d’ombre, mais on peut faire en sorte que la page reste visuellement intéressante et ergonomique sans ces éléments de design.
2. Travailler dans le navigateur dès le début peut permettre d’éduquer son client de manière plus efficace : il verra tout de suite les différences d’un navigateur à l’autre au lieu de s’étonner qu’au final, son site n’est pas tout à fait le même que la maquette sous Photoshop.
3. On peut choisir cet outil de travail comme point de départ, mais rien ne nous empêche d’altérer le code et de rajouter des images par la suite pour que certains effets soient visibles sur tous les navigateurs. Avant tout l’intérêt est de ne pas travailler dans un format statique. On peut même faire des captures écran et les envoyer au client si on veut mais ça perd un peu de son intérêt.

Photoshop vs. le navigateur

Alors bien entendu chaque méthode a ses avantages et ses inconvénients. Dans Photoshop il sera sans doute plus rapide d’arriver à un design satisfaisant. D’après Dan (Wuup), qui a testé le design dans le navigateur pour ses clients, la phase du design initial est plus longue que dans Photoshop mais au final on gagne du temps sur le développement et donc sur la totalité du projet.

Je pense que les deux méthodes sont valables ; qu’on travaille dans Photoshop ou dans le navigateur, il s’agit de choisir un outil de création graphique qui sera le plus adapté à un projet et à un Designer Web.

Dan coupe la poire en deux en suggérant que le design d’une ou deux pages soit fait dans Photoshop, et le reste du site dans le navigateur. Ça me parait assez raisonnable comme approche, mais je ne suis pas sûre que ce soit très novateur.

Au moins, si on est le genre de Designer Web qui sait coder, on a le choix des outils. Mais ça c’est un autre débat qui fait du bruit depuis plusieurs années…

Quelques liens

• sxsw.beercamp.com : voici un site qui a été réalisé non seulement dans le navigateur, mais surtout avec aucune image – que du code !
• 24ways.org (en anglais) : Meagan Fisher exprime son dégoût pour Photoshop et son approche du design qui consiste à commencer par le contenu.
• Design Shack (en anglais) : voici une liste d’astuces et d’outils pour aider à concevoir un site dans le navigateur.

Ca sort du four!!

Lorsque l’on veut industrialiser le process de création de sites, il est nécessaire d’établir des procédures que l’on répète de manière similaire, sinon identiques à chaque nouveau projet. Je vous propose aujourd’hui notre procédure de synchronisation maison. Ne vous brûler pas, c’est tout chaud, ça sort à peine du four!!

Un développement de site se fait toujours en local, c’est à dire sur un poste client. Une fois les développements terminés, ou en cours de finalisation, il reste à uploader le contenu de son site sur son serveur distant. Cette tâche se compose de 2 parties distinctes :

• la copie des fichiers statiques :
  • core de wordpress
  • répertoires de plugins spécifiques au projet (wp-content/*plugins/*)
  • répertoire de thème du projet (wp-content/themes/monThemeProjet)
• la copie de la base de donnée

Dans un monde parfait, une simple copie serait suffisante, wordpress détecterait que l’emplacement de l’installation a changé, et prendrai en compte ce changement. Mais dans la vrai vie, une procédure un peu plus compliquée s’impose.

Pré-requis :

• le poste client est un linux-like (distribution linux ou Mac)
• le serveur est également un linux-like (plus facile à trouver!)
• un répertoire projet créé sur le serveur
• On a fait le nécessaire pour se connecter au serveur distant sans mot de passe (comme expliqué ici)

Notre procédure se compose de 7 étapes :

1. En local, exécuter le script suivant qui va réaliser un rsync (synchronisation du répertoire projet avec le répertoire cible sur le serveur :

# ./deploy_local_wordpress_rsync.sh
#!/bin/bash
# Ce script doit être exécuté depuis le répertoire contenant l'installation de wordpress
USER="julien"
HOST="monsite.com"
PORT=
RSYNC=`which rsync`
PROJECT_NAME=nom_de_mon_projet ## eg: portail_client_X
VERSION=1
DEPLOY_DIR=/var/www/html/staging/$PROJECT_NAME/$VERSION

echo "Deploiement de $PROJECT_NAME vers $DEPLOY_DIR"
$RSYNC -avz -e ssh ./ $USER@$HOST DEPLOY_DIR --exclude-from=wordpress_exclude.rsync

avec wordpress_exclude.rsync (fichier regroupant les fichiers/répertoires à ne pas synchroniser) pouvant ressembler à :

desktop.ini
.DS_Store
/wp-config.php
/wp-content/gallery
/wp-content/themes/blamatic
/wp-content/themes/classic
/wp-content/themes/default
/wp-content/themes/delight
/wp-content/themes/medical-theme
/wp-content/themes/modularity-lite
/wp-content/themes/retrospective
/wp-content/themes/simpleblocks
/wp-content/themes/thematic
/wp-content/themes/whiteboard
/wp-content/plugins/flexi-pages-widget
/wp-content/plugins/nextgen-gallery
/wp-content/plugins/wp-shopping-cart
/wp-content/plugins/wp_date_fr
/wp-content/uploads/wpsc
/wp-content/uploads/js_cache
/wp-config.php.BAK

2. Sur le serveur modifier les droits du répertoire

   wp-content

   (utilisé pour l’upload de contenus – images, attachements, etc -) :

   chmod -R 777 wp-content

3. 

   Création de la base wordpress sur le serveur

   Sur le serveur, créer de la base de donnée. Sous phpMyAdmin par exemple.

   Donner un nom à votre base, ici wp_database, choisir l’interclassement utf8_general_ci si possible pour une meilleur gestion des caractères spéciaux.

4. Sur le serveur, modifier le fichier wp-config (situé à la racine de wordpress) pour que wordpress puisse se connecter à la nouvelle base (DB_NAME, DB_USER, DB_PASSWORD, DB_HOST)
5. Envoyer au serveur un Dump de la base locale (un Dump est un export de la base, onglet exporter sous phpMyAdmin) par exemple avec la commande :

scp monDump.sql user@serveur:repertoire

6. Importer le Dump dans la base du serveur (Onglet importer sous phpMyAdmin)
7. La base contient des chemins absolus correspondant à votre configuration locale : Mettez à jour tous les champs, via les commandes SQL suivantes :

UPDATE wp_options
SET option_value = replace(option_value, 'http://www.old-domain.com', 'http://www.new-domain.com')
WHERE option_name = 'home' OR option_name = 'siteurl';

UPDATE wp_posts
SET guid = replace(guid, 'http://www.old-domain.com','http://www.new-domain.com');

UPDATE wp_posts
SET post_content = replace(post_content, 'http://www.old-domain.com', 'http://www.new-domain.com');

TroubleShootings :
Attention au fichier .htaccess. Il semble que le fichier .htacess (utilisé pour gérer les Friendly URLs) se regénère automatiquement. Ce n’a pas été notre cas. Il a fallut éditer ce fichier pour le mettre à jour :
de l’ancienne version en local (on y accède via http://localhost/WPlocalInstall)

# BEGIN WordPress

RewriteEngine On
RewriteBase /WPlocalInstall/
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /WPlocalInstall/index.php [L]

# END WordPress

à la nouvelle version sur le serveur :

# BEGIN WordPress

RewriteEngine On
#RewriteBase /localInstall/ ## COMMENTÉ CAR LE SITE EST À LA RACINE DU DOMAINE ##
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L] ## LE SITE EST À LA RACINE DU DOMAINE ##

# END WordPress

Bonne mise en ligne!!