Un visualiseur de documents peut être techniquement fonctionnel et rester inutilisable sur un écran étroit. Des barres d’outils denses, des contrôles minuscules, des panneaux latéraux surdimensionnés et des conteneurs aux dimensions fixes transforment rapidement un aperçu simple en une expérience frustrante.

Pour les applications Windows basées sur ASP.NET et .NET, Doconut fournit un SDK de visualisation de documents intégré pour les documents métier, les fichiers PDF, les dessins CAD, les courriels et les images. Votre application contrôle toujours la mise en page environnante, l’authentification, l’autorisation, le stockage et le flux de travail des documents.

Ce guide se concentre sur cette expérience environnante : comment offrir suffisamment d’espace à un visualiseur intégré, rendre les contrôles de l’application confortables à utiliser, gérer les changements d’orientation et tester des documents réalistes sans dépendre d’un code source SDK non vérifié.

Mises en page réactives de visualisation de documents connectées à un composant serveur .NET

Le design réactif commence à l’extérieur du visualiseur

Le visualiseur ne peut utiliser que l’espace fourni par sa mise en page parent. Si l’application le place dans une carte étroite, lui attribue une largeur fixe de bureau ou l’entoure de plusieurs panneaux persistants, la zone du document restera à l’étroit.

Commencez par trois questions :

Quelle est la tâche principale sur cette page ?
Quels contrôles de l’application doivent rester visibles pendant la lecture ?
Quels panneaux secondaires peuvent se réduire ou se placer derrière un bouton ?

Pour une page de document dédiée, le visualiseur doit généralement être l’élément dominant. Les métadonnées, les commentaires, les approbations et les actions du flux de travail peuvent rester disponibles sans occuper d’espace permanent du document.

Planifier la mise en page selon l’espace disponible

Le comportement réactif doit suivre l’espace disponible pour le composant, et non des suppositions basées sur le nom d’un appareil particulier.

Mise en page large

Sur un grand viewport, la page peut afficher :

Une vignette de document ou un panneau de navigation
Le canevas principal du document
Un panneau secondaire de flux de travail pour les commentaires ou les métadonnées
Un ensemble complet d’actions de l’application

Lorsque un panneau secondaire devient un tiroir, ajoutez le comportement de dialogue, la gestion du focus et le libellé accessible requis par votre système de conception.

Rendre les contrôles de l’application conviviaux pour le tactile

Les contrôles autour du visualiseur doivent être confortables à activer sans mouvement précis du pointeur.

Attribuez aux contrôles interactifs une zone cible d’environ 44 × 44 pixels CSS.
Laissez suffisamment d’espace entre les actions destructrices et celles fréquemment utilisées.
Ne comptez pas sur le survol pour révéler des informations essentielles.
Gardez les indicateurs de focus visibles pour les utilisateurs de clavier.
Fournissez des noms accessibles pour les boutons uniquement icônes.
Évitez de placer des contrôles critiques près des zones de gestes du navigateur ou du système.

Ne remplacez pas les styles internes de Doconut avec des sélecteurs devinés ou des variables CSS non documentées. Utilisez les ressources officielles pour la version du SDK installée, et appliquez vos règles réactives aux conteneurs et contrôles appartenant à l’application.

Traiter les panneaux latéraux comme un espace de travail optionnel

Les vignettes, les résultats de recherche, les annotations, les métadonnées et l’historique du flux de travail sont utiles, mais ils ne doivent pas tous concurrencer le document simultanément.

Sur les mises en page compactes :

Ouvrez un panneau latéral uniquement lorsque l’utilisateur le demande.
Restaurez le focus sur le bouton qui l’a ouvert après la fermeture.
Capturez le focus à l’intérieur des panneaux modaux lorsque cela est approprié.
Donnez au panneau un titre clair et une action de fermeture.
Conservez la position actuelle du document lorsque le panneau s’ouvre ou se ferme.

Si le visualiseur fournit ses propres panneaux, testez leur comportement réactif documenté avant d’ajouter un second système de navigation au niveau de l’application autour d’eux.

Maintenir l’espace de travail du document rapide

Le design réactif n’est pas seulement visuel. Les gros documents peuvent révéler des contraintes de mémoire, de bande passante et de rendu, surtout lorsque la page contient également des tableaux de bord ou des animations complexes.

Réduire le travail concurrent

Mettez en pause les animations décoratives pendant que l’utilisateur lit, évitez les effets coûteux autour du visualiseur et supprimez les observateurs ou écouteurs d’événements inutiles.

Réserver de l’espace de mise en page

Attribuez à l’hôte du visualiseur une hauteur stable avant son chargement. Cela évite de grands déplacements de mise en page et réduit le risque que les utilisateurs appuient sur le mauvais contrôle.

Charger délibérément les fonctionnalités secondaires

Les commentaires, l’historique d’audit et les grands panneaux de métadonnées ne doivent pas toujours se charger avec la première page du document. Différez-les jusqu’à ce que l’utilisateur ouvre le panneau correspondant, selon votre flux de travail.

Tester des fichiers représentatifs

Utilisez des PDF longs, des feuilles de calcul larges, des dessins CAD détaillés, de grandes images et des documents avec des polices inhabituelles. Un petit fichier d’échantillon ne peut pas révéler les limites de l’expérience de production.

Conserver le contrôle d’accès sur le serveur

La présentation réactive ne modifie pas les responsabilités de sécurité de l’application. Chaque requête de document doit toujours passer par l’authentification et l’autorisation spécifique au document.

Pour les applications ASP.NET Core, des mécanismes standards tels que le middleware d’authentification, les politiques, les revendications, l’attribut [Authorize] et l’autorisation basée sur les ressources peuvent protéger la route serveur qui résout un document.

Utilisez des identifiants de document générés par le serveur.
Vérifiez que l’utilisateur actuel peut accéder au document demandé.
Gardez les informations d’identification de stockage et les chemins non restreints loin du client.
Nettoyez les erreurs affichées sur la page du visualiseur.
Appliquez des règles de rétention explicites aux fichiers originaux et temporaires.
Évitez d’enregistrer le contenu des documents, les secrets ou les URL d’accès sensibles.

Masquer les actions de téléchargement, d’impression ou de menu contextuel peut soutenir le flux de travail prévu, mais cela ne remplace pas l’autorisation côté serveur et ne peut empêcher toutes les formes de capture une fois le contenu visible.

Intégrer Doconut dans l’expérience réactive

Doconut fournit la couche de visualisation de documents intégrée, tandis que l’application fournit la coquille réactive et le flux de travail métier.

Une séquence d’implémentation sensée est :

Confirmez les formats requis et les fonctionnalités du visualiseur.
Intégrez le package Doconut pris en charge pour votre application .NET.
Protégez la résolution du document avec une autorisation côté serveur.
Placez le visualiseur dans un conteneur hôte fluide appartenant à l’application.
Concevez des états compacts pour les barres d’outils de l’application et les panneaux secondaires.
Testez le redimensionnement, l’orientation, le focus, le chargement et le comportement en cas d’erreur.
Validez le résultat avec des documents similaires à la production et des sessions concurrentes.

Consultez la page produit Doconut Viewer vérifiée pour les informations produit actuelles. Utilisez la page officielle de téléchargement et de documentation pour les instructions d’installation et d’intégration spécifiques à la version, plutôt que de copier des exemples SDK non documentés provenant de publications tierces.

Liste de contrôle de révision du visualiseur réactif

Mise en page

Le visualiseur reçoit la plus grande part utile de la page.
Les largeurs fixes n’imposent pas de défilement horizontal.
Les panneaux secondaires se réduisent proprement.
La mise en page reste utilisable lorsque la hauteur du viewport est limitée.
Les états de chargement et d’erreur réservent l’espace approprié.

Interaction

Les contrôles de l’application ont des tailles cibles confortables.
Les actions essentielles ne dépendent pas du survol.
Les contrôles uniquement icônes ont des noms accessibles.
Le focus reste visible et suit un ordre logique.
Les tiroirs et dialogues restaurent correctement le focus.

Documents

Les gros PDF restent navigables.
Les grandes feuilles de calcul peuvent être inspectées sans rompre la mise en page.
Les dessins détaillés conservent un zoom et un panoramique utilisables.
Les noms de fichiers longs et les messages d’erreur ne débordent pas.
Modifier la taille de la mise en page ne redémarre pas le document inutilement.

Sécurité et opérations

Le serveur autorise chaque requête de document.
Les détails de stockage restent privés.
La rétention des fichiers et des données temporaires est documentée.
Les erreurs et les journaux excluent les informations sensibles.
Les limites de ressources et le comportement des sessions concurrentes sont testés.

Questions fréquentes

L’application doit‑elle maintenir des pages de visualiseur séparées pour les téléphones et les ordinateurs de bureau ?

En général, non. Une page réactive unique est plus facile à maintenir. Modifiez la mise en page en fonction de l’espace disponible et révélez progressivement les contrôles secondaires.

L’application peut‑elle remplacer le CSS interne du visualiseur ?

Évitez les sélecteurs et variables non documentés. Stylisez le conteneur hôte et vos propres contrôles d’application. Utilisez uniquement les points de personnalisation documentés pour la version de Doconut que vous déployez.

Les boutons de téléchargement et d’impression doivent‑ils être masqués sur les mises en page compactes ?

Il s’agit d’une décision produit plutôt que d’une frontière de sécurité. Si une action est autorisée mais ne convient pas, placez‑la dans un menu débordement accessible. Si elle n’est pas autorisée, appliquez cette politique sur le serveur.

Comment les gros documents doivent‑ils être testés ?

Créez une collection de tests assainie qui reflète le nombre réel de pages, les tailles de fichiers, les polices, les dessins et les feuilles de calcul. Répétez la suite après des changements de SDK, .NET, Windows Server ou de mise en page.

Conclusion

Une expérience mobile de documents solide commence par un conteneur fluide, une mise en page centrée sur le document, des contrôles confortables, des panneaux latéraux optionnels, un comportement de redimensionnement prévisible et une autorisation côté serveur.

Doconut peut fournir la capacité de visualisation au sein de votre application .NET sous Windows. Votre équipe pourra alors se concentrer sur la coquille réactive de l’application, les règles de sécurité et le flux de travail qui font du visualiseur une partie naturelle du produit.