여름 휴가차 8/2부터 큐슈 온천 여행을 계획하고 있습니다. 처음에는 렌터카로 큐슈를 쭉 돌아볼까 했는데, 날씨도 더운데 돌아다니면 고생만 할 것 같아서 편히 쉴 수 있는 쿠로카와 온천을 중심으로 한 계획을 세웠습니다.
쿠로카와 온천은 후쿠오카에서 대략 3시간, 유후인에서 대략 1시간 반쯤 걸리는 곳에 위치해 있는 산골 온천 마을로, 주로 일본인들이 많이 찾는, 일본 이외에는 아직 많이 알려지지 않은 곳이라 합니다. 쿠로카와 온천에는 24개의 료칸온천이 하천을 끼고 모여있고 온천 조합에서 1200엔짜리 마패 같은 것을 사면 3군데까지 온천을 맘대로 이용할 수 있다고 합니다. 료칸마다 온천들이 특색이 있게 달라서 한번씩 다 구경해보는 것도 재미있을 것 같더군요. 한때 이 여행을 계획하면서 와이프하고 이번 여행의 테마는 "온천 master!!"라고 하면 24개 온천을 다 가보자는 의기 양양한 결의도 했었지만... 온천 물속에만 하루 종일 있을 생각을 하니.. 자제를 해야겠다는 생각이 들더군요.
우선 여행의 예산은 와이프와 함께 인당 1백만원, 총 2백만원으로 잡고 그 한도내에서 이리저리 최대한 좋은 곳으로만 가보려고 계획을 세웠습니다. 우선 순위가 가장 높은 쿠로카와의 료칸을 중심으로 후쿠오카 및 유후인 일정도 살짝 넣어서 일정과 계획을 만들어보니 다음과 같은 계획이 나오더군요.
유후인노모리 관광열차나 먹는데 비용을 아끼지 않아서 약간 초과하긴 했지만, 이 정도면 별 무리없이 5박 6일 일정으로 잘 다녀올 수 있을 것 같더군요. 다행히 그 비싼 쿠로카와에서 카이세키 요리를 빼고 2만엔 정도에 싸게 나온 숙박이 있어서 비용이 대략 맞았던 것 같습니다.
일본 드라마에 보면 온천 물에 술상 띄워놓고 사케 마시는 모습이 나오는데, 꼭 해보고 싶더군요. 정 안되면 온천물 들어가서 맥주라도...
티스토리 베타 테스팅이 한창 진행중인데, 티스토리의 flexible layout에 걸맞는 장난감 하나 만들어봤습니다.
요즘 웹 어플리케이션들은 RIA기술의 발달로 데스크탑 어플리케이션과 견줄 수 있는 인터페이스를 제공해줄 수 있게 되었고, 그래서 웹과 데스크탑의 경계를 허물고 있는 관련 기술들이 계속 나오고 있습니다. Adobe AIR, Mozilla Prism, Google Gears등이 그와 같은 맥락에서 웹과 데스크탑의 경계를 모호하게 만들고 있습니다.
일반 브라우저로 웹 어플리케이션을 이용하는 것과 SSB로 웹 어플리케이션을 이용하는 것은 사용상에 있어서의 차이점은 없습니다. 하지만 SSB를 이용할 때에 해당 웹 어플리케이션만을 위한 minimal한 기능 및 디자인을 탑재한 가벼운 브라우저를 이용할 수 있고 해당 웹 어플리케이션만을 위한 별도의 프로세스로 어플리케이션이 작동하기 때문에 브라우저 오작동으로 여러탭에 묶여있다가 한번에 접속해있던 사이트가 모두 닫히는 경우도 방지할 수 있습니다. 게다가 데스크탑 OS와의 자연스러운 통합 기능은 마치 웹 사이트를 데스크탑 어플리케이션처럼 이용할 수 있게 해줍니다.
서두가 좀 길었는데, 암튼 이번 티스토리 개편과 함께 만들어본 장난감이 무엇이냐하면, 바로 SSB를 이용한 티스토리 어플리케이션입니다.
위의 스크린 샷을 보면 MacOSX의 dock에 있는 여러 어플리케이션중에 티스토리 아이콘을 볼 수 있습니다. 마치 MacOSX전용 어플리케이션처럼 보이죠. 작동하는 모습을 잠깐 볼까요?
티스토리 어플리케이션을 만들기 위해 Fluid를 이용하였고, User Scripting기능을 이용해서 자동 로그인까지 되도록 했습니다. 윈도우의 틀도 약간 검은 색의 look and feel로 변경하여 티스토리 상단 바의 색과 맞췄고, 화면이 시작할 때 자동으로 1024x768 윈도우 사이즈가 되도록 했습니다.
티스토리 어플리케이션 만들기
우선 준비물이 필요합니다. MacOSX 10.5 Leopard와 Fluid를 준비해주세요.
Fluid를 실행하면 다음과 같은 화면이 나오는데, URL에는 티스토리 관리화면 URL을 넣어주시고, Name에는 블로그 제목이나 "티스토리"라고 적어주시면 됩니다. Location은 어플리케이션이 생성될 위치인데, 이왕이면 "Applications"디렉토리가 좋겠죠. 그리고 Icon은 어플리케이션 아이콘을 넣는 곳인데, favicon을 다운로드하여 넣거나 아니면 어플리케이션 아이콘으로 쓸 이미지를 따로 지정을 해도 욉니다.
위의 설정들을하고 Create버튼을 누르면 어플리케이션이 생성됩니다.
저는 제 블로그 주소 URL을 이름으로 지정해서 mtgear.net이라고 나옵니다. 더블 클릭을 하여 실행을 해보면 주소창이나 북마크 툴 바 등이 없는 깔끔한 창에 둘러싸인 티스토리 로그인 화면이 나오고 로그인을 하면 티스토리 관리화면으로 넘어갑니다. 생성된 어플리케이션을 Dock으로 이동하면 일반 macosx어플리케이션과 같이 dock에서도 바로 실행할 수 있습니다.
2차 도메인을 사용하는 경우 로그인을 하게 되면 새로운 브라우저가 뜨면서 밖으로 튀어 나가는 경우가 있는데, 이는 fluid가 다른 도메인으로 화면이 바뀌는 경우 외부 브라우저를 사용하도록 되어있기 때문입니다. 티스토리에서는 2차 도메인으로 접속을 해도 로그인할 때에는 1차 도메인으로 접속을하기 때문에 1차 도메인도 어플리케이션 내에서 사용가능하도록 추가해야합니다. 추가 방법은 설정 -> Advanced에서 Allow browsing to any URL을 선택하든지 아니면 *tistory.com*을 추가하여 tistory.com과의 모든 접속을 허용하면 됩니다.
여기까지 하면 기본적인 티스토리 어플리케이션의 골격은 만들었고 이제 좀 더 편리하게 사용하기 위해 자동 로그인, 최적 사이즈(1024x768)로 맞추기 기능을 추가해보겠습니다. 아래 그림에서 보면 스크립트 아이콘의 메뉴가 있고 펼쳐보면 아래와 같은 메뉴 아이템들이 쭉 나옵니다. 여기에서 New Userscript를 선택하고 스크립트의 이름을 입력하면 xcode가 실행되고 자바스크립트 코드 스텁이 생성됩니다.
Xcode 편집 화면에서 다음과 같은 코드를 입력하세요.
(function () { if (window.fluid) { with (document.getElementById("LoginForm")) {
loginid.value = "*****@******.com"; // 로그인 ID
password.value = "*****"; // 로그인 암호
submit();
}
window.resizeTo(1024, 768); // 최적의 창 사이즈 조절.
}
})();
위의 코드에서 loginid.value와 password.value의 값은 로그인시 사용되는 email주소와 암호를 입력하면 됩니다. 이렇게 해서 저장하고 Command+Q로 티스토리 어플리케이션을 완전 종료하였다가 다시 시작하면 로그인하지 않고 바로 관리화면으로 들어갑니다. 야호~!
자 그럼 완성된 모습을 볼까요?
Updated: Fluid 홈페이지가 접속이 안되네요. 임시로 제가 쓰고 있는 fluid파일을 다운로드할 수 있도록 올려놨습니다.
1차로 티스토리 관리의 센터부분과 에디터 부분이 오픈되었고 추후 2주에 걸쳐서 점진적 오픈이 될 예정입니다.
크게 달라진 부분은 다음과 같습니다.
1. Flexible Layout 도입
기존에 정적 레이아웃을 가진 관리화면에서 보다 데스크탑 어플리케이션스러운 동적 레이아웃으로 바뀌어 화면 변화를 보다 효율적으로 수용할 수 있는 구조로 바뀌었습니다. 사용자와의 인터렉션이 많은 관리 화면이기 때문에 전통적인 웹의 레이아웃보다는 데스크탑의 어플리케이션과 같은 유연한 레이아웃이 훨씬 더 효율적이라 생각됩니다.
2. 센터 요소 편집
센터에 나오는 요소들에 대한 편집이 가능하졌습니다. 센터에서 보여줄 요소를 선택하거나 위치를 원하는데로 배치하는 것이 가능합니다. 개인적으로 블로그 방문 통계등이 항상 궁금한데 센터 상단에 유입 경로, 유입 키워드, 방문자 통계등의 컴포넌트를 배치해놓으니 한눈에 볼 수 있어서 좋네요.
3. 에디터 개선
다음 카페에 적용되었던 '다음에디터'(구 파워에디터)가 적용이 되었습니다. 역시 브라우저의 화면을 충분히 활용하는 어플스러운 레이아웃이 디폴트로 사용되어 공간활용도가 높고 원하는 기능을 쉽고 빠르게 가져다 쓸 수 있어서 좋습니다.
가장 마음에 드는건 이제는 MacOSX의 safari에서도 WYSIWYG 글 작성, 편집이 가능해졌다는 것입니다. 전에는 주로 맥에서 safari를 쓰다가도 티스토리에 글을 쓸 때에는 firefox를 쓰곤 했었는데, 이제는 그럴 필요가 없어졌네요. 지금도 맥의 safari에서 글을 작성하고 있는 중입니다.
작년부터 관련된 프로젝트들이 사용자와의 상호작용이 많은 프로젝트들이라 그런지 지금까지의 일반적인 웹 레이아웃에 대한 고민을 해볼 기회가 자주생기는군요.
문제점
디자이너도 아니면서 웹 디자인 레이아웃에 대해 고민하게 된 것은 브라우저의 스크롤바 때문이었습니다. 블로그 글이나 신문 기사같이 쭉 읽어내려가는 웹페이지의 경우에는 보통 잡지나 책과 같은 구성을 하고 있어서 읽어내려가기 쉽게 가로보다는 세로로 긴 구성을 하고 있습니다. 하지만 모니터는 어떻습니까? 거의 대부분이 세로보다는 가로로 길죠. 더군다다 요즘에는 와이드 모니터들이 많아져서 가로 길이가 상대적으로 더 길어지고 있습니다. 그래서 어쩔 수 없이 거의 대부분 브라우저에 상하 스크롤바가 생기게 되죠. 그래도 마우스 스크롤을 하거나 스페이스 키(Page Down)를 톡톡 쳐가면서 보면 하번에 웹페이지의 내용이 다 나오지 않더라도 그럭저럭 볼만은 합니다. 즉, 의도한 목적(글 읽기)를 하는데 별 불편함은 못 느낄 정도입니다. (읽기 위주의 페이지에서도 스크롤바가 문제되는 경우도 있는데 이 이야기는 다음번에 하도록 하겠습니다.)
하지만 편집, 관리와 같이 사용자와의 상호작용이 많은 페이지들은 기존의 위에서 아래로 스크롤이 생길 정도로 길게 흐르는 구성으로는 불편할 수 밖에 없습니다 . 우선 이러한 페이지들은 사용자가 화면에서 정보를 읽어내는 것 뿐만이 아니라 상호작용 요소를 통해서 액션을 취할 수도 있고 때로는 정보를 거꾸로 전달할 수도 있는데 이러한 상호작용 요소가 브라우저에 스크롤바가 생기면 움직이기 때문이죠. 자꾸 버튼이나 입력 필드가 왔다갔다 움직이는 것도 신경쓰이는데, 더 안 좋은 경우는 웹페이지가 상하로 길고 상호작용 요소가 상, 하단에 흩어져 있다면 한 화면에 모두 나타나지 않아서 스크롤을 해가며 액션을 취해야합니다.
현상적으로는 스크롤바의 존재 유무나 위치로 인해 불편함이 느껴지는데 이는 웹 페이지의 레이아웃 구성 자체가 상호작용에는 적합하지 않게 되어있기 때문에 발생하는 문제라 생각됩니다. 또한 반대로 적절한 스크롤바의 사용이나 적절한 요소에 스크롤바가 생긴다면 오히려 편리하게 느껴질 수도 있겠죠.
글쓰기 화면을 생각해봅시다.
좀 더 구체적인 얘를 생각해봅시다. 블로그에서 글을 쓰려면 제목도 입력해야하고 때로는 공개 설정도 입력해야합니다. 태그도 입력해야하고, 파일 첨부도 해야합니다. 상당히 기능이 많고 기능의 수에 비례해서 버튼이나 입력 필드와 같은 상호작용 요소의 수도 많습니다.
보통 웹에서 제공하는 글쓰기화면에서는 제목, 카테고리와 같은 필수 설정 영역들이 맨 위에 있고 바로 이어서 툴바를 비롯한 에디팅 영역이 나오고 그 하단에 파일 첨부나, 공개 설정, 태그와 같은 부가 설정 영역들이 뒤따라오는 것이 일반적인 구성입니다.
보통은 에디팅 영역의 상하 길이도 꽤 길기 때문에 에디팅 영역조차 전부 나오지 않는 경우도 있습니다.
이렇게 배치된 경우, 사용자가 착실하게 필수 설정 영역 -> 에디팅 영역 -> 부가 설정 영역의 순으로 편집을 하게 되면 별 문제가 없을 수 있습니다.
하지만 대부분 그렇지 않을 겁니다. 글을 먼저 쓰고 제목을 바꾸고 싶을 때가 있을 것이고 태그도 생각나면 태그도 입력 했다가 다시 글을 쓰기도 하고, 색을 바꾸기도 하는등 여러가지 설정들이 많아지면 이리저리 왔다갔다하는 경우가 많아지게 될 겁니다. 위의 그림에서 점선으로 된 박스가 브라우저를 통해서 보이는 영역인데 화면의 아랫단에 있는 공개설정과 같은 부가 설정을 하기 위해서는 아래 그림과 같이 브라우저 스크롤을 이용해 화면을 아래로 이동시켜야합니다.
스크롤을 아래로 이동시켜 놓고 편집을 하다가 카테고리 변경과 같은 작업을 해야하게 되면 다시 또 스크롤을 하여 화면을 올려야합니다. 위의 그림에서만 봐도 스크롤을 하지 않고 한번에 접근할 수 있는 영역이 두 영역밖에 되지 않죠. 다른 기능들을 사용하려면 스크롤을 할 수 밖에 없게 되고, 글이 길어져서 에디팅 영역에 상하 스크롤바가 생기게 되면 커서의 현재 위치에 따라 마우스 휠을 굴렸을 때 움직여지는 스크롤바가 다르니 마우스 휠로 스크롤하는 것도 마우스 커서 위치를 봐가면서 해야하니 불편하게 되겠죠. 쓰고 있는 글에서 편집할 위치를 찾기 위해 마우스를 굴렸는데, 브라우저 스크롤이 작동해서 화면이 흐트러지면 살짝 난감해질겁니다.
마우스 스크롤 하는게 사실 손가락 조금 움직이는 것이라 별로 불편하지 않아서 그 정도는 별 불편함을 못느낀다고 할 수도 있겠지만 글쓰기 화면을 MS워드와 같은 데스크탑 어플리케이션과 비교해보면 생각이 달라질 수도 있습니다. RIA 기술이 발달하지 않았을 때에는 데스크탑 어플리케이션과 비교하기 힘들었겠지만, 요즘 웹 기술로는 데스크탑 어플리케이션과 같은 사용성이나 레이아웃은 충분히 낼 수가 있기 때문에 더욱 욕심이 날 수 밖에 없습니다.
Work-around
보통 어플리케이션이라고 하면 데스크탑 PC에서 실행되는 브라우저나 오피스와 같은 프로그램을 얘기합니다. 사용자가 거의 시스템의 리소스를 독점해서 사용하다시피 하고 네트웍 지연도 없기 때문에 데스크탑 어플리케이션들은 뛰어난 사용성과 빠른 반응성을 보여줍니다. 사용자의 모니터의 크기가 다양하고 선호하는 창의 크기가 다르기 때문에 데스크탑 어플리케이션들은 어플리케이션 창의 크기가 조절되는 것을 당연히 받아들였고 그 결과 유연하고, 상대성을 고려한 디자인, 레이아웃을 가지고 있습니다. 게다가 다양한 상호작용까지 고려를 하고 있습니다. 그리고 이러한 유연한 레이아웃의 구성은 절대적인 위치보다는 상대적인 위치, 절대적인 길이보다는 상대적인 길이, 그리고 정적인 출판물이 아닌 동적인 툴이라는 원칙에서 온 것이라 생각됩니다.
요즘에는 웹에서도 사용자들에게 상당한 상호작용을 원하고 있고, 웹을 사용하는 것이 데스크탑 어플리케이션을 사용하는 것과 구분이 잘 안 되는 상황에 와있습니다. 요즘 웹 서비스들은 데스크탑 어플리케이션을 대체할 수 있을 정도의 사용성, 기능을 보여주는 것들도 많이 있습니다. 구글 캘린더나 오피스, zoho, remember the milk등의 서비스들이 그러한 좋은 예가 될 것입니다. 이제는 "웹 페이지"의 시대가 아닌 "웹 어플리케이션"의 시대입니다. 그리고 웹 디자인의 메타포는 책, 잡지, 포스터, PDF리더 이외에도 MS워드, 오픈 오피스 writer와 같은 것들이 추가되어야 할 것 같습니다.
Fluid.zip
