네이버는 전사적으로 자바스크립트 개발과 사용의 효율성을 높이기 위해서 진도 프레임웍을 쓰고 있다. 오페라 미니에서 네이버의 페이지들이 정상적으로 작동하지 않는 것을 발견하고 그 원인을 찾다보니 자바스크립트 이벤트의 사용이 독특한 것을 발견할 수 있었다. 듀트님과 같이 얘기해 본 내용을 정리해보니 진도 프레임웍은 이벤트 버블링을 사용해서 자바스크립트 이벤트를 다루고 있는 것 같다.
보통 자바스크립트 이벤트는 사용자가 액션을 직접 취하는 요소에 적용한다. 예를 들어서 레이어를 보이게 하고 싶다면 사용자가 클릭을 하는 A 요소에 온클릭 이벤트 핸들러를 할당하게 된다. 하지만 이때 발생하는 이벤트는 그 요소에만 제한적이지 않다. 브라우저에 따라서 다르기는 하지만 보통 이벤트 버블링이나 이벤트 캡춰링을 통해서 다른 상위요소에서도 이벤트가 발생하게 된다. 클릭된 요소의 상위요소로 이벤트가 버블링을 통해서 번지게 되고 이를 이용해서 이벤트 발생을 제어할 수 있다. 네이버 뿐만아니라 요즘 이러한 방식을 사용하는 사이트가 조금씩 나오고 있는 것 같다.
진도에서는 이벤트를 이벤트가 발생되어야 하는 각 요소에 할당하지 않고 요소들을 감싸고 있는 상위 요소 - 보통은 DIV나 P요소 - 에 할당한다. 그러면 이벤트가 발생했을 때 이 상위 요소에서 이벤트를 제어할 수 있다.
문제는 이벤트가 발생해야 하는 요소가 아닌 상위 요소에 이벤트를 지정할 경우 이것이 키보드 접근성을 해치게 된다는 것이다. 오페라는 스페이셜 네비게이션(spatial navigation)이라는 키보드 접근 방법을 제공하고 있다. 스페이셜 네비게이션을 사용하면 상위 요소에 할당된 이벤트에도 접근이 가능해져서 사용자의 혼란을 야기할 수 있다. 네이버 뉴스 같은 경우도 전체 콘텐츠 영역이 선택이 가능해지게 된다. 포커스는 생기지만 클릭이 되지 않는 현상은 분명 키보드 접근에 있어서는 장애요소이다. 
또한 이러한 현상은 장치독립성이 아주 중요한 모바일 기기에서도 나타난다. 아이폰의 사파리나 오페라 모바일로 네이버 페이지를 사용하다보면 반응은 하지 않지만 넓게 나타나는 클릭영역을 볼 수 있다. 
이러한 현상은 오페라 미니와 같은 서버-클라이언트 기반의 브라우저에서는 불편함을 넘어서 사용자에게 직접적으로 손해가 생길 수도 있다. 
미니는 자바스크립트 엔진이 클라이언트에 없기 때문에 이벤트가 발생할 경우 서버에 이벤트 처리를 요청해야 한다. 사용자 입장에서는 아무 동작도 하지 않는 이벤트를 위해서 불필요한 데이터 트래픽 비용을 지불해야 하게 된다. 많은 모바일 기기에서 키패드로 웹페이지를 사용해야 하는데 이 경우에도 네비게이션에 방해가 되는 포커스가 많이 나타난다.
왜 이러한 방식을 사용하는지 정확한 원인을 모르기 때문에 무조건 잘못됐다고 말 할 수는 없다. 아마도 성능상 - 사실 성능을 위해서는 버블링을 다 없애는게 더 좋다. - 이나 유지관리상 이점이 있을것 같기는 하다. 하지만 키보드로 사용할 때에는 분명한 장애요소이기 때문에 그 효용성이 높다고 하더라도 이벤트 처리 방식에 대해서 다시 고민할 필요가 있어보인다. 장치독립적인 접근 방식을 취할때 가장 비슷한 것이 키보드 네비게이션이기 때문에 데스크탑을 제외한 많은 기기에서 이러한 현상이 나타날 것으로 생각된다. 다양한 환경에서도 잘 작동할 수 있는 좋은 웹사이트를 제작하기 위해서는 이러한 장치독립성도 같이 고려할 필요가 있다.
(본의 아니게 갑자기 네이버까 분위기의 글을 많이 쓰게 되는데 - 하나 더 있음;; - 나쁜 의도는 아니고 제일 많이 쓰다보니까 자꾸 보이는 것이니 이해해 주세요.)
July 03, 2009
| Comments (3) | TrackBacks (0)
메뉴 같은 곳의 마우스 오버 효과를 낼때 사용되는 기법중에 좀 특이한 것이 있습니다. 사이트들 둘러볼때도 가끔 보이고, 최근에는 어떤분이 메일로 물어보시기도 하고, 웹 접근성 연구소에 질문이 올라와있기도 합니다. 처음 이 기법을 봤을 때는 이걸 왜 이런식으로 만들었나 의아해 하면서도 많이 사용안되는 기법이라고 생각하고 무시해 왔는데, 생각보다 많이 사용하고 있는 기법인 것 같습니다. 
<style type="text/css">
#menu a img.menuon {
display: none;
}
#menu a:hover img.menuoff {
display: inline;
}
</style>
<!-- ... 중략 ... -->
<ul id="menu">
<li>
<a href="menu1.html">
<img src="menu1_off.png" class="menuoff" alt="메뉴1">
<img src="menu1_on.png" class="menuon" alt="메뉴1">
</a>
</li>
<li>
<a href="menu2.html">
<img src="menu2_off.png" class="menuoff" alt="메뉴2">
<img src="menu2_on.png" class="menuon" alt="메뉴2">
</a>
</li>
<li>
<a href="menu3.html">
<img src="menu3_off.png" class="menuoff" alt="메뉴3">
<img src="menu3_on.png" class="menuon" alt="메뉴3">
</a>
</li>
</ul>
이렇게 이미지 두개를 사용하여 자바스크립트를 사용하지 않고 CSS를 이용해서 이미지 롤 오버 효과를 만드는 기법입니다. 자바스크립트를 사용하지 않고 CSS만으로 이미지 롤오버 효과를 만들어 내는 재미있는 방법이지만 큰 문제가 있는 방법이기도 합니다. 바로 HTML에 이미지 두개가 사용된다는 것입니다. 의미적으로 봐서 메뉴에 해당하는 이미지는 하나면 충분하고 그 옆에 있는 이미지는 중복된 콘텐츠입니다.
웹표준이나 웹접근성을 고려하여 콘텐츠를 제작할 때 중요한 것이 HTML, CSS, 자바스크립트를 구분하여 사용해야 한다는 것입니다. 아마 많이들 들어보셨고 CSS로 디자인을 분리하는 것들이 이것에 포함되는 것은 다들 알고 계실 것입니다. 여기에 들어있는 좀 더 깊은 의미는, HTML로 해야 하는 일을 CSS나 자바스크립트로 하지 않고, CSS로 할일을 HTML이나 자바스크립트로 하지 않고, 자바스크립트로 해야 할 일을 CSS나 HTML로 하지 않는 다는 것입니다. 각각의 영역을 다른 것들이 침범하지 않게 한다는 것입니다.
위에 사용된 예는 롤오버된 이미지를 보여주는 자바스크립트로 해야 하는 동적인 일을 HTML과 CSS로 처리를 해서 문제가 발생된 것입니다. 자바스크립트를 자제해서 사용해야 한다고 말은 하지만 그렇다고 자바스크립트를 써야 하는 곳에도 사용하지 말라는 의미는 아닙니다. 오히려 이런 경우와 같이 억지로 자바스크립트를 사용하지 않다보면 그 부작용이 더 커지게 됩니다.
HTML은 콘텐츠를, CSS는 콘텐츠의 표현을, 자바스크립트는 동적인 기능을 담당하고 있습니다. 각 기술들의 역할을 충분히 이해하고 적절한 곳에 최소화하여 사용하는 것이 중요합니다.
June 30, 2009
| Comments (1) | TrackBacks (0)
네이버 뉴스가 개편을 했습니다. 훨씬 깔끔해진 디자인에 기능도 많이 좋아졌습니다. 기사 목록을 내가 원하는 방식을 보는 기능, 특히 사진들을 모아서 보는 기능은 참신한 것 같습니다. 많은 경우에는 사진만 보는 목록을 따로 제공하는데 이렇게 기사의 보는 방식을 변경하는 개념이 동일한 기사목록이라는 느낌이 전달 되어서 더 좋은 것 같습니다.
전반적으로 아주 마음에 들지만 접근성 문제가 하나 발견되었습니다. 사이트를 마음먹고 분석해본 것은 아니어서 다른 문제가 또 있는지도 모르겠지만 일단 왼쪽 하위 메뉴 부분이 키보드로 접근이 되지 않는 것이 눈에 띕니다.
현재 왼쪽 메뉴 부분은 마우스를 올리면 하위 메뉴가 나와서 마우스로 하위 항목을 선택하게 되어 있습니다. 마우스 외의 키보드로는 이부분을 선택할 수 없습니다. 예를 들어서 정치 부분의 하위 섹션를 보고 싶으면 반드시 마우스를 사용해만 클릭을 할 수 있습니다. 물론 왼쪽 메뉴에서 들어갈 수 없더라도 그 섹션 안에서 키보드로 접근할 수 있는 일반 링크가 있다면 키보드로 접근은 할 수 있을 것입니다. 하지만 섹션에 들어가도 왼쪽 메뉴 부분을 대체할 수 있는 링크는 찾을 수가 없습니다.
키보드 접근은 마우스를 사용할 수 없는 사용자나 마우스가 없는 환경, 특히 모바일과 같은 환경에서 매우 중요합니다. 많은 모바일 기기는 마우스가 없기 때문에 키보드 네비게이션 방법을 많이 사용하게 됩니다. 물론 마우스 기능을 전혀 사용할 수 없는 것은 아닙니다. 많은 경우 마우스 기능을 흉내낸 기능을 제공합니다. 애플의 모바일 사파리는 마우스 오버 이벤트와 마우스 클릭 이벤트(또는 링크)가 하나의 요소에 있을 경우, 첫 클릭은 마우스 오버 이벤트를 발생시키고 두번째 클릭은 아무스 클릭 이벤트를 발생시킵니다. 이 경우에는 다행이 네이버 뉴스와 같은 구성 방식을 사용할 수 있습니다. 하지만 대부분의 다른 모바일 브라우저들은 이렇게 하나의 요소에 두가지 이벤트가 있는 경우에는 클릭이벤트를 사용합니다.
또한 마우스를 사용할 수 없거나 키보드 사용을 더 선호하는 장애인도 키보드 접근이 막혀 있으면 사이트를 제대로 사용할 수 없습니다. 손이나 뇌병변 장애때문에 마우스 사용이 불편한 사용자의 경우 마우스를 올리고 옆으로 마우스를 이동시켜서 클릭을 하는 작업을 매우 힘들게 느낍니다. 그나마 이동 도중에 레이어가 닫히게 되면 힘든 작업을 처음부터 다시 해야 하고 포기하는 경우도 생기게 됩니다.
개편하느라 많은 분들이 고생하셨을 텐데 괜히 딴지 거는건 아니고요. 조금이라도 많은 분들이 이러한 것들도 고민해서 좀더 나은 웹이 되었으면 좋겠습니다. 앞으로 더 나아질 것이라고 믿습니다.
June 09, 2009
| Comments (2) | TrackBacks (0)
웹페이지에 스타일을 적용하는 것에도 브라우저 이슈가 있지만 이메일에 비하면 매우 쉽습니다. 오래된 브라우저를 고려할 때에는 버그때문에 골치가 아프지만 많은 사람들이 같은 고민을 해와서 해결책들이 많이 알려져 있습니다. 그리고 점차 브라우저들이 표준을 잘 지원하는 방향으로 개선되고 있기 때문에 점점 웹표준으로 사이트를 제작하는 일이 쉬워지고 있습니다.
하지만 이메일의 경우는 얘기가 조금 다릅니다. 이메일은 메일 클라이언트도 다양하고 이메일을 웹에서 보여주는 서비스들도 다양해서 단일한 코드로 많은 환경을 호환시키는 것이 쉽지만은 않습니다. 메일 클라이언트마다 표준을 지원하는 정도가 다르고, 보통 웹메일이라고 얘기하는 메일 서비스들은 보안이나 기타 알 수 없는 다른 이유로 스타일을 없애버리기 때문입니다.
예를 들어 지메일의 경우 외부스타일 링크를 완전히 무시해서 스타일이 적용되지 않은 상태의 선형화된 메일을 보여줍니다. 아웃룩 익스프레스 2007과 같은 메일 클라이언트도 워낙 지원하는 스펙이 제한되어 있어서 열심히 만든 메일 페이지가 잘 나오지 않는 경우가 많습니다. 아웃룩 익스프레스 2007이 배경이미지를 지원하지 않는다는 말을 듣고 굉장히 충격을 받았던 생각이 납니다.
이러한 메일 클라이언트나 메일 서비스에서 안전하게 사용할 수 있는 스타일은 이메일 클라이언트 CSS 지원(Guide to CSS support in email clients (2008))에 잘 정리가 되어 있습니다. 우리나라 메일 서비스의 경우에는 김군우님께서 조사해 주신 국내 유명 웹메일 CSS 지원 테스트를 참고하시면 됩니다.
현재로서 가장 확실한 방법은 BODY 요소 안에서 모든 다지인을 구현하고 스타일을 인라인으로 넣는 것입니다. CSS로 잘 선언된 스타일을 인라인으로 풀어서 넣는 것은 상당히 곤혹스러운 일입니다. 특히나 깔끔한 표준 코드에 익숙해져있는 분들은 이 복잡한 스타일 속성의 난장에서 수정할 것을 찾는 것이 힘들 수도 있습니다. 예전에는 저도 이러한 작업을 손으로 직접 했었는데 최근에 굉장히 좋은 스크립트를 발견했습니다.
이모그리파이어(Emogrifier)는 분리된 HTML과 CSS를 인라인 스타일을 이용해서 하나로 합쳐주는 스크립트입니다. 라이센스는 MIT라이센스를 따르고 있어서 누구나 특별한 제한 없이 사용할 수 있습니다.
div.email-content {
font-size: 0.75em;
}
div.email-content h1 {
font-size: 1.5em
}
div.email-content p {
margin-left: 3em;
}
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Emogrifier TEST</title>
</head>
<body>
<div class="email-content">
<h1>Emogrifier</h1>
<p>Thanks Emogrifier!</p>
</div>
</body>
</html>
위와 같은 코드를 이모그리파이어로 변환하면 아래와 같은 코드를 만들어 줍니다.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Emogrifier TEST</title>
</head>
<body><div class="email-content" style="font-size: 0.75em;">
<h1 style="font-size: 1.5em">Emogrifier</h1>
<p style="margin-left: 3em;">Thanks Emogrifier!</p>
</div></body>
</html>
background-image는 잘 지원이 안되니 HTML 속성으로 구현하는 것이 더 좋습니다. 그리고 배포 사이트에서는 한글이 잘 안되는거 같은데 소스 코드를 다운 받을 수 있으니 유니코드 환경에서 작동시키면 작동 될 것 같습니다. PHP5가 필요합니다. 이 코드를 사용하면 더이상 CSS를 인라인으로 풀어 넣거나 인라인 난장 HTML 코드를 눈아프게 분석할 필요도 없습니다. 참 좋은 세상입니다. :)
June 08, 2009
| Comments (5) | TrackBacks (1)
어제 자기 전에 검색할 것이 있어서 아이팟 터치로 네이버에 접속 했다가 모바일 페이지를 제공하고 있는 것을 발견했다. 디자인도 깔끔하고 페이지도 굉장히 빨리 로딩이 됐다. 하지만 검색을 몇 건 해 보고는 불편해서 데스크톱 화면을 찾게 되었다. 다행히 화면 맨 아래에 데스크톱 화면으로 전환하는 버튼이 있었다. 페이지 로딩 속도는 확실히 차이가 났지만 아무래도 데스크톱 화면이 훨씬 편하게 느껴졌다.
탑페이지 뿐만 아니라 PDA페이지 같은 모바일 페이지를 이미 오래전부터 제공하고 있었고 다음과 같은 다른 포탈도 마찬가지로 경량화된 페이지를 가지고 있었다. 작은 모바일 기기를 배려하여 경량화된 페이지를 제공한다는 것은 사용자의 선택권이 늘어난다는 관점에서 매우 바람직한 현상이다.
하지만 여기서 간과해서는 안되는 것은 모바일용 페이지를 사용자에게 강요해서는 안된다는 것이다. 네이버 같이 데스크톱 화면 버튼을 넣는 것은 아주 좋은 시작이라고 볼 수 있다. 하지만 더 중요한 것은 버튼을 넣는 것 뿐만 아니라 데스크톱 화면을 모바일 기기에서도 잘 쓸 수 있도록 만드는 것이다. 서비스 제공자 입장에서는 모바일 사용자를 위해서 모바일 페이지를 만들었고, 사용자들이 그 페이지를 써주기를 바랄 것이다. 하지만 메일을 읽는 것과 같은 몇가지 경우를 제외하고는 사용자들은 모바일용 페이지를 원하지 않는다. 사용자들이 모바일용 페이지를 사용하는 많은 이유는 데스트탑용 화면이 작동을 잘 안하기 때문이다. 데스트탑 화면을 쓸 수 없게 만들고 모바일 페이지를 제공하는 것은 모바일 페이지를 사용자에게 강요하는 일이다.
데스크톱용 화면을 모바일 기기에서 완벽하게 지원할 수 없다는 것은 누구나 잘 알고 있다. 완전히 동일한 콘텐츠와 사용자 겸험을 제공해야 한다고는 말하는 것은 아니다. 하지만, 최소한의 사용자 경험, 전체적인 페이지의 느낌과 자신이 많이 사용하는 콘텐츠의 위치 정도는 동일하게 가져갈 수 있다. 그런 것을 위해서 이미 HTML이나 CSS는 만들어져 왔고 플러그인도 대체 콘텐츠(fallback)을 제공하는 방법이 마련되어 있다. 두말하면 잔소리인 "표준을 공부하고 표준을 적용하라"는 이야기이다. 그러면 별도의 모바일 페이지를 만들지 않아도 사용자들이 웹페이지를 잘 사용할 수 있다.
모바일 브라우저 벤더나 디바이스 제조사들은 보다 좋은 제품을 만들어서 이 사용자 경험의 차이를 좁혀야만 하고, 웹사이트 제공자도 다양한 사용자들이 자신이 원하는 환경을 선택하여 이용할 수 있게 노력해야만 한다. 데스크톱 브라우저 호환성은 물론이고 이제는 모바일 환경도 고려하여 사이트를 제작해야만 한다. 경량화된 별도의 페이지가 아니라 다양한 환경을 고려하여 사이트를 가볍게 만드는 것이 중요하다. 그러면 나머지 선택은 사용자가 할 것이다.
오페라 미니3에서는 모바일 뷰만을 지원했었는데 데스크톱 화면을 제공하는 오페라 미나4가 나오니까 사용자들이 훨씬 좋아하고 사용율도 늘었다는 얘기는 적지않은 충격이었다. 사용자들은 모바일용 페이지를 원하지 않는다. 그들은 데스크톱 사용자 경험을 모바일 환경에서도 동일하게 유지하고 싶어한다. 화면도 작고 입력 수단도 달라졌는데 웹사이트까지도 달라져버리면 그것을 자신이 이용하던 사이트라고 생각할 수 있는 사용자는 많지 않을 것이다.
모든 결정은 사용자가 한다. 서비스나 제품을 만드는 사람 입장에서는 최대한 다양한 사용자가 되어보는 것이 가장 필요할 것 같다.
(한줄요약: 모바일 페이지 만드는 노력 만큼이나 데스크톱 페이지를 모바일에서 접근성있게 만드는 것도 중요하다.)
June 03, 2009
| Comments (3) | TrackBacks (0)
이전글
![[Valid RSS]](/home/images/badge-valid-rss.png "Validate my RSS feed"){kind=icon}