6 Results for '프로그래밍'

  1. 2008.02.22 골수 개발자가 디자이너에게 보내는 편지 (10)
  2. 2007.04.21 수학은 절망 (3)
  3. 2006.09.05 Yahoo! Widget Engine [03]
  4. 2006.08.31 Yahoo! Widget Engine[02]
  5. 2006.08.29 Yahoo! Widget Engine[01] (5)
  6. 2006.08.28 이런 걸 만들어 보고 싶다. (1)

트랙백이 없는 네이버 카페ㅠ.ㅜ
http://cafe.naver.com/mssilverlight/1742 글에 대한 답변이에요.
참 'XX에게의 편지' 따위의 제목을 쓰고 싶진 않았는데 더 적당한 말이 떠오르지 않네요;


모든 것에 앞서 얘기드리고 싶은 건, 전 골수 개발자에요. 전혀 디자인 관련 공부를 해본적도 일을 해본적도 없을 뿐더러 디자인 감각조차 꽝이라는(그 점이 제일 가슴아프네요) 거죠. 따라서 제가 싸질러 놓은 모든 글들은 디자이너의 입장에서 전혀 공감되지 않을 수도 심지어 완전히 헛소리일 수도 있음을 감안해 주세요. 만약, 제가 그런 헛소리를 해대고 있다면 어떤 점이 잘못되었는지, 디자이너가 느끼는 진짜 문제는 뭔지에 대해 댓글로 남겨주시면 개발자와 디자이너가 소통하는 데 중요한 키가 될 수 있을 거에요. 주저 없이 의견을 날려 주세요.


이제 많은 사람들이 같은 고민을 하게 될 것 같네요.

먼저 실버라이트와 관련된 디자인에 나름 참고가 될만한 제 글들을 링크해 볼께요.

http://gongdosoft.com/228

http://cafe.naver.com/mssilverlight/1615

http://gongdosoft.com/category/Expression

제 글 외에도 UX에 관한 사항은 마이크로소프트의 UX 이반젤리스트인 리건님이 운영하는 http://uxfactory.net 가 도움이 될 것 같고요.

현재로서는 명쾌한 답 같은건 없다는게 제 결론이에요.

반대로, 개별 상황을 해결할 수 있는 최선의 방법이 있다 라고 얘기할 수도 있겠죠. 돌가님이 제기한 의문에 대한 나름의 답을 생각해봤어요.


1. 과연 디자이너에게 있어서 UX란 무엇인가!

UX는 굉장히 넓은 범위로 얘기될 수 있는 주제지만, 저는 '사람들이 쓰고 싶어하고 또 쉽게 쓸 수 있는 사용자 경험'이라고 요약하고 싶네요.

전통적인 디자인의 목표라면 '쓰고 싶게 하는 것', 바로 디자인의 감성적인 측면으로, 어도비의 많은 툴들은 바로 이런 점에 촛점을 맞춰서 디자인되었고 또 많은 디자이너들이 여기에 익숙해져있죠.

반면, '쉽게 쓸 수 있는 것'은 디자인의 기능적인 측면이라고 볼 수 있는데요, 초기 RIA에서 나타난 문제점 중에 하나는 화려하고 현란하고 멋지긴 한데... 도무지 쓰기가 어렵고 반응성도 좋지 않았다는 점들이죠. 이런 점들은 어떤 툴을 사용하든 사용자 경험에 대한 배려와 노력이 없으면 이룰 수 없을 거에요.

저는 이런 UX에 대한 고민의 답을 게임들의 인터페이스에서 어느 정도 찾을 수 있을 거라고 생각해요. 게임은 UI라곤 단지 사각형과 텍스트밖에 없던 오래전부터 보다 화려하고 현란하고 멋진 그래픽을 표현함과 동시에 사용자들이 보다 쉽게 조작하고 쉽게 사용할 수 있는 인터페이스를 구현하는 엄청난 노하우가 집약된 분야라고 생각해요. 과거에는 이런 게임들의 인터페이스를 웹이나 데스크탑 애플리케이션에서 구현한다는 것은 굉장히 어려운 일이었지만 아시다시피, 현재는 플래시와 같이 강력한 툴의 지원으로 상당 부분 따라갈 수 있게 되었죠.

현재 웹에서의 그래픽 표현(2D)은 거의 한계에 가까워졌다고 생각해요. 툴들이 보다 지능적이고 자동화 되는 발전 과정이 있을 뿐 남은 것은 디자이너 개개인의 창조성에 달려있다는 거죠. 반면, 사용자 경험에 대한 전반적인 논의와 고민은 아직 많은 쟁점을 가지고 있고 보다 더 고민하고 개척해야할 분야라고 생각해요. UX의 관점에서 전자는 기본이요, 후자의 중요성이 점점 더 커질 수 있다는 거죠.


2. 그렇다면 우리나라의 UX는?

이 부분에 대해서는 저도 심각하고 심지어 절망적이기까지 해요. 아시다시피 우리나라의 UX는 모든 것을 한꺼번에 차린 밥상 이라고 표현할 수 있는 다소 난잡한 포털식이잖아요? 이게 사용자가 원해서인지 아니면 초기 포털이 그런식으로 발전해 왔고 사용자들은 단지 적응을 한 것 뿐인지는 잘 모르겠어요. 만약 후자라면 그나마 가능성은 있어보이죠. 요컨대, 수년 전 인터넷 비즈니스는 '야후'때문에 할게 없다 라고 툴툴거려왔고 지금은 '구글'때문에 할게 없다 라고 하죠. 야후는 전통적인 포털 서비스와 같은 UX를 제공해왔고 구글은 단순함에 기반한 UX를 추구하고 있기 때문에 많은 것을 시사하고 있다고 봐요.

그렇지만, 다시 현실로 돌아오면 분명히 말해 현실의 서비스는 정확히는 서비스 제공자들은 구글과 같은 혁신적인 모험을 원치 않을거에요. 처음 계획에는 뭔가 새로운걸 시도하기 위해 이런저런 회의를 하겠지만 시간이 지날 수록 사람들은 당장의 현실에 한계를 짓는 경우가 많죠.

분명히 말해서, 아직까지 국내에서 혁신적인 UX를 말한다는 것은 무리일지 몰라요. 그러나 UX가 반드시 단순하고 깔끔한 디자인 또는 화려하고 멋진 UI만을 얘기하는 것은 아니잖아요? 네이버나 다음과 같이 난잡한 UI속에서도 사용자들이 좀 더 쉽고 편안하게 쓸 수 있는, 그런 것이 바로 UX겠죠.

그렇지만 저는 좀 더 혁신적인 UX를 가진 웹 서비스를 만들어보고 싶고, 제 바램을 구현할 수 있는 직장과 일을 선택하고 싶어요.


3. Microsoft Expression Studio가 어도비의 툴들과 경쟁력이 있는가?

물론 당장은 아니죠. 하지만 시간이 지나면 어떨지 아무도 예측할 수 없겠죠. 심지어 저는 폐쇄적으로 닫혀있는 어도비보다 열려있는 마이크로소프트의 그것이 훨씬 더 큰 발전 가능성을 가지고 있다고 생각해요.

단순히 툴만으로 비교하자면 십수년간 디자이너를 위한 그래픽 툴을 만들어온 어도비가 압도적으로 유용하고 유리하겠죠. 그러나 Expression Studio는 단순히 그래픽 툴로서의 가치만을 가지는게 아니라고 생각해요. Expression Studio는 마이크로소프트의 UX, 그 중에서도 Presentation 분야에 특화된 툴이고 마이크로소프트의 Presentation은 XAML이라는 잘 설계된 방향을 향하고 있죠. 아시다시피 XAML은 완전히 열려있는 플랫폼이기 때문에 설사 마이크로소프트의 Expression Studio가 좋은 툴을 제공할 수 없다고 해도 서드 파티에서 보다 완벽하고 보다 디자이너 친화적인 툴을 만들어낼 수 있을거에요.

예를 들어보죠.

포토샵은 현존하는 가장 유명하고 가장 많이 사용되는 그래픽 툴이고 PSD는 바이너리 포맷으로 닫혀 있는 포맷이죠. 그럼에도 불구하고 페인터와 같은 툴들은 포토샵이 긁어주지 못한 곳을 파고들어 하나의 영역을 구축하는데 성공했어요. 저는 이들이 어도비와 어떤 파트너쉽을 가지고 있는지 모르겠지만, 만약 제가 페인터와 같은 툴을 만든다고 하면 눈앞이 깜깜해 질거에요. PSD와 같은 거대한 바이너리를 맨땅에서 분석해내야 하기 때문이죠.

반면, Expression Studio(정확히는 Blend에 한정되지만 개념상)는 기본적으로 완전히 열려있는 XAML을 기반으로 하고 있고 누구나 마음만 먹으면 그 스펙을 열람하여 훨씬 더 좋은 툴을 개발할 수 있다는 점이 달라요. 벌써 WPF쪽으로는 3D 디자인을 위한 ZAM 3D라는 서드파티 툴이 Blend에 비해 훨씬 더 좋은 기능을 제공해주고 있죠.

어쩌면 이런 생각이 질문과는 거리가 멀지 모르겠어요. '툴'자체의 유용성은 시간이 지나면서 변하기 나름이라고 생각해요.

제 생각에 단기적으로는 혹은 조금 더 많은 시기 동안은 어도비 포토샵과 일러스트레이터의 아성은 견고할거에요. 그러나 웹 디자인, RIA에 있어서 중요한 표현은 단지 그래픽이 아니라 UX라는 점이죠. 단지 툴만으로 경쟁이 되는 것이 아니라 기획자와 디자이너, 그리고 궁극적으로 사용자가 원하는 UX를 보다 생산성 있게 운용할 수 있는 기술, 그것이야 말로 경쟁의 포인트가 된다고 생각해요.

적어도 수 년간(소심스럽긴...^^)은 어느 한쪽이 일방적인 승리를 거둘 수는 없을 거에요. 마이크로소프트의 UX전략은 어느정도 시장에 진입하기 시작했고 그리 쉽게 떨어져 나가지는 않을 거라고 예상해요. 이런 상황에서 물론 가장 좋은 것은 모든 툴을 잘 다룰 수 있는 능력이겠지만 현실적으로 그것이 어렵기 때문에 디자이너에게 다음과 같은 제안을 해볼께요.

먼저 포토샵(취향에 따라 일러스트레이터)은 디자이너로서 가지고 있는 창조성을 보여주기에 무리가 없을 정도로 숙련도를 높일 필요가 있을 거에요. 적어도 수 년간(^^)은 포토샵과 일러스트레이터의 아성은 깰 수 없을 테고, 실제로 현재로서는 가장 좋은 그래픽 퀄리티를 낼 수 있는 툴이니까요.

다음으로 시장의 요구에 따라 -회사의 요구에 따라^^- 실버라이트와 플래시or플렉스의 선택을 강요받게 되겠죠? 이 때는 자신이 선택에 달려 있을 거에요. 플래시/플렉스는 지금 당장은 더 많은 리소스와 커뮤니티 그리고 금쪽같은 노하우를 더 많이 얻을 수 있기 때문에 안전한 선택이 되지만 그만큼 더 많은 경쟁이 기다리고 있겠고, 실버라이트/WPF는 초기 기술에서의 갖은 문제점과 부족한 리소스와 정보 때문에 상당히 시달릴 거에요. 그렇지만 보다 적은 경쟁에서 닷넷 개발자들의 열렬한 환호와 도움을 받으며 새로운 시장을 개척해볼 수 있는 기회를 얻게 되죠. 참고로, 전 디자이너는 아니지만 후자에 걸겠어요^-^


4. 디자이너로서 긍정적인 방향으로 준비할 것은?

먼저 개발(협업) 프로세스의 어려움에 대해 얘기해 보죠. 디자이너와 개발자와의 협업 프로세스에서 가장 어려운 점은 심지어 개발자들조차도 UX를 지향하는 웹 애플리케이션을 어떻게 만들어야 하는지 모른다는 점이 아닐까 싶어요. 누구도 그런 완전한 경험을 해보지 않았기 때문이죠. 잘은 모르겠지만, 실버라이트와 가장 비슷한 개발 모델인 플렉스에서도 훨씬 먼저 나왔지만 지금까지도 그런 협업 프로세스에서의 문제점으로 골치아픈 걸로 알고 있어요. 하물며 프로젝트의 파일 교환이 훨씬 더 어려운 플래시는 더 할테고요.

이런 문제는 서로 많은 공부를 하고 좋은 구조와 방법론을 사용하는 것도 하나의 방법이겠지만, 그보다 더 중요한 것은 디자이너가 표현하고자 하는 바를 좀 더 구체적으로 설명하고 좀 더 세부적으로 나누어서 표현하는 것, 그리고 개발자는 개발 플랫폼에서 디자이너의 오브제들이 어떤식으로 운용되고 디자이너의 니즈를 어떻게 만들 수 있는지에 대해 잘 설명하는 것, 즉 진부하지만 디자이너와 개발자는 더 많은 대화와 소통을 필요로 한다는 거죠.

플래시는 전통적으로 '디자인'으로 간주되는 영역이기 때문에 거의 개발자가 해야할 임무인 스크립팅 까지도 디자이너가 하지 않으면 안되었죠. 디자이너는 그렇게 어려운 싸움(?)을 해왔고 노하우를 습득해왔는데 이제와서 개발자들이 옆에서 궁시렁거리면 당연히 기분 나쁘겠죠? '니들이 뭘 알어 엉?' 이러면서요. 그래서 오히려 더 서로 좋은 협업이 어려워지는 것 같아요.

반면 실버라이트는 태생이 개발자 중심적인 환경이었고 모든 것들이 디자이너에게 다소 생소한 개념으로 다가 올 수 있어요. 그래서 콧대가 높아진 개발자들은 우쭐해져서 디자이너를 가르치려 들거에요. 반대로 '니들이 뭘 알어 엉?'이러면서요^^

자 이런 상황이 되면 뭘 선택하든 결과는 마찬가지일 거에요. 제가 무슨 얘기를 하고 싶은지 아시겠죠? :D

다시 처음 했던 얘기를 반복해 볼께요. 모든 상황에 들어맞는 개발/협업 프로세스 따위는 존재하지 않아요. 모든 프로젝트는 현재 구성원이 처해있는 상황과 능력, 기술, 취향, 성격에 따라 완전히 달라질 수 밖에 없죠. 바로 이 점을 명확하게 이해하고 인정해야 할 거에요. 몇 가지 전형적인 상황에 따른 협업 프로세스 혹은 대처 방안은 http://cafe.naver.com/mssilverlight/1615 2.19 네이버 실버라이트 카페 세미나에서 정리한 적이 있어요.

현실은 늘 이상과는 멀게만 느껴지지만 그래도 이상을 지향하는 것이 훨씬 더 발전적이고 즐거운 일이 될거에요. 그런 의미에서 제가 생각하는 디자이너와 개발자와의 이상적인 협업 모델을 얘기해 볼 께요.

그래픽 디자이너는 전문적이고 아름다운 그래픽 오브제와 레이아웃 그리고 전체적인 주제를 결정하고 만들어 내는 역할을 할 거에요. 아마도 이 그래픽 디자이너는 익숙한 포토샵과 일러스트레이터를 사용하거나 혹은 조금 더 개방적이라면 Expression Design과 Blend를 함께 사용할 수도 있겠죠. 그래픽 디자이너는 과거와는 달리 모든 디자인을 '통짜'로 만들지 않고 각 오브제들의 상관 관계와 계층 관계를 고려하여 적절하게 그룹화 하고 사전에 협의된 중요한 오브제에 대해 적절한 이름도 붙여주는 것도 잊지 않았을 거에요.

인터랙티브 디자이너는 디자인과 적당한 코드 작성 능력을 갖추고 그래픽 디자이너가 만들어 놓은 오브제들에 생명을 넣는 일을 하게 되죠. 또한 인터랙티브 디자이너는 사용자의 반응에 대해서도 충분한 고민을 하고 보다 역동적이면서도 편리하게 쓸 수 있는 UI를 구성할 거에요. 또 로직 개발자들이 제공하는 데이터를 바인딩 하여 애플리케이션이 더 의미 있는 정보를 보여줄 수 있게 할 거에요.

로직/서버 개발자는 애플리케이션에서 사용될 데이터의 흐름과 가공을 모델링하고 보편적이고 단순화된 방법으로 인터랙티브 디자이너가 필요로 하는 데이터를 전달해주는 역할을 해요.

그리고 이 모든 과정에는 아마도 디자이너/개발자와의 협업에서 싸우는 것보다 훨씬 더 많이 싸우게 될 기획자(내지는 팀장님^^)가 있고 특히 디자이너들은 기획자의 기획의도를 어떻게 잘 표현할 수 있을지 그리고 개발자는 그러한 요구에 필요한 개발과 프로덕션에 필수적인 전반적인 개발 일정을 주도하게 될 거에요.

물론 이 모델에도 구체적인 파일 교환, 수정 사항에 대한 대응 등 많은 문제가 있겠지만 제 생각에는 이 정도로 이상적인 모델을 구축할 수 있다면 다른 기술적인 문제도 함께 해결 할 수 있을 거라고 봐요.


마지막으로, 디자이너와 개발자의 공통점을 찾자면 '창조'가 아닐까 싶어요. 다만 그 창작물에 이르기까지의 관점이 다를 뿐이죠. 더 창조적인 디자이너와 개발자가 되기 위해서는 자신이 만들고 싶은 것들을 어떻게 하면 더 좋게 더 멋지게 그러면서도 현실적인 시간의 범위 안에서 구현해 낼지에 대해 끊임 없이 고민하고 노력하고, 결정적으로 즐기는 것이 필요하다고 생각해요. 답답하고 꽉 막힌 현실에서 뜬 구름 잡는 얘기 같지만, 이런 노력들 하나하나도 바로 현실 속에서 일어난다고 생각하면 한번쯤 해볼 만한 가치가 있을 거에요.

돌가님이 제기한 의문에 자극 받아서 다다다다 타이핑을 했네요. 부디 이런 고민들이 더 많이 모이고 더 나은 현실을 만드는 데 도움이 되길 바래요.

신고
Posted by gongdo

사용자 삽입 이미지

명색이 공돌이면서 피타고라스의 정리가 기억안나 네이버나 뒤적이는 자신에게 절망했다!
피타고라스의 정리가 중학 수학이었다니 절망했다!
수학은...
수학은 절망이다!

XAML 관련해서 예제를 만들려고 끄적거리다가 역시 시각적으로 임팩트 있는 프랙탈이 좋겠다 싶어서 시어핀스키의 삼각형이나 만들어볼까하고 IDE를 열었는데...
도대체 화면에 꽉차는 정삼각형의 각 꼭지점 좌표를 어떻게 계산해야 할지 생각이 안나는겁니다.

그냥 예제니까 고정 좌표를 쓰면 계산할것도 말것도 없겠지만 윈도 사이즈가 변경되면 정삼각형의 크기도 자동으로 현재 윈도 내에 가장 넓은 면적을 차지하도록 그리고 싶었죠.

그딴게 뭐가 어렵냐고 생각하시는 분이 있다면... 곧바로 back해주세요. ㅠ.ㅜ

그림판으로 그려가면서까지 삽질하고 중딩용 피타고라스의 정리 강좌를 다시 한번 읽어보고 한시간 동안 삽질하다보니 그럭저럭 동작은 하는게 나왔는데 아무리 생각해도 이거 일반적인 구현 방법이 있을 것 같은 불안감이 엄습하네요.

허접하나마 생각해본 구현 방안은 아래와 같아요.


오랫만에 절망해봤습니다.
누가 임의의 사각 영역에서 가장 넓은 면적을 차지하는 정삼각형 구하는 좋은 알고리즘이나 코드가 있으면 소개해주세요. ㅠ.ㅜ

신고
Posted by gongdo
한동안 구글에서 국내 위젯 엔진 관련 개발자가 없는지 뒤져보다가 포기하고는 성실하게도 레퍼런스의 기초 부분을 토대로 나름대로의 강좌를 작성하고 있었습니다.

그런데 생각지도 못한 야후 위젯 엔진 블로그... 그것도 한국어 판에 죄다 올라와 있더군요.
대절망.(참고 절망)

http://kr.blog.yahoo.com/yk_widget/folder/12.html
이곳에 가보면 1, 2회에서 어설프디 어설프게 설명한 부분이 정확하게 나와 있습니다.
저도 1, 2회는 없었던 일로 치고 이쪽이나 공부해야겠습니다.

이런 차로, 3회는 끝. OTL

(추가)
어쨌든 한국 야후의 위젯 엔진 블로그는 8월 28일, 레퍼런스 기본편의 Flat-File Format 까지만 설명되어 있고 그 뒤로 업데이트가 없습니다.
추가적인 도움은 역시나 영문 야후의 포럼에서 얻을 수 있습니다. 링크는 이쪽.
http://www2.konfabulator.com/forums/
아직도 콘파뷸레이터네요^^
신고
Posted by gongdo
이번 회부터는 통상 모드로 돌아와서 진행합니다. (좌절)

야후! 위젯 엔진 두번째.
지난번엔 맨땅에 헤딩격으로 간단한 위젯을 만들어봤습니다.
사실 야후 위젯을 그다지 깊게 사용하지 않을 것 같아서 첫회에 얼렁뚱땅 대충 만들었는데 조금 더 제대로 사용해보고 싶은 마음이 들었습니다.

이번 회엔 야후! 위젯 엔진을 간략하게 소개하고 기본적인 구성을 연구해보도록 하죠.
※주의!
야후! 위젯 엔진과 관련된 모든 내용은 제 이해의 부족으로 잘못된 정보가 있을 수 있습니다.
야후! 위젯에 대한 정확한 정보는 http://kr.widget.yahoo.com 에서 확인하실 수 있습니다.
하지만 개발자라면 영문홈인 http://widget.yahoo.com 을 둘러보시길 적극 권장합니다.

◆ 야후! 위젯 엔진 준비
야후! 위젯 엔진(이하 위젯 엔진)을 만드려면 우선 위젯 엔진을 설치해야겠지요.
야후!의 위젯엔진 홈페이지에서 다운로드를 받아서 설치합니다.
단, 앞으로 제대로 개발을 해보고 싶다면 영문 홈에서 SDK를 다운받으시길 권장합니다.
한국 홈에는 SDK가 제대로 정리되어있지 않더군요.

위젯 엔진을 설치했으면 우선 기본으로 설치되어 있는 위젯들을 건드려보면서 어떤 유저 인터페이스를 제공하는지 느껴보는 것도 좋겠지요.

위젯을 개발하려면 소스 코드를 작성해야 할텐데요, 다음 절에서 얘기하겠지만 위젯 엔진은 XML과 자바 스크립트로 이루어져 있으므로 소스 코드는 순전히 메모장 만으로도 충분합니다.
물론 원활한 편집을 위해서는 손에 맞는 고급 텍스트 편집기가 있는게 편하겠죠. :)

위젯은 다른 무엇보다 UI가 중요합니다.
"아름답지 않으면 살아갈 의미가 없어...", 바로 이거죠.
그러기 위해선 제대로 된 이미지 편집기도 필요할 것입니다.
만약 포토샵 CS나 CS2를 사용하신다면 SDK에서 제공되는 포토샵 스크립트로 PSD파일을 바탕으로 자동으로 위젯을 만들수 있어 편리합니다.

정리하자면,
  • 야후! 위젯 엔진 SDK
  • 텍스트 편집기
  • 이미지 편집기
...만 있으면 위젯을 작성할 수 있습니다.


◆ 위젯 엔진의 구성

위젯 엔진은 기술적으로 다음과 같이 요약될 수 있습니다.
위젯 엔진은 Java virtual machine이나 Microsoft .NET Framework 처럼 일종의 플랫폼을 제공하고 있습니다.
이 플랫폼 위에 XML과 Java script를 통하여 작성되는 위젯이 구동된다고 볼 수 있지요.

※참고
위젯 엔진은 과거 Konfabulator라고 불렸고 최근 야후! 위젯 엔진으로 이름을 바꾸었는데요, 그런 이유로 아직까진 곳곳에 Konfab.의 흔적이 남아있습니다.
위젯은 XML과 Java script로 작성되므로 간단한 텍스트 편집기만으로도 쉽게 코드를 짤 수 있고 소스 코드의 공유도 자유롭습니다. 웹에서 HTML이나 간단한 자바 스크립트를 써보신 분이라면 이미 만들어진 위젯의 소스 코드를 보고 'Copy & Paste'신공만으로도 괜찮은 결과물을 만들어 낼 수 있다는 얘기지요.

위젯 작성에 필요한 소스 파일들은 보통 다음과 같은 디렉터리 구성으로 이루어집니다.

보통 개발 폴더명을 title.widget 이라고 짓고, 그 아래에 Contents 폴더가 위치하며 거기에 가장 중요한 파일인 .kon파일과 Resource나 외부 스크립트 파일 등이 위치합니다.

Contents 하부의 폴더나 파일은 편의에 따라 구성할 수 있지만 위젯 엔진 설치시에 기본으로 제공되는 위젯들은 모두 저런 구조로 구성되어 있으므로 다른 개발자를 위해서도 기본 형태를 따르는 것이 좋겠지요.

.kon 파일은 XML을 기반으로 작성되며 여기에 코드의 제어를 위해 자바 스크립트를 사용할 수 있습니다.
하지만, 자바 스크립트는 기본적인 math function 들과 위젯 엔진에서 제공되는 API의 범위 내에서만 제한적으로 사용 할 수 있기 때문에 무턱대고 웹에서 쓰던 코드를 그대로 가져오면 동작하지 않습니다. 항상 위젯 엔진 레퍼런스를 끼고 살아야겠지요. :)


◆ .kon 파일의 구성

.kon 파일은 XML 기반이므로 반드시 첫행에서 XML 규격에 대한 선언(?)을 해줘야 합니다.
<?xml version="1.0" encoding="UTF-8"?>
물론 텍스트 에디터에 따라 encoding이 바뀔 수 있겠지만 무리 없는 유니코드 지원을 위해서 UTF-8로 고정하는 것이 좋을 것입니다.

위젯의 사용을 위하여 모든 코드는 <widget></widget>태그 내에 위치해야 합니다.
마치 HTML 문서가 <HTML>로 시작하여 </HTML>로 끝나는 것과 같습니다.
<widget version="1.0.0" minimumVersion="2.0">
...
</widget>
이와 같은 태그 문법은 HTML에서부터 익숙하게 사용해왔으므로 직관적으로 이해할 수 있습니다.

위젯 엔진은 태그의 어트리뷰트와 관련하여 세 종류의 표현법을 모두 지원합니다.
예를 들어 이미지 개체에 대한 정보를 표현하는 <image>태그는 다음과 같이 표현될 수 있고 모두 동일한 결과를 보여줍니다.
파일 경로 : "Resources/My Image.png"
배치할 위치 : 20, 10

▒ 1. 태그 블럭 내에 어트리뷰트를 태그로 표현
<image>
  <src>Resources/My Image.png</src>
  <wOffset>20</wOffset>
  <hOffset>10</hOffset>
</image>

▒ 2. 태그내에 어트리뷰트를 기입
<image src="Resources/My Image.png"
  wOffset="20"
  hOffset="10" />

▒ 3. 1과 2의 방법을 혼합하여 사용
<image src="Resources/My Image.png">
  <wOffset>20</wOffset>
  <hOffset>10</hOffset>
</image>
특히 XML 해석 규정에 따라 두번째 방법처럼 하나의 태그가 여러 줄에 걸쳐 작성되어도 두 칸 이상의 공백은 무시되므로 상관없습니다.

위젯을 선언했으면 위젯을 보여줄 윈도가 있어야겠지요.
<window name="mainWindow" title="Widget01">
  <width>100</width>
  <height>100</height>
  <visible>1</visible>
</window>
윈도 개체는 <window>태그로 작성되며 사용자에게 뭔가 보여주기 위해선 반드시 하나 이상의 윈도가 있어야 합니다.
위 코드에서의 각 어트리뷰트는 다음과 같은 의미를 가집니다.
  • name : 이 윈도 개체의 식별명, 자바 스크립트에서 접근할 때 사용됨
  • title : 윈도의 제목. 단순히 제목이에요.
  • width : 윈도의 너비
  • height : 윈도의 높이
  • visible : 윈도를 보여줄지 여부 (1=보여줌, 0=숨김)
설명할 필요도 없이 간단한 내용입니다. 물론 이 외에도 많은 어트리뷰트를 가지고 있고 상세한 내용은 레퍼런스를 참고하면 되겠습니다.


◆ 첫 위젯!

자 그럼 아주 간단하게 이미지 한장을 덜렁 내놓는 위젯 코드를 작성해보죠.
메모장을 열고 Widget01.kon 파일을 생성하여 다음 코드를 복사합니다. 예제에 충실하기 위해 필요 없는 코드는 완전히 배제했습니다.
윈도의 크기 및 이미지 파일의 경로는 수정해주셔야겠죠?

▼List 02-1

물론 파일 저장 구조는 전 절에서 설명한 대로 아래와 같이 구성하면 좋겠지요.

그리고 Widget01.kon을 실행하면 다음과 같은 경고 문구가 나오는데 [위젯 사용]을 클릭하고 넘어갑니다.

첫 위젯이 구동됩니다!
제목은 '희미한 기억을 더듬어 그린 황제 펭귄의 새끼 그림의 희미한 기억을 더듬어 그린 그림'입니다.
볼 수록 마음이 불안해지는 멋진 그림이죠.
아후.

구동된 위젯을 이리저리 옮겨보기도 하고 마우스 오른쪽 클릭으로 위젯 메뉴를 사용해보기도 해보면 위젯 엔진이 기본으로 제공하는 윈도 관련 명령을 써먹을 수 있습니다. 아무런 노력도 없이!!

이제 위젯을 시작할 수 있습니다.
여기에 레퍼런스를 참고하여 태그들과 스크립트를 조합하면 간단하게 위젯을 만들 수 있습니다. 직접 해보세요. HTML만 알아도 된다니까요? ;)




간단하게 소개만 하려고 했는데 너무 길어졌습니다.
다음 회에는 1회에서 얼렁뚱땅 넘어갔던 예제에 좀 더 제대로 된 설명을 붙여보도록 하겠습니다. :)

p.s.
어째 글이 어중간한 느낌이네요.
사용기도 아니고 설명도 아니고 강좌도 아니고...
원래 글쓰기는 형편 없었으니까 그러려니 하고 회가 거듭된다면 더 나아지겠지요.
그리고 피드백이 있다면 더욱더!
신고
Posted by gongdo

0호 : 프로젝트 시작도 전에 전의상실.
1호 : 늘 그렇잖아.
0호 : 오늘 야후! 위젯 엔진으로 끄적끄적해봤는데, 이거야 원 내가 적어도 한달은 걸려야 만들 수 있는게 이미 다 구현되어 있더라.
1호 : 그것도 늘 그렇지. 그런데 진짜 해보기라도 한거냐.
0호 : 내가 아무리 게으르다고 해보지도 않고 뭐라고 하겠나;;

0호 : 이것이 바로 위젯!
이런저런 위젯들이 많이 있는데 난 일단 야후! 날씨랑 주식 창을 띄워 봤어.
인텔 그래도 오르고 있구나... 25달러만 돌파하자 당장 판다 ㅠ.ㅜ
2호 : 헤에~ 어른의 세계.
1호 : ...
0호 : 음음. 샷처럼 불투명도를 조절 가능한데, 이거 98에서도 될지 몰라?
아마도 LayeredWindow API를 사용했을거라고 생각하고 98에서는 안되겠지?
1호 : 글쎄 그거 확인하자고 98깔고 앉아있을 수도 없고.
0호 : 관심 있다면 야후! 위젯 엔진 홈(http://kr.widgets.yahoo.com/)에서 다운 받을 수 있고 영문판 홈(http://widget.yahoo.com)에는 맥OS용을 비롯해서 약간 더 많은 정보를 얻을 수 있었어.
1호 : 역시 한국에서 맥OS는 개무시를 당하는구만...
0호 : 거기에 위젯 만들기에서 간단한 튜토리얼, 레퍼런스, 포토샵 레이어들을 위젯으로 간단하게 옮겨주는 스크립트 등등이 있고 포토샵 스크립트를 사용해서 데스크 토이의 아주 기초적인걸 만들어봤어.

0호 : 실행하면 이런게 나와서 이미지 2장이 0.5초마다 교차되는 매우 심플한 것이지만 기본으로 지원되는 환경 설정으로 시작하고 종료할 때 페이드인/아웃 효과나 반투명 지정이나 윈도를 최상위로 놓는다거나 하는걸 조절할 수 있고 사용되는 이미지에 따라 투명색은 윈도 리전을 자동으로 따주는 것 같아.
위쪽 샷에서는 캐릭터의 외곽선을 따라 윈도 리전이 세팅되어 있어. 이건 정말 귀찮은 작업인데 내가 이런 기능을 VB로 만들려고 1주일 걸렸지만, 위젯으로 10분 만에 만들었어. OTL
2호 : 그런데 저 그림도 니가 그린거야? 되~게 못그린다.^^
0호 : ...예 죄송해서 어쩌죠 앞으로도 저런거 봐야할텐데요. ㄱ=

1호 : 내가 소개하고 이런 얘기 하기 그렇지만; 난 Yahoo! 이 트레이드 마크가 정말 꼴보기 싫어. 다 좋은데 이게 야후가 제공하는 플랫폼이란게 제일 싫단 얘기지.
0호 : ...실은 나도...
0호 : 실제로 해보면 일단 야후! 위젯 엔진을 사용자가 개별적으로 설치해야 하는데 과연 데스크 토이 같이 작은 프로젝트를 위해 귀찮은 설치를 받아들일 사용자가 있을까? 약간 회의가 들긴 해.
1호 : 응, 나라면 토이 주제에 뭔가 설치하고 이것저것 옵션이 붙어있으면 짜증나서 안깔지.
0호 : 그 외에도 마음에 안드는게 설치 마법사에 기본값으로 야후를 시작페이지로 만든다거나 하는게 있어서 셋업하면 [다음]만 눌러대는 대부분의 일반유저는 본의 아니게 야후에게 피해를 받게 되겠지.
0호 : 시작부터 안좋은 점만 눈에 띄어서 좀 그렇지만 일단 좀 더 자세히 들어가보지.

0호 : 야후 위젯 엔진은 XML과 JavaScript가 핵심 키워드인것 같아. 실제로 텍스트 편집기 만으로 만들 수 있는 .kon 파일은 내부적으로 XML과 JavaScript를 섞어서 만들고 .widget 파일은 약간의 컴파일이 들어간 형태.
1호 : 어느 정도 익숙해지면 html 편집 수준으로 만들 수 있겠네.
0호 : 정확히. 근데 튜토리얼을 대충만 보고 만들어서 그렇겠지만 익숙해지기엔 약간 시간이 걸릴 것 같아. 레퍼런스도 HTML이나 비주얼스튜디오 형태의 도움말이 훨씬 찾기 편한데 PDF만 제공되고 있고. 뭐, 어딘가에 HTML이나 도움말 파일이 있을지도 모르겠지만.
튜토리얼만 보면 도무지 감이 안잡히는데 그냥 맨땅에 헤딩해보면 생각보단 쉬웠어.

▼[List 01-1]

0호 : 야후 위젯 엔진을 설치하고 메모장에서 저걸 그대로 카피하고 Resource폴더 아래에 Layer 1.png와 Layer 2.png 파일 넣고 실행하면 끝.
코드를 보면 HTML을 어느정도 손대본 사람이라면 설명이 필요 없을 만큼 간단해. XML 및 JavaScript기반이니까 당연하긴 하지만.
자세한 문법이나 기능들이야 레퍼런스를 참고하면 되고, 이미 작성된 것도 소스를 볼 수 있으니까 쉽게 참조가 가능해.
1호 : 확실히 소스가 공개된 클라이언트 스크립트들은 예제가 있으면 금방금방 카피해다 쓸 수 있으니까...
0호 : 일단 간단하게 깨작여봤지만 이걸로 데스크 토이를 만들 수 있는 가능성은 충분하다 못해 넘친다고 봐. 하지만 엔진 자체가 야후에 종속되어 있다는 점과 야후! 자체도 상당히 강조되어 있다는 점이 거부감이 들고, JavaScript의 태생적 한계는 분명히 있을 것 같아.
아, 그리고 한번 메모리에 로드된 위젯은 위젯 엔진에서 언로드해도 뭔가 파일 핸들을 가지고 있는 것 같아. 테스트용 위젯파일을 바탕화면에 폴더를 만들고 작성했는데 위젯 엔진을 완전히 종료하기 전까진 그 폴더를 삭제할 수 없었어.
1호 : 그건 정말 치명적인데;
0호 : 아직은 베타 서비스이고 연구 대상이니까 조금만 더 깨작거려보고 M$ 가젯이나 구글 데스크탑의 사이드바도 건드려볼래.
1호 : 헤에~ 꽤 성실하게 진행하네?
0호 : 두고보시라!

신고
Posted by gongdo

0호 : 그 뭐냐... 아무짝에도 쓸모 없고 약간 귀엽기만 한 캐릭터가 윈도 데스크 탑에서 돌아다니거나 마우스에 반응하거나 하는 애플리케이션 있잖아.
2호 : 글쎄... 무슨 얘긴지 잘...
0호 : 윈도 위에서나 태스크 바 위에서 돌아다니는 양 같은거 기억 안나?
0호 : 희미한 기억을 더듬어서 그려보자면...

0호 : 윈도 경계선에서 빨빨거리면서 돌아다니다가 가만 내버려두면 풀 뜯어 먹고 자고.
2호 : 아 기억난다. 마우스 쫒아다니는 고양이도 있었고, 투하트 캐릭터라던가...
2호 : ...근데 저건 너무 희미한거 아니야?
0호 : 생각 났으면 넘어가지.
1호 : 아, 플레이보이 성인모델의 미니쇼도 있었지.
0호 : ...
2호 : ...;
0호 : 진짜?
1호 : 응. 내가 언제 없는 얘길 하던가.
0호 : ... 어쨌든. 저런걸 만들어보고 싶어.
1호 : 저런 쓰잘데기도 없는 걸 뭐하러?
0호 : 일단은 취미지. 그리고 그렇게 단순하지만은 않은 구상도 있고.
2호 : 난 재밌을 것 같은데?
1호 : 또 하다 말려고...
0호 : 아 시끄러.
0호 : 내가 본 저런 종류의 앱(APP, Application)들은 그냥 단순했어. 뭐 그냥 양처럼 돌아다니거나 멈추거나 고양이처럼 따라 다닌다거나 아님 마우스 클릭에 특정 반응을 한다거나...
어떤 종류는 마우스 게임도 있었는데 쓸데없이 무거웠고 셋업도 해야했고.
내가 구상하는건 최대한 심플하면서 눈길을 끌만한... 그러면서 참여를 이끌어 낼 수 있는 아이템이야.
1호 : 말은 거창하지...
2호 : 참여라면 메신저 같은거?
0호 : 메신저 기능도 넣고 싶지만 아직 스킬이 안되고. 기술적인 면 보다는 컨텐츠, 그러니까 유저가 직접 그린 이미지가 화면에 떠서 움직이고 반응을 하고... 그런 플랫폼 역할을 할 수 있는 앱을 만든 후에 거기에 플러그인 형식으로 메신저든 메모든 RSS 리더든... 추가해 나갈 수 있겠지.
1호 : 후우... 그딴건 이미 나와있는 위젯으로도 가능하잖아. 이제와서 무슨 의미가 있나. 게다가 스킬 부족. 어느 세월에 이미지 처리 엔진 만들고 사용자 편집기는 어떻게 만들거며 배포는 어떻게 할건데? 아서라 아서...
0호 : ...음; 뭐 내가 생각하는 것의 90% 이상은 이미 구현되었거나 구현되는 중이라고 하지만; 위젯이라니?
1호 : 방금 말한거 모두, 일종의 위젯이라고 할 수 있지. 구글은 뒀다 어디다 쓸래. 검색 좀 해봐라. 정확한 의미야 검색해보면 나올테고, 일단은 작고 핵심적이고 단순한 기능을 위한 앱이라고 할 수 있겠지. 그리고 UI 적인 측면이 강조되어 사용자의 눈길을 끌 수 있으면 더 좋고, 아니 그런게 기본이 되어야 하고.
0호 : ...아 벌써부터 의욕 상실.
1호 : 작심삼분. 아니 작심도 전인가.
1호 : 어쨌든, 야후 위젯 엔진(http://kr.widgets.yahoo.com/) 이 대표적이라고 봐야하나. 예전엔 콘파뷸레이터(Konfabulator)라는 외우기도 힘든 이름을 썼었는데 지네들도 어려웠는지 이름을 위젯 엔진으로 바꿨더라고...
자바 스크립트를 사용하니까 제공되는 API만 익히면 사용하기도 쉬운 편이고... 귀찮으니 나머지는 검색.
0호 : 음음.
1호 : 돈냄새 잘 맡기로 유명한 M$에서도 윈도 비스타에 맞춰서 가젯 서비스 베타를 출시했는데 요건 좀 더 복잡한것 같아. M$에서 MSN의 다음 플랫폼으로 http://live.com을 밀고 있는 것 같은데 가젯은 live.com의 웹사이트랑 연동도 되고 개발 툴은 정말 잘만드는 회사 답게 개발 지원은 빵빵하고, 무엇보다 윈도를 사용하는 한 M$가 밀면 대세가 되니까. 충실한 M$의 개라면 이쪽을 파보는 것도 좋은 방법.
0호 : 휴우... 머리가 띵해지네.
내가 생각한 건 그리 복잡한 것도 아니고 해서 그냥 GDI나 기껏해야 GDI+ 정도를 사용해서 만들어볼까 했는데. 배포도 편하게. 나름대로 생각해 본 것도 많은데.
1호 : 세상일은 절대 니 맘대로는 안돌아가니 걱정마시고. 플랫폼이라... 혼자 쓰고 버릴 게 아니면 최대한 있는 걸 활용하는게 낫지. 아니 혼자 쓰더라도 거기에 투자한 시간이 아깝잖냐? 똑똑하신 고수들은 널리고 널렸어. 그 사람들이 생각해서 만들어 놓은게 있다면 적어도 어설픈 아마추어가 구상한 것 보다야 훨~씬 나을거다.
0호 : ...휴우...
0호 : 아 혼란스러워 공부 좀 더 해야겠다.
1호 : 마음대로~


...예 이런 데 관심 있는 개발자가 계신지요?
개념 자체는 상당히 단순하고 이미 구현되어 있는 형태도 많습니다.
몇 달 전부터 이런 구상을 해보고 있다가 구글링을 해보니 '위젯'이란 용어가 가장 적합하고 또 플랫폼을 만들어가고 있더군요.
간단하게 검색만 해봐서 정확한 개념 파악은 안됐지만, 일단 M$ 가젯보단 야후의 위젯 엔진(이전 콘파뷸레이터)이 더 구미에 당기더군요.
포토샵 CS나 플래쉬의 액션스크립트 엔진인 자바 스크립트를 기반으로 한다는 것도 강력한 점이겠구요.

하지만, 다름 아닌 M$입니다. 비스타의 출시와 함께 live.com, start.com과 사이드바의 가젯들... 그리고 엄청난 밀어붙이기 마케팅... 결정적으로 M$에 목매달 수 밖에 없는 많은 개발자들.

야후 위젯과 M$ 가젯, 그리고 다른 위젯 엔진들을 좀더 둘러보고 장래에 써먹을 수 있는 흐름에 합류할 것 인지 아니면 순수한 개발 의욕만으로 혹은 취미로 프로젝트를 진행할지는 좀 더 공부해봐야 겠습니다.

고민은 이쯤하고 정리합니다.
Desktop Toy 줄여서 Desktoy.
T를 대문자로 쓰는게 좋을지도. DeskToy.

이 프로젝트는 데스크 탑의 작은 앱을 통하여 유저가 그 이미지를 직접 제작하고 서로 교환하거나 배포하여 즐길 수 있는 커뮤니티를 목표로 합니다.

이번엔 뭔가 했다는 느낌 정도는 날 수 있게 해보자. 아자!

신고
Posted by gongdo


티스토리 툴바