| 13장 | | | 13:1 데이터 입력란에서 필수 사항과 선택 사항의 구별 |
|
13:1 데이터 입력란에서 필수 사항과 선택 사항의 구별
(상대적 중요도: 5, 증거의 강도: 3)
지침 : 데이터 입력란에서 필수 입력 사항과 선택 입력 사항을 명확하고 일관되게 구분하라.
주석 : 사용자들은 어떤 데이터 입력란이 필수 사항이고 선택 사항인지 쉽게 판단할 수 있어야 한다. 많은 웹사이트들이 현재 필수 입력란 레이블 앞에 별표(*)를 사용하고 있다. 다른 사이트들은 레이블 옆에 "필수"라는 단어를 붙이고 있다. 한 연구에 의하면 필수 입력란을 표시하는데 있어 갈매기(chevrons, >>>), 체크표시(checkmarks), 색상보다 강조체 텍스트를 선호하는 것으로 밝혀졌다. 역주 : 한글 웹사이트에서는 데이터 입력란(폼)이 있을때 위에 "*표시가 붙은 사항은 필수 입력 사항입니다"등의 문구를 넣고 *를 각 사항 레이블 앞에 붙이는게 일반적인듯 하다. 지침의 핵심은 선택 사항과 필수 사항을 사용자가 쉽게 구별할 수 있어야 한다는 것이고 현재의 관례는 큰 문제가 없다고 본다. *에 빨간 색등을 써서 눈에 띄게 해주면 사용성은 더 높아질 것이다. |
| 13장 | | | 13:2 에러 검출의 자동화 |
|
13:2 에러 검출의 자동화
(상대적 중요도: 5, 증거의 강도: 3)
지침 : 사용자에 의해 만들어진 에러는 컴퓨터가 검출하도록 하라.
주석 : 사용자가 입력란을 수정할 것이라고 기대해서는 안된다. 가능한 사용자 에러를 예상하여 컴퓨터가 이 에러들을 확인하고 맞는 것을 제시하도록 만들어야 한다. 예를 들어 날짜가 "2월 31일"로 입력되었을 때 컴퓨터는 입력 수정을 요청하는 에러메시지를 띄워야 한다. 어떤 사용자 입력란은 체크가 필요하지 않을 수 있으며 컴퓨터가 체크하기에 부적합할 수 있다. 역주 : 기본적인 에러는 입력 단계에서 컴퓨터에 의해 검출될 수 있으며 가능하다면 부정확한 입력 자체가 방지될 수 있도록 하는 것이 중요하다. 예컨데 우편 번호를 동명만 넣으면 자동으로 찾아주는 모듈은 지금은 당연한 것으로 여겨지나 결과적으로 사용성 증대에 획기적인 기여를 했다고 볼 수 있다. 가이드에서 제시하는 구글의 "이것을 원하셨습니까?(Did you mean?)" 역시 사용성 증대를 가져오는 사례의 하나이다.
|
| 13장 | | | 13:3 사용자 입력의 최소화 |
|
13:3 사용자 입력의 최소화
(상대적 중요도: 5, 증거의 강도: 3)
지침 : 사용자에게 동일한 정보를 한 번 이상 입력하도록 요구하지 말라.
주석 : 데이터를 재입력하도록 요구하는 것은 사용자에게 추가적인 작업을 부과하는 것이며 입력 오류의 가능성이 높아지게 된다. 페이지에서 사용자에 의해 입력된 사항들이 다른 페이지에서도 필요할 경우 동일한 정보를 재입력하도록 할 것이 아니라 컴퓨터가 이미 입력된 사항들을 다시 입력하도록 하여야 한다. 일반적으로 가능한 한 사용자에 대한 입력 요구를 최소화하여야 한다. 역주 : 계속 지적해 온 문제지만 시장 경쟁 아래에 있는 사이트들은 동 지침과 같은 사용성 문제들에 대해 자발적으로 신속히 해결책을 도입하고 개선해 나가기 마련이다. 그렇지 않은 사이트는 당연히 도태되거나 경쟁에서 밀리기 때문이다. 예컨데 쇼핑몰 사이트들이 그러하다. 그러나 그렇지 않은 공공 부문이나 관련 사이트들은 여전히 불편한 것 또한 사실이다. 가이드에서 제시하고 있는 ''아이디 기억 옵션''의 제공 사례는 보안 문제 때문에 최근에 대형 포털에서는 의도적으로 빼고 있는 것으로 보이나 편의를 도모해주는 대표적인 방안의 하나이다.
|
| 13장 | | | 13:4 데이터 입력란의 명확한 레이블 |
|
13:4 데이터 입력란의 명확한 레이블
(상대적 중요도: 5, 증거의 강도: 3)
지침 : 각 데이터 입력란의 레이블은 사용자가 무엇을 입력해야 하는지 이해할 수 있게 표현하도록 하라.
주석 : 입력란을 표현하는 명확하고 간결하며 애매모호하지 않은 설명력있는 레이블을 만들어야 한다. 레이블은 충분히 식별이 가능하여 사용자가 데이터 입력란 자체와 혼동을 일으키지 않도록 해야 한다. 이는 레이블을 강조체로 쓰거나(bolding) 별표(*)와 같은 시각적인 실마리를 제공함으로써 가능하다.
데이터 입력란에 레이블링 할 때 새로운 용어(jargon)를 만들지 않도록 한다. 보통 용어(예컨데 남성, 여성)를 사용하고 작위적인 레이블(예컨데 그룹1, 그룹2)은 사용하지 않는다. 선택한 레이블의 의미가 의심스러울 때는 적절한 수의 선별된 사용자 샘플을 이용하여 사용성 테스트를 수행한다. 역주 : 기획자가 책임져야 할 지침이다.
|
| 13장 | | | 13:5 레이블은 데이터 입력란 가까이 |
|
13:5 레이블은 데이터 입력란 가까이
(상대적 중요도: 5, 증거의 강도: 2)
지침 : 레이블은 해당 데이터 입력란에 충분히 붙여 써서 사용자들이 레이블이 데이터 입력란을 설명한다는 것을 알게 하라.
주석 : 모든 레이블과 관련 정보는 데이터 입력란에 붙여 써서 사용자들이 레이블과 해당 입력란이 관련된다는 것을 알 수 있어야 한다.
[아래는 레이블을 붙여 써서 파악이 쉬운 사례이다] 
[아래는 레이블을 붙여 쓰지 않아서 입력 속도가 느려지는 사례이다]  |
| 13장 | | | 13:6 누르는 버튼의 명확한 레이블 |
|
13:6 누르는 버튼의 명확한 레이블
(상대적 중요도: 4, 증거의 강도: 2)
지침 : 누르는 버튼의 레이블은 그 용도를 명확히 표시하도록 하라.
주석 : 누르는 버튼의 레이블은 버튼을 클릭했을 때 적용되는 용도를 명확하게 표시하여야 한다. 자주 보는 누르는 버튼의 레이블은 "Update", "Go", "Submit", "Cancel", "Enter", "Home", "Next", "Previous"등이 있다. 역주 : 한글 웹사이트의 누르기 버튼중 흔하게 볼 수 있는 것은 "확인", "취소", "검색", "찾기", "홈", "제출"등이 있다. 그러나 버튼 레이블은 수백 수천 가지가 가능하며 상기의 것만 가능한 것은 아니다. 동 지침의 목적은 ''용도의 명확한 표시''이며 한 단어로 불가능하다면 두 단어나 문구로 짧게 표현하는 것도 무방하다. 같은 맥락에서 관용화되어 쓰고 있다고 판단되는 레이블은 따라서 쓰는 것도 중요하다.
|
| 13장 | | | 13:7 데이터 입력란의 일관된 레이블 |
|
13:7 데이터 입력란의 일관된 레이블
(상대적 중요도: 4, 증거의 강도: 3)
지침 : 데이터 입력란 레이블은 일관된 용어로 써서 동일한 데이터 항목이 다른 페이지에 나오더라도 동일한 레이블을 갖도록 하라.
주석 : 가능하다면 일관된 레이블 사용 관례를 만들어야 한다. 예를 들어 어떤 레이블에는 한 개의 단어나 문구를 쓰고 다른 레이블에서는 짧은 문장을 쓰거나, 한 쪽에는 동사를 쓰고 다른 쪽에는 명사를 써서는 안된다. 역주 : 한 사람이 작성하는 경우 이런 경우는 드물지만 팀 작업시, 혹은 담당자 교체시 이런 문제들이 발생할 수 있다.
|
| 13장 | | | 13:8 사용자들이 자신이 입력한 데이터를 볼 수 있을 것 |
|
13:8 사용자들이 자신이 입력한 데이터를 볼 수 있을 것
(상대적 중요도: 4, 증거의 강도: 3)
지침 : 데이터 입력란을 충분히 크게 만들어서 스크롤 없이도 입력한 데이터 전체를 볼 수 있게 하라.
주석 : 사용자들이 한 번에 자신이 입력한 것을 볼 수 있게 해야 한다. 스크롤 없이는 볼 수 없을 정도로 데이터를 많이 입력하는 사용자도 있게 마련인바 이 경우에도 입력란에 있는 모든 데이터를 보기 위해 스크롤이나 커서를 움직여야 하는 것을 최소화하여야 한다. 만일 특정 입력란에 글자수 제한이 있을 경우에는 입력란 옆에 이 제한을 명시하여야 한다. 역주 : 입력란이 작아서 사용자가 자신이 입력한 것이 맞는지 보기 위해 키보드 커서를 ''수평으로'' 움직여야 하는 경우가 종종 있다. 특히 사용자가 길게 입력해서가 아니라 항목의 성격상 길어질 수 있는 모 포털의 아이디나 메일 주소등의 경우는 더 문제이다. 이는 전적으로 입력란을 만든 프로그래머나 디자이너의 책임인바 변명의 여지 없이 즉각 수정하여야 한다. 가이드에서 제시하고 있는 아래 사례처럼 의견이나 메시지를 적는 란은 세로 스크롤을 써야 할 수도 있으나 이 경우에도 초기 데이터 입력란의 크기를 넉넉히 하여야 한다. 웹페이지의 가로 스크롤도 많은 불편을 주나 데이터 입력란이 협소하여 커서를 움직여야 하는 이 보다 더 큰 불편을 야기한다.
[아래 사례는 텍스트 박스에 세로 스크롤이 생기게 하여 많은 입력도 가능하게 만든 경우이다] 
[아래는 수평으로 커서를 움직여야 하는 경우로 가능하다면 절대 피해야 할 경우이다]  |
| 13장 | | | 13:9 초기값의 표시 |
|
13:9 초기값의 표시
(상대적 중요도: 4, 증거의 강도: 2)
지침 : 기본 선택을 정할 수 있으면 항상 초기값을 표시하라.
주석 : 초기값이 정해질 수 있다면 데이터 입력을 빠르게 하기 위해 그 값을 입력란에 미리 표시해 놓도록 한다. 초기값은 사용자가 가장 많이 선택하는 것일 수도 있고 가장 적게 선택하는 것일 수도 있다. 일반적으로 초기값 넣는 곳에 그 입력/선택란(widget)의 헤딩이나 레이블을 표시하지 않도록 한다.
[아래는 수량을 입력하는 입력란에 1이라는 초기값을 적어 넣었다] 
[아래는 공원을 선택하는 선택란에 아카디아 국립공원이라는 초기값을 넣었다]  |
| 13장 | | | 13:10 라디오 버튼은 최소 2개 사용 |
|
13:10 라디오 버튼은 최소 2개 사용
(상대적 중요도: 4, 증거의 강도: 2)
지침 : 라디오 버튼을 한개만 제공하지 말라.
주석 : 라디오 버튼은 적어도 2개 이상 같이 사용하여야 한다. 만일 사용자가 선택할 것이 하나도 없으면 "없음"이라는 레이블이 붙은 라디오 버튼을 제공하여야 한다. 역주 : 라디오 버튼의 정의 자체가 서로 배타적인 둘 이상의 선택에서 하나를 고르는 것이므로 만일 라디오 버튼이 하나라면 그것은 개념에 반한다.
|
| 13장 | | | 13:11 상호 배제적인 선택의 경우 라디오 버튼의 사용 |
|
13:11 상호 배제적인 선택의 경우 라디오 버튼의 사용
(상대적 중요도: 3, 증거의 강도: 2)
지침 : 사용자가 상호 배제적인 선택들에서 하나를 골라야 할 때는 라디어 버튼을 제공하라.
주석 : 라디어 버튼은 상호 배제적인 선택들 중에서 하나를 고를때 사용해야 한다. 사용자는 선택을 위해서 버튼이나 텍스트 레이블을 클릭할 수 있어야 한다. 라디어 버튼의 여러 선택항중에 하나를 초기값으로 할당해 놓도록 한다. 한 연구에 의하면 상호 배제적인 선택을 할 때 라디오 버튼이 드롭 다운 리스트보다 나은 수행성을 이끌어내었다고 한다. 라디어 버튼은 오픈 리스트나 드롭 다운 리스트보다 더 선호되고 있다. 역주 : 다음은 가이드에서 제시하는 사례이다. 사용자가 목록중에서 하나만 골라야 할 때는 체크 박스보다 라디오 버튼을 제공하는 것이 낫다.
|
| 13장 | | | 13:12 복수 선택을 가능하게 할 때 체크 박스의 사용 |
|
13:12 복수 선택을 가능하게 할 때 체크 박스의 사용
(상대적 중요도: 3, 증거의 강도: 3)
지침 : 사용자가 가능한 선택 목록 중에서 하나 이상의 선택을 하게 허용할 때는 체크 박스 콘트롤을 제공하라.
주석 : 각 체크 박스는 모든 다른 체크 박스와 독립적으로 선택이 가능해야 한다. 한 연구에 의하면 상호 비배제적인 목록에서 복수 선택을 할 때 체크 박스는 다른 모든 콘트롤(widgets)들보다 빠른 수행성을 이끌어내었다. 사용자는 체크 박스나 해당 텍스트 레이블을 클릭할 수 있어야 한다. 역주 : 다음은 가이드에서 제시하는 사례이다. 관례적으로 하나 이상의 복수 선택이 예상될 때 체크 박스를 사용한다.
|
| 13장 | | | 13:13 친숙한 콘트롤(widgets)의 사용 |
|
13:13 친숙한 콘트롤(widgets)의 사용
(상대적 중요도: 3, 증거의 강도: 3)
지침 : 사용자에게 친숙한 콘트롤을 그 콘트롤이 흔히 쓰이는 방식으로 제공하라.
주석 : 모든 사용자들이 모든 이용가능한 콘트롤들에 익숙할 것이라고 간주하지 말아야 한다. 친숙하지 않은 콘트롤은 어떤 사용자들을 느리게 만들 수 있으며 어떤 사람들은 그 콘트롤이 제대로 작동하게 만드는 법을 모르기 때문에 사용을 안할수도 있다. 예를 들어 한 연구에 의하면 어떤 사용자들 특히 나이 든 사용자들은 드롭 다운 리스트 박스를 어떻게 사용하는지 모르고 있었다고 한다.
콘트롤(widgets) 선택에 있어서 일반적으로 디자이너는 사용가능한 화면 크기와, 사용자 클릭수를 줄이는 것, 사용자가 많은 항목들중에 하나를 선택하게 할 것인지 아니면 여러 항목을 한꺼번에 선택하게 할 것인지를 고려하게 된다. 사용성이-해당 콘트롤이 사용자를 혼란시키지 않거나 느리지 않게 만드는- 수행성과 수용가능성을 판단하는 기준이 된다. 역주 : 다음은 가이드에서 제시하는 사례들이다.
[아래는 관례에 어긋나는 콘트롤이다. 오른쪽 원 안은 텍스트 입력 박스처럼 보인다. 그러나 커서를 입력란에 놓으면 왼쪽 창의 링크된 텍스트가 반전된다. 즉 왼쪽 창에서 링크를 선택하면 이 박스속에 그 링크의 텍스트가 들어오는 것이다. 이런 경우엔 드롭 다운 박스가 뜨는 것이 낫다.] 
[아래 사례의 경우 사용자는 라디오 버튼이 이런 식으로 사용되리라곤 예상하지 못한다]  |
| 13장 | | | 13:14 단일 데이터 입력 방식의 사용 |
|
13:14 단일 데이터 입력 방식의 사용
(상대적 중요도: 3, 증거의 강도: 4)
지침 : 사용자들이 가능한 한 단일한 입력 방식을 쓸 수 있도록 데이터 입력 처리를 하라.
주석 : 사용자들에게 데이터 입력 방식때문에 왔다 갔다 하지 않게 하여야 한다. 사용자로 하여금 키보드에서 마우스로, 다시 키보드로 이동하도록 요구한다면 이는 입력 속도를 아주 느리게 만든다.
[아래 사례는 마우스를 이용한 일관된 입력 방식이다] 
[아래는 왼쪽은 키보드, 오른쪽은 마우스를 번갈아 사용해서 입력해야 하는 잘못된 입력 방식 디자인이다]  |
| 13장 | | | 13:15 긴 데이터 항목의 분할 |
|
13:15 긴 데이터 항목의 분할
(상대적 중요도: 3, 증거의 강도: 2)
지침 : 데이터 입력이나 데이터 표시에 있어서 긴 데이터 항목은 짧막한 섹션들로 분할하라.
주석 : 긴 데이터 항목들의 분할은 사용자가 입력 오류를 발견하고 잘못된 입력을 줄이는데 도움을 준다. 예를 들어 10자리 전화 번호를 세개의 그룹(xxx-xxx-xxxx)으로 나누면 입력이나 확인이 더 쉬워진다. 유사한 경우로 우편번호나 사회 보장 번호도 마찬가지다. 역주 : 국내의 경우 주민등록번호나 특히 인터넷 뱅킹시 신용카드 번호, 계좌 번호등의 경우 일반적으로 필드 구분을 안하고 입력하게 하는데 이 때문에 빈번히 입력시 오류가 발생하거나 확인이 어렵게 된다. 섹션 분할을 안하는 이유는 물론 있을수 있으나 주요하게는 사용성 개선 마인드가 없어서 생기는 경우가 다수이다. 이는 기획자나 프로그래머의 무지나 게으름으로 인해 발생한다고 볼 수 밖에 없다.
|
