2010년 4월 19일 월요일

알라딘 아이폰 앱 유감

기대가 크면 실망이 크다지만, 이건 실망이라기 보다는 허탈에 가까운 앱이라 하겠다.

알라딘 앱 기획자가 누구인지 모르겠으나 진짜로 물어보고 싶다. 어떤 소비자를 대상으로 하냐고.

"음, 우아하게 스타벅스에서 한잔 마시면서, 혹은 버스타고 집에 가는 도중에 왠지 심심해져서 아이폰을 꺼내들고 알라딘 앱을 띄운 다음 베스트셀러나 신간특선이나 추천도서나 특가도서나 대충 훑어보다가, 어, 웬지 이거 끌리네, 하고 장바구니에 담은 다음, 결제를 한다..."

세상에, 누가 그렇게 책을 사나? 얼핏 책이 충동구매 같아 보여도, 책이야 말로 사람들이 가장 심사숙고(?)하는 상품이다.

(아이폰에 알라딘 앱을 설치할 만큼 도서구매에 관심있다면) 책을 구매하는 사람들은 대개 다음 패턴 중의 하나로 책을 구매한다.

1) 이미 사야 하는 책을 알고 있다. - 업무용이든, 교재든, 누군가의 추천이든, 정확하게 무엇을 사야한다라는 것을 알고 있는 경우들. 이런 경우 필요한 기능은, 해당 책에 얼마나 정확하고 빠르게 도달시켜주느냐가 중요하다.

2) 비슷한 책을 찾는다. - 좁게는 카테고리에서, 넓게는 다른 사람의 선택이나 관련있는 책 목록까지. 무언가에 대한 책이 필요는 한데, 정확하게 알지는 못한 상태에서는 검색으로부터 시작하여 관련 책들을 찾아나가는 탐색경로 및 평가지표가 필요하다. 알라딘은 특히 이 부분에 대해 웹서비스가 아주 강한 장점을 보이는데, 앱에서는 전혀 그러한 장점을 살리지 못했다.

3) 이미 경험했던 작가나 시리즈, 장르를 찾는다. - 1),2)가 목적성이 강하다면, 유희나 취미의 단계에서의 책의 구매는 이러한 패턴을 보인다. 따라서 해당 작가의 신간이라든가, 혹은 비슷한 취향의 다른 사람들의 데이터라든가 하는 정보가 가장 중요하다.

4) 개인화가 중요하다. - 알라딘 앱을 자발적으로 설치할만큼의 열성적인 독자/구매자라면 베스트셀러라고 해서 무조건 구매하지도 않고, 사은품을 많이 준다고 구매하지 않는다.(사려고 하는 책에 사은품이 들어있으면 고마울뿐.) 남들이 무엇을 보건 간에, 나에게 그 책이 어느 정도의 가치를 가지느냐가 책 구매에 중요한 지표가 된다. 1Q84가 아무리 많이 팔리건, 하루키를 싫어하는 사람이라면 쳐다보지 않을 것이며, 한편 하루키 팬이라면 1Q84가 베스트셀러가 아니라 하더라도 구매할 것이다. 물론 베스트셀러라 하여 혹하는 독자들도 있겠으나, 그런 정도의 독자가 과연 알라딘 앱을 설치할 것인가?
기존 알라딘 웹에서는 보관함 및 마이서재가 그 역할을 담당했고, 지금은 사라졌지만(?) 마이알라딘도 톡톡한 역할을 했었는데 흠....



사실 실제로 카드번호 입력하는 결제 단계는 도서구매자에게는 그다지 중요하지 않다. 결제를 결심하게끔 만드는 게 중요한 것이지. (뭐, 지금 정도의 불편함이라면 아무리 결심을 해도 때려치우겠다만.)

알라딘 앱의 목표는 책을 많이 팔려는 것인가? 아니면 회원들을 알라딘에 lock-in 시키는 것을 목표로 하는가? 전자라면... 글쎄. 일단 이정도 수준의 인터페이스로 그 고단한 구매과정을 구매자에게 요구한다면 책을 많이 팔기는 커녕 알라딘에 대한 혐오감만 불러일으키지 않을까?
후자라면 처음부터 방향이 틀렸다...


일단, 구매가 거의 불가능할 정도로 어렵다. 뭐하러 앱을 만들었는지 모르겠는데, 실제 결제과정은 그냥 PC용 웹페이지를 가져다 붙였다. 눈알빠지는 줄 알았다. 게다가,유용하게 사용했던 각종 정렬기능들도 사용할 수 없고, 평가나 리뷰 등도 한 눈에 안들어온다. 그냥 묻지마 구매하라는 뜻인가? 쿠폰할인은 사용법을 추측하는 데에만 10분 걸렸다. ThanksTo 적립도 안되고 적립금사용도 복잡하며 웹과의 장바구니 연동도 안된다. 결제 안되는 카드가 수두룩 한데다, 제휴카드마저도 제한이 걸려있다다. 편의점배송도 안된다. 이런 XXX!!!!
욕이 나올만도 한게, 알라딘에 나름 충성을 바쳐온 소비자로써(플래티늄회원인데 말이지...) 그동안 누려왔던 알라딘의 모든 장점을 단 한가지도!!!!!!!! 이용할 수 없다. 아니, 그런 불이익을 감수하면서까지 앱으로 꼭 결제를 해야할 만큼의 필요성은... 글쎄다. 그정도로 급하다면 차라리 버스에서 내려서 PC방비 1000원 지불하는 쪽이 적립금이라도 더 많이 쌓을 수 있겠다.


그냥 모바일 웹페이지나 잘 만들어 제공하는 쪽이 더 낫지 싶다. 진심으로.



그럼 현재 같은 모습이 아니라면, 인터넷 서점에는 어떤 앱이 필요할까?
Mobile이니까, Wireless니까, iPhone이니까 가능한 무언가를 찾아야 하지 않을까?
아래의 기능을 꼭 하나의 앱에서 구현할 필요는 없을테다. 가볍고 유용하고 재미만 있다면 알라딘 앱 시리즈를 여러개 까는 걸 불평할 사람은 없을테니.

1) meat-world에서의 검색/탐색
일단, 기껏 아이폰용 앱인데도 불구하고 타이핑이나 클릭으로 뭔가를 조작하려는 생각은 버려주시길.
올라웍스의 스캔서치인가 하는 앱을 보니, 표지만으로 책 검색이 되더구만. 그게 아니라면 에그몬 같은 앱은 바코드 촬영으로 책 검색이 된다. 문자 검색을 아예 배제할 수는 없겠지만, 모바일환경에서의 아이폰이라면 그에 맞게 오프라인의 책을 그대로 검색할 수 있어야겠다. (표지검색이든, 바코드 스캔이든, 타이틀 스캔이든... 기왕 촬영해서 스캔이 가능하다면 작가 이름이나 출판사 이름도 스캔 가능할 테고...)

이게 되면 다음과 같은 시나리오도 가능하다는 말씀.
"옆자리 동료가 읽고 있는 책이 좋다길래 슬쩍 들고와서 사진한방 찍어주고 돌려주면 그 책이 검색이 된다"

이 시나리오가 어떻게 확장되는지 다음의 유스케이스를 가정해보자.
"약속시간이 남아 교보문고에서 얼렁뚱땅 시간을 때우고 책을 구경하다가, 맘에 드는 책 발견! 아이폰을 꺼내 사진 한방 찍으면 알라딘에서 구매시 교보보다 얼마나 싼지 계산해주고 자동으로 내 보관함에 담기게 된다."

아예 캐치프레이즈로 만들어도 되겠다. "아이쇼핑은 교보에서, 구매는 알라딘에서."
쪼그만 iPhone 화면, 타이핑 요구하면 피곤하다.

2) 내 서재를 아이폰으로.
책을 많이 사는 사람들은 늘, 자기가 가지고 있는 책을 DB화 하고 싶은 욕구에 한번씩은 빠지게 된다. 스스로도 대견해보이니까.
그러나 대부분 조금 시도해보고 포기한다. 왜? 무지하게 손이 많이 가고, 귀찮기 때문에.
책장에서 책 꺼내서 사진 한방씩 찍어주면 자동으로 마이서재에 차곡차곡 담겨준다면 마이서재 활성화 및 마이리뷰 작성에 크게 도움되지 않을까?
더불어, 내가 책을 올해 얼마나 샀고, 얼마나 읽었고 또 목표를 세워서 얼마를 읽어야 하고... 등등의 독서일기 내지는 독서 계획관리등의 기능이 추가된다면 항상 몸에 지니고 다니는 아이폰의 특성상 개인의 독서도우미 역할을 톡톡히 할 수 있겠다. 책을 많이 읽으면, 많이 사게 되기 마련이니... 책을 많이 팔고 싶으면 독자가 책을 많이 읽도록 먼저 만들자.
아, 생각난 김에, 책을 다른 사람에게 빌려줬다든가 하는 기록도 남길 수 있다면 금상첨화. 이거 독서가나 장서가들에게는 언제나 풀리지 않는 골치거리였으니까.

3) 포토리뷰/밑줄긋기/리뷰남기기
네.네. 간단한 겁니다. 그냥 아이폰에서 포토리뷰 쉽게 작성하도록만 해줘도 되는 것. OCR 기능을 탑재해서 아예 책읽다가 책 페이지를 찍은 후에 문자인식 후, 필요한 부분만 긁어서 밑줄긋기라든가, 북마크(브라우저 북마크 말고)할 수만 있어도 좋겠다.
조금 나아가면, 버스안에서든 어디든, 책의 마지막 페이지를 덮은 후에, 그 감회가 잊혀지기 전에 리뷰를 작성한다든가. (장담하건데, 버스 내리면 그 때의 그 기분은 어느새 까먹게 된다니까.)
"마지막 책장을 덮고 나서, 책 뒷면의 바코드를 아이폰으로 찍은 후, 리뷰작성 버튼 누르고 한 줄 소감을 남긴다..." 음... 내가 생각해도 너무 자연스럽네.

4) 지역정보/Social Network
이 책을 산 사람들은 어디에 살고 있을까. 혹은 이 근처에 있는 사람들이 많이 사본 책은 무엇일까. 같은 것.
혹은,
"우리 동네 나와 같은 나이 또래에 미혼인 여성 중에 코맥 맥카시를 좋아하는 여자가.... 어라, 바로 옆 커피숍에 지금 있네..."
네. 알라딘제공 사랑의 짝대기 서비스도 농담은 아닐 수도...
취향, 그것도 책에 관한 취향은 개인의 성향과 아주 밀접한 것. 그러니까, 르 귄을 좋아하는 독자치고 나쁜 사람은 없다던가...
반대로 "아, 저 분은 겉은 멀쩡해보이는데 알고보니 양판소 매니아... 웁스." 같은 것도 가능하다는.

또는, 어차피 알라딘이 설마 중고판매 수수료를 엄청난 수익원으로 생각하지 않는다면, "이 책을 중고로 파는 사람들 중 가장 가까운 사람은 어디에??" 같은 서비스도 제공할 수 있겠지. 어차피 중고거래시의 문제는 애스크로처럼 복잡한 방법으로 해결하는 것보다는, 그냥 대면해서 그자리에서 거래해 버리면 그만이니까. 뭐, 알라딘이 중고판매 수수료로 한몫 벌 생각이라면 좀 어렵겠지만 설마 그럴라고. 품절이나 절판된 책을 찾는 독자들에 대한 lock-in 효과를 노렸던 것 아니었나?

5) 다 떠나서...
iPhone이나 iPad용 전자책 솔루션이나 만들어주시길. 얼마든지 구매해줄테니.


ps. 이 중 일부는 하신다고 하시더라... 하시거든, 다시 마주합시다. 아이폰에서는.

2010년 4월 13일 화요일

사람에겐 얼마만큼의 평수(?)가 필요한가.

iPad를 산 이유중에 가장 큰 것은 조만간 다가올(?) 전자책시대. 지금은 ebook이 없냐고 하겠지만, 까놓고 말해, 현재 국내의 ebook은 '책'이 아니지. 그냥 텍스트파일더미일뿐.

ebook에 관심이 있는 가장 큰 이유는 무엇보다도, '책'에 들어가는 비용 때문.

계산을 해보자.


내 방에 현재 책장이 5개가 있고, 1개의 폭은 약 1m. 1개당 7단으로 구성되어 있다. 1단 당 보관할 수 있는 책의 갯수는 약 30권. 두꺼운 책도 있고, 얇은 책도 있으니 정확히 계산하기는 어렵지만 평균 30권이라 하면, 현재 내 방에는 1000여권의 책이 수납되어 있는 셈이다.
책장 한개당 대략 반 평정도의 공간을 차지하고 있는 셈인데, 책장이라는 특성상 무조건 포개서 쌓아놓을 수도 없고, 책장의 배열도 고려하면 이 정도가 현재 내 방에 수납가능한 책의 총량. 즉, 2평 정도의 공간에 1000권이라 하겠다.

책 1권당 구매가를 10000원이라 치자면 1000만원 어치를 2평에 보관하고 있는 셈.

그런데 현재 아파트 시세가 평당 1000만원이라던가. 그러자면, 1000만원 어치 책을 2000만원 어치 공간에 보관해야 하는 역설이 생긴다. 즉, 책에 들어가는 비용은 단지 책의 가격이 아니라 그것에 두배 만큼을 구매,보관에 따른 기회비용으로 추가해야 한다. (과도할 정도로 단순화한 계산이라 엄밀히 따지자면 실제와는 다르지만. 실제로는 책의 크기라든가 이런 걸 따져야겠지...)

보관해둘 공간이 여의치 않다보니, 책을 구매할 때 자체 검열을 받게 된다. 책값이 부담스러운 게 아니라, 그 책의 보관이 걱정이 되서. 예를 들어 김용의 전작품 같은 거는 그냥 어렸을 때의 기억때문이라도 전부 구해서 소장하고 싶지만, 막상 그렇게 되면 다른 책들을 위한 공간이 없어진다!!! 길티 플레져라고 부를만한 장르문학뿐만 아니라, 별 쓰잘데기 없지만 가지고 싶은 책들도 많다. 가령 영국왕립무기박물관에서 출간한 '무기'라는 책은, 내가 그 책을 사서 실제적으로 써먹을 곳은 없겠지만, 그럼에도 불구하고 사보고 싶은 책... 이런 것들은 못사보게 된다.

자. 애서가가 되고 싶은가? 부자가 되어 넓은 집에 살기 전까지는 무리.


2010년 4월 10일 토요일

인증샷


책상 너무 지저분함.
요즘 이래놓고 삽니다.

그런데 회사에서 진짜 하고 있는 일은 전화로 고객답변해주기. 진상고객들 짱!

2010년 3월 23일 화요일

IE Error : KB927917

IE는 다른 브라우저들과는 달리, 자신이 속한 DOM 트리의 부모 엘리먼트를 조작하지 못하게 되어있다. 즉, 다음과 같은 코드는 에러를 만든다.

<div id="something">
  <script type="text/javascript">
    document.getElementById("something").appendChild(anything);
  </script>
</div>
자식엘리먼트에 속한 script블록이 자신의 부모엘리먼트에 대한 조작을 하려하고 있는 상태이다. 이 경우 다른 브라우저에서는 아무런 문제없이 정상작동하지만, IE에서는 KB927917 에러를 발생시킨다. 대표적인 조작 메쏘드는 appendChild, removeChild, innerHTML 등.

이 문제를 해결하기 위해서는 해당 스크립트를 조작대상 엘리먼트(이 경우에는 "something")의 바깥으로 빼면 된다. (애초에 모든 스크립트를 head 섹션안에 두고, body안에는 script 태그를 없애고, onload를 이용해서 Late Binding을 시켜주면 아예 발생하지 않는다만, 이렇게 리팩토링하라고 하면 모두 좌절할 듯. 게다가 텍큐는 내가 안짰다규... T_T)

MSDN을 보면 IE8에서는 이 버그가 해결되었다고 하는데(아주 자랑스럽게, 해결책을 "Upgrade to IE8"이라고 내놓고 있다.), 여전히 발생하는 걸 보면 안고쳐진게 틀림없는 듯.

아무튼 어제 쓴 포스팅에 대한 AS 차원의 글.



URL Shortener - 재수정 -

Permalink 처럼 Shortenlink라는 이름으로 Shorted URL이 블로그툴이나 기타 CMS에서 기본 제공되면 좋겠다. 굳이 goo.gl 같은 Shortener를 따로 쓰지 않게. (귀찮음)
예를 들어 텍스트큐브라면 "http://tc.it/XXXX" 같은 Shorted URL을 충분히 자체제공할 수 있지 않나?


--- 수정 ---

그래서 만들었음.

아래의 코드를  <body>바로 아래에 넣고,


<script type="text/javascript" defer="defer">
//<![CDATA[
var urlPool = new Array();
function  shortenURL(entry_id) {
  urlPool.push(entry_id);
}

function doShortenURL() {
  var len = urlPool.length;
  for (var i = 0; i < len; i++) {
    var entry_id = urlPool[i];
    window.googl_callback=function(response){
      if(response.error_message){
        alert('Error:' + response.error_message);
      }else{
       var short_url = response.short_url;
       var rep = document.getElementById('shorten_url_' + entry_id);
       rep.innerHTML = short_url;
       rep.href = short_url;
      }
    };
    var u='http://ebadac.textcube.com/' + entry_id; // <- 요부분 각자 블로그에 맞게.
    var s=document.createElement('script');
    s.src='http://ggl-shortener.appspot.com/?url=' + encodeURIComponent(u) + '&jsonp=googl_callback';
    void(document.body.appendChild(s));
  };
}
//]]>
</script>

그 다음, </body>의 바로 위에, 아래 코드를 붙여 넣고...

<script type="text/javascript">
//<![CDATA[
doShortenURL();
//]]>
</script>






다음 코드를 각 엔트리의 적절한 구역에 끼워넣으면 됨
<span class="shorten_url"> |
<script type="text/javascript">
//<![CDATA[
shortenURL([##_article_rep_id_##]); //<- 이거 블로그 도구마다 다를테니 알아서.. 텍스트큐브는 이렇다오.

//]]>
</script>
이 글의 단축URL[<a id="shorten_url_[##_article_rep_id_##]" href="#"> </a>]
</span>
내 경우에는 제목 밑에 대충 붙였음.

그러면 아래처럼 붙음.

아마도 tistory나 wordpress나 대충 비슷하게 될 거라고 생각함.(그런데 아마 wordpress에는 플러그인이 있는 것으로 알고 있음)

버그 있다면 알아서 잡으세요. 오랜만에 코드잡으니까 귀찮다능...


--- 재수정 했음 ---
IE8의 악명높은 KB927917 버그(?) 때문에 다시 수정했음. IE 안쓴지 너무 오래되어 이런 문제가 있는지 생각도 못했다능.


2010년 3월 22일 월요일

한겨레-광고 유감

한겨레에 들어가 신문기사를 읽다보면,
기사 가운데를 떡하니 차지하고 있는 호버광고들이 있다.

기사 옆도 아니고 기사를 가리는 광고라... 이건 방송에서 뉴스 중에 PIP로 화면 1/4쯤 CF 내보내는 것과 비슷할까?

커서키나 페이지 다운 등을 누르면 잠시 사라지지만, 사라졌다 싶어 기사 읽는 도중에 또다시 덮는다. 젠장.


경영은 중요하지만, 이건 정말 아니다 싶다. 정말로 신문사가 수익을 낼 수 있는 방법이 이런 것 뿐인가?

2010년 3월 13일 토요일

iPad 질렀음

인증샷....


California에서는 Recycle fee를 $8을 받는다는 사실을 처음 알았음. 이런 젠장.
국내에 들어올 때에는 이 가격에 10% 부가세포함.

배송대행은 몰테일 이용.
개봉기는 4월 첫째주에....

ps. apple의 1세대 제품은 마루타인지라 어떤 건지 맛만 보고 팔아버릴까 해서 걍 최소사양으로 샀음.

2010년 3월 12일 금요일

오지라퍼


우리 빌딩 화장실에 걸려 있는 공익(?) 광고.
이 광고를 보고 항의전화가 걸려왔다.
왼쪽그림은 그렇다 치고, 오른쪽 그림을 문제삼는데, 외국인들이 보고 한국 사람들은 모두 소변기에 큰 일을 보는 걸로 알면 어떻게 하냐고, 나라 망신이니까 당장 내리라고...

오지라퍼들이 많다는 쪽이 더 나라망신 아닐까. 유머는 유머일 뿐.

2010년 3월 3일 수요일

간만에 만난 쓸만한 책 - 리팩토링 HTML

리팩토링 HTML - 10점
엘리어트 러스티 해럴드 지음, 김인교 옮김/에이콘출판
Two thumbs up!
웹개발자들이 웹을 모른다. 어제 오늘 일도 아니었지만.

이 책은 제목대로 기존 웹사이트의 HTML을 리팩토링하는 법을 알려준다. 하지만 정확히 말하자면, 개발자들의 잘못된 버릇, 오해, 틀린 개념을 리팩토링한다. 그것도 한 번에 한 단계씩, 콕콕 찝어서.

사실 리팩토링이 아니라, 올바른 클라이언트사이드 개발법에 대한 교과서라 할 수 있다. 이전에 나왔던 다른 웹표준관련 도서에 비해 개발자들의 취향에 가장 잘 맞을테다. 왜냐하면 고민할 필요없이 여기에 나오는 규칙대로 "코딩"하기만 하면 되므로. (기존 국내에 소개된 책들은 이 책에 비하자면 충분히 비실용적이자 형이상학적이라고 하겠다. 지금 와서 하는 소리지만.)

우리 회사 개발자들에게 하나씩 사주고 싶네. 물론 내 돈으로는 말고.

2010년 1월 29일 금요일

현실은 시궁창 (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. 샀다가 와이프가 이게 뭐여!!! 라고 할 것 같음. 이래저래 현시창.

2010년 1월 28일 목요일

술을 먹으러 갔는데...

그저께는 거래처 분들이 술을 산다길래 쫄래쫄래 나갔습니다. (원래 맡은 업무가 거래처랑 술먹는 일)
1차로 참치를 먹고, 2차를 어디로 갈까 하다가... 좋은 곳(?)에 가자, 오랜만에 한국에 들어온 거니까 자기는 꼭 놀고 싶었다. 오늘 밤새도록(?) 놀아보자... 등등의 말로 저를 꼬셔서 데리고 간 곳은...


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

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

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

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

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

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

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


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

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

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

2010년 1월 25일 월요일

접근성 및 모바일 환경을 위한 메일 작성가이드라인(광고메일, 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/

 

2010년 1월 4일 월요일

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

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

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

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

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



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

새해

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