Pourquoi le piratage de la console Google Docs n'est pas la bonne façon d'obtenir une vue sur deux pages

C’est pourquoi l’astuce est à la fois si séduisante et si trompeuse. Il résout d'abord le problème visuel, ce qui le rend intelligent, mais il laisse intacte la partie la plus difficile : le comportement de l'éditeur lorsque vous tapez, sélectionnez, commentez et vous déplacez dans le document.

Avant et après le hack de la console

Vous avez peut-être vu l'astuce de la console du navigateur qui force Google Docs à adopter une pseudo-mise en page sur deux pages. À première vue, cela semble utile : les pages apparaissent côte à côte et un écran large semble moins gaspillé.

Cette impression visuelle est tout le truc. Ce n’est pas un véritable mode d’édition et ce n’est pas une bonne solution. Il s’agit d’un remplacement rapide du DOM qui donne à l’écran un aspect différent.

Comment fonctionne le hack

Le message original de Coderwall par Jérémie sur Coderwall décrit l'astuce comme un simple ajustement CSS : faites en sorte que les conteneurs de pages remplissent toute la largeur, faites flotter les pages vers la gauche et forcez la mise en page dans une fausse vue à deux colonnes.

(function(d,t,z,s) {
      s = d.createElement(t);
      s.innerHTML = z+'-outer{left:0px !important;}'+z+'-outer,'+z+'-inner{width:100% !important;}.kix-page{float:left; width:48% !important;}';
      d.getElementsByTagName(t)[0].parentNode.appendChild(s);
      })(document, 'style', '.kix-zoomdocumentplugin');

L'article original est de Jérémie sur Coderwall, et la version bookmarklet est liée à partir de ce message.

En d’autres termes, le hack est avant tout un remplacement de style. Il n'apprend pas à Google Docs à modifier différemment. Cela persuade simplement le navigateur de peindre l’interface d’une manière qui ressemble davantage à deux pages.

Pourquoi la bonne page ne semble pas fiable

Google Docs calcule toujours le placement du curseur, les tests d'accès, la sélection et les commentaires autour de son modèle de mise en page d'origine. Le hack ne repeint que là où les pages apparaissent à l'écran, de sorte que le résultat visuel et le modèle d'édition s'éloignent.

• Le placement du curseur peut dériver : les clics et les sélections ne correspondent pas toujours au texte visible.
• L'édition active devient fragile : la vue peut être bonne pour la révision, mais moins fiable pour une véritable écriture.
• Les commentaires et les superpositions peuvent mal se comporter : l'astuce n'est pas conçue autour de la surface complète de l'interface utilisateur de Docs.
• Il est fragile par nature : Les noms et la structure des classes Docs internes peuvent changer sans avertissement.

Pourquoi ce n'est pas la bonne façon

Le hack vous donne un résultat visuel qui semble intelligent pendant une minute, mais un véritable flux de travail d'écriture doit survivre à une utilisation quotidienne. Vous avez besoin d'une stabilité du curseur, d'une sélection prévisible, de commentaires qui atterrissent là où ils devraient et d'une mise en page qui reste compréhensible après la dixième modification de la journée.

L'astuce de la console échoue à ce test car il ne s'agit pas d'une fonctionnalité du produit. C'est une manipulation DOM. Une fois que vous le traitez comme un workflow, les points faibles apparaissent immédiatement.

Quand le hack est encore utile

Si vous n’avez besoin que d’une démo rapide en lecture seule sur votre propre ordinateur, le hack peut être amusant à essayer. Mais pour l’écriture, la révision ou la collaboration quotidiennes, un flux de travail de mise en page natif est le choix le plus sûr.

C’est la ligne à garder à l’esprit : démo amusante, mauvaise habitude. Si vous essayez réellement de travailler, vous ne devez pas vous fier à une astuce qui peut être carrément bloquée par Trusted Types, ou qui pourrait cesser de se comporter au moment où Google modifie un nom de classe ou redistribue à nouveau l'éditeur.

Le problème n’est pas seulement la fragilité. C'est aussi la confiance. Un flux de travail d'écriture doit être ennuyeux de la meilleure façon possible. Dès qu’une astuce de mise en page vous fait hésiter avant de cliquer ou de sélectionner du texte, elle a déjà franchi la limite entre l’utile et le distrayant.

Conclusion

L'astuce de la console est une démo intelligente, pas une surface d'édition fiable. Si vous souhaitez un travail Google Docs côte à côte auquel vous pouvez faire confiance au quotidien, utilisez plutôt DocDocDoc.

La réponse rapide

Si vous êtes curieux, essayez le hack une fois comme expérience visuelle. Si vous essayez d'écrire, de réviser ou de collaborer, arrêtez-vous là. Une astuce qui modifie uniquement la couche de peinture ne sera jamais la bonne réponse pour un document actif.

La meilleure question n’est pas de savoir si le piratage peut donner à l’écran un aspect différent. La meilleure question est de savoir si cela vous aide à terminer le document. En pratique, la réponse est non. Cela n’a jamais été utile que pour le visionnage, pas pour un véritable montage.

Ce que les gens recherchent réellement

La plupart des gens qui recherchent ce hack ne recherchent pas vraiment CSS. Ils recherchent un soulagement à la sensation d'une seule page de Google Docs. Ils veulent que la page paraisse plus large, que la page suivante reste visible et que l'ensemble du processus d'édition soit moins à l'étroit.

C’est exactement pourquoi le hack attire l’attention. Cela semble répondre à la véritable plainte. Mais comme il ne modifie que la couche visuelle, il ne peut pas offrir la stabilité dont a besoin un flux de travail d'écriture quotidien.

Références et lectures complémentaires

• coderwall.com/p/qvdxia/2-page-view-in-google-docs
• Extension côte à côte README et problèmes connus : github.com/ryanpcmcquen/side_by_side_gdocs
• Source du script d'extension (manipulation DOM/CSS) : raw.githubusercontent.com/.../side_by_side_gdocs.js
• Aide officielle « côte à côte » de Google (applications du panneau latéral, pas d'édition sur plusieurs pages) : support.google.com/docs/answer/106237