기획자가 알아야 할 퍼블리싱 이슈
프로젝트를 진행하다 보면 크고 작은 사건(?)들이 발생하게 되는데, 미리 업무별 담당자의 협의로 최소화 시켜 나갈 필요가 있다.
이하는 기획파트에서 대수롭지않게(?) 생각하거나, 자주 빠트릴 수 있는… 실무에 영향을 끼칠수 있는 잦은 예를 찾아보았다.
1. 표준과 비표준에 대한 이해
2. 폰트 사이즈
3. 프린트기능
4. 사용자 입력부분 (게시판)
5. 논리적으로 구성되지 않은 컨텐츠
6. 동적, 기능적 구성에 관한 구체적 명시
7. 웹2.0 용어의 오해
1. 표준과 비표준에 대한 이해
사이트 제작시에 표준에 대한 여건을 명확히 알려줄 필요가 있다.
표준과 비표준사이에는 동원되는 css의 기술이 확연이 달라서 한번 제작하고 난 후에 표준과 비표준의 전환은 쉬운일이 아님을 알아야 한다.
표준으로 제작중 혹은 제작후에
“아 죄송해요~ 클라이언트측에서 DTD위에 뿌려줘야하는 코드가 있다고 하네용~” 라는 말을 듣는다면 기획자에 대한 퍼블리셔의 신뢰도는 바닥으로 추락할수 있으니 사전에 꼭! 표준과 비표준에 대한 인지를 해야한다.
2. 폰트 사이즈
먼저 폰트 사이즈는 절대단위와 상대단위가 있다.
각각의 장단점을 인지한 후에 프로젝트에 어떻게 적용할것인가를 판단해야 한다.
물론 퍼블리셔가 먼저 주도적으로 제안해 나갈 수도 있지만, 사이트의 정책과 향후 운영방안에 따라 기획자와 함께 커뮤니케이션이 이루어져 결정하는것이 좋겠다.
상대단위의 폰트로 사이트를 제작하게 되면, 브라우저의 자체기능인 폰트 사이즈 조절로 기능이 가능하다.
브라우저의 보기 -> 텍스트 크기, 혹은 Ctrl + 마우스 휠로 조절 가능하다.
그러나 최근의 브라우저들은 절대단위의 폰트도 브라우저 자체에서 사이즈조정이 가능하므로 (익스플로러6 제외), 프로젝트의 성격을 잘 파악하여 상대단위의 폰트 제작을 해야할지 판단이 필요하다.
* 폰트 사이즈가 단지 px단위로 기술되는지, em(%)단위로 기술되는지만 따지면 안된다.
“px를 em으로만 바꾸면 되는거아녜요” 라고 한다면 큰오산!
늘어나는 폰트사이즈에 대해 상대적으로 배경이미지나 레이아웃도 그 형태를 유지할수 있도록 하는것은 중급이상의 기술이므로 애초에 결정지을 필요가 있다.
이글을 쓰는 시점에서는 익스6과 파폭에서는 em단위의 폰트라도 이미지에 대해서는 확대 축소가 되지 않고 있다.
익스7과 오페라에서는 이미지와 폰트 모두 확대해 주는 기능을 가지고 있으나, 익스7에서는 축소 확대기능이 아직 미흡한 편임.
** 폰트사이즈를 전체 영역에 관해 조절가능하게 할지, 혹은 일부에 관해 확대/축소기능을 제공할지도 기획단계에서 결정지어져야한다.
마찬가지로 웹표준인지, 비표준인지에 따라 제작형태가 달라지게 된다.
** 브라우저 자체의 기능을 이용할지, 별도의 개발로서 확대/축소를 제공할지도 미리 결정지어져야 한다.
이또한 제작방법에 영향을 주기때문이다.
*** 대부분의 경우 상대크기의 폰트가 사용자에게서 환영받지 못하는건, 사용자가 해당 기능을 인지못하고 있는 경우가 그 이유이며, 또하나는 이경우 폰트사이즈가 작게 혹은 크게 설정되어있는걸 모르고 사이트를 이용하면서 나오는 불만이다.
기획단에서부터 이부분에 대한 고려가 이루어 져야한다.
예를 들어, 퀵메뉴나 상단 등.. 잘 보이는 곳에 폰트사이즈에 대한 가이드를 제시하거나, 별도로 확대/축소 기능을 추가로 제공할 수도 있다.
3. 프린트기능
항상 나중에 고려되곤 하는 프린트 기능이다.
되풀이 되지만 처음부터! 고려되어야 하는 사항중 하나이다.
폰트사이즈처럼 브라우저에는 자체로 인쇄미리보기 및 인쇄기능이 있고, 다행이 사용자들도 그나마(?) 알고 있는 기능이다.
비표준 방식에서는 페이지의 일정영역을 가져와 새창으로 뿌려주는 방식을 많이 이용했지만, 표준으로 제작할경우 css만으로 쉽게 프린트 기능을 이용할 수 있다. 이럴경우 본문에 위치한 ‘프린트 버튼’은 단순히 브라우저의 프린트 기능을 연결하기만 하면된다.
하지만 특별히 인쇄용 화면이 새창으로 뜰경우에는 개발이 필요하니, 미리 퍼블리셔와 개발자와 협의가 필요하다.
* 배경이미지의 경우엔 대게 브라우저 기본값은 ‘인쇄안함’으로 설정되어 있다.
이럴경우 많은 블릿이미지나, 구분되는 배경이미지를 사용할 수 없게 되므로 주의해야한다.
print용 css를 제작함에 좀 일이 늘어나겠지만, 배경이미지 대신 font-weight나 border등을 이용해서 표현할 수 있게 제작이 가능하다.
4. 솔루션
솔루션이 쓰일경우 해당 솔루션이 웹표준과 비표준에 어떻게 영향을 받는지 파악이 중요하다.
기껏 웹표준으로 작업했는데 해당 솔루션이 지원안하거나 솔루션으로 인해 퍼블리싱이 망가질때 퍼블리셔들은 속으로 눈물을 흘린다. (실제로도 흘린다.)
가장 큰예가 게시판에 사용자 입력부분인데, 만약 html방식으로 입력이 가능할 경우에 문제가 생긴다.
<b>, <u>, <font>등의 비표준 태그가 쓰이는건 둘째치고 사용자가 입력한 css가 충돌이 나서 - 이경우 사용자가 알고 하는게 아니라 어딘가에서 copy & paste할경우가 대부분- 레이아웃이 깨지기도 하고, table이나 div등의 사이즈가 본문사이즈보다 클 경우도 마찬가지이다.
(어떤경우엔 붙여넣은 내용이 태그가 완전히 닫히지도 않는 상황도 있다. xhtml에서는 문제가 된다.)
역시 개발, 퍼블리싱, 기획단에서 함께 협의해야할 문제이나…대부분 기획단에서 마무리되어 넘어가곤 한다.
다른 솔루션 예는 TTS 음성 서비스 솔루션인데, 다행이 최근에는 사용이 지양되고 있으므로 나아지고 있는 상황이다.
5. 논리적으로 구성되지 않은 컨텐츠
스토리보드를 보고 디자인한 후, 퍼블리싱 단계를 일반적으로 거치게 된다.
이때, 스토리보드에 애매한 위치에 의미가 명확하지 않은 컨텐츠가 있을때, 디자이너가 임의로 디자인해서 넘어오는 경우가 왕왕 있다.
대부분 ‘디자인적’으로 표현된 컨텐츠일 수도 있고, 의미가 있는 컨텐츠 일수도 있다.
퍼블리셔들은 모든 컨텐츠에 의미를 부여하여 그에 맞는 태그를 주므로, 이처럼 의미를 파악하기 힘든 컨텐츠의 경우 대뜸 올라가 항의하곤 한다.
개발에서 뿌려지는 ‘특정입력값’을 일반 ‘컨텐츠’사이에 넣어 구별할수 없게 된다던가 하는 등 주의가 필요하다.
6. 동적, 기능적 구성에 관한 구체적 명시
마우스 오버시 효과, 메뉴의 동적 구성등에 관해 디자인 스타일 가이드에 포함되어 제시되어야 한다.
대부분의 스타일 가이드에는 이런한 동적 구성에 관한 별도의 지시사항이 없다.
공들인 만큼 ui가 개선되므로 꼼꼼히 챙겨야 한다.
7. ‘웹2.0′ 용어의 오해
굳이 쓸 필요가 있을까 싶지만, 종종 이런 단어를 듣을 경우가 있어서 거론해본다.
‘웹2.0′이란 단어는 추상적인 개념일뿐, 뭔가를 지칭하거나 기술되기 어려운 단어이다.
마케팅적으로 “우리는 웹2.0 으로 사이트르 만들어 드립니다.” 라고 사용되는건 애교로 봐줄수 있지만…
웹표준방식의 퍼블리싱 기법을 말하려 한다지만 ‘웹2.0코딩’이란 말은 애초에 존재하지 않는다.
퍼블리셔 면접보는 면접관님들은 꼭 알아두시기 바란다.