'Quasimode'에 해당되는 글 1건

  1. 2011.02.15 New Shiny Button, Only for Voice UI (11)

휴대폰용 음성 사용자 인터페이스를 해보겠노라고 동분서주할 때다. 아직 휴대폰에 터치스크린을 붙인다는 생각은 "대표적인 실패사례"로 꼽히고 있었고, "그게 단가가 얼만지 아느냐"며 이미 십여개 붙어있는 버튼에 하나를 더 추가하는 것도 위아래로 줄줄이 윤허를 받자와야 하던 무렵. 당시 나에게 소원이 하나 있다면 음성인식 전용의 버튼을 하나 넣는 거 였다.


(1) EPD Techniques
음성인식의 적확율을 좌우하는 것 중 가장 큰 것이 음성명령의 맨앞과 맨뒤를 찾아내는 작업, 즉 EPD(End-Point Dectection)이다. 아무리 좋은 음성인식 엔진도 앞뒤로 요상한 음운이 들어가 버리면 엉뚱한 결과를 낼 수밖에 없기 때문이다.

(1-1) Pause Detection
EPD를 기술적으로 해결하는 대표적인 방식은 역시 말이 없는 순간(pause)을 잡아내는 거다. 아무래도 사람은 무슨 말이 "명령"이라고 생각할 때 앞뒤로 pause를 넣게 되니까. 하지만 주변이 시끄럽다든가 하면 이 pause가 인식되지 않을 수도 있고, 무엇보다 굳이 명령을 하지 않더라도 말하다보면 수시로 발생하는 게 pause다. (노홍철씨는 예외적인 경우로 치자 -_- )

(1-2) Magic Word Detection
그래서 나온 것이 소위 magic word 방식. 무식하게 철저하지만 오직 한 단어만을 인식하는 인식기를 한켠에 돌리고 있다가, 그 단어가 인식되면 그 이후 일정기간 동안 입력된 음성을 명령으로 보고 검증하는 것이다. 최근 Microsoft Kinect에서 음성인식을 플랫폼 범위로 적용하면서 "엑스박스"를 매직워드로 설정한 게 이 경우에 해당한다. 음성명령을 내릴 때마다 같은 단어를 말해야 한다는 사실이, 안 그래도 (의외로) 수고스러운 음성인식 작업에 짜증을 가중시키기는 한다.

(1-3) Prompt Sound
조금 더 수동적인 해결안으로는 prompt 방식이 있다. 음성명령을 받아야 할 때마다 "삐ㅡ" 소리를 넣어서 사용자가 발화를 시작해야 하는 시점을 알려주는 것이다. 초기의 음성인식 ARS 시스템(혹은, IVR 시스템)이 이런 방식을 많이 썼다. 사용자 입장에서도 오랫동안 익숙해진 자동응답기와의 대화("삐 소리가 나면 녹음하세요.")와 유사한 멘탈모델을 제공해 주었기 때문에 큰 거부감 없이 받아들였지만, 사실 말하고 싶은 것이 머릿속에 빙빙 도는 데 허가(프롬프트)가 떨어질 때까지 말하지 못하는 것은 나름 상당히 괴로운 일이다. (여기에 사용되는 sound prompt를 어떻게 만드느냐도 이 음성대화 시스템의 사용성에 큰 영향을 미치는데, 이 글은 버튼에 대한 내용이니 일단 넘어가기로 하자.)

(1-4) Others
정확한 EPD를 위해서 시도된 방법들 중에는, 사용자 관점에서 지켜봐야 하는 사람에게는 참 당혹스러운 게 많았다. 심지어 음성명령 직전에 박수를 친다든가, 매직워드를 앞뒤로 넣는다든가 하는 방식도 정확한 인식에 도움은 됐을지 몰라도, 사람을 기술에 끼워 맞추는 전형적인 방법이고 일종의 '고문'에 가까왔다.


(2) "Voice" Button
그런 온갖 기법들을 한편으론 직접 시도해보거나 어깨너머로 보면서, 개인적으로 내린 최적의 EPD 기법은 어이없게도 그냥 누르는 버튼이다. 정확히는 Push-to-talk 버튼. 예전 워키토키처럼, 말하고 싶은 동안 누르고 있다가 말이 끝나면 떼면 되는 방식이다. 앞에서 말한 자동응답기보다 오래된 멘탈모델이고, 큰 회의실에서 발언권을 얻을 때 아직도 사용되고 있으며, 또 실제로 적용해봐도 꽤 자연스러운 방식이다.

그냥 버튼이 눌린 동안만 음성을 받으면 되는 것이니 EPD라고 논할 건 없어 보이는 게 사실이다. 하지만 실제 사용자들의 행동에서는 버튼이 눌리고 음성인식 엔진이 구동되는 그 짧은 순간을 앞질러 말하거나, 마지막 말의 음운이 마무리되기 전에 버튼에서 손을 떼는 경우가 많기 때문에 앞뒤로 약간의 buffer를 주고 여기에 기존의 EPD 기술(1-1)을 적용하는 게 좋다. 이 방식을 주장했을 때 가장 큰 장애물은 그 기술적 난이도가 아니라, 오히려 "그건 내노라할 기술이 아니다"는 거였다. 물론 조직의 목적에 따르자면 어쩔 수 없는 반응이었지만.

이렇게 음성버튼을 채용할 때 가질 수 있는 최대의 장점은, 기존의 GUI나 다른 조작과 병렬적으로 사용할 수 있다는 것이다. 이를테면 일상적인 전화번호부 화면을 띄워놓고 작업하다가, 음성검색이 필요할 때에 별도의 GUI 조작을 하지 않고 바로 버튼을 눌러 음성을 입력할 수 있다.

또한, 버튼을 누르고 "있어야" 한다는 것은 Jef Raskin이 주창한 바 있는 일명 quasimode로, 모드 분리에 따른 사용자의 인식오류 문제를 대부분 해결할 수 있는 장점도 있다.

... 그렇게 Graphical UI와 Voice UI를 자유자재로 오가면서 사용할 수 있는 multi-modal interaction을 입에 달고 지냈던 때가 있었다.


(3) Voice Button FAIL
하지만 앞에서 말한 바와 같이, 버튼 하나 더 우겨넣기 힘든 게 현실이었기 때문에 결국 기존에 있는 버튼을 길게 누르는 것으로 음성인식 "모드"를 넣는 것으로 되었고, 결국 사용성 문제를 발생시키는 대표주자인 이 "모드" 덕택에 음성버튼 컨셉은 안그래도 천덕꾸러기 신세였던 음성UI와 함께 그냥 사그라져 버렸다. 달랑 하나의 모델에만 적용되는가 싶더니 그대로 소리소문없이 사장되어 버렸으니까.


(4) Voice Button on Motorola Droid Pro
모토롤라에서 미국과 유럽에 Droid Pro, 혹은 Motorola Pro라는 모델을 출시한다고 한다. 업무용 휴대폰이면서도 개인용도의 사용을 동시에 고려했다고 하는데, 화면이 크면서도 블랙베리에서 보던 방식의 키보드를 채용했다. ... 아니, 정확히 말하자면 블랙베리 키보드에 버튼을 하나 더 추가했다.

Voice Button on Motorola Pro

저 위치의 마이크 버튼은 분명 이전에 안드로이드 폰들에서 발견된 터치스크린용 가상키보드의 음성인식 아이콘을 따라한 것이다. 그러니 십중팔구 그 기능도 앞에서 상상한 것처럼 아무때나 음성인식을 할 수 있기보다는 그냥 특정한 음성인식 모듈을 띄워주는 형태가 되리라 생각한다. 아무래도 안드로이드 기본 UI와의 충돌도 고려해야 할테고.

혹시 물리적인 QWERTY 키보드가 달린 안드로이드 휴대폰들에는 원래 음성인식 키가 들어가 있었던 건가 싶어서 이전 모델들을 닥치는대로 찾아봤지만, 화면상의 버튼이 아닌 물리적인 음성버튼을 채용한 것은 아마도 이 휴대폰이 최초인 것같다. Voice UI에 관심을 가진 입장에서는 나름 고무적인 사건이 아닐 수 없다! :)


어쨋든 이 버튼을 보자마자, 이제 휴대기기에서의 음성인식 버튼이 이런 식으로 "통화"나 "홈" 버튼만큼 일반화되고, 기기를 사용하는 중에 음성 UI를 사용할 수 있는 순간이 오면 저 마이크 모양에 불이 들어오고, 그럴 때는 버튼을 누른채로 말 한마디해서 쉽게 주소록 검색이나 일정 입력을 할 수 있으면 좋겠다... 뭐 그런 생각이 들어서 반가운 마음에 예전 기억을 주절주절 늘어놔 봤다.


이건 뭐 뒷방노인네도 아니고... 비맞은 중도 아니고... ㅡ_ㅡa;;;
Posted by Stan1ey

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절

  1. 2011.02.15 16:45
    댓글 주소 수정/삭제 댓글
    하드키뿐 아니라 요즘 구글,네이버,다음 음성검색에 쓰이는 GUI 음성 버튼도 말씀하신것처럼 음식인식모드를 시작하는게 아니라 pushtotalk 방식으로 되어야 한다고 생각해요.

    안드로이드 키보드의 음성인식 버튼도 그렇게 바뀌어야하고요. 근데 굳이 새로운 방식을 바꾸지 않고도 tap(짧게 손을 떼면)인 경우는 현재처럼 음성인식 모드를 시작하고 hold 시는 바로 음성 인식을 하도록 하면 기존 방식을 학습한 고객도 불편은 없을 것 같습니다. 모드없는 pushtotalk방식이 편하니까 알면 잘 쓰겠고요.
  2. 2011.02.15 16:58
    댓글 주소 수정/삭제 댓글
    안드로이드폰의 활용도가 낮은 하단의 검색키를 quasimode 음성검색버튼으로 쓰도록 하면 쓸모가 있을 것 같아요.
  3. 2011.02.15 17:06
    댓글 주소 수정/삭제 댓글
    라고 쓰고 테스트해보니 검색키를 길게 누르면(딜레이가 있는 방식) 음성검색 모드로 바로 진입하는 군요. :)
    • 2011.02.15 18:07
      댓글 주소 수정/삭제
      기존 버튼을 길게 누르는 방식의 사용하면 바로 그 딜레이가 문제가 되더군요. 사람에 따라서 버튼을 누를 때 눌렀다가 떼는 시간이 차이가 많아서, 특히 모바일 제품처럼 일일히 사용자 설정을 넣을 수 없는 경우엔 결국 대다수 사용자가 수용할 수 있는 threshold를 설정하게 되거든요. 그 시간만큼이 Hold 라고 판단하기까지의 시간이 되는 거죠.

      이상적으로는 그렇게 시간지연이 있는 경우에는 버튼을 누르는 순간(물리버튼이든 터치든) 홀드 기능이 preview되어서 사용자가 확신을 갖고 기다리게 하면 좋겠는데(Key Down 이벤트를 Hold를 위한 roll-over처럼 쓴다는 느낌?), 그렇게 기존에 없는 이벤트를 만들기도 참 현실적인 장벽이 많습니다. ㅎㅎ

      그외에도 VUI 관점만 생각하면 인식기의 신호입력단만이라도 항시 띄워놓아서 로딩시간을 없애는 것도 주장해볼만 해요. 우리나라 포탈에서 제공하는 음성인식 서비스는 너무 구글을 벤치마킹한 것같습니다.

      역시 전 그냥 전용버튼 - 누르면 바로 말할 수 있는 - 이 좋아요. ^^* 하지만 버튼 하나에 별도의 이벤트 핸들링을 넣고, 심지어 즉각적인 음성입력을 위한 메모리를 할당하는 일은 현재 있는 회사 중에선 애플에서나 가능할 듯합니다.
    • 2011.02.15 18:10
      댓글 주소 수정/삭제
      참, 그리고 기존 Key를 쓸 경우에는 그 Key의 context를 검색대상과 연결시킬 수 있다는 점도 주요한 장점이긴 합니다. 통화버튼은 주소록 검색, 메뉴버튼은 네비게이션, 인터넷 버튼은 ... 뭐 그런 식으로요. 이런 것도 특허를 내놓은 사람이 있다는 게 문제라면 문제지만. (쿨럭 ;ㅁ; )
    • 2011.02.15 23:48
      댓글 주소 수정/삭제
      아. hold라는게 press시에 바로 음성 버퍼링을 시작하고 release하면 끝낸다는 의미로 사용했어요. tap(threshold 미만에 뗀경우)이면 버퍼링된걸 날리면 그만이니까요.

      중간에 설명하신 부분(얼마나 오래 눌러야하는지 사용자에게 cue를 주면 좋겠다)은 아이폰 네이버맵에 적용되어 있더라구요. 지도상에 아무데나 길게 누르면 출발지,도착지등을 지정할 수 있는 메뉴가 뜨는데 누르는동안 바가 차오르게 되어 있어요. 예전에 키패드를 사용하는 단말에서 제안했었는데 구현된걸 보니 썩 좋은지는 모르겠어요 :) 그냥 적당히 짧은게 좋은것 같아요.
    • 2011.02.16 04:12
      댓글 주소 수정/삭제
      정말 그렇게 할 수 있다면 좋겠는데요. 단순히 버튼 이벤트를 받아서 기능을 호출하는 수준을 넘어가면 아무래도 개발 단계의 어려움이라는 게 상당히 부각되더군요. (-_-;;)

      터치스크린 상에서의 hold indicator(?)는 Windows Pocket PC 시절에도 있었죠. 그때는 지금의 Windows Phone 7 같은 인터페이스를 뽑아줄 거라고는 상상도 못했네요. ^^;
  4. 2011.04.05 16:06
    댓글 주소 수정/삭제 댓글
    비밀댓글입니다
    • 2011.04.25 14:23 신고
      댓글 주소 수정/삭제
      ㅎㅎㅎ 그런 일이 있었구나. 글쎄, 그럴 날이 올지도 모르지.
  5. creep
    2011.04.13 19:19
    댓글 주소 수정/삭제 댓글
    잘 읽었어요.
    상당히 늦은 시점이긴 하지만 :-)
    • 2011.04.25 14:26 신고
      댓글 주소 수정/삭제
      http://youtu.be/-tyfxEl22Ac
      http://youtu.be/sEU83IiGTT4
      이 동영상? 결국 애플이 한 만큼은 적용이 됐네. 그 다음부터는 ROI 따지자면 안 나오는 작업일테니 뭐 삼성으로선 할 만큼 했다는 생각. 그런데 애플의 VUI 디자인은 매뉴얼에 써있는 것보다는 훨씬 깊이가 있는데, 갤럭시의 경우엔 어떻게 되어있으려나... :)


BLOG main image
by Stan1ey

카테고리

분류 전체보기 (347)
HTI in General (45)
User eXperience (11)
Voice UI (50)
Vision UI (14)
Gesture UI (25)
Tangible UI (28)
Robot UI (14)
Public UI (9)
Virtuality & Fun (56)
Visual Language (15)
sCRAP (70)

글 보관함



www.flickr.com
This is a Flickr badge showing public photos and videos from Stan1ey. Make your own badge here.