Intro
안녕하세요. MFC 카테고리의 꽃집총각 입니다.
지난 포스팅에서는 2회에 걸쳐 멀티터치 인터페이스의 비전과(사람이 기계와 만나는 진정한 방법 – 멀티터치), 멀티터치 프로그래밍을 하기 위한 환경 구축([멀티터치]멀티터치 프로그래밍 환경 구축하기)에 대해서 각각 알아보았습니다. 오늘부터는 실제로 터치 UX 프로그래밍을 하기 위한 내용들을 살펴보고자 합니다. 이제부터 점점 내용이 재미있어 지겠군요! 자 이제 시작하겠습니다!!
MSDN 매거진이나 channel9에 올라오는 article들을 보면, 응용 프로그램에 멀티터치 UX를 적용하는 방법을 3단계로 나누어 설명하고 있습니다.
- ‘Good’ step : 코딩하지 않아도 공짜로 얻을 수 있는 기능들.
- ‘Better’ step : 제스처(Gesture)를 이용해 멀티터치 프로그래밍 하기.
- ‘Best’ step : 원시 데이터(raw-data)를 직접 제어해, 가장 디테일한 터치 UX 구현하기.
위와 같이 터치 적용 수준에 따라 세 단계로 나누고, 각각의 단계에 Good / Better / Best 라는 이름을 붙이고 있습니다. 멀티터치 UX를 적용하는 좋은 방법, 더 좋은 방법, 가장 좋은 방법 정도가 되겠네요 ㅎ 단계성을 표현하려는 의도는 이해합니다만 조금 우습군요 (피식). 각 단계가 어떤 내용을 담고 있는지 하나씩 좀 더 자세하게 이야기해보도록 하겠습니다.
1. ‘Good’ step : 코딩하지 않아도 공짜로 얻는 터치 UX
우선 기본적으로 첫 번째 단계는, 소스코드를 손대지 않고도 얻을 수 있는 기본적인 터치 UX에 대한 내용입니다. 기본으로 제공되는 컨트롤들이 윈도우 7의 터치 인터페이스 환경에 맞게 버전업 되면서, 자체적으로 멀티터치 입력에 반응하는 기능들을 제공하게 되었습니다. 이런 기능들은 기존에 작성된 다수의 레거시(legacy) 프로그램에도 그대로 적용됩니다. 다시 말해 예전에 제작했던 응용 프로그램이 별다른 호환성의 문제 없이 WIndows7에서 실행되기만 한다면 바로 얻을 수 있는 기능들입니다.
스크롤바의 스크롤 기능, 에디트 컨트롤의 화상키보드 호출기능, 윈도우 탐색기나 인터넷 익스플로러와 같은 프로그램의 네비게이션 기능 (쉽게 말해, ‘앞으로’, ‘뒤로’ 버튼 기능. WM_APPCOMMAND 메세지) 등이 그것입니다. 이런 것들은 직접 한 번 조작해 보시는 게 훨씬 나을 겁니다. 이전 글에서 소개해 드린 Multi-Touch Vista의 터치 인식 디바이스 드라이버를 구동하면 터치 입력을 시뮬레이션 해 볼 수 있으니까요 :) 윈도우 탐색기의 파일 리스트 영역에서 손가락을 좌/우로 빠르게 드래그 해주면 – 아이폰에서 사진을 넘기는 동작입니다. 뒷부분에 다시 정리하겠지만 Flicks 라는 이름의 제스쳐 입니다 – 이전 / 다음 버튼을 누른 것처럼 네비게이션 히스토리를 따라 경로가 변경됩니다.
윈도우 탐색기에서 왼쪽 –> 오른쪽으로 문지르는 Filcks 제스처를 실행한 모습.
윈도우 탐색기에서 오른쪽 -> 왼쪽으로 문지르는 Flicks 제스처를 실행한 모습.
스크린샷을 보시면 일반 아이콘 크기 정도의 ‘앞으로’, ‘뒤로’ 이미지가 손가락을 갖다 댄 곳에 잠시 나타나는 것을 보실 수 있습니다. 이렇게 되면서 윈도우 탐색기의 탐색 경로가 앞/뒤로 변경됩니다. 이 시점을 Spy++로 조회해 보니 WM_APPCOMMAND 메세지가 넘어오는군요. 이전에 작성된 응용 프로그램이 WM_APPCOMMAND 를 받아서 네비게이션 기능을 처리하고 있었다면, 윈도우 7에서 실행하는 것 만으로도 Flicks 터치 제스처를 얻게 되는 겁니다.
손가락 터치로 스크롤바의 스크롤이 가능하다는 사실은 제가 이미지 스크린샷을 찍어서 보여드릴 방법이 딱히 없군요 ^^; 이 부분은 직접 실행해서 확인해 주시길 부탁 드리면서 나머지 한가지만 더 같이 보기로 하죠. 메모장을 열어서 View 영역을 손가락으로 탭 해주면 위 스크린샷에서 보이는 것 같이 키보드 그림이 그려진 작은 윈도우가 잠깐 동안 노출됩니다. 이 녀석을 다시 탭 하면 터치로 텍스트를 입력할 수 있는 화상키보드가 화면에 나타납니다.
오… 요즘 인기를 얻고 있는 블록키보드 타입이군요. 먼지의 유입이 적고 간격이 넓어 오타가 줄어든다는 바로 그 방식 +_+ 아… 근데 어차피 화상 키보드라 아무 상관 없겠습니다…;;
이 화상키보드 호출 기능은 텍스트를 입력하는 방식의 컨트롤들이면 어느 곳에나 기본 구현되어 있습니다. 기본 에디트 컨트롤, 리치 에디트 컨트롤, IP Address 입력 컨트롤 등이 이에 해당됩니다. 텍스트를 입력할 수 있도록 캐럿이 깜박이는 방식의 인터페이스를 가진 컨트롤들이면 이미 화상키보드 호출 기능도 공짜로 얻게 된 겁니다. 윈도우 7에서 실행하기만 한다면 말이지요 :)
이런 기능들은 그저 공짜로 얻게 된 추가기능 치고는 꽤나 근사합니다. 하지만 모든 응용 프로그램에 공통 적용되는 사항이기 때문에 내가 만든 응용프로그램만의 고유한 기능이라기보다는 윈도우 7 OS의 새로운 기능이라고 보는 편이 더 적합합니다. 프로그램의 실제 사용자에게도 해당 기능들은 아주 당연한 인터페이스로 인식될 것이고, 금새 적응하게 될 것입니다.
그렇다면 좀 더 터치 인터페이스에 친화적인 응용 프로그램을 만들기 위해서는 어떻게 해야 할까요?
터치를 인식하도록 프로그래밍 하는 방법은 두 가지가 있습니다. 하나는 적은 수정비용으로 기본적인 동작들을 재빠르고 심플하게 구현하는 방법이고, 또 다른 한가지는 보다 강력하고 디테일한 움직임을 다루는 방법입니다. 이 두 가지 방법들을 각각 2. ‘Better’ step과 3. ‘Best’ step에서 이야기해 보도록 하겠습니다.
2. ‘Better’ step : 제스처(Gesture) 이용하기.
터치 UX를 응용 프로그램에 적용하는 두 번째 방법은 제스처(Gesture)를 이용하는 방법입니다. 여기에서 ‘제스처’란 터치 인터페이스를 통해 손으로 입력할 수 있는 한가지의 입력 패턴을 말합니다. 예를 들어 멀티터치라고 하면 가장 대표적으로 떠오르는 입력방식 중에 하나인 사진 확대/축소 방법은 두 손가락을 스크린에 갖다 대고 간격을 벌리거나 좁히는 식으로 주로 쓰입니다. MSDN에서는 이런 입력 방식을 Zoom이라는 이름의 제스처로 부르고 있습니다. 멀티터치는 앞으로도 다양한 제스처가 적절한 기능들과 보다 직관적으로 연결되어 확장해 나갈 수 있는 무한한 가능성을 가지고 있지요.
MSDN에 보면 (http://msdn.microsoft.com/en-us/library/dd940543(VS.85).aspx) 여러 가지 제스처들 중에서 가장 흔하고 쉽게 사용되는 대표적인 9가지 제스처에 대해 이름을 정의하고 있습니다.
이미지가 작아서 잘 안보이실 텐데요. MSDN 링크를 열고 보다 큰 이미지로 내용을 확인하시는 게 좋겠습니다. 비록 도표는 영어로 되어있지만 그다지 내용도 없을 뿐더러 Action 그림과 제스처 이름만 보면 대충 어떤 방식인지 직관적으로 이해하실 수 있습니다. 앞으로 제스처를 이용한 터치 프로그래밍을 구현하고자 하면 각 제스처의 이름을 자주 확인하게 될 테니 위의 도표는 꽤나 유용하게 쓰일겁니다. 한 번 정도는 눈여겨봐두시기 바랍니다.
제스처를 이용한 터치 구현 방법은 9가지 제스처가 입력된 경우 이에 따른 기능들이 실행되게 하는 것입니다. Windows 7은 기본적으로 터치 입력이 감지되면 위의 9가지 제스처에 해당하는지 여부를 자체적으로 판단합니다. 이에 해당하는 적절한 Gesture가 있을 경우 WM_GESTURE라는 메세지를 만들어 응용 프로그램에 전달해줍니다. 해당 메세지에는 각각의 제스처에 대한 좌표정보 등의 추가정보들이 적절하게 가공되어 제공됩니다. 이미 OS 자체에서 터치 인터페이스를 인식해서 한번 가공해둔 상태이기 때문에 프로그래머는 가벼운 마음으로 OS가 해석해준 좌표 정보나 수치 등을 활용해 기능을 연동하기만 하면 그만입니다. 그렇기 때문에 적은 수정 비용으로, 기본적인 제스처에 반응하는 기능들을 빠르게 구현할 수가 있는 점이 장점입니다.
만약 Win32 API만을 이용하여 프로그램을 만든다면 WndProc 에서 WM_GESTURE 메세지를 잡아서 이에 맞는 코드를 넣어주면 되고, MFC는 한층 더 간단하게 적절한 가상함수를 오버라이딩해서 코드를 넣어주면 되는 식이지요. 윈도우 메세지와 MFC 클래스의 가상함수를 재정의하는 구현 방식은 이미 우리가 오래도록 작업해 왔던 기존의 윈도우 프로그래밍 방법과 크게 다르지 않기 때문에 익숙하고 거부감이 없습니다. 보다 자세한 구현 방법은 다음 포스팅에서 계속 이어 나가도록 하겠습니다.
제스처를 이용한 구현 방법은 ‘적은 수정 비용으로 기본적인 동작의 구현을 빠르게 만드는 방향’에 초점을 둔 방식입니다. 저수준 단위의 터치 입력 데이터를 프로그래머가 일일이 분석해서 제스처의 패턴을 파악하지 않아도 됩니다.
하지만 이런 일반적인 제스처 말고 색다른 입력 방식을 구현해야 할 경우도 있을 겁니다. 기존에 없었던 독특한 방식의 제스처를 새롭게 만들고 싶을 수도 있습니다. 혹은 마치 실제로 손가락을 이용해 도화지에 그림을 그리듯 매우 디테일한 레벨의 컨트롤을 구현하고 싶을 수도 있습니다. TED 강연에서 제프한 박사가 보여준 독특한 형태의 멀티터치 데모라던가, Microsoft Surface에서 처리하듯이 화면의 Widget을 직접 손으로 만지는 것 같은 직관적인 움직임을 구현하고 싶을 수도 있습니다. 이런 경우에는 제스처를 이용한 구현방법을 적용하기에는 무리가 있습니다.
그렇다면 그러한 고급 수준의 터치 인터페이스를 구현하려면 어떻게 해야 할까요?
그것을 다음 단계인 3 ‘Best’ step이 설명하고 있습니다 :)
3. ‘Best’ step : 가장 디테일한 터치 UX를 구현하는 방법.
마지막 단계인 3. ‘Best’ step에서는 가장 세밀하고 유연한 터치 인터페이스를 만들 수 있는 방법을 제시하고 있습니다. 2단계에서처럼 윈도우가 자체적으로 터치 메세지를 가공하는 방식이 아니라, 아무 처리도 거치지 않은 원시 터치 데이터(Row Touch Data)를 응용 프로그램으로 직접 넘겨주게 설정하고(WM_TOUCH 메세지), 개발자 스스로가 이를 이용해 저레벨 수준의 구현 부터 직접 담당하는 방식입니다. 이런 식이라면 아무래도 제스처를 이용한 방법 보다는 신경써야 할 부분이 많아지고 구현이 좀 더 까다로워지는 점이 있습니다. 제스처를 이용한 구현방식이 적은 수정비용으로 빠른 구현을 꾀한 방향이었다면, 원시 데이터를 직접 활용하는 방법은 조금 까다롭더라도 고수준의 인터페이스를 구현하는 것에 초점을 두고 있습니다. Microsoft Surface 처럼 말이지요.
Microsoft Surface ® (이미지 출처 : http://cyberimpacts.com/)
이러한 low-level의 터치 데이터는 WM_TOUCH라는 새로운 윈도우 메세지를 통해서 넘겨받을 수 있습니다. 역시 기존의 다른 윈도우 메세지를 처리해오던 것처럼 WndProc에서 메세지를 받아서 코드를 넣어주면 됩니다. WM_TOUCH는 WM_MOUSE… 계열의 마우스 메세지와 유사합니다. 이를 활용하는 방법 역시 차례대로 다음 포스팅에서 보다 자세히 알아 보도록 하겠습니다.
Outro
이번 포스팅에서는 드디어 멀티터치 프로그래밍을 하기 위한 단계적 방법들과 몇 가지 개념들, 용어들에 대해서 정리해 보았습니다. 아직까지도 소스코드나 api들의 직접적인 설명은 없었지만 오늘 알아본 내용들을 통해 터치 UX를 구현하기 위한 전반적인 방향들은 어느 정도 체계가 잡히셨을 거라고 생각합니다.
다음 포스팅에서는 WM_GESTURE를 이용한 방법부터 시작해서 WM_TOUCH를 이용하는 방법까지 순서대로 멀티터치 관련 API들과 활용 방법들을 정리해 보도록 하겠습니다. Win32 API를 이용하는 방법과 MFC를 이용하는 방법들을 소개할 예정이니 참고해 주세요.
그럼 빠른 시간 안에 다음 내용을 가지고 다시 인사 드리도록 하겠습니다. 화창한 봄날인데 너무 모니터 앞에만 앉아있지 마시고 봄기운 가득 느끼시면서 재충전 하는 시간들 가져보시기 바랍니다 ^^
감사합니다 ^^*
reference
'Windows 7' 카테고리의 다른 글
[멀티터치]멀티터치 프로그래밍 환경 구축하기 (9) | 2010.04.05 |
---|---|
사람이 기계와 만나는 진정한 방법 - 멀티터치 (2) | 2010.03.29 |
[Windows7] Win32를 이용해 윈도우7 멀티터치 프로그래밍하기 (0) | 2010.03.14 |
Windows 7을 위한 Windows XP 모드 (2) | 2009.04.27 |
Windows SDK 설치 후 XAML 인텔리센스 문제 (0) | 2009.04.16 |