문서 뷰어는 기술적으로는 기능적일 수 있지만 좁은 화면에서는 사용하기 어려울 수 있습니다. 복잡한 툴바, 작은 컨트롤, 과도하게 큰 사이드 패널, 고정된 크기의 컨테이너는 간단한 미리보기를 금방 좌절감이 드는 경험으로 바꿔버립니다.

Windows 기반 ASP.NET 및 .NET 애플리케이션의 경우, Doconut은 비즈니스 문서, PDF 파일, CAD 도면, 이메일 파일 및 이미지를 위한 임베디드 문서 보기 SDK를 제공합니다. 애플리케이션은 여전히 주변 레이아웃, 인증, 인가, 저장소 및 문서 워크플로를 제어합니다.

이 가이드는 그 주변 경험에 초점을 맞춥니다: 임베디드 뷰어에 충분한 공간을 제공하고, 애플리케이션 컨트롤을 사용하기 편하게 만들며, 방향 전환을 처리하고, 검증되지 않은 SDK 소스 코드를 의존하지 않고 현실적인 문서를 테스트하는 방법을 다룹니다.

뷰어 외부에서 시작되는 반응형 디자인

뷰어는 부모 레이아웃이 제공하는 공간만 사용할 수 있습니다. 애플리케이션이 뷰어를 좁은 카드 안에 배치하거나 고정된 데스크톱 너비를 지정하거나 여러 지속적인 패널로 둘러싸면 문서 영역은 계속 비좁게 유지됩니다.

다음 세 가지 질문으로 시작하세요:

이 페이지에서 주요 작업은 무엇인가요?
읽는 동안 어떤 애플리케이션 컨트롤을 계속 보여줘야 하나요?
어떤 보조 패널을 접거나 버튼 뒤로 숨길 수 있나요?

전용 문서 페이지의 경우, 뷰어가 보통 가장 큰 요소가 되어야 합니다. 메타데이터, 댓글, 승인 및 워크플로 작업은 문서에서 영구적인 공간을 차지하지 않고도 제공될 수 있습니다.

사용 가능한 공간에 따라 레이아웃 계획하기

반응형 동작은 특정 디바이스 이름에 대한 가정이 아니라 컴포넌트에 제공되는 공간을 기준으로 해야 합니다.

와이드 레이아웃

넓은 뷰포트에서는 페이지가 다음과 같이 표시될 수 있습니다:

문서 썸네일 또는 내비게이션 패널
메인 문서 캔버스
댓글이나 메타데이터용 보조 워크플로 패널
전체 애플리케이션 액션 세트

보조 패널이 드로어가 될 때는 다이얼로그 동작, 포커스 관리 및 디자인 시스템에서 요구하는 접근성 라벨링을 추가하세요.

애플리케이션 컨트롤을 터치 친화적으로 만들기

뷰어 주변의 컨트롤은 정밀한 포인터 움직임 없이도 편하게 활성화될 수 있어야 합니다.

실용적인 가이드라인:

인터랙티브 컨트롤의 목표 영역을 대략 44 × 44 CSS 픽셀로 설정합니다.
파괴적인 액션과 자주 사용하는 액션 사이에 충분한 간격을 둡니다.
필수 정보를 표시하기 위해 호버에 의존하지 마세요.
키보드 사용자를 위해 포커스 표시기를 항상 보이게 유지합니다.
아이콘 전용 버튼에는 접근성 이름을 제공하세요.
브라우저나 시스템 제스처 영역 근처에 중요한 컨트롤을 배치하지 마세요.

Doconut의 내부 스타일을 추측한 선택자나 문서화되지 않은 CSS 변수로 재정의하지 마세요. 설치된 SDK 버전에 대한 공식 리소스를 사용하고, 애플리케이션이 소유한 컨테이너와 컨트롤에만 반응형 규칙을 적용하세요.

사이드 패널을 선택적 작업 공간으로 다루기

썸네일, 검색 결과, 주석, 메타데이터 및 워크플로 히스토리는 유용하지만, 한 번에 모두 문서와 경쟁하게 해서는 안 됩니다.

컴팩트 레이아웃에서는:

사용자가 요청할 때만 사이드 패널을 엽니다.
닫힌 후에는 패널을 연 버튼으로 포커스를 반환합니다.
적절한 경우 모달 패널 내부에 포커스를 가두세요.
패널에 명확한 제목과 닫기 액션을 제공하세요.
패널을 열거나 닫을 때 문서의 현재 위치를 유지합니다.

뷰어가 자체 패널을 제공한다면, 두 번째 애플리케이션 수준 내비게이션 시스템을 추가하기 전에 해당 패널의 문서화된 반응형 동작을 테스트하세요.

문서 작업 공간을 빠르게 유지하기

반응형 디자인은 시각적인 것만이 아닙니다. 큰 문서는 메모리, 대역폭 및 렌더링 제약을 드러낼 수 있으며, 특히 페이지에 복잡한 대시보드나 애니메이션이 함께 포함된 경우 더욱 그렇습니다.

경쟁 작업 줄이기

사용자가 읽는 동안 장식용 애니메이션을 일시 중지하고, 뷰어 주변의 무거운 효과를 피하며, 불필요한 옵저버나 이벤트 리스너를 제거하세요.

레이아웃 공간 예약하기

뷰어 호스트에 로드되기 전에 안정적인 높이를 지정합니다. 이렇게 하면 큰 레이아웃 이동을 방지하고 사용자가 잘못된 컨트롤을 탭할 가능성을 줄일 수 있습니다.

보조 기능은 의도적으로 로드하기

댓글, 감사 히스토리 및 대형 메타데이터 패널은 첫 번째 문서 페이지와 함께 반드시 로드될 필요는 없습니다. 사용자가 관련 패널을 열 때까지 지연 로드하여 워크플로에 맞추세요.

대표 파일 테스트하기

길이가 긴 PDF, 넓은 스프레드시트, 상세한 CAD 도면, 대형 이미지 및 특수 폰트를 사용하는 문서를 사용하세요. 작은 샘플 파일만으로는 실제 환경의 한계를 파악하기 어렵습니다.

서버에서 접근 제어 유지하기

반응형 프레젠테이션이 애플리케이션의 보안 책임을 바꾸지는 않습니다. 모든 문서 요청은 여전히 인증 및 문서별 인가를 거쳐야 합니다.

ASP.NET Core 애플리케이션의 경우, 인증 미들웨어, 정책, 클레임, [Authorize] 특성 및 리소스 기반 인가와 같은 표준 메커니즘을 사용해 문서를 제공하는 서버 라우트를 보호할 수 있습니다.

애플리케이션은 다음을 수행해야 합니다:

서버에서 생성된 문서 식별자를 사용합니다.
현재 사용자가 요청된 문서에 접근할 수 있는지 확인합니다.
저장소 자격 증명 및 무제한 경로를 클라이언트에서 숨깁니다.
뷰어 페이지에 표시되는 오류를 정제합니다.
원본 및 임시 파일에 대한 명시적 보존 규칙을 적용합니다.
문서 내용, 비밀 또는 민감한 접근 URL을 로그에 남기지 않습니다.

다운로드, 인쇄 또는 컨텍스트 메뉴 액션을 숨기는 것은 의도된 워크플로를 지원할 수 있지만, 서버 측 인가를 대체하지 못하며 콘텐츠가 표시된 이후 모든 형태의 캡처를 방지할 수는 없습니다.

Doconut을 반응형 경험에 통합하기

Doconut은 임베디드 문서 보기 레이어를 제공하고, 애플리케이션은 반응형 쉘 및 비즈니스 워크플로를 제공합니다.

합리적인 구현 순서는 다음과 같습니다:

필요한 포맷 및 뷰어 기능을 확인합니다.
.NET 애플리케이션에 맞는 Doconut 패키지를 통합합니다.
서버 측 인가로 문서 해상도를 보호합니다.
뷰어를 유동적인 애플리케이션 소유 호스트 컨테이너에 배치합니다.
애플리케이션 툴바 및 보조 패널에 대한 컴팩트 상태를 설계합니다.
크기 조정, 방향 전환, 포커스, 로딩 및 오류 동작을 테스트합니다.
실제와 유사한 문서와 동시 세션으로 결과를 검증합니다.

현재 제품 정보를 확인하려면 검증된 Doconut Viewer 제품 페이지를 참고하세요. 버전별 설치 및 통합 지침은 공식 다운로드 및 문서 페이지를 이용하고, 서드파티 게시물의 문서화되지 않은 SDK 예제를 복사하지 마세요.

반응형 뷰어 검토 체크리스트

레이아웃

뷰어가 페이지에서 가장 큰 유용한 영역을 차지합니다.
고정 너비가 가로 스크롤을 강제하지 않습니다.
보조 패널이 깔끔하게 접힙니다.
뷰포트 높이가 제한될 때도 레이아웃이 사용 가능해야 합니다.
로딩 및 오류 상태가 적절한 공간을 예약합니다.

인터랙션

애플리케이션 컨트롤이 편안한 목표 크기를 가집니다.
필수 액션이 호버에 의존하지 않습니다.
아이콘 전용 컨트롤에 접근성 이름이 있습니다.
포커스가 보이고 논리적인 순서를 따릅니다.
드로어와 다이얼로그가 포커스를 올바르게 반환합니다.

문서

대형 PDF도 탐색이 가능합니다.
넓은 스프레드시트를 페이지 레이아웃을 깨뜨리지 않고 검사할 수 있습니다.
상세 도면은 사용 가능한 줌 및 팬 공간을 유지합니다.
긴 파일명 및 오류 메시지가 넘치지 않습니다.
레이아웃 크기 변경이 문서를 불필요하게 다시 로드하지 않습니다.

보안 및 운영

서버가 모든 문서 요청을 인가합니다.
저장소 세부 정보는 비공개로 유지됩니다.
파일 및 임시 데이터 보존이 문서화되어 있습니다.
오류와 로그에 민감한 정보가 포함되지 않습니다.
리소스 제한 및 동시 세션 동작이 테스트되었습니다.

흔히 묻는 질문

애플리케이션이 휴대폰과 데스크톱용으로 별도 뷰어 페이지를 유지해야 하나요?

보통은 아닙니다. 하나의 반응형 페이지가 유지 관리가 더 쉽습니다. 사용 가능한 공간에 따라 레이아웃을 변경하고 보조 컨트롤을 점진적으로 노출하세요.

애플리케이션이 뷰어의 내부 CSS를 재정의할 수 있나요?

문서화되지 않은 선택자와 변수를 피하세요. 호스트 컨테이너와 자체 애플리케이션 컨트롤만 스타일링하고, 배포하는 Doconut 버전에서 문서화된 커스터마이징 포인트만 사용하세요.

컴팩트 레이아웃에서 다운로드 및 인쇄 버튼을 숨겨야 하나요?

이는 보안 경계라기보다 제품 결정에 해당합니다. 동작이 허용되지만 화면에 맞지 않을 경우 접근 가능한 오버플로 메뉴에 배치하고, 허용되지 않을 경우 서버에서 해당 정책을 강제하세요.

대형 문서는 어떻게 테스트해야 하나요?

실제 페이지 수, 파일 크기, 폰트, 도면 및 스프레드시트를 반영한 정제된 테스트 컬렉션을 구축하세요. SDK, .NET, Windows Server 또는 레이아웃 변경 후에 테스트 스위트를 반복 실행합니다.

결론

강력한 모바일 문서 경험은 유동적인 컨테이너, 문서 우선 레이아웃, 편안한 컨트롤, 선택적 사이드 패널, 예측 가능한 크기 조정 동작 및 서버 측 인가를 기반으로 시작됩니다.

Doconut은 Windows 기반 .NET 애플리케이션에 보기 기능을 제공할 수 있습니다. 팀은 이제 반응형 애플리케이션 쉘, 보안 규칙 및 워크플로에 집중하여 뷰어가 제품의 자연스러운 일부처럼 느껴지도록 할 수 있습니다.