Design도 잘하고 markup도 잘 작성하는 사람이 있다면 더 없이 좋겠지만, 단점이 있다.
Design을 하면서 markup생각을 하게 된다. 아무래도 상상의 나래를 펼치는데 제약이 될 수밖에 없다. 웹디자이너도 사람인지라 디자인 할때는 디자인만, 마크업할때는 마크업만 생각할 수가 없다.

디자인하면서 "이런 레이아웃은 마크업 작성할때 까다롭거나 크로스브라우징에서 분명 문제가 생길꺼야" 라는 생각 안해 본사람이 있을까?

이건 그저 정신수양 말고 다른 방법이 없을것 같다.
아니면 내안에 다중이를 키우거나...

최근에 책에서 본건데...
그럴때는 컴퓨터 앞을 떠나서 연필을 들고, 종이에 스케치를 하라고 한다.
그런다고 markup 생각이 없어 질까만은.... 아예 효과가 없을것 같지는 않다. 
TAG markup
홈페이지를 만드는 일이 업이거나 혹은 지망할 경우 기본적인 디자인 실력은 물론 markup skill도 갖춰야 한다. 물론 국내 유수의 웹에이전시나 세분화가 잘 되어 있는 대규모의 업체라면 논외이지만, 우리나라 대부분의 기업에서는 디자인도 잘하고, 코딩도 잘하고, 기왕이면 자바스크립트 베껴쓰는 정도의 능력을 갖추면 금상첨화이고, 프로그래밍에 기본적인 지식까지 있다면 완전 사랑받는 디자이너라고 할 수 있을것 같다. (우리나라에서 웹관련 종사자들은 정말 슈퍼맨이다.)

markup도 visual design 못지 않게 창의적이고 체계적인 사고방식이 필요한것 같다. 오랜시간 블로그 관리자 화면과 블로그 스킨을 만들면서 하나의 markup이 모든 상황을 모두 커버할수 있는건 아니지만, 어느정도 업무의 효율성은 가져올 수 있다.... 라는 당연한 이론을 뼈저리게 깨닫기 까지는 참 오랜이 걸린것 같다.

사실 나도 수년전만 해도 table로 layout을 구성할 때가 있었다. 그러다가 웹표준, 접근성, 웹2.0등을 접했는데... 사람은 변화를 받아들이는데 참 인색한것 같다. 전에는 몇시간안에 끝났던 코딩이 두배, 세배의 시간이 걸리기 시작하고, 브라우저마다 출력을 달리해주는 통에 고생은 또 배가 되면서 무작정 회의적인 생각만 들었었다.

어느정도 코딩에 익숙해지고, Cross browsing을 당연하게 생각하게 되면서부터 생각이 달라지기 시작했다. 어떻게 하면 더 효율적으로 markup을 할 수 있을지 고민하기 시작했는데.... 그러면서 markup하는데 또 엄청난 시간이 들었다. 이렇게도 해보고 저렇게도 해보고... 뭔가 정답을 바랬던것 같다.

그러다가 효율적인 markup에는 정답이 없다며 포기하기 시작하니까 마음도 편해지고, 또 다른 시선이 생기기 시작했다. 그건 그냥 자신이 정답을 만들면 되는것 같다. 나름대로의 rule을 만들어 그 rule대로 일관성있게 작업을 하면 된다.

사설이 너무 길었는데...
자신만의 knowhow를 서로 공유하면 좋을것 같아서 몇가지만 얘기해보려고 한다.

1. 축약하지 말고 가능하면 변수에 모든 의미를 담아라

authorProf(△) → 틀렸다기보다는 별로 좋지 않음.
authorProfile(O)

축약하고나면 나중에 긴가민가 한다. 직관적이지 않아서 본인조차 헛갈리는 경우가 생긴다.

2. rule을 만들었으면 일관성있게 끌고나가는게 중요한것 같다.

1번의 rule에 따르면 두 단어 이상일 경우가 많다. 그럴경우 class name을 만들때 세가지정도의 방법이 있다. 분명 더 많은 rule들이 존재하겠지만, 일반적인것들만 예를 든다면,

하이픈 : content-header(O)
언더라인 : content_header(O)
카멜표기 : contentHeader(O)

작업할때마다 어떤때는 하이픈이 좋아보이고, 어떨때는 언더라인이 좋아보이지만, 사실 좋아보이는 어떤건 없는것 같다. 일단 일관성을 가지는게 중요한것 같다.

3. common한 요소와 unique한 요소를 찾아라.

효율적인 markup의 핵심인것 같다. unique와 common을 적절히 사용하면 css의 코드 수를 확실히 줄일 수 있으며, 유지보수가 쉬워진다.
예를 들어 블로그 사이드바를 만들경우 각 사이드바 요소들마다 unique한 class명을 각각 주고, 모든 사이드바 요소에 common 클래스명을 동일하게 부여하면, 해당 사이드바 요소들을 동일한 디자인으로도 표현이 가능하고, 사이드바 요소중 원하는 요소의 디자인을 달리 할 수도 있다.

<div id="notice" class="widget">공지사항 리스트 </div>
<div id="category" class="widget">카테고리</div>
.
.
.
<div id="recentPost" class="widget">최글 글 </div>
<div id="recentComment" class="widget">최근에 올라온 댓글 </div>
<div id="recentTrackback" class="widget">최근에 받은 트랙백 </div>

widget라는 공통된 클래스명을 사용하여 일괄적으로 style를 적용할 수도 있고, 각각의 unique한 요소로 각각 다른 style를 적용할 수도 있다. 이 부분은 나중에 다시 다뤄볼 기회가 있으면 좋겠다.

4. 너무 많은 case에 대한 상황을 고려하지는 말자.

이건 주의해야할점에 가까운데 당장 생기지도 않을 너무 많은 상황에 대해 고려를 하기 시작하면 markup은 나도 모르는 괴물로 변해간다. 나중에 그 markup을 봤을때 이 레이어는 왜 넣은거지? 하며 아리송해진다. 엄청난 중첩 레이어에 side effect 때문에 결국 재활용은 커녕 markup을 새로 해야할지도 모른다. 당시 상황에 맞는 최적화된 markup은 나중에 재활용하기도 쉽다.


웹의 역사를 저장한다.

Bookmark | 2009.07.22 12:54 | leezche
이미 아는 사람도 많겠지만, remind차원에서,,,
plyfly.net을 검색해 보면 2003년부터 시작해서 작년초까지 archive되어 있다. 아마 티스토리로 잠깐 옮겨 2차 도메인을 쓰면서 기록이 멈춘것 같다.(확실치 않음) 심심풀이로 주요포털들을 검색해보면 초창기의 포털들의 모습을 볼 수 있다. (참고로 plyfly.net을 운영하기 시작한건 2001년부터이다. 10주년이 얼마 안남은것 같다. )


-
-
-
-

아래 이미지는 1998년말 google의 모습니다
User image
 
TAG 기록

이건 그냥 여러 블로그를 다니면서 느낀건데 블로그를 방문하면 꼭 보게되는 영역만 본다는 것이다. 특히 처음 방문하거나, 오랜만에 방문하거나, 아주 띄엄띄엄 방문하는 방문자라고 가정했을때 그 행동패턴이 더 정형화 되어 있는것 같다.

  1. 먼저 첫페이지 글들을 쭈욱 훑어본다.
  2. 카테고리를 본다. 어떤 카테고리가 있는지, 글들은 얼마나 있는지 본다.
  3. 공지사항이 있나 본다. 보통 해당 블로그가 어떤 블로그인지 주인장은 어떤 사람인지에 관심을 가진다.
  4. 태그클라우드에 눈길을 한번 준다.
  5. 링크를 본다.
  6. 카운터도 한번 본다.

대충 이런 순이다.

블로그를 이용하는 사람을 크게 두 부류로 나눠보면...
블로그를 운영하는 사람, 블로그를 방문하는 사람이 있다.
하지만, 블로그 하나를 놓고 봤을때 블로그를 방문하는 방문자의 사용이 훨씬 더 많다.

블로그에는 운영자가 주로 이용하는 영역이 있고, 방문자가 주로 이용하는 영역이 있다. (물론 관리자 화면은 운영자만 볼수 있기 때문에 논외로 한다. 일단 블로그 화면만 보자)

블로그 운영자는 누가 댓글을 달았는지, 누가 방명록에 글을 남겼는지, 누가 트랙백을 보냈는지를 주로보게 되는데 거의 feedback에 관련된 것들이다.

그렇다면 방문자는 주로 무엇을 보게 될까? 물론 블로그를 방문한 목적인 글을 보기 위함이 제일 클것이다. 그렇다면 글 외에는? 나의 경우에는 카테고리, 카운터, 태그클라우드, 공지사항, 최근글, 검색 정도를 들 수 있다. 아마 이건 개인마다 혹은 방문한 블로그의 성격마다, 혹은 블로그를 방문한 빈도수마다 약간의 차이가 있을 수 있을것이다.

그렇다면 스킨을 만들때, 특히 사이드바를 만들때
좀 더 방문자를 배려한다면 방문자를 위한 사이드바 요소들의 순위를 먼저 나열해 보고, 강조해보면 어떨까?

  1. 검색: 일단 부피가 작고, 작은만큼 눈에 잘 안 띌 수 있기 때문에 제일 상단에 위치시켜도 좋을것 같다.
  2. 공지사항: 카테고리가 더 중요 할 수도 있지만, 공지사항의 부피가 작기 때문에 카테고리보다 상위에 위치해도 좋을것 같다. 보통 한 두개, 많아야 두 세개 정도 될듯하다.
  3. 카테고리 : 카테고리는 태그클라우드보다 블로그의 성격을 가장 잘 파악하게 해주는 요소이다. 카테고리가 중요함에도 불구하고 검색과 공지사항 다음에 위치하는 만큼 다른 요소들 보다 더 '강조'해주는것이 좋을 것 같다.
  4. 태그클라우드: 태그클라우드도 어느정도 블로그의 성격을 정의해 주기는 하지만, 가끔 잘못된길로 인도하기도 한다. 약간은 재미적인 요소가 더 크다는 느낌이다.
  5. 최근글: 사실 최근에 쓴글 목록 보다는 그냥 페이지를 넘겨서 훑어 보는 편인데 이건 제목이 내용을 잘 대변해주지 못하고 있다는 내 편견일 수도 있다고 생각이 든다. 다른 사람들은 어떠려나..
  6. 링크: 이건 종종 보는 편이다. 블로그 운영자의 또다른 관심사나 지인관계를 알고 싶은 훔쳐보고 싶은 묘한 심리랄까? 예전에 이웃로그가 이런 역할을 했던것 같은데.. ㅠ ㅠ;; 사실 나는 링크를 최근글 보다 더 상위에 위치시키고 싶다.

이 정도를 상위에 위치시키고, 나머지 운영자를 위한 사이드바 요소를 아래에 위치시켜보는게 어떨까? 물론 정답이란 있을 수 없지만, 블로그를 운영하는 사람이라면 방문자를 위해 단 5분만이라도 고민해 보면 어떨까 싶다.

관련글
- How to Decide How Many Columns are Best for your Blog

Design Patterns

Design note | 2009.07.17 13:19 | leezche

설치형 텍스트큐브의 UI

Skin story | 2009.07.17 13:15 | leezche
설치형 텍스트큐브의 UI는
불편하고, 예쁘지 않다.
기본적으로 grid가 엉망이다.
grid가 잘 맞춰져 있는 UI는 사용자로 하여금 피곤함을 덜어준다.
기본중의 기본이라고 할 수 있다.

css를 조금 손보려고 하였으나, 효율적이지 못했다.
이내 포기했다.
css만으로는 모든 상황을 커버할 수가 없다.

설치형 텍스트큐브는 오픈소스인데
디자이너가 참여하기엔 장벽이 너무 크다.

텍스트큐브의 UI를 개선하려는 디자이너가 단 한명이라도 있다면
지금보다는 편한 UI를 많은 사람들이 접할 수 있을것 같다.

관리자 화면도 블로그 화면처럼 치환자를 이용한 스킨 시스템이라면
그 단 한명의 디자이너가 더 나은 텍스트큐브를 만드는데 도움을 줄 수 있지 않을까?

텍스트큐브는 정말 좋은 블로그 툴 임에도 불구하고,
그 빛을 발하지 못하는 이유중에 하나가 UI인 것 같다.

하지만 지금 상황은 그 누구도 탓할 수가 없다.
사실 감사하다고 절을 해도 모자랄 판이다.

사실 나도 스킨을 만들어 배포하면서
내가 만든 스킨을 이렇게 해달라 저렇게 해 달라는 이야기가 나올때마다.
힘이  빠진다.
아마 시간이 남아돌아 텍스트큐브를 만드는 사람은 없을거다.

다들 텍스트큐브에 대해 생각도 많고, 하고 싶은것도 많을테지만,
그렇게 하지 못하는 이유를 너무 잘 알것 같다.

감사하며 그냥 써야겠다.
스킨이나 열심히 만들어야겠다.. :)