title 속성을 이용하여 선택 후 엔터를 입력해야된다는 것을 알려주는 것은 어떨까요?
아니면 이 포럼의 최하단에 있는 것 같은 처리방식도 생각해 볼 수 있겠네요.
추가 : ie하고 ff하고 동작하는 방식이 다르네요. 제가 말한건 ff의 동작형태입니다.

덧. Go버튼이 없는 저런 형태는 javascript를 사용할 수 없는 환경에서는 치명적이니 그에 따른 처리도 해주셔야 될 것 같네요.

최종 편집 : Peris (2008-04-02 09:36 AM)

마우스가 위아래로 움직이는것  =  키보드로 위 아래키를 누르는것
클릭 = 엔터 혹은 스페이스바.

유저에게 선택한것을 확인시키는 엔터나 스페이스바가 UX 를 해치지 않는다고 생각합니다.

또한 유저가 키보드로 긴 리스트를 볼 시에도 (시간대 고르기) 알파벳을 눌러 이동후에 맞는 옵션을 고른후 확인의 부분으로 볼수 있는 엔터나 스페이스바키를 누르는것이 괜찮다고 생각됩니다.  보통 TAB을 이동으로 사용하는데 이동+확인의 역할을 수행하지 않는다고 해서 해칠꺼 같지는 않습니다.

저도 키보드의 엔터키를 눌러 들어가는 것과 마우스로 클릭해서 가는것이 사용성을 해친다고 생각하진 않습니다.
저는 오히러 GO버튼이 존재하는게 사용성이 좀 떨어진다고 생각을 합니다^^

우선 select는 form안에 존재하는 것입니다. submit 버튼 없이 보통 드롭다운 메뉴를 구성하는데 이는 마치 레이아웃을 잡기 위해 table을 사용하는 것과 비슷한 케이스일 것입니다. drop-down list라는 표준 컨트롤를 대부분의 브라우저가 지원하기 때문에 복잡한 JS 구현없이 쉽게 된다고 이것을 사용합니다만.. 뭐 큰 문제는 없습니다만 스레드가 고민해 보자는 것이니 몇가지 사안들을 적어봅니다.

우선 JS가 안되는 상황.
이세상에 JS가 안되는 상황이 어디있냐고, 혹은 소숫점도 안되는 퍼센테이지를 지원해야 하나고 항의를 많이 듣습니다만 생각보다는 많습니다. 모바일 디바이스나 텍스트 브라우저 같은 특별한 상황도 있습니다만 상당수의 RSS 리더들이 JS와 Plug-in(object혹은 flash)이 꺼져 있는 것이 디폴트입니다. 대안(얼터너티브)이 없는 구현은 분명 문제라 할 수 있습니다. 브라우저의 고급기능(JS등)은 사용자의 UX를 증가시켜주는 것일 뿐입니다. JS Tutorial이나 현재의 브라우저 능력으로는 불가능한 기술일 때 사용하는 것은 어쩔 수 없습니다만 역으로 기본 기능만으로 기본 사이트 피쳐를 이용할 수 없게 만드는 것은 사려깊지 못하다고 생각이 됩니다.

콤보박스가 언제나 같지는 않다.
iphone이나 ipod touch 혹은 모바일에 올라간 opera등 모바일 디바이스에 들어간 풀브라우저들은 화면이 작기 때문에 select의 콤보박스(드롭다운 리스트)를 쉽게 사용하기 힘들기 때문에 다른 형태를 취합니다. 이것이 사실 표준컨트롤의 장점입니다. 선택을 하는 UI가 있다면 사용하는 환경에 최적화 된 UI를 플랫폼이 제공해 줄 수 있죠. 특히 iphone/ipod touch의 콤보박스 구현은 개인적으로는 찬사를 보냅니다. 어떻게 하는지는 주위에서 기계를 구하시거나, 직접 구매를 하시거나(전 이런 환경을 경험해 보기 위해 직접 샀습니다.) 아니면 현재 나와있는 iphone SDK를 다운받으시면 iphone simulator가 들어 있습니다(맥을 사야 되나?). 아무튼 이런 환경이 되면 마우스와 키보드가 아닌 전혀 새로운 인풋 형태가 됩니다. 그리고 공들여 짠 JS가 반대로 짜증나게 됩니다.

마지막으로 back & forward 문제입니다.
위와 같은 네비게이션을 사용해서 페이지를 이동했다가 Back을 하면 직전에 선택한 메뉴가 select에 남아 있습니다. form 요소의 특성이죠. 다시 방금 봤던 페이지로 돌아가기 위해서는 포워드 버튼을 누르는 방법도 있습니다만 페이지 자체의 네비게이션을 이용하려면 select를 두번 변경해야 합니다. 다행이 select에 아무것도 하지 않는 옵션이 있다면 모를까 없다면 F5를 누르고 선택해야 합니다(딴 페이지 갔다 오거나). 백워드 버튼을 누르는데 포워드 버튼 누르면 되는거 아니냐구요? 제가 마우스도 상당수 수집했는데 백워드 버튼만 있는 놈들이 꽤 됩니다. 둘다 있어도 엄지를 구부려 포워드 누르는 행위가 부자연스럽기도 하구요.

수전증이 있거나 마우스 광학센서의 문제로 미스클릭시 페이지가 엉뚱한 곳으로 휙 날아가는 문제는 개인적인 것으로 치부하겠습니다. (한번 클릭하면 반드시 어디론가 이동해야 하는 낙장 불입으로 만든 사이트도 가끔 있습니다.)
submit 버튼을 구지 만드는 경우 대부분의 케이스에서 사용자에게 클릭 한번을 더 유도하는 것도 맞습니다. 허나 반대 급부도 있습니다.

덧.
저는 어떻게 하느냐. 다른 부서(디자인, 기획등)와 이런 문제를 종종 논의하는데 왠만하면 전 이렇게 대답합니다. 종토세 내는것도 아닌데 왜이리 자리 아끼냐구요. 앵커로 쫙 깔아 버리는 식으로 고민해 보자고 합니다. 실제로 자리가 비좁은 경우엔 어쩔 수 없긴 합니다만... 아무튼 확실한것은 현재 html에 drop-down menu를 문제없이 제대로 할 수 있는 엘리먼트는 없습니다.

선호 차이겠지만 전 GO 버튼 있는 걸 좋아합니다. 일관성 때문에 그러한데요.

기억이 나질 않아 어디라고 콕 집어낼 수는 없지만, 그곳은 어느 부분에선 선택하는 순간 뭔가 행위가 일어나고 어느 부분에선 GO버튼을 눌러야 행위가 일어 났습니다. 한 서비스 안에서도 그렇게 일관성이 없다보니 나중엔 좀 헷갈리더군요. 분명 옆에 GO 버튼이 있는데도 뭔가를 선택하고 멍하니 기다리고 있다든가, 뭐있나 보려고 펼쳤다가 실수를 하여 엉뚱한 화면으로 휙 날아갔다든가.

사용성이라는 것은 대체로 개인 성향에 많이 좌지 우지 될 텐데, 입력 요소가 많은 서비스일수록 GO버튼 없는 펼침메뉴는 Interface 인지를 방해 한다는 생각입니다. @_@

저도 이 생각에 동의합니다.

form내에서 메뉴로 사용되는 셀렉트 박스를 왜 점프메뉴에 쓰려고하시는건가요?

셀렉트 박스는 form내에서 사용자의 입력값을 받는 입력컨트롤중의 하나인데

단지 우리가 머릿속에서 그리고 있는 점프메뉴의 이미지와 select박스 컨트롤의 생김새가 비슷하다는 이유로

사용하시려는건 아닌가요?

<ul>
 <li><a href="">링크1</a></li>
 <li><a href="">링크2</a></li>
 <li><a href="">링크3</a></li>
 <li><a href="">링크4</a></li>
</ul>

오히려 이런식으로 마크업을 하여 자바스크립트를 사용하여

점프메뉴를 구현하는게 더 맞다고 봅니다.

(자바스크립트가 동작하지 않는 상태에서는 물론 모든 목록이 나와야겠죠)

UI 를 담당하시는 분들의 입장에서는

이런 드랍다운컨트롤을 만들기 솔직히 귀찮습니다.

반면에 select박스쓰면 onchage 이벤트만 하나 등록하면 되니 간단하지요.

select박스를 사용한 점프메뉴에 go 버튼이 있어야 하느냐 없어야 하느냐가 아니라

점프메뉴를 select박스로 구현하는게 맞느냐가 먼저 아닐까 생각해봅니다.
(물론 100% 틀리다라는 입장은 아니지만 select박스를 사용하지 않고 ul li 목록을 사용하여 드랍다운 컨트롤을 만들면
모든 고민이 해결되지 않나 싶습니다)

그냥 새 쓰레드를 여시는게 더 활발하게 토론 될 수 있지 않을까요?

저도 ul돠 a를 사용하여 select인척하고 tabindex를 이용하여 포커스처리를 가능하게 한 다음
포커스시에 드랍다운 메뉴를 오픈하고 혹은 원 클릭(원오버?)시에도 드랍다운 오버. 키보드 ↑↓ 처리도 넣어주고..
펼처진 메뉴에서는.. 앵커이기때문에 별다른 조취를 해줄 필요는 없겠죠. 굳이 form으로 전송하고 싶으시다면
스크립트로 히든인풋 관련하여 스크립트 처리만 해주면 간단하지 않을까요?

짧지만 디자이너도 경험하며 삽질하다보니 너무 깊게 생각할수록 후퇴된 결론이 나온다는걸 깨닿고 요즘은
즉각 생각난것으로 결정하고 처리해버리게 됩니다 ㅎㅎ