본문

RoughlyDrafted Magazine

Daniel Eran Dilger in San Francisco

An Adobe Flash developer on why the iPad can’t use Flash

February 20th, 2010

Daniel Eran Dilger

Flash 구축에 대해 전문가라 할 수 있는 인터랙티브 컨텐트 개발자인 모건 아담스(Morgan Adams)가 플래시와 아이패드에 관한 흥미로운 글을 보내왔다. 나머지는 동 주제에 대한 그의 글이다.

전 왜곡되어 있다고 할만 합니다. 전문 플래시 개발자이자, 아이패드용 플래시 사이트 의뢰가 들어오면 행복해 할 테니까요. 정말 그러고 싶습니다만, 그것이 합리적이지는 않습니다. 아이패드용 플래시는 나오지 않을 것이며, 나와서도 안됩니다. 주된 이유는 그동안 거론이 안된 이유때문입니다.

현재 플래시 사이트들은 터치스크린 기기에서 잘 만들어질 수가 없어요. 애플이나 어도비는 커녕 마술과 같은 새 기기가 나오더라도 어쩔 수 없습니다.

즉, 이 이유는 느린 휴대기기의 성능이나 배터리 수명, 충돌현상때문이 아닙니다. 마우스오버, 혹은 호버(hover) 문제 때문입니다.

대다수가 아니라 하더라도, 수많은 플래시 게임과 메뉴, 심지어 비디오 플레이어에 이르기까지 플래시 컨텐트는 눈에 보이는 마우스 포인터를 필요로 합니다. 뭔가에 대한 호버링(마우스오버)과 실질적인 클릭 간의 관계에 의존하는 코딩이기 때문이지요. 이 차이는 흔한 겁니다. 인터랙티브 디자인에는 근본적이기도 하고, 널리 퍼져있기도 하지요. 플래시 컨텐트의 기본적인 사용에 있어서도 필수적입니다. 터치스크린용으로 디자인한 플래시 컨텐트를 새로 만들 수는 있겠지만, 사람들이 원하는 건 기존의 플래시 사이트입니다. 모두 다이죠. 여기는 되고 저기는 안되고, 그런 것이 아니에요. 그것도 사용할 수 있어야 합니다. 불가능한 일이에요.

애플과 어도비가 할 수 있는 일이란 것이, 현재의 플래시 컨텐트를 보이게 만드는 것 뿐입니다. 그러면 보이긴 하겠죠. 하지만 종종 작동을 안할 겁니다. 그러면 이용자들은 이게 안보인다고 화를 내겠죠. 페이지 사이에 갭이 있다거나 배너광고가 안보이고, 플래시 게임 페이지를 방문할 때마다 다시 다운로드받는 대신 앱스토어에 가서 다운로드받아야 할 때 내는 짜증 이상일 겁니다.

Mouseover examples:

* 마우스오버가 있을 때 컨트롤이 나타나거나 숨는 비디오 플레이어. (사실상의 표준같아 보입니다만 영상 가운데를 클릭하면 보통은 멈춤이지요. Hulu를 해 보십시오.)

* 클릭 없이 마우스를 돌려서 하는 게임. (매우 일반적입니다.)

* 마우스를 메인버튼 위로 움직이면 하부 페이지 링크가 나타나는 메뉴. (클릭할 때 메인 카테고리 페이지로 직접 갈 때와는 다릅니다.)

* 마우스가 움직일 때 중요한 설명이나 요약이 나오는 버튼. 클릭하기 전에 무엇인지 이해해야 할 필요가 있을 때 나옵니다.

* 마우스오버를 통해 프리뷰를 보는 기능. 아바타용 머리 색깔을 고를 때와 같은 것입니다. 캐릭터가 마음에 들 때까지 색상을 마우스로 고르는 것이지요. 정해지면 클릭을 합니다.

* 클릭을 전혀 사용하지 않는 지도와 표. 하지만 마우스를 움직일 경우 나타나는 팝업 정보.

* 마우스만 있으면 "돌아가는" 개별 마우스오버 기능. 설명이 필요 없음.

이런 사례들을 손가락(혹은 전통적인 스타일러스)으로 올바르게 할 수가 없습니다. 터치스크린 상에서 클릭 없이 뭔가를 포인팅하는 것은 마우스오버가 아니지요. 그저 손가락을 허공상에서 움직이는 것과 마찬가지입니다. 기기가 인식하지 못하는 상황이죠.

또한 오른쪽-클릭에 의존하는 플래시 사이트도 있습니다. (보안설정과 같은 것을 위함이죠.) 물리적인 키보드를 요구하는 것도 있습니다. 특히 게임이 그러하죠. 플래시를 원하는 주된 이유 중 하나가 게임입니다. (비디오도 그럴 수 있겠지만, 비디오는 플래시 없이도 돌릴 수 있고, 그렇게 하는 사이트가 점차 늘어나고 있습니다. 플래시 비디오가 제일 아쉬울 곳은 아무래도 유튜브이겠죠.) 게임은 실질적인 키 컨트롤을 사용할 때가 종종 있습니다. 싱글 프레스(single press)와 롱홀드(long hold), 그리고 코딩(chording) 모두를 필요로 하죠. 가령 오른쪽 화살표를 누르고 있으면 계속 걸어갑니다. 이와 동시에 스페이스를 치면 불을 발사하는 식이죠. 위쪽 화살표를 치면 점프한다거나 위쪽 화살표를 계속 누르고 있으면 더 높게 점프하는 식입니다. 터치스크린 키보드는 그런 종류의 정확하고 빠른 동작을 할 수 없어요. 게다가 키보드가 게임 화면을 가리기도 할 겁니다. 터치스크린 상의 게임은 터치스크린에 어울리는 컨트롤을 넣어야 합니다.

The only potential “solutions” to the mouseover problem are terrible ones:

A) 최고의 경우: 모든 사이트의 모든 플래시 앱을 프로그래머들이 다시 디자인하고 코딩하는 것입니다. 터치스크린을 위해서이죠. 마우스오버를 더 이상 사용하지 않거나, 아예 이중 버전으로 해놓으면 되겠죠. 마우스오버가 필요한 경우 마우스를 사용할 수 있도록 말입니다. 상당한 작업이 필요할 것입니다. 수만 곳이 해야 할 일이죠. 즉, 불가능합니다. 게다가 마우스오버가 너무나 근본적이어서, 사이트 개념 자체를 바꿔야 할 곳도 많을 것입니다. 기존 이용자들이 완전히 바뀐 사이트를 사용해야 하겠죠. (그런데 단순히 플래시를 없애고 하는 디자인보다 쉬울까요 과연? 꼭 그렇지도 않습니다.)

B) 제스쳐나 손가락 움직임, 외장형 버튼으로 마우스오버를 시뮬레이션하는 것입니다. 마우스오버는 그 자체가 클릭/탭보다 더 간단하고 더 복잡하지 말아야 하기 때문에 멍청한 짓이죠. 자연스러워야 하며 새로 배울 필요도 없어야 합니다. 데스크톱을 쓰던 습관을 완전히 뒤바꿔서는 안되죠. 하지만 게임에 이르르면, 추가적인 수정도 결국 안돌아갈 겁니다. 빠르고 단순하게 반응해야 하니까요. 시뮬레이트 마우스오버 버튼을 누를 때가 언제인지, 손가락 세 개를 이용할 때가 언제인지를 기억해야 할 필요가 없어야 하는데 말입니다. 게임 자체가 매우 어려운 존재입니다. 그렇게 했다가는 재미를 상당히 빼앗아가겠죠.

C) 클릭 자체를 근본적으로, 끊임 없이 사용하는 것으로 보다 복잡하게 만드는 방안이 있습니다. 무엇이든 등록하기 전에, 더블-탭이나 두 손가락 탭을 필요로 하는 것이죠. (투 탭은 현재 모바일 사파리가 자바스크립트 팝업메뉴에 대해 사용하는 방식입니다. 첫 번째 탭을 하면 메뉴가 뜨고, 두 번째 탭으로는 메뉴를 선택하지요.) 하지만 플래시 앱과 게임 다수는 이미 더블-클릭(혹은 빠른 클릭)을 나름대로 목적으로 사용하고 있습니다. 별도의 탭은 특정 상황(메뉴 팝업)에서만 쓸모있을 따름이죠. 단순한 클릭도 아닙니다. 움직여줘야 합니다. 드래그 대 마우스오버 움직이기랄 수 있겠네요. 게임중에 시스템이 이 모든 것을 빠르고 단순하게 해낼 수 있다 하더라도, 특별한 규칙을 웹페이지의 어느 부분에 적용하는지 이용자가 어떻게 알 수 있을까요? 페이지의 일부는 스크롤이나 링크-클릭을 제대로 하고 다른 곳은 완전히 다르게 한다면요? (터치-기반의 앱이 어떻게 될지는 고사하고 말이죠.)

D) 손가락 근처에 눈에 보이는 마우스 포인터를 갖다 놓고, 직접적으로 인터랙트하지 않는 방안이 있습니다. 애플의 트랙패드 스타일이죠. VNC 클라이언트에서도 보이는 탭-드래그 제스쳐를 사용하는 겁니다. 이런 간적 컨트롤은 직접적인 터치형 조작의 원칙을 뒤흔들게 됩니다. 터치스크린이 "노트북"처럼, 그리고 노트북보다 더 안좋게 변하는 것이죠. 굳이 터치스크린을 쓸 이유가 사라지는 겁니다. 다시 말씀드리건데, 이 경우, 페이지의 어느 부분이 직접적인 터치모드인지, 아니면 "화살표 드래그" 모드인지를 계속 기억하고 있어야 합니다.

E) "리얼" 탭을 별도로 요구하는 방안이 있습니다. 즉, 가벼운 탭과 무거운 탭을 구분지어야 하게 되겠죠. 직관적이지 않아요. 오작동할 가능성도 높아집니다. (단순한 클릭만으로도 RIM 블랙베리 SurePress 실험이 실패했었습니다.) 브라우저 플러그인 하나 때문에 전체 기기를 복잡하게 만들어버리는 겁니다. 비용도 더 비싸지고요.

따라서 애플이 그냥 플래시를 거부한 것이 아닙니다. 논리적으로 지원을 할 수가 없어요. 손가락은 마우스가 아닙니다. 그런데 플래시 사이트들은 마우스 포인트(그리고 키보드)를 근본적인 방식으로 요구하는 디자인이죠. 언젠가는 바뀌겠죠. 모든 플래시 사이트를 터치스크린 친화적으로 바꿀 날이 올 겁니다만, 그렇다고 해서 지금 플래시 사이트가 돌아가지는 않을 겁니다.

성능이나 배터리 수명, 충돌 문제가 전혀 없다 하더라도(분명 문제가 있지요), 어느 회사의 터치스크린이건, 터치스크린용으로 현재의 플래시 사이트들을 제대로 즐길 수는 없을 겁니다. 불만을 가질만한 부분을 다 들어줄 수가 없어요.

그런데 저는 플래시 개발자입니다. 제가 만든 애니메이션 사이트가 최신 유행의 아이폰에서 안돌아갈 때 제 느낌이 어떻겠습니까! 그래서 전 WebKit의 CSS 애니메이션 기능을 이용하여 애니메이션을 새로 만들었습니다. 데스크톱 이용자들도 물론 adamsi.com에서 플래시를 보실 수 있죠. 아이폰 이용자들도 애니메이션을 볼 수 있습니다. 즉, 이 방식은 할 수 있는 방식입니다.

Morgan Adams, adamsimmersive
interactive design and games

Daniel Eran Dilger is the author of “Snow Leopard Server (Developer Reference),” a new book from Wiley available now from Amazon as a paperback or digital Kindle download.

An Adobe Flash developer on why the iPad can’t use Flash — RoughlyDrafted Magazine

위민복님이 번역한 글입니다.

0 0

로그인 후 추천 또는 비추천하실 수 있습니다.