모든 웹 기반의 위지윅 에디터를 조사한 것은 아니지만 제가 간단하게 벤치마킹한 결과에 따르면 국내외를 막론하고 대부분의 제품들은 웹 브라우저가 기본으로 제공하는 처리 방식에 따라 p 요소에 Enter키를 맵핑해 두었고 br 요소에 Shift+Enter키를 맵핑해 두었습니다.

한편 글로벌 제품들은 p 요소에 브라우저가 제공하는 기본적인 상하 여백 {margin:1em 0} 스타일을 그대로 살려두는 방식을 채택했는데 국내 제품들은 p 요소에 브라우저가 제공하는 기본적인 상하 여백을 {margin:0} 으로 덮어쓰기 하는 방식으로 리셋 했습니다.

이를 통해서 우리는 다음과 같은 세 가지 사실을 알 수 있습니다.

• 해외에서는 Enter키를 치면 단락을 변경하는 것으로써 단락 사이의 여백이 학습되어 있다. 행간 여백 없이 줄 바꿈을 하려면 Shift+Enter를 치면 된다.
• 한국에서는 Enter키를 치면 단락을 변경하는 것이 아니라 단순히 줄 바꿈을 하는것으로 학습되어 있다. 단락을 구분하려면 Enter키를 두번 치면 된다. 문단 요소 p의 여백이 제거되어 있으므로 Shift+Enter를 알 필요도 없다.
• 외국 사람과 한국 사람은 웹에서 선호하는 글쓰기 모양도 다르고 경험도 다르다. 외국 사람은 하나의 문장에 마침표를 찍더라도 다음 문장을 줄 바꿈 없이 이어쓰며 단락을 바꿀 때에만 Enter를 치는 경향이 있고 한국 사람들은 마침표를 찍으면 다음 문장을 쓰기 위해 줄을 바꾼다. 외국인이 생성하는 태그는 의미론적 관점에서 옳은 방향이나 한국인이 사용하는 방식은 편리하다.

외국인과 한국인의 습성이 다를 뿐만 아니라 글쓰기 교육 시간에 문단을 바꿀 때에만 개행하라고 배웠다 하더라도 한국 사람들의 글쓰기가 틀렸다고 보기는 어렵다고 생각합니다. 국민 모두가 한 방향으로 틀렸다면 그 방향이 우리 나라에서는 사실상 통용되는 표준이라고 인정해야 한다는 생각입니다. 따라서 우리의 고민은 다음과 같이 전개됩니다.

• 한국에서 제품을 만들기 시작했지만 글로벌 시장에 진출하려면 사실상 국제 표준에 따라야 한다.
• 글로벌 시장에 진출하더라도 한국 시장은 포기할 수 없다.
• 우리 제품은 내수용과 수출용 구분이 따로 없다.

‘A’도 만족해야 하고 ‘B’도 만족해야 한다면 둘 다 만족 시켜주자라는 것이 중론인데요. 다음과 같은 제안들이 검토 대상에 올랐습니다.

• p 요소는 Enter키로 생성하며 br 요소는 Shift+Enter키로 생성한다.
• p 요소의 여백을 관리자 화면에서 원하는 방식으로 선택할 수 있도록 옵션을 제공한다. "[v] p 요소에 여백 제거"
• p 요소의 여백을 글 쓰는 사람이 에디터에서 직접 선택할 수 있도록 옵션을 제공한다. "[v] p 요소에 여백 제거"
• p 요소에 브라우저가 제공하는 기본 마진을 보존한 다음 Enter 한번은 br 요소를 생성하고 Enter 두번은 p 요소를 생성한다. (이 방법은 작년부터 제안되었으나 구현에 대한 난제가 있었던 것으로 지금은 정확히 기억이 나지 않네요)

글 쓰는 사람이 에디터에서 직접 선택할 수 있도록 옵션을 제공하는 방법은 개인적으로 반대하는 방법입니다. 개발자 또는 관리자가 해야 할 선택을 사용자에게 떠넘겨 UI를 복잡하게 만든다는 느낌을 지울 수가 없고 의미를 정확하게 간파하는 사용자도 드물꺼라 생각합니다. XE개발팀에서 XEED라는 새로운 에디터를 개발하며 이 문제를 어떻게 해결하는지 지켜봐주세요. 그리고 좋은 의견이나 경험담이 있으면 댓글로 함께 의견 나누시죠.

미리 알려드립니다만 저는 주로 인터렉션을 프로토타이핑 해서 보여줄 목적으로 자바스크립트를 작성하기 때문에 제 블로그에서 보여드리는 예제 코드가 모두 XE에 반영되는 것은 아닙니다.

예제를 새 창으로 보기

HTML

• ‘LOG-IN’ 링크에 accesskey 속성을 사용. ‘Alt+L’ 또는 ‘Alt+Shift+L’ 키를 사용하면 링크에 직접 접근.
• 논리적인 키보드 접근 순서. 로그인 레이어를 열거나 닫더라도 포커스는 초기화 되지 않고 문맥에 알맞게 순서를 유지.

CSS

• 화면 전체를 덮는 반투명 레이어.
• 로그인 상자를 화면의 정 중앙에 배치.
• 서밋 버튼을 텍스트로 처리해서 텍스트를 교체할 수 있음.

Javascript

• ‘LOG-IN’ 링크를 클릭해서 모달 윈도우 처리된 레이어 띄우기.
• 인풋에 포커스가 들어가거나 빠질 때 ‘레이블’ 텍스트를 숨기거나 보여주기.
• ‘로그인 유지’ 항목에 체크하면 경고문 보여주기.
• ‘ID/PW’를 입력하지 않았을 때 상황에 맞는 알럿 띄우기.
• ‘Open ID’ 링크를 클릭하면 오픈 아이디 화면으로 전환하기.
• ‘ESC’키를 누르거나 ‘여백’ 또는 ‘X’ 버튼을 클릭하면 창 닫기.

P.S.

저는 얼마 전부터 텍스타일에서 글을 쓰고 있습니다. 여러분이 만약 이 글을 제 워드프레스에서 보셨다면 배달된 글을 보고 계신 겁니다. 텍스타일에서 작성한 글은 워드프레스, 미투데이, 트위터 등으로 자동으로 배달 된답니다. 번거롭게 퍼다 나르고 다닐 일이 없어서 좋네요. 텍스타일 한 번 사용해 보세요. 즐거운 글쓰기 경험도 해 볼겸 해서 말이죠. ^^

이 밖에 더 많은 예제들이 OUIF | XEUI 페이지에 링크되어 있습니다.

이번에는 운이 좋게도 디자인팀으로부터 지원을 받았는데요. 이렇게 디자인팀으로부터 지원을 받은 디자인은 품질이 상당히 좋아서 한 번 쓰고 말기에는 정말 아깝더라구요. 재 활용 가치가 있는 UI 콤포넌트는 가끔 처음부터 재 사용을 염두해 두고 설계를 합니다. 물론 시간이 무척 오래 걸리는 단점은 있지만 다른 누군가의 시간을 분명히 단축해 줄꺼라 믿고 있습니다.

오늘 공유해 드릴 UI 콤포넌트는 평범한 네비게이션 바 입니다. 이런 종류의 네비게이션은 너무 흔해서 일년에 열두번도 더 코딩을 하지만 항상 재 사용을 염두하지는 않았기 때문에 할 때마다 새로 만들고 처음부터 다르게 코딩 합니다. 물론 디자인이 조금씩 달라지는 것도 이유가 있겠지만 다소 소모적인 부분이 있었던 것도 사실입니다. 보기에 평범해 보이지만 재 사용과 보편적 설계를 위해서 제가 이 네비게이션 바에 얼마나 많은 정성을 쏟았는지 한 번 설명드려 보겠습니다.

보편적이고 사용성이 좋은

수평 네비게이션은 보편적인 형태지만 하위 메뉴를 처리하는 방법에는 크게 두 가지 형태가 있습니다. 하위 메뉴를 수평으로 늘어뜨리거나 또는 위 예제와 같이 수직으로 늘어뜨리거나. 그런데 이 두 가지 형태의 메뉴 구조는 사용성이 크게 다릅니다. 하위 메뉴를 수직으로 늘어뜨리는 것이 사용성과 확장성이 훨씬 좋습니다.

하위 메뉴를 수평으로 열게 되면 사용자는 정확하게 선택하기 위하여 ‘L’자 모양으로 마우스 포인터를 이동시켜야 합니다. 게다가 하위 메뉴 영역을 벗어날 때 하위 메뉴가 사라지도록 처리하는 경우 사용성은 더 나빠집니다. 원하는 메뉴 링크까지 이동하려면 조심스럽게 마우스 포인터를 옮겨야 하니까요. 하위 메뉴를 수직으로 펼치면 마우스의 이동 괘적은 ‘I’자 모양을 그리게 되고 마우스를 옮기는 과정에서 메뉴가 닫힐 위험은 사라집니다. 

웹 표준과 접근성을 지키는

이런 메뉴 구조를 테이블 <table> 요소를 사용해서 마크업하면 의미에도 맞지 않고 접근성도 떨어집니다. 네비게이션 요소는 HTML로 표현할 때 ‘목록’ 요소 <ul>, <li>로 마크업 해야 합니다. 동등한 수준의 내용이 같은 계층에서 여러번 반복 된다면 ‘목록’입니다. 시각장애인이 사용하는 화면 낭독기는 이런 목록에 대하여 목록의 ‘시작, 끝, 단계 그리고 항목의 개수’를 음성으로 알림으로써 목록에 대한 이해를 돕습니다. 상기 예제에서 ‘CSS X’ 버튼을 누르면 네비게이션이 어떤 HTML 구조로 마크업 되어 있는지 확인할 수 있습니다. 이렇게 코딩된 네비게이션 바는 다음과 같은 장점을 갖습니다.

• 상-하위 계층 관계가 논리적으로 처리되어 CSS를 지원하지 않거나 걷어낸 장치(예:모바일)에서도 이해하기 쉽습니다.
• 모든 항목에 키보드 접근이 가능하고 키보드 접근 순서가 의미있게 처리되어 있습니다.

이 네비게이션 바는 키보드만을 사용할 수 밖에 없는 시각장애인과 지체장애인도 사용할 수 있습니다. 키보드만으로 탐색을 시도해 보세요.

유연하고 확장하기 좋은

하위 메뉴의 개수가 상당히 많이 늘어나는 상황에서 수평으로 열리는 하위 메뉴는 필연적으로 줄바꿈을 동반하거나 메뉴의 개수를 제한하게 되지만 수직으로 열리는 메뉴는 그럴 필요가 없기 때문에 메뉴 데이터가 가변적인 상황에서 확장성이 더 좋습니다.

메뉴의 전체적인 너비는 레이아웃에 맞게 가변폭으로 조절되고 메뉴 항목의 너비도 메뉴 이름의 길이에 따라 모두 가변폭으로 처리되어 있습니다. 디자인 때문에 글자 개수를 자르거나 제한 할 필요가 없습니다.

네비게이션 바의 색상을 바꾸기 위해 새로 이미지를 컷팅할 필요가 없습니다. CSS 편집을 통해 배경색과 보더 색상만 변경해 주면 끝입니다. 은은하게 처리된 그라디언트 효과는 배경색상 위에 반투명 흰색 그라디언트 PNG 이미지를 덧붙이는 기법으로 처리 했습니다.

이미 널리 쓰이고 있는

jQuery 자바스크립트 프레임웍을 사용했기 때문에 약간의 자바스크립트 코드를 추가하거나 변형하면 누구나 쉽게 사용할 수 있습니다. 물론 지금 그대로 사용해도 될만큼 이미 스크립트가 잘 처리되어 있습니다. 자바스크립트는 행복한고니에 의해 처리 되었습니다.

브라우저 호환성

다음과 같은 브라우저에서 테스트 되었고 호환성이 확보되어 있습니다.

• Internet Explorer 6
• Internet Explorer 7
• Internet Explorer 8
• Firefox 3
• Chrome 4
• Safari 4
• Opera 10

이 네비게이션을 처리하기 위하여 테스트 했던 거의 모든 브라우저들의 버그를 다 만났던것 같습니다. 여러분이 보시기에 HTML 코드에 ‘이건 왜 이렇게 마크업을 했지?’ 라고 의문이 든다면 그 부분이 바로 그 흔적 입니다. 특히 IE7 브라우저의 경우 링크 영역(width)을 제대로 렌더링하지 못하는 버그 때문에 상당히 고전을 했는데 결국 방법을 찾지 못하고 자바스크립트의 도움을 받아서 디버깅 했습니다. 코딩하는데 1.5일이 걸렸고 디버깅하는 시간도 1.5일이나 걸렸습니다. 3일동안 쳐다보고 있으니 아주 지겨워 죽겠더라구요.

이 밖에 더 많은 예제들이 OUIF | XEUI 페이지에 링크되어 있습니다.

이미 알고있는 분들도 계시겠지만 저는 오픈소스 XE의 UI 개발을 담당하고 있습니다. 모든 오픈소스가 그렇지만 저희 팀원들의 모토 가운데 하나도 ‘내가 불편한 것을 바꾸고 내가 쓰고 싶은 도구로 만들자’입니다. 이런 모토는 팀원들이 스스로 동기를 유발해서 열정적으로 XE를 개선하는데 도움이 됩니다.

그러나 오픈소스팀이라고 해서 주어진 일정이 없고 언제나 하고 싶은 일만 골라서 할 수 있는것도 아니기 때문에 즉시 실행으로 옮길 수 있는 일이 아니면 개인적으로 마음 한 켠에 쌓아놓을 뿐입니다. 물론 좋은 아이디어를 공유하지 않고 혼자 쌓아두는 것이 좋은 습관은 아니지만 아이디어를 제시하고 토론하는 과정에서 무척 많은 에너지를 필요로 하고 현재의 일에 몰입하는데 방해가 되기 때문에 자주 그러지 못할 뿐입니다.

제가 오늘 하고 싶은 이야기는 XE의 불편한 사용자 경험에 대한 이야기 입니다. XE는 아직 충분히 좋은 사용자 경험을 갖추지 못했지만 고객들은 그걸 잘 모릅니다. "XE는 어렵다" 또는 "XE를 배워야겠다"라는 말을 들을때마다 정말 미안해서 미칠 지경입니다. XE 사용자가 그렇게 말하는 이유는 사용자가 바보이기 때문이 아니라 XE의 사용자 경험이 좋지 않다는 뜻이고 그 책임의 일부는 저에게도 있기 때문입니다. 사용성이 좋지 않은 소프트웨어를 대할 때 사람들은 제품의 문제라고 생각하지 않고 스스로를 비난하는 경향이 있으며 5명 중 1명 정도만 문제제기를 한다고 합니다.

XE와 같은 설치형 소프트웨어의 사용자층은 크게 둘로 나눌 수 있는데 XE를 설치 운영하는 집단과 XE라는 사실조차 알지 못한채로 그저 가볍게 이용하는 사용자 집단 입니다. XE 공식 웹 사이트에 등록되는 버그 또는 이슈들은 대부분 XE를 설치 운영하는 사용자 집단으로부터 나온 것으로써 XE를 가볍게 사용하는 사람들의 문제는 거의 표면적으로 드러나지 않고 있습니다. 따라서 우리는 스스로 문제를 찾아내서 해결해야 합니다.

XE 개발자는 UX 전문가가 되어야 한다

지금까지 그러지 못했다는 것이 아니라 충분하지 않다는 의미 입니다. 설계 과정에서 항상 고려가 되지만 섬세하지 못했거나 우선순위가 낮았고 물려받은 유산들 때문에 미시적으로만 접근하는 측면이 있어왔습니다. 이런 문제를 해결하려면 개발자들이 사용자의 심리상태를 이해해야 하는데 사실상 그것은 거의 불가능에 가깝습니다. 프리젠테이션 젠이라는 책에서는 이런것을 두고 지식인의 저주라는 표현을 씁니다. 이미 너무 많은 것을 알기 때문에 모르는 사람들의 상태를 절대 이해할 수 없다는 것입니다. 사용자경험에 대하여 보다 진지하게 이해하고 연구해야 하며 보다 거시적으로 접근할 필요가 있습니다. XE의 Ajax/Javascript UI 개발을 담당하고 있는 행복한고니는 항상 웹 개발에 문외한인 와이프를 가상의 사용자로 가정한다고 하는데 이런 방법은 비용대비 효과가 괜찮은 작은 실천 중의 하나라고 생각합니다.

선택의 폭을 줄이고 만족도를 높여야 한다

XE의 장점 가운데 하나는 많은 사용자로부터 오는 공통된 불만사항을 빠르게 개선해서 반영한다는 점입니다. 이것은 사용자가 답이라는 zero님의 운영 철학 가운데 하나 인데요. 이런 철학 때문에 실제로 사용자들이 상상하는 대부분의 모듈들은 이미 존재하거나 개발자가 마음만 먹으면 쉽게 만들 수 있습니다.

그러나 선택의 폭을 줄여야 한다는 주장은 상황에 따라서 zero님의 운영 철학과 충돌하는 측면도 있습니다. 왜냐하면 사용자들의 공통된 피드백을 모두 반영하다보면 그만큼 사용자들은 더 많은 선택의 기로에 놓이게 되는데 이것은 곧 XE가 복잡해진다는 것을 의미하고 사용자들의 만족도를 떨어뜨리는 방향으로 작용할 가능성이 있습니다. XE 관리자 페이지에는 무수히 많은 인풋과 선택지가 있는데 이런 경향이 사용자 페이지에 그대로 전이되는 경우가 있습니다. 딱히 뭘 더 줄이자는 이야기를 여기서 하기에는 너무 지엽적인 문제이기 때문에 언급하지 않는것이 좋겠습니다.

장사가 잘 되는 유명한 식당에 가보면 한 가지 음식만 제공해서 메뉴판이 아예 없는 경우도 있는데 오히려 사람들은 굉장히 만족스러워 합니다. 만약 그 식당의 음식들을 고스란히 뷔페로 옮겨놓으면 어떻게 될까요? 장담컨데 같은 음식에 대한 만족도는 확연하게 차이가 날 것입니다. 뷔페의 음식들은 모두 충분한 퀄러티를 가지고 있지만 모두 그저 그렇게 보이고 딱히 만족스럽지 않는 이유는 너무 많은 선택지가 제공되면서 모든 음식들이 서로의 비교 대상이 되기 때문입니다. 맛있는 음식을 더 많이 제공하면 만족도가 더 많이 올라갈것 같지만 절대로 그렇지 않습니다. 저는 신 김치를 딱히 좋아하지 않지만 다른 반찬이 제공되지 않는다면 맛있게 먹을수 있습니다. 너무 많은 선택지와 옵션을 제공하지 않아야 하는 이유 입니다.

인간의 생리와 문맥을 고려해야 한다

XE는 다른 설치형 소프트웨어들와 다르게 기본적으로 다국어환경을 가정합니다. 따라서 기본으로 제공되는 레이아웃을 사용하게 되면 언어를 변경할 수 있는 메뉴가 항상 따라다니는데 유용한 기능임에도 불구하고 좋지 않은 사용자 경험을 제공하는 경우가 훨씬 더 많습니다.

사용자는 보통 다국어 메뉴를 통해서 현재의 웹 사이트에 대한 모든 표현들이 자신의 언어로 변경되는 것을 기대하지만 XE는 이런 기대를 충족해 주지는 않습니다. 아니 정확히 말해서 XE가 충족해 주지 못하는 것이 아니라 XE를 사용하는 콘텐츠 제작자들이 그렇게 해주지를 못하는 것입니다. 다국어는 기계적으로 번역이 되는것이 아니라 콘텐츠 제작자에 의해서 수작업으로 번역이 되는데 대부분의 제작자는 이 기능을 제대로 사용하지 않습니다. 따라서 보통의 사용자들은 다국어 메뉴를 사용할 때 좌절하게 됩니다. 콘텐츠 제작자가 다국어 지원을 하지 않는 경우 다국어 지원 메뉴는 아예 보이지 않도록 처리해야 하는것이 인간의 생리와 문맥을 고려한 설계인데 이것은 문맥을 고려한 설계에 대한 다양한 문제 가운데 한 가지 예시일 뿐입니다.

또한 다국어환경 지원 문제는 다음과 같은 상황에서 매우 까다롭습니다. "A 카테고리에서 검색된 B 키워드가 C개 입니다" 라는 메시지를 출력한다고 가정할 때 이렇게 작성된 한글을 영어 또는 기타 외국어로 변환할 때 어순이 바뀌어야 하는데 저 문장은 A, B, C 를 포함한 6개의 변수로 작성되어 있고 언어 선택에 따라 어순이 바뀌도록 하는 것은 거의 불가능에 가깝기 때문에 실제로 저런 문장은 XE에서는 사용할 수가 없습니다. 이런 문제에 대해서 딱히 해법을 가진것은 아니지만 고민해 볼 필요는 있겠습니다. 다국어 환경 지원 때문에 인간이 쓰는 자연어를 오히려 사용하지 못하게 되는 것이 모순입니다.

맺음말

XE뿐만 아니라 모든 웹 개발자는 사용자 환경을 이해하기 어렵고 적절한 피드백을 받는것도 한계가 있기 때문에 사용자 경험에 대한 연구를 통해 직접 문제를 발견하고 해결해야 합니다. 사용자들은 자신들이 스스로 원하는 것을 모두 안다고 생각하지만 실제로는 그렇지 않으며 이슈트래커에 등록된 문제들은 실제 사용자들이 격는 문제의 20% 밖에 되지 않습니다. 인간의 생리를 이해하고 문맥을 고려한 설계를 통해서 사용자 스스로 자각하지 못했던 문제들에 대한 불편함을 개선해야 합니다. 사용자 경험은 UX 전문가들의 고유한 업무 영역이 아니라는 점도 상기해야 합니다. 모두에게 책임이 있다는 뜻입니다.

XE 커뮤니티에서 많은 기여를 하시고 활발하게 활동하셨던 분들이 오히려 초대장을 받지 못한 안타까운 사연도 있었습니다. 따라서 행사에 참석하신 분들은 운이 정말 좋으신 겁니다. 초대장을 받지 못한 분들께는 정말 죄송하다는 말씀을 드립니다.

저는 이날 ‘XE 스킨 제작 가이드’라는 개요 세션과 실무 위주의 ‘XE 스킨 제작 실습’ 이라는 두 개의 세션을 준비해서 공유해 드렸습니다. 초대받지 못하신 분들께 너무 죄송한 마음에 한시라도 빨리 자료를 공유해야겠다는 생각을 했습니다. ‘XE 스킨 제작 가이드’는 얼마전 있었던 NHN Deview 2009 행사 때 이미 공유했던 자료인데 이날 한번 더 발표를 했고 ‘XE 스킨 제작 실습’이라는 문서는 처음 공유하는 문서 입니다.

아무쪼록 더 많은 분들이 더 쉽게 만들고 접하고 나눌 수 있는 XE가 되었으면 하구요. 아낌없는 투자와 지지를 보내주는 회사에도 감사합니다. 수 일 전부터 이 행사의 모든것을 챙겨주셨던 NHN 고객커뮤니케이션팀 팀원분들과 저희 오픈UI기술팀원들에게도 감사의 인사를 전합니다.

XE 스킨 제작 가이드

XE 스킨 제작 실습

‘XE CSS Framework for Layout’ 이란 XE를 이용하여 제작되는 웹 페이지들의 다양한 레이아웃 요소들을 ‘이해하기 쉽고, 유연하게 변형이 가능하며, 효과적으로 생성’하기 위한 HTML과 CSS코드 작성 규칙 입니다. CSS 프레임웍은 다양한 컬럼 구조의 화면 배치와 레이아웃의 성질에 직접적으로 관여하여 스킨 제작자들을 도울 것입니다.

• CSS 프레임웍을 이용하여 간단하게 화면의 배치와 성질을 바꿀 수 있도록 구현한 예제.
• HTML 보기.
• CSS 프레임웍 파일.
• CSS 프레임웍 파일에 사용자 정의 스타일 코드를 추가(override)한 파일.

이 밖에 더 많은 예제들이 OUIF | XEUI 페이지에 링크되어 있습니다.