2008/05/05 03:03
Rich Internet Applications HCI & UX2008/05/05 03:03
최초 작성자: 세티
최초 작성일: 2008년 5월 5일
꽤 오래된 자료 인데 개인적으로 필요해서 번역을 했습니다.
그리고 많은 부분을 의역화 했습니다.
A Look at Rich Internet Applications
By Cameron O'Rourke
2002년부터 2004년까지 2년동안 Rich Client를 이용한 흥미있는 아이디어가 많이 나오게 되었습니다. Rich Client의 사용자 인터페이스는 HTML 보다 더 견고하고, 응답적이고 비쥬얼한 흥미를 주기 때문입니다.
Rich Internet Application(RIA) 기술은 웹을 이용하여 Rich Client를 배포할 수 있는 기술을 말합니다. RIA는 그 어떤 누가 예측하더라도 완벽하게 HTML을 대체할 수 있을 것이라 여겼습니다. 그러나 복합적인 애플리케이션을 실행하기 위해선 "fat client" 기술처럼 저렴한 비용으로 복합적 애플리케이션을 실행할 수 있는 대안이 요구되었습니다.
왜 Rich Internet Application인가?
HTML 기반 애플리케이션은 간단한 아키텍처와 낮은 비용으로 배포를 할 수 있었기 때문에 많은 인기가 있었습니다. 그리고 HTML은 누구나 쉽게 배우고 또 사용할 수 있었습니다. 많은 사용자와 개발자들은 새로운 데이터와 애플리케이션에 즉시 접속할 수 있었고 또 잠시 자리를 비웠다가 다시 컴퓨터 앞으로 돌아왔을 때에도 그 상태 그대로 사용자 인터페이스를 보여줍니다. 이것은 웹 기반에서 의미있는 UI의 기능보다 더 중요한 이점이었습니다.
그러나 HTML은 우리가 확신을 가지고 사용하게 되는 애플리케이션과 잘 맞지 않았습니다. 그 이유는 다음과 같은데 복잡한 애플리케이션은 한 트랜잭션에서 완벽하게 몇몇의 페이지를 다시 그려줘야 하기 때문입니다. 예를 들어서 의학 분야나 금융 분야 처럼 확실하게 필드를 보여줘야 하는 케이스에서는 느린 상호작용을 보여주면 안됩니다. 또한 프로젝트 매니지먼트 시스템과 같은 것을 만들때도 HTML 애플리케이션으로 조작 되야 하고, 유저에게 차트, 스케줄, 계층적인 것과 같은 것들을 보여줘야 합니다.
더 나아가 오프(off)된 상태에서도 바로 스크립트와 쌍방향 작용이 가능해야하고, 입력 폼에 의해 입력되는 값들은 브라우저에 의해 간단한 이름/값 쌍으로 보내질수 있어야 합니다. 또한 XML 문서로 부터 복합적인 데이터 구조를 받고 보낼 수 있어야 하기 때문입니다.
HTML과 달리 RIA의 유틸은 다른 그 어떤 것보다 강력한 클라이언트-사이드 렌더링 엔진입니다. 그것은 일반적인 애플리케이션에 비해 허술하지 않으며 그래픽적인 Rich User Interface를 통해 응답할 수 있습니다. 추가적으로 컨트롤의 다양성(슬라이더, 데이트 피커, 윈도우즈, 탭, 스나이퍼, 게이지 등)이 있으며, 일반적인 SVG나 다른 매커니즘에 따르는 그래픽 생성을 수용 합니다. 어떤 RIA기술은 데이터 변경시 응답하는 풀 모션 애니메이션을 제공하기도 합니다.
이런 RIA의 또 다른 이점은 데이터가 클라이언트에 캐쉬될 수 있다는 점, HTML 보다 서버에 라운드 트립하는게 낮다는 점, 그리고 최근의 트랜드가 텍스트 기반의 웹 클라이언트에서 멀어지면서 무선이나 디바이스를 지원하는 Rich Client로 넘어가고 있기 때문입니다. 또한 랩탑에서 실행되는 애플리케이션은 인터넷 연결을 잃어도 오프라인에서 작업이 가능하도록 디자인 되어져 있습니다.
RIA의 일반적인 아키텍처는 그림과 같습니다.
XML은 데이터 전송이나 폼 레이아웃을 기술하는 용도로 사용됩니다. 수 많은 인스턴스로 클라이언트가 데이터 소스를 이용하여 연결되고 그 안에 머무르게 되면 서버는 실시간으로 클라이언트를 업데이트 할 수 있습니다.
Rich Clients를 위한 기술들
RIA의 기술은 다음과 같습니다.
Java
오라클의 J디벨로퍼나 이클립스로 자바 코드를 작성할 수 있는데 상상할 수 있는 대부분의 Rich Client 를 생성할 수 있습니다. Java는 몇년전 부터 폼 기반 UI를 지원하는데 폭 넓게 이용되었습니다. 추가적으로 사용자 인터페이스는 Java Foundation Classes(JFC/Swing)내의 콤포넌트에서 찾을 수 있습니다. 또한 개발자들은 이클립스 프로젝트와 다른 써드 파티 툴킷에서 Standard Widget Toolkit(SWT)을 사용하여 개발할 수 있습니다. Java는 또한 XML과 웹 서비스를 지원합니다. 웹 브라우저의 자바 플러그 인이나 자바 런타임 환경에 포함된 새로운 자바 웹 스타트 기술을 사용하여 애플리케이션을 배포할 수도 있습니다. Rich Client를 만드는데 있어 자바를 사용하는데 중요한 결점 한가지는 간단한 폼이나 그래픽을 생성하는데 있어서 적지 않은 라인의 코드를 요구합니다.
XUL
XUL은 모질라 오픈 소스 프로젝트에서 제안한 XML 기반의 UI 언어입니다.
그것은 Zulu(플래쉬 MX 컴포넌트)와 Thinlets(자바도구)와 같은 다른 렌더링 엔진과 마찬가지로 모질라 브라우저내에서 실행되는 폼 애플리케이션을 생성하기 위해 사용됩니다. XUL 랜더링 엔진은 일반적으로 매우 작고(100k) XML 데이터를 산출할 수 있습니다. 자바와 더불어 Theodore Thinlet Editor와 같은 오픈소스 툴의 풍부함으로 인해 꽤 큰 사용자 커뮤니티가 있습니다. 자바 애플리케이션에서 그래픽한 레이아웃 UI와 XUL을 통신하게 할 수 있습니다. XUL의 가장 큰 불리한 점은 주요 기업의 지지가 없다는 점이다. XUL의 큰 이점은 Gecko 엔진과 통합할 수 있고, 실제로 XUL은 다른 XML UI 정의언어 대부분과 비교했을 때 매우 표현적이고 간결한 언어입니다.
마크로미디어 플래쉬와 플렉스
플래쉬는 웹 페이지에서 그래픽을 보여주기 위한 상업적 제품입니다. 그것은 최근에 폼-스타일 애플리케이션을 빌딩하기 위한 특징을 포함했고, 업그레이드 했습니다. 플래쉬는 웹에 광범위하게 배포된 프론트-엔드 기술이고 이론의 여지는 있지만 98%의 데스크 탑에 설치되어 있습니다. 활발한 그래픽을 생성하는 플래쉬의 편리함은 매우 강력하고 또 비쥬얼적 입니다. 이것의 스크립팅 언어는 액션 스크립트, 자바스크립트로 잘 알려진 ECMAScript 1.5입니다. 플래쉬에 XML description language가 추가된 제품이 Flex 입니다. 그래서 UI는 플래쉬 플레이어에 의해 컴파일과 렌더링 될 수 있습니다. 플래쉬와 플렉스의 첫번째 불리한 점은 개발툴의 미비점으로 인해 XML과 웹 서비스를 지원에 한계가 있다는 점입니다. 하지만 플렉스와 플래쉬의 이점은 복잡한 애니메이션을 쉽게 만들 수 있고 써드파티 제품에 애드온 된다는 점입니다.
오라클 폼(Forms)
오라클 폼은 데이터 중심 인터넷 애플리케이션을 빌딩하기 위한 상업적 제품입니다. 오라클 폼에서 폼 모듈 파일들의 출력물인 비쥬얼 디자이너를 사용하여 폼을 생성할 수 있습니다. 모듈 파일들은 FMT 포맷이나 그 밖의 디자인 툴을 위한 XML로 형식화 될 수 있습니다. 추가적으로 표준화된 폼의 모든 위젯은 자바 콤포넌트와 커스텀 자바 빈즈에 통합될 수 있습니다. 스크립팅 언어는 오라클 데이터베이스에서 사용되는 것과 같은 PL/SQL 이다. 오라클 폼의 흥미로운 특징은 폼 모듈 파일을 생성하고, 수정하고 컴파일링 하기 위한 자바 API를 사용할 수 있습니다. 오라클 폼의 중요한 결점은 웹에 배포하기 위한 오라클 애플리케이션 서버 라이센스가 요구된다는 점이며 이점으로는 오라클 플랫폼이나 오라클 데이터베이스에 강력하게 통합된다는 점입니다.
Rich Internet Applications를 생성하기 위한 기술을 이용하는데 있어서 RIA기술을 선택해야 하는데 다음과 같은 요소를 따라야 한다.
1. 오픈소스와 상업적 제품간의 비교
2. 성숙한 기능 이냐 특정 기능이냐
3. 가볍고 저장공간이 작아야 하느냐 UI가 풍부해야 하느냐
4. 미디어 중심이냐 데이터 중심 애플리케이션이냐?
RIA를 생성하기 위한 최상의 준수사항은
1. 백그라운드 스레드를 이용하여 패치 되어야 합니다. 리치 클라이언트를 위한 퍼포먼스의 기대는 높아야 하고, 만약에 웹 서비스로 데이터를 수집하는데 애플리케이션이 중단될 때 그것은 응답이 없는 것처럼 보여야 합니다.
2. 클라이언트와 리모트 데이터가 동기화 되는 것 처럼 보여야 합니다.
4. 흥미롭고 기능적인 UI를 비쥬얼하게 생성하는 능력을 가진 그래픽 아티스트나 최소한 좋은 UI 디자이너가 잇어야 합니다.
최초 작성일: 2008년 5월 5일
꽤 오래된 자료 인데 개인적으로 필요해서 번역을 했습니다.
그리고 많은 부분을 의역화 했습니다.
A Look at Rich Internet Applications
By Cameron O'Rourke
2002년부터 2004년까지 2년동안 Rich Client를 이용한 흥미있는 아이디어가 많이 나오게 되었습니다. Rich Client의 사용자 인터페이스는 HTML 보다 더 견고하고, 응답적이고 비쥬얼한 흥미를 주기 때문입니다.
Rich Internet Application(RIA) 기술은 웹을 이용하여 Rich Client를 배포할 수 있는 기술을 말합니다. RIA는 그 어떤 누가 예측하더라도 완벽하게 HTML을 대체할 수 있을 것이라 여겼습니다. 그러나 복합적인 애플리케이션을 실행하기 위해선 "fat client" 기술처럼 저렴한 비용으로 복합적 애플리케이션을 실행할 수 있는 대안이 요구되었습니다.
왜 Rich Internet Application인가?
HTML 기반 애플리케이션은 간단한 아키텍처와 낮은 비용으로 배포를 할 수 있었기 때문에 많은 인기가 있었습니다. 그리고 HTML은 누구나 쉽게 배우고 또 사용할 수 있었습니다. 많은 사용자와 개발자들은 새로운 데이터와 애플리케이션에 즉시 접속할 수 있었고 또 잠시 자리를 비웠다가 다시 컴퓨터 앞으로 돌아왔을 때에도 그 상태 그대로 사용자 인터페이스를 보여줍니다. 이것은 웹 기반에서 의미있는 UI의 기능보다 더 중요한 이점이었습니다.
그러나 HTML은 우리가 확신을 가지고 사용하게 되는 애플리케이션과 잘 맞지 않았습니다. 그 이유는 다음과 같은데 복잡한 애플리케이션은 한 트랜잭션에서 완벽하게 몇몇의 페이지를 다시 그려줘야 하기 때문입니다. 예를 들어서 의학 분야나 금융 분야 처럼 확실하게 필드를 보여줘야 하는 케이스에서는 느린 상호작용을 보여주면 안됩니다. 또한 프로젝트 매니지먼트 시스템과 같은 것을 만들때도 HTML 애플리케이션으로 조작 되야 하고, 유저에게 차트, 스케줄, 계층적인 것과 같은 것들을 보여줘야 합니다.
더 나아가 오프(off)된 상태에서도 바로 스크립트와 쌍방향 작용이 가능해야하고, 입력 폼에 의해 입력되는 값들은 브라우저에 의해 간단한 이름/값 쌍으로 보내질수 있어야 합니다. 또한 XML 문서로 부터 복합적인 데이터 구조를 받고 보낼 수 있어야 하기 때문입니다.
HTML과 달리 RIA의 유틸은 다른 그 어떤 것보다 강력한 클라이언트-사이드 렌더링 엔진입니다. 그것은 일반적인 애플리케이션에 비해 허술하지 않으며 그래픽적인 Rich User Interface를 통해 응답할 수 있습니다. 추가적으로 컨트롤의 다양성(슬라이더, 데이트 피커, 윈도우즈, 탭, 스나이퍼, 게이지 등)이 있으며, 일반적인 SVG나 다른 매커니즘에 따르는 그래픽 생성을 수용 합니다. 어떤 RIA기술은 데이터 변경시 응답하는 풀 모션 애니메이션을 제공하기도 합니다.
이런 RIA의 또 다른 이점은 데이터가 클라이언트에 캐쉬될 수 있다는 점, HTML 보다 서버에 라운드 트립하는게 낮다는 점, 그리고 최근의 트랜드가 텍스트 기반의 웹 클라이언트에서 멀어지면서 무선이나 디바이스를 지원하는 Rich Client로 넘어가고 있기 때문입니다. 또한 랩탑에서 실행되는 애플리케이션은 인터넷 연결을 잃어도 오프라인에서 작업이 가능하도록 디자인 되어져 있습니다.
RIA의 일반적인 아키텍처는 그림과 같습니다.
XML은 데이터 전송이나 폼 레이아웃을 기술하는 용도로 사용됩니다. 수 많은 인스턴스로 클라이언트가 데이터 소스를 이용하여 연결되고 그 안에 머무르게 되면 서버는 실시간으로 클라이언트를 업데이트 할 수 있습니다.
Rich Clients를 위한 기술들
RIA의 기술은 다음과 같습니다.
Java
오라클의 J디벨로퍼나 이클립스로 자바 코드를 작성할 수 있는데 상상할 수 있는 대부분의 Rich Client 를 생성할 수 있습니다. Java는 몇년전 부터 폼 기반 UI를 지원하는데 폭 넓게 이용되었습니다. 추가적으로 사용자 인터페이스는 Java Foundation Classes(JFC/Swing)내의 콤포넌트에서 찾을 수 있습니다. 또한 개발자들은 이클립스 프로젝트와 다른 써드 파티 툴킷에서 Standard Widget Toolkit(SWT)을 사용하여 개발할 수 있습니다. Java는 또한 XML과 웹 서비스를 지원합니다. 웹 브라우저의 자바 플러그 인이나 자바 런타임 환경에 포함된 새로운 자바 웹 스타트 기술을 사용하여 애플리케이션을 배포할 수도 있습니다. Rich Client를 만드는데 있어 자바를 사용하는데 중요한 결점 한가지는 간단한 폼이나 그래픽을 생성하는데 있어서 적지 않은 라인의 코드를 요구합니다.
XUL
XUL은 모질라 오픈 소스 프로젝트에서 제안한 XML 기반의 UI 언어입니다.
그것은 Zulu(플래쉬 MX 컴포넌트)와 Thinlets(자바도구)와 같은 다른 렌더링 엔진과 마찬가지로 모질라 브라우저내에서 실행되는 폼 애플리케이션을 생성하기 위해 사용됩니다. XUL 랜더링 엔진은 일반적으로 매우 작고(100k) XML 데이터를 산출할 수 있습니다. 자바와 더불어 Theodore Thinlet Editor와 같은 오픈소스 툴의 풍부함으로 인해 꽤 큰 사용자 커뮤니티가 있습니다. 자바 애플리케이션에서 그래픽한 레이아웃 UI와 XUL을 통신하게 할 수 있습니다. XUL의 가장 큰 불리한 점은 주요 기업의 지지가 없다는 점이다. XUL의 큰 이점은 Gecko 엔진과 통합할 수 있고, 실제로 XUL은 다른 XML UI 정의언어 대부분과 비교했을 때 매우 표현적이고 간결한 언어입니다.
마크로미디어 플래쉬와 플렉스
플래쉬는 웹 페이지에서 그래픽을 보여주기 위한 상업적 제품입니다. 그것은 최근에 폼-스타일 애플리케이션을 빌딩하기 위한 특징을 포함했고, 업그레이드 했습니다. 플래쉬는 웹에 광범위하게 배포된 프론트-엔드 기술이고 이론의 여지는 있지만 98%의 데스크 탑에 설치되어 있습니다. 활발한 그래픽을 생성하는 플래쉬의 편리함은 매우 강력하고 또 비쥬얼적 입니다. 이것의 스크립팅 언어는 액션 스크립트, 자바스크립트로 잘 알려진 ECMAScript 1.5입니다. 플래쉬에 XML description language가 추가된 제품이 Flex 입니다. 그래서 UI는 플래쉬 플레이어에 의해 컴파일과 렌더링 될 수 있습니다. 플래쉬와 플렉스의 첫번째 불리한 점은 개발툴의 미비점으로 인해 XML과 웹 서비스를 지원에 한계가 있다는 점입니다. 하지만 플렉스와 플래쉬의 이점은 복잡한 애니메이션을 쉽게 만들 수 있고 써드파티 제품에 애드온 된다는 점입니다.
오라클 폼(Forms)
오라클 폼은 데이터 중심 인터넷 애플리케이션을 빌딩하기 위한 상업적 제품입니다. 오라클 폼에서 폼 모듈 파일들의 출력물인 비쥬얼 디자이너를 사용하여 폼을 생성할 수 있습니다. 모듈 파일들은 FMT 포맷이나 그 밖의 디자인 툴을 위한 XML로 형식화 될 수 있습니다. 추가적으로 표준화된 폼의 모든 위젯은 자바 콤포넌트와 커스텀 자바 빈즈에 통합될 수 있습니다. 스크립팅 언어는 오라클 데이터베이스에서 사용되는 것과 같은 PL/SQL 이다. 오라클 폼의 흥미로운 특징은 폼 모듈 파일을 생성하고, 수정하고 컴파일링 하기 위한 자바 API를 사용할 수 있습니다. 오라클 폼의 중요한 결점은 웹에 배포하기 위한 오라클 애플리케이션 서버 라이센스가 요구된다는 점이며 이점으로는 오라클 플랫폼이나 오라클 데이터베이스에 강력하게 통합된다는 점입니다.
Rich Internet Applications를 생성하기 위한 기술을 이용하는데 있어서 RIA기술을 선택해야 하는데 다음과 같은 요소를 따라야 한다.
1. 오픈소스와 상업적 제품간의 비교
2. 성숙한 기능 이냐 특정 기능이냐
3. 가볍고 저장공간이 작아야 하느냐 UI가 풍부해야 하느냐
4. 미디어 중심이냐 데이터 중심 애플리케이션이냐?
RIA를 생성하기 위한 최상의 준수사항은
1. 백그라운드 스레드를 이용하여 패치 되어야 합니다. 리치 클라이언트를 위한 퍼포먼스의 기대는 높아야 하고, 만약에 웹 서비스로 데이터를 수집하는데 애플리케이션이 중단될 때 그것은 응답이 없는 것처럼 보여야 합니다.
2. 클라이언트와 리모트 데이터가 동기화 되는 것 처럼 보여야 합니다.
4. 흥미롭고 기능적인 UI를 비쥬얼하게 생성하는 능력을 가진 그래픽 아티스트나 최소한 좋은 UI 디자이너가 잇어야 합니다.
'HCI & UX' 카테고리의 다른 글
| User Experience Architecture (4) | 2008/06/23 |
|---|---|
| Remix08 Beyond RIA (0) | 2008/06/07 |
| User Experience란? (0) | 2008/06/04 |
| Rich Internet Applications (0) | 2008/05/05 |
| Scott Guthrie가 발하는 Silverlight2의 RIA(Rich Internet Application) (0) | 2008/04/27 |
| 웹 접근성을 위한 CSS(1) (0) | 2008/04/06 |
