윈도우용 애플리케이션과 게임의 버튼 상태 구분 차이

한참 전 인터페이스의 비활성 상태에 대해 이야기한 적 있습니다. 윈도우용 애플리케이션을 기준으로 버튼에는 활성 및 비활성 상태가 있습니다. 우리들이 늘 익숙하게 사용하는 여러 가지 애플리케이션은 버튼을 활성 및 비활성 상태로 제어하기 때문에 우리들은 버튼의 이런 의사소통에 그리 낯설지 않다고 생각합니다. 활성 상태의 버튼을 클릭할 수 있고 클릭하면 분명 그 버튼의 이름에 연관된 어떤 동작을 수행하리라 예상할 수 있습니다. 반면 비활성 상태의 버튼은 시각적으로 그 상태를 구분할 수 있고 클릭을 시도할 수는 있지만 버튼이 클릭 되지 않기 때문에 분명 마우스 버튼을 누르더라도 아무 일도 일어나지 않을 거라는 사실을 예상할 수 있습니다. 또한 비활성 상태의 버튼은 어떤 이유에 의해 버튼이 현재 비활성 상태가 되었을 것이기 때문에 그 이유를 제거하면 활성 상태로 만들어 클릭해 그 기능을 수행하게 만들 수 있으리라 예상할 수도 있습니다. 컴퓨터를 주로 사용하고 또 윈도우 기계에서 주로 일하는 사람들이 모여 있을 때 이런 버튼의 의사 표현 방법은 딱히 이상하지 않고 또 너무나 익숙한 나머지 비록 여전히 윈도우용 애플리케이션에 기반하기는 하지만 그 목적과 용도가 상당히 다른 게임 인터페이스를 설계할 때도 비슷한 접근을 하려고 하는데 사실 이를 이상한 접근이라고 보기는 어렵습니다.

그런데 현대에 게임을 플레이 하며 비활성 상태의 버튼을 만나기는 이전 시대보다 훨씬 어렵습니다. 오래 전에는 게임 애플리케이션이라도 윈도우 기반 애플리케이션의 버튼 문법과 같이 활성 상태 버튼과 비활성 상태 버튼을 사용하곤 했습니다. 하지만 게임은 점점 이런 의사소통 방법을 사용하지 않도록 변했는데 여기에는 비활성 상태 버튼이 가진 의사소통 상의 근본적인 문제가 있습니다. 비활성 상태인 버튼은 근본적으로 이 버튼을 클릭할 수 없기 때문에 버튼이 비활성 상태라는 사실을 인식할 수는 있지만 이 버튼이 비활성 상태인 이유를 인지하기는 어려울 겁니다. 위 스크린샷은 제가 여러 기계에 걸쳐 거의 모든 파일을 관리하는데 사용하는 퍼포스라는 형상관리도구에서 파일을 서브밋 - 다른 도구에서는 주로 커밋이라고 부름 - 하기 위해 서브밋 팝업을 연 상태인데 팝업 맨 아래 오른쪽을 보면 Submit, Save 버튼은 비활성 상태이고 Cancel 버튼만 활성 상태인 것을 볼 수 있습니다. 이런 인터페이스는 현재 서브밋과 세이브를 할 수 없는 상태이며 오직 취소만 가능하다는 사실을 직관적으로 전달해 줍니다. 하지만 어떻게 해야 서브밋과 세이브를 할 수 있는 상태로 만들 수 있는지에 대한 힌트를 주지는 않습니다. 사실 이 팝업 위쪽에 ‘Write a changelist description’이라는 메시지가 빨간색으로 표시되어 있는데 이 메시지가 빨간색으로 표시된 이유는 그 밑에 있는 텍스트박스에 아무 것도 입력하지 않았기 때문이고 이 메시지가 빨간색으로 나타나는 한 팝업 맨 아래쪽에 있는 Submit, Save 버튼은 활성화 되지 않습니다. 그런데 보시다시피 비활성화 된 버튼과 이들을 활성화 할 수 있는 힌트는 서로 팝업의 정 반대쪽에 흩어져 있어 이들이 서로 연관되어 있다는 사실을 직관적으로 인식하기 어렵습니다.

사실 이전 시대에는 이런 문제가 있다는 사실조차 널리 알려지지 않았던 것 같습니다. 여러 소프트웨어가 적극적으로 버튼이나 메뉴를 비활성 상태로 만들었고 딱히 이상하지 않았습니다. 하지만 시간이 흐르며 누군가가 어떤 메뉴가 비활성 상태여서 사용할 수 없는데 이를 활성화 할 방법을 모르겠다는 질문을 하기 시작하고 이런 질문이 쌓이자 인터페이스를 비활성 상태로 만드는 의사소통 방법이 사용자에게 충분한 힌트를 주지 못한다는 사실을 인식하게 됩니다. 비활성 상태의 인터페이스가 가진 가장 큰 문제는 사용자가 이 인터페이스로부터 힌트를 얻고 싶어도 근본적으로 인터페이스와 상호작용 할 수 없다는 점입니다. 앞서 소개한 오래된 글에서도 종종 이 사실을 잘 모르는 게임디자이너들이 비활성 상태로 표시되는 버튼을 만들어 놓고 이 버튼을 클릭하면 이 동작을 수행할 수 없는 이유를 표시해 달라고 요구하고 또 이를 곧이곧대로 알아들은 엔지니어는 비활성 상태의 버튼에는 그런 구현을 할 수 없다고 말하면서 어려운 상황에 종종 빠지곤 합니다. 앞서 소개한 퍼포스 클라이언트 프로그램은 대체로 전문가용 애플리케이션으로 분류되어 이런 의사소통을 상당히 불친절하게 하고 있지만 고객들이 불편함을 적극적으로 호소하지는 않는 것 같아 보입니다. 그래서 현대에도 오래된 인터페이스 설계 규칙이 얼마나 불편하게 동작하는지 사례를 찾을 때 상당히 유용하게 사용하고 있습니다. 하지만 현대에 소프트웨어를 만드는 우리들은, 그리고 전문가용 소프트웨어가 아닌 엔터테인먼트 용도의 소프트웨어를 만드는 우리들은 이런 식으로 행동해서는 안됩니다.

상황을 개선하는 한 가지 방법은 비활성 상태인 인터페이스와 가까운 곳에 왜 이 인터페이스가 비활성 상태인지, 그리고 이 인터페이스를 활성화 하려면 어떻게 해야 하는지 기입하는 것입니다. 위에서 퍼포스 앱의 서브밋 팝업에서 서브밋 버튼과 세이브 버튼이 비활성 상태인 이유가 이 버튼과는 아주 멀리 떨어진 곳에 적혀 있는 것은 좋은 접근이 아닙니다. 물론 이 경우는 애플리케이션이 전문가들을 타겟으로 하고 있음을 감안하면 그럴 수도 있긴 하겠지만 좀 더 잘 만들 수 있을 여지가 있습니다. 여기서는 서브밋 버튼과 세이브 버튼이 위쪽에 있는 디스크립션을 기입하지 않았기 때문에 비활성 상태라는 점을 설명해 보았는데 이전에 비해 이 버튼을 본 사용자가 이 두 버튼이 왜 비활성 상태인지 팝업 전체를 살펴보지 않고 파악할 수 있습니다. 그리고 이 상태를 해결하려면 이 팝업 어딘가에 있는 디스크립션을 기입해야만 한다는 사실 역시 파악할 수 있습니다. 하지만 이 개선 역시 썩 훌륭하지는 않은데 사용자에게 이유를 알려주어 이전 보다는 덜 불친절하지만 여전히 이 버튼을 활성 상태로 만들기 위해 해야 하는 일과 그 일에 해당하는 실제 텍스트박스는 여전히 아주 멀리 떨어져 있기 때문입니다. 그렇다고 이 비활성 상태인 버튼들을 활성 상태로 만드는데 필요한 텍스트박스를 버튼 가까이 가져올 시도를 하기도 쉽지 않은데 현재 내가 입력한 정보들을 최종 확인한 다음 서버로 보낸다는 팝업의 역할 상 이 버튼들과 텍스트박스를 가까운 곳에 두기는 쉽지 않습니다.

앞서 비활성 상태인 버튼 가까이 이 버튼들을 활성 상태로 만들 수 있는 방법과 비활성 상태인 원인을 표시해 주는 방법을 설명했는데 만약 이 방법을 수행할 인터페이스가 이 버튼들과 너무 멀리 떨어져 있다면 색상으로 힌트를 줄 수도 있습니다. 위 와이어프레임에서 비활성 상태인 서브밋 버튼과 세이브 버튼 왼편에 이 버튼들의 비활성 상태를 해결할 수 있는 방법을 안내했지만 실제로 이 행동을 해야 할 텍스트박스는 팝업의 반대쪽 끝에 있습니다. 이미 같은 메시지가 텍스트박스 위에 표시되어 있고 또 이 삭막한 팝업에서 색상을 가진 요소는 이 두 같은 메시지 밖에 없으므로 어쩌면 사용자는 버튼 왼편의 메시지와 팝업 맨 위에 있는 메시지가 서로 같은 메시지임을 눈치 채고 맨 위에 있는 텍스트박스에 관심을 가지기 시작할지도 모릅니다. 비활성 상태인 버튼과 이 버튼을 활성 상태로 바꾸는 방법 설명, 그리고 이 설명에 의해 실제로 조작해야 하는 텍스트박스를 가리키는 인터페이스를 서로 색상으로 연결해 문제를 완화하기는 했지만 썩 훌륭하지는 않습니다. 여전히 근본적으로 버튼을 활성 상태로 바꿀 수 있는 인터페이스가 실제 버튼과 너무 멀리 떨어져 있다는 점, 그리고 색상에 의한 표시는 저 색상을 구분할 수 있는 사람들에게는 전달될 수 있겠지만 저 색상을 구분할 수 없는 사람들에게는 강조는커녕 저 문구 자체를 효과적으로 팝업으로부터 제거해 버릴 수도 있습니다. 마치 다른 문구에 비해 더 강조하기 위해 빨간색으로 인쇄한 안내문의 글자들이 시간이 흐르며 자외선에 의해 변성되어 가장 중요한 빨간색 글씨는 희미해지고 나머지 검정 글자들만 온전히 남아 도대체 뭘 강조하려고 했는지 잘 알 수 없는 상태가 된 인쇄물과도 비슷합니다. 더 나은 방법을 검토해볼 필요가 있습니다.

게임 애플리케이션이 생각해낸 방법은 근본적으로 비활성 상태 버튼을 만들지 않는 것입니다. 게임은 앞서 소개한 퍼포스와 같이 전문가를 상대하는 애플리케이션과는 속성이나 이들을 사용할 고객들이 극적으로 다릅니다. 퍼포스 앱은 사용자가 비활성 상태인 버튼을 만나 이 버튼을 활성화 할 방법을 잘 모르겠다면 매뉴얼을 찾아보거나 검색해볼 가능성이 높습니다. 왜냐하면 이 앱을 사용해 자신의 업무를 처리해야만 하기 때문입니다. 사용 방법을 모른다고 해서 앱을 사용하기를 거부하면 일을 할 수가 없고 이는 여러 가지 문제를 일으킬 겁니다. 반면 게임은 같은 상황일 때 매뉴얼을 찾아보기를 기대하기는 거의 불가능합니다. 애초에 매뉴얼이 존재하지 않을 가능성이 높으며 매뉴얼로부터 사용자가 보고 있는 팝업을 표시한 행동을 키워드 모양으로 정확하게 인식해 검색하기를 기대하기도 대단히 어렵습니다. 그리고 이 상태를 방치하면 결국 고객은 이 행동을 포기하고 나아가 게임을 그만 둘 수도 있는데 이는 현대에 정말 정말 원하지 않는 상황입니다. 그래서 게임은 아예 버튼을 누를 수 없는 상황을 없애버리고 버튼을 누르기 전에 미리 결과를 안내하고 또 버튼을 눌렀을 때 일단 버튼이 눌린 다음 실행에 실패했음을 안내하는 방식을 주로 사용합니다.

퍼포스 클라이언트의 서브밋 팝업을 계속해서 예로 들어 보면 게임에서는 비록 조건을 만족하지 않아 서브밋과 세이브에 실패가 확실한 상황이라도 이 버튼들을 비활성 상태로 만들지 않습니다. 대신 먼저 버튼 주변 어딘가에 이 버튼을 클릭하더라도 버튼을 클릭할 때 예상한 동작이 실패할 거라는 사실을 미리 알려줍니다. 가령 재료 아이템 10개를 요구하는 제작 인터페이스가 있을 때 재료 아이템이 부족한 상태라면 ‘제작’ 버튼 주변 어딘가에 재료 아이템의 현재 수량과 목표 수량을 표시하고 수량이 부족하다는 점을 표시해 ‘제작’ 버튼을 클릭하더라도 제작이 실행되지 않을 거라는 사실을 미리 알려줍니다. 고객은 직관적으로 팝업 중간에 아이템 수량 표시가 빨간색으로 표시되어 있으면 제작 버튼을 클릭할 수 있는 상태이더라도 제작 버튼을 클릭하지 않고 팝업을 닫은 다음 재료를 더 확보하러 던전을 한 바퀴 더 돌라 갈 수 있습니다. 하지만 습관적으로 제작 버튼을 클릭하더라도 제작이 실행되지 않으며 재료가 부족하다는 메시지를 표시하는데 이를 통해 제작이 실행되지 않았고 또 왜 제작이 실행되지 않았는지를 버튼을 클릭할 때 바로 할 수 있습니다. 심지어 메시지가 빨리 사라져 메시지를 확인하지 못했다면 버튼을 반복해서 클릭해 같은 메시지를 다시 확인할 수도 있습니다. 온라인 게임은 초창기 MUG 시대부터 화면 중앙 상단에 메시지를 표시하는 규칙이 널리 굳어져 그 자리에 여러 가지 메시지를 표시하곤 하는데 윈도우용 애플리케이션에는 그런 규칙이 없어 위에 그려 놓은 가상의 퍼포스 서브밋 팝업은 메시지 대신 작은 메시지 팝업으로 서브밋에 실패했고 서브밋 하기 위한 조치를 말해주도록 해봤습니다.

하지만 분명 실행되지 않을 기능 버튼을 클릭할 수 있을 것처럼 만들어 놓고 이를 클릭해야만 이 조작에 실패하지 않을 수 있는 이유를 설명하는 것 역시 좋은 접근은 아닐 수 있습니다. 고객은 활성 상태인 버튼을 봤고 이는 그 행동을 할 수 있음을 의미한다고 게임 뿐 아니라 온갖 애플리케이션을 통해 학습해 왔기 때문입니다. 버튼 근처에 이 버튼을 클릭하는데 필요한 조건과 현황을 설명한다 하더라도 일단 버튼이 클릭할 수 있을 것처럼 보이는데 클릭하지 않을 이유가 없고 이는 고객을 실망시킬 가능성이 있습니다. 그래서 비록 게임에서는 앞서 설명한 여러 이유 때문에 비활성 상태 버튼을 사용하지 않는 쪽으로 인터페이스가 발전해 온 연장으로 기술적으로는 똑같이 활성 상태이지만 버튼을 클릭할 때 동작을 수행할 수 있는 상태와 그렇지 않은 상태를 미리 구분해 같은 활성 상태에서도 시각적으로 구분하는 방법을 사용합니다. 위 그림에서 서브밋 버튼가 세이브 버튼이 어둡게 표시되어 있는데 이들은 비활성 상태와는 다릅니다. 비활성 상태는 애초에 운영체제나 프레임워크 수준에서 이벤트를 전달해 주지 않아 버튼이 클릭 되지 않을 뿐 아니라 유저가 버튼 클릭을 시도했다는 사실 자체를 인식하기 아주 어렵지만 이번에는 똑같은 활성 상태의 버튼이지만 그저 버튼을 좀 어둡게 표시해 놓았을 뿐입니다. 고객은 버튼 상태를 보고 버튼을 클릭할 때 원하는 동작이 수행되지 않을 거라는 사실을 직관적으로 예측할 수 있고 이 상태는 클릭 할 수는 있는 활성 상태와 시각적으로 구분되어 덜 실망할 수 있습니다.

앞서 게임은 초창기 MUG 시대부터 이전 MUD 시대에 메시지를 프롬프트 근처에 표시하던 규칙을 그대로 가져와 윈도우 인터페이스에서는 전혀 사용하지 않는 인터페이스와 관계 없는 고정된 위치에 메시지를 표시하는 방법이 별로 어색하지 않다는 이야기를 했습니다. 가령 게임 화면 중앙 상단에 가끔 노란색으로 ‘안녕하세요. 운영자입니다.’로 시작하는 점검 공지가 튀어나와도 딱히 이상하지 않다고 생각할 겁니다. 반대로 만약 윈도우 운영체제나 윈도우용 애플리케이션이 비슷한 동작을 하면 굉장히 당혹스러울 테고요. 게임에서는 이런 방식을 사용할 수 있기에 활성 상태이지만 어둡게 표시된 버튼으로 이미 이 버튼을 클릭하더라도 동작에 실패할 것임을 예상할 수 있게 해 줄 뿐 아니라 버튼을 클릭할 때마다 딱 봐도 이 버튼 때문에 메시지가 나타나는 것이 확실해 보이는 자유로운 위치에 메시지를 표시하고 또 버튼을 연속해서 클릭할 때마다 메시지가 반복해서 표시되고 있음을 자연스럽게 표현하고 있습니다. 이런 동작은 윈도우 애플리케이션 입장에서는 상당히 당혹스러울 수 있지만 게임 인터페이스에서는 화면 중앙 상단에 표시되는 메시지와 비슷한 맥락으로 비교적 자유롭게 사용하고 있고 고객들도 이런 동작이 딱히 이상하다고 생각하지는 않는 것 같아 보입니다. 덕분에 비활성 상태 버튼을 완전히 사용하지 않고 또 버튼을 클릭할 수 있으면서도 기능이 수행되지 않을 거라는 사실을 예상할 수 있는 시각적 표현을 하며 버튼을 클릭할 때 버튼 가까이에 이 상태를 해결할 수 있는 방법을 안내해 고객들이 매뉴얼을 찾아볼 생각이 전혀 없으면서도 막다른 길을 마주하지 않도록 하고 있습니다.

제목으로 돌아가 ‘윈도우용 애플리케이션과 게임의 버튼 상태 구분 차이’는 크게 세 가지입니다. 첫째. 인터페이스의 비활성 상태를 사용하지 않습니다. 비활성 상태는 이 기능을 사용할 수 없음을 잘 전달할 수 있는 방법이지만 이 기능을 사용할 수 있는 방법을 안내해 주지 않습니다. 이런 의사소통은 전문가용 소프트웨어라면 문제 없겠지만 게임 소프트웨어는 함부로 선택할 수 없는 방법입니다. 둘째. 조건을 만족하지 않아 실행에 실패할 인터페이스를 비활성 상태와는 다른 시각적 표현을 통해 나타내 버튼을 클릭하더라도 실행에 실패할 예정이라는 사실을 사용자에게 미리 전달하는 활성, 비활성 상태 구분과는 다른 활성 상태이면서도 버튼에 다른 시각적 표현을 추가하는 방법을 사용합니다. 셋째. 버튼을 클릭했지만 실행에 실패할 때 이 실행에 실패한 이유, 실패하지 않기 위해 해야 할 일 등을 버튼과 가까운 위치에 자유롭게 표시하고 또 버튼을 연속해서 클릭하는데 따라 메시지를 여러 번 표시하기도 합니다. 이는 과거 MUD 시대부터 프롬프트와 가까운 곳에 메시지가 표시되던 규칙을 현대에도 그대로 사용하고 있는 사례로 볼 수 있는데 윈도우 애플리케이션의 인터페이스 설계 관점에서는 좀 이상해 보일 수 있지만 게임 인터페이스 관점에서는 크게 이상하지 않습니다.