La problématique de la conception responsive
J'essaye de le montrer depuis quelques temps déjà, mais la logique de conception responsive implique un changement de la méthodologie de conception et de réalisation. Rudy Rigot évoque ce sujet dans un article très complet dans lequel je vais piocher quelques paragraphes.
Basically, you had the infamous sequence: specifications – conception – design – front-end dev – back-end dev, and all the small pieces before, after, and in-between. Each of these areas didn't need to know that much about each other. For example the front-end developer could work on the project weeks after the conception.
De manière classique, vous procédez à la séquence suivante :
- spécification
- conception
- habillage
- intégration graphique
- développement fonctionnel
Chaque phase fonctionne de manière quasi-indépendante et n'a pas besoin de connaître comment fonctionne l'autre. Un système de division du travail dans lequel chaque métier est découplé (un chef de projet réalise le liant).
Responsive design imposes tight technical constraints on the conception, which completely turn this model on its head. You can’t produce one fixed-width wireframe like before, and expect all of the website’s interaction to be conceived from this. And you can’t expect a functional designer to produce an output that is technically relevant, if he doesn’t have a solid technical background allowing him or her to respect the flow of content into different responsive layouts, and isn't working closely with someone who does.
La conception responsive impose des contraintes techniques particulières, qui remettent en cause le modèle précédent. Il n'est plus possible de partir d'un écran présentant une largeur de colonne fixe et, de plus, espérer concevoir les interactions sur celui-ci. Ce gabarit sera difficile à interpréter une fois arrivé au stade du développement front-end.
So, should you ask your front-end developer to make wireframes? Or wait, should you expect HTML/CSS pages right away, created by your graphic designer? Headache!
A ce stade, plusieurs questions peuvent vous venir à l'esprit, il pourrait être pertinent de donner la réalisation des gabarits ou encore de demander à votre graphiste de coder des pré-gabarits. Que choisir ?
One thing is for sure: in a team-driven project, the separation of roles and expertise is not as clear as it used to be, and a simple "let’s do it responsive" mantra is not good enough — we need to redefine the order in which we’re used to doing things.
Plutôt que de trancher en espérant une monté en compétence illusoire des membres de vos équipes, il conviendrait, peut-être, de passer à une vision équipe. Equipe, dans laquelle les compétences, les rôles, ou encore les expertises ne sont pas strictement déterminées, il suffit pas de dire "faites moi un site responsive" pour avoir un résultat conforme aux attentes. Il est préférable de redéfinir les priorités et de passer par un peu plus d'autonomie.
On retrouve donc dans cet article un point de vue inhérent à la conception web : la division du travail est contre productive dès qu'on veut atteindre des objectifs d'interopérabilité, de qualité, de performance et d'accessibilité.
Note : l'explication de cette réalité s'explique par le niveau de complexité à maîtriser ; la division du travail peut, effectivement, se justifier dans un cadre ou la complexité est maîtrisée ou réduite.
Lire : Responsive web design: a project-management perspective.