현실은 시궁창 (iPad 단상)

1. iPad가 출시되면 사기는 살 건데...

2. 뭐하는 기기냐고 와이프도 묻고 해서 대답은 PMP + ebook리더 + 게임기라고 답해줬음.

3. iPad는 TabletPC가 아님. Tablet은 맞지만.

4. iPod Touch를 쭈~욱 늘려놓은 거라고 생각하면 됨.

5. 즉 주머니버전 대신 가방버전.

6. 넷북을 업무용 서브노트북 쯤으로 사용하는 사람이라면 iPad가지고 아무것도 못함. (오피스와 IE가 없으니까???)

7. 여전히 영화를 보려면 자막이랑 합쳐서 인코딩해야 할 듯. <- 귀찮음.

8. iTunes Store에 한국영화들이 올라올 수 있을까? <- 일단 지금은 현시창

9. ebook 보기는 좋을 듯 한데, 마땅한 ebook이 없음 <- 역시 불법다운...

10. iTunes Store에 한국 ebook이 올라올 날은 언제? <- 일단 울나라 출판사들이 ebook부터 좀 찍어줘야만... 역시 일단은 현시창

11. 게등위인지 뭔지에서 게임심의조건을 풀어주지 않는 한, 한국에서 iTunes Store의 게임 카테고리는 열리기 어려움 <- 다시 한번 현시창

12. PMP + eBook 리더 + 게임기라는 컨셉은 한국에서는 삼천포가 되려나...

13. 사야 하나? T_T

14. 미국 계정이 있으니까, 미국영화 사고, 미국 책 읽고, 미국 게임 하면 되지만... -_-a

15. 샀다가 와이프가 이게 뭐여!!! 라고 할 것 같음. 이래저래 현시창.

술을 먹으러 갔는데...

그저께는 거래처 분들이 술을 산다길래 쫄래쫄래 나갔습니다. (원래 맡은 업무가 거래처랑 술먹는 일)

1차로 참치를 먹고, 2차를 어디로 갈까 하다가... 좋은 곳(?)에 가자, 오랜만에 한국에 들어온 거니까 자기는 꼭 놀고 싶었다. 오늘 밤새도록(?) 놀아보자... 등등의 말로 저를 꼬셔서 데리고 간 곳은...

나.이.트. 였습니다. oTL..

아니, 진짜로, 룸싸롱이라든가.. 이런 거 기대안했다면 거짓말이긴 한데, 어쨌든 우리 회사는 '윤리경영'의 원칙에 따라 부적절한 접대를 지양하므로, 룸같은데 가자고 했다면 거절했겠습니다만(진짜?).

나이트라니요.. 일천구백구십오년도 이후 십오년 만에 나이트라는 곳에 가보았습니다.

그런데, 일단 멤버 구성이... 제가 제일 어립니다. 서른일곱에 애 둘 딸린 유부남인 제가 말이죠. 거기에다 넥타이에 양복이란 말이죠. 즉, 칙칙한 아저씨들이라는 거죠.

부킹을 시켜주던데, 3번 딱지 맞았습니다. 당연한 이야기.

그러니 역시 당연히 기분이 더러워지잖아요. 이거슨 어쩔 수 없는 진리. 게다가 이쪽은 남자 네명인데, 부킹에서 4:4 짝이 맞기가 어렵잖아요. 평일이라 사람도 없는데. 그러다보니 짝도 안맞고, 계속 딱지맞고. 어차피 더 진도(?)나갈 것도 아닌데, 공연히 부킹온 아가씨(?) 아줌마(?)한테 껄떡대는 것도 웃기고.

술 얻어먹으러 와서 이게 뭔 시츄에이숑인가 싶더라구요. 그래서 걍 인사하고 나왔습니다.

오늘은 그날 그 업체의 경쟁업체쪽에서 술 산다고 나오라고 하더군요. 또 쫄래쫄래 나갑니다. 설마 또 나이트는 아니겠지요.

결론 : 거래처 접대할 때 나이트는 가지마세요. 상대방 기분 더럽게 만드는 데 15분도 안걸립니다. 룸같은데 데려가도 마찬가지이긴 한데, 나이트니, 노래빠니 이런 데 데려가서 원초적으로 논다고 해봤자 술깨고 생각해보면 진짜 뻘쭘한 짓이에요. 차라리 정 성의를 보이고 대접하고 싶다면 근사한 식사 한끼 사는 정도면 충분합니다.

ps. 하긴, '갑'이 먼저 요구하는 경우들이 있긴 하죠. 우리 회사는 그런 '갑'이 아니므로 패스.

접근성 및 모바일 환경을 위한 메일 작성가이드라인(광고메일, DM 등)

1. 메일 클라이언트는 사용자마다 다릅니다.

Naver 웹메일, Outlook 2007, Gmail, iPhone 메일함… 다종 다양한 환경에서 이용자들은 메일을 봅니다. 메일 클라이언트들은 벤더에 따라 다르며, 또한 버전 및 사용자의 환경설정에 따라 또 달라집니다. 따라서 특정 메일 클라이언트에서는 문제없는 메일이라 하더라도 다른 메일 클라이언트를 사용하는 사용자에게는 문제가 될 수 있습니다.

 

2. CSS 지원여부

메일 클라이언트가 HTML을 지원하는 것은 필수가 아닙니다. 따라서 메일 클라이언트마다 다 다른 형태로 HTML 렌더링을 지원합니다. 예를 들어 Outlook 2007은 Internet Explorer에 탑재된 렌더링엔진대신, MS-Word 2007에 들어있는 렌더링엔진을 사용합니다. 그러나 Outlook 2003은 IE 6 렌더링엔진을 이용합니다. 따라서 HTML 태그가 똑 같은 모양으로 렌더링될 거라는 보장이 없습니다.

 

2-1. <style> & <link>

현재 유통되고 있는 메일 클라이언트 (웹메일 포함)의 일부는 Style 태그나 link 태그를 사용할 수 없는 경우들이 있습니다. 따라서 외부 CSS 혹은 내부 CSS 사용이 될 거라는 보장이 없습니다.

 

2-2. CSS Selectors

선택적 CSS 셀렉터가 안되는 경우들이 많습니다. (어차피 style, link 태그를 못쓰는 경우들을 고려한다면 불필요한 이야기)

 

2-3. 문제가 있을 수 있는 CSS 속성들

background-color, background-image, background-position, background-repeat, border, border-collapse, border-spacing, bottom, caption-side, clip, cursor, clear, direction, display, empty-cells, float, font-family, font-variant, height, left, letter-spacing, line-height, list-style-image, list-style-position, list-style-type, margin, opacity, overflow, padding,  position, right, table-layout, text-indent, text-transform, top,vertical-align,  visibility, white-space, width, word-spacing, z-index…

 

사실 엄밀히 말하자면 모든 CSS에 다 문제가 있을 수 있습니다. 이메일은 HTML문서가 아니기 때문에 정상적으로 렌더링될거라는 보장을 하면 안됩니다.

 

Inline-css (HTML의 style attribute를 이용)의 경우는 상대적으로 잘 지원되지만, 이 경우에도 단축형은 지원하지 않는 케이스들이 있습니다.

 

결론 : inline-css를 제외하고는 CSS 사용에 문제있음. 가능하면 CSS를 이용하여 디자인하지 말 것. Inline-css 에서도 모든 속성이 제대로 지원될 거라는 보장없음.

 

3. 폭과 정렬

일부 메일 클라이언트의 경우, 표시되는 메일 본문의 폭이 매우 좁을 수도 있습니다. 특히 모바일 환경에서 볼 경우에는 메일 클라이언트에 따라 그 폭이 200pixel 미만일 수도 있습니다.

또, 대부분의 메일 클라이언트는 가운데 정렬이 지원되지 않을 수 있으며, 시도할 경우 레이아웃이 매우 이상하게 바뀔 수 있습니다. 좌측정렬을 기본으로 삼아야 합니다.

결론 : 장폭의 이미지, 긴 URL의 링크 등을 그대로 제공하지 말 것.

 

4. table 태그의 이용

Table이 반드시 지원될 거라는 보장은 없지만, 그나마 레이아웃을 잡기 위해서는 table 태그를 사용할 수 밖에 없습니다.

HTML 4.0 기준의 Table 관련 태그들은 제법 다양한 메일 클라이언트에서 지원되며, css property를 사용함에 제한이 있으므로 table이나 td 태그의 html attribute (border, valign, align, cellspacing, cellpadding 등)을 이용하면 레이아웃을 잡을 수 있습니다. 그러나 colspan이나 중첩 테이블 등의 경우 제대로 표시된다는 보장이 없습니다. 100% 보장되는 것은 아니므로 가능한 다단 편집대신 1단으로 컨텐트를 구성하는 쪽이 바람직합니다.

혹시 table 관련 태그를 사용할 경우, width를 지정하겠다면 가능한 한 픽셀단위 고정폭을 사용하지 말고, %단위의 가변폭을 사용하는 쪽이 바람직합니다.(사용자 환경을 알 수 없으므로 렌더링될  넓이를 정확히 추측할 수 없기 때문.) 또한 가장 바깥쪽 넓이를 100%로 잡을 경우 몇몇 웹메일 클라이언트에서는 제대로 렌더링되지 않는 문제가 발생할 수도 있으므로 주의해야 합니다. (그러나 반대로, 몇몇 메일 클라이언트에서는 %단위를 사용하는 것 자체가 문제가 될 수도 있음. 어쩌란 말이냐… -_-a)

 

5. 각종 embed 요소

심지어는 img 태그마저도 제대로 안 걸릴 수 있습니다. 나아가 플래시 등을 로딩하기 위한 embed 태그나 javascript 등은 사용하지 마세요. (특히, 버튼이나 링크등을 javascript로 작성하지 말 것!)

결론 : embed, javascript.. 이런 거 전부 쓰지 말 것.

 

6. background image

백그라운드 이미지는, 없어도 되는 이미지가 백그라운드 이미지입니다.

1) 전달해야할 텍스트 컨텐트가 없는 이미지라면 백그라운드 이미지입니다.

2) 전달해야할 텍스트 컨텐트가 포함된 이미지라면 img 태그를 사용하세요.

3) 백그라운드 이미지는 table td 태그의 background-image attribute를 이용하여 표시할 수 있지만, 이 경우에도 제대로 표시될 거라 확신할 수 없습니다. 따라서 백그라운드 이미지는 “없어도 메시지 전달에 지장없는” 이미지여야 합니다.

 

7. image

<img> 태그는 제법 잘 쓸 수 있습니다. 주의할 점은, sliced image를 남발하지 마세요. 제대로 된 위치에 출력되리라는 보장이 없습니다. 꼭 복잡한 이미지를 써야겠다면 table 태그를 이용하여 레이아웃을 잡고, 가능한한 백그라운드 이미지로 통이미지를 쓰는 쪽이 더 나을 수 있습니다. 단, 이렇게 잡은 이미지와 레이아웃이 반드시 생각대로 표시된다는 보장이 없으므로 중요한 핵심메시지를 img 태그 혹은 백그라운드 이미지로 넣으면 안됩니다.

이미지가 표시되지 않는 경우, 해당 이미지가 전달하려던 메시지가 안보이게 되므로 반드시 alt 속성을 이용해서 대체텍스트를 제공해야 합니다. 또, width,height 속성을 정확히 사용해서 이미지가 표시되지 않더라도 해당 영역을 확보함으로써 레이아웃이 깨지지 않도록 처리해줘야 합니다.

결론 : 브라우저의 이미지 표시 옵션을 끄고서도 메일의 내용이 이해될 수 있도록 해야 함.

 

8. 사용해서 안전한 HTML 요소

결론은 없습니다. Plain Text를 제외한 모든 HTML 요소들의 이용을 보장할 수 없습니다. 그러나 통계상 다음 HTML 요소들의 순서대로 제법 많은 메일 클라이언트에서 지원되므로 최소한으로 사용은 가능합니다.

-      <a> : 그러나 hyper-text 링크가 표시안되는 경우가 있으므로 사용자가 복사해서 이용할 수 있는 대체 URL 문자열을 같이 출력시켜주는 쪽이 좋습니다. 또한, 가능한한, 링크의 오픈 타겟은 target=”_blank”를 사용해서 새 창에서 열리도록 하는 것이 좋습니다. 그렇지 않은 경우 일부 웹메일 사용자에게는 매우 불쾌한 경험이 될 수 있습니다.

또한, 문서내 anchor가 먹지 않는 경우가 있으니 #을 이용한 anchor 사용은 자제해야합니다.

-      <img> : 일부 속성이 적용되지 않을 수 있습니다. 이미지 자체의 출력이 안되는 경우도 있습니다. 특히 모바일 환경의 메일 클라이언트에서는 네트웍사용량을 줄이기 위해 img를 선택적으로 로딩하는 경우도 있습니다. 이런 경우 등을 대비하기 위해 “alt=” 속성을 이용해서 이미지의 내용을 보여주는 대체텍스트를 작성해야 합니다.

Ex) <img src=”http://somewhere.com/image/order_confirm_message.gif” alt=”고객님의 주문이 접수되었습니다.”/>

-      <p>, <div>, <span>, <a>, <td>, <h1>,<blockquote> : 이런 류의 block/group element 들은 제법 잘 지원되는 편이며, 심지어 style attribute도 일부 지원합니다. 오히려 <font> 태그가 제대로 지원안되는 경우들이 있으니, <p style=”font-family:Tahoma”> 같은 형태가 더 안전할 수 있습니다.

 

 

9. 수신확인은 불가능하다.

RFC3798 등의 규약에서는 메일 헤더에 Receipt 정보를 요구할 수 있게 되어 있으나, 이를 적용하지 않는 메일 클라이언트가 더 많은 현황입니다.

따라서 일부 웹메일에서는 별도로 자체서비스 이용자들간에서만 수신확인을 DB접근 기록등을 토대로 제공하기도 하나 전체 서비스에서는 적용되기 어려운 방법입니다.

한동안 안보이는 작은 이미지 등을 써서 HTTP Request 정보를 이용하여 오픈 여부를 확인하는 방법들을 쓰기도 했었으나 이러한 방법 역시 이미지 출력이 제한되어 있거나, POP/IMAP 등을 이용하는 사용자에게는 작동하지 않는 경우가 있으므로 별로 신뢰할 수 없으며, 마찬가지 이유로 JavaScript를 이용하는 방법도 사용할 수 없습니다.

결론 : 수신확인을 위해 애쓰지 말 것.

 

10. 결론

1) 고객에게 반드시 전달되어야 할 모든 메시지는 반드시 텍스트로 만들어져야 합니다.

2) 텍스트 밑에 백그라운드로 이미지를 까는 것은 상관없습니다. (단 CSS로 제어는 안된다고 가정해야 함.)

3) 일부 컨텐트가 반드시 강조되어야 해서 이미지로 메시지를 작성할 경우, alt, width, height를 반드시 작성해야 이미지가 표시되지 않는 환경에서도 사용할 수 있습니다.

4) 모바일 환경에서는 특히 이미지를 표시안하는 경우가 디폴트나 다름없으므로 반드시 주의해야 합니다.

5) script를 절대로 쓰지 마세요.

 

 

Reference

 

http://www.email-standards.org/

http://www.birdhouse.org/etc/evilmail.html

http://www.mailchimp.com/articles/how_to_code_html_emails/

http://mailchimp.blogs.com/blog/2006/01/im_a_web_design.html

http://www.w3.org/TR/1998/NOTE-HTMLThreading-0105

http://msdn.microsoft.com/en-us/library/aa338201.aspx

http://articles.sitepoint.com/article/code-html-email-newsletters

http://www.campaignmonitor.com/templates/

http://www.xavierfrenette.com/articles/css-support-in-webmail/

 

Good News, Bad News

Good News.

우리 회사도 아이폰 사준대요.

Bad News.

저는 이미 피같은 제값 다주고 첫날 구매했어요.

ps.

그냥 아이폰 받아서 와이프 주기로 했음.

ps2.

회사에서 사주는 아이폰은 16G. 난 32G니까...

아드레날린 중독증

- Adrenaline Junkies and Template Zombies (프로젝트가 서쪽으로 간 까닭은) 은 작년에 읽은 책 중 가장 가치있는 책이라 할 만하다. 86개의 프로젝트 진행 패턴 모두 언급할 가치가 있어, 하루에 1개정도씩 내가 처한 상황과 맞춰서 포스팅할 예정...

1. 아드레날린 중독증

첫 패턴이 이것이라는 것이 의미심장. 내가 이 책에 꽂히게 된 이유이기도 하고.

내가 이끌고 있는 기획1팀은 현재 8명이 소속되어, 이미 오픈된 3개의 서비스를 책임지고 있고, 1개의 서비스가 오픈 예정이며, 4개의 서비스를 추가로 준비하고 있고, 3개의 서비스가 보류중이다. 그외로 2개의 서비스가 곧 통폐합 예정이며, 2개 정도의 프로젝트를(서비스 모델은 아닌) 별도로 진행하고 있다.

8명이다.

하나의 팀으로서는 결코 작다고 할 수 없는 팀이긴 하나, 그렇다고 위에 언급된 업무들을 모두 해내기에 충분한 인력은 아니다.

그럼에도 불구하고 흘러가게 되는 이유는, 우리 회사의 전체적인 분위기가 전형적인 아드레날린 중독증세를 보이기 때문이다.

1) 정시퇴근이 죄악시된다. - 물론 어느 누구도 야근을 강요하지 않는다. 그러나 비즈니스 기회, 고객만족, 당장 던져진 과업 등의 명목은 자발적인(?) 추가근무를 강요한다.

2) 슈퍼맨을 원한다. - 100% 효율은 당연한 것이고 120%, 130% 효율을 요구한다.

3) 의사결정이 빠르다. - 단지, 의사결정이 빠른 것이 나쁘다는 것은 아니다. Agile 스타일의 '준비, 발사, 조준' 정도가 아니라, 아예 '발사, 준비, 조준' 형태로 일이 진행된다는 것.

4) 모든 것이 유동적이다. - 다른 말로는 기민하다고 표현하겠지만, 반대로 준비한 것 없이 진행하면서 닥치는 대로 수습해야 한다는 뜻이기도 하다.

솔직히 고백하자면, 사장님이 가장 심한 아드레날린 중독증세. 여기에 제동을 걸어야 할 팀장인 나 자신도 '프로젝트 매춘부' 스타일이다보니 설상가상.

일은 많이 하는데, 성과는 크지 않고, 만족도는 떨어지고, 위험도는 증가한다. 나자신을 포함한 팀원 모두 불만이 쌓여가는 형태.

어째서 강력하게 반대하지 못하냐고? 사장님은 똑같은 스타일로 이미 '성공'을 한 상태. 반대로 '성공'의 키워드가 이런 아드레날린 중독증이라고 생각하시고 있음. 그 경험칙이 깨어지지 않는 한 어떠한 반대도 통용되지 않음. 반대의 방법으로 동등한 실적을 쌓지 못하는 한 고양이 목에 방울 달기 임.

책에서는, 아드레날린 중독증은 치료할 수 없다고 되어 있음. 이 문제를 어떻게 해결할 것인가가 남은 회사생활의 가장 큰 화두인 셈이다.

프로젝트가 서쪽으로 간 까닭은 - 톰 드마르코 외 지음, 박재호 외 옮김/인사이트

새해

고양이과 맹수의 해입니다. 쥐를 잡는 한 해가 되길 바랍니다.