Adobe Flex Design

Flex 디자인하기

Flex 디자인하기 – Part 1: Flex 개요와 소개

롭 아담스(Rob Adams)는 캘리포니아주 샌프란시스코의 어도비 시스템즈(Adobe Systems, Inc.)에 근무하고

있다. 2004년 매크로미디어(Macromedia, Inc.)에 조인하여, 플래시 저작도구, 플래시 플레이어, 파이어웍스 등에

관련된 일을 한 바 있다. 현재는 Flex 제품군에 초점을 맞추고 있다. 핵심 프레임워크뿐만 아니라

디자이너/개발자 도구인 Flex Builder와 Creative Suite에 관련된 일도 병행하고 있다.

Adobe Flex 는 RIA(Rich Internet Applications)를 디자인하고 개발하기 위한 혁신적인 플랫폼이다.

RIA 는 애플리케이션의 새로운 트렌드로서, 전통적인 웹 및 데스크톱 환경의 제약에서 탈피하여

보다 풍부한 정보 중심의 유저 경험을 제공한다. Flex 는 RIA 를 쉽게 개발할 수 있도록 해주는

반면, 애플리케이션 개발자와 디자이너들에게 다른 각도의 애플리케이션 디자인 접근 방식을

요구한다. 전통적인 웹 및 데스크톱 애플리케이션을 만들 때와는 다르게 생각해야 한다는 것이다.

본 연재에서는 Flex 로 RIA 를 디자인할 때, 디자이너와 개발자들이 직면할 수 있는 이슈, 신기술,

새로운 시도 등에 해 다루고자 한다. 특히 Flex 애플리케이션 플래닝 및 구조화, 웹 및

데스크톱의 Flex 애플리케이션 디자인에 있어서의 고려사항, 리치 컨텐츠 디자인, 애플리케이션

디자인을 위한 적절한 모션 사용, 애플리케이션의 유용성 향상, 애플리케이션 사용에 따른 유저의

신뢰성 확보 등을 제시하고자 한다. 또한 관련된 컴포넌트와 샘플 코드 세트를 제공하여 여기서

소개하는 이론들을 적용할 때 도움이 됐으면 하는 바람이다. 또한 향후 어도비는 여러분의

프로젝트에 Flex 어플리케이션 디자인을 최적화 할 수 있도록 심도 깊은 방법론 ‘Flex Interface

Guidelines’ 출간을 계획 중에 있다.

앞으로 Flex 디자인하기는 총 8 회에 걸쳐 연재할 예정이며, 다음과 같은 순으로 연재한다.

• Part 1 : Flex 개요 및 소개

• Part 2 : 애플리케이션 플래닝하기

• Part 3 : 애플리케이션 구성하기

• Part 4 : 웹과 데스크톱 결합하기

Flex 디자인하기 1/125



• Part 5 : 컨텐츠 디스플레이 디자인하기

• Part 6 : 모션 활용하기

• Part 7 : 빠른 애플리케이션 만들기

• Part 8 : 안전한 애플리케이션 만들기

Flex 애플리케이션 디자인의 플래닝은 다른 애플리케이션 플래닝과 유사하다. 다만 유저의 목적,

유저가 사용하거나 만드는 컨텐츠, 목적을 성취하기 위한 유저의 작업과 워크플로우를 확실히

이해한다는 것이 전제된다(이 부분은 Part 2, 애플리케이션 플래닝하기 에서 다룰 예정이다).

Flex 애플리케이션은 웹 및 데스크톱의 페이지에서 페이지, 화면에서 화면으로의 엄격한 메타포를

따르지 않는 신 애플리케이션의 개별적 스크린들 내에서의 인터렉션에 중점을 둔다. 그 결과

Flex 애플리케이션은 전통적인 웹 사이트나 데스크톱 애플리케이션과는 다소 다르게 구조화

되어야 한다. Flex 애플리케이션은 information structures, process structures, creation

structures 라는 세 가지 구조로 구성돼 있고, 이들 모두는 각각 다르게 디자인되어야 한다(구조

디자인 부분은 part 3 에서 다룰 예정이다).

Flex 애플리케이션이 전통적인 웹 및 데스크톱 애플리케이션의 제약을 따르지는 않으면서, 웹 및

데스크톱이 가진 공통의 장점들을 수반하고 있다. 뒤로가기 버튼 지원, 즐겨찾기, 하이퍼링크

같은 웹 애플리케이션의 일반적 특징은 웹에서 유지되어야 한다. 데스크톱에서 파일 시스템,

네트워크 연결 변경, 화면과 메뉴 바 등이 유지되는 것처럼 말이다(본 내용은 part 4 의 웹과

데스크톱 결합하기에서 다룰 예정이다).

잘 디자인된 Flex 애플리케이션은 정보를 이해하고 시각화함으로써 유저의 컨텐츠를 우선시 할

수 있도록 하며, 필요한 경우 컨텐츠와 인터렉트할 수 있는 적절한 방법을 제시해준다(part

5 에서는 어떻게 Flex 의 강력한 그래픽 기능을 사용하여 유저들의 컨텐츠를 인터렉트할 수

있는지에 해 알아 볼 것이다).

과거 애플리케이션에서 모션이 남용됐던 것과는 다르게 Flex 는 모션을 디자인 수단의 한 파트로

기능을 제공한다(Part 6 에서는 Flex 디자인에서의 모션 사용에 해 다룰 것이다).

컴퓨터는 인간의 생산성 향상을 위해 고안된 것처럼, 애플리케이션의 유용한 사용은 매우

중요하다. 잘 된 Flex 애플리케이션은 빠른 시스템 성능과 적절한 도움을 제공함으로써 유저가

업무를 빠르고 쉽게 끝낼 수 있도록 돕는다(part 7 에서는 애플리케이션의 효과적인 사용과 빠른

애플리케이션을 만들 수 있는 방법에 해 설명한다).



마지막으로 유저가 신뢰하지 않는 애플리케이션은 존재의 의미가 없다. 좋은 Flex 애플리케이션은

유저들의 데이터와 신뢰를 안전하게 유지할 수 있어야 한다. 유저의 데이터와 신뢰는 테크니컬

측정 및 유저에게 지속적으로 정보를 제공- 유저의 액션과 결과치가 예측되어 유저가 실수를

두려워하지 않고 자신감을 갖게 된다-함으로써 지켜줄 수 있다(part 8 에서는 안전하게

애플리케이션을 만들기 위해 어떤 방법을 사용할 지를 다룰 예정이다).

Flex 발견하기

이 문서를 읽는 것으로 여러분은 벌써 Flex 애플리케이션 디자인의 세계에 발을 들인 것이다. 이

글을 읽고 있는 여러분 중에는 애플리케이션 디자인에 통달한 인터페이스나 인터랙션

디자이너이거나 애플리케이션을 만드는 UI 전문 개발자일 수도 있으며, 혹은 애플리케이션 디자인

프로젝트를 총괄하는 매니저나 비즈니스 분석가일 것이다. 본 문서는 Flex 애플리케이션 디자인

및 개발에 적용 확장할 수 있는 필수지식을 전달해 도움을 제공하고자 한다.

Flex 애플리케이션은 웹이나 데스크톱 방법론과는 많은 공통점을 가지고 있지만, 디자인에서는

특별한 접근이 필요하다. 본 세션은 다음을 다룬다.

• Flex 는 다른 기술들과 어떻게 다른가?

• Flex 가 RIA 를 만드는데 있어 왜 이상적인 기술인가?

• Flex 가 HTML 이나 데스크톱 기술에서 하던 기존 방식과는 다른 방식으로 디자인을 함에도 불

구하고 더 많은 편의성을 제공하는 이유는 무엇인가?

Flex RIA

앞에서 우리는 Flex 가 RIA 를 디자인하고 구축하는데 가장 최적의 플랫폼이라고 했다. Flex RIA 는

디자이너와 개발자들이 웹이나 데스크톱의 오래되고 낡은 제약에서 벗어나 애플리케이션을

구축할 수 있게 함으로써 사용자들에게 보다 유용하고 편리한 경험을 전달할 수 있다. 하지만

Flex 역시 성취해야 하는 새로운 디자인 과제와 새로운 환경에 한 사용자 기 에 부응해야

하는 두 과제를 안고 있다. 이러한 과제들은 잘 디자인된 Flex RIA 의 다음과 같은 두 측면에서

비롯된다.

• Flex RIA 는 웹 및 데스크톱 스타일이 합쳐져 있으므로, 웹과 데스크톱 사용자 모두의 기 를

만족시켜야 한다.

• Flex RIA 는 애플리케이션에서 모션 사용, 새로운 방법의 컨텐츠 렌더링, 그리고 인터넷을 통해

정보서비스에 접속한 상태에서 사용자의 컴퓨터에 다이렉트로 업데이트를 실행할 수 있는 기능


을 통해 새로운 디자인 가능성에 오픈되어 있다.

Flex 애플리케이션은 웹과 데스크톱의 장점만을 가져와 결합하고 있다. 부분의 Flex

애플리케이션은 전통적인 HTML 컨텐츠와 애플리케이션이 함께 나란히 웹 사이트 상에서

보여진다. 이 때 사용자들은 브라우저의 뒤로가기 버튼을 누르면 이전 사이트로 돌아 가고,

즐겨찾기와 하이퍼링크를 통해 원하는 페이지로 이동하며, 애플리케이션의 비주얼이 웹 사이트의

다른 부분과 한결 같을 것이라 기 한다. 또한 브라우저나 운영체제 소프트웨어에 상관없이

어디서나 어느 컴퓨터로나 애플리케이션에 접속하리라 기 한다. 즉, 환경에 맞는 ‘웹스러움

(web-ness)’을 기 하는 것이다.

<그림 1> Flex 로 제작된 Cotswold Outdoor 사이트는 웹 브라우저의 일반적인 스타일인 브라우저 뒤로가기

기능을 적절하게 지원하고 있다.

또한 Flex 는 다수의 데스크톱 운영체제의 웹과 같은 모습과 느낌을 전달한다. Flex 는 tabs,

sliders, trees, data grids 같은 고급 데스크톱 제어뿐 아니라 drag and drop, direct selection, in-

place validation 과 같은 고급 데스크톱 언어를 확실히 구현한다. 이들 제어와 언어는 사용

가능하고 지속적으로 구현되기 때문에 사용자들은 전통적인 웹 사이트에서 경험하지 못했던

풍부한 인터렉션을 기 하게 된다. 이들 두 매체를 결합하여 애플리케이션을 디자인하는 방법에

한 더 자세한 정보는 Flex 디자인하기 – Part 4: 웹과 데스크톱 통합하기에서 확인할 수 있다.



<그림 2> Adobe Premiere Express 는 웹 기반의 Flex 애플리케이션처럼 브라우저 안에서 드래그앤드롭 같은

많은 데스크톱 언어를 구현한다.

Flex 는 표준 웹 브라우저와 Flex 가 만들어진 Adobe Flash 기술을 강화함으로써 새로운 디자인의

가능성을 연다. 이 기술은 현재 Adobe Flash Player(전 세계 98%의 인터넷 연결 PC 에 설치된

브라우저 플러그인)와 Adobe AIR(Flex 애플리케이션을 통해 웹 브라우저 범위 밖의 사용자

데스크톱에 존재하는 런타임)라는 두 개의 호환성 있는 런타임 환경에서 가능하다. 두 개의

런타임 모두 웹 및 데스크톱 애플리케이션 디자인에 새 가능성을 여는 강력하고도 검증된 도구

세트를 제공한다. 이들 도구들은 다음 특징을 포함한다:

• 벡터 그래픽, 비트맵 그래픽, 고화질 비디오 사용을 위한 강력한 드로잉과 매체 API 로 애플리케

이션에 풍부한 정보 디스플레이를 만든다. 표적인 예로는 Google Finance 의 주식 차트와

YouTube 의 인터렉티브 비디오 플레이어가 있다(이들 도구를 사용하여 사용자가 정보를

이해하고 상호작용하는 것을 돕는 것에 한 보다 자세한 정보는 Flex 디자인하기 – Part 5:

컨텐트 디스플레이 디자인하기를 참조하기 바란다).

• 모션과 이펙트의 빌트인 지원은 사용자를 가이드 하는 새로운 방법을 제시하고 유용한 피드백



을 제공한다(이에 한 추가적 논의는 Flex 디자인하기 – Part 6: 모션으로 가이드 하기를

참조하기 바란다).

• 하드코어 개발자들이 원하는 로 애플리케이션을 만들 수 있을 만큼 충분히 강력하다. 최근의

코드 실행 엔진은 아직도 간단한 스크립팅 언어를 근간으로 하기 때문에 프로그래머가 아닌

사람도 코드로 자신의 아이디어를 표현할 수 있다. 이 엔진은 디자이너와 개발자들이 데이터

유효성, 정보 보호, 호출시간 줄이기 같은 많은 처리 업무를 위해 서버 보다는 사용자의

컴퓨터에서 사용할 수 있게 한다(이들 주제에 한 더 자세한 정보는 Flex 디자인하기 – Part

7: 빠른 애플리케이션 만들기(준비중)와 Flex 디자인하기 – Part 8: 안전한 애플리케이션

만들기(준비중)를 참조하기 바란다).

<그림 3> YouTube 와 Google Finance 는 비디오 플레이어와 인터렉티브 주식 차트를 위해 플래시 기술을

도입하여 사용자들이 제공된 정보를 더 잘 이해할 수 있도록 돕는다.

기본 기술과 환경의 변화는 당신과 사용자간의 새롭고 흥미로운 방법으로 커뮤니케이션할 수

있도록 한다. 하지만 이러한 변화들은 다른 매체를 디자인할 때와는 조금 다른 방법으로

생각하기를 요구한다. 다음 세션에서는 Flex 와 다른 중화된 클라이언트측 기술을 비교하여

이것을 설명하겠다.

Flex 와 HTML

HTML 은 하이퍼텍스트 문서를 위한 간단한 마크업 언어로 시작했기 때문에 ‘페이지’와 ‘페이지 –

페이지’ 모델을 고수해왔다. 컨텐츠는 페이지상에서 위에서 아래로 정렬됐고 마크업 태그는

컨텐츠의 다양한 블럭-특히 헤더, 단락, 이미지 등-의 뜻을 정의했다. 웹 디자이너들이

HTML 상에서 정적이지만 다채로운 레이아웃을 만들고자 했지만, 에이젝스가 등극하기 전까지는

기본적인 페이지-페이지 모델에 큰 변화를 주진 못했다.

HTML 기반의 웹 사이트와 애플리케이션 디자인의 일반적인 사고 프로세스는 페이지-하이퍼링크

모델과 매우 유사하다. 디자이너는 단일 페이지를 만들고, 이들 페이지를 사용자의 정보 계층



안에서 운영하는 경향이 있다. HTML 내에서 페이지가 인터렉션을 획득하기에는 어렵기 때문에,

전통적으로 디자이너들은 페이지 내에서의 인터렉션에 해 거의 생각하지 못한다. 그렇기 때문에

스크린을 업데이트해야 할 때마다 페이지 리로드 시간이 길어질 수밖에 없다. 하지만 이 페이지-

하이퍼링크 모델도 분명 장점이 있다. 일단 매우 간단하다. 웹 브라우저의 네비게이션 모델을 잘

표현하고 있고, 다수의 컴퓨터 사용자들이 이를 잘 이해하고 있다는 것이다.

<그림 4> 전통적인 HTML 웹 사이트(왼쪽)의 사이트 맵은 Flex 애플리케이션의 구조적 다이어그램(오른쪽)과

는 조를 이룬다. Flex 애플리케이션은 페이지의 계층구조에 컨텐트를 운용하는 신 하나의 스크린에서 더

많은 기능을 제공하는데 초점을 맞추고 있는 점에 주목하자.

Flex 애플리케이션 또한 일반적으로 다중의 상위레벨 페이지나 섹션을 가지고 있지만, HTML 과는

다르게 페이지와 페이지 사이에서가 아닌 페이지 내에서 흥미로운 인터렉션이 많이 이루어진다.

그러므로 디자이너와 개발자는 Flex 를 사용시 사용자 입력에 따라 페이지가 어떻게 응답할 지에

해 보다 깊게 생각해야 한다. 동시에 심플한 페이지 모델을 유지하면서 사용자 경험을

향상시켜야 한다.

AJAX 의 출현으로, 몇 가지 이슈들이 HTML 애플리케이션 디자인에서도 서서히 나타나고 있다.

이에 이 문서에서 지적하는 몇 가지 가이드라인은 HTML 에도 역시 적용할 수 있다. 그러나 AJAX

자체는 일반적으로 기존 HTML 페이지와 약간의 리치 인터랙티브 기능을 강화하는데 사용되므로

다수의 HTML 디자이너는 Flex 애플리케이션 디자이너처럼 인트라 페이지의 인터렉션에 해

깊게 생각할 필요가 없다. 하지만 이들 인터렉션이야말로 Flex(AJAX 와 함께) 애플리케이션을

매력적으로 만드는 요소다. 이 기술들이 효과적으로 사용된다면, 사용자들이 원하는 목적을

달성할 수 있도록 애플리케이션을 쉽게 조작할 수 있도록 해준다(페이지 내의 상호작용이 Flex



애플리케이션 구조에 어떤 영향을 끼치는지에 해 더 자세히 알고 싶다면 Flex 디자인하기 –

Part 3: 애플리케이션 구성하기를 참조하기 바란다).

<그림 5> 다수의 웹 애플리케이션은 Flex Cookbook(왼쪽)의 순위 매기기와 댓글달기 위젯처럼, 전통적인

HTML 페이지상에서 AJAX 로 리치 인터렉티브 기능의 작은 부분이나마 결합한다.



<그림 6> 반면 Flex Store 같은 Flex 애플리케이션은 탁월한 사용자 경험을 제공하기 위해 거의 모든 리치

인터렉티브 기능으로 구성되어 있다.

Flex 와 데스크톱 클라이언트

웹 애플리케이션 개발이 두되기 전에는, 데스크톱 기반의 ‘무거운 클라이언트(fat clients)’이

인터넷 애플리케이션을 디자인, 개발, 설치하는데 가장 중적인 방법이었다. 오늘날에도 여전히

많은 프로젝트에 사용되고 있다. 데스크톱 클라이언트는 체로 사용자 인터페이스 디자인(창,

아이콘, 메뉴, 포인팅 도구) WIMP 스타일을 따랐으며, MFC, Cocoa, Java Swing 같은 데스크톱

사용자 인터페이스 툴킷을 사용하여 만들어졌다. 또한 사용자 인터페이스 제어 또는 위젯(버튼,

체크박스, 슬라이더, 데이터 테이블 같은) 클러스터를 위젯 혹은 윈도우 스크린 맨 위에 나타나는

편재된 메뉴 바와 상호작용함으로써 작업을 수행하고 데이터를 볼 수 있는 다양한 애플리케이션

창에 모았다. 여기서 디자이너들이 가지는 가장 주요한 질문은 어떻게 이 제어 팔레트를 사용하여

사용자들이 원하는 윈도우를 레이아웃 하는가 이다.



<그림 7> 기존의 무거운 클라이언트 데스크톱 애플리케이션의 예이다. 다수의 인터페이스는 플랫폼 툴

킷으로 정의되는 표준 제어로 이루어져 있다(Microsoft Windows 경우).

데스크톱 클라이언트 기술처럼, Flex 도 표준 사용자 인터페이스 제어의 풍부함을 제공한다.

하지만 데스크톱 클라이언트 기술과는 다르게, Flex 는 맞춤화된 아크워크, 모션, 인터렉션을 통해

디자이너와 개발자들이 프레임워크를 다양한 방법으로 확장할 수 있도록 하는 플래시 플레이어의

리치 그래픽과 모션 능력을 또한 제공한다. 이를 통해 디자이너들은 표준 제어 팔레트만으로

보여지는 것보다 인터렉티브한 비주얼을 통해 사용자 경험을 유도하고 데이터를 보여 준다.

다수의 사용자 인터페이스의 툴 킷은 주된 운영체제와 접하게 연결되어 있는 윈도우 관리에

강력한 목적이 있다. 하지만 다수의 Flex 애플리케이션은 윈도우 기반의 인터페이스가 웹

상에서 보여지지 않는 것처럼 윈도우를 완전히 막는다. 그리고 다수의 웹 애플리케이션에 있어

다중 창의 장점은 사용자가 창 사이를 드나들고 이를 정렬할 때 가장 뛰어나다(Flex

애플리케이션이 AIR 을 겨냥했다는 것은 사실이 아니다. 그리고 AIR 애플리케이션도 기존의

데스크톱 애플리케이션이 그러는 것처럼 무겁게 멀티 윈도우에 전적으로 의존하지 않는다). 신

Flex 는 멀티 윈도우를 탈피하여 하나의 한결같은 경험으로 확장되는 통합 기능을 선호한다.

Adobe Flash Player 의 비주얼 표현력과 윈도우 관리의 부재 간의 결합은 스크린 상의 제어

관리와 사용자를 위한 비주얼 정보, 정보와 인터렉션할 수 있는 기회를 제공하는 것에 의해

우리가 심도깊게 고민할 필요가 없다는 이점을 제공한다.



Flex 와 기존 Flash

Flex 와 Adobe Flash 저작 도구를 사용하여 만들어진 전통적인 플래시 컨텐트의 차이점을

이해하는 것은 쉽지 않다. 이들 모두가 Adobe Flash Player 에서 만들어진 ‘플래시 기반’ 이라는

동일한 핵심기술로 만들어졌기 때문이다.

<그림 8> Homestar Runner 은 기존의 Flash 사이트의 표적인 예로, 플래시 저작도구로 만들어진 사이트다.

하지만 Flex 와 Flash 는 디자인 및 개발 모델에서 완전히 다르다. 플래시 디자이너와 개발자들은

시간과 애니메이션 메타포에 해 전통적인 플래시 컨텐츠를 만들었다. 스토리를 만들어 제품이나

서비스 광고 개념을 가르치거나 혹은 자신의 스토리를 얘기한다(유머 사이트인 ‘Homestar

Runner’은 스토리텔링 자체를 보여주는 좋은 예다). Flash Player 의 인터렉티브한 개발 능력이 더

강력해짐에 따라 어떤 플래시 전문가들은 이 기술을 더욱 진보시키고 전통적인 애플리케이션의

복잡성과 어깨를 겨루는 큰 데이터의 플래시 경험을 창조한다. 이것을 ‘Rich Internet Application’

또는 ‘RIA’로 이들의 경험을 설명하고 있다. 하지만 플래시 툴의 한계와 작금의 기술력으로 인해

장기적 지원과 보수 지원을 필요로 하는 복잡한 애플리케이션을 만드는 것이 다소 어렵고 비용

비 비효율적이다. 그러므로 다수의 전통적인 플래시 컨텐츠는 미디어와 웹 상의 스토리텔링에

초점을 맞추고 있다.

Flex 프레임워크는 웹 또는 데스크톱 상에 배포된 RIA 를 디자인하고 개발하기 위한 애플리케이션

에 중점을 방법론을 제공한다. Flash 와 달리 Flex 의 주요한 운용 메타포는 시간이나 애니메이션



이 아닌, 스크린과 상태다. 시간과 애니메이션은 여전히 Flex 의 가장 중요한 요소지만 하나의

상태에서 다음 상태로 사용자를 이동할 때 가이드로서 사용될 뿐이다. Flex 에서 디자이너들은

피드백을 통한 사용자의 이해력을 높이기 위해 비주얼 효과로 모션을 사용한다. 반면,

인터텍티브한 무비처럼 전체적인 사용자 경험을 운용하는 것은 아니다. 그러므로 Flex

애플리케이션을 디자인하는 것은 최고 수준의 전통적 HTML 이나 데스크톱 애플리케이션을

디자인하는 것과는 유사하지만, 개발자나 디자이너들이 Flash 의 모션을 사용하여 보다 유연하고

자연스러운 애플리케이션을 만들 수 있다.

<그림 9> Flash 저작의 선형 애니메이션 모델은 Flex 의 비선형 모델과 조를 이룬다. 상태 모델은 시스템

을 통해 사용자들이 받아들이는 많은 경로 때문에 애플리케이션에 더 선호하는 경향이 있다.

이런 차이에도 불구하고 Flash 와 Flex 는 모두 동일한 플랫폼의 일부분이고, 그래서 상호운용이

가능하다. 만약 Flash 저작 도구의 애니메이션 중심의 접근법을 사용하여 애플리케이션을 만드는

것이 더 적절하다면, Flex 애플리케이션의 주 요소로 통합할 수 있다. Flex 애플리케이션상에서

기존의 Flash 컨텐츠를 그 로 사용하거나 아니면 손에 익은 Flash 저작도구를 선호하는 것이,

Flex -Flash 의 상호 운용성을 부정하는 것이 아니라는 것이다.

강력한 기능에 따르는 막중한 책임감

지금쯤이면 Flex 가 이전의 사용자 인터페이스 기술 매체와 어떻게 다른지 확인했을 것이다.

Flex 의 강력한 기능과 유연성을 맛보았고, Flex 프레임워크를 목표로 애플리케이션을 디자인하는

것이 다른 매체의 애플리케이션과는 약간 다른 사고를 요한다는 것도 알게 되었다. 하지만 항상

기억해야 할 것은 Flex 가 사용자와 여러분이 완전히 새로운 방법으로 소통하는 길을 열었지만,

새로운 잠재적 이슈도 지니고 있다는 것이다. 이는 우리가 디자이너든 개발자든 간에 상관없이,

이 새로운 매체의 능력을 효과적으로 사용하여 사용자와 비즈니스에 혜택을 주는 것이다. 이 글이




이를 효과적으로 사용하는 방법을 설명하고 있다(더 많은 것을 배우고자 한다면, 후속 글인 Part

2: 애플리케이션 플래닝하기를 추천한다).



Flex 디자인하기 – Part 2: 애플리케이션 플래닝하기

Flex 디자인에 한 자세한 컨텐츠에 들어가기에 앞서 Flex 애플리케이션을 플래닝하는 방법에

해 알아보자. Flex RIA 디자인의 플래닝 프로세스는 형 애플리케이션 프로젝트가 요구하는

것과 비슷하지만, 몇 가지 새로운 점과 기존 특징이지만 Flex RIA 이기에 주의해야 하는 몇

가지가 있다. 본 글에서 다루는 부분은 다음과 같다:

• Flex 애플리케이션 디자이너와 개발자가 반드시 알아야 하는 다섯 가지 데이터 포인트: 타겟

마켓, 타겟 고객, 목표, 컨텐츠, 업무

• 고객의 컨텐츠를 디자인 및 시각화 위해 준비 방법

• 고객 업무와 워크플로우에 한 애플리케이션 디자인하는 방법

본 글은 여러 분야에 걸쳐 있는 디자인이나 개발 프로세스에 나타나는 사항들을 참조하고 있다.

Flex 는 특정 프로세스를 필요로 하거나 선호하지 않는다. 여러분이 선행 디자인 기능(예를 들어

목표지향적 디자인 혹은 컨텐츠 지향적 디자인)을 강조하는 프로세스든, 디자인 및 개발을 합한

인터렉티브한 프로세스를 사용하든, 모두 성공적으로 Flex 애플리케이션을 디자인할 수 있다.

이들 기능을 여러분의 프로세스에 통합하거나, 혹은 특정 프로세스 자체가 없을 경우, 이 방법을

따르기만 해도 된다. 본 글은 다음의 연재들로 구성돼 있다:

• Part 1 : Flex 개요 및 소개

• Part 2 : 애플리케이션 플래닝하기

• Part 3 : 애플리케이션 구성하기

• Part 4 : 웹과 데스크톱 결합하기

• Part 5 : 컨텐츠 디스플레이 디자인하기

• Part 6 : 모션 활용하기

• Part 7 : 빠른 애플리케이션 만들기

• Part 8 : 안전한 애플리케이션 만들기

이 글을 시작하기 전에 Part 1 을 읽기 권한다. 이 컨텐츠는 공개된 초안이다.


고객 이해하기

일반적으로 제품을 기획할 때는 현재 또는 잠재적 마켓을 이해하는 것이 순서이다. 마켓을 이해하

는 최종적으로 제품을 구매할 고객을 이해한다는 뜻이다. 제품이 인트라넷 같은 기업 내부전용이

라 할지라도, 마켓은 구매력과 접한 인구 통계 데이터로 정의되곤 한다. 물론 여러분이 비영리

단체나 정부 기관에서 일한다면 다른 방법으로 마켓을 정의해야 할 것이다. 마켓을 이해하는 것은

Flex 애플리케이션뿐만 아니라 다른 제품에도 매우 중요하다.

하지만 애플리케이션 측면에서는, 마켓을 이해하는 것만으로는 충분하지 않다.

이 경우 마켓뿐만 아니라 타겟 고객을 명확히 해야 한다. 고객을 이해한다는 것과 마켓을 이해하

는 것을 혼동스러울 수 있다. 이들 둘은 관련이 있긴 하지만 같은 건 아니다. 마켓 데이터는

방 하고, 숫자적으로 측정가능한 편이다(그래서 예상 매출액과 연관이 있을 수 있다). 목표

마켓은 ‘위성도시에서 사는 25 세에서 45 세 사이의 엄마들’, ‘R&D 부서원들’, ‘캘리포이나 주

투표권자’라는 식으로 설정될 수 있다. 이 정보를 명확히 하는 것은 가격 결정, 마켓 메시지,

효과적인 고객 정의에 매우 중요하다. 하지만 마케팅 데이터 자체만으로는 Flex 애플리케이션을

디자인하는 것은 충분한 정보를 포함할 수 없다.

마켓 인구 통계를 이해하는 것만이, 디자인 자체를 가이드하는 것은 아니다.

이러한 정보를 얻기 위해서는 통계 뒤에 있는 사람들에 초점을 맞추어야 한다. 마케팅 데이터는

여러분의 제품을 사용할 사람들을 정의하는데 사용한다. 다음은 그 사람들이 무엇을 하는지,

어떻게 생각하는지, 무엇을 원하는지 등의 사람들의 행동에 관한 질적 데이터에 초점을 맞춘다.

이러한 데이터를 얻는 중적 방법은 잠재적 고객들의 니즈와 바람을 인터뷰하거나, 여러분의

제품으로 고객들이 집이나 직장에서 어떤 업무를 수행하는지 방문하고, 하루 일과 정리를

요청하는 등의 방법이 있다. 이들 업무는 마켓 조사 연구원을 통해 플래닝 및 실행하는 것이 좋다.

어떤 방식의 마켓 조사를 하든, 아니면 아예 하지 않든 간에, 중요한 몇 가지 질문에 해답을

가지고 있어야 한다.



<그림 1> 애플리케이션 플래닝은 서로 연관되어 있다. 마켓을 구분하면 고객을 정의할 수 있게 되고,

여러분의 애플리케이션을 사용하는 고객의 목표를 확실히 할 수 있으며, 이 목표는 고객들의 업무에 동기를

부여한다. 이 모든 정보는 성공적인 Flex 애플리케이션 디자인에 도움이 된다.

먼저 고객의 목표, 즉 제품을 사용하는 이유가 무엇인지 이해해야 한다.

예를 들어 회계 애플리케이션을 디자인한다고 가정하자. 한 고객은 최신 정보를 최신 마켓 정보를

강력한 그래픽 분석 툴을 통해 그들의 투자를 결정하기를 원한다고 하자. 다른 고객은 최소한의

시간을 투자하여 회계만을 정리하고자 한다고 하자. 두 가지 모두 타겟 고객이 누구인지에 따라

최적의 목표가 결정되겠지만, 둘 중 어떤 방식으로 디자인하느냐에 따라 결과물은 매우 달라질

것이다. 동일한 고객 경험을 기반으로 두 타입의 고객 모두를 만족시키고자 한다면 모두에게

절망적일 것이고, 애플리케이션 디자인은 또한 재앙이 될 것이다.

프로젝트와 관련된 고객 목표를 이해하자.

둘째로 고객이 업무에 이용하는 툴과 장비를 이해해야 한다. 휴 용 오디오를 디자인하려면

고객의 음악 컬렉션을 들어봐야 하고, 사진 브라우저의 경우 고객의 사진을 점검해야 한다.

비즈니스 관리 지원 시스템의 경우도, 고객이 사용하는 형식과 기록, 데이터베이스를 점검해야

한다. 동시에 툴뿐만 아니라 고객이 이 장비로 무엇을 하는지도 이해해야 한다.

지금 여러분의 고객이 사용하거나 만드는 툴과 장비를 검토하라.

<그림 2> 고객이 정기적으로 사용하거나 만드는 주요 장비를 복사하자. 고객이 이 장비로 무엇을 하는지,

장비에 주석을 달아놓는 것은 때로는 좋은 아이디어가 될 수 있다. 위의 예는 기업의 상환형식의 사용법을

설명하고 있다.



마지막으로 현재 제품을 사용하고 있는 고객이 어떤 식으로 제품을 사용하는지를 이해하는

것이다. 생산성 높은 소프트웨어의 경우, 이를 ‘워크플로우’ 또는 ‘업무’라 부른다. 필자는 이

단어들을 계속 쓰겠지만, 여러분이 만약 엔터테인먼트나 교육시장의 제품 디자인을 한다면 다른

단어를 사용하고 싶을 수도 있다. 만약 소수의 제품만이 있다면 완전히 새로운 워크플로우를

제시한다. 반면 고객은 어떻게든 항상 자신의 목표를 달성하려고 한다. 고객들이 제품을 통해 더

효과적이고 즐거운 워크플로우를 갖게 된다 하더라도 지원 방법과 이유를 이해한다면 실제로

고객들의 삶을 더 낫게 하는 새로운 방법이 될 것이라는 것을 명확히 하자. 오늘날 여러분의

고객이 수행하는 문서 작업은 그들의 목표를 달성시키고자 하는 것이다.

<그림 3> 업무와 워크플로우는 위와 같이 도식으로 표현하는 것을 제언한다. 도식에 Flex 애플리케이션에서

언급해야 하는 현 문제점과 기회를 주석으로 달아놓으면 편리하다.

이해하는 것만큼 최고의 커뮤니케이션은 없다. 고객의 목표, 장비, 워크플로우를 완벽히

이해했다고 판단되면 디자인 및 개발 팀원들과 커뮤니케이션하라. 이해한 바를 문서화하면 디자인

프로세스 과정에 쉽게 참조할 수 있다.

여러분의 디자인 시도에 따라 고객의 작업환경, 조직 문화 등의 자세한 사항에 해 여러분은 더

알아보고자 할 것이다. 고객의 목표, 사용 장비, 참여 등과 같은 고객의 주요 행동을 제 로

이해한다면 훌륭한 Flex 애플리케이션을 디자인할 수 있을 것이다. 향후 그 이유에 해

거론하겠다.



컨텐츠 플래닝하기

‘컨텐츠’은 일반적으로 Flex 애플리케이션의 ‘명사(nouns)’로 일컫는다. 고객의 작업, 고객의 구매

제품, 고객이 접하는 매체, 심지어 고객이 친구들에게 보내는 메시지 등이 포함되는 컨텐츠들은

여러분의 애플리케이션 제안의 중심부에 있다. 컴퓨터 기술기반의 고객 목표는 컴퓨터를 정보

머신으로, 컨텐츠를 폭넓은 단어에 담긴 정보로 간주한다.

<그림 4> 애플리케이션의 컨텐츠는 많은 형식을 가질 수 있다. 위의 예는 아주 작은 샘플에 불과하며

인간이 만드는 혹은 소비하는 어떠한 정보라도 Flex 애플리케이션의 컨텐츠가 될 수 있다. 디자인하기 전에

여러분의 애플리케이션 컨텐츠를 미리 이해해야 한다.

Flex 와 Flash 는 컨텐츠를 비주얼 및 조작하는 강력한 툴을 제공한다. 핵심 Flash Player 의

그래픽, 오디오, 비디오 기능 등을 통해 다양한 매체 타입으로 풍부한 랜더링을 할 수 있다. Flex

프레임워크는 네트워크 상에서 매체를 스트리밍으로 다이나믹한 매체로 만들 수 있는 툴을

제공하여 고객이 새로운 방법으로 인터렉션할 수 있게 한다. 이들 툴은 여러분이 컨텐츠를

여러분의 최우선 애플리케이션에 위치할 수 있게 한다. 훌륭한 Flex 애플리케이션은 고객이

애플리케이션 위젯 레이어들을 오고 가며 작업하는 신, 고객이 직접 컨텐츠를 작업할 수 있도록

해 준다.

애플리케이션을 효율적으로 디자인하려면 컨텐츠와 더불어 고객이 그 컨텐츠로 무엇을 할 지

명확히 이해해야 한다.

첫 번째 단계는 목표 고객이 현재 사용하는 툴과 장비를 점검하는 것이다. 이것을 기반으로

고객이 애플리케이션에서 작업해야 하는 컨텐츠 리스트를 만들고 속성을 기록한다. 예를 들어,

음악 플레이어를 디자인할 때 리스트는 제목, 가수, 앨범, 재생목록 등이 여러분의 리스트에




포함되어야 한다. 이 작업은 애플리케이션을 사용하는 동안 고객이 생각하는 방향으로 컨텐츠를

기술하는 것으로, 소프트웨어 개발의 데이터 모델링과 비슷하다. 다만, 관계형 데이터베이스의

테이블에 맞출 데이터의 기술적 구조를 정의하는 부분은 제외된다.

여러분의 애플리케이션이 지원해야 하는 컨텐츠 타입을 정의하게 되면, 여러분은 디자인

프로세스를 통해 사용하는 컨텐츠의 실제 샘플을 얻게 된다. 실제 샘플의 컨텐츠는 컨텐츠 중심의

애플리케이션을 생산하는 디자인 프로세스의 핵심 요소이다. 실제 샘플이 없다면, 디자인

프로세스는 고객 인터페이스의 위젯에 과도한 관심을 갖게 돼 많은 버튼, 슬라이더, 기타

애플리케이션 등을 남발함으로써 정작 중요한 컨텐츠를 효율적으로 사용할 수 없게 된다.

애플리케이션에서 고객이 접속할 컨텐츠 타입을 나열하고 레퍼런스로 실제 샘플을 갖자.

업무 및 워크플로우 플래닝하기

여러분의 애플리케이션에서 컨텐츠가 ‘noun’라면, 업무와 플로우는 ‘verb’다. 여러분의

애플리케이션 업무와 플로우는 고객이 무엇을 할 지, 애플리케이션을 사용하여 어떻게 목표를

달성할 지를 나타낸다. 업무와 플로우는 일반 고객이 여러분의 애플리케이션을 사용하여 어떻게

목표를 달성할지를 시나리오나 짧은 글로 나타내는 것이 최고의 방법이다. 예를 들어, 회계

시스템의 시나리오는 ‘비용 제출하기’라 할 수 있다.

스티븐은 출장을 일주일 다녀온 후 비용 보고서를 제출한다. 영수증 뭉치를 꺼낸 후 브라우저를

띄우고 비용보고서시스템으로 이동한다. ‘새 보고서’를 클릭하고 각각의 영수증을 확인한 후 폼에

날짜, 비용, 타입 등을 입력한다. 하나의 비용 정산이 끝나면, 또다른 새로운 아이템이 뜬다.

회식의 경우, 회식 목표를 추가적으로 자세히 입력해야 한다. 글자 입력칸이 나타나면 정보를

입력한다.

모든 영수증을 다 처리한 후 스티븐은 ‘보고서 제출’ 버튼을 클릭한다. 보고서를 완성하기 위해

회계부서로 영수증을 어떻게 보내는지를 설명하는 화면이 뜬다.

업무와 플로우는 고객이 Flex 애플리케이션을 어떤 방식의 네비게이션을 사용하는지와 어떤

기능을 결합하여 사용하고자 하는지를 여러분이 이해하는데 도움을 줄 것이다. 훌륭한 Flex

디자인을 위해 여러분의 애플리케이션을 정확하게 이해하는 것이 아주 중요하다. 고객이 원하는

바를 정확하게 파악하지 못한다면 유연한 Flex 를 디자인할 수 없다.

고객이 여러분의 애플리케이션을 기반으로 실행하는 주요 작업을 도식화 하는 시나리오를

작성하자.


여러분이 개발하는 업무와 플로우는, 플래닝 단계에서 미리 검토한 고객의 기존 워크플로우를

이해하는 데서 출발해야 한다. 고객이 여러분의 제품을 기반으로 현재 작업을 어떻게

수행하는지를 이해해야 플로우를 정의하는데 도움이 된다. 또한 고객의 업무 단계를 이해한다면,

어떤 미묘한 차이도 놓치지 않게 된다. 이런 검토가 없다면, 고객의 니즈를 충족시키지 못하는

시스템을 디자인하게 되고, 이전보다 더 열악한 상태로 만들 수 있다.

<그림 5> 가상의 온라인 요금지불시스템의 워크플로우를 비교한 도식이다. 과거의 워크플로우에서는 요금을

각각의 다른 화면에서 나눠 지불해야 했으나, 새로운 워크플로우에서는 하나의 화면에서 모든 요금을 지불할

수 있다. 여러 개의 요금을 한꺼번에 자주 지불해야 고객에게는 새로운 워크플로우가 더욱 매력적으로

다가간다.

고객이 현재의 업무 수행 방법을 향후에 사용할 Flex 애플리케이션에 직접적으로 옮겨서는

안된다. 이 말은 현재 사용하는 기능에 추가적인 단계를 넣어 새로운 워크플로우로 옮겨야 한다

<그림 5 참조>. 기술은 업무와 플로우의 신선하고 용이한 방법을 통해 목표를 수행할 수 있도록

시간에 따라 진보한다. 워싱턴 DC 에서 보스톤으로의 여행은 200 년 전과 지금을 비교할 때,

완전히 다른 작업이다. 시카고에서 지연될지언정 말이나 마차를 이용하는 것보다는, 비행기를

이용하는 것이 훨씬 효율적이다. 여러분이 고객의 현재 작업에만 너무 몰두된다면 고객이 미래에

원하는 작업을 만족시켜줄 수 없다.

고객의 니즈와 바람을 기반으로 하는 목표는 거의 변하지 않는다. 새로운 가능성을 꿈꾸는

여러분의 경험 지식을 발휘해라. 반면 현재 고객이 사용하는 컨텐츠와 업무에 한 여러분의

이해도를 비교하여 테스트해 보라. 이렇게 하면 고객의 니즈에 부응하는 훌륭한 Flex

애플리케이션을 디자인할 수 있다.




Flex 디자인하기 – Part 3: 애플리케이션 구성하기

구조적 디자인 프로세스는 다음과 같은 질문에 답을 제시한다. 가장 앞단에 보여줄 중요한 정보나

기능은 무엇인가? 사용자는 어떻게 주요 업무를 마무리할 것인가? 목표 달성을 위해

애플리케이션의 특정부분에서 다른 부분으로 어떻게 이동할 것인가? 다음에 무엇을 할 지 결정을

하는데 필요한 정보를 어떻게 파악하고 배열, 평가할 것인가?

구조적 결정은 애플리케이션 사용성이나 니즈에 중 한 영향을 준다. 또한 개발 프로세스 막판에

문제가 생겼을 때 이를 바꾸는 것이 어렵다는 것을 가끔 보여준다. 이런 이유로 HTML

애플리케이션 개발에 있어 와이어프레임 혹은 페이지의 낮은 정 도 표현을 만들고 사용자가 한

페이지에서 다음 페이지로 이동을 설명하는 플로우 다이어그램을 만드는데 엄청난 시간을

보내곤한다. Flex 애플리케이션 디자인에서 구조는 매우 중요하다. 다만 Flex 애플리케이션이

전통적인 HTML 이나 데스크톱 애플리케이션과는 다르게 구성되기 때문에, 구조에 해 약간 다른

견지에서 생각해봐야 한다.

본 글에서 다루는 부분은 다음과 같다.

• 애플리케이션 구조의 세 가지 타입: 정보, 프로세스, 창작

• 애플리케이션 구조를 디자인하는데 이들 구조를 접목하는 방법

• 사용자와 바로 맞닿아있는 애플리케이션의 엔트리 포인트나 첫 페이지를 디자인하는 방법

• 사용자의 업무가 무엇인지를 알고 유연하게 쉽게 목표를 달성할 수 있도록 돕는 방법

• 비주얼 계층 원칙을 채택하여 화면, 사용자를 안내할 수 있는 방법

이 글을 시작하기 전에 앞에서 다뤄진 Part 1 과 2 를 꼭 읽기를 권유한다.

세 가지 구조

디자이너와 개발자들은 다양한 사용자와 그들의 다양한 활동을 위해 Flex 애플리케이션을 만든다.

하지만 애플리케이션의 폭넓은 스펙트럼을 살펴 보면 이들의 구조는 크게 정보, 프로세스,

창작이라는 세 가지 구조 타입으로 나눠진다.

정보 구조(information structure)의 예에는 온라인 상점의 제품 브라우저, 경영 시보드, 뉴스

리더기, 미디어 플레이어 등이 있다. 정보 구조는 애플리케이션 컨텐츠로 만들어지고 일차적으로

사용자와 새 정보 간의 소통을 목적으로 만들어진다. 이들 구조는 사용자들이 새 추론과 사용자의


목표를 높이는 방법에 한 정보를 이해할 수 있도록 폼 형식에 애플리케이션 데이터를 넣어

보여줌으로써 적절한 결정을 내릴 수 있도록 한다. 다수 정보 구조의 목표는 사용자가 특별한

노력 없이도 적절한 정보를 바로 얻을 수 있도록 하는 것이다.

<그림 1> Flex Store 제품 브라우저인 Oakland Crimespotting 지도와 Amegen Tour of California 레이스

트래킹 뷰는 정보 구조의 예다.

프로세스 구조(process structure)의 예에는 온라인 뱅킹 청구-지불 시스템, 상점 결제 프로세스,

제품 구성 등이 있다. 이들 구조는 사용자가 특정 업무를 수행하는데 도움이 되도록 만들어졌다.

사용자의 작업 전반에 걸쳐 각 단계를 마치는데 필요한 정보를 제공하고, 사용자로부터 정보를

받는 것에 더 집중한다. 다수 프로세스 애플리케이션의 목표는 사용자로부터 가능한 쉽고

빠르게 정보를 수집하는 것이다.

<그림 2> 보험 청구 위자드, Flektor 비디오 편집기, Adobe.com 계정 정보 편집기는 프로세스 구조의 예다.

창작 구조(creation structure)의 예에는 데스크톱 저작 도구, 비디오 편집기, 음악 시퀀서 등이

있다. 이 구조를 통해 사용자들은 새 컨텐츠를 생산하거나 기존 것에 자유로운 형태로 수정을

가할 수 있다. 이들 편집을 위해 컨텐츠를 시각화 및 편집, 도구 세트를 제공한다. 창작 구조는

애플리케이션 디자이너가 예측하기 어려운 방법으로, 프로세스 구조보다 선형적이지 않다.



<그림 3> Flex 리치 텍스트 편집기, Adobe Photoshop, Adobe Premiere Express 는 창작 구조의 예다.

전형적인 Flex 애플리케이션을 위해 앞에서 언급한 구조들 중 하나만 선택할 필요는 없다. 필요에

따라 체로 두 개, 심지어 세 개 모두를 선택한다. 예를 들어, 다수의 온라인 상점은 제품

브라우징 경험을 위해 정보 접근을 사용하지만, 결제 작업흐름을 위해서는 프로세스 접근으로

바꾼다. 이와 비슷하게 웹로그 승인 도구는 프로세스 접근을 사용하여, 새 엔트리를 만들어

제목이나 카테고리 같은 정보를 수집하고 실제 글을 승인하는데는 창작 접근을 사용한다. 다음

절에서는 구조들 중 어떤 것을 현명하게 선택할지에 해 다루겠다.

<그림 4> 다수의 실제 애플리케이션은 다중 구조를 사용한다. 예를 들어 Amazon.com 은 제품 브라우징

경험을 위해 정보 구조를 사용한 후, 결제를 위해서 프로세스 구조로 바꾼다.

구조 적용하기

구조 선택은 애플리케이션에 큰 영향을 줄 수 있다. 체로 이 선택은 쉽지 않다. (더 안 좋게는)

명백한 선택인 것 같은 구조가 정확하지 않을 때도 있다. 예를 들어 Adobe Photoshop 과

비슷하게 창작 구조를 사용하여 사진 편집 애플리케이션을 디자인하였다. 하지만 많은 일반

사진가들은 적목현상 삭제나 색 보정 정도의 간단한 작업만 하길 원한다. 이런 사용자들에게는

프로세스 접근이 더 적절하다. 이런 함정을 피하기 위해 각 구조의 장점과 단점을 살펴보고

디자인에 어떻게 적용할 것인지 설명하겠다.



정보 구조 디자인하기

체로 정보 구조는 사용자의 주요 목표가 각기 다른 정보를 브라우징하고, 비교 이해하는데

사용된다. 정보 구조는 교육 및 발견에 적합하다. 이 구조는 리치 그래픽 정보를 보여주고 사용자

목표와 상관없는 업무와 네비게이션을 줄임으로써 비주얼 커뮤니케이션을 강조한다.

정보 구조는 사용자의 주요 목표가 각기 다른 정보를 브라우징하고, 비교 이해하는데

사용된다.

체로 모든 정보 구조는 애플리케이션의 컨텐츠를 보여주는 것으로 시작한다. 컨텐츠의

부분집합이나 메서드 표시가 명확치 않다면 애플리케이션은 컨텐츠로 판단해야 한다. 사용자는

필터를 추가하거나 멀티 뷰에서 선택 등을 통해 추가 선택을 제공하여 조절할 수 있다. 필요할

때만 제어 및 다른 애플리케이션 크롬을 보여주거나 불가능하다면 화면 끝쪽으로 보내버리는

식으로 처리해 화면에는 컨텐츠를 최 로 보여주도록 한다. 애플리케이션의 보조 기능은 ‘허브와

바퀴살(hub and spoke)’ 모델, 즉 모든 보여지는 정보와 조절 기능을 중앙 허브에 통합하고,

사용자가 필요한 때만 보조 기능을 찾을 수 있게끔 바퀴살로 나눠 보낸다. (참고: Hagan River 의

‘The Designer’s Guide to Web Applications’ 보고서에서 허브와 바퀴살 구조적 모델에 해

자세히 설명하고 있다).

예를 들어 달력과 약속을 표시한 스케쥴 애플리케이션을 주 허브로 한다면 사용자는 허브

자체에서 직접 애플리케이션을 만들거나 제거할 수 있어야 한다. 사용자는 재발생하는 약속의

경우 약속 버튼을 눌러 바퀴살을 만드는 식의 간단한 작동이 수행되어야 한다.



<그림 5a> Yahoo! Maps 은 허브와 바퀴살 모델을 사용하고 있다. 지도와 찾아가는 길은 정보 구조화된

허브를, 지도 프린트나 친구에게 보내기 같은 보조 기능은 툴바에서 접근할 수 있는 바퀴살로 나타난다.

<그림 5b> Yahoo! Maps 의 구조적 다이어그램은 허브와 바퀴살 모델을 명확히 따르고 있다.

많은 형 Flex 애플리케이션은 싱글 타입의 정보 배열로 사용자의 니즈를 충족시켜주지 못할

것이다. 이런 이유로 많은 디자이너들이 애플리케이션 컨텐츠를 멀티 뷰로 제공한다. 예를 들어

운영체계는 디렉터리 파일의 아이콘, 목록, 세 뷰를 제공한다. 이들 뷰를 디자인할 때 사용자가

수행해야 할 다양한 목표와 작업을 각각 고려해야 한다. 사용자가 완성해야 할 작업이 완전히

다른게 아닌 한 다른 뷰로 바꾸지 말라.

프로세스 구조 디자인하기

사용자의 기본 목표가 간단하고 능률적인 정보를 제공하는 것일 때는 프로세스 구조가 적합하다.

특히 사용자가 한번에 용량의 정보를 넣거나 복잡한 업무를 지원할 때 적합하다. 이러한 작업은

디자이너와 개발자로 하여금 사용자와 더불어 익숙치 않은 프로세스를 주게 된다.

프로세스 구조는 이 기능을 선형 작업흐름으로 만들기 때문에 사용자들은 단계를 따르기만 하면

된다.

사용자의 기본 목표가 간단하고 능률적이고 구조화된 정보를 제공하는 것일 경우,

프로세스 구조가 적합하다.




프로세스 구조를 디자인하기에 앞서 진정 프로세스 구조가 필요한지, 아니면 필요하다고 느끼는

만큼 필요한지 여부를 물어 본다. 많은 프로세스 구조가 사용자의 목표와 상관없는 정보를

제공하거나, 시스템이 스스로 해결할 수 있는 정보를 주거나 (가장 안 좋게는) 15 분 전에

시스템에게 준 정보를 다시 주기도 한다. 그러니 요청하는 정보가 진정 필요한지, 자동적으로

결정될 수 있는지, 정보가 필요하긴 한지 꼭 점검해 보기 바란다. (참고: 요청하는 정보가

사용자가 아닌 자신만을 위한 정보라면 이를 선택적으로 놔두고, 필수 정보 플로우에서 명확히

분리한다. 예를 들어 마케팅이나 트래킹 목적을 위한 인구통계적 정보가 있다면 선택적으로 놓고

이를 제공하는 사용자에게 인센티브를 제공하는 것이다.)

컴퓨터가 사운드카드의 포트를 스스로 찾지 못해 사용자에게 IRQ 포트를 애플리케이션에

입력하도록 하는 시 는 이미 지났다. 그러나 아직도 애플리케이션은 우편번호(주소 방금

넣었음에도 불구하고), 선호하는 위치(우리 집에서 가까운 식당을 기본으로 보여주면 안되나?),

선호하는 식성(이디오피아 식당을 찾기 위해 이 사이트에 몇 번이나 방문했음에도 매번 다시

입력해야 하는) 등과 반복적인 정보를 입력해야 하는 실수를 저지르고 있다.

어떤 정보를 물을지 결정했다면 어떻게 묻는게 가장 좋을지 생각해야 한다. 전통적으로

디자이너들은 마법사-‘다음’과 ‘이전’ 단추가 있는 다중 화면 화상자로 사용자들이 선형 흐름을

따르게 한다-를 사용하여 프로세스 구조를 구현했다. 마법사 같은 인터페이스는 Flex 에서는

하나의 옵션이지만 단 하나의 방법은 아니다. 많은 Flex 애플리케이션에서는 나눠진 화면 신

하나의 잘 꾸며진 화면으로 프로세스 구조를 나타낸다. 또는 아코디언 컨트롤(accordion

controls)과 같은 다중 상태 선형 컨테이너로 각 단계를 나타내며 보다 간결한 표현을 제공한다.

방법을 선택하는 것은 작업의 단계가 어떻게 나눠지느냐에 달려있으므로 사용자에게 한 단계의

옵션을 변경하는 것이 다른 것에 어떤 영향을 미치는지 보여주는 것이 중요하다.

여러분이 선택한 프로세스 구조에 상관없이, 사용자들이 프로세스의 다른 단계를 네비게이션할 수

있는 방법을 제시한다. 이렇게 함으로써 사용자는 잘못 입력한 부분을 고치고, 아직 준비가 안 된

정보를 지나치고 향후 얼마나 남았는지 예측할 수 있다.

사용자들이 ‘유효하지 않은’ 정보를 넣더라도 다음 단계로 넘어갈 수 있게 해야 하고, 추후 이를

고칠 수 있도록 정보를 저장할 수 있게 해야한다. 문서형식로 작성하던 시절, 사용자는 다음에

다시 채워 넣을 것을 각오하고 메모나 임시 정보를 넣곤 했다. 뒤로 다시 갈 수 있는 이 중요한

능력은 디지털 데이터베이스로 바뀔 때 잊어 버리곤 했다. 임시 정보 입력을 강력하게 막기

보다는, 사용자에게 원하는 정보를 넣고 확실한 정보를 갖게 되면 다시 뒤로 돌아가 입력할 수

있도록 허락해야 한다.



체로 정보 구조나 창작 구조보다는 프로세스 구조에서 컨트롤과 위젯을 위한 공간을 더

배정할수 있다. 이들 컨트롤은 사용자가 어디 있는지를 알려 주거나, 혹은 다른 단계를

네비게이션할 수 있도록 허락하거나 혹은 당장 명확치 않은 단계나 옵션을 설명하는 등의 기능을

한다. (참고: 많은 사용자들이 글자로 된 설명을 읽지 않는다. 특히 일반 화상자의 표준 부분에

해서 그렇다. 그러니 설명을 그림으로 바꾸거나 아예 설명이 필요없도록 만드는 것이 좋다).

여분의 크롬은 제거돼야 한다.

창작 구조 디자인하기

사용자의 목표가 완전히 새로운 컨텐츠를 만들거나 출발점으로 사용된 컨텐츠를 확장할 때 창작

구조가 적절하다. 특히 사용자의 목표가 애플리케이션들과 결합되어 있는 free-form 시퀀스를

요청할 때 가장 유용하다. 창작 구조는 익숙한 사용자들에게는 컨트롤과 힘을 주지만,

일반사용자들에게 범접하기 힘들 수 있다.

창작 구조는 사용자의 주 목표가 완전히 새로운 컨텐츠를 만들거나 기존 컨텐츠에 중요한

변화를 주는 것일 때 적절하다.

어떤 구조를 채택할지를 결정할 때는 항상 애플리케이션 도메인과 사용자의 목표를 염두해야

한다. 하지만 다수의 사용자가 자신의 애플리케이션을 정기적으로 사용하진 않는다는 것도

고려해야 한다. 스스로를 돌아보자. 체로 일상적으로 사용하는 것은 간단한 애플리케이션이며,

보다 광범위한 데스크톱이나 웹 애플리케이션은 주 혹은 월 별로 가끔 쓴다. 이런 이유로

애플리케이션의 원칙을 정리하는데 창작 구조를 선택하는 것은 현명치 못하다. 창작 구조는 보다

한정된 업무에 사용하거나 아예 사용하지 말자. 사진 편집기 예에서 이미 언급했듯이 보다 예상

가능한 업무를 수행하는 일반 사용자들을 위해서는 프로세스 구조가 더 적합하다.

창작 구조를 디자인할 때는 사용자의 컨텐츠가 중앙에 오도록 한다. 툴바 버튼같은 컨트롤은

화면의 가장자리에 배치하거나, 사용자가 필요로할 때만 보여준다. 한 번에 가능한 기능들의 수나

다양성이 증가됨에 따라 정보 구조보다 창작 구조에서 더 힘들다. 직접적인 조작 기술을 통해

복잡하고 컨트롤이 많은 화상자를 제거하고 편집 기능을 우선시 하자. 많은 창작

애플리케이션은 사용자들이 필요로 하는 것보다 더 많은 기능을 제공하여 전반적인 사용자

경험을 망치는 실수를 범한다.


<그림 6> Picnik 은 창작 구조로 되어 있다. 주된 기능만 제공하고 컨텍스트에서 옵션을 제공함으로써 사진

편집 기능을 간단히 하고 있다.

애플리케이션의 창작 구조가 복잡한 수준에 이르게 되면 업무 중심의 문서를 제공하여

사용자들의 편의를 돕는다. 문서는 검색 기능과 도움 버튼을 통해 애플리케이션에서 쉽게 접근할

수 있어야 한다. 문서를 처음부터 끝까지 다 읽도록 디자인하지 말고, 간단하게 접근할 수 있도록

한다. 문서를 나쁜 디자인의 용으로 쓰지 말라. 다수의 사용자는 문서를 읽어내려가는 것을

싫어하고, 가능하면 읽을 일이 없길 바란다.



<그림 7> Adobe Fireworks 의 헬프 시스템은 테스크 중심으로 작성되었다. 사용자 워크 플로우와 동떨어진

‘필터’로 기능을 묘사하는 신, 사용자가 필터들을 가지고 무엇을 할 수 있을 지를 검토해 봐야 한다. 예를

들어 그래픽을 제공하거나, 비트맵의 색과 톤을 조절하거나 혹은 맞춤 필터를 만드는 식이다.

유동적인 네비게이션

잘 디자인된 Flex 애플리케이션에서는 애플리케이션의 한 부분에서 다른 부분으로 이동하는 것이

자연스럽게 느껴진다. 섹션은 합쳐지고 사용자 업무와 함께 사용자들의 목표를 달성할 수 있게

인도한다. 이 ‘플로우’은 두 가지 요소 즉, 화면이 바뀔 때 모션을 효율적으로 사용하는 것(Flex

디자인하기 – Part 6: 모션 안내에서 자세히 다룰 예정이다)과 사용자 업무를 제 로 이해하고

목표를 애플리케이션 디자인에 끼워넣는 것으로 가능하다. 목표 및 테스크 중심의 디자인은

사용자의 니즈에 따라 원하는 로 할 수 있도록 지원한다. 이를 유동적인 네비게이션(fluid

navigation)이라 부른다.

유동적 네비게이션 경험을 디자인할 때는, 가능한 다른 네비게이션이 없도록 해야 한다.

네비게이션은 그 자체로 사용자가 목표를 달성하는데 아무런 도움이 안된다. 자동차에 연료를

넣듯 네비게이션은 애플리케이션을 사용하는데 필요한 부산물일 뿐이다. 연료를 채운다고

목적지까지 더 빠르게 가는 건 아니지만, 연료가 없으면 차를 움직일 수 없다. 이와 마찬가지로

네비게이션 동작은 최소한의 작용을 해야 한다. 사용자들은 컨텐츠와 인터렉트하거나 작업을

완성하는데 시간을 투자해야 한다. 디자인 내의 화면에서 화면으로 이동하는데 시간을 보내서는




안된다. (참고: 이 예는 핵심 애프리케이션 디자인 개념의 훌륭한 비유와 설명으로 가득 찬 Alan

Cooper 와 Robert Reimann 이 지은 About Face 2(Wiley Publishing, Inc., 2003)에서 발췌했다.

애플리케이션에서 불필요한 네비게이션을 제거하라.

극소수의 애플리케이션만이 네비게이션을 간단하게 제거할 수 있다고 한다. 그렇다면 여러분의

네비게이션이 최소한이면서 두드러지지 않고 자연스러운지 어떻게 확신할 수 있는가? 답은

간단하다. 계층 구조나 사이트맵에서 페이지와 화면을 정리하는 것에서 탈피하여 기본적으로

여러분이 고려하는 애플리케이션으로 운용 변환하고, 사용자의 주 업무화면으로 직접 플로우를

맵핑하는 것이다.

부분의 전통적 HTML 웹사이트는 사이트맵이라는 계층적으로 분류된 시스템으로 정리된다. 즉,

사용자는 네비게이션바, 브레드크럼(breadcrumb), 그외 다른 인터페이스 기술을 사용하여

접근하였다. HTML 웹 사이트들은 많은 페이지로 이루어진 정적인 컨텐츠들을 주로 포함하고 있고,

동적인 컨텐츠나 애플리케이션 기능을 가지고 있지 않기 때문에 이런 방식을 사용했다. (참고:

정적인 웹사이트마저도 가끔은 사이트맵만으로는 부실하다. 많은 컨텐츠를 가지고 있는 요즘의

다수 웹사이트들은 검색 기능을 필수로 하고 있다). 그러므로 이들 사이트를 사용하는 것은

도서관에서 책을 찾는 것으로 비유된다. 디자이너의 목표는 사용자들이 정확한 컨텐츠를 가능한

빠르고 쉽게 찾을 수 있도록 네비게이션을 디자인하는 것이다.

불행하게도 이 접근은 Flex 가 지원하는 유동적이고 동적인 애플리케이션에는 맞지 않다. Flex

애플리케이션 디자인에 분류 접근을 쓰게 되면, 주요 기능과 하위 기능으로 나눠지게 된다.

사용자들은 목표를 달성하기 위해 계층의 한 기능에서 완전히 다른 부분의 기능으로 자주

이동해야 한다. 이렇게 되면 애플리케이션을 네비게이션하는데만 엄청난 시간을 소비해야 하고

사용자들은 좌절하게 된다.

기능을 계층에 넣는 분류 신, 사용자 업무와 유연한 경험으로 Flex 애플리케이션의

네비게이션을 디자인해야 한다. 사용자들이 한 컨텍스트에서 다른 컨텍스트로 이동해야 하는 많은

갑작스런 화면 변형을 제거한다. 신에, 인트라 화면의 작은 변화로 사용자들이 새 컨텍스트로

변경하지 않아도 작업을 완성할 수 있도록 한다. 애플리케이션을 집이라고 생각하고,

애플리케이션의 나눠진 화면과 페이지를 방이라 생각해 보자(Cooper & Reimann, 2003).

부분의 집에서 방은 거주자들의 목표에 따라 특정 기능을 수행하도록 나눠져 있다.

예를 들어 부엌은 음식준비를 위해, 식당은 음식을 먹기 위해 디자인된다. 거실은 사람들과

휴식을 취하고, TV 를 시청하기 위해 마련된다. 각 방은 고유의 목표가 있기 때문에 거주자들은


같은 목표(요리, 먹기, 휴식 등)를 위해 다른 곳으로 이동할 필요가 없다. 감자 껍질을 벗기기

위해 부엌에서 거실로 이동하는 것은 아니라는 것이다. 마찬가지로 손님을 초 해놓고 음식을

먹기 위해 식당에서 복도로 움직인다면 원망을 들을 것이다. 이처럼 애플리케이션에서도

사용자들의 목표가 기본적으로 변하지 않는 한 화면에서 다른 화면으로 이동하는 것을 피하고

관련된 모든 작업을 한 화면에서 마칠 수 있게 해야 한다. 이렇게 하면 잘 디자인 된 Flex

애플리케이션에서는 화면수를 많이 줄일 수 있다. 용량의 애플리케이션도 주된 화면을 열 개

이하로 가질 수 있다.

사용자가 완전히 다른 목표를 가졌을 때만 페이지에서 페이지로의 전환을 사용한다.

<그림 8> Picnik 은 분리된 테스크를 분리된 화면으로 이동시킨다. 즉, Flickr 나 컴퓨터 하드 드라이브에서

이미지를 모으거나 별개의 이미지를 편집한다. Picnik 은 ‘편집’및 ‘만들기’등을 한번에 결합하여 싱글 화면에

넣을 수 있을 수 있는데, 사진을 작업하고 필터를 적용하는 것 모두가 특별한 사진을 찾기 위한 사용자

목표와 관련이 있다.

목표당 하나의 화면 철학을 채택하게 되면, 화면 수가 확 줄어드는 장점이 있다. 하지만 화면

내의 인터렉션에 해 더 깊이 생각해야 하고, 이를 위해 디자인 도구 세트도 수정해야 한다.

전통적인 HTML 애플리케이션에서, 디자이너들은 주요 페이지의 와이어 프레임(wireframe)이나

구조(comps)를 만들어 디자인을 표현한다. 사용자들을 새 페이지로 인도하는 링크를 클릭하면,

가능한 모든 동작들이 가능하다. 이들 와이어프레임과 구조는 주석 혹은 다른 설명 텍스트와 함께

애플리케이션이 어떻게 작동하는지를 충분히 설명한다. 페이지 내의 변경을 최소화할 수 있어,

이를 단어나 추가 그림으로 설명하여 각각의 새로운 상태에서 페이지를 보여줄 수 있다.

와이어프레임과 구조는 Flex 애플리케이션 디자인의 시작점에 유용하지만 화면 내의 복잡한

인터랙션을 모두 표현하기에는 너무 정적이다. 와이어프레임에 스토리보드를 추가하여 각

인터랙션을 그려 보자. 모든 스토리보드는 화면이 어떻게 변경되는지를 완벽히 보여주고




사용자들이 주요 테스크를 어떻게 마칠 수 있는지 설명할 수 있어야 한다. 주 업무를 나열하고

각각에 스토리보드를 만들자.

와이어프레임과 구조에 스토리보드를 추가하여 화면 내의 변화를 설명하자.

와이어프레임(wireframe)과 스토리보드(storyboard)는 애플리케이션 작업 플로우와 행동의 많은

타입을 생각해 볼 수 있는 유용한 도구이다. 반면 Flex 애플리케이션의 인터랙티브한 측면을

디자인하기 위해서는 프로토타입(prototype)을 만들어야 한다. 다수의 프로젝트가 인터렉티브

프로토타입을 완성하기 위해 비용과 시간에 쫓기어 이 부분을 간과하지만, Flex 애플리케이션의

가장 중요한 부분을 선택하여 와이어프레임과 스토리보드를 만들면 다른 것들과 소통할 수 있다.

컨텐츠 인터랙션과 유동적인 모션의 이펙트 및 변경 등은 프로토타입에 특히 중요하다고 할 수

있다. 너무 복잡한 인터랙션이라면 특히 그래야 한다. Adobe Flash 와 Flex 는 사용자 리서치,

클라이언트 커뮤니케이션 등을 위한 인터랙티브한 프로토타입을 디자인할 수 있는 중적인

도구이다.

애플리케이션에서 프로토타입의 주요 인터랙션으로 느낌을 조절하고 전달하자.

사용자 업무와 애플리케이션 기능의 결합은 체적으로 복잡하고 다양하다. 사용자들은 다양한

기능을 결합하여 하나의 작업을 완성하고 같은 기능에 접근하여 완전히 다른 업무를 완성하기도

한다. 그러므로 시작할 때 사용자의 업무를 이해하고 디자인하는 것이 매우 중요하다. 멀티

테스크들이 같은 기능을 요구하지만, 각각의 테스크들은 각기 다르게 사용되어야 한다.

모바일폰의 예를 생각해 보자. 빌트인 카메라로 사진을 찍는 화면과 SMS 텍스트 메시지를

보내는 화면 등 두 개의 화면을 가지고 있다. 이들은 사용자가 사진을 텍스트 메시지와 함께

보내지 않는 한 다른 작업이다. 기능에 따라 계층적으로 구조화 된 애플리케이션이라면 사용자는

카메라 화면으로 바꿔 사진을 찍고, 다시 텍스트 화면으로 가서 방금 찍은 사진을 찾아 텍스트

메시지를 입력한 후 ‘보내기’ 버튼을 누른다. 분명 이것은 최적화된 사용자 경험이 아니다. 느슨한

작업 중심의 애플리케이션이라면, 사용자는 사진을 찍은 후 ‘친구에게 보내기’를 선택하고 텍스트

메시지 애플리케이션으로 바꿀 것이다.

이 방법도 좋겠지만, 여전히 최적화는 아니다. 사용자가 메시지를 작성하는 동안 찍은 사진을 볼

수 없기 때문이다. 이상적인 애플리케이션이라면, 텍스트 메시지 기능을 사진보내기 작업

플로우에 통합할 것이다. 즉, 두 개의 기능을 사진보내기 작업에 맞춤 인터페이스로 결합하는

것이다.



전통적인 HTML 웹사이트와는 달리 Flex 애플리케이션의 네비게이션 구조는 계층적이어서는

안된다. 그 신 각각의 허브가 부분의 컨텐츠와 인터랙션을 통합하는 바퀴의 역할을, 그리고

바퀴살은 부수적인 작업의 완성을 가능하게 한다.

계층적 사이트맵이 아닌 ‘허브와 바퀴살’ 네비게이션 모델을 따르자.

엔트리 포인트

잘 디자인된 Flex 애플리케이션에서는, 사용자가 보는 첫 화면에 주요 목표를 달성하는 방법을

설명한다. 이를 위해 애플리케이션은 좋은 엔트리 포인트를 가져야 한다. 집을 비유하자면

애플리케이션의 엔트리 포인트는 문이다. 이는 초 와 즉각적인 사용 등에 매우 중요하다.

모든 사용자는 애플리케이션을 접할 때 특정한 목표를 가지고 있다. 그러므로 최고의 엔트리

포인트는 목표 달성을 방해하지 않는 것이다. 사용자 목표를 가로막게 되면(‘skip intro’,

네비게이션이 힘든 메인 스크린, 다른 방해물) 안 좋은 초기경험을 쌓게 된다.

인터랙션 없이도 사용자 목표와 관련된 유용한 작업과 정보를 나타낼 수 있도록

애플리케이션의 엔트리 포인트를 디자인한다.

가장 좋은 방법은 애플리케이션의 주요 구조를 따르는 것이다. 정보 구조로 디자인된

애플리케이션의 경우, 엔트리 포인트로 컨텐츠를 의미있게 보여준다. 다수의 온라인 상점들은

방문자들이 원하는 상품 타입을 제공하는 신, 상품의 샘플링을 즉각 보여준다. 사용자들에게

아무 것도 없는 화면을 보여주거나 컨텐츠를 보여주기 전에 필터 조건을 입력하도록 요구하지

않는다. 온라인 상점에서 아무 것도 보여주지 않고 긴 폼을 작성하거나 복잡한 상점 디렉터리를

네비게이션하도록 한다고 생각해보라. 사용자는 이런 시스템을 사용하고 싶지 않을 것이다.

제품을 찾으러 왔지 웹사이트 전체를 돌아다니려고 방문한 것이 아니기 때문이다. (일반 상점에

갔는데 상품은 다 숨겨두고 무엇을 원하는지 적도록 한다고 생각해보자. 이런 상점에서 물건을

구매하겠는가?)

애플리케이션 엔트리 포인트 정보를 위해 사용자에게 관련된 컨텐츠를 즉각 보여준다.


<그림 9> Amazon.com 은 사용자가 홈페이지에 방문하자마자 관련된 상품을 보여준다. 애플리케이션이

Amazon 만큼 자세하게 관련된 엔진을 구현하지 못하더라도, 사용자들에게 정보를 제공해달라고 요구하지

않고도 관련된 컨텐츠를 많이 즉각적으로 보여줄 수 있는 방법을 찾아보자.

가능할 때마다 사용자가 접하는 컨텍스트를 기반으로 여러분이 제공한 정보 타입을 맞춰 본다.

예를 들어, 지도 애플리케이션을 디자인했을 때 사용자가 예전에 자주 나이트클럽에 관심을

보였다면 기본적으로 나이트클럽을 지도에 보여줘야 한다. 어떤 경우에는 유용한 답을 하기

전에 프로세스 구조를 사용하여 사용자에게 추가 컨텍스트를 요구해야 할 때가 있다. 예를 들어,

비행기 예약시스템의 경우 사용자에게 비행기 목록을 보여주기 전에 사용자의 자세한 여행

계획을 알아야 한다. 이러한 자세한 사항을 최소한으로 요구하기 위해서는 컨텍스트에서 가능한

많은 정보를 유추해야 한다(예를 들어 비행기 예약 시스템은 사용자의 IP 주소나 이전 엔트리를

기반으로 사용자가 거주하는 지역의 공항을 추측할 수 있다).



<그림 10> Yahoo! Maps 은 사용자가 제공한 주소를 통해 사용자의 살고 있는 위치를 유추한다. 집 주소를

제공하면 이 정보를 바탕으로 더 상세한 엔트리 포인트를 제공한다.

잘 디자인된 정보 애플리케이션은 쉽게 이해하고 유추할 수 있는 정보를 제공한다.

애플리케이션이 이런 가치를 가지고 있음을 엔트리 포인트를 통해 처음으로 보여줄 수 있다.

가능한 빨리 가능한 많은 정보를 제공한다. 그래야 방문자는 더 많은 정보를 제공해주고, 이를

통해 더 상세한 결과를 얻을 수 있다.

애플리케이션이 프로세스 접근을 우선으로 채택한다면, 사용자가 흥미를 느끼는 작업흐름을 쉽게

찾을 수 있도록 만든다. 엔트리 포인트에는 애플리케이션이 지원하는 명확한 작업 목록을

제공하고, 이를 사용자의 언어로 설명한다. 예를 들어 은행의 ATM 기로 금액을 인출하고

예금하고 계좌잔액을 확인할 수 있다. 그러므로 은행 카드를 삽입하면 바로 각각의 작업 목록을

첫 스크린에 띄워 원하는 작업을 바로 실행할 수 있게끔 한다.

프로세스 애플리케이션의 엔트리 포인트를 위해 애플리케이션이 지원하는 업무를 명확히

나열한다.



<그림 11> Fidelity Mortgage Search 애플리케이션은 작업 목록을 엔트리 포인트로 사용한다.

특정 애플리케이션은 프로세스 구조와 정보 구조를 결합해야 한다. 예를 들어 많은 온라인 뱅킹

웹사이트들은 계좌 요약과 더불어 ‘지불’ ‘이체’와 같은 작업 목록을 함께 보여준다. 이들은 함께

존재할 수 있으나, 최소의 인터랙션만 보여주어야 하며, 혹은 인터랙션이 많은 외부 콘트롤 없이

필요한 컨텍스트만 보여줄 수 있게끔 해야한다. 이런 크롬은 (사이트를 방문한 주요 목적인)

사용자를 귀찮게 한다.

만약 애플리케이션이 창작 구조를 우선으로 채택했다면 매우 어려워진다. 정보 애플리케이션처럼

사용자들은 작업해야 하는 컨텐츠를 처음으로 봐야 한다. 하지만 이것은 닭이 먼저냐 달걀이

먼저냐의 문제다. 사용자는 아직 만들어 놓은 것이 없기 때문이다. 사용자의 목표가 이미

존재하는 컨텐츠를 수정하는거라면 데이터베이스에서 자동적으로 이를 끌어 내거나 사용자에게

물어 보든 이 컨텐츠를 시작점으로 해서 로드한다. 예를 들어, 문서 편집기는 사용자들이 선택할

수 있도록 최근에 편집한 문서 목록을 보여 준다. 존재하는 컨텐츠가 없는 사용자라면 기존의

컨텐츠를 제공하여 시작하는 방법을 고려해야 한다(템플릿이나 샘플을 수정하는 것으로). 기존의

작업을 시작으로 만드는 것은 항상 무에서 유를 창조하는 것보다 쉽다.

만들기 애플리케이션의 엔트리 포인트는 기존 작업에서 시작하자.

어떤 구조를 선택했든 애플리케이션을 로드할 때 사용자가 처음으로 보는 것은 엔트리 포인트 여

야 한다. 아마도 가장 평범한 엔트리 포인트는 로그인 화면이겠지만, 사용자의 관점에서는 매우

좋지 않다. 사용자들에게는 ‘자신을 식별하지 않으면 상 하지 않겠다’라는 의미로 보이기



때문이다. 어떤 애플리케이션은 보안을 너무 강조하여 사용자가 자신을 식별하지 않으면 아무것도

할 수 없게 만든다. 하지만 부분의 애플리케이션은 민감한 정보를 가지고 있다 하더라도

사용자들이 로그인을 하기 전에도 많은 것을 할 수 있다. 로그인이 꼭 필요하기 전까지 미룬다.

서버에 데이터를 저장해야하는 때( 신 브라우저 쿠키를 사용하는 방법을 고려해보자), 또는

신용카드나 주소 데이터 같은 민감한 정보에 접근해야 할 때까지 미룬다. 다행히 부분의

전자상거래 사이트는 이미 이를 알아채고 꼭 필요하기 전에는 로그인을 요구하지 않는다.

애플리케이션을 디자인할 때 이 좋은 예를 꼭 따르기 바란다.

<그림 12> Kuler 는 다른 사용자의 색깔 스키마를 살펴볼 때나 혹은 자신의 것을 만들때도 로그인을

요구하지 않는다. 다른 이들이 볼 수 있게 테마를 발행할 때만 계정에 로그인하게 한다.

잘못된 엔트리 포인트의 또다른 예는 몇 초간 지속되는 ‘로딩…’ 화면이다. 불행하게도 모든 Flex

애프리케이션에서 볼 수 있다. 긴 로딩 화면을 피하려면 불필요한 애플리케이션 섹션이나

데이터를 다운로드하지 않게 하면 된다.

비주얼 계층

애플리케이션에서 가장 하급의 구조는 개별 화면 구조다. 가끔 디자이너들은 화면을 정교하게

서로 연결시키기 위해 이 구조를 무시하지만 특히 주 애플리케이션 화면의 비주얼, 인터랙션



디자인을 강조하는 Flex 애플리케이션에서는 실수다. 비주얼 계층을 효과적이고 적절하게

사용하여 잘 구조화된 화면을 만들어야 한다.

비주얼 계층을 채택하는 것은 색깔, 모양, 질감, 방향, 크기, 위치의 비주얼 변수를 적용하여 어떤

것이 중요한지, 어떤 것을 무시할 것인지, 나중에 중요해질 것은 무엇인지를 사용자와 논의하는

것이다. 비주얼 계층을 제 로 사용했는지의 여부는 두 화면이 똑같은 컨텐츠를 갖고 있다

하더라도 명확하고 쉽게 이해할 수 있는 애플리케이션 화면인지 혹은 복잡하고 이해하기 어려운

화면인지의 차이다.

견고한 비주얼 계층을 채택하여 페이지의 중요한 요소와 소통하고 사용자의 다음 작업으로

인도하자.

<그림 13> Flex Builder 의 화상자는 비주얼 계층을 제 로 사용하지 못한 예다. 컨트롤은 섞여 버렸고,

모든 텍스트는 같은 비주얼 무게감을 가지고 있다. 퍼스펙티브를 바꾸는 컨트롤이 어디 있는지 화상자

안에서 찾아 보자. 다음 컨트롤로 넘어가기 전에 각각의 컨트롤을 읽어야 하기 때문에 시간이 매우 많이

걸린다는 것을 알 수 있다.



<그림 14> Dreamweaver 의 화상자는 비주얼 계층을 보다 효과적으로 사용한다. 섹션은 줄과 위치로

구분된 제목을 가지고 있고, 컨트롤은 여백과 의미있는 정렬로 표시된다. 접근가능성 캡션의 정렬을 바꾸는

컨트롤을 찾아보자. 쉽고 빠르게 찾을 수 있다.

비주얼 계층은 거의 모든 보고서에서 일반적으로 사용된다. 다수의 긴 보고서(이 글과 같은)는

멀티 섹션과 하위 섹션을 가지고 있다. 이들 섹션은 제목으로 나눠진다. 제목과 본문 텍스트는

같은 글자체, 색깔, 크기, 스타일 등을 가지고 있지 않다. 제목은 체로 더 크고, 더 굵고, 다른

색깔로 표현된다. 비주얼로 더 두드러진다. 예를 들어, 이 글에서도 섹션 제목은 아래 위로 회색

줄이 그어져있어 본문 텍스트와는 구별되고 비주얼도 쉽게 찾을 수 있다. 본문 텍스트와 비주얼이

구별되지 않으면, 어떤 것이 제목이고 어떤 것이 문단인지 찾을 수 없다. 섹션을 찾는 것이 너무

힘들어진다.

하지만 제목만이 비주얼 계층을 나타내는 유일한 페이지 요소가 아니다. 페이지의 어떤 것이라도

비주얼 구조로 나타낼 수 있다(또는 여백처럼 아무 표시가 없어도 비주얼 계층을 표현할 수 있다).



색깔 배경은 사용자에게 사이드바와 같은 역할을 한다(내 예전 커뮤니케이션 디자인 강사는 이

기술을 ‘토스트 toast’라 불렀다). 커다란 이미지는 사용자 시선을 당길 수 있다.

<그림 15a> 사용자는 애플리케이션 화면의 모든 단어를 읽지 않는다. 신 화면의 비주얼 계층을 무의식

중에 사용하여 무엇을 볼 지 결정한다. Flex cookbook 에서 다수의 사용자들은 커다란 주 제목을 먼저

보고 하위제목을 훑어본 후 흥미로운 컨텐츠만 읽는다. 다수의 페이지는 읽지 않은 채로 남는다는 것을

기억하자.



<그림 15b> 그리고 나서 하위제목을 훑는다.

<그림 15c> 그리고 흥미로운 컨텐츠만 읽는다. 다수의 페이지는 읽지 않은 채로 남는다.




화면의 비주얼 계층은 다른 것들처럼 사용자가 어떻게 목표를 달성할 것인지를 명확히 보여

주어야 한다. 색깔을 사용해 기본 선택을 표현하는 버튼을 나타내거나, 유해한 작동은 피하도록

경고한다. (예를 들어 Wordpress 에서 ‘글 삭제’처럼 데이터를 없애는 작동에는 빨간색 버튼으로

경고를 표시한다). 크기를 사용하여 화면의 가장 중요한 부분을 사용자에게 각인시킨다. 위치를

사용하여 사용자가 폼의 요소를 순서 로 볼 수 있도록 한다. (비주얼 계층과 다른 커뮤니케이션

디자인 기술에 한 더 자세한 정보는 Mullet 과 Sano 의 책, ‘Designing Visual Interfaces’를 읽기

바란다. Tidwell 의 ‘Designing Interfaces’는 비주얼 계층과 다른 사용자 인터페이스 디자인 기술

을 포함하고 있다).

Flex 를 통해 원하는 모양을 표시할 수 있다. 이 능력을 현명하게 사용하자. 비주얼 디자인은

사용자와 소통하는 한 방법임을 늘 명심하라. 디자이너와 개발자들은 디자인화면을 사용자가 보는

것과 매우 다름을 기억하라. 페이지의 비주얼 계층을 생각하여 이 함정에 빠지지 않도록 한다.



Flex 디자인하기 – Part 4: 웹과 데스크톱 결합하기

<Flex 디자인하기 – Part 1: Flex 개요 및 발견하기> 에서 Flex가 어떻게 두 개의 완전히 다른

소프트웨어 매체를 결합하는지에 해 설명했다(크로스플랫폼: 일반적으로 접근 가능하지만

기술적으로는 한정적인 웹 애플리케이션, 의존형 플랫폼: 지엽적으로 인스톨되지만 풍부한

인터랙티브 데스크톱 클라이언트 애플리케이션). 지금까지 원래 웹 용어(컨텐트 포커스,

Flash에서의 모션 사용)와 데스크톱 용어(파일 저장, 제어 및 사용)에서 가져온 Flex의 많은

관점에 해 설명했지만 이들 두 매체의 결합이 사용자의 기 를 어떻게 바꾸는지, 그리고 이것이

Flex 애플리케이션에 어떤 영향을 끼치는지 살펴보도록 하겠다.

Flex 애플리케이션은 웹 기반의 Adobe Flash Player와 데스크톱 기반의 AIR (Adobe Integrated

Runtime), 두 런타임 중 하나에 있을 수 있다. 예상했듯이 사용자가 Flash Player를 ‘웹 같은’

느낌을 갖도록 하는 Flex 애플리케이션과는 달리, AIR는 ‘데스크톱 같은’ 느낌을 갖게 한다.

Flex 애플리케이션은 일단 리치 인터넷 애플리케이션이고, 그 다음 웹 또는 데스크톱

애플리케이션이다. 하지만 환경을 선택하는 것은 사용자가 애플리케이션에 어떻게 접근하느냐에

영향을 주기 때문에 디자인할 때 이를 고려해야 한다. 본 글은 다음의 주제를 다룬다.

• 웹 과 데스크톱 애플리케이션 간의 공통점과 차이점, 그리고 웹과 데스크톱 환경 중

하나의 개발 환경을 선택하는 법

• 웹 애플리케이션 동작에 한 사용자 요구를 충족시키는 방법

• 사용자들이 Flex 애플리케이션에 문제 없이 접근할 수 있는 방법

• 네트워크 연결, 파일 시스템 접근, 윈도우, 메뉴바 등 데스크톱의 고유 기능을 디자인하는

방법

웹에서 살기, 데스크톱에서 살기

웹 애플리케이션과 데스크톱 애플리케이션 간의 공통점은 그리 많지 않다. 웹 애플리케이션은

인터랙션에 있어 덜 리치한 반면, 데스크톱 애플리케이션은 연결성이나 컨텐츠 접근에 있어 웹

어플리케이션보다 제한적이다. 하지만 지난 몇 년 간 이런 제약은 줄어 들고 있다.

<Part 1>에서 언급했듯 Flex나 Ajax 같은 RIA 테크놀로지를 가지고, 웹 애플리케이션은 데스크톱

애플리케이션이 누렸던 인터랙티브의 측면을 향상시키고 있다. 이와 마찬가지로 많은 데스크톱

애플리케이션도 웹 용어와 결합하기 시작했다. iTunes은 iTunes Music Store 기능의 일환으로

http://www.adobeflex.co.kr/iwt/board/board.php?tn=pds_tech&page=2&id=112&mode=view


작은 웹 경험을 가지고 있다. 윈도우 XP는 탐색기에 웹과 유사한 네비게이션을 제공한다. 많은

데스크톱 애플리케이션은 이제 사용자 인터페이스 위젯으로 하이퍼링크를 사용한다.

<그림 1> Flex Store은 웹 애플리케이션이지만 드래그 앤 드롭 같은 많은 데스크톱 용어를 사용한다. Adobe

Bridge는 데스크톱 애플리케이션이지만 Adobe Stock Photo 처럼 어떤 애플리케이션은 임베디드된 웹

컨텐츠로 구성되어 있다.

이는 무엇을 의미하는가? 다행히 이제 웹을 위한 Flex 디자인과 데스크톱을 위한 Flex 디자인이

별로 다르지 않다는 것을 의미한다. AIR 기반의 데스크톱 Flex 애플리케이션을 디자인한다고

해서, MS Office 97 과 같은 메뉴, 툴바, 컨트롤 패널을 붙일 필요가 없다는 뜻이다. 또한 Flash

Player 기반의 Flex 애플리케이션을 디자인하기 위해 전통적인 HTML의 모습을 ‘일관성 있게’

만들기 위해 폼과 네비게이션 사이드 바를 이유 없이 추가할 필요가 없다. 모든 Flex

애플리케이션은 컨텐츠 중심으로 자연스러운 네비게이션을 가지고 사용자들을 모션으로 유도하고

본 연재에서 언급한 다른 원칙들을 따른다. 일반적으로 웹과 데스크톱 Flex 애플리케이션은

비슷한 룩앤필을 갖는다.

Flex 애플리케이션은 RIA로 먼저, 그 후에 데스크톱 혹은 웹 애플리케이션으로 디자인한다.



<그림 2> 웹 기반의 Flex 애플리케이션인 Kuler 과 데스크톱 Flex 애플리케이션인 Digital Editions 는 다른

환경에 배치됨에도 불구하고 외형과 구조에서 많은 공통점을 공유한다.

양쪽 환경 모두 리치 애플리케이션 경험을 만들 수 있는데, 왜 웹과 데스크톱 애플리케이션을

따로 만들어야 하는가? 아니면 Flex 코드가 양쪽 환경 모두에서 작동하므로 양쪽 모두를

만족시켜야 하는가? 사실 각 환경에는 몇 가지 고유의 속성이 남아 있어 특정한 애플리케이션

목표에 맞춰야 하는 부분이 있다.

웹 기반의 애플리케이션은 데스크톱 기반보다 두 가지 기본적인 장점이 있다. 특별한 인스톨

없이도 네트워크 연결만 되어있다면 어떤 머신에서도 동작 가능하다는 점과 웹 환경과 완벽하게

통합된다는 점이 그것이다. 사용자가 머신을 많이 가지고 있다면 이들을 완벽히 통제하기

위해(라이브러리의 퍼블릭 터미널 같은 웹 애플리케이션을 만들어야 한다. 더 중요한 것은

인스톨 프로세스가(Adobe AIR 인스톨 프로세스와 같이 매우 가볍더라도) 애플리케이션 자체에만

관심이 있는 많은 웹 사용자들에게 불편하게 느껴진다는 것이다.

사용자들이 데스크톱 애플리케이션을 인스톨하기 싫어한다면 웹 경험을 제공하기 바란다.

애플리케이션이 어떤 머신에도 접근 가능하고 웹 환경과 완벽히 통합돼야 한다면 웹 경험을

제공하자.



<그림 3> 사용자들은 기업을 신뢰하고 애플리케이션을 인스톨할 만큼 간절히 원할 때만 위 그림 같은

인스톨 프로세스를 따라 데스크톱 애플리케이션을 배포한다.

웹 애플리케이션은 검색 엔진과 URL 에 접근 가능하다. 다른 웹 사이트 소유자는 데스크톱

애플리케이션에 링크할 수 없고 컨텐츠를 검색 엔진 스파이더에 링크할 수 없다. 웹 서비스

API 를 통해 컨텐츠에 접근할 수 있다 하더라도 다른 사이트나 검색 엔진이 제공하는 것과 같은

수준의 쉬운 통합을 제공하진 못한다. 이러한 수준의 통합이 중요하다면 웹 경험을 제공한다.

<그림 4> 웹 애플리케이션은 유일한 URL 이 있어서, 블로그 같은 기타 웹 사이트에서 링크를 걸 수 있다.

여기 Amgen Tour of California 애플리케이션도 이와 관련된 블로그와 직접적으로 연결되어 있다.



데스크톱 기반의 애플리케이션들은 자신만의 장점을 가지고 있다. 웹 애플리케이션과는 달리

사용자 컴퓨터에 설치되어 있어 호스트 운영 체제와 더욱 접하게 통합된다. 또한 사용자 파일

시스템을 저장소로 활용함으로써 오프라인에서도 사용할 수 있다.

애플리케이션이 사용자 컴퓨터에 있고 호스트 운영 체계와 더 자연스럽게 통합되어야 한다면

데스크톱 경험을 제공하자.

데스크톱 애플리케이션은 체로 윈도우에서는 Start Menu의 아이콘으로, Mac OS X에서는

애플리케이션 폴더로 나타난다. 사용자가 애플리케이션을 자주 사용한다면, 데스크톱

애플리케이션은 웹 브라우저를 띄우거나 북마크로 갈 필요가 없는 쉬운 접근성을 부여한다.

사용자가 신속한 접근을 가장 크게 요구하거나 자주 사용하지 않는 도구를 애플리케이션

목록에서 보고 싶어하지 않는다면, 데스크톱 경험을 제공하자.

<그림 5> 데스크톱 AIR 애플리케이션- Adobe Media Player-은 사용자의 로컬 머신에 인스톨되고 Windows

Start Menu 와 Macintosh Applications 폴더에 나타난다. 이는 웹 기반의 Flex 애플리케이션보다 사용자

시스템에서 더 눈에 띄게 나타난다.

보안의 이유로, 웹 브라우저는 호스트 운영 체계와 웹 애플리케이션 통합에 제한을 둔다. 어떤

데스크톱 기반 기능은 -파일 만들기 및 열기, 특정 타입의 컨텐츠 복사 및 붙이기웹 상에서의

구현이 불가능하다. 또한 데스크톱 애플리케이션만이 사용자의 하드 드라이브에 직접 접근할 수



있다. 하드 드라이브를 사용함으로써, 애플리케이션은 풍부한 정보를 사용자 머신에 저장할 수

있고 인터넷에 접속되지 않았을 때도 중요한 기능을 제공한다. 웹에 제한적인 용어를 사용하는

것이 사용자 목표를 달성하는데 도움이 된다면, 특히 사용자가 인터넷 연결이 없이도

애플리케이션에 접속해야 한다고 생각되면 데스크톱 경험을 제공한다.

<그림 6> 다수의 데스크톱 애플리케이션처럼 Digital Editions 도 사용자가 파일 시스템에서 직접 파일을

열 수 있도록 한다. Desktop Flex 애플리케이션은 애플리케이션과 호스트 운영 체제 간의 파일 시스템

접근과 드래그앤드롭/복사하여 붙이기 기능을 포함한 고유 애플리케이션의 모든 능력을 가지고 있다.

지금까지 웹이나 데스크톱에 배치된 Flex 애플리케이션은 매우 비슷하지만 고유의 장점과 단점에

차이가 있음을 보았다. 이제 이러한 장단점이 애플리케이션 디자인에 어떤 영향을 주는지

살펴보도록 하겠다.

브라우저 기 감(Browser expectations)

전통적인 HTML 기반 인터페이스를 확장하든 체하든 간에 Adobe Flash Player 또는 WEB에서

실행되는 Flex 애플리케이션은 웹 작동방식에 한 사용자의 이해 수준에 맞아야 한다. 이는 웹

인터랙션의 두 가지 기본 개념으로 요약될 수 있는데, 브라우저 네비게이션 버튼과 URL이

그것이다.

‘뒤로가기 버튼’이라 불리는 브라우저 네비게이션 버튼은 웹 브라우저 어디에나 있고 웹 사용자에

의해 도처에서 사용되고 있다. 웹 사용자가 네비게이션 결정을 바꾸려고 하거나 이전 페이지로



돌아가고자 할 때 즉각 마우스를 움직여 뒤로가기 버튼(back button)을 누른다. 지금까지 Flash

기반의 웹 사이트는 뒤로가기 버튼을 지원하지 않았다. 뒤로가기 버튼을 누르면 애플리케이션에서

아예 벗어나게 됐다. 다행히 Flex는 최신 페이지 관리 기능에도 불구하고 뒤로가기 버튼을

지원한다.

URL은 웹 디자인의 기본이다. 사용자는 북마크를 하고 웹 페이지와 비슷한 것은 모두 링크를

만들고자 할 것이다. Flex가 HTML처럼 기술적으로 ‘페이지’ 개념 자체가 없더라도 Flex

애플리케이션은 몇 가지 화면으로 나눠지고 이들 화면 내에서 많은 상황을 만든다. 사용자에게는

이것이 HTML의 페이지와 같게 느껴지므로 이들을 페이지처럼 작동하도록 만들어야 한다.

사용자 기 를 만족시키기 위해 Flex 애플리케이션은 브라우저 네비게이션 버튼과 URL 개념을

화면과 상태의 개념에 맞춰야 한다. 각각의 네비게이션 가능한 상태는고유 URL을 가져야 하고 웹

브라우저의 전/후 사이트에 나타나야 한다.

하지만 ‘각각의 네비게이션 가능한 상태’에는 무엇이 포함되는가? 분명 다른 탑 레벨 화면이

들어갈 것이다. 하지만 같은 화면 내의 다른 상태 또한 포함된다. 예로는 네비게이터의 상태(탭과

펼치기 콘트롤 같은)와 컨텐츠 컨트롤에 적용되는 다른 필터(타일형 목록과 데이터 그리드

같은)가 포함된다. 하지만 몇몇 상태는 작업흐름의 컨텐츠에만 맞고 네이게이션가능한 상태에는

맞지 않는다. 예제들은 버튼의 호버 피드백과 추가 정보 보여주기와는 상관없는 목록의 간단한

아이템 선택을 포함한다. 가장 중요한 것은 현재 상태가 새로운 정보로 업데이트되려면

네비게이션 가능한 상태고 URL과 뒤로가기 버튼이 필요하다.

사용자가 북마크할 수 있는 URL과 모든 네비게이션이 가능한 상태를 지원하는 뒤로가기

버튼을 제공한다.

<그림 7> Flex Store 에서 ‘Home’과 ‘Product’ 섹션은 확연히 구별되는 네비게이션 상태이다. 그리고 전화의

다른 목록을 가져오는 필터 기준 변경에도 분리된 네비게이션 가능한 상태가 포함되고, 이와 관련된 분리된

URL 을 가지고 있어야 한다(Flex Store 자체가 상태를 위해 URL 을 지원하지 않는다 하더라도).



<그림 8> Flex Store 상의 전화 위에 면 뷰가 바뀐다. 사선의 하이라이트와 인-컨텍스트 컨트롤을

추가한다. 하지만 이것 자체로는 분리된 네비게이션 상태를 포함하지 않고 이 자체의 고유한 URL 이 필요치

않다.

Adobe AIR 에서 작동하는 Desktop Flex 애플리케이션 또한 뒤로가기 버튼과 앞으로가기 버튼의

장점을 가지겠지만 데스크톱 애플리케이션에 있어 이 기능은 선택적이다. 데스크톱

애플리케이션에 뒤로가기/앞으로가기 버튼을 제공하고자 한다면 웹 기반의 Flex 애플리케이션에서

사용하는 것과 같은 네비게이션 모델을 따르도록 해야한다.

어떤 만들기 위주의 애플리케이션은 네비게이션 가능한 컨텐츠를 거의 보여주지 못한다. 또한

웹같지 않은 모양과 기능으로 인해 웹과 같을 거라는 기 를 저버릴 수 있다. 이들

애플리케이션은 URL 바 혹은 뒤로가기/앞으로가기/홈으로가기 버튼같은 크롬을 포함하지 않는

브라우저 창을 열어 사용자들이 애플리케이션에 이런 기능 자체가 없음을 깨닫게 해야한다.

하지만 다수의 Flex 애플리케이션은 이들 브라우저 기능과 통합되야 한다.



<그림 9> Fauxto 는 기본적으로 만들기-구조화 된 접근을 따르므로 뒤로가기/앞으로가기 네비게이션과 URL

바를 포함하는 브라우저 크롬을 제거할 수 있다. 하지만 다수의 Flex 애플리케이션은 이 접근을

사용해서는 안된다.

애플리케이션으로 생성된 문서는 나름의 고유한 문제를 갖는다. 사용자는 만들기 중심의 구조를

직접 사용하여 이들 문서를 만들거나 시스템이 사용자 신 프로세스 구조 또는 다른 입력

인터페이스에 입력을 해 그 결과로 이들 문서를 만들어낸다. 예로는 업로드한 사진, 메시지

보드의 글, 온라인 쇼핑몰 사이트의 주문 내역이나 송장 등을 포함한다. 이들 문서는 자신의

URL 을 가져야 하며 사용자는 이를 북마크할 수 있어야 하고 문제 도메인이 있을 수 있으므로

나중에 수정도 가할 수 있어야 한다.

Flex 접근성

장애자를 위한 접근성은 부분의 웹 및 데스크톱 애플리케이션에 있어 중요한 고려사항이다.

많은 국가에서 정부부처를 위한 애플리케이션을 만드는데 법적으로 지정된 접근성 요구사항을

맞춰야 한다. 법적 의무가 없는 애플리케이션이라도 장애자를 배제시키고 싶어하지 않는다.

이것이 웹/데스크톱에 국한된 이슈가 아니라도 Flex 접근성은 데스크톱과 웹 접근 요소를 모두

포함한다. 이제 장애자를 지원하는 이들 메커니즘을 어떻게 사용하는지 설명하겠다.



접근성을 이야기할 때 다수의 디자이너나 개발자는 화면 리더나 키보드만의 네비게이션을

떠올린다. Flex 는 이들 기능을 모두 지원한다. 표준 컴포넌트 세트에 있어 애플리케이션을 접근

지원이 가능한 것(기본으로 설정할 수는 없다)과 컴파일할 수만 있다면 약간의 추가 작업만 하면

된다. 체로 탭 오더(tab order)만 설정해/SPAN> 되므로 탭 키는 로직의 순서에 따라 컨트롤

사이를 움직이면 된다. 이 기능은 많은 사용자들이 데이터에 접근할 때 필드 사이를 탭 키로

움직이는 경우가 많기 때문에 장애가 없는 사람에게도 중요하다.

<그림 10> 다이어그램은 가상의 주문 양식으로 기 되는 탭 주문을 보여준다. 서구 사용자들은 탭 주문이

섹션 내에서 일반적으로 왼쪽에서 오른쪽으로, 위에서 아래로 이루어지는 것에 익숙해 있다. 한 섹션 내의

모든 컨트롤을 끝낸 후 다음으로 넘어가야 함을 명심하자.

하지만 다수의 장애자들이 장님이 아니므로 화면 리더기가 필요하지 않다. 다수의 시력이

나쁜 경우기 때문에 화면을 볼 수 있지만 작은 글자를 읽는 것이나 저해상으로 요소를 구분하기

어렵다. 또한 많은 사용자들이 운동 기능이 약하여 작은 컨트롤을 사용하는 것에 어려움을 느낀다.

시력이 나쁜 사용자를 위해 색깔과 글자 크기에 신경을 쓰고 쉽게 조작할 수 있는 컨트롤

사이즈를 제공한다. 이를 위한 한 방법은 애플리케이션을 시작할 때 고해상 색깔과 콘트롤하기에

알맞은 큰 글자 크기를 제공하는 것이다. 다수의 사용자가 시력이 안 좋을 때 이 방법은

최고의 방법이다. 물론, 사용자의 다수가 시력에 문제가 없다면 이 디자인은 보기에 좋은



디자인이 아니다. 이 경우 Flex 의 스타일시트를 사용하여 글자 크기, 컨트롤 크기, 색의 화상도를

늘리는 기능을 가진 애플리케이션 디자인의 버전을 제공하면 된다.

고해상 색깔과 큰 타입 및 컨트롤을 가진 버전을 제공하여 시력이 안 좋은 사용자를

지원한다.

<그림 11> Adobe.com 은 시력이 안 좋은 사용자를 위해 타입 크기 조정을 지원한다(보기엔 덜 좋을지라도).

Flash 는 과거 접근성이 떨어진다는 나쁜 명성을 가지고 있었으나, 더 이상 그렇지 않다. HTML

웹 애플리케이션보다 덜 작업하고서도 Flex 애플리케이션을 장애자들에게도 똑같이 접근

가능하도록 만들 수 있다.

데스크톱으로 옮기기

다수의 데스크톱 애플리케이션은 독립적(sovereign) 애플리케이션이나 일시적(transient)

애플리케이션으로 두 유형으로 구분된다(Alan Cooper과 Robert Reimann이 2003 년에 출간한

그들의 훌륭한 책, About Fact 2.0 에서 이런 분류법을 개발했다). 독립적 애플리케이션은 장시간

동안 사용자가 집중하여 사용한다. 체로 풀 스크린 모드에 가장 적합하고 다양한 도구와 기능을

가지고 있으며, 다른 많은 작업을 지원한다. 많은 독립적 애플리케이션은 제작 애플리케이션이다.

예로는 Adobe Photoshop, Microsoft Word, Intuit Turbo Tax가 있다.



<그림 12> Adobe Flex Builder 은 독립적 데스크톱 애플리케이션의 예이다. 작은 아이콘, 정보의 다양한 뷰,

많은 기능이 한꺼번에 폭넓게 사용된다. 독립적 애플리케이션은 장시간 동안 사용자의 주목을 받도록

디자인된다.

반면 일시적 애플리케이션은 짧은 작업에 간단히 열리도록 사용된다. 사용자들이 풀 스크린

모드를 사용할 일은 별로 없다. 체로 독립적 또는 다른 일시적 애플리케이션과 함께 화면

공간을 공유하기 때문이다. 예로는 Microsoft Windows’ Calculator, 다수의 Apple Dashboard

위젯, 데스크톱 디스플레이 프레퍼런스 화상자가 있다. 동시에 어떤 일시적 애플리케이션은

독립적 모드를 취하기도 한다. 예를 들어 Apple iTunes 은 배경에 음악을 듣는 동안에는

일시적이지만 음악을 정리하고 임포트할 때 부분의 시간을 사용하므로 독립적인 면도 갖추고

있다.



<그림 13> 인스턴트 메시징 클라이언트인 Adium 은 일시적 애플리케이션의 한 예다. 사용자들은 환경에서

사용하는 시간이 적고, 나갔다 들어왔다를 반복하므로 컨트롤과 기능이 별로 없다. 일시적 애플리케이션은

가끔씩 사용하기 위해 디자인된다.

독립적 애플리케이션과 일시적 애플리케이션은 다르게 디자인돼야 한다. 독립적 애플리케이션은

사용자의 관심을 독점하므로 더 많은 화면 지면을 갖고 적은 컨트롤을 사용하고 더 복잡하고

연관된(그럼에도 사용가능하고 매력적인) 인터랙션을 사용한다. 일시적 애플리케이션은 간단한

인터랙션을 갖고 애플리케이션이 지원하는 약간의 작업에만 관심을 갖는다. 사용자가

애플리케이션을 가끔씩 방문하므로 사용자 인터페이스 요소보다는 명확하게 모든 작업이 바로

이루어져야 한다.

독립적 애플리케이션을 디자인하려면 더 넓은 화면을 가져야 하고 인터랙션과 작은 컨트롤에

더 집중해야 한다.

일시적 애플리케이션을 디자인하려면 간단한 인터랙션, 큰 컨트롤, 명확한 작업흐름을

갖도록 해야 한다.

애플리케이션을 디자인하기 전에 이들 두 가지 카테고리를 잘 생각하기 바란다. 애플리케이션

유형을 선택하기 전에 지원해야 할 사용자의 목표, 컨텐츠, 작업이 무엇인지 고려하자. 많은



AIR 애플리케이션은 일시적 애플리케이션이 될 것이고, 일시적 애플리케이션은 부분의

디자이너와 개발자가 데스크톱 애플리케이션을 상상할 때 생각하는 방법인 광범위한 독립적

애플리케이션과 달라야 한다.

데스크톱 애플리케이션에서 고려할 점

애플리케이션이 독립적이든 일시적이든지에 상관 없이 디자인에 영향을 미치는 AIR 만의 고려

사항이 있다. 이들 고려 사항은 파일 시스템, 네트워크 연결성, 데스크톱에 제한된 컨트롤과

아이콘 사용 등을 포함한다.

애플리케이션 디자이너와 개발자들은 파일 시스템을 익숙하게 사용하지만, 많은 사용자들은

복잡하고 어렵다고 느낀다. 좋은 Flex 애플리케이션은 이 복잡성을 숨기려 노력한다. 일반적으로

데스크톱 Flex 애플리케이션은 사용자들이 계속적으로 저장할 필요 없이 다른 웹들처럼 지속적

저장 패턴을 따라야 한다. 애플리케이션이 크리에이션 지향이나 문서 지향이 아니라면,

사용자들이 파일 시스템을 사용하지 않아도 되며 유용한 정보만 기억하도록 하면 된다.

애플리케이션에 인터페이스를 제공하여 사용자들이 도메인에 한정된 컨텐츠를 관리하는데 도움이

되도록 하자. 애플리케이션의 인터페이스는 사용자 목표와 관련된 컨텐츠에만 집중해야 하고 상관

없는 상세 파일과 폴더는 제거해야 한다. 다수의 Apple iLife 애플리케이션은 많은 AIR

애플리케이션과 마찬가지로 이 모델을 따른다.



<그림 14> Adobe Media Player 는 사용자들이 파일 시스템을 뒤지지 않아도 되도록 애플리케이션으로

다운로드와 저장된 비디오를 관리한다.

사용자가 직접 파일 시스템을 작업하도록 해야한다면 이 프로세스를 보다 쉽게 만드는 방법을

제공해야 한다. 사용자들은 체로 최근 작업했던 것과 같은 문서에서 작업하기를 원한다. 파일

시스템에서 작업해야 한다면 시간 낭비일 뿐이다. 좋은 데스크톱 Flex 애플리케이션은 최근에

사용한 파일 목록을 제공하여 사용자가 어디에 저장했는지 기억할 필요가 없게 해야 한다. 이

기능을 지운다면 시간과 노력이 덜 들겠지만, 사용자들에게는 어려운 시간이 될 수밖에 없다.

이와 마찬가지로 모든 열린 화상자는 가장 최근에 연 파일들을 포함하는 폴더를 즉시 열어야

한다. 어떤 애플리케이션은 이 프로세스를 더 쉽게 하기 위해 최근 폴더 목록을 제공하기도 한다.

파일 시스템의 복잡성을 감춘다.

<그림 15> Adobe Dreamweaver 는 애플리케이션의 환영 화면에 바로 뒤 이어 최근에 사용한 파일 목록을

제공한다. 이렇게 되면 사용자는 즉시 지난 번에 작업했던 문서가 어디에 있는지 알게 된다.

네트워크 연결성은 AIR 만의 고유한 특성은 아니다. 하지만 AIR 을 목표로 하는 Flex

애플리케이션은 더 확장된 오프라인 능력을 지원하므로 네트워크 연결이 기능 감소를 의미한다



하더라도 애플리케이션 자체는 사용할 수 있다. Flex 애플리케이션의 두 유형 모두 강요는

아니지만 쉽게 표시되는 형태로 네트워크 연결성 없이 소통해야 한다. 네트워크 연결성 없이

소통하는 최악의 방법에는 화상자 열기(너무 강요적임)와 화면 구석의 작은 아이콘

변경하기(쉽게 눈에 띄지 않음)가 있다. 적절한 소통 방법은 애플리케이션에 부분적으로

의존하지만 디자이너는 배경 화면이나 이미지를 바꿈으로써 모드를 바꾸는 것이다.

애플리케이션의 일부 기능이 못쓰게 된다면 이 기능을 없애고 인라인 메시지나 도구 팁으로

온라인에서만 가능함으로 표시하면 된다.

명확하게 소통하는 기능 변경은 네트워크 연결성이 없어지기 때문이다.

마지막으로 데스크톱 애플리케이션에서만 일반적으로 나타나는 몇 가지 컨트롤을 살펴 보자.

전통적인 메뉴바는 Flash Player 기반의 Flex 애플리케이션에는 적절치 못하다. 사용자들이

브라우저의 메뉴바와 헷갈려 하기 때문이다. 데스크톱 애플리케이션에서 사용자는 이를 기 한다.

메뉴바는 항상 필요한 것은 아니다. 많은 일시적 애플리케이션은 메뉴바가 없으므로 있을 거라는

가정도 하지 않는다. 하지만 많은 데스크톱 애플리케이션에서 메뉴바는 중요한 기능을 한다. 특히

사용자들이 애플리케이션 메뉴에서 기 하는 다양한 도구가 있는 애플리케이션 만들기에

중요하다. 많은 사용자들이 시도나 오류를 통해 애플리케이션을 배우므로 사용자가 사용할 수

있는 기능을 발견하는 일반적인 방법을 제공하는 메뉴는 중요한 교육 도구가 된다. 다시 말하지만

사용자들이 톱 레벨 메뉴를 열고 훑으므로써 새 기능을 검색하는 것을 많이 보아 왔다. 모든

중요한 기능을 메뉴 아이템에 넣고 적절하게 이름을 지어 바로 뜰 수 있도록 해야 한다.




<그림 16> Adobe Fireworks 같은 복잡한 데스크톱 만들기 애플리케이션은 메뉴를 새로운 기능을 찾는

기준으로 사용한다. 데스크톱 애플리케이션이 한 화면에 많은 기능을 제공한다면 메뉴를 같은 방법으로

사용할 것을 고려하기 바란다.

여러 개의 애플리케이션 창은 데스크톱 애플리케이션에서만 전형적으로 나타나는 또 다른

컨트롤이다. AIR는 다중 창을 지원하지만, 다수의 Flex 애플리케이션은 창 수를 최소한으로

제한한다. <Flex 디자인하기 – Part 3: 애플리케이션 구성하기>에서 설명했듯 Flex 애플리케이션은

일반적으로 화면에 구성돼 사용자 목적에 따라 완전 분리된다. 창은 화면을 분리하는 용도로만

사용한다. 사용자가 창을 바꿔 사용하더라도 사용자 작업 흐름과 심적 프로세스를 방해하는

컨텍스트 변경은 최소한으로 해야 한다. 웹 애플리케이션의 화면처럼 스스로 제한적인

작업흐름에만 창을 사용해야 한다.

연결되지 않은 페이지로 이동할 때를 제외하고, 데스크톱 애플리케이션에서는 창을 늘리지

말아야 한다.

Flash Player 이든 AIR 이든에 상관 없이 모든 Flex 애플리케이션은 새로운 방법으로 웹과

데스크톱 용어로 결합된다. 애플리케이션의 환경을 조심스럽게 살펴보면 이들 언어를 사용자들이

납득할 수 있는 모델로 결합할 수 있고 사용자 기 를 저버리는 괴물같은 애플리케이션을 피할

수 있다.

http://www.adobeflex.co.kr/iwt/board/board.php?tn=pds_tech&id=137&mode=view



Flex 디자인하기 – Part 5: 컨텐츠 디스플레이 디자인하기

애플리케이션 디자이너와 개발자들 사이에 널리 알려진 잘못된 방식 중하나는 먼저 애플리케이션

디자인에 집중하고 다음에 컨텐츠를 신경쓰는 것이다. 부분의 사람들이 컨텐츠를 나중에

생각한다. 컨텐츠를 와이어프레임에 ‘X’로 꽉 찬 큰 박스, 데이터베이스 담당자가 남겨둔 공간,

화면 제품이라 생각하는 것이다. 하지만 다수의 애플리케이션에서 사용자들이 신경쓰는 것은

컨텐츠다. 버튼, 탭, 패널은 컨텐츠와 함께할 때 의미가 있다. 그러므로 제 로 디자인한 Flex

애플리케이션은 이런 철학을 반영한다. 컨텐츠 디스플레이는 Flex 애플리케이션 디자인의 주

요소다. 애플리케이션 크롬(chrome)이 존재해야 한다면 이들 디스플레이를 지원하기 위해서만

존재한다.

본 글은 다음의 주제를 다룬다.

• 정보 디자인 – 컨텐츠를 둘러싼 애플리케이션 디자인하기

• 사용자가 컨텐츠를 네비게이트할 수 있는 인터페이스 디자인하는 방법

• 사용자가 컨텐츠를 조작할 수 있는 인터페이스 디자인하는 방법

• 컨텐츠 중심의 인터페이스에서 사용자 액션에 피드백을 제공하는 방법

• 컨텐츠 중심의 인터페이스에서 표준 제어를 이용하는 방법

• 컨텐츠에 관심을 갖도록 디자인을 제어하는 방법

정보 디자인

컨텐츠 디스플레이를 디자인하는 것은 새로운 아이디어는 아니다. 정보 디자인 분야는 인쇄나

TV 에서 이미 수 백년 전부터 문제제기를 해왔다(‘정보 디자인’이라는 용어는 1970 년 부터

사용되기 시작했지만 그 이전부터 있었던 개념이다. 심지어 어떤 사람들은 초기 동굴벽화로

사람들이 소통한 것에서부터 시작한다고 주장하기도 한다). 정보 디자이너들은 표지판에서 지하철

지도, 안내 그림까지 모든 종류의 커뮤니케이션 장비를 만든다. 컨텐츠 디스플레이를 효과적으로

디자인하려면 정보 디자이너처럼 생각해야 한다.

컨텐츠는 다양한 형태를 가진다. 개인 디지털 장비는 약속, 날짜, 업무 등의 컨텐츠를 갖는다.

항공사 예약 시스템은 비행 날짜, 여행 경로, 티켓 등을 포함한다. 여행 플래너는 길, 지도,

위치를 포함한다.

컨텐츠를 효과적으로 디자인하려면 컨텐츠를 중심에 두고 디자인을 생각해야 한다. 사용자가

애플리케이션을 보고 조작하는 실제 사례를 중심으로, 이 애플리케이션으로 사용자가 하고자 하는


업무를 이해해 보도록 하자. 정보 중심의 애플리케이션 구조를 위해 사용자가 컨텐츠에 갖는 질문

– 즉, “8 월 첫째 주에 북경으로 가는 가장 저렴한 항공표는 무엇인가?,” “오늘 어떤 약속을

잡을까?,” “러시아워에 다운타운까지 가장 빠르게 갈 수 있는 방법은?”과 같은, 사용자 요구에

맞게 프레임을 재구성하고 싶을 것이다.

사용자가 컨텐츠에 해 가지는 질문에 맞게 컨텐츠 디스플레이를 디자인하자.

샘플 컨텐츠와 사용자의 주요 질문을 갖게 되면, 여러분의 목표는 사용자가 질문에 한 답을

얻을 수 있는 컨텐츠 디스플레이를 디자인하는 것이다. 질문이 너무 다양해 컨텐츠의 멀티 뷰를

제공해야 한다면 어떤 뷰가 어떤 질문에 답을 줄 것인지 생각하며 각 뷰별로 디자인해야 한다. 이

시점에서는 네비게이션바나 다른 애플리케이션 크롬을 걱정하지 말자. 먼저 정보 디자인을 제 로

가지고 있는지 확인하고 그 다음에 필요한 인터랙션에 어떻게 추가할 것인지 고민하자.

컨텐츠 디스플레이를 먼저 디자인하고 컨트롤과 다른 애플리케이션 크롬(chrome)은 나중에

추가하자.

<그림 1a> 효과적인 컨텐츠 디스플레이를 디자인하려면 항상 실제 컨텐츠의 샘플로 시작해야 한다. 이

이미지는 매체 중심의 애플리케이션 디자인 프로세스의 첫 단계를 보여준다. 즉, “라이브러리와” 스토어”에

느슨히 정렬된 샘플 컨텐츠의 세트를 보여준다.



<그림 1b> 샘플 컨텐츠를 갖게 되면 컨텐츠 디스플레이를 정렬하여 사용자가 쉽게 업무를 달성하도록

하거나 사용자의 질문에 답할 수 있게 한다. 아직 인터랙션에 해서는 걱정하지 말자. 마치 사용자가

보아야 하는 오직 하나의 정보인것처럼 포스터나 간판 같은 실제적 정보 디스플레이를 디자인한다고

가정하자. 예를 들어 미디어센터처럼, 위의 그림에서 앨범을 사용자들이 흥미를 느끼는 방식으로 – 인기있는

앨범, 개인적으로 좋아하는 앨범, 전체 앨범 - 나눠 정리했다.



<그림 1c> 정적인 디스플레이를 디자인한 후 인터랙티브한 요소를 추가함으로써 사용자들이 정보를

역동적으로 네비게이트할 수 있도록 한다. 컨트롤을 최소로 하고 사용자들이 필요로 하는 것 이상의 기능은

제공하지 말자. 실제 사용하는 것보다 기능이 많아지면 사용자들은 오히려 불편해한다(원 디자인: Ty Lettau).

정적 컨텐츠 디스플레이 디자인에 만족하면 여기에 사용자의 질문에 답할 수 있는 최소의

네비게이션, 필터, 조작 컨트롤을 추가한다. 잘 디자인된 컨텐츠는 중심에 위치시킨다. 모든

애플리케이션 기능을 한 눈에 볼 수 있도록 화면에 컨트롤을 몰아넣지 말아야 한다.

<그림 2a> 많은 Apple의 시보드 위젯은 위젯 반 방향에 약간의 구성 컨트롤만을 옮기고 주 화면에 날씨,

주식, 시간, 기차 시간 등의 컨텐츠 디스플레이만 놓음으로써 컨트롤이 산재해 있는 것을 방지한다.



<그림 2b> Yahoo Maps은 커다란 애플리케이션이고 사용자가 원하는 것을 얻기 위해 많은 컨트롤을 필요로

하지만 디자이너는 부분의 공간을 지도 자체만을 보여주는데 할애했다. 컨트롤은 지도를 방해하지 않는

수준에서 지도 위에 놓여있다.

Flex 애플리케이션의 컨텐츠 디스플레이 디자인과 전통적인 웹 및 데스크톱 애플리케이션

디자인의 중요한 차이는 Flex 컨텐츠 디스플레이에서는 네비게이션을 최소화한다는 것이다.

분리된 뷰나 비슷한 디테일 뷰를 제공하는 신에 Flex 애플리케이션은 가장 적절한 컨텐츠

디테일을 기본적인 컨텐츠 디스플레이 자체에 통합해야 한다.

인터페이스 디자인의 일반적인 패턴은, 컨텐츠 아이템으로 약간의 정보만 보여주고 목록이나

트리로 ‘마스터/디테일’이나 ‘오거나이저/작업공간’을 보여주는 것이다. 사용자가 한 아이템을

선택할 때 애플리케이션은 바뀐 다른 화면이나 화면의 다른 창에 아이템의 자세한 사항을

보여준다. 이는 좋은 패턴이고 효과적으로 적용될 수 있지만, 목록 자체에 부족한 정보를

제공하기 십상이다. 즉, 사용자는 원하는 정보를 찾아보기 위해 지속적으로 몇 가지 아이템을

클릭해야 한다. 현재 선택한 아이템과 이전 선택한 아이템을 비교하기 위해 단기 기억에 의지해야

하는 것이다. Gmail 은 주 목록에 보낸이의 이름과 제목뿐만 아니라 메시지 자체의 첫 줄을 함께

보여줌으로써 이 분야에서 혁신을 일으켰다.

가능한 한 관련 높은 정보를 하나의 컨텐츠 디스플레이로 통합하자. 정보를 몇 가지

화면이나 상태로 나누지 말자.



<그림 3a> Gmail은 다른 이메일 클라이언트와는 달리 각 메시지와 메시지 목록 자체를 통합시킴으로써

메시지 목록과 개별 메시지 디스플레이 사이를 왔다갔다 할 필요를 줄였다. 사용자들은 이메일 관련한 모든

참여자를 볼 수 있고 메시지 목록 뷰를 떠나지 않아도 가장 최신 메시지 발췌를 볼 수 있다.

<그림 3b> Adobe Media Player는 필요한 공간에 디테일을 보여주면서도 마스터/디테일을 이용하고 있다.

규모 비디오를 지원하기 위해, 하위 카테고리로 들어갈 때 매스터-디테일 모델을 사용한다. 이 모델 덕에

사용자들은 카테고리 전반의 정보를 비교하지 않아도 되고, 주 화면에서 최초 비디오 세트는 카테고리 이름

밑에 놓인다. 이로써 사용자들은 카테고리 자체를 더 잘 이해할 수 있다.




컨텐츠 목록을 디스플레이하고 인터랙트하는 Flex 의 메카니즘은 매우 유연하며, 디자이너들이

목록 자체에 리치 정보 컨텐츠를 놓을 수 있게 한다. 정보를 다른 화면에 배치하는 신,

사용자들이 자신의 질문에 한 답을 보고자하는 것을 고려한다면 이 기능을 이용하면 된다.

모든 컨텐츠를 한 공간에 넣으려면 신중하고 기술력 있는 커뮤니케이션 디자인이 필요하다. <Flex

디자인하기 – Part 3: 애플리케이션 구성하기>에서 논의했던 것처럼 컨텐츠 요소에서 시각적

계층을 적절히 사용하려면 사용자가 정보의 풍부함을 제 로 이해하는 것이 중요하다. 실력있는

정보 디자이너가 시각 정보 디자인 원칙을 효과적으로 애플리케이션 인터페이스에 적용하면 많은

Flex 애플리케이션은 효과를 극 화 할 수 있을 것이다.

컨텐츠 네비게이트와 조작하기

잘 디자인된 컨텐츠에는 많은 네비게이션이나 조작도 많이 필요하지 않다. 하지만 많은 컨텐츠

데이터베이스는 너무 거 하기 때문에 특정 컨텐츠를 찾거나 다른 컨텐츠와 비교 혹은 어떤

컨텐츠가 있는지 확인하기 위해 사용자들은 열람 및 검색해야 한다.

전통적인 웹 사이트와 애플리케이션은 정보 계층으로 컨텐츠 구성 전략(content organization

strategy)을 이용하곤 한다. 각각의 컨텐츠는 카테고리에 부여되고 사용자는 정확한 카테고리에서

원하는 정보를 찾아야 한다. 많은 기업체들이 사용자 기 에 부응하는 정확한 카테고리화

시스템을 디자인 및 연구하기 위해 엄청난 투자를 하고 있다.

Flex 애플리케이션 디자인에도 카테고리가 있지만 - 특히 작고 경량일 때 - 일반적으로는 계층을

피한다. Adobe 의 LiveCycle Form Manager 제품은 계층적 접근을 취해 사용 적합성을

감소시킨다. 모든 폼은 사용자들이 실제 업무(요청에 맞게 입력하기)에 돌입하기 전에 새

업무(폼을 찾는)를 수행하도록 강요해 트리 컨트롤 어딘가에 나타난다. 다수의 계층적 시스템은

사용자가 흥미를 느끼는 컨텐츠에 닿기 전에 네비게이션 업무를 수행하도록 하고 <Flex

디자인하기 – Part 3: 애플리케이션 구성하기>에서 언급했듯이 정보 중심의 구조는 가능한

신속하고 쉽게 사용자들이 원하는 컨텐츠를 찾도록 해야 한다. 또한 계층 구조는 사용자들이

컨텐츠를 찾는데 어려움을 느끼므로 좋은 Flex 애플리케이션이 되기에 부족하다.


<그림 4> Adobe LiveCycle Form Manager은 덜 계층적이어야 하는 인터페이스의 한 예다. 계층에서는

사용자들이 실제 업무를 시작하기 전에 폼이 어떤 카테고리 밑에 있는지 추측해야 한다. 카테고리는

혼란스러울 수 있다. 예를 들어, 유급휴가를 돈으로 환산하는 폼은 ‘출석 및 휴가’ 카테고리 하에 있어야

하는가? ‘봉급 지급’ 카테고리 하에 있어야 하는가?

웹 상에서 전형적인 컨텐츠 열람하기는 주로 검색 폼 채우기와 관련이 있고 열람 결과는 가장

흥미로운 컨텐츠 찾기에 있다. 사용자가 검색 매개변수를 바꾸려면 뒤로가기 버튼을 눌러 폼을

다시 채우고 새 결과 세트를 둘러봐야 한다. 이 경험은 특정하고도 미리 결정된 컨텐츠를 찾을 때

최적이지만 컨텐츠 공간을 찾는데는 효과적이지 못하다.

가끔 사용자들은 자신이 찾고자 하는 것이 정확히 무엇인지 모르는 채 애플리케이션에 접속한다.

신 원하는 것에 한 일반적 생각을 가지고 있는 컨텐츠를 기반으로 결정하려 한다. 사용자들이

원하는 것을 정확히 알 때에도 비슷한 컨텐츠를 찾아 비교해 보고자(예를 들어 온라인 상점에서

경쟁 상품을 비교할 때) 하기도 한다. 이런 이유로 쉽게 알아볼 수 있는 컨텐츠 경험을

디자인해야 한다.

사용자들이 컨텐츠를 찾는 것뿐만 아니라 알아보기 쉽도록 만들자.



검색과 필터링 기능을 컨텐츠 열람 경험과 자연스럽게 통합해보자. 인터페이스를 각각의 검색,

네비게이션, 결과 페이지로 나누지 마라. 사용자들이 검색 및 필터 매개변수를 쉽게 수정하고,

바로 결과를 볼 수 있는지 확인하자. 필터 폼과 결과 뷰 사이를 옮겨다니는 시간이 적어질수록

컨텐츠를 보고 이해하는데 더 많은 시간을 할애할 수 있다.

사용자가 변경하는 즉시 검색 및 필터 컨트롤을 응답하게끔 하여 컨텐츠 탐색을 지원하자.

<그림 5a> INM Library 사이트는 속성 기반의 컨텐츠 네비게이션 전략을 사용한다. 이를 통해 사용자는

카테고리뿐만 아니라 키워드, 연도, 소스에 기반하여 문서를 찾을 수 있다.



<그림 5b> Flex Support Forum은 계층적 네비게이션 전략을 이용한다. 사용자는 한 번에 하나의 카테고리와

관련된 컨텐츠만을 볼 수 있어 카테고리 전반의 글을 찾는데 큰 어려움을 느낀다.




<그림 5c> Yahoo! Search는 검색/결과 네비게이션 전략을 사용한다. 사용자는 키워드 기반의 웹 페이지만

찾을 수 있다.

컨텐츠를 네비게이트하는데는 몇 가지 방법이 있다. 텍스트나 그래픽 결과 목록은 필터 컨트롤과

함께 결과 디스플레이를 동반하는 가장 일반적인 것중의 하나다. 하지만 공간적 데이터 같은

컨텐츠는 패닝이나 줌이 가능한 표면 상에서 더 쉽게 보인다. 인터랙션 모델의 이 변경은

알아보기의 필요성을 계속 가지고 있다. 즉, 애플리케이션을 맞추는 것은 Google Maps 이 이전

인터페이스에서 이용한 불편한 화살표나 화면 새로고치기와 비교해 드래깅 및 맵 찾아보기가

훨씬 쉬워졌을 때 더 효과적이다.

부분의 Flex 애플리케이션은 확장된 컨텐츠 조작 기능을 제공할 필요가 없다. 창작

애플리케이션을 디자인하는게 아니라면 사용자에게 많은 조작 옵션을 주지 말자. 사용자가

컨텐츠를 조작해야 할 때 기능을 가능한 한 간단하고 찾기 쉽게 만들어야 한다. 다이렉트를

선호한다는 것은 간접적으로 컨텐츠를 조작한다는 뜻이다. 예를 들어 한 목록에서 다른 목록으로

아이템을 옮기기 위해 버튼을 추가하는 신 사용자가 이를 드래그앤드롭 하도록 하면 된다.

드래그앤드롭은 Flex 애플리케이션에서는 일반적인 인터랙션이다. 항상 컨텐츠의 부분을

재배치하고 움직이도록 하자. 한정적 공간에서의 컨트롤을 사용해 다른 컨텐츠 조작 기능을

나타내는 것은 이후 ‘컨트롤과 컨텐츠 결합하기’에서 다루겠다.

다이렉트를 선호한다는 것은 간접적으로 컨텐츠를 조작한다는 뜻이다.


<그림 6> Netflix의 영화 큐(queue)를 배치하는 인터페이스는 원래 간접적 조작을 기반으로 했다. 큐를

재주문하려면 사용자는 각 영화 다음에 있는 번호를 바꾸거나 ‘위로가기’ 버튼을 사용해야 했다. 이

인터페이스로는 사용자가 주문에 어려움을 겪으리라는 것을 알아차린 Netflix는 한 큐 위치에서 다른 곳으로

영화를 끌어넣기 할 수 있는 기능을 추가했다 – 직접 조작 전략.

검색 결과 디스플레이, 지도 네비게이션, 조작할 수 있는 차트 및 그래프 같은 정보 구조에서는

특히 인터랙티브한 컨텐츠 디스플레이가 간단하고 실제 사용에 있어 맞다는 느낌을 가질 수

있게끔 디자인하는데 힘써야 한다. 애플리케이션 부분의 원형을 만드는데만 시간을 낼 수 있다면,

컨텐츠 디스플레이의 원형을 만들어라. 인터랙션이 제 로 느껴지는지 여부에 따라 전체 Flex

애플리케이션을 만들수도 다시 부술수도 있다.

피드백으로 컨텐츠 결합하기

초기 GUI 에서부터 애플리케이션을 괴롭혀왔던 너무나 흔한 방식은 팝업 화상자다. 디자이너와

개발자들은 팝업 화상자를 다양한 목적으로 사용한다. 기능에 한 피드백 제공, 작동불가의

기능 경고, 오류 보고, 또는 기능의 목적 설명(심지어 ‘다시는 보여주지 말기’ 체크박스도 많이



사용된다) 등이 여기에 포함된다. 이들 팝업 화상자는 디자인 및 프로그램하기 쉬우므로

일반적으로 사용되지만 슬프게도 사용자들에게는 성가신 경험이다.

<그림 7> 위와 같은 팝업 화상자는 전통적 방식의 애플리케이션에서는 널리 쓰이지만 사용자에게

피드백과 그외 정보를 주는 가장 예의없고 불쾌한 방법 중 하나다.

사용자에게 팝업 화상자는 팝업 광고와 다를 바 없다. 이들은 시각적 방해뿐만 아니라 즉각적인

주목을 요한다. 하지만 흥미로운 정보를 포함하지 않는 경우가 많으므로 사용자는 제 로 보지도

않고 닫아버리는 경우가 많다. 피드백을 제공하는 예의없고 불쾌한 방법이므로 가능한한 사용을

자제해야 한다.

하지만 팝업 화상자가 아니라면 어떤 방식으로 정보 제공이나 사용자의 경고, 오류를

공지하겠는가?

비양식 피드백(modeless feedback)을 사용해 메시지를 정보 디스플레이에 넣도록 디자인하면

된다. 비양식 피드백으로 사용자 흐름을 깨지 않고도 정보를 통합할 수 있다. 예를 들어 사진

썸네일 목록을 가지고 있고, 사용자들이 실제 크기를 아는 것이 중요하다고 한다면 사용자에게 이

정보가 들어간 화상자를 보여주는 신 썸네일 아래에 크기를 두는 방식을 생각할 수 있다.



기능의 중 함에 해 사용자들에게 경고하고자 한다면 기능 버튼이나 컨트롤에 콜아웃을

부착하는 방법을 생각한다.

비양식 피드백이 컨텐츠와 통합되는 것이 팝업 화상자보다 낫다.

<그림 8a> Adobe Photoshop Lightroom 은 비양식 피드백을 사용해 사용자에게 명령이 제 로 실행됐음을

알린다. ‘원상태로 돌리기’ 명령을 수행한 후 위의 비양식 메시지가 컨텐츠 위에 나타나고 알아서 슬쩍

사라진다.



<그림 8b> Microsoft Outlook은 사용자가 새 이메일 메시지를 받았음을 알릴 때 비양식 피드백을 이용한다.

공지 상자가 화면 우측 하단에 위에 나타나는데 Outlook이 작아졌거나 숨겨졌을 때에도 나타난다. Outlook의

비양식 공지자는 또한 이메일 메시지와 관련된 상세 내용(메시지, 제목, 메시지 텍스트의 발췌)도 포함한다.

<그림 8c> OmniGraffle은 문서 캔버스에 직접적으로 다른 종류의 제공한 비양식 피드백을다. 사용자가

lex 의 유효성 검사는 프레임워크에 만들어진 비양식 피드백 방식을 탄탄히 구현한다. 사용자가

문 며

모양을 드래그하는 로 툴팁(tooltip)이 떠서 x와 y 위치를 디스플레이하고 안내가 나타나 정렬 및 공간

힌트를 준다. Outlook이나 Lightroom과는 달리 OmniGraffle의 비양식 피드백은 텍스트 메시지를 보여주지

않지만 도움이 되는 정보를 슬쩍 보여준다. 각각의 예에서 디자이너가 비양식 피드백 신 팝업 화상자를

이용했다면 사용자가 얼마나 불편했을지 상상해보자!

F

폼 필드에 값을 잘못 넣었을 때 화상자를 띠우는 신 유효성 검사는 폼 필드 옆에 빨간

콜아웃 박스를 보여주어 무엇이 잘못됐는지 설명하고 제 로 된 포맷을 소개한다. 팝업

화상자에 비해 세 가지 장점이 있다. 덜 성가시고 더 맥적이 잘못된 정보를 포함한 폼

필드를 더 깨끗하게 만든다. 여기에 사용자가 오류는 나중에 고치되 이전으로 되돌아가고자 하는

경우 사용자 흐름을 방해하지 않는다.



<그림 9> Flex의 빌트인 유효성 검사는 유효하지 않은 폼 오류에 비양식 피드백을 제공하는 편리한

방법이다. 유효성 검사는 잘못된 입력을 포함한 필드를 강조하고 비양식 콜아웃을 제공해 무엇이 잘못됐는지

설명한다. 이는 사용자가 필드에서 나가거나 폼을 제출하려 할 때 전통방식의 화상자를 보여줄 때 보다

훨씬 덜 불쾌하다.

애플리케이션을 디자인하거나 개발할 때 자신에게 물어보자. 이용하는 팝업 화상자 중 몇 개가

진짜 필요한지, 그리고 비양식 피드백으로 더 잘 실행될 수 있는지 여부를 말이다.

컨트롤과 컨텐츠 결합하기

본 글에서는 부분 컨트롤을 사용하지 말고 컨텐츠를 디자인하는 방법을 설명했고, 심지어

콘트롤 사용을 최소화하라고까지 했다. 하지만 거의 모든 애플리케이션은 인터랙션 패턴이 필요할

것이다. 그렇다면 컨텐츠에게 방해가 되지 않게 컨트롤을 이용할 수 있는 방법은 무엇일까?

먼저 사용자의 목표를 만족시키는데 모든 컨트롤이 필요한지 여부를 고려하자. 컨텐츠 자체 내의

요소는 가끔 호버(hovers), 클릭, 드래그에 인터랙티브하거나 반응하게 되고 다른 사용자는 추가

정보나 새 정보를 디스플레이하기 위해 입력한다. 이런 ‘크롬없는 컨트롤’의 단점은 찾기

어렵다는데 있다. 인터랙티브하게 보이지 않으므로 사용자가 컨트롤이라 생각하지 않는 것이다.

이 어려움을 해결하려면 정적인 것에서 화면의 인터랙티브한 요소를 구분하면 된다.

어포던스(affordance)는 시각적 처리로 사용자가 이것으로 무엇을 할 수 있는지 알려주는

인터랙티브한 화면 요소에 적용된다. 어포던스의 가장 일반적인 예는 호버 강조하기로 일관성을

위해 거의 항상 이용돼야하는 것이다. 상황에 따라 인터랙티브한 요소뿐만 아니라 사용자가

어포던스로 무엇을 해야하는지 알기 위해 다른 어포던스도 이용하고자 할 것이다. 일반적인 예로

널링(knurling)이 있다. 널링은 스크롤바 썸 등에 추가되는 작은 능선이다. 널링은 널링 자체의



위치에서 잡기와 움직이기 기능을 제공한다. 실제적 객체에서 널링은 추가로 마찰을 제공해

사용자가 부드러운 화면으로 바꾸거나 미끄러지듯 옮겨질 수 있도록 하기 때문이다.

어포던스를 이용해 컨텐츠의 어떤 아이템이 인터랙티브한지 명확히 보여주자.

<그림 10a> Adobe Media Player은 호버 강조하기 기법을 사용해 쇼의 썸네일을 클릭할 수 있다는 것을

나타낸다. 이를 통해 사용자는 썸네일이 정적인 정보 디스플레이가 아니라 인터랙티브하다는 것을 발견할 수

있다.

<그림 10b> Google Maps 또한 인터랙티브한 컨텐츠다. 사용자는 맵을 드래그하여 화면에 나타나는 부분을

정할 수 있다. 이런 경우 컨텐츠 자체의 폼은 드래깅이 가능하다. 지도는 제한된 화면에 나타나는 것보다

체로 크다. 그러므로 줌과 팬 컨트롤이 있다면 사용자는 드래깅이 옵션이라는 것을 이해하게 된다. 오픈




핸드 커서(open hand cursor) 또한 도움이 되지만 컨텐츠가 지도 신 여러 장의 나열된 사진이라고

가정한다면 꼭 그렇지만도 않다. 드래깅은 체로 썸네일 목록과 함께 하지 않으므로 사용자들이 드래그

기능을 발견하지 못하는 경우가 많다.

컨트롤이 필요할 때 컨텐츠 자체의 컨텍스트에서 이들을 디스플레이하는 것을 고려하자. 예를

들어 서버에 웹 사이트 목록을 가지고 있고 사용자는 이들 중 하나를 사용해 사용 통계에 관한

보고서를 생성해야 한다고 하자. 사용자가 아이템을 선택하여 툴바 버튼에 옮겨 보고서를

생성하는 신에 목록 아이템 자체 옆에 모든 다른 적절한 기능과 함께 보고서 생성 버튼을

제공하자. (주의해야 할 점은 사용자가 하나 이상의 아이템을 선택하고 한 번에 선택한 아이템

모두를 적용하려고 한다면 이 패턴은 적절하지 못하다는 것이다).

사용자가 조작하는 컨텐츠의 컨텍스트에 컨트롤을 디스플레이하자.

체로 화면의 모든 컨텐츠 요소 옆에 모든 컨트롤을 보이게 하면 매우 복잡한 인터페이스

디자인이 될 수 있다. 모든 컨트롤을 항상 디스플레이하는 신 사용자가 흥미를 느끼는 기능에

마우스를 가져 면 보여주거나 혹은 선택할 때 아이템 컨트롤을 보여주는 방식을 고려하자.

아마도 아이템 위의 오버레이(overlay)에 관련 컨트롤을 놓아야 할 것이다. 특히 목록처럼 관리된

레이아웃에서 특히 인기가 있는 또 다른 옵션은 아이템을 확장해 선택에 따라 추가 컨트롤과

컨텐츠를 보여주는 것이다. 하지만 이 방식을 사용하는데 주의를 기울여야 한다. 선택이나 호버

뒤로 컨트롤을 숨기게 되면 일반 사용자가 이를 찾아 사용하기가 더 힘들게 된다. 사용자가

컨트롤을 필요로 하기 전에 원하는 컨텐츠를 자연스럽게 선택하거나 호버 오버하게 될 때만 이

방식을 이용하자. 사용자들이 미리 시험해보게끔 하는 것이 필요하다.


<그림 11a> Picnik은 자체 UI 전반에 in-컨텍스트 컨트롤을 사용한다. 예를 들어 사용자가 이펙트를 적용할

때 필터 목록 내의 필터 아래에 구성 옵션이 바로 나타난다. 이렇게 하면 사용자가 필터를 적용한 직후 이를

커스터마이즈하는게 훨씬 쉽다.



<그림 11b> Flex Store은 in-컨텍스트 컨트롤을 이용하여 아이템에 호버 오버할 때 사용자들이 아이템을

장바구니에 추가하거나, 다른 아이템과 비교, 혹은 아이템의 전체 설명을 볼 수 있도록 한다.

정보 구조에서 사용자의 주 관심사는 컨트롤이 아니다. 최소화되어야 하지만 사용자의 목표가

정보 디스플레이를 네비게이트하거나 조작하는 것이라면 컨트롤을 쉽게 찾을 수 있어야 한다.

이들 컨트롤을 컨텍스트에 맞게 만들어야 일석이조의 효과를 얻을 수 있다. 사용자가 컨트롤을

필요로 할 때 정확히 나타나겠지만 필요 없을 때에는 정보 자체만을 보여주기 위해 화면이나

인터페이스를 복잡하게 만들지 않는 것이다.

컨트롤 디자인하기

Flex 애플리케이션에 컨트롤이 나타날 때는 애플리케이션 컨텐츠의 시각적 스타일과 전반적인 웹

애플리케이션 브랜드와 맞춰야 한다. 다행히 Flex 에서는 쉽게 할 수 있다. Flex 스타일링(styling)

과 스키닝(skinning) 매카니즘을 사용해 애플리케이션의 시각적 모습을 거의 다 커스터마이즈할

수 있다.



<그림 12> 스타일링과 스키닝이라는 두 가지 메커니즘을 사용해 Flex 컨트롤의 모습을 얼마든지 바꿀 수

있다. 스타일링은 기본 컨트롤 모양의 속성을 변경해 표준 모양에 변화를 줄 수 있는 것을 말한다. 스키닝은

Adobe Photoshop, Adobe Illystrator, Adobe Flash, Adobe Fireworks 같은 Adobe Creative Suite 도구를

사용해 만든 모양을 표준 모양과 바꾸는 것을 말한다. 스킨은 스타일보다 훨씬 유연하지만, 만드는데 오랜

시간이 걸리는 경향이 있다.

하지만 주의해야 할 점이 있다. 일반적인 컨트롤 라이브러리의 주된 장점 중 하나는 표준화에

있다. 사용자는 이들 컨트롤에 익숙하고 어떻게 사용해야 하는지 안다. 컨트롤을 너무 확

바꿔버리면 이 장점을 잃게 된다. 표준이 아닌 컨트롤은 사용자들이 인터페이스의 크롬을 어떻게

조작하는지에 집중하게 하므로 진정 원하는 컨텐츠와 업무에 집중하는데 방해가 된다.

사용자들에게 있어 표준 컨트롤의 가장 중요한 점은 작동 방식이다. 예를 들어 사용자는

스크롤바가 특정 방식의 세트를 구현한다고 알고 있다. 썸은 뷰에서 전체 스크롤 영역이 얼마나

되는지 나타내고 트랙을 클릭하면 썸을 클릭한 위치로 보내게 되며 화살표 버튼을 누르면 스크롤

영역이 위나 아래로 한 단계가 이동될 것이라는 등이 그것이다. 스크롤바가 이런 방식을 구현하지

않거나, 사용자가 알고 있는 방식으로 구현되지 않는다면, 컨트롤의 시각적인 모습이 표준

Windows 나 Macintosh 스크롤바와 같아도 당황하게 된다(사실 컨트롤의 시각적 모습이 표준

컨트롤과 같을 때 특히 중요하다. 가장 혼돈스러운 컨트롤은 모습은 표준 컨트롤인데, 다른

방식으로 작동하는 컨트롤이다). Flex 의 상용 컨트롤 또한 이들 표준 방식을 따른다. 이런 이유로

상용 컨트롤이 있을 경우에는 자신만의 컨트롤을 재구현하면 안된다.

적절한 상용 컨트롤이 있을 경우 자신만의 컨트롤을 재구현하면 안된다. 신 컨트롤을

필요에 맞게 커스터마이즈 하라.



<그림 13> 위의 그림은 스크롤바 컴포넌트의 원래 방식을 설명한다. 많은 표준 컨트롤처럼 스크롤바는

사용자들이 의존하게 되는 많은 미묘한 기능을 가지고 있다. 애플리케이션의 스크롤바가 이들 기능을

구현하지 않는다면 사용자는 혼란에 빠지게 될 것이다. 신 기존 Flex 스크롤바 컴포넌트를 재사용하고

스키닝이나 스타일링을 사용해 모양을 커스터마이즈하자.

표준 컨트롤의 시각적 모양은 중요하지만 일관성에서 오는 장점을 위해 사용자들에게 이미

친근한 모양만을 사용할 필요는 없다. 하지만 컨트롤의 외양에 급격한 변화를 주게 되면

사용자들은 혼란스러워한다. 일반적으로 Flex 스타일링을 사용해 기본 Flex 모양(Aeon 이라

부른다)의 시각적 모양을 맞춘다. Aeon 은 매우 유연하고 눈에 띄는 모양과 느낌을 내는데

충분하다. 애플리케이션에 더욱 맞춤화된 모양이 필요하다면 스키닝 메커니즘을 사용하자. 스킨을

통해 원하는 모양으로 만들 수 있지만, 잘못 사용하면 사용자들이 알아볼 수 없게 된다. 컨트롤의

주요한 시각적 요소를 가지면서도 구별되게끔 해야 한다. 예를 들어 스크롤바는 위, 아래의

화살표와 트랙, 사이즈를 조절할 수 있는 썸을 가져야 한다. 언제나 그렇듯 요소가 시각적으로

충분히 구별되도록 하여 모든 사용자들이(시력이 안 좋은 사용자도) 사용할 수 있도록 해야한다.




Flex 디자인하기 – Part 6: 모션 활용하기

모션은 Adobe Flash 의 핵심 요소였다. 웹에서 객체를 움직이게 하는 능력은 기술의 핵심이며,

기본적으로 세일링 포인트의 하나이다. <Flex 디자인하기 – Part 1: Flex 개요 및 소개>에서

언급했듯 Flash 는 기본적으로 애니메이션을 사용해 교육이든 판매든 오락이든 간에 이야기를

전개했다. 하지만 Flash 플랫폼은 Flex 와 함께 애플리케이션 디자인으로 변형되었으며, 모션

기술이 가지는 소통으로서의 모든 파워를 덧붙이게 됐다.

불행히도 몇 가지 하이-프로파일(High-profile)의 실수 때문에 모션은 애플리케이션 디자인 및

개발에서 실망스러운 평가를 받게 됐다. ‘불행히도’라고 이야기 하는 이유는 모션을 제 로만

사용하면 애플리케이션을 보다 유용하게 원하는 로 사용할 수 있도록 만드는 강력한 툴이 될 수

있기 때문이다. 모션을 사용하면 사이트에 익숙하지 못한 사용자들이 항상 괴로워하는 화면에서

화면으로 넘어가는 현상을 제거할 수 있다. 하지만 모션을 적절히 사용하지 못하면 사용자가

원하는 것을 막아 불편과 괴로움을 줄 것이다.

본 글에서 다루는 내용은 다음과 같다.

• Flex 애플리케이션에서 모션을 디자인하는 것과 다른 매체에서 모션을 디자인하는 것의

차이

• 사용자의 본능적 이해를 극 화해 애플리케이션 사용을 강화하도록 모션을 사용하는 방법

• 사용자가 다음 단계로 흥미를 느끼게 안내하고 쉽게 다시 돌아올 수 있도록 하는데 있어

화면에서 화면으로의 전환을 사용하는 방법

• 피드백을 제공하고 사용자의 관심을 집중시키는데 모션 이펙트를 사용하는 방법

다른 매체에서의 모션

지난 세기 동안 많은 디자이너들은 특히 영화와 방송 매체에서, 그리고 최근에는 컴퓨터 게임에서

모션 디자인에 집중해왔다. 영화 업계의 감독과 촬영기사들은 모션의 속성과 정적 이미지상의

모션 영향에 대해 깊이 심사숙고해야 했다. 이 영화적 경험은 단순히 동작에 카메라를 맞추는

것보다 훨씬 복잡하다. 전통적 애니메이션 작가와 최근 CGI 기술자 모두는 더 높은 수준에서

모션 디자인을 생각해야 한다. 즉 자연스러운 매체로 모션을 만들어 자연스러운 동작을

재생성하거나 의도적으로 동작을 과장해 즐거움이나 온스크린 이펙트를 준다.


<그림 1> 애니메이션과 필름을 위한 모션 디자인은 예술적 형태를 가지는데 수년의 세월이 걸린다. Adobe

After Effects 와 같은 모션 디자인 도구는 일반인에게는 매우 강력하고 복잡하며 접근하기 힘들다.

다행스럽게도 부분의 Flex RIA 는 이 정도 높은 수준의 모션 디자인 전문성 없이도 사용할 수 있다.

다행히 애플리케이션은 예술 분야에서 요구하는 것만큼의 전문성이 필요하지 않다. 영화,

텔레비전 쇼, 게임은 모두 매우 사실적이면서 복잡한 방법으로 3D 객체가 서로 인터랙트할 수

있는 정교한 서사적 모션을 매끈하게 보여 준다. 반면 애플리케이션에서는 시각적 단순함이

우선이다. 사용자들이 정보나 갖고자 하는 목표에 도달하도록 안내하는 것이 주 목적이기

때문이다. 확장적이거나 필요 이상으로 정교한 모션 사용은 오히려 사용자들에게 방해가 된다.

그러므로 애플리케이션은 영화나 게임보다 더 간단한 모션을 요구하는 것뿐만 아니라 이

단순함이 이점으로 작용한다.

과거에 많은 웹사이트와 애플리케이션들이 모션에 지나치게 열중하여 불편함을 안겨줬다. 어쩌면

Flash 에서의 안좋은 기억의 예가 90 년 후반에 웹사이트에 등장한 ‘skip intro’ 영화였다.

사용자들이 웹사이트를 통해 원하는 컨텐츠나 작업에 바로 진입하는 것을 막아버렸기 때문이다.

비슷한 예로 데스크톱의 Microsoft Clippy 를 들 수 있다. 여러 이유로 사용자들에게 방해가

됐는데 그 중 하나가 화면 한 쪽에 머무르며 일하는 사용자의 집중을 방해한 것이다(주의:

애플리케이션을 디자인할 때 주의를 기울이지 않아도 잔잔한 빛이나 다른 침략적이지 않은

이펙트를 제외하고는 절 지속적으로 움직이는 애니메이션을 달지 말자. 다행히 이런 경향은

예전만큼 유행하지 않는 듯 하지만 늘 주의해야 한다).



이런 실수를 계속하지 않으려면 모션이 인간의 지각에 어떤 영향을 끼치는지를 고려해야 한다.

실생활에서 모션이 인간 행위에 어떤 영향을 끼치는지 연구해 본다면 Flex 애플리케이션에서

이펙트적인 모션을 디자인하는데 도움이 될 수 있다.

실제 세상와 애플리케이션

전통적인 컴퓨터 애플리케이션의 세상과는 달리 실제 세상에서 객체는 매우 다른 방식으로

작동한다. 객체가 움직일 때 객체 사이의 공간을 움직이는 것이다. 객체가 커질 때는 큰 사이즈,

새로운 것으로 확 바뀌기보다는 눈이 감지할 수 있게 확장된다. 눈에서 사라질 때는 사람의 시각

범위 밖으로 움직였거나 다른 객체에 의해 가려졌기 때문이다. 인간은 본능적으로 이런 실제적

객체의 작동을 이해하므로 객체가 갑자기 사라지거나 위치를 변경할 때 어떤 일이 벌어졌는지에

한 예상된 해석을 한다.

전통적인 웹 및 데스크톱 애플리케이션에서 객체는 이런 방식으로 작동하지 않는다. 그저 화면의

한 위치에서 다른 곳으로 옮겨질 뿐이다. 이들 객체는 순간적으로 커진다. 별다른 계기가 없이도

그냥 사라진다. 이런 세상에서 인간의 모든 본능적 지식은 패널 밖으로 사라진다(컴퓨터 초보자가

두 애플리케이션 사이에서 멀티테스크를 하고 있다고 가정하면 얼마나 고통스러울 지 알 것이다.

한 애플리케이션 패널이 다른 애플리케이션 위로 떠오를 때 많은 사용자들은 첫 애플리케이션을

무슨 이유인지 모르게 사라지게 만들었고, 하고 있던 모든 일을 날려버렸다고 믿게 된다).



<그림 2a> Adobe Dreamweaver 에서 패널이 움직일 때 한 위치에서 다른 위치로 옮겨진다. 이는 실제

생활에서 객체가 작동하는 것과는 매우 다른 방식이다.

<그림 2b> Dreamweaver 와는 다르게 Adobe Connect 에서는 패널이 움직일 때 공간 사이에서 이동하고,

새로운 크기로 바뀌기 보다는 자체 크기가 커진다. 훨씬 자연스럽다.

정기적으로 컴퓨터로 업무를 진행하는 사람들은 전형적인 애플리케이션으로 일할 때 다른 관념적

모델(mental mode)을 따르도록 자신을 훈련시켜왔기 때문에 이런 비정상적인 면에 피상적으로

익숙해져 왔다. 하지만 좀 더 깊은 레벨에서 보면, 컴퓨터가 작동하는 방식은 불편하다. 현재의

Macintosh 운영체계는 리치한 실제적 특징(옆으로 사라지는 것, 최소화 할 때 패널이 줄어드는

것, 열었을 때 문서 아이콘이 앞으로 튀어나오는 것 등)이 가장 매력적이다.

Macintosh 처럼 Flex 애플리케이션도 현실 세상에서 인간이 이해하는 모션으로부터 이점을

얻어야 하고 이런 지각력 있는 원칙을 패널, 컨텐츠, 컨트롤 및 다른 인터페이스 객체 등 모션

디자인에 적용시켜야 한다. 실제적 원칙의 사용을 통해 Flex 애플리케이션은, 모션으로 작업

흐름을 강화하고 컨텐츠를 통해 사용자를 안내하는데 도움을 줘야 한다.

모션을 사용해 애플리케이션으로 작업하는 사용자의 이해를 돕는 실제적 원칙을 적용하자.




<그림 3> Mac OS X 의 매력적인 부분은 모션의 리치한 실제적 특징이다. 이 데모에서 보면 dock 에 있는

Flex 애플리케이션의 모든 모션이 실제적 작동과 유사성을 갖지는 않는다. 예를 들어 크로스

실제 세상에서의 모션은 자연스럽게 인간의 관심을 유도하는 이펙트를 얻는다. 인간의 주변적

한 적이

최소화된 패널이 커지고 새 폴더 컨텐츠가 오른편에 나타나듯이 폴더 구조가 왼쪽으로 펼쳐지며 마지막으로

파일 아이콘이 바로 확장되고 파일이 열리면 바로 사라진다. 각 장면전환은 관련된 실생활의 모션을 모방해

사용자가 파일 시스템의 관념적 모델을 본능적으로 이해한 실제적 모델과 매핑하여 이해하는데 도움을 준다.

Play 를 클릭해 이 예를 살펴보자.

페이드(cross-fades)는 필요없어진 화면이나 패널의 상세사항을 제거할 때 아직도 적절하지만

실제 세상에서는 나타나지 않는다. 아직도 크로스 페이드는 많은 객체에 한 번에 적용될 때

슬라이드나 리사이즈 이펙트가 만드는 복잡한 이동 객체를 만들지 않고도 상세사항을 변경하여

사용자의 이해를 돕는다. 여기서도 모션은 애플리케이션을 살피며 어떤 일이 벌어졌는지를

사용자에게 이해시키는데 도움을 준다.

시각은 갑작스러운 모션을 잘 잡아내고 기본 본능은 갑작스러운 모션의 원인에 바로 집중한다.

이는 인간의 본능으로 호시탐탐 노리는 호랑이로부터 자신을 보호하려는 본능 때문이다.

(식당이나 바에서 화하는 사람 뒤의 텔레비전 프로를 보면서도 화에 집중하려고 노력

있는가? 그렇다면 벌써 이 원리에 해 이해하고 있다.) 이것이 Clippy 와 배너 광고가 눈에

거슬리고 방해가 되는 이유지만 반면 지금은 집중하지 않지만 언젠가 흥미로울 수 있는



모션을 사용해 사용자의 관심을 살짝 돌려보자.

전환과 이펙트

션 이해와 인간에 미치는 모션 이해를 통해 애플리케이션 디자인에서 모션을

1. 애플리케이션으로 작업하는 사용자의 이해를 돕고 실체적 객체에 한 사용자의 본능적

과에 이펙트적인 피드백을 제공하거나 사용자의 현재

Flex 는 모션 사용에 관한 두 가지 모두를 인식하는 기능을 제공하고 이를 각각 “전환”과

전통적으로 서술위주의 모션 디자인 환경은 경험의 출발에서 시작해 끝날 때까지 흐르는 시간을

전환은 전통적 애플리케이션에서 방해가 됐던 객체의 급작스러운 움직임을 Flex 애플리케이션

인터페이스의 부분에 잠시라도 사용자가 관심을 가질 수 있게 하는 좋은 방법이다. 모션은

사용자가 자신의 목적을 달성할 수 있는 다음 단계로 데려다주는데 도움이 될 수 있다.

실제 세상의 모

사용하는 두 가지 이유를 추론할 수 있다.

이해를 극 화해 만족도를 높이고,

2. 사용자의 관심에 집중하고 액션의 결

목표를 달성하는 다음 단계로 안내한다.

‘이펙트’라고 부른다.

주요한 정리 원칙으로 간주한다. 하지만 Flex 의 비선형 모델에서 모션은 주로 두 애플리케이션

사이에서 전환시에 일어난다.

에서는 피할 수 있게 해 준다. 객체가 움직일 때 공간 사이에서 부드럽게 움직인다. 크기를 바꿀

때 객체 자체가 커지거나 줄어든다. 제 로 디자인 된 Flex 애플리케이션에서는 실제적 특징의

은유가 잘 보존된다. 화면이 오른쪽으로 펼쳐져 다른 컨텐츠나 기능을 보여준다면 왼쪽으로

펼쳐질 때는 옛 컨텐츠를 다시 보여준다. 서랍(drawer)이 닫히면 이를 끄집어낼 때 다시 열린다.


<그림 4> 위의 가상의 사진 브라우저 애플리케이션은 액션에서 전환을 데모해준다. 검색상자를 가진 패널은

매끄럽게 검색 결과를 펼쳐 보여준다. 이 모션은 두 애플리케이션 사이에서 사용자가 가지는 패널의 정체를

강화한다. Play 를 클릭해 예를 살펴보자.

잘 디자인된 전환은 사용자가 어디에 있는지 어디에 있었는지 어떻게 뒤로 돌아가는지를 완벽히

알 수 있게 한다. 또한 사용자가 애플리케이션의 상태에 어떤 변화가 있었는지와 이를 어떻게

되돌릴 수 있는지도 알게 해 준다. 사용자는 실제 세상에서 본능적으로 이해하기 때문에 이

메커니즘에 해 추가로 공부할 필요 없다.

전환을 사용해 사용자가 어디에 있는지, 어디에 있었는지, 어떻게 돌아가는지를 알 수

있도록 하자.

또한 이펙트는 실제 모션에 한 본능적 지식을 사용해 사용자의 이해를 강화하지만 개별 객체에

보다 지엽적이다. 이펙트는 애플리케이션 이동 경로를 통해 사용자를 안내하는 것이 아니라

사용자의 관심을 현재 작업의 다음 단계로 이동시키고 사용자 액션에 따른 응답의 리치 피드백을

제공한다. 예를 들어 사용자가 인터랙트할 수 있다고 하는 컨텐츠에 마우스를 올릴 때 반짝이는

글로 이펙트를 사용하거나 선택할 때 이미지를 키워 더 눈에 띄게 만들 것이다.



<그림 5> 가상 사진 브라우저에서 hover 작동은 액션에 이펙트를 보여준다 – 사용자가 각 사진 위에

마우스를 가져다 면 사진과 인터랙트를 하는 것처럼 부드럽게 선택한 것을 나타낸다. 이펙트는 각 객체의

수준에서 피드백을 제공하는데 뛰어나다. Play 를 클릭해 예를 살펴보자.

이펙트와 전환을 사용할 때 모션을 거짓으로 또는 불필요한 방법으로 사용하지 말자. 사용하는

모션이 앞에서 언급한 목적 중 하나로 사용된 것이 아니라면 애플리케이션에 포함시켜야 하는지

여부 자체를 곰곰히 생각해보자. 모션에 매혹되어 적절히 사용하지 못하게 되기 쉽다. 예를 들어

Gnome Luminosity 프로젝트의 “Wobbly Windows” 이펙트 데모를 보자. 사용자가

애플리케이션을 이해하는데 전혀 도움이 되지 않고 사용 경험에 방해만 될 뿐이다. 이런 불필요한

이펙트는 데모를 멋져 보이게 하지만 실제 애플리케이션에서는 피해야 한다.

거짓된 또는 불필요한 모션을 피하자.

전환 – 가르쳐주는 모션

이펙트적인 전환을 디자인하는 것은 까다롭다. 본 섹션에서는 이를 위한 몇 가지 원칙과 조언을

제공하겠다.

90 년 중반, 컴퓨터 내부에 실제 공간을 전체적으로 변하는 것에 기반한 몇 가지

인터페이스가 등장했는데 이 중 Microsoft Bob 이 가장 잘 알려진 예이다. 이들 인터페이스는

과도하게 꾸며진 정보 디자인이자 인터랙션 패턴으로 컴퓨터 입력 디바이스를 잘 해석하지



못했다. 모두 실패했다. 애플리케이션 모션 디자인에 실제 원칙을 적용하는 것이 실제를

맹목적으로 복사한다는 뜻은 아니다. 신 디바이스의 목적과 기능에 맞게 인터랙션에 이들

원칙을 통합해 보자.

<그림 6> 온라인 ‘북’은 UI 기술로 만든 멋진 실험이지만 체로 은유를 직접적으로 받아들인다. 사용자들은

페이지를 넘기기 위해 화면 반에서부터 페이지를 끌어와야 하는데 마우스로 하기엔 어려운 작업이다. 여기에

실제 책에서 보여주는 적절한 정보가 화면에서는 적절하지 않을 수 있다 – 컴퓨팅 기술을 사용해 정보

디자인을 해야지 다른 매체에 다른 속성으로 사용해 디자인을 복사하려고 하면 안된다. Play 를 클릭해 이

예를 살펴보자.

컴퓨터 내에서 ‘버추얼 세상’를 만들려고 하는 신 실제 객체의 모션 속성을 사용해 Flex

인터페이스 요소가 어떻게 움직여야 하는지를 결정하자. 각 상태에서 온스크린 객체가 어디에

있는지 확인하고 단계별로 어떻게 흐르는지 확인하자. 앞에서 설명한 실제적 특징의 속성을

기억하자. 실제적 객체는 이동하거나 크기를 바꿀 때 공간 사이를 움직인다. 옛 위치에서 새

위치로 매끄럽게 움직이거나 크기를 바꿔 사용자 마음의 객체를 보존하자. 객체가 화면 밖으로

이동하거나 없어질 때 사용자가 갔던 공간을 찾아 객체를 다시 찾아올 수 있게 하자.

실제 객체의 모션 속성을 사용해 Flex 인터페이스 요소가 어떻게 움직여야 하는지 결정하자.



<그림 7a> 위 그림에서 가상의 보험 청구는 모션을 이펙트적으로 사용해 실제 공간을 통해 찾는 환영을

만든다. 사용자가 한 페이지에서 다음 페이지로 이동함에 따라 옛 페이지는 새 슬라이드가 들어오는 사이에

사라지게 된다. Play 를 클릭해 예를 살펴보자.

<그림 7b> 보험 폼의 모션 전환을 통해 사용자는 폼이 어떻게 정리돼 있는지 시스템의 모델을 이해하는데

도움이 된다. 사용자가 마법사를 통해 처리하는 것처럼 페이지가 왼쪽에서 오른쪽으로 이동하기 때문에 다른

폼 페이지 옆에 현재 보이는 페이지의 관념적 모델을 만들고 다음 페이지로 이동하여 목록에서 다음

페이지만을 보이게끔 한다.

하지만 이해의 목적을 위해 실제적 특징의 규칙을 어겨야 하는 경우도 있다. 많은 화면 요소는

시각적으로 복잡하다 – 패널은 많은 컨트롤을 가지고 있고 다이어그램은 많은 모양과 색깔을



가지며 목록은 다양하고 복잡한 컨텐츠를 가진다. 그 결과 이들 요소를 움직이거나 크기를

조정하는 것 자체는 시각적으로 불편하거나 혼란스러워진다. 한 번에 너무 많은 것을 보여주기

때문이다(기술적 측면에서도 성능에 악영향을 끼치지 않으면서 이를 달성하는 것이 어렵다).

수정하려면 전환할 때 객체 자체의 공간에 애니메이션 프록시를 사용하면 된다. Adobe

Connect 를 예로 들어보자. 사용자가 레이아웃을 바꿀 때 패널을 재배열하기 전에 패널의

컨텐츠를 없애자. 이렇게 하면 전환시 객체를 잠시나마 단순화할 수 있다해도 같은 객체로 인식할

수 있는 시각적 특징을 충분히 갖고 있다. 그렇지 않다면 잘못된 메시지를 사용자에게 보낼 수

있는 위험이 생긴다. 실제적 특징은 늘 이해를 도와야 한다. 실제적 특징으로 인터페이스를

이해하게 되면 이해도는 성공이다.

시각적으로 복잡한 객체에는 애니메이션에 프록시를 사용하자.

<그림 8> Adobe Acrobat Connect 가 포드(pods)를 움직일 때 프록시를 사용한다. 포드가 이동하거나

크기를 조절하기 전에 각 포드의 컨텐츠가 어떻게 없어지는지, 그리고 새 크기로 다시 돌아오는지 살펴보자.

Play 를 클릭해 예를 살펴 보자.

실제 은유를 사용할 때 어떤 전환 상태는 짧은 시간동안 많은 객체의 이동을 가져온다. 동시에

발생하는 모든 이 모션은 사용자를 흥분시켜 급작스러운 화면 변화보다 더 나쁜 결과를 초래할

수 있다. 이를 피하려면 상태 전환에서 동작의 연결을 가능한 한 약간만 오버랩되게 하면 된다.

시퀀스의 각 섹션은 하나의 개념만을 보여줘야 한다. 예를 들어 사용자가 목록에서 몇 가지



아이템을 삭제한다면 아이템을 먼저 페이드아웃 시키고 남아있는 아이템을 원래 공간에

어넣는다. 화면 전환이 레이아웃의 몇 가지 패널을 재정비하고 새 패널을 소개하는 것과 관련이

있다면 기존 패널을 먼저 움직이고 새 패널을 페이드인 시킨다.

전환 상태의 동작의 연결을 가능한 약간만 오버랩되게 한다.

<그림 9> Adobe Media Player 은 사용자 인터페이스를 통해 연속된 전환을 사용한다. 왼쪽 패널 컨텐츠가

페이드아웃되고 비디오가 움직이고 마지막으로 오른쪽 패널 컨텐츠가 페이드인 되는 것을 확인하자. 각

모션은 살며시 오버랩되지만 전체 전환은 이해하기 쉽게 연결된다. Play 를 클릭해 예를 살펴보자.

전환 상태를 연결해 어떻게 작업을 끝낼 수 있는지 사용자에게 이해시키는데 도움을 줄 수 있다.

예를 들어 사용자가 패널 셋에 정보를 넣고자 한다면 같은 시퀀스의 레이아웃에 이를 소개해

순서를 강화할 수 있다.

이펙트 – 강조하는 모션

움직이는 이펙트는 사용자의 관심을 특별히 중요한 객체로 유도할 수 있다. 본 절에서는 이펙트를

사용하는 몇 가지 일반적인 방법을 설명한다.

이펙트의 가장 직접적인 사용은 한시적으로 중요한 아이템을 강조하는 것이다. 기본 버튼이나

다른 컨트롤이 작업의 다음 단계를 표시하기 위해 반짝거려 사용자의 관심을 갖도록 하자.

사용자의 액션에 따라 나타나고 사라지고 변경하는 컨텐츠 조각은 이펙트를 사용하여 변화를



나타내야 한다. 예를 들어 인스턴스 메시지 애플리케이션은 IM 목록의 사람이 로그인하거나

로그아웃하거나 메시지를 보냈을 때 약간의 이펙트를 사용할 수 있다.

이펙트를 사용해 이펙트없이는 알아 채지 못하는 영구적 또는 한시적으로 중요한 특이한

아이템을 강조하자.

<그림 10> Converse 의 신발 보여주기 이펙트를 사용해 사용자의 다음 액션이 무엇이어야 하는지 알려준다.

사용자가 원하는 신발 색깔을 모두 선택하면 아코디언 컨트롤의 다음 바가 반짝여 작업에서 다음 단계로

가도록 클릭해야함을 나타낸다. Play 를 클릭해 예를 보자.

다수의 다른 이펙트 사용은 이것처럼 특별한 경우다. 예를 들어 인터페이스의 몇 가지 요소는

비디오 스트림을 로딩하는 것처럼 비동기적 운영의 진척을 표현해야 한다. 이 운영은 움직이는

이펙트를 통해 여전히 진행 중인 것을 나타낸다. 도는 바퀴나 진행바같은 이펙트는 컨텐츠를 꾸

수도 있고 컨텐츠 자체일 수도 있다. 진행바와 비디오 시간바를 합쳐 놓은 것은 이같은 예다. 더

많은 정보가 다운로드 되듯 고차원 버전으로 로드를 진행하는 웹의 뒤섞인 이미지의 작동은 또

다른 것이다.



<그림 11> 위의 Adobe Media Player 같은 많은 비디오 플레이어는 플레이 바 배경을 옅은 색으로

채워감으로써 비디오 로드의 진행을 표현한다. 이를 통해 사용자들은 비디오의 로드할 양이 얼마나

남았는지와 기다리지 않은 상태로 얼마나 볼 수 있는지를 이해할 수 있다.

<Flex 디자인하기 – Part 5: 컨텐츠 디스플레이 디자인하기>에서 하지 말라고 했던 강요하는

화상자를 신하는 transient notifier 는 일반적으로 나타나고 사라질 때 약한 페이드 이펙트를

사용한다. Transient notifier 는 사용자에게 약간의 정보를 제공하거나 강조한 후 시간이 지나면

페이드아웃된다. 이 정보는 새 이메일이나 새 인스턴트 메시지가 왔을 때처럼 몇 가지 배경

활동의 결과를 사용자에게 알려준다. 또한 사용자가 실행한 몇 가지 연산 결과의 형식없는

피드백을 제공한다.

transient notifier 를 사용해 일시적으로 중요한 정보를 약간만 슬쩍 보여주자.

현재 작업에서 사용자의 관심을 돌리는 system-triggered notifiers 는 조심스럽게 디자인되어야

하고 함부로 적용돼서는 안된다. 사용자가 system-triggered notifier 가 제공하는 정보가 흥미롭고

관련있다고 생각되면 유용하면서 강요하지 않는다고 느낄 것이다. 하지만 정보가 흥미롭지

못하거나 너무 자주 나타나면 notifier 는 바로 귀찮아진다. 사용자가 원한다고 확신하는

컨텐츠에만 이펙트를 사용하자. Windows 의 bubble notifier 는 이론상 좋은 아이디어였지만

사용자에게 관련없는 정보를 제공해 프로그램에서 이를 과용한다고 느껴졌을 때(Microsoft 가



제공한 “데스크톱 아이콘을 없애길 원합니까?” 같은 메시지)는 편리하다기보다는 귀찮게

느껴졌다. System-triggered notifiers 는 지방과 기름 같다-가능한 사용을 아끼자.

system-triggered notifiers 는 가능한 조금 사용하자.

<그림 12a> 인스턴트 메시지가 들어왔을 때 사용자에게 알려주려면 iChat 은 systme-triggerd notifier

사용의 좋은 예가 된다. 다수의 iChat 사용자들이 메시지가 왔을 때 알기를 원하므로 화면 좌측 상단의

움직이는 버블은 방해가 되지 않는다. 또한 사용자가 다른 작업을 하느라 바쁠 때는 쉽게 무시할 수 있을

정도로 작다. Play 를 클릭해 예를 살펴보자.

<그림 12b> Flash Player 는 Windows bubble notifier 를 사용해 새 업데이트가 있을 때 사용자에게 알려준다.

잘 의도됐다 하더라도 너무 자주 등장하기 때문에 많은 사용자들이 귀찮다고 느낀다. 인스턴트 메시지를




받는 것과는 달리 소프트웨어 애플리케이션을 업데이트 하는 것은 사용자의 목표와 관련있는 것이 아니므로

system-triggered notification 과 함께 사용할 때는 조심해야 한다.

더 자세한 내용을 배우려면 Part 7: 빠른 애플리케이션 만들기를 계속 읽기를 권한다.



Flex 디자인하기, Part 7: 빠른 애플리케이션 만들기

이 글이 Flex의 성능 튜닝에 한 기술적 방법을 자세히 소개하는 것이라 기 했다면 유감이다.

물론 네트워크화 된 Flex 애플리케이션 응답을 향상시키는 몇 가지 디자인 기술을 언급하겠지만

이 글은 기본적으로 Flex의 효율적인 사용과 사용자에게 보다 빠르고 생산적인 경험을 안겨주는

것에 초점을 맞추고 있다.

사용자의 생산성을 감소시키는데 일조하는 애플리케이션이 있다. 그 중 하나는 애플리케이션

자체가 둔할 때다. 디스크가 돌아가고 알고리즘이 돌아가고 네트워크 연결이 너무 오래 걸린다면

사용자의 집중도가 떨어져서 목표 달성이 어렵다. 하지만 사용자가 이전에 제공한 정보를 다시

입력하거나 애플리케이션이 이미 해결한 데이터를 제공할 때 사용자는 애플리케이션 성능을 또한

의심한다. 상황에 따라 일단 한 번 작동한 애플리케이션이 다음 작업을 수행할 때 시간이 줄어

든다면 애플리케이션 로드에 걸리는 시간이 약간 길어지는 건 참을 수 있다. 애플리케이션을 더

빠르게 만들고자 한다면 먼저 어떻게 하면 사용자의 속도를 높일 것인가를 고려해야 하고

시스템의 생산성에 방해가 된다면 시스템의 속도를 높여야 한다. (예를 들어 사용자의 기호를

연구하는 내 친구가 Flex 애플리케이션 사용자들을 인터뷰한 적이 있다. 성능의 어떤 문제가 가장

힘들게 하는가를 질문하면서 느린 작동과 계속 돌아가는 수은시계 모양의 커셔를 답변으로

예상했다. 하지만 놀랍게도 다수의 사용자들이 시스템 성능에 불만을 품기 보다는 일상적인

작업을 완료하는데 너무나 많은 단계가 있다는데 불만을 품었다!)

본 글에서 다루는 부분은 다음과 같다.

• 일반적인 사용자 업무에서 불필요한 단계를 제거하는 방법.

• 반복적 업무를 자동화하고 정보를 기억하게 하는 방법.

• 좋은 애플리케이션 시작점을 제공해 사용자에게 유리한 시작을 주는 방법.

• 사용자에게 큰 차별점을 주는데 주력해 애플리케이션의 응답을 향상시키는 방법.

작업 제거하기

컴퓨터는 두 가지 면에서 탁월하다. 하나는 기억을 하는 것이고 다른 하나는 계산을 수행하는

것이다. 또는 다른 컴퓨터와 연결됐을 때, 다른 컴퓨터들이 아는 것이 무엇인지 잘 찾게 된다.

다수의 인간은 이들 세 가지 작업을 잘 하지 못한다. 유용한 애플리케이션은 컴퓨터가 잘 하는

것, 즉 사용자를 위해 작업을 제거하는(eliminating) 일을 하게끔 한다.


컴퓨터의 완벽한 메모리와 강력한 프로세싱 능력을 사용해 사용자의 작업을 제거하자.

작업을 제거하는 데는 세 가지 기본적인 방법이 있다. 사용자가 행하는 일반적인 작업 중

불필요한 단계를 잘라내는 것, 단계를 자동화해서 시스템이 알아서 처리하게끔 하는 것, 사용자가

원하는 컨텍스트를 기반으로 애플리케이션의 지능적 시작점을 추론하는 것이 그것이다.

작업 단축하기

작업을 제거하는 가장 쉬운 방법 중 하나는 애플리케이션에서 사용자가 행하는 작업을 꼼꼼하게

살펴 필요없는 단계를 가차없이 잘라내는 것이다. 하지만 이 방법이 너무 쉽다면 왜 요즘

소프트웨어의 작업 흐름이 전반적으로 길겠는가? 여기에는 다양한 이유가 있다. 먼저 시스템

디자이너나 개발자들이 자신의 애플리케이션에서 사용자들이 무엇을 하는지 일반적인 작업흐름이

무엇인지 제 로 이해하지 못해서다. Part 2: 애플리케이션 계획하기에서설명한 것처럼 주요

사용자 업무를 제 로 파악하고 그에 맞게 애플리케이션 디자인을 최적화했다면 이미 문제를

해결하고도 남았다. 디자인 하기 전과 애플리케이션을 출시한 후에도 사용자의 작업을 제 로

이해하는 것이 Flex 애플리케이션을 디자인할 때 어디에 집중해야 하는지 알 수 있는 가장 좋은

방법이다. (애플리케이션이 발전할수록 어떻게 교육받았든 추측에 의존하는 신 제 로 된

사용자 연구를 진행하는 것이 더 중요하다. 몇 명의 사용자들과 사담을 나누며 의견을 물었다면

다수의 고객이 원하는 것이 아닌 일부 고객의 작업흐름에 맞춰 애플리케이션을 디자인하게

되는 위험요소를 갖게 된다.)

사용자의 실제 작업을 파악해 보다 효율적인 흐름을 만드는 방법이 어떤 것인지 더 잘

이해하자.

<그림 1> Part 2에서 가져온 가상의 지불시스템 그림은 프로세스에서 필요없는 단계를 제거하는 작업흐름의

재디자인이 얼마나 사용자의 효율성을 향상시키는지 보여준다.

가끔은 단순한 부주의 때문이 아니라도 작업이 의도적으로 너무나 복잡할 때도 있다. 이 중 가장

용서할 수 없는 것이 일반적인 작동 보고 외에는 아무런 의미도 없이 확인 화상자 혹은



팝업같은 시스템 디자이너가 만든 단계 삽입이다. (“네트워크가 다시 연결됐습니다. 원하십니까?”)

아주 다급하거나 사용자의 즉각적인 주의를 요하는 것이 아니라면 사용자 업무에 아무런 영향도

줄 수 없는 정보나 질문으로 사용자를 절 괴롭히지 말자. 이런 일들은 애플리케이션 디자이너와

개발자들이 믿는 것보다 훨씬 많이 일어난다.

<그림 2> Adobe 의 CS3 업데이트는 필요없는 화상자를 많이 뜨게 하는 표적인 예다. 많은 사용자들이

Adobe Photoshop, Adobe Illustrator, Adobe Dreamweaver 등을 업데이트하고자 하지만 업데이트 자체를

위해 업데이트할까요를 물어 사용자를 괴롭힌다면?! 생각해 볼일이다.

또 다른 문제는 기술적인 것이 아니라 조직적인 플로우에 있다. 비즈니스나 마케팅적 이유로

애플리케이션이 사용자에게 필요없는 많은 정보를 요구할 때가 있다. 그 데이터가 얼마나

중요한지 모르겠지만 사용자에게 불쾌한 경험을 줄 만큼 가치있진 않다. Part 3: 애플리케이션

구성하기에서 언급했듯 데이터가 정말 중요하다면 이를 선택사항으로 놓고 사용자가 이러한

데이터를 제공했을 때 인센티브를 주자. (일전에 형 웹 사이트의 디자인팀이 사용자 등록

프로세스시 포기율을 감소시키는 방법을 찾으려는 시도를 했었다. 그리고 사용자의 모든 것을

알고자 하는 길고 자세한 등록 폼이 가장 큰 문제였음을 발견했다. 마케팅팀에 연락해 어떤 것을

잘라낼 지 알아보면서 그 누구도 이 긴 정보를 사용하지 않고 있음을 발견하고 경악했다.

사용자의 시간을 낭비하면서 웹 사이트의 비즈니스에 하등 도움이 안 됐던 것이다.)

사용자의 업무에 전혀 도움이 안되는 정보나 질문으로 사용자를 괴롭히지 말자.



<그림 3> Adobe.com 의 등록 폼은 필수 필드와 선택 필드를 명확하게 보여줌으로써 등록 프로세스를

간단화한다. 이후 더 많은 필드를 선택으로(Adobe 는 진정 내가 사는 도시와 나라를 알아야 하는가?)

만들고 이를 필수 정보 다음에 다른 섹션으로 나눠 더 나은 폼을 만들 수 있다.

작업 자동화하기

사용자의 관심을 끌기 위해 요구를 만들어내는 신 컴퓨터의 완벽한 메모리와 계산력을

만드는데 집중해 이런 요구를 완화시키는 것이 좋다. 사용자들은 컴퓨터를 사용하는 동안 많은

정보를 제공하나 많은 애플리케이션들은 이를 다 잊어버린다. 사용자가 Flex 애플리케이션에

주소를 입력하면 애플리케이션은 이를 다시 물어서는 안된다. 사용자가 지난 3 일 동안 한 문서를

작성했다면 이를 열고자 할 때마다 파일 시스템을 통해 열게 해서는 안된다. 애플리케이션은 이를

기억하고 최신 문서에서 이를 쉽게 열 수 있는 방법을 제공해야 한다.

사용자가 이미 제공한 정보를 다시 입력하게 하면 절 안된다.



<그림 4a> Amazon.com 은 배달지 주소와 지불 정보를 기억하므로 사용자는 새로 구매를 할 때마다 이를

다시 입력할 필요가 없다. 이는 웹 상의 애플리케이션 메모리가 제 로 작동하는 것을 보여주는 가장

일반적인 예다.



<그림 4b> Adobe Fireworks CS3 는 웰컴 화면에서 최근 연 문서들의 목록을 보여줌으로써 사용자가 최근에

작업했던 문서를 쉽게 열 수 있도록 해준다. 이는 데스크톱 소프트웨어에서 애플리케이션 메모리의 일반적인

예다.



<그림 4c> 다른 Adobe 애플리케이션과 마찬가지로 Adobe Dreamweaver 도 사용자가 기본 작업공간

레이아웃을 변형한 것을 기억하고(창 열기 및 이동하기 등) 애플리케이션이 닫혔다 다시 열려도 자동적으로

남아있게끔 한다. Dreamweaver 의 애플리케이션 메모리는 정교하고 광범위하여 사용자가 애플리케이션을

구성하는데 시간을 덜 쏟고 자신의 웹 페이지를 작업하는데 더 많은 시간을 할애하게끔 한다.

Flex 애플리케이션은 거의 언제나 인터넷과 연결돼 사용자의 작업을 제거할 수 있는 완전히

새로운 기회를 제공한다. 전통적인 데스크톱 애플리케이션과는 달리 사용자 스스로 제공한 정보를

기억하는데 제한이 없을 뿐더러 다른 인터넷 서비스에 접촉하여 사용자 신 정보를 찾아올 수

있다. 주소와 책 제목을 사용해 우편번호나 ISBN 처럼 기억하기 어려운 숫자 정보를 웹

서비스에서 찾아올 수 있으므로 사용자는 더 이상 ID 숫자 때문에 괴로울 필요가 없다. 사용자가

선명하게 사진을 현상하고 싶다면 애플리케이션 스스로 가장 저렴한 가격에 가장 가까운

사진관을 결정할 수 있다.

<그림 5> Firefox 의 인터넷 검색바는 사용자가 이전에 검색한 것을 기억할 뿐 아니라(선 위의 검색어들)

다른 이들이 Google 에서 사용했던 일반적인 검색어들도 보여주는 자동 완성 기능을 가지고 있다. 이

기능은 사용자가 처음 검색을 하더라도 더 신속하고 정확하게 검색어를 입력할 수 있도록 도와준다.

마지막으로 많은 애플리케이션은 사용자의 편이를 위해 더 유연한 입력 포맷을 받아들이고 다른

계산 작업을 수행함으로써 작업을 제거할 수 있다. 일반적인 예는 입력 폼 필드로 너무나 많은

애플리케이션이 특정 입력 타입만을 받아들인다. 시스템이 예측했던 정확한 포맷의 주소가



아니라면 오류가 날 것이다. 사용자가 전화번호를 입력할 때 지역번호에 ()로 나누는 신 –를

사용하면 바로 오류가 난다.

좋은 Flex 애플리케이션은 사용자 입력에 유연하다. 사용자가 전화번호를 입력할 때 여러가지

다른 방법으로 입력하더라도 애플리케이션은 이를 충분히 받아들일 수 있어야 한다. 물론

사용자가 전화번호 신에 ‘asdf’를 입력하면 애플리케이션이 받아들이기 힘들겠지만 얼마나 많은

사용자가 이런 짓을 하겠는가? ‘(415)555-1234’ 신 ‘415.555.1234’라고 입력하는 것보다 훨씬

적을 것이다. (주석: 많은 Google 애플리케이션은 이런 방식에 매우 유연하며 이것이 그들의 성공

원인 중 하나다. Google Maps 에서 위치를 검색할 때 위치를 나타내는 어떤 타당한 열이라도

입력하면 바로 정확한 지도를 보여준다.)

애플리케이션이 받아들이는 입력 포맷을 유연하게 만들자.

<그림 6> 물론 도로명을 기재하는 것이 우선시돼야 하지만 Google Maps 은 위치 검색창에 입력되는 것을

받아들이는데 매우 유연하다. Google Maps 에 ‘hotels in sf’라고만 쳐도 샌프란시스코에 있는 호텔 목록을

보여주며 호텔의 위치를 지도에서 보여준다. 애플리케이션은 이 입력에 한 다른 포맷도 받아들일 만큼

똑똑하기 때문에 ‘hotels near sf’나 ‘sf hotels’ 또한 같은 결과를 얻을 수 있다.




사용자의 속도를 높이기 위해 작업을 자동화하는데 가장 일반적인 반 의견은 애플리케이션이

항상 옳을 수 없다는 것이다. 항상 옳은지 걱정하지 말자. 사용자는 애플리케이션이 추측해야 할

때 이를 명확히 알려 사용자가 실수를 고칠 수 있도록 해 준다. 옳은지 여부에 해 걱정하는

신 시스템이 ‘적절한’ 시작점을 제공해 사용자 시간을 절약해줘야 하는지 시스템 자체가 직접

작업을 수행하는 신 시스템을 추측하는데 사용자가 시간을 더 들여야 하는지 고려해보자.

확실치 않을 때에도 자동화가 얼마나 많은 시간을 절약해주는지 알면 놀랄 것이다.

사용자의 시간을 절약할 수 있다면 작업을 자동화하자. 하지만 항상 시스템의 잘못을

입증하고 고칠 수 있도록 하자.

시작점 제공하기

작업 제거의 일반적인 경우는 지능적인 시작점(starting points)을 제공하는데 있다. 과거에는

사용자가 처음 애플리케이션을 열었을 때 무엇을 할 지 다수의 애플리케이션은 추측을 하지

못했다. 첫 작업과 그에 따르는 작업들에 해 깜깜했으므로 사용자는 자주 사용하는

애플리케이션 섹션도 반복적으로 네비게이트해야 했다. 좋은 Flex 애플리케이션은 이보다

똑똑해야 하고 사용자가 무엇을 하고자 하는지에서부터 시작해야 한다. (이는 가끔 “개인화”라고

불리기도 하는데 개인적으로 이 단어를 좋아하지 않는다. 이 단어는 마치 마지막으로 사용했던

것도 완벽하게 잊어버리는 애플리케이션을 친근하게 느껴지도록 개인 컴퓨터 상단의 “Rob님,

환영합니다”라는 메시지를 띄우는 것을 말하는 것처럼 들리기 때문이다.)

두 번째 사용 시작점은 처음 것보다 더 쉽게 디자인 및 구현된다. 가장 일반적인 접근은 “마지막

상태” 전략을 따르는 것이다. 사용자가 애플리케이션으로 다시 돌아온다면 떠나기 바로 전의

상태에서 시작해야 한다. 여기에는 몇 가지 장점이 있다. 먼저 사용자가 마지막으로 작업했던

많은 도메인은 사용자가 돌아왔을 때도 작업하고자 하는 부분일 확률이 높다. 두 번째로 실체적

객체의 행위를 따라 하는데 다른 누군가가 수정하지 않는 한 떠나기 전 상태로 남아있게 되는

것이다. Part 6: 모션 활용하기에서 언급했듯 실체적 객체를 따라 하는 것은 사용자가 직관적으로

인터페이스를 이해하는데 도움이 되므로 마지막 상태는 사용자에게도 납득이 된다.


<그림 7> iGoogle 은 Google 의 커스터마이즈된 홈페이지로 마지막 상태의 전략을 따른다. 사용자가

iGoogle 로 돌아올 때마다 사용자가 떠나기 바로 전의 상태와 똑같다. 같은 위치의 같은 위젯과 구성이다.

이 행위는 사용자에게 매우 수월하게 느껴진다. 그래서 다수의 사용자는 애플리케이션이 화면 뒤에서

사용자의 작동을 기억하는 작업을 하는지 조차 못 느낀다.

안타깝게도 마지막 상태의 전략은 언제나 들어맞진 않는다. 온라인 상점에서 이미 제품을

구매했다면 다음 번에 구매한 제품 페이지로 돌아가고 싶지 않을 것이다(주문내역으로 돌아와

고치거나 배송날짜를 확인하고자 할 수는 있더라도). 또한 사용자가 애플리케이션을 전혀

사용해보지 않았다면 정보가 남아있지 않기 때문에 첫 시작점에서는 제 로 작동이 되지 않는다.

그럼에도 첫인상이 강렬히 남기 때문에 사용자가 원하는 부분을 찾기 위해 수많은 네비게이션을

하도록 놔두고 싶지 않을 것이다. 그렇다면 무엇을 할 수 있을 것인가?

이전 행위에 의지하는 신 새로운 사용자가 도착했을 때 컨텍스트를 검사하고 이 컨텍스트에서

추론할 수 있는 것이 무엇인지 알아봐야 한다. 예를 들어 좋은 캘린더 기능의 애플리케이션은

사용자를 1970 년 1 월 1 일에 노출시키지 않는다. 시스템 시계를 봄으로써 쉽게 결정할 수 있는

‘오늘’부터 시작한다. 좋은 지도 애플리케이션은 거 한 미국 전도에서부터 시작하지 않는다.

체로 사용자가 보고자 하는 위치인 사용자가 살고 있는 도시를 기점으로 표시한다. (물론 너무

개인적일 가능성이 높다. 다수의 지도 애플리케이션은 사용자의 집을 표시해서는 안된다.



자신이 사는 곳 주변은 이미 잘 알고 있기 때문이다.) 좋은 온라인 상점은 사용자가 검색

엔진에서 들어왔을 때를 검색어를 사용해 관련 제품을 바로 보여준다.

사용자가 애플리케이션을 떠날 때 상태를 기억하거나 사용자의 컨텍스트에서 적절한

시작점을 추론함으로써 사용자에게 현명한 시작점을 제공하자.

<그림 8> Google 은 사용자의 IP 가 나타내는 국가를 기반으로 사용자의 언어를 추론한다. 그러므로 일본인

사용자가 Google 에 접속하면 일본어 버전을 즉각 받기 때문에 영어 웹 사이트를 보고 어떻게 일본어

사이트로 바꿔야 할 지 고민할 필요도 없다.

불행히도 현재의 웹 환경은 새 사용자가 기존 계정 없이 접근하면 컨텍스트를 분석하기 힘들다.

이는 이후 해결해야 할 문제지만 가지고 있는 컨텍스트를 사용자의 시작점에 맞춰 사용자의

목표에 맞춰야 한다.

응답 향상시키기

어떤 애플리케이션은 잘 구조화됐음에도(작업 제거에 신경을 쏟고 사용자의 목표나 업무를

기반으로 최고의 시작점을 제공하는) 그저 애플리케이션이 너무 느리다는 전통적인 의미의

효율성에 신경쓰지 못하는 우를 범한다. 인터넷은 악명높게도 불안정한 짐승이기 때문에

네트워크에 많이 연결된 Flex 애플리케이션은 이런 함정에 쉽게 빠질 수 있다. 본 절에서는



사용자가 성능을 지각하는 것이 애플리케이션을 사용하는 그들의 경험에 어떤 영향을 주며 이를

토 로 어떤 부분의 디자인 및 개발에 노력을 더 기울여야 하는지에 중점을 둔다.

애플리케이션 성능을 튜닝할 때 사용자가 기 하는 속도가 무엇인지와 실제 속도가 어떤

기능에서 가장 상충하는지에 중점을 두자. 사용자 기 의 컨텍스트에서 떨어져 나온다면 완벽한

성능 메트릭스는 아무런 의미가 없다. O(n2) 알고리즘이나 10 초 응답시간은 애플리케이션

사용자가 연산에 기 하는 시간에 따라 아무 문제가 없을 수도, 너무 느리다고 느낄 수도 있다.

기 하는 성능 레벨과는 완전히 다른 연산에는 세 가지 종류가 있다. 실체적 변화, 화면 로드,

거 업무가 그것이다.

실체적 변화(physical changes)는 사용자에게 인터페이스 객체의 조작으로만 나타나는 연산이다.

이는 잠깐 사용하는 사용자에게 나타날 수 있다. 예로는 하나의 목록에서 다른 목록으로 사진을

드래그 앤 드롭하는 것과 버튼 위에 마우스를 댈 때 피드백이 뜨는 것이 있다. 실체적 변화는

브라우저 기반의 애플리케이션에서 AJAX 나 Flex 를 사용할 때 한 상태에서 다음 상태로

넘어가는데 브라우저 페이지를 새로 고치게 하고 싶지 않을 때 가장 적합하다.

<그림 9a> 사용자가 버튼을 누를 때 버튼이 솟아있다가 낮아지는 것처럼 상태에서 표준 컨트롤로의 변화는

체로 실체적 변화의 예다.



<그림 9b> 드래그 앤 드롭은 실체적 변화의 또 다른 예다. 사용자가 실제로 한 위치에서 다른 위치로

객체를 움직였기 때문이다.

화면 로드(screen loads)는 사용자가 처음으로 애플리케이션을 네비게이트할 때나 완전히 다른

섹션으로 이동할 때(사용자가 새 목표에 따라 업무를 진행할 때만 나타난다. Part 3: 애플리케이션

구성하기를 보자) 나타난다. 화면 로드는 체로 순간적일 필요가 없지만 10 초 이하여야 한다.

1 초에서 10 초 사이보다 조금이라도 더 시간을 끈다면 사용자는 더 많이 기다려야 한다고 느낀다.

애플리케이션을 잘 구성했다면 사용자는 화면 로드가 나타날 때마다 새 업무를 시작할 수

있으므로 잠시는 기다릴 수 있다. 사용자가 은행의 온라인 지불 시스템에서 투자 서비스

시스템으로 옮길 때가 화면 로드의 예가 되겠다.

<그림 10> Flektor 는 사용자가 퀵 스타트를 선택한 후 화면 로드를 수행한다. 사용자가 퀵 스타트 옵션을

클릭하면 로딩 화면이 나타나고 Flektor 는 적절한 퀵 스타트 기능이 있는 화면으로 바뀐다.

거 업무(big jobs)는 사용자가 시간이 오래 걸릴거라 기 하는 긴 연산이다. 사용자는 이를 가끔

요청하고 체로 많은 준비를 거친 후에만 요청한다. 거 업무는 10 초 이상 걸릴 수 있고 특히

사용자가 다른 업무를 진행하며 작동시킬 때 더욱 그렇다. 보고서 생성과 여러 웹 사이트에서

검색 결과를 취합하는 것 등이 거 업무의 예다. 시간이 오래 걸릴 것이라는 사용자의 기 는

변한다는 것에 주의하자. 예전에는 프로그램 코드를 컴파일하는데 몇 시간이 걸렸다면 이제는 몇

초밖에 안 걸린다.



<그림 11> 백업 연산은 거 업무의 좋은 예다. 사용자는 조심스럽게 이를 준비하고 가끔 작동시키며 오랜

시간이 걸릴거라 예상한다.

이런 유형의 연산은 고성능 기 에서 저성능으로 작동한다는 것에 주의하자. 이는 응답을

향상시키는 방법을 찾을 때 복잡하고 오래 작동하는 알고리즘 신 애플리케이션의 작은 실체적

변화를 먼저 검사해봐야 한다는 것을 의미한다.

실제로 애플리케이션에서 사용자 기 와 가장 어긋나는 연산 속도가 나는 부분에서 성능을

튜닝하자.

실체적 변화의 응답을 향상시키는 것은 체로 많은 캐싱을 의미한다. 느린 네트워크 로드와

복잡한 계산은 실체적 변화의 순간이 아닌 속도가 덜 중요할 때 나타난다. 두 가지 기본 옵션이

있다. 화면을 로드할 때 성능을 측정하거나 사용자가 성능과 상관없는 업무를 진행할 때 뒤에서

연산을 작동하는 것이 그것이다. 후자는 사용자가 무슨 일이 벌어지는지 모르는 상황에서 시간과

접한 연관이 있는 업무를 수행할 수 있기 때문에 특히 매력적이다.




이들 두 가지 전략 모두 하나의 장애물로 고통받는다. 사용자를 위해 미리 로드하거나 미리

계산한다면 사용자가 무엇을 할 것인지 예측해야 한다. 이는 상상하는 것만큼 어렵지 않다.

사용자가 사용하는 명령이나 보고자 하는 것은 체로 몇 가지 안된다. 잘 모르겠다면 모든 것을

계산하고 필요없는 결과는 간단히 지워버리면 된다. 프로세서는 이미 매우 빠르고 네트워크는

점점 더 빨라지고 있다. 이들은 액션을 취하기 전 결과가 필요한 그 순간(사용자가 요청할

때)만을 기다리며 시간을 보내고 있다. 이 때는 사용자의 성능 기 를 충족시키기엔 너무

늦어버린 때다.

애플리케이션이 놀고 있을 때 결과를 미리 계산하고 캐시해 미래 연산의 속도를 높이자.

가끔 데이터를 미리 계산하거나 미리 로딩하는 것이 옵션이 아닐 수 있다. Flex 애플리케이션에서

사용자가 거 데이터베이스를 검색하면 검색 매개변수가 나타나기 전까지 할 수 있는 일이 별로

없다. 데이터베이스 전체를 미리 로드하기엔 너무 크기 때문이다. 업무가 1 초 이상 걸린다면 더

작은 단위로 쪼개 사용자에게 시간이 덜 걸리는 것처럼 보이게끔 할 수 있는지 고려해보자. 예를

들어 검색 결과가 나타나는 로 조금씩 로드하고 보여주자. 어차피 사용자는 한 번에 하나의

화면만 처리할 수 있다. 이 전략을 사용해 무기력한 실체적 변화에 긍정적인 효과를 줄 수 있다.

긴 업무는 더 작게 쪼개 결과가 나올 때마다 사용자에게 보여주자.

언제든 가능하면 Flash Player 와 인터넷 자체의 비동시적 성질을 통해 사용자가 다른 일을 하는

동안(컨텐츠를 보고 생각하는 등) 뒤에서 느린 연산을 수행하자. 낡은 알고리즘 성능 분석을

포기해야 할 때가 있겠지만 Flex 애플리케이션에서 최고의 성능을 얻는 것은 실제로 빠르게

만드는 것이 아니라 사용자가 애플리케이션이 빠르다고 느끼게 하는 것이다.

기 관리하기

완벽한 세상에서는 그 어떤 연산도 0.2 초 이상 걸리지 않을 것이며 이는 인간이 인식하지도

못하는 시간이다. 불행히도 아직 그에 미치지 못한다. 그렇다면 사용자가 기 하는 기다림을

관리해 Flex 애플리케이션에 절망하지 않게 하려면 어떻게 해야 하는가?

작업의 성질과 로드 길이를 위한 적절한 피드백이 답이다. 마우스 클릭에 따른 버튼의 응답같은

저레벨의 기계적인 실체적 변화를 제외하고는 1 초 이하의 연산에는 특별한 피드백이 필요없다.

1 초 이상 걸리지만 10 초 이하로 걸리는 연산은 어떤 일이 발생하고 있다는 피드백을 제공하거나

사용자의 요청을 애플리케이션이 처리하고 있다는 것을 알아채지 못하게 해야 한다. 가끔

애플리케이션은 빙글빙글 도는 모래시계 커서를 사용한다. 움직이는 로딩 그림이 더 적절할 때도

있다. 어떤 것을 사용하든 목적은 애플리케이션이 사용자의 요청을 처리하고 곧 처리가 끝난다는


것을 사용자에게 알리는 것이다. (느리게 움직이는 애니메이션을 사용해 로딩 상태를 표시하는

것에 주의하자. 사용자는 느린 모션을 느린 로드로 받아들여 화면 로드가 빠르게 진행되더라도

사용자는 더 느리게 느낀다.)

<그림 12> Facebook 게임인 Scrabulous 에서 사용하는 Spinners 는 진행되고 있다는 일반적인 표시며

10 초 이하의 짧은 연산에 적절하다.

연산이 10 초 이상 걸린다면 애플리케이션은 진행과정을 표시하는 것 이상을 해야 한다. 이제

사용자는 완료되는데 얼마나 시간이 걸리는지 알고자 한다. progress bars 는 정확성에 문제가

있더라도 이런 류의 피드백을 제공하는 일반적인 컨트롤이다. 사용자에게 정확한 예상시간을

알려줘 기다리는 시간동안 무엇을 할 지(앉아서 기다려야 할까? 이메일을 쓸까? 커피를 마시고

올까? 내일 아침이나 되어야 해결되므로 집에 일찍 갈까?) 결정할 수 있도록 하자. 가끔

예상시간에 더해 애플리케이션은 현재 어떤 일이 진행되는지를 제공할 수 있다. 이러한 상세

내역이(기술적인 것 제외) 사용자에게 의미가 있어야만 적절하다. 애플리케이션이 현재 Austrian

Airlines 에서 좌석을 검색한다면 상세내역은 흥미롭겠지만 끼워진 SVG 그래프용 bezier 곡선을

계산한다면 다수의 사용자는 따분함과 두려움을 느낄 것이므로 애플리케이션 자체에서만 알면

된다.

작업의 성질을 기반으로 긴 연산과 연산 수행의 예상 시간을 위해 적절한 피드백 메커니즘을

사용하자.



<그림 13> Adobe Media Player installer 에서 사용하는 것과 같은 progress bars 는 사용자에게 거 작업이

작동하기까지 시간이 얼마나 걸릴지를 알려주는 인기있는 컨트롤이다. installer 에는 Cancel 버튼이 포함되어

있음에 유의하자. 모든 거 작업은 사용자가 작업을 실수로 시작했을 때나 시작 후 마음이 바뀌었을 때를

비해 기능적인 취소 명령을 제공해야 한다.

<그림 14> 비행기 가격 모음 사이트인 Kayak 은 가장 저렴한 비행기 표를 위해 웹 사이트를 검색하는 동안

progress bar 을 보여주지만 또한 검색하는 사이트들에 한 많은 추가 정보와 지금까지 찾은 결과를

보여준다. 이 경우, 추가적인 상세목록은 유용하고 사용자의 목표와 관련 있으므로 사용자에게 도움이 된다.



10 초 이상 걸리는 모든 연산은 사용자가 취소할 수 있도록 해야 한다. 사용자가 실수로 연산을

시작했을 수도 있고 연산에 걸릴 시간이 너무 길다는 것을 확인한 후 마음을 바꿀 수도 있기

때문이다. 특별한 후유증 없이 연산을 끝내는 ‘Cancel’ 버튼으로 사용자는 신속히 자신의 실수를

고칠 수 있다. 이런 버튼을 제공하지 않는 시스템은(또는 버튼을 눌렀을 때 아무 일도 일어나지

않는다면) 사용자는 크게 절망해 그저 자리에 앉아 다리나 떨며 시스템이 얼른 작업을

끝내주기를 초조히 기다릴 것이다.

거 작업은 체로 비동시적이어야 한다. 사용자는 뒤로 돌아가 연산의 처리과정을 확인할 수

있어야 하지만 거 작업이 진행되는 와중에 사용자가 애플리케이션을 사용해 다른 업무를

수행한다면 기다리는 시간은 그리 길게 느껴지지 않을 것이다.

<그림 15> Flex Builder 는 거 프로젝트를 컴파일할 때 거 작업을 비동기적으로 만든다. 코드가 컴파일

되는 동안 사용자는 애플리케이션에서 업무를 계속 수행할 수 있다. 하단 우측 코너에 진행 지시가 나타나

거 작업의 진행과정을 지속적으로 보고한다.

적절한 피드백을 제공하는 것은 효과적인 기술이 되겠지만 애플리케이션의 속도를 높일 때는

마지막 수단이어야 한다. 사용자는 애플리케이션을 효율적으로 사용할 수 있다면 거 작업을

처리하는데 시간이 많이 걸려도 용서해준다. 하지만 사용자가 무언가를 클릭할 때마다 끔찍한

돌아가는 모래시계가 화면에 뜬다면 애플리케이션을 사용하려고 하지 않을 것이다.

기다리라는 피드백은 가장 마지막 수단으로 제공하자.




Flex 디자인하기 – Part 8: 안전한 애플리케이션 만들기

사람들이 애플리케이션의 안전성(application safety)에 해 이야기할 때는 체로 보안에 한

이야기를 하는 것이며, 보안은 전체 그림에서 중요한 의미를 가진다. 하지만 기본적으로

사용자들이 애플리케이션이 안전하다고 느끼는 것은 통제가 되고 있다고 느끼기 때문이다.

그렇기에 사용자들에게 시스템이 하고 있는 것을 이해시키는 것이 중요하다.

이에로 사용자들이 의사 결정을 할 때마다 결정에 따른 변화의 결과가 무엇인지 명확하게

알리도록 하자. 명확한 의사 전달과 원활한 오류 처리를 하는 애플리케이션은 사용자로 하여금

쉽게 새로운 환경에 적응하게 만들며 더 쉽게 배우게 만든다. 왜냐하면 부분의 사용자들은

새로운 애플리케이션을 시도와 오류를 통해 배우기 때문이다. 하지만 만약 몇 일 혹은 몇 시간에

걸쳐 만들어놓은 작업을 애플리케이션의 기능 불량이나 파괴 연산으로 잃어 버린 사용자라면,

부주의한 데이터를 가지고 있거나 혹은 오류를 허락하지 않는 애플리케이션은 사용자의 믿음을

깨뜨릴 뿐만 아니라 신뢰를 다시 회복하기 어렵다.

본 글은 주로 규모 있는 플랜에서 보안이 절 적이지 않은 애플리케이션을 다루고 있다. 사용자가

몇 시간에 걸쳐 만든 작업이 다 날라가는 것은 매우 속상하고 비생산적이다. 또한 의도하지 않은

많은 이들에게 메일이 보내지는 것은 당혹스러운 일이다. 하지만 자신이 만든 애플리케이션의

오작동으로 사람들이 목숨을 잃거나 장애인이 되는 등(의료 장비 디자인이나 비행 통제 시스템

등) 안전이 절 적인 애플리케이션에 비하면 아무것도 아니다. 안전이 절 적으로 중요한

애플리케이션을 디자인한다면 본 글에서 다루는 많은 원칙들과 주제들이 더욱 중요해질 수 있다.

그리고 적절한 사용자와 시스템 테스트의 우선 순위도 “우리가 할 수 있는 최선을

다하겠습니다”에서 “본 제품은 누구도 죽이지 않을 만큼 완벽하게 안전하다는 게 입증되기

전까지 판매되지 않습니다”로 바뀐다. 본 글을 읽되 보안이 절 적으로 중요한 하드웨어 및

소프트웨어 시스템을 디자인하는 것만큼 엄격한 잣 를 들이 지는 말자.

본 글에서 다루는 내용은 다음과 같다.

• 지속적인 보안을 구현하여 사용자의 데이터를 보호하는 방법

• 원상태로 되돌아가기 및 취소 기능을 제공해 사용자의 잘못을 용서하는 방법

• 적절하게 눈에 띄는 피드백을 제공해 원상복귀되지 않은 액션의 결과를 사용자가 인식할

수 있게 하는 방법

• 적절히 구현된 보안 메커니즘을 통해 애플리케이션을 안전하게 하는 방법


절 데이터를 잃지 말자

이는 애플리케이션 보안의 첫 번째 규칙이다. 소프트웨어상의 몇 가지 오류로 인해 몇 시간

동안의 작업을 잃는 것보다 사용자를 절망에 빠뜨리고 생산성을 망가뜨리는 일은 없다. 이러한

오류가 시스템의 기술적 결함 때문이든 적절한 예방조치의 일환으로 의도적으로 발생한 오류이든

크게 중요치 않다. 데이터를 잃어버리는 일은 절 일어나서는 안 된다.

사용자의 데이터를 절 날리지 말자.

전통적인 데스크톱 애플리케이션과는 달리 Flex 애플리케이션은 체로 네트워크에 연결돼 있다.

이는 저장(Save) 기능이라는 하나의 표준 소프트웨어 용어와 큰 관련이 있다. “저장하기”는

사용자의 관점에서는 별 의미가 없다. 메모리와 영구 스토리지 간의 차이는 절 노출돼서는 안

되는 디테일한 구현이다. 하지만 웹 환경은 새로운 방식으로 복잡하다. 먼저 문서는 사용자가

익숙하지 않은 서버에 저장돼야 한다. 둘째, 네트워크 연결의 불안정성은 클라이언트/서버 간의

커뮤니케이션에 예상치 않은 단절을 가져올 수 있다. 이런 일이 발생하더라도 사용자는 자신의

작업을 잃지 않으리라는 확신을 가져야 한다.

다행히 이런 문제를 해결할 간단한 해결책이 있다. 사용자가 자신의 작업을 확실하게 저장하도록

하는 신 지속적인 저장(continuous save)을 항상 구현하면 된다.

항상 지속적인 저장(continuous save)을 제공하자.




<그림 1> Gmail 은 사용자가 이메일 메시지를 작성할 때 지속적으로 자동 저장한다. 사용자의 브라우저가

충돌하거나 세션 타임이 끝나더라도 사용자는 작업하던 내용을 아주 조금 잃을 뿐이다.

보내기/저장하기/취소하기(Send/Saved/Discard) 버튼 옆에 있는 ‘초안 자동저장(Draft autosaved)’ 메시지를

주목하자.

지속적인 저장은 메모리의 컨텐츠를 디스크에 남기는 사용자 주도의 ‘저장’ 개념이 갖는 부족한 점을

보완하고 있다. 신 애플리케이션이 사용자를 신해 영구 스토리지 매체(하드 디스크나 서버 위치에 상관

없이)를 관리한다. 사용자의 관점에서는 그저 작업할 뿐이고 잠시 나갔다 돌아와도 떠나기 전 상태로 작업이

남아있다.

지속적인 저장에 한 가장 일반적인 반 의견은 ‘사용자가 변경사항을 저장하고 싶지

않다면?’이다. 사용자가 그저 이런저런 시도만 해보고, 변경사항이 파일에 영향을 주지 않았으면

한다면 어떻게 할까? 해결은 아주 쉽다. 사용자가 문서를 편집하기 위해 열 때 영구 스토리지

매체에 백업 복사를 만든다. 그리고 이전에 연 상태로 파일을 돌려놓는 ‘복귀(Revert)’ 기능을

제공한다. 파일을 저장하는 것과 저장 없이 파일을 닫는 것 중에서 더 많이 행해지는 것이 어떤

것인가? 다수의 사용자는 체로 작업한 것을 저장하고자 할 것이다. 그러므로 저장하기보다는

취소하기 기능을 만드는 것이 훨씬 말이 된다.

지속적인 저장의 장점은 두 가지다. 첫번째는 사용자가 잘못하여 저장 버튼을 누르는 것을 잊어

버려 하던 작업을 잃지 않도록 방지한다. 이것은 특히 일정시간 동안 사용자의 활동이 없으면

로그아웃 시켜버리는 시스템의 문제이지만 Flex 애플리케이션에서는 일어나지 않는다. 둘째로

애플리케이션이 충돌할 때 작업을 잃는 일을 최소화한다. 애플리케이션은 절 충돌해서는

안되지만 충돌하곤 하기 때문에 이런 때를 비해야 한다. 충돌이 발생하면, Flex 애플리케이션은

미리 로드가 된 사용자 데이터와 함께 이미 충돌 전에 사용자가 있던 위치로 자체 복원한다.

충돌은 언제든지 발생할 수 있으며 인터넷이 안정적이지 않다는 것은 누구나 알고 있다. 거기다

역폭의 문제로 사용자가 키를 누를 때마다 데이터를 서버로 지속적으로 보내는 것은

비현실적이다. 지속적인 저장 기능은 절 적으로 네트워크 연결 가용성에 기 서는 안 된다. 신

애플리케이션이 네트워크 운영 간의 Adobe AIR 클라이언트를 목표로 한다면, Flash Player 의

Local Shared Objects 혹은 디스크 파일에 데이터를 저장해야 한다. 이런 행위는 사용자에게

보이지 않아야 한다. 사용자의 관점에서는 그들의 데이터만을 작업해야 하고, Flex

애플리케이션이 사용자가 전송하는 모든 것을 세심하게 처리하고 있다고 알아야 한다.


오류 용서하기

애플리케이션 실패(Application failures)는 안전성에 문제가 생겼음을 알리는 오직 하나의

방법이다. 다른 것들은 ‘사용자 오류(user error)’로 불리는데 이는 잘못된 말이다. 다수의

잘못이 엉성하게 디자인된 애플리케이션 때문이지, 사용자의 문제가 아니기 때문이다. 잘

디자인된 Flex 애플리케이션은 사용자의 실수를 용서하고 사용자가 오류들을 요청하더라도

안전성의 실패를 막을 만큼 스마트하다. 본 절에서는 그 방법에 해 설명하겠다.

애플리케이션에서 가장 중요한 안전성 기능은 ‘undo(원상태로 되돌리기)’다. 적절하게 구현된

undo 기능은 컴퓨터의 강력한 메모리를 사용해 문제가 발생하기 전의 바로 이전 상태로 돌려

실수를 커버한다. undo 기능으로 인해 사용자들은 자신 있게 애플리케이션을 사용할 수 있으며,

모르는 기능도 시도해 볼 수 있다. 사용자가 원하지 않거나 또는 기 하지 않은 일이 발생하면

undo 옵션을 언제든지 선택할 수 있다. 모든 애플리케이션은 어떤 의미로든 실수를 undo하는

기능을 제공해야 한다.

<그림 2a> Adobe Fireworks 같은 데스크톱 애플리케이션에서는 Undo 와 Redo 기능이 Edit 메뉴에 표준

메뉴 아이템으로 들어 있다. 다수의 데스크톱 도구는 이 기능을 가지고 있다. 사용자는 이 기능이 없을

때에야 이 기능을 그리워한다.



<그림 2b> 안타깝게도 Undo 기능은 다수의 웹 애플리케이션에 빠져 있다. 하지만, 다행히 이런 현상은

변하고 있다. Gmail 은 연산이 수행된 후 나타나는 오렌지색 공지 메시지 옆에 링크로 단일 수준의 undo

기능을 지원하고 있다.

하지만 Flex 애플리케이션에서 사용자에게 undo 기능을 어떻게 보여줘야 하는지는 항상 명확하지 않다.

데스크톱 상에서는 undo 가 체로 “편집” 메뉴의 첫 아이템이다. Flex 애플리케이션에서는 체로 창작

위주의 애플리케이션이나 복잡한 정보 위주의 애플리케이션에 제한된다. 다른 정보 중심의 또는 더 단순한

창작 중심의 애플리케이션은 기본적인 컨트롤 바에 항상 이 기능 버튼을 제공해야 한다. 반면 테스크 중심의

애플리케이션에서는 undo 를 “취소”로 생각해야 한다. 완성된 모든 테스크들은 애플리케이션에 보여져야

하고, 가능한 오랫동안 테스크의 결과를 취소할 수 있는 관련 기능을 가져야 한다. 예를 들어, 이것이

가능치 않다면 주문한 것이 이미 배송됐다면 취소 명령은 사용자에게 남아있는 옵션이 어떤 것이 있는지

제공해야 한다. 특정 시간 전에 취소해야 하는 작업이 있다면 사용자에게 작업이 끝난 후 마음을 바꿀 수

있는 시간이 얼마나 되는지 명확히 알려줘야 한다.

사용자가 undo 나 취소 기능을 사용해 이전 상태로 돌릴 수 있게 함으로써 사용자의 실수를

용서해야 한다.



<그림 3> ETrade 의 청구 지불 시스템은 사용자가 자신의 계류중인 지급과 취소된 지급 목록을 볼 수

있도록 한다. 이같은 테스크 중심의 디자인에서 취소는 undo 의 역할을 한다(주의: 본 디자인은 민감한

정보를 제거하기 위해 살짝 수정됐다).

결과를 명확히 알려주기

많은 인기 있는 데스크톱 및 웹 애플리케이션은 사용자의 데이터를 보호하고 오류를 용서하는

적절한 기능을 제공한다. 하지만 명확한 피드백이라는 애플리케이션 안전성의 세 번째 측면에는

좋은 예가 거의 없다. 다수의 애플리케이션은 위험을 불러 올 수 있는 잠재적인 동작의 결과를

사용자가 충분히 이해할 수 있도록 미리 알려주지 못한다.

예를 들어, 웹 브라우저는 체적으로 보호 모드와 비보호 모드를 가지고 있다. 사용자가 이들

모드를 바꿀 때 받는 피드백은, 아래쪽 컨트롤 바에 나타나는 조그마한 잠금 아이콘뿐이다.

다수의 사용자는 이 아이콘이 중요한 정보 중의 하나임에도 불구하고 보지 못하는 경우가 많다.

사용자들은 웹 사이트에 보내는 민감한 정보가 잠재적으로 범죄에 노출되지 않는다는 확신을

갖고 싶어한다. 보다 명확한 방법으로 보안 상태를 표현하려면 폼 요소 혹은 전체 브라우저 창을

수정하거나 위험 모드와 안전 모드를 시각적으로 명확하게 만들어주는 것이다.

또한 부분의 이메일 클라이언트는 빈번한 사용자 실수의 결과를 명확하게 알려주지 못하고

있다. 많은 사람들이 실수로 ‘전체에게 답신 메일 보내기(reply all)’를 클릭하고 괴로워한다.

이들을 비난할 순 없다. 메시지가 어디로 가는지는 이메일 주소의 ‘To’ 필드에만 보이기 때문이다.

많은 사용자들은 메시지 작성에 주로 초점을 맞추기 때문에 메시지 제목과 본문에만 신경을 쓴다.



엉뚱한 이에게 메일을 보내는 일은 사용자에게 아주 창피한 일이기 때문에 이메일

애플리케이션은 좀 더 명확하게 이를 알려줘야 한다. 메일을 보낸 사람에게만 답신을 보낼 때와

메일을 받은 모든 사람들에게 답신을 보낼 때는 확실하게 다른 메일 환경을 보여줘야 한다.

Outlook 같은 상업용 이메일 시스템과 묶인 이메일 클라이언트는 더더욱 개인에게 발송되는

메시지와 분산 목록으로 보내지는 메시지를 확실히 구별해 보여줘야 한다.

<그림 4> Buzzword 는 문서 공유 인터페이스를 사용하여 정확한 방향을 보여주고 있다. 사용자는 맨 밑의

바에 제공된 각 개인의 이메일 주소와 이름으로 누가 사용자의 문서에 접속되었는지 명확하게 분류해야

한다. 이를 통해 현재 열린 문서에 누가 접속했는지 명확히 볼 수 있다.

좋은 Flex 애플리케이션은 그들이 제공하는 기능 안전성을 더 심도 있게 고민해야 한다. 특히

개인의 신용카드 정보를 안전하지 못한 연결을 통해 보내거나, 계획되지 않은 많은 이들에게

이메일을 보낼 때는 돌이킬 수 없다. 잠재적으로 안전하지 않은 작동의 결과는, 화면 한 쪽의

작은 아이콘으로 숨겨둘 것이 아니라 명확하게 보이도록 한다.

사용자 동작의 결과가 어떠냐에 따라 적절한 피드백을 제공한다.



보안과 비 번호

보안(Security) 은 소프트웨어 애플리케이션(특히 네트워크로 연결된 Flex 애플리케이션)에서 가장

중요한 고려사항이지만 불행하게도 보안을 위해 디자인된 인터페이스는 애플리케이션을 사용하기

어렵게 만들곤 한다. 반어적으로 이 때문에 애플리케이션의 보안이 더 취약하게 되기도 한다.

사용자들은 보안 기능을 꽤 잘 피한다. 비 번호가 그 중 가장 표적이다. 보안을 중요시

생각하는 디자이너와 개발자들은 사용자들이 지속적으로 비 번호를 사용하도록 강요하지만

종이에 비 번호를 적어 모니터에 붙이거나 같은 비 번호를 많은 웹 사이트에서 사용하는 등

사용자들의 취약한 비 번호 사용을 발견할 뿐이다. 강력한 비 번호를 사용하라고 사용자들을

압박하는 것은 문제를 더 악화시키기만 한다.

비 번호(passwords)를 요구하는 많은 시스템들은 사실상 보안에 비 번호가 필요하지 않은

경우가 많다. 많은 웹사이트들은 사용자들이 입력할 수 있는 비 번호 찾기 시스템을 가동하는데

예를 들어 사용자 엄마의 성이나 추측하기 힘든 질문의 답 등이 그것이다. 사용자가 비 번호를

잊어버렸을 때를 비해 보안 질문을 만들거나, 혹은 비 번호 신 보안 질문을 사용하면

어떨까? 많은 애플리케이션을 위해서는 이 정도면 충분하다. 그리고 사용자들에게는 더 쉽고

안전성 면에서는 비슷하다.

필요 이상의 엄격한 보안 단위를 피하라.




<그림 5> Interaction Design Association 의 웹 사이트는 혁신적으로 비 번호가 없는 로그인 메커니즘을

도입했다. 오직 토론 포럼에만 참여하고자 하는 이들에게 심각한 방해가 되는 방문자 등록을 요구하는 신

웹 사이트는 사용자 이름과 이메일 주소만을 묻는다. 그리고 나서 사용자의 신분과 사용자가 클릭할 수 있는

링크를 포함한 확인 이메일을 보낸다. 이 절차가 끝나면 브라우저 쿠키를 통해 사용자의 머신에서 절차가

다시 반복되지 않도록 한다. 모든 웹 사이트에 적절한 것은 아니지만 이 메커니즘은 사용자의 필요에 맞는

적절한 보안성을 제공하는 동시에 귀찮은 등록 및 비 번호 기억을 피할 수 있도록 한다.

명확치 않은 보안 기술을 사용자들에게 강요하는 신 지난 세션에서 설명했던 것처럼 사용자

동작의 결과를 명확히 알려주면 된다. 기능에 보안 암시가 있다면, 이 암시를 명확히 하자. 예를

들어, 사용자들이 폼의 체크박스에 의해 선택된 네트워크를 통해 공개적으로 접근할 수 있는

파일을 만들 수 있도록 지원하는 시스템을 고려해 보자.

이보다 더 좋은 접근은 사용자들이 파일들을 옮길 수 있도록 구별된 공공의 공간을 정의하는

것이다. 이 공간은 사용자에게 기능을 설명하는 일반적인 개인 공간과는 시각적으로 명확히

달라야 한다.

변경할 시간적 여유가 있을 때 사용자 동작의 결과에 적절한 피드백을 제공함으로써

사용성과 보안성을 향상시키자.

결론

본 글은 Flex 디자인하기 글을 마무리하는 글이다. 이제 계획 및 사용자 연구에서 구조적

디자인/정보 아키텍처, 디테일한 비주얼 및 인터랙션 디자인에 이르기까지 Flex RIA 디자인의

주요 주제에 익숙해졌을 것이다. 본 글에 더해 부록 A: 베스트 실행 목록에추려낸 몇 가지 베스트

디자인 실행을 모았다. 애플리케이션을 디자인하면서 또는 기존 애플리케이션을 평가하거나

디자인을 제안하면서 이 베스트 실행 목록을 사용하기 바란다.

본 글의 연재를 통해 Flex RIA 디자인과 가장 관련 있는 디자인 원칙이나 실행을 다뤘지만 디자인

분야는 사실 너무나 광범위하다. 부록 B: 추가 읽기에서는 본 연재에서 다루지 못한 디자인

베스트 실행에 관한 더 많은 정보를 제공하는 서적들과 웹 사이트 목록을 수록했다. 애플리케이션

디자인에 관한 지식을 더 넓히고자 하는 이들에게 좋은 참고서가 될 것이다.

RIA 디자인 분야는 여전히 새로운 분야다. 본 글에서 다룬 베스트 실행들이 다른 매체나

Adobe의 RIA경험에서 개발된 디자인 지식을 기반으로 하지만, 전문가인 우리들 조차도 아

충분한 안내 지식을 갖추지 못하고 있다. 결과적으로, 베스트 실행은 계속 진보될 것이고, 새

직까지

로운



아주 것이 추가될 수도 있고, 옛 것이 사라질 수도 있다. 지금 이 시간이 RIA 디자이너에게는

어렵기도 하지만 재밌기도 한 시기다. 아직도 발견해야 할 것들이 많이 남아 있다. 여러분

나름 로 발견한 것이 있다면 이를 Flex 인터페이스 가이드 포럼에서다른 이들과 공유하거나 본

글의 사이드 바에 있는 링크를 통해

피드백을 보내기 바란다. 우리는 언제든지 Flex

애플리케이션에서의 새로운 도전과 해결책을 들을 만반의 준비가 돼 있다.

다음 Flex 애플리케이션에도 좋은 결과가 있기 바란다!

Documents

Adobe Flex Design