En dokumentvisare kan vara tekniskt funktionell och ändå kännas oanvändbar på en smal skärm. Täta verktygsfält, små kontroller, överdimensionerade sidopaneler och behållare med fasta dimensioner förvandlar snabbt en enkel förhandsgranskning till en frustrerande upplevelse.

För Windows‑baserade ASP.NET‑ och .NET‑applikationer erbjuder Doconut ett inbäddat dokument‑visnings‑SDK för affärsdokument, PDF‑filer, CAD‑ritningar, e‑postfiler och bilder. Din applikation styr fortfarande den omgivande layouten, autentisering, auktorisation, lagring och dokumentarbetsflöde.

Denna guide fokuserar på den omgivande upplevelsen: hur du ger en inbäddad visare tillräckligt med utrymme, gör applikationskontroller bekväma att använda, hanterar orienteringsändringar och testar realistiska dokument utan att förlita dig på otestad SDK‑källkod.

Responsiva dokumentvisningslayouter kopplade till en .NET‑server‑komponent

Responsiv design börjar utanför visaren

Visaren kan bara använda det utrymme som dess föräldralayout tillhandahåller. Om applikationen placerar den i ett smalt kort, ger den en fast skrivbordsbredd eller omger den med flera beständiga paneler, kommer dokumentområdet att förbli trångt.

Börja med tre frågor:

Vad är huvuduppgiften på den här sidan?
Vilka applikationskontroller måste förbli synliga medan du läser?
Vilka sekundära paneler kan kollapsa eller gömmas bakom en knapp?

För en dedikerad dokumentsida bör visaren vanligtvis vara det dominerande elementet. Metadata, kommentarer, godkännanden och arbetsflödesåtgärder kan förbli tillgängliga utan att ta permanent utrymme från dokumentet.

Planera layouten efter tillgängligt utrymme

Responsivt beteende bör följa det utrymme som komponenten har, inte antaganden om en specifik enhetsnamn.

Vid bred layout

På en bred vy kan sidan visa:

En dokument‑miniatur eller navigationspanel
Dokumentets huvud‑canvas
En sekundär arbetsflödespanel för kommentarer eller metadata
En komplett uppsättning applikationsåtgärder

När en sekundär panel blir en drar‑ut‑panel, lägg till dialogbeteende, fokus‑hantering och tillgänglig märkning som krävs av ditt designsystem.

Gör applikationskontroller pekvänliga

Kontroller runt visaren bör vara bekväma att aktivera utan exakt pekrörelse.

Praktiska riktlinjer inkluderar:

Ge interaktiva kontroller ett målområde på ungefär 44 × 44 CSS‑pixlar.
Lämna tillräckligt med avstånd mellan destruktiva och ofta använda åtgärder.
Förlita dig inte på hover för att avslöja viktig information.
Håll fokusindikatorer synliga för tangentbordsanvändare.
Tillhandahåll tillgängliga namn för knappar som bara innehåller ikoner.
Undvik att placera kritiska kontroller nära webbläsar‑ eller systemgestområden.

Åsidosätt inte Doconuts interna stilar med gissade selektorer eller odokumenterade CSS‑variabler. Använd de officiella resurserna för den installerade SDK‑versionen och tillämpa dina responsiva regler på de applikationsägda behållarna och kontrollerna.

Behandla sidopaneler som valfritt arbetsutrymme

Miniatyrer, sökresultat, anteckningar, metadata och arbetsflödeshistorik är värdefulla, men de bör inte alla konkurrera med dokumentet samtidigt.

På kompakta layouter:

Öppna en sidopanel endast när användaren begär den.
Återställ fokus till knappen som öppnade den efter att den stängts.
Fånga fokus inuti modala paneler där det är lämpligt.
Ge panelen en tydlig titel och en stäng‑åtgärd.
Bevara dokumentets aktuella position när panelen öppnas eller stängs.

Om visaren levererar egna paneler, testa deras dokumenterade responsiva beteende innan du lägger till ett andra navigationssystem på applikationsnivå runt dem.

Håll dokumentarbetsytan snabb

Responsiv design handlar inte bara om utseende. Stora dokument kan belasta minne, bandbredd och renderingskapacitet, särskilt när sidan också innehåller komplexa instrumentpaneler eller animationer.

Minska konkurrerande arbete

Pausa dekorativ animation medan användaren läser, undvik dyra effekter runt visaren och ta bort onödiga observatörer eller händelselyssnare.

Reservera layoututrymme

Ge visar‑värden en stabil höjd innan den laddas. Detta förhindrar stora layoutförskjutningar och minskar risken att användare trycker på fel kontroll.

Ladda sekundära funktioner med avsikt

Kommentarer, revisionshistorik och stora metadatapaneler behöver inte alltid laddas med den första dokumentsidan. Skjut upp dem tills användaren öppnar den relaterade panelen i enlighet med ditt arbetsflöde.

Testa representativa filer

Använd långa PDF‑filer, breda kalkylblad, detaljerade CAD‑ritningar, stora bilder och dokument med ovanliga typsnitt. Ett litet provfil avslöjar inte gränserna för produktionsupplevelsen.

Behåll åtkomstkontroll på servern

Responsiv presentation ändrar inte applikationens säkerhetsansvar. Varje dokumentförfrågan bör fortfarande gå igenom autentisering och dokument‑specifik auktorisation.

För ASP.NET Core‑applikationer kan standardmekanismer såsom autentiserings‑middleware, policies, claims, [Authorize]‑attributet och resurs‑baserad auktorisation skydda server‑rutten som levererar ett dokument.

Applikationen bör:

Använda server‑genererade dokument‑identifierare.
Verifiera att den aktuella användaren har åtkomst till det begärda dokumentet.
Hålla lagringsuppgifter och obegränsade sökvägar borta från klienten.
Sanera fel som visas på visarsidan.
Tillämpa explicita lagringsregler för original‑ och temporära filer.
Undvika att logga dokumentinnehåll, hemligheter eller känsliga åtkomst‑URL:er.

Att dölja nedladdnings‑, utskrifts‑ eller kontext‑meny‑åtgärder kan stödja det avsedda arbetsflödet, men det ersätter inte server‑sidig auktorisation och kan inte förhindra varje form av inspelning när innehållet är synligt.

Integrera Doconut i den responsiva upplevelsen

Doconut levererar det inbäddade dokument‑visningslagret, medan applikationen levererar det responsiva skalet och affärsarbetsflödet.

En rimlig implementeringssekvens är:

Bekräfta vilka format och visarfunktioner som krävs.
Integrera det stödjade Doconut‑paketet för din .NET‑applikation.
Skydda dokumentupplösning med server‑sidig auktorisation.
Placera visaren i en flytande, applikations‑ägda värdbehållare.
Designa kompakta tillstånd för applikationsverktygsfält och sekundära paneler.
Testa storleksändring, orientering, fokus, laddning och felbeteende.
Validera resultatet med produktionsliknande dokument och samtidiga sessioner.

Konsultera den verifierade Doconut Viewer‑produktsidan för aktuell produktinformation. Använd den officiella nedladdnings‑ och dokumentationssidan för versionsspecifik installation och integrationsinstruktioner snarare än att kopiera odokumenterade SDK‑exempel från tredjeparts‑inlägg.

Checklista för responsiv visar‑granskning

Layout

Visaren får den största användbara andelen av sidan.
Fasta bredder tvingar inte horisontell scrollning.
Sekundära paneler kollapsar snyggt.
Layouten förblir användbar när vyhöjden är begränsad.
Laddnings‑ och fel‑tillstånd reserverar lämpligt utrymme.

Interaktion

Applikationskontroller har bekväma målstorlekar.
Väsentliga åtgärder är inte beroende av hover.
Ikon‑endast‑kontroller har tillgängliga namn.
Fokus förblir synligt och följer en logisk ordning.
Drar‑ut‑paneler och dialoger återställer fokus korrekt.

Dokument

Stora PDF‑filer förblir navigerbara.
Breda kalkylblad kan inspekteras utan att bryta sidlayouten.
Detaljerade ritningar behåller användbart zoom‑ och panoramautrymme.
Långa filnamn och felmeddelanden överflödar inte.
Ändring av layoutstorlek startar inte om dokumentet onödigt.

Säkerhet och drift

Servern auktoriserar varje dokumentförfrågan.
Lagringsdetaljer förblir privata.
Fil‑ och temporär‑databevarande är dokumenterad.
Fel och loggar exkluderar känslig information.
Resursgränser och samtidiga‑session‑beteenden är testade.

Vanliga frågor

Bör applikationen ha separata visarsidor för telefoner och skrivbord?

Vanligtvis nej. En enda responsiv sida är lättare att underhålla. Ändra layouten efter tillgängligt utrymme och avslöja sekundära kontroller successivt.

Kan applikationen åsidosätta visarens interna CSS?

Undvik odokumenterade selektorer och variabler. Styla värdbehållaren och dina egna applikationskontroller. Använd endast de anpassningspunkter som dokumenterats för den Doconut‑version du distribuerar.

Bör nedladdnings‑ och utskriftsknappar döljas på kompakta layouter?

Det är ett produktbeslut snarare än en säkerhetsgräns. Om en åtgärd är tillåten men inte får plats, placera den i en tillgänglig overflow‑meny. Om den inte är tillåten, verkställ policyn på servern.

Hur bör stora dokument testas?

Bygg en sanerad testsamling som speglar faktiska sidantal, filstorlekar, typsnitt, ritningar och kalkylblad. Upprepa testsviten efter SDK‑, .NET‑, Windows Server‑ eller layout‑ändringar.

Slutsats

En stark mobil dokumentupplevelse börjar med en flytande behållare, en dokument‑först layout, bekväma kontroller, valfria sidopaneler, förutsägbar storleksändring och server‑sidig auktorisation.

Doconut kan leverera visningskapaciteten i din Windows‑baserade .NET‑applikation. Ditt team kan sedan fokusera på det responsiva applikationsskal, säkerhetsregler och arbetsflöde som får visaren att kännas som en naturlig del av produkten.