상상공장 스킨공작소

Hi from Multitouch Barcelona on Vimeo.

여기에 사용된 이미지 소스는 Media Militia.com에서 제공하는 무료 이미지들을 사용하였습니다.

여기에 사용된 이미지 소스는 Media Militia.com에서 제공하는 무료 이미지들을 사용하였습니다.

웹에서 사용되는 텍스트에 대한 흥미로운 조사가 있다.
(물론 영문 활자를 기반으로 한 조사이다. )

요약해 보면

웹사이트 구축시 텍스트를 위한 가이드라인 작성할때 도움이 많이 될것 같다. 물론 한글을 기본으로 발표된 자료가 있으면 더 좋겠지만 말이다. 우리 나라에서 하나 아쉬운점은 사용할 수 있는 폰트가 극히 제한되어 있고, 별로 미려하지 못하다는 거다. (돋움, 아니면 굴림. 물론 명조도 있긴 하지만...) 인터넷 속도는 한국이 미국에 15년 앞서 있다는데... 폰트 시스템은 그에 훨씬 못 미치는것 같다. 디자인을 하는데 있어서는 열악하기가 그지 없는것 같다. 디자이너들은 잘 알것이다. 폰트가 차지하는 비중이 얼마나 큰지...

꽤 오래된 사이트인데 사이트가 많이 축소된것 같다. 한때 디자인 한답시고 여기저기 웹을 돌아다니며 스펀지가 되었던적이 있는데 그때 알았던 사이트이다. 갑자기 정말 갑자기 불현듯 생각난 사이트이다. 다행히 지금까지 URL을 잊지 않고 있었다. 깔끔한 UI가 상당히 매력적이였던 기억이 난다.

지금은 아마 이런쪽으로 영역을 확장한듯!
creative가 있는 사람들은 한번 시도해볼만 할것 같다.

디자이너 공민선의 개인 홈페이지로 제품 패키지나, 포스터등의 작업물들을 볼 수 있다.
최근에는 가수들의 앨범이나 포스터를 주로 작업하고 있는것 같다.

잡지 PAPER의 "정신과 영수증"이라는 아트웍을 통해 처음 알게 되었는데 지금은 그때만큼 아이디얼한 작품을 많이 하지는 않지만, 참고할만한 작업물들이 많이 있다.

<em>
emphasis, 강조의 의미를 담고있는 태그로 보통의 브라우저에서는 <i>태그와 같이 이탤릭체로 표현이 된다. <i>태그는 강조의 의미를 담고 있지 않고, 다만 문자의 모양을 기울여줄 뿐이다.
ex) 나는 네가 지난 여름에 한 일을 알고 있다

<strong>
stronger emphasis, 강한 강조의 의미를 담고 있고, <b>태그와 같이 볼드체로 표현이 되며, 역시 <b>태그는 강조의 의미가 아니라 문자의 모양을 굵은 글꼴로 표현해 줄 뿐이다.
ex) 나는 네가 지난 여름에 한 일을 알고 있다

<dfn>
defining, 특정한 용어를 정의할 때 쓰인다.

<address>
address,  홈페이지 내에서 제작자의 연락 정보를 위해 주소나 e-mail 정보를 나타낼때 사용한다.

<code>
code, 홈페이지에서 특수 문자를 표현하려면 "<"은 "&lt;"로 작성해야 하는데, 이를 그대로 표시하기 위해서 사용

<samp>
프로그램이나 스크립트의 실행 결과를 표시하기 위해 사용

<kbd>
keyboard text, 키보드의 특정 키 입력을 설명할때 사용

<var>
프로그램의 변수를 위해 사용

<cite>
인용문이나 참조한 문서의 출처를 표시하기 위해 사용

<abbr>
약어를 표시하기 위해 사용

<acronym>
단어의 첫글자만 따서 만든 두문자어를 표기하기 위해 사용

<blockquote>
block quotation, block요소의 인용문, 들여쓰기의 형태로 인용문 표현

<q>
inline요소의 인용문, 문장 사이에서 따옴표의 형태로 인용문 표현

<sup>
위첨자를 표현하기 위해 사용

<sub>
아래첨자를 표현하기 위해 사용

<ins>
문서에서 추가된 내용을 표시하기 위해서 사용

<del>
문서에서 삭제된 내용을 표시하기 위해서 사용

<pre>
preformatted text, 프로그램 소스 코드와 같이 특수 문자를 포함한 내용이나 공백등을 그대로 표시해 준다.

XHTML 작성할때는 <table>태그를 사용하면 안되나요?
<table>태그는 행과 열이 있는 데이터를 표시하기 위한 목적을 가지고 있습니다. <table>태그도 엄연히 나름대로 사용용도를 가지고 있으니 당연히 사용해도 되지요. 다만 레이아웃을 위한 태그가 아닌데, 사람들은 종종 레이아웃을 위해 <table>태그를 사용한다는것에 문제가 있습니다.

<form>을 서밋하기 위해서 이미지버튼을 사용하면 안되나요?
당연히 이미지를 이용해서 버튼을 만들수도 있습니다. 다만 그것이 <a> 태그를 이용한 자바스크립트 형태가 아닌 <input> 태그를 이용한 이미지 버튼이여야 합니다. <input type="image"> 이렇게 사용하는것이 올바른 사용입니다.
여기서 잠깐! <form>을 사용하면 여백이 생겨서 가끔 <tr> 태그 사이에 넣어버리는 경우가 있는데, 이는 <form>태그에 에 margin 값이 기본으로 들어가 있어서 그런것이니, 스타일에 margin값을 0으로 작성해주면 되겠지요.

위 두가지 예제 모두, "얼마나 의미에 맞게 태그를 사용하는가"에 대한 문제 인것 같습니다. 웹표준을 준수하는 문서를 작성하는데 가장 기본적인 마음가짐이겠지요. ^^

XHTML 1.0 Strict 로 DOCTYPE를 규정하면 좀 더 쳬계적인 문서로 거듭날 수 있는데, 많은 사람들이 XHTML 1.0 Transitional 을 고집하는 이유는 무엇을까요?

역시 아는 사람은 다 알겠지만, 브라우저 호환성을 보장해 주기 위해서 하고 합니다. XHTML 1.0 Strict 에서는 <center>, <u>, <strike>, <applet> 등의 태그를 사용하지 못합니다. 하지만 여전히 많은 브라우저에서 위 태그들을 허용하고 있기때문에 현재의 브라우저 호환성을 위해서는 XHTML 1.0 Transitional로 DOCTYPE를 규정하는것이 어쩌면 당연하다고 할수 있겠습니다.

뭐 어느정도 예상하고 있는 답안지였지만, 확실하게 못박고나니 속이 시원하네요!

오랫동안 함께 디자인을 해왔지만, 나는 웹2.0이라는 트렌드에 발을 담그게 되었고, 내 지인은 여전히 치열한 작은 규모의 에이전시에서 일을 하고 있다.  사실 작지는 않지만, 워낙 작은 인원으로 여러 프로젝트를 해야 하다보니 열악하다는 표현이 더 맞을 것 같다. 암튼 우리나라 대부분의 에이전시가 그렇듯 열악한 환경에서 시간에 쫓겨 프로젝트를 진행해야 하기 때문에 "웹표준 준수"라는 가치보다 "정해진 시간내에.."라는 것에 치중해 있다. 여전히 말이다.
웹표준 준수를 하게 되면 사실 더 치열해진다. 좀 익숙해지면 나을지는 모르겠지만 ...

암튼 각설하고... 그 지인이
"야.. html 로 선언하는거랑, xhtml로 선언하는거랑 뭐가 틀려? 그리고 웹표준을 준수하려면 꼭 xhtml로 선언해야 하는거야?" 라고 물어 봤다.
당연히 답은 알고 있지만, 막상 설명하려니 정리가 잘 안되서... 여기저기 뒤져보니.. 이렇게 간단명료하게 설명된 문장이 있어 옮겨 보았다. 

간단하게 정리하면, DOCTYPE은 한 문서가 사용하는 언어(그리고 그 수준)가 무엇인지를 선언하고 선택적으로 어떤 문서형 정의(DTD, Document Type Definition)를 사용하여 그 문서를 처리할 것인가를 선언하는데 사용되는 요소이다. 다른 말로 하면 문서 타입이라는 말이다.  by Eric Meyer

한마디로 html로 선언을 하든 xhtml로 선언을 하든 해당 DTD의 문법에 맞게 제대로만 사용하면 그게 웹표준!


관련글 : XHTML DTD(Document Type Definition)

World Wide Web Consortium

• XHTML1.1 W3C Recommendation : http://www.w3.org/TR/xhtml1/
• XHTML1.0 W3C Working Draft : http://www.w3.org/TR/xhtml11/
• XHTML2.0 W3C Working Draft : http://www.w3.org/TR/xhtml2/
• XHTML1.0 Document Type Definitions : http://www.w3.org/TR/xhtml1/dtds.html
• HTML 4.01 Specification : http://www.w3.org/TR/html401/

트리오 홈페이지

• XHTML 1.0 규격 한국어 번역문 : http://trio.co.kr/webrefer/xhtml/xhtmlidx.html
• XHTML 4.01 규격 한국어 번역문 : http://trio.co.kr/webrefer/xhtml/xhtmlidx.html

기타

• w3schools XHTML Tutorial : http://www.w3schools.com/xhtml/
• cadvance(XHTML 한글 Tutorial) : http://www.cadvance.org/doc/xhtml

white-space: normal

• 연속하는 공백 문자를 한개로 압축.
• 포함되어 있는 블록을 넘길때는 줄이 바뀜

white-space: pre

• 연속하는 공백 문자의 압축을 금지.
  
• pre를 지정한것과 같은 기능
• 내용이 포함블록에서 벗어날 가능성이 있음.
  (overflow:hidden 속성으로 처리)

white-space: nowrap

• 연속하는 공백 문자를 한 개로 압축
• 포함되어 있는 블록을 넘길때는 줄 바뀜이 되지 않음
• 행바꿈을 위해서는 /br를 이용
• 내용이 포함블록에서 벗어날 가능성이 있음.
  (overflow:hidden 속성으로 처리)
  

!   : Exclamation Point
"   : Quotation Mark
#  : Crosshatch
$  : Dollar Sign
% : Percent Sign
@ : At Sign
&   : Ampersand
'   : Aposterophe
*  : Asterisk
-  : Hyphen
.  : Period
/  : Slash
\  : Back Slash
:   : Colon
;   : Semicolon
^   : Circumflex
`   :  Grave
{   : Left Brace
} : Right Brace
[   : Left Braket
]   : Right Braket
|   : Vertical Bar
~   : Tilde

업무관련 대화나 회의를 할때 특수 문자 명칭을 모르거나 헛갈릴때가 간혹 있는데 알아두면 유용할것 같다. 물론 Exclamation Poin는 "느낌표", Quotation Mark는 "큰 따옴표"로 말을 해도 되겠지만, Braket 같은경우는 달리 뭐라고 해야할지 모르겠다. Vertical Bar도 그냥 "짝대기"라고 했던것 같다. ㅋ

이에 대응되는 한국말은 없을까?

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

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

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

최근에 책에서 본건데...
그럴때는 컴퓨터 앞을 떠나서 연필을 들고, 종이에 스케치를 하라고 한다.
그런다고 markup 생각이 없어 질까만은.... 아예 효과가 없을것 같지는 않다. 

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

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

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

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

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

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

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

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

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

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


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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

지난 3월 이후로 처음 글을 쓰는 거니까... plyfly.net에서 완전 백만년만에 쓰는 글 같다.

오늘 잠깐 짬을 내서 1.7.8로 업그레이드 했다. 뭐가 바뀐게 있나 이곳저곳을 돌아보다가 플러그인을 몽땅 켜놓고 글쓰기 화면으로 들어왔더니 뭔가 조금 바뀌긴 한것 같다. 아래 아이콘들도 많이 생기고... 저런건 다 플러그인 같긴한데... 어쨌거나... 상당히 오랜시간 방치하다가 들어와보니 조금 새로운 시선들이 생겼다. (사실 새롭진 않다. 예전부터 갖고 있던 생각들인데 새삼 다시 되새겨진달까)

관리자 화면의 UI와 visual 디자인이 조금 더 정리되고 세련되어졌으면 하는 마음도 있고...
(이건 그냥 직업병이다. 좀 더 편하고, 좀 더 예쁜 화면을 바라는... 아무리 완벽해도 내 눈에는 아마 사소한 것들이 눈에 들어올수도 있을것 같다. 그냥 병이다. )

정말 좋은 기능의 수많은 플러그인들이 여전히 친절하지 않다는것도 있고...
(이쪽 업계에 있는 나도 잘 모르겠는데... 다른 사람들은 오죽할까 싶기도 하다. 이건 스크린샷 몇개만 있어도 해결 될것 같은데... 다른 사람들은 전혀 신경 안쓸지도 모르겠다. 그냥 병이다. )

그리고 여전히 미련을 못버리고 있는 RSS페이퍼(이웃로그)가 다시 부활했으면 하는 생각이다.
(지금 내가 애용하고 있는 hanrss 도 있고, 여기 관리 화면에도 Rss로 수집된 글들을 볼수 있지만, 태터툴즈 초창기의 RSS페이퍼 만큼의 감흥은 없는것 같다. 여러 블로그들 돌아다니면서 RSS 페이퍼를 읽는 재미가 참으로 쏠쏠했던것 같다. 거의 이웃로그 폐인이였다고나 할까. 요즘 social이 붐인것 같은데... RSS 페이퍼야 말로 진정한 social의 초기 단계가 아니였던가 싶다. 그 당시 재훈님의 선견지명이 대단했던거다 분명! 근데 그걸 없앴으니... 거기서 조금만 발전해도 지금쯤이면 텍스트큐브가 워드프레스를 능가하는 툴이 되었을 것이다 분명! 암튼 난 그렇게 믿는다 지금도... 사람들은 벌써 그 존재에 대해서 잊었을지도 모르겠다. 이것도 그냥 이 쪽에 일을 너무 오래한탓에 병인것 같다.)

암튼 갑자기 텍스트큐브가 새로워진다. 2006년인가 처음 입사했을때의 초심이 생각나기도 하고, 그때 함께했던 사람들이 하나 둘 떠오르기도 하고... 2009년 지금 내 상황이 급생소해지기도 하고... 갑자기 설치형에 대한 무한 애정이 생겨 뭐라도 기여하고 싶은 마음이 마구 샘솟는다. 하지만 나는 못할꺼다. 2006년 이후보다 딱 여섯배정도 바빠진것 같다.

http://photl.com/

 

서로 잘 어울리는 색상들의 조합을 제공하며, 제공된 색상들의 조합을 바꿔볼수도 있다. 거기에 몇가지 variation을 제공하여 색상톤들을 다양하게 보여주고 있다. 사용된 색상의 색상값을 제공하여 바로 적용하여 사용해 볼 수도 있다.


Generator of color schemes and palettes to create good-looking and well balanced and harmonic web pages.
http://wellstyled.com/tools/colorscheme2/index-en.html

업로드한 사진을 흑백의 단순화된 이미지로 변환해 준다. 블로그의 프로필 이미지나 스킨을 만들때 사용하면 아주 유용할것 같다. 파란색과, 빨간색으로도 변환이 가능하고, 각 사이즈별로도 변환이 가능하다. 무엇보다 벡터기반의 svg(Scalable Vector Graphics) 파일 포맷으로도 변환된 파일을 다운로드 받을 수 있어 사용성이 무궁무진할것 같다.
* svg파일 포맷은 illustrator에서 편집이 가능하다.

http://browsershots.org/

아는 사람은 이미 알고 있는 웹사이트를 각종 브라우저에 따라 스크린샷을 제공하는 사이트입니다. 결과 화면도 느리고, 요청이 많으면 나중에 시도하라는 메세지도 나옵니다. 그렇기 때문에 개발용으로 사용하기보다는 그냥 자신의 블로그가 다른 OS의 다른 브라우저에서 어떻게 보이는지 재미삼아 해보세요.

대충 요랬던 IETester가 다음과 같이 버전업 되었네요.
 


탭브라우징이 대세이긴 한가 봅니다. 어쨌거나 정말 편해졌지 뭡니까.
다시 텍큐 만들고 다듬는 작업에 박차를 가해야겠습니다.  ^____________________^

IETester Download : http://www.my-debugbar.com/wiki/IETester/HomePage

텍스트큐브의 전신 태터툴즈 시절부터 작성되어져 왔던 스킨 매뉴얼을 텍스트큐브의 최신버전에 맞춰 내용을 업데이트 하였습니다. 텍스트큐브 설치형 스킨제작에 조금이나마 도움이 되어 더욱 더 다양한 텍스트큐브를 볼 수 있었으면 하는 사용자의 한사람으로 노가다좀 했습니다. ^^

설명 및 스크린샷은 플라이투 스킨을 예로 만들어졌습니다.

티스토리 스킨 매뉴얼은 "티스토리 스킨가이드"를 이용하시면 됩니다.
텍스트큐브 버전업에 따라 업데이트된 내용을 제외한 거의 모든 내용이 동일합니다.

플라이투 스킨은 ClearType을 지원하는 맑은고딕체를 기본으로 사용하고 있습니다. 먼저 맑은고딕체(비스타(Vista), MS 오피스 2007의 한글 공식 글꼴이라고 하네요)를 다운로드 받아 C:\Windows\Fonts에 복사해둡니다. 이렇게 설치된 맑은고딕체를 부드럽고 깔끔하게 보려면 ClearType속성을 이용해야 합니다.

ClearType이란 텍스트에 포토샵으로 작업한것과 같은 효과를 주어 텍스트를 좀 더 고급스럽게 보이도록 Anti Aliasing을 적용시켜 주는 기능입니다. 참고로 굴림이나 돋움체는 ClearType을 지원하지 않습니다.

ClearType을 적용하는 방법에 대하여 알아보겠습니다.

1. 바탕화면에서 마우스 오른쪽 버튼을 클릭하여 "속성"을 선택한 후 "화면 배색"탭으로 이동하여 "효과"버튼을 클릭합니다
   
2. "화면 글꼴의 가장자리를 다음는데 다음 방법 사용"에서 ClearType을 선택합니다.
   

참고로 ClearType을 좀 더 정교하게 설정할 수 있는 ClearType Tuner라는 것도 있습니다.

플라이투 스킨은 사이드바 230pixel, 본문영역이 500pixel이고, 여기에 여백등을 고려하면 스킨의 전체 사이즈가 820pixel 입니다. 여기에서 본문 영역을 넓게 쓰고자할때 어떤 부분을 어떻게 수정하면 되는지 알아보도록 하겠습니다.

step 01. style.css 파일을 편집하겠습니다.

1. "Layout"이라고 주석처리 되어 있는 곳으로 이동하면, container, content, sidebar 에 각각 width속성이 지정 되어 있습니다. 본문 영역을 200pixel 더 넓혀서 700pixel로 쓰고 싶다면, content의 width를 700px로 수정합니다. 이렇게 되면 스킨 전체 사이즈가 늘어 났기 때문에 container도 200pixel더해서 1020pixel로 수정해야 합니다.
2. "Article Basic Style"라고 주석처리 되어 있는 부분으로 이동하면 article 레이어에도 width가 지정되어 있습니다. 역시 700px로 수정합니다.
   * article의 width부분을 삭제하셔도 무방합니다. 다만, overflow:hidden; 을 content 레이어로 옯겨주시면 됩니다.
3. "Content Part" 라고 주석처리 되어 있는 부분으로 이동하면, writeForm 레이어에 textarea와 textField라는 클래스명을 가진 input폼의 가로 사이즈를 각각 200pixel 넓혀 주시면 됩니다. (* 방명록과 댓글이 writeForm이라는 동일한 클래스명을 사용하고 있기 때문에 한번만 수정해 주시면 두곳 모두 수정이 됩니다. )

step 02. index.xml 파일을 편집하겠습니다.

가장 아랫부분으로 이동하면 contentWidth를 지정하는 곳이 나옵니다. 이곳을 700으로 수정해 주어야 합니다. 이 부분이 스킨에 직접적인 영향을 미치는 것은 아닙니다. 다만 글을 작성할때 텍스트 입력폼의 사이즈를 이 수치로 반영하게 됩니다. 또한 본문에 이미지를 삽입할때도 이곳의 수치를 참고하여 이미지의 기본 가로 사이즈를 반영하게 됩니다.

요약하자면...

style.css의 Layout 에서

#container { width:820px;} → #container { width:1020px;}
#content { width:500px;} → #content { width:700px; overflow:hidden;}

style.css의 Article Basic Style 에서

.article { width:500px; overflow:hidden;} → .article { }

style.css의 Content Part 에서

#content .writeForm .textField { width:250px;} → #content .writeForm .textField { width:450px;}
#content .writeForm textarea { width:330px;} → #content .writeForm textarea { width:530px;}

index.xml에서

<contentWidth>500</contentWidth> →<contentWidth>700</contentWidth>