에반 비상하다~!!

유용한 정보

Thu, 10 Jan 2008 08:52:10 +0900

2008년 개발트랜드는?...

GS이숍 개발자 블로그에서.....

아래 내용중에서 가장 관심이 가는 분야는 소셜네트워크?......idtail.com 도 소셜네트워크에 포함이 될듯 하다..

자세한 정보는=> http://ecs.gseshop.co.kr/blog/375

클라우드 컴퓨팅
검색시장이 포화상태에서 아주 뒤늦게 뛰어들어 판을 바꿔버린 구글이 있었습니다. 구글의 검색에는 다른 것이 있었습니다. 요즘은 GFS(Google File System)과 BigTable 로 알려진 구글만의 파일관리 시스템과 대용량 데이터처리 시스템입니다. 웹 로봇이 수집한 방대한 웹페이지를 인덱싱하고 1초내에 수십만 쿼리를 처리할 수 있는 분산처리기술에 대한 기술적 노하우입니다. 구글은 당신의 마우스 클릭 하나도 놓치지 않는다고 합니다. 바로 CRM 정보를 거의 실시간으로 활용한다는 뜻인데, 구글에 로그인해서 서비스를 이용해보면 이 말이 무슨 뜻인지 실감하게 될 것입니다.
hadoop 이나 HBase 같은 오픈소스로 된 프로젝트들에 관심이 가는 이유입니다. 익히 들어온 그리드 컴퓨팅이 마케팅 용어로 더 알려진 반면 비슷한 개념의 클라우드 컴퓨팅은 클러스터링의 궁극적 구현체가 아닌가 생각합니다. 구글에서 cloud computing 으로 검색해보면 많은 대학과 연구소들의 링크가 산재해있습니다.

오픈API
이것도 포문은 구글이 열었습니다. 구글이 시작했다기보다는 당했죠. 폴 래드매셔가 구글 맵과 그레이그리스트 부동산 정보를 해킹해서 매시업 서비스로 만든 것이 시초였습니다. 이후 그는 구글에 입사하게 되죠. 그리고 구글은 자사의 정보를 open 합니다. 자사의 데이터를 외부 개발자들에게 열어놓은 구글은 돈도 안 주고 새로운 아이디어로 거듭난 여러가지 서비스를 맛보게 됩니다.
국내에서도 네이버가 공식적으로 오픈API를 지원하고, 다음도 뒤이어 오픈했습니다. 쇼핑몰 가운데서는 옥션이 웹서비스를 이용해서 옥션 상품 검색과 등록을 비롯해 거의 모든 서비스를 이용할 수 있도록 API를 공개했습니다.
오픈API를 이용해서 가장 득을 보는 업무는 제휴 업무입니다. 잘 정리된 외부 공개용 API와 매뉴얼을 갖고 있으면 제휴 개발에 드는 소통비용을 많이 절감할 수 있습니다.
아, 저희도 이스토어 상품 등록은 웹서비스를 이용해서 가능합니다. 더 확장하고 싶은 마음이 굴뚝같죠. 산타 할아버지가 들어오실만한 굴뚝이죠. ^^;

소셜네트워크
군중속의 고독, 인간 본성 가운데 해소되지 않는 무엇이 외로움입니다. 이 외로움을 해소하기 위해 채팅에 빠져들게 되죠. 이런 이유로 싸이월드나 세이클럽이 문전성시를 이루지 않았나 생각됩니다. 인터넷에 체류하는 시간이 많아질 수록 인간미를 맛보고 싶어하는 욕구가 더 심해집니다.
커뮤니티의 커뮤니티를 표방하는 것이 오픈소셜입니다. 이것도 구글에서 발표한 내용인데, 이거 구글에 구걸하는 기분이 드는 것은 왜 일까요. 현재 미국은 소셜 네트워크에 대한 관심이 뜨겁습니다. 그 선두에 Facebook과 MySpaces 가 있죠. Facebook으로 이직하는 구글 개발자들이 많다는 것도 재밌는 사실입니다.
각설하고, 관계에 기반한 서비스는 사람들의 체류시간을 증폭시킬 수 있습니다. 오픈API와도 맥락이 닿는데, 특히나 모바일과 연계된 서비스들이 많다는 특징을 갖고 있습니다.
국내 SNS(Social Network Service)는 2008년 뜨겁게 경쟁할 듯 합니다. me2day, playtalk, tossi 등 토종 마이크로블로그들의 경쟁이 바로 그것이죠.

모바일 컴퓨팅
용머리뱀꼬리, 우리나라 모바일 산업을 이렇게 얘기하고 싶습니다. 2000년대 초에는 전세계 무선 전화기 시장의 개발을 주도할 것 같은 우리가 이통3사의 종량제 기반의 패킷요금으로 아주 씨를 말려버렸습니다. 전화기에 기능은 잔뜩 넣었지만, 생활 속에서 쓰기에는 카메라 밖에 쓸 게 없을 정도죠.
구글의 안드로이드나 애플의 아이폰을 보면 국내 모바일 개발은 한숨만 나옵니다. 2008년에는 답답한 무선 시장의 숨통이 트일 거라고 기대해봅니다.

책을 읽자

Thu, 10 Jan 2008 08:46:57 +0900

디자인 정보, 생활의 활력소, 여행관련 등 읽어 볼만한 책들로 구성을 할 예정입니다.

디자인 관련 책자

- 디자인 정보

UI 정보

Wed, 29 Aug 2007 20:05:48 +0900

목록페이지에서 상세정보 미리보기 페이지 적용가능 여부.....

디자인창고

Mon, 20 Aug 2007 20:14:03 +0900

아이콘 디자인 사이트

http://www.iconwerk.de/ , http://iconkits.com/

아이콘이 필요할때 참고해서 작업이 가능할듯.....

CSS

Fri, 27 Jul 2007 11:33:12 +0900

mozilla의 css 선언 제안순서

display
list-style
position
float
clear
width
height
margin
padding
border
background
color
font
text-decoration
text-align
vertical-align
white-space
other text
content

position:absolute 와 relative의 다른점
absolute에서 style.right는 블럭의 오른쪽으로부터의 기준이고

relative에서의 style.right는 블럭의 왼쪽을 기준으로 음의 방향으로 움직인다. 즉 style.left를 - 방향으로 움직이는 것과 같다.

한 블럭에 relative속성을 가진 개체가 있으면 top정렬이 된다

absolute는 Canvas라 불리는 웹문서 전체영역에서 0,0의 좌표를 기준으로 포지션 값을 가지게되며,

Relative는 스스로가 하나의 Canvas가 되면서 그 안에 포함하는 absolute에 새로운 0,0의 기준을 제공합니다.

static 포지션과 비슷한 성질을 띄면서 자식요소에 영향을 주는 것이 relative입니다

다음 UI 개발자 블로그에서 발췌
http://blog.daum.net/uidev/
<html lang="ko">
<head>
<style type="text/css">
p {margin:20px 0 0 0}
div {border:1px solid gray;}
div.d1 {width:150px;height:100px;}
div.d2 {position:absolute;top:30px;left:30px;background-color:#ff8989;width:200px;height:150px;z-index:100} 
div.d3 {position:relative;background-color:#fff589;width:150px;height:100px;z-index:1} 
</style>
</head>
<body>
<p>
<div class="d1">
<div class="d2">position:absolute</div>
</div>
<div class="d3">position:relative</div>
</p>
<p>
<div class="d1" style="position:relative">position:relative
<div class="d2">position:absolute</div>
</div>
<div class="d3">position:relative</div>
</p>
</body>
</html>

위의 결과를 보면 위의 p 는.. d1, d2, d3가 사이 좋게 잘 나오죠.. 하지만 아래 그림은 뭔가 어색합니다.

d2의 left, top을 d1의 종속을 받게 하기 위해 d1에 position:relative를 주게되면.. 위의 결과 처럼 d2가 d3의 밑으로 숨어 들어가 버리는 현상이 발생을 합니다.

css쪽을 살펴 보면 분명 d2의 z-index가 100이고 d3의 z-index가 1 임에도 불구하고 말이죠.. 참으로 알 수 없는 ie입니다.

하지만, d2를 감싸고 있는 d1의 z-index에 d3의 z-index값 보다 큰 값을 주게 되면 아래 결과 처럼 정상적으로 잘 표현이 된답니다.

결론은 ie는 특정 element가 absolute되어 z-index가 사용될경우 상위 parent element 의 z-index도 함께 고려를 해봐야 한다... 정도겠네요..

그럼 허접한.. tip 이었습니다.. 수고하세요~

디자인관련

Wed, 25 Jul 2007 19:18:17 +0900

[스크랩] MonaC님의 블로그에서...

http://hanb.co.kr/look.php?isbn=978-89-7914-503-8&tab=review

이 책은 UI 설계에 대한 본격적인 책입니다.

다양한 UI 구성 요소들에 대한 분석을 전재로 하고 있습니다. 예를 들어, 어떤 종류의 정보를 표시하는 데

리스트박스가 좋은지, 텍스트 박스가 좋은지, 그리드가 좋은지, 드랍다운 리스트가 좋은지 등을 설명하고 있습니다.

이 설명 역시 지엽적일 수 있습니다. 페이지 레이아웃, 다양한 화면 구성 요소들(개발자라면 UI Components라는 표현이 더 익숙하겠죠?),

데이터를 보여주는 방법들을 설명합니다.

이 책의 가장 큰 단점은 여러분이 이미 다 알고 있는 것들이라는 겁니다. 이 책에서 설명하는 것은 "단 한 가지"도 새로운 것이

없다는 것입니다.

그런데, 여러분이 모두 잘 알고 있다고 말하는 UI들, 또는 자주 보게 되는 패턴들에 대해 통일된 용어가 없습니다.

이 책의 장점은 작업하면서 자주 보게 되는 UI나 패턴들에 대한 명확하고, 체계적인 정리에 있습니다.

따라서, 디자이너, UI기획을 하시는 분들에게 유용하며, 본의 아니게 UI 설계를 함께하는 개발자나 디자이너에게 유용합니다.

이 책을 통해 얻을 수 있는 한 가지 장점은 UI 분야에서 쓰이는 패턴 언어의 획득입니다. 국내에서 UI 기획자나 디자이너들은

패턴 언어에 익숙하지 않습니다. 저마다 쓰는 표현이 다릅니다.

예를 들어, 본문 중에 흥미있는 키워드들은 링크를 갖고 있습니다. 사용자가 예상하지 못한 곳에 링크를 두어,

사용자의 호기심을 끄는 방법입니다. 온라인 백과 사전에서는 이런 방법이 흔히 쓰입니다.

국내에서는 이를 어떤 용어로 표현할까요?? 제가 아는 걸로는 "본문 링크" 정도지만, 회사마다 쓰이는 용어가 다를겁니다.

원어로는 "intriguing branches"라고 합니다. 사용자의 관심을 다른 곳(branches)으로 이끄는 방법이라는 의미입니다.

intrigue라는 표현 자체가 "어떤 것에 대한 흥미를 이끌어내다"라는 뜻입니다.

일종의 통일된 용어, 패턴 언어를 습득한다면, 다른 사람에게 "이 화면에는 XXX를 이용하는 것이 좋겠어요"라고 얘기하는 것으로

충분합니다. 대화가 간결해지고, 커뮤니케이션 비용도 낮출 수 있습니다. 이것이 패턴 언어의 힘입니다.

자신이 아무리 많은 지식을 알고 있다고 해도 이를 다른 사람에게 전달할 수 없다면 의미가 없습니다.

많은 사람들이 패턴 언어를 익히기 위해 노력하는 것도 이 때문입니다. 패턴 언어는 건축학에서 시작해서, 컴퓨터 공학에

전파되었고, 이제는 UI를 비롯한 다른 많은 분야에 패턴 언어가 전파되고 있습니다.

위 예에서 한 가지 알 수 있는 이 책의 단점은 또 있습니다.

번역에 급급하여 용어 선택에 대한 진지한 고민이 없습니다. 원어 표현을 그대로 한글로 적어두는 것도 좋습니다.

"intriguing branches"를 "인트리깅 브랜치"로 적어두는 것도 좋습니다.

그러나, 페이지의 남는 공간에 한글 용어에 대한 고민이 있었으면 더 좋았을거라는 생각이 듭니다.

물론, 겉멋만 잔뜩 들어서 영어를 요란하게 섞어쓰는 UI 기획자들을 알고 있습니다만,

그래도 "키워드 링크, 본문 링크" 등의 표현이 있다라든가 하는 말도 있었으면 더 좋았을 겁니다.

현업에서의 괴리감을 느끼는 부분입니다.

또 하나, 이 책에 나오는 패턴들을 모두 외워두고, 소프트웨어나 웹 사이트의 화면 설계를 보면서

각각의 패턴들을 지적해보면 좋겠습니다. 저 같은 개발자는 이런 용어들을 토대로 떠들면서

실력없는 UI 기획자를 깔아뭉개는 용도로 사용하겠습니다.(덕분에 대부분의 패턴 용어들이 쏙쏙 외워지더군요)

UI 기획자가 화면과 자신이 원하는 것을 한참 설명하고 나면,

"아, 그러니까 이 부분은 extras on demand를 하자는 것이고, 이쪽의 네비게이션은 sequence map,

콘텐트 페이지의 네비게이션은 bread crumbs을 쓰고, 탭 패널 네비게이션에서는 color-coded sections를 하자는 거군요!"

라고 답해드리겠습니다.

UI에서 디자인 패턴을 사용하기 위한 시도는 꽤 있습니다. 그 중에는 YUI(Yahoo! UI Library)가 있습니다.
(http://developer.yahoo.com/yui/)

color-coded sections는 색상을 이용해서 섹션이나 페이지를 구분하는 방법으로 아마존(http://www.amazon.com)이

이를 처음 시도하면서 당시에 많이 언급되었습니다.

Tab View 패턴은 애플(http://www.apple.com)에서 시도하면서 많이 알려졌습니다.

물론, Tab View와 Tab Panel은 전혀 다릅니다. 다른 UI 패턴입니다.

이 책은 breadcrumb을 "브레드크럽"으로 옮겼습니다. 오역(?)입니다. "브레드크럼"이 맞습니다.

Tomb에서 "mb"에서 b는 묵음이 됩니다. 그래서 "툼"입니다. Tomb Raider

영어 단어는 자음이 2개가 붙어있는 경우 뒤의 자음이 묵음이 됩니다.

자음이 3개가 되면 가운데 자음이 묵음이 됩니다. 예를 들어, COSTCO 같은 경우 STC에서 T가 묵음이 되어 "코스코"로

발음합니다. 한국에 사는 외국인은 "코스트코"로 발음해도 알아듣습니다.(한국에 온지 얼마 안된 분들은 빼고)

이 책은 UI 전반에 대한 것으로 반드시 웹에 대한 것만 다루지 않는다는 것도 알았으면 합니다.

일단 응용프로그램의 UI 설계와 웹 사이트 UI 설계는 공통된 부분도 있지만 다른 부분도 있습니다.

웹의 근본인 하이퍼링크가 설계를 어렵게 하는 주범이기 때문입니다. 정보 구조(information architecture) 설계가

어려운 것도 이 때문입니다. 기존의 수직적인 설계는 하이퍼링크에 의해 단번에 무너질 수 있고, 그로인해

사용자의 머리속에 만들어지는 인지 과정, 정보 구조가 실제 설계자가 원했던 또는 인지하길 원했던 정보 구조와는

판이하게 다른 것일 수도 있습니다.

이 책은 다음과 같은 분들에게 추천합니다.

1. UI 분야의 패턴 언어 습득을 통해 패턴 언어를 구사하길 원하시는 분.

부수적으로 당신은 보다 더 스마트해 보일 수 있습니다.

2. 디자인팀이나 UI 기획자가 무시하지 못하는 개발자가 되기.

부수적으로 디자이너를 울릴 수 있습니다.(악마!!)

3. 응용프로그램이나 웹 사이트를 개발하면서 UI 문제로 늘 고민하는 디자이너/개발자.

4. 일반 산업용 제품 개발을 하지만, 접목시킬 아이디어가 없을까 궁금해하는 분.

그러나, 아트를 하는 분들에겐 아무 도움이 되지 않습니다.(뼈있는 한 마디!)