오랫만(?)에 세미나 공지. 그간 세미나를 안한건 아닌데 이상하게 공지를 안올리게 되더군요.
어쨌든, 이번 세미나는 훈스닷넷 22회 정기세미나로 그 이름도 유치 찬란한 UX 뽀뽀뽀!!
훈스닷넷 22회 정기 세미나

이번 MIX10에서 실버라이트 4, 블렌드 4 그리고 WPF 4에 관한 소식이 쏟아졌죠? 그래서 Four, four, four = 뽀뽀뽀! (다시 한번 두둥!)
누구 아이디어냐고 묻지는 말아주세요. ㅎㅎ

어쨌든, 저는 실버라이트 4 발표를 맡았어요.
뭐 실버라이트 4의 내용이야 이미 PDC에서부터 많이 공개가 되어서 관심 있는 분들은 특별할게 없다...라고 생각하실지도 모르겠지만, 제 경우는 실버라이트 4가 앞으로 RIA시장에 또 하나의 충격을 줄 거라고 생각해요. 그 규모가 어찌되었던 말이죠.
또한 RIA라는 것 자체의 개념도 기존과는 많이 달라질 수 밖에 없고요.

가볍게~ 실버라이트가 어떡게 되어 가는지 확인해보세요!
마이크로소프트에서 만나요 :)
저작자 표시 동일 조건 변경 허락
신고
Posted by gongdo

effectiveui사의 CEO인 Anthony Franco가 발표한 10 Ways To Ensure RIA Failure 요약본이에요. 물론 야매TM 영어로 들은거라 엄청나게 오해한 내용도 있을테니 비디오를 직접 보시길…^^;; videos.visitmix.com/MIX09/c06f

 

시작 할 때 나오는 인상적인 도표.

UX를 말할 때 항상 나오는 "사용자". 하지만 좋은 사용자 경험을 제공하는 애플리케이션을 개발 하는 것은 결코 쉽지 않은 일이죠.

앤써니는 RIA를 개발 할 때 실패하고 싶다면 다음과 같이 하라고 역설하고 있어요. 노파심에서 얘기하지만 다시 말해, 아래에서 굵고 크게 붉은 글씨로 표시한 표제들을 하지 말라는 거에요^^ 물론 그 외의 굵은 글씨는 중요한 것을 의미하고요;

1. 최종 사용자를 고려하지 말 것.
DO NOT UNDERSTAND THE END USER

70%에 가까운 IT 프로젝트가 실패하는 이유는 실제 사용자가 받아들이지 않았기 때문이라는군요. 그러면서 예를 든 유명한 사례는 미국의 최초의 MP3P인 Diamond Rio인데요, Apple의 아이팟에 비해 모든 스펙이 앞서 있었을 뿐만 아니라 2년 동안이나 시장을 장악하고 있었지만 결국 지독하게 나쁜 사용성때문에 아이팟에세 떠밀리고 말았다고 해요.

결론으로 소프트웨어 개발의 새로운 황금률을 제시하는군요.

최종 사용자에게 강하게 집중하라!

  • 다른 모든 규칙은 부차적일 뿐이다
  • 다른 모든 실패는 절대적으로 이 조언을 무시했을 때 돌아오는 결과이다

 

2. 개발자들이 좋은 디자인 결정을 내릴거라고 믿을 것.

TRUST DEVELOPERS TO MAKE GOOD DESIGN DECISIONS

개발자들에게 UI를 맡겼을 때 나오는 결과. 왜 이런 결과가 나오냐에 대해 다음과 같이 정리하네요.

개발자들은 정말 좋지 않은 결정을 조장한다

  • 개발자들의 결과물은 프로젝트 계획이나 기능이나 일정에 기반한다
  • 개발자들은 데드라인에 맞출 수 없게 되면 최종 사용자가 진짜로 바라는 것에 집중하기 보다는 기능 구현에 전력을 다한다

이것은 디자이너와 개발자가 가지는 생각의 차이Mind Gap 때문인데 이런 생각의 차이를 메꾸기 위해 다음과 같이 제안하죠.

디자이너를 믿어라

  • 사용자는 애플리케이션이 Silverlight, AJAX, Flash, .Net… 어떤 것이든지 상관하지 않는다
  • 정치나 사조직이 끼어들도록 하지 말라
  • 기술적인 과제를 놓고 허심탄회하게 디자이너와 얘기하고 알려라, 그러면 디자이너는 싸우는게 아니라 함께 일하게 될 것이다
  • 좋은 디자이너는 최종 사용자와 그들의 요구를 뭔가 쓸만한 것으로 옮기는 데 도움을 줄 것이다
  • 의심이 들면 사용자에게 물어보라

 

3. 기적같은 아이디어의 디자인을 기대하라.

HOPE FOR A SILVER BULLET DESIGN

때로는 엄청난 아이디어가 중요하기도 하고 작은 변화가 큰 결과를 만들기도 하지만 기본적으로는 '효과'가 아닌 '내용'에게 집중하라는거죠. 정리하자면,

사용자를 믿어라

  • 공감이란 단어를 새겨놓고 사용자와 대화하여 행동하라
  • 사용자의 피드백을 바탕으로 자발적으로 아이디어를 내놓아라
  • 포트폴리오에 신경쓰지 말라
    • 만약 사용자가 UI에 신경쓴다면 분명히 실패할 것이다

음… 알아듣기 힘드네요. 어쨌든 그 외에도 사용자의 피드백을 문자 그대로 받지 말고 정확히 어떤 것을 원하는지를 생각하라는군요.

4. 모두를 위한 애플리케이션을 만들어라.

BUILD FOR EVERYONE

"모두를 위해 만든다면 아무에게도 필요없게 된다."

왜 아이폰 사례를 소개하는지 잘 못들었지만(=_=), 제목이 "iPhone의 저주"네요. 여기에서 왜 아이폰을 디자인의 사례로 생각하면 안되는지를 설명하는데요,

  • 애플은 엄청난 비용을 디자인에 쏟아 붓는다
  • 모든 컨트롤들이 과도하게 통합되어 있다
  • 사용하기 어렵다 – 직관적이지 않다
  • 익숙하게 하기 위해 마케팅에 비용을 쏟아 붓는다

그러니까 애플은 디자인과 사용자 경험으로 성공한 사례로 칭송받지만 사실 애플처럼 할 수 있는 기업은 거의 없다는 것을 지적하는 것 같네요. 특히 사용자 경험에 대한 관점이 그런데요, 사실 아이폰의 플립 슬라이드의 동작 방식이 경험이 없다면 어떻게 알 수 있겠어요? 바로 직관적이지 않다는 얘기죠. 그리고 애플은 그런 약점을 커버하기 위해 아이폰의 광고 대부분을 아이폰을 어떻게 사용하는지 애플리케이션을 어떻게 동작하는지에 할애하고 있다는 거죠. 그것도 엄청난 비용을 들여서요.

어쨌든 다음과 같이 결론을 내리는데요,

다음의 사항에 노력을 집중하라

  • 사용자가 공감할 수 있게
  • 하나의 프로젝트에 최대 3개의 페르소나Persona만 정의하고 그들에게 강력하게 집중하라

 

5. 런칭하고 잊어버려라.

LAUNCH & FORGET

뭐어… 런칭하고 나서도 꾸준히 사용자의 행동을 측정하고 분석하고 그런 피드백을 바탕으로 향상시킬 수 있게 하라는거죠.

 

6. 성공을 정의하지 말라.

DO NOT DEFINE SUCCESS

성공을 정의하려면, 기능이 아니라 이득benefit에 대해 토론하라

  • 질적인 이득
    • 고객이 빠른 업무 처리를 인지한다
    • 고객이 이 소프트웨어를 친구에게 추천한다
    • 브랜드 일관적이고 신뢰할 수 있는 경험이 되어야 한다
  • 양적인 이득
    • 배송을 추적하는데 드는 시간이 20% 감소한다
    • 선결제가 50% 증가한다
    • 고객 서비스 전화가 50% 감소한다

 

성공은 충돌을 수반한다, 적당한 균형을 찾아라

7. 모든 충돌을 피하라.

AVOID ALL CONFLICT

"충돌없는 진행는 없다"
"모든 사람이 동의한다면 프로젝트에 문제가 있다는 신호이다"

8. 아이디어까지 팔 필요는 없다고 믿어라.

BELIEVE YOU SHOULDN’T HAVE TO SELL YOUR IDEAS

아이디어를 팔기 위해서:

  • 프로젝트에 연관된 개인들을 이해하고 그들이 반대 의견과 걱정을 가져오기 전에 먼저 말하라
  • 고객의 의견을 듣고 당신의 의견이 그들과 일치한다는 것을 확신시켜라, 그리고 다른 고객들의 말을 빌어 말하라("전에 우리의 고객들이 얘기해준 것과 같네요…")
  • 겸손하지만 정렬적으로 아이디어를 말하라
  • 공격적으로 팔라

 

9. 완벽한 계획을 세워라.

PLAN FOR PERFECTION

심지어 길을 찾는 것도 많은 변수가 있고 변경이 있으니 개발은 어떻겠느냐는 거죠. 뭐 많이 얘기되었던 사항이죠.

 

10. 제품보다 프로세스에 가치를 두라.

VALUE PROCESS OVER THE PRODUCT

엄청나게 많은 프로세스 다이어그램이 있지만 어떤 것도 실제 프로젝트와 일치하지 않는다는군요. 제 아무리 좋은 프로세스와 방법론으로 '제 시간에' 개발 했을지라도 제품이 엉망이면 아무 의미가 없다고 정리하네요.

우리가 '아이디어'를 스케줄에 포함 할 수 있다면 좋겠지만 좋은 아이디어는 절대로 스케줄을 잡는다고 나오는게 아니죠. 소프트웨어 프로젝트는 건설 프로젝트와는 달리 완벽하게 설계하거나 예측할 수 없죠.

사람들은 전혀 기대하지 못한 상황에서 문제를 해결하는 경우가 많다고 해요.

뭐 그 뒤로는 회사 자랑이 조금 이어지고요^^

암튼, 몇몇은 이제 꽤나 잘 알려진 사항이지만 한번 쯤 들어볼만해요. 시간도 40분정도 밖에 안되니까요.

저작자 표시 동일 조건 변경 허락
신고
Posted by gongdo

트랙백이 없는 네이버 카페ㅠ.ㅜ
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
2008/01/18 - [잡소리/Wired] - 네이버 의약학사전, 알고 계시나요?
에 이어,

http://medic.naver.com/pharm_search.php
이야 이건 더 재밌네요!

이런 건 좀 더 직관적인 형태로 재밌는 웹 애플리케이션을 만들어 볼 수 있겠어요. (동물모양 약이라니;;; )
뭔가 선택할 때마다 범위가 좁혀지면서 해당 범위 안의 약들이 좌르르르 쏟아진다거나...

그런데 이 정보를 댓글에서 얻었는데 그 댓글이 사라졌군요? :)
신고
Posted by gongdo

MNet 미디어(http://mnet.com)가 더욱 풍부한 사용자 경험을 제공하는 미디어 서비스인 TVDeep(http://tvdeep.mnet.com)을 실버라이트로 전환했어요.
실은 지난 12월 3일부터 XP에서 IE 6.0을 사용하고 있는 일부 유저를 대상으로 시험 서비스를 시작했지만 시험적으로 열었다 닫았다를 반복하고 약간의 기능 구현이 안되어 있어서 자신있게 소개드리진 못했네요. :(


실버라이트가 없을 때 접속하면 아주 강력하게 설치할 것을 어필하죠. 이부분은 좀 더 설명이 필요 할 것 같아요. 오픈 3일동안 추세를 보면 대부분의 유저가 아무런 의문이나 불만 없이 -혹은 아무 생각 없이- 설치하고 넘어가긴 했지만, 그래도 실버라이트를 왜 설치하는가, 무엇이 좋아지는가에 대한 설명 정도는 해줘야 하지 않을까요?

 
설치 버튼을 누르면 곧바로 다운로드 창이 열리면서 설치할 수 있게 하죠. ActiveX의 노란 띠보다는 훨씬 직관적이고 정확한 설치 방식이라고 생각해요. 하지만 일반 사용자에게 이런 방식을 썼을 때 ActiveX는 그냥 설치하면서 애플리케이션은 설치하지 않는 경우가 더러 있다는군요. 누굴 탓하겠습니까. 앞으로 조금씩 바꿔야겠죠.


설치는 상당히 짧은 시간내에 끝나고 설치가 완료되면 브라우저를 재로딩 할 필요 없이 곧바로 로딩 및 재생이 시작되죠.

TVDeep의 메인 화면, 여타 다른 미디어 서비스와 다를게 없어 보이죠? 하지만 미디어 서비스 사용자들의 요구를 만족시키는 몇 가지 기능들이 있어요.

먼저 가장 특징적인 PIP화면. 오른쪽 위를 보면 뭔가 드래그 해보라는 메시지가 있네요? 한번 따라해보죠.
 
선택된 아이템을 드래그&드랍하면...

조그만 창이 열리면서 로딩이 시작되고

메인 동영상과 함께 PIP 동영상이 함께 재생돼요. 마우스 커서가 메인 동영상에 있을 때는 메인 동영상의 소리가 재생되고 PIP에 있을 때에는 PIP 동영상의 소리가 재생되죠. 또한, PIP는 드래그해서 위치를 옮길 수 있고 클릭했을 때는 메인 동영상과 화면이 전환되죠.

이 기능은 미디어 서비스를 많이 이용하는 사용자에게 빠르게 채널을 선택할 수 있도록 해주죠. 보통 이런 미디어를 많이 소비하는 사용자는 지금 보고 있는 동영상도 있지만 또 다른 관련 영상을 계속해서 검색하고 열어보길 원하는데요, 이럴 때 PIP는 화면의 전환 없이 또 부담 없이 다른 영상을 검색할 수 있게 하는 거죠. 특히, 이 기능은 관련 영상 및 검색과 맞물려서 더 쾌적한 환경을 마련합니다.

앞에서 얘기한 관련 영상을 한번 볼까요?

영상 하단에는 지금 재생중인 동영상과 관련된 영상 목록을 보여주는 곳이 있어요. 이 목록에 적용된 애니메이션도 그간 많이 소개되어 왔던 것들이라 식상할지도 모르겠지만 상당히 멋진 움직임을 보여주죠. 그리고 이 관련영상도 검색된 목록과 마찬가지로 드래그를 하여 PIP로 띄울 수 있어요.

 

다음으로, 북마크 기능인데요, 단순히 영상을 북마크하는게 아니라 내가 원하는 장면의 일부만 저장하고 열어보기 위한 기능이에요.


한가지 아쉬운건, 구간 선택시 위치 선택 헤더를 따라서 동영상이 원활하게 움직이면 좋을텐데 대부분의 영상은 MMS로 서비스되기 때문에 스트리밍을 위한 버퍼링이 있고 그래서 헤더가 움직이고 나서 약 3~5초 후에나 해당 위치의 영상이 나온다는 점이 있어요. 이것은 현재 기술상의 한계라고 볼 수 있겠죠.


구간을 선택하고 제목을 입력한 후 이미지를 선택하고 완료.


내 구간 저장 탭에서 저장된 내용을 볼 수 있고 같은 방식으로 사용 가능.

 
실버라이트에서 가장 큰 어려움 중에 하나는 바로 '퍼가기' 기능인데요, TVDeep은 이 문제를 단순 링크 방식과 iframe 방식으로 처리하고 있어요.

 
TVDeep의 배너 광고. 미디어를 재생하고 있는 도중에도 미디어를 가리지 않고 추가적인 광고를 삽입하고 있죠. 이 광고는 노출되는 시점을 DB에서 조절할 수 있게 되어 있어서 특정 영상에 특정 광고를 특정 시점에 노출할 수 있어서 광고의 구성에 따라서는 굉장히 높은 효율을 보일 수 있을거에요.

이 외에 풀스크린에서도 동일한 방식으로 사용할 수 있고 다른 기능들은 일반적인 미디어 플레이어와 동일하니 패스.

한가지 화면에는 설명되지 않는 팁을 알려드릴께요. :) TVDeep 플레이어는 몇 가지 키보드 제어도 가능한데요, 다음과 같은 단축 키를 지원하고 있어요.

→ : 앞으로 10초
← : 뒤로 10초
↑ : 볼륨업
↓ : 볼륨다운
Space : 재생/정지
M : 음소거

하지만 실버라이트에 포커스가 왔을 때에만 동작하니까 포커스를 잘 맞춰야 동작하네요.

MNet 미디어의 TVDeep은 실버라이트가 기존 웹 환경, 웹 페이지에서 다른 요소들과 함께 '지금 당장' 사용이 가능하다는 것을 보여주는 사례라는 점에서 팝업으로 제공되는 SBSi의 NView와 다른 의미를 가지고 있어요. 물론 사실을 얘기하자면 TVDeep은 iframe을 통해서 제공되기 때문에 어떤 의미에서는 팝업과도 같다고 볼 수 있지만 사용자에게 있어서 TVDeep은 전체적으로 하나의 페이지로 받아들여지게 되죠.

기술적으로 TVDeep은 실버라이트 1.0 즉, JavaScript 만으로도 이 정도 수준의 기능 구현이 충분히 가능하다는 것을 증명하고 있어요. 지난 5월 MIX에서 많은 사람들을 낚았던 Top Banana의 웹 동영상 편집기의 사례를 생각해보면 이 애플리케이션은 데모를 위해서 미리 준비된 리소스들(수많은 이미지, 동영상, 화면 등)로 구성된 '눈속임'이 많았죠. 하지만 TVDeep은 실버라이트 1.0과 ASP.NET AJAX와의 완벽한 조화를 통해 미디어 제어, 검색, 데이터 바인딩, 북마크, 실시간 동영상 구간 지정, PIP 등과 같은 기능들을 실제로 작동하게 구현했다는 거죠.

TVDeep은 향후 웹 미디어 플레이어 환경에 상당한 영향을 줄 것이라고 예상할 수 있어요. 기존의 미디어 플레이어가 단순히 재생을 위한 역할이었다면 TVDeep은 사용자의 미디어 소비 패턴 즉, 사용자의 경험을 더 중시한 기능들을 제공하고 있고 특히, PIP기능은 빠르게 미디어를 소비하는 사용자의 요구를 만족시키는 간단하지만 강력한 도구가 될 것이라고 확신해요.

TVDeep은 새로운 기술-실버라이트-이 기존의 기획과 디자인이 가지고 있던 상상력의 제한을 풀어주고 사용자 경험을 끌어올릴수 있다는 것을 보여주고 있어요. TVDeep의 사례가 더 재밌고 풍부한 사용자 경험을 제공하는 애플리케이션을 기획하고 디자인 할 수 있는 계기가 되었으면 해요.

마지막으로 TVDeep은 여기에서 그치지 않고 벌써 다음 세대의 미디어 서비스를 구상하고 있어요. 아직은 물리적인 인프라스트럭처가 구성되지 않았지만 제반 환경만 마련된다면 기술적으로 충분히 구현이 가능한 멋진 서비스들이죠. 기대하셔도 좋아요!

P.S.
그간 1.0으로 작업하면서 엄.청.나.게. 많은 삽질과 고난이 있었어요. 관련된 얘기는 천천히 풀어볼께요. :)

신고
Posted by gongdo
별건 아니고 UX, RIA와 Silverlight를 소개하는 간단한 PPT자료에요.
뭐 기존에 있던걸 여기저기서 카피해다가 짜집기 한거라 대부분 보셨던 걸거에요.
그야말로 뉴비를 대상으로 디자이너가 있다는 가정하에 한거라 코드같은거 한줄 안보여주고 소개 위주로만 했어요.


이걸로 사내 세미나를 진행했는데 정말이지 UX, RIA, Silverlight 중에 들어본 단어가 하나도 없다가 95%였고 그나마 RIA나 UX는 들어본 것 같긴하다 가 한명 정도;;;

좀 암울하네요. -_-;
뭐 다른 데도 마찬가지겠지만 이런거 별로 관심도 없어 하고요.
아니 애초에 개발이란 것 자체에 관심이 없는 것 같기도 해요.
도대체 뭐하러 개발자가 된걸까...
그냥 사무실에서 일하니까 만만해보여서?
신고
Posted by gongdo

네이버 실버라잇 카페에 올라온 질문(http://cafe.naver.com/mssilverlight/166)에 대한 나름대로의 생각이에요.



사용자 리소스에의 무제한적인 접근.
이것이 바로 ActiveX가 훌륭한 기술임에도 불구하고 사방팔방에서 뭇매를 맞게된 가장 큰 원인이죠.
ActiveX에 대해 오해가 생기지 않도록 얘기하자면 엄청나게 길어지겠지만, 과감하게 압축해서 얘기해볼께요. 다소 엉뚱한 주장이 들어가더라도 이해해 주세요.

ActiveX는 애초에 HTML의 한계를 벗어난 동적인 웹애플리케이션을 작성하기 위한 시도였어요. 무려 10년도 전에 이미 지금 말하는 RIA라는 것에 대한 고민과 하나의 해답이었던거죠.

시장의 흐름을 캐치하고 빠르게 ActiveX를 발표한 것 까진 좋았는데, MS가 늘 그래왔듯이 초기에는 거대한 구멍투성이의 기술이었고 이를 애초의 목적인 동적인 UI 구성에 사용하는게 아니라 갖가지 악의적인 구멍으로 사용되어 버렸죠.

해외에서는 진작에 이런 문제점들과 플랫폼 종속적인 한계 때문에 최강의 기술이었던 ActiveX를 사용하기 보다는 다소 불편한 DHTML, JavaScript, CSS 등의 기술들을 더 선호하게 되고 급기야 구글맵으로 유명해진 AJAX를 탄생시키게 되었죠.

반면 국내에서는 해외와 달리 일반 유저의 IE 의존도가 99% 이상이었기 때문에 애초에 플랫폼을 고려할 필요가 전혀 없었고 보안 문제는 누구 하나 지적하는 일 조차 없었어요. 국내 개발자들을 탓하는게 아니에요. 보안... 당장 한달 걸릴 일을 1주일만에 해내라고 닥달하는데 누가 신경이나 쓸 수 있었겠어요? 여하튼.

그런 와중에 ActiveX의 무분별한 사용을 어느정도 제어하기 위해 XP SP2가 출시되었지만 국내는 이미 ActiveX 중독 말기환자였고 정상적으로 ActiveX를 꼭 필요한데만 사용하는게 아니라 사용자에게 'ActiveX 설치 어쩌고 나오면 예를 누르세요', '팝업이 막히면 풀어주세요' 이따위 대응을 하게 되었던 거죠.

이 점은 강력하게 개발자를 성토할 수 있어요. 분명히 중독에서 치료될 수 있는 기회였는데 스스로 거부한 셈이죠. 여하튼.

이런 역사(?)때문에 ActiveX가 웹애플리케이션의 전부인양 생각하게 되었고 웹애플리케이션이 사용자 리소스에 접근하는데 아무런 거리낌이 없게 되었지만, 단정적으로 얘기해서 웹애플리케이션은 사용자 리소스에 접근 할 수 없고 접근 해서도 안되는 거에요!

ActiveX에 대해 정리하자면,
1. ActiveX는 동적인 UI 구성 등을 기존 윈도 개발자가 빠르게 접근할 수 있도록 도와주기 위해 나온 기술이다.
2. 하지만 그 무한한 접근권한 때문에 원래 의도와는 달리 철저하게 악용되는 기술이 되어 버렸다.
3. 그런 문제 때문에 ActiveX의 무분별한 사용을 줄이고 다른 방법으로 웹애플리케이션을 구현하게 되었는데 국내에는 중독에서 헤어나오지 못했다.
4. 그 결과 국내에서 ActiveX를 통해 사용자 리소스에 접근하는 것에 대해 아무런 의문도 문제점도 느끼지 못하게 되었다.

이에요.

다음 실버라잇으로 넘어가서, MS는 어느 매체에서도 실버라잇으로 ActiveX를 대체할 거라고 발표한 적은 없어요.

다시 한번 강조하지만 실버라잇과 ActiveX는 개미 눈꼽만큼도 비교할 만한 기술이 아니에요.

비교한다면 실버라잇, Flex(플래쉬도 아닙니다), JavaFX인지 뭔지(이쪽은 관심이 없어서 이름도 잘 몰라요;;;) 이 정도 되겠고요.

심지어 DHTML도 실버라잇과 비교할만한 기술은 아님과 동시에 DHTML, CSS, JavaScript, AJAX 등의 기존 기술은 실버라잇과 함께 사이좋게 연동할 수 있는 평행한 관계라고 보면 되겠습니다.

Q. 그럼 도대체 실버라잇을 왜써요?
A. 좋은 질문이죠. 한마디로 압축하자면 실버라잇은 RIA를 구현하기 위한 기술이에요.

Q. 그럼 기존에 플래쉬도 Flex도 있는데 뭐하러 써요? 머리아프게?
A. 실버라잇은 프리젠테이션의 표현을 XAML이라는 XML로 완전히 공개적으로 제공하며 따라서 프리젠테이션의 교환, 다시말해 디자이너와 개발자와의 협업이 훨씬 더 유연해질 수 있어요. 그리고 이 XAML은 일반적으로 컴파일되지 않고 공개되므로 다른 웹애플리케이션, 다른 서비스들과 동일한 코드를 가지고 연동할 수 있어서 디자이너-개발자 수준을 떠나 서비스-서비스 수준의 협력이 가능해요.

단순히 기능적인 면만 살펴봐도 이미지 리소스와 동영상 리소스에 대한 런타임 자체의 지원이 실버라잇 쪽에 압도적으로 우세하고 특히 실버라잇은 완전한 클라이언트 기술로 서버 사이드에는 아무런 제약이 없기 때문에 Flex처럼 별도의 라이센스 서버나 라이센스된 코덱 같은 추가적인 낭비가 필요 없어요.

이 외에도 말하자면 엄청나게 많지만 이쯤하죠. 자세한 검색은 셀프.

Q. 그건 그렇다치고 그러니까 왜 내가 만든 실버라잇 프로그램으로 사용자 리소스에 접근 못해요? 우리 서버랑 통신도 해야되고 백도어도 만들어야 되고 파일 업/다운도 해야되는데...
A. ActiveX 편을 다시 복습하시기 바래요. 그리고 지금 백도어 까는걸 자랑이라고 하는거니? 응? 응? 응?

추가적으로 TCP통신 기능에 관해서는 Silverlight 1.1 개발팀에서 심각하게 그 방법을 제시하기 위해 노력한다고 MS의 로렌스 모로니씨에게 '직접' 들었어요.(맞아요, 자랑하는거에요. 히히 싸인도 받았지롱~) 실버라잇 개발 로드맵 상에도 WCF 기술이 포함되는 것은 거의 확정적이라고 보고 있으니 이 부분에 대해서는 조금 기다려야겠고, 지금 당장 필요하다면 서버사이드에 프록시를 만들어 연동할 수도 있어요.

Q. 에고... 그럼 파일 업/다운은요?
A. 옙. 돼요. 실버라잇은 사용자 리소스에 대한 접근과 크로스 도메인(외부 주소)에 대한 접근을 아주 철저하게 막고 있지만 몇 몇 애플리케이션 개발에 필수적인 수단은 제공해요.

예를 들어 파일 업로드를 위해 파일 목록을 얻어야 한다면 그 파일 목록을 개발자 코드가 지 꼴리는대로 검색해서 가져갈 수 있는게 아니라 사용자에게 업로드할 파일을 선택하는 다이얼로그를 띄워서 사용자가 직접 선택하게 되어 있고 다운로드 역시 다른 곳에 악용될 수 있는 시스템 폴더(C, C:\Windows, C:\Windows\System32) 따위에 명시적으로 접근할 수 있는게 아니고 실버라잇 웹애플리케이션에 종속적이고 암시적이며 다른 애플리케이션에 고립된 영역에 저장돼요. 만약 사용자가 저장을 원한다면 마찬가지로 저장할 위치를 결정하는 다이얼로그를 통해서만 가능하죠.

Q. 아 짱나 그냥 ActiveX 쓸래요.
A. 옙, 그러세요. 한가지 안좋은 소식이 있다면 VISTA 이후로 ActiveX가 예전처럼 지 꼴리는대로 사용자 리소스를 헤집을 수 있게 놔두지 않을거에요. 아직 레거시 지원때문에 이런저런 유도책을 제공하고 있긴 하지만 단언코 말하건대 ActiveX의 사용자 리소스 접근은 결국 막히게 될거에요. 뭐, 그때까지 생명연장의 꿈을 꾸는 것도 나쁘진 않겠죠. 모름지기 개발자는 꿈을 품고 살아야하니까요. ^-^

그냥 라이브 타이핑(?)하다 보니 말이 막나간 점도 있긴 하지만, 이 긴 문장들은 단 하나의 문장으로 요약할 수 있겠어요.

웹앱(Web Application)은 웹앱이요 데스크탑앱은 데스크탑앱이로소이다.

P.S.1. 혹시나 또 오해가 있을까 말해두지만, 질문 올리신 네오군님을 공격하기 위한 설명이 아니에요;; 나름대로 재미있게 쓴답시고 저렇게 쓴거니까 삐지지 마세요.
P.S.2. 추가적인 의견 대환영~♥

신고
Posted by gongdo
[WebAppsCon 후기] 리치 웹 기술의 미래 토론(2)  에서 계속...

토론 중 첫 질문 시간에 RIA와 클라이언트 부하에 대한 이슈가 나왔는데요, RIA가 서버 입장에서는 온갖 자원을 클라이언트에게 떠넘김으로써 서버 부하는 줄겠지만 사용자 입장에서는 웹이 더 무거워지는게 아니냐...란 요지의 질문이었던 걸로 기억돼요.

물론 어떤 런타임은 최적화가 되지 않아서 동일한 표현이 다른 기술에 비해 특히 안좋을 수도 있어요. 하지만 웹사이트 부하의 대부분은 너무 많은 수의 이미지 파일과 잘못된 코드에서 기인한다고 생각해요. 그런 점에서 '사용자에게 부하를 떠넘기느냐?'보다는 '사용자에게 더 나은 경험을 제공한다'라는 관점이 더 유효할 것 같네요.

성능적인 관점에서 Silverlight은 로렌스씨의 데모에서도 강조되었지만 특히 미디어를 다루는데 있어서 다른 기술들에게 넘사벽(넘을 수 없는 4차원의 벽)을 선사하며 엄청난 효율을 보여주고 플렉스/플래쉬는 빌드가 swf 단일 파일로 되므로 배포가 용이하고 초기 파싱이나 코드 로딩이 빠른 장점이 있죠.

...그런데, 실제로 써보면 동적으로 XAML을 파싱하는 실버라잇도 별로 느리지 않고 되려 비슷한 수준의 오브젝트 구성이면 실버라잇 로딩이 더 빠르게 느껴지는건 기분탓 만은 아니겠죠? 이 부분은 넘어가구요.

여하튼 뭐 누가 좋네 나쁘네 얘기가 중요한게 아닌데 한가지, 어도비측 패널에선 매우 부적절한 예시를 든 것 같아요.

어떤 영화 사이트에서 이벤트 당첨자 몇명? 천명이었나 만명었나를 한 페이지에 게시를 했다가 웹사이트가 다운되었다...는 건데요. 이거야 말로 전형적으로 잘못된 코드 사용으로 인한 문제 아닐까 싶어요.

이 케이스에서 만명이라고 치고, 이 정도 숫자의 목록을 한 화면에 표시한다는 것 자체가 잘못된거죠. 당연히 검색기능을 넣든 페이징을 하는 것이 정답이죠.

설사 이걸 플래쉬든 뭐든 컴파일된 작은 용량으로 만들었고 이것이 한 화면에 아주 문제 없이 잘 나타났다고 해도 그건 잘못된 구성일 거에요.

예시는 별로 적절하지 않았지만 어쨌든 swf의 압축으로 인한 장점을 얘기한 것 같구요, 실버라잇은 swf에 비해 다소 복잡한 구성을 이루지만 개별 리소스의 관리 측면에서는 더 효과적이라고 생각해요. 게다가 실버라잇은 Downloader를 통한 ZIP 패키지도 지원하고 있으니 트래픽을 줄이는 방법도 제공하고 있구요.

RIA 기술들 간의 성능 비교는 http://bubblemark.com/ 이쪽을 참고해보세요.


토론의 마지막 질문은 바로, 거금 2만 2천원을 아낄 수 있게 한 댓글 이벤트에서 나온 그것! 히힛.

원래 제가 올렸던 질문은 좀 Silverlight에 치우친 거였는데 진행하시는 분께서 아주 적절하게 가공하셔서 질문의 수준마저 높아진 느낌이었죠.

질문의 요는, 적절한 보안 통제속에 사용할 수 있는 로컬 스토리지의 활용성과 향후 계획에 관한 것이었구요. 답은 약간은 뻔한 거였죠.

실버라잇은 '향후' 이러한 지원을 per Application, per Domain, per Service등 다양한 모델로 지원할 수 있을 것이라는 다소 희망적인 그러나 피상적인 답변이었고, 어도비쪽은 역시 기억에 안남고, OpenLaszlo쪽은 당연히 표준에서 제공하지 않는 기능이니 불가능이겠고요.

좀 더 덧붙이자면, 실버라잇은 웹 애플리케이션이 로컬의 암시적인 장소에 생성된 스토리지에 접근하여 기록하고 읽을 수 있는 IsolatedStorage를 지원하고 있어요. '암시적'이란 것은 이 스토리지(폴더)의 물리적 위치는 알 수 없고 단지 참조만 가능하며 상위 폴더로 올라가는 것도 불가능한, 그야말로 '격리된' 공간이죠.

어떻게 보면 쿠키의 확장인데요, 쿠키의 보안 이슈와 마찬가지로 당연히 로컬로 저장되는 내용에 보안에 영향을 주는 정보를 넣어선 안되겠죠. 제 생각엔 갈 수록 대용량화 되는 웹 사이트의 리소스를 보다 넓은 범위에서 캐슁하기 위한 용도로 좋을 것 같아요. 그러나 실버라잇은 아직 per Application 즉, 한 실버라잇 페이지 당 하나의 스토리지가 생성되어서 같은 서비스끼리 서로 그 스토리지를 공유할 수 가 없어서 비효율적이에요. 뭐 앞으론 더 넓은 범위의 지원을 한다니까 기다려 봐야죠.

또 MS의 황리건님과의 대화에서 알게 되었는데, 플래쉬의 경우는 Shared file(?? 이름은 정확히 기억 안납니다) 기능이 있는데 플래쉬가 설치된 경로에 각 도메인별 또는 애플리케이션별로 지정된 암호화된 파일 스토리지를 지원한다는군요.

여하튼, 현재로서는 커다랗고 많은 수의 미디어 파일(이미지, 음악, 동영상)의 캐슁은 순전히 브라우저의 캐슁 기능에 의존하는데 따라서 브라우저 별로, 그리고 시스템 환경에 따라 대용량 미디어가 많은 페이지의 표시 효율이 다르겠죠.

이런 점에서 각 애플리케이션이 보안 이슈에 독립적으로 사용할 수 있는 공간은 보다 안정적이고 효율적인 캐슁에 많은 도움이 되리라 생각해봅니다.


시간이 빡빡해서 정신 없이 돌아갔던 것 같네요. 한꺼번에 너무 많은 걸 준비하다 보니 그런 것 같아요. 남은 컨퍼런스들은 더 이상 집중하기 힘들 것 같아서 집에 왔습니다.

꽤 길게 후기를 썼지만 이번 컨퍼런스에서 가장 인상 깊었던 건 OpenLaszlo 프로젝트. 로 요약할 수 있겠네요;
나중에 Raju씨의 발표내용이 올라온다면 꼭 한번 보시길 권장해요!
신고
Posted by gongdo
비도 시원~하게 내리는 오늘, 웹앱스콘에 다녀왔습니다.
원래 비전 나잇까지 가서 뭔가 사람도 좀 만나보고 싶었는데, 저에겐 다행하게도 MS의 황리건님과 김국현님과 잠깐이나마 인사하고 대화를 할 수 있어서 다른건 가볍게 포기하고 집에왔네요. 스프링노트는 관심있었는데 그것까지 듣고 올걸 하는 후회도 쬐끔...

방금전까지 담소(?)를 나누다 온 황리건님께는 연이어 아픈 얘기지만 실버라잇이 준비가 제일 부족해보였어요 ㅠ.ㅜ 물론 오늘 발표된 기술들 중에서 베타 심지어 알파딱지도 아직 떼지 못한 것이기도 하지만요.

실버라잇에 집중하고 있으니 좀 더 자세히 얘기해보자면 실버라잇이 관심을 못받는 가장 큰 이유는 아마도 디자이너의 저변 부족이 아닐까 생각해봅니다. 두번째 세션인 쇼핑몰 예에서도 아주 적절하게 짚어 주셨듯이 Rich한 사용자 인터페이스는 XHR도 벡터 그래픽도 프로그래머빌리티도 아닌 단지 버튼아래 적절한 그림자 표현이 더 크게 다가온다는 점이에요.

무슨 얘기냐면 제 아무리 훌륭하고 멋드러진 기능으로 무장하더라도 디자인 감각 없는 개발자가 그걸 활용해봤자 일반 사용자에겐 아무런 감성도 전달할 수 없다는 것이고 RIA의 구현에서 가장 핵심적인 것은 아주 기초적인 디자인, 나아가 사용자가 쉽게 접근할 수 있는 인터페이스가 아닐까요?

다음으로 개발적인 측면에서 아직 공식 버전이 런칭되지 않았기 때문이겠죠. 프로덕션을 위한 런타임에 'Beta' 'Alpha'가 뜨는건 일반 유저에게 썩 기분좋은 일이 아닐거에요. 이것만으로도 큰 감점요인이죠. 물론 1.0 Beta는 올여름 느즈막히 공식 버전으로 런칭한다고 하지만, 1.1 Alpha는 연말로 미뤄진 것 같네요. 사실 개발자로써 1.0 Beta, JavaScript버전은 별 활용가치가 없다고 생각해요. 실버라잇의 진짜 위력은 1.1 Alpha, CLR 버전에 있고 실제 실버라잇 코드 작성에 있어서 JavaScript 개발 환경이 CLR 혹은 DLR 개발환경보다 우위에 있는 점이라곤 눈꼽만큼도 없다고 장담할 수 있어요. 이 얘긴 나중에 따로 하기로 하죠.

다음 세션으로 쇼핑몰 구축 사례인데요, 집에 와서 좀 둘러봤지만 사이트 자체는 썩 마음에 들진 않지만 개발 사례와 경험 그리고 사이트 구축에 대한 식견은 만점을 줄 수 있어요.

사이트 자체에 높은 평가를 못내리는 가장 큰 이유는! 일단 접속하자마자 반겨주는 '오류가 있습니다. 디버그 하시겠습니까?' 메시지. 아마 어도비 쪽 기술을 사용하는 웹 개발자들은 비주얼 스튜디오를 사용하지 않으시겠지만 비주얼 스튜디오 사용자들은 자바스크립 오류가 있는 사이트를 무지 싫어해요. 편집증 말기의 과민성 환자인 디버거가 사소한 오류에도 반응하거든요. 실수로라도 '예'를 눌렀다간 한참동안 디버거 띄우고 취소하고 어쩌고 짜증이 밀려오죠.

뭐 그래봤자 이런 개발자는 애초에 고객으로도 무시당할 만한 한국 최악의 계층이니까 상관 없겠지만(하아... 이런 말에 일일이 농담이에요~^^* 이렇게 쓰지 않아도 되면 좋겠습니다) 제 취향에도 좀 안맞는거라 별로 좋아보이지가 않았어요. 그래봤자 이것도 '개편후 매출이 늘었습니다!'란 한마디에 그냥 제 취향이 이상한게 되는거죠.

이게 중요한게 아니고 쇼핑몰 사례의 핵심은 RIA RIA 입으로만 떠들어봤자 고객들에겐 아무런 영향이 없고, 기존사이트와 99.9% 똑같은 구성을 하더라도 버튼 하나, 장면 전환 하나하나에 새로운 기술들을 도입해 나가는게 보다 고객에게 어필할 수 있다는 점이죠.

그런 자연스러운 기술 전환에 대해서는 좋은 평가를 받을만 한 것 같아요.


마지막 세션인 Raju Bitter씨의 OpenLaszlo는 정말 정말 정말 정말 정말 정말 정말 x 100 훌륭했어요.
아니 여태 이런걸 모르고 있었지? 란 생각이 머리속을 가득 채우네요.
사실 AJAX도 기술적인 관점에서는 그야말로 역사에 남을 뒷북이었는데 OpenLaszlo를 여태 몰랐다는게 엄청나게 부끄러워요. 아 어디가서 RIA니 웹 2.0이니 안다고 나불거리지 말아야지;;;

우선 링크부터 갑니다.
http://www.openlaszlo.org/

RIA, WEB 2.0 이딴거 다 집어치우고 웹쪽에 관심있다고 하시는 분은 무조건 들어가서 20분만 둘러보세요. 아 이래서 영어를 잘해야 하는데... ㅠ.ㅜ

그 중에서도 제가 얘기하고 싶은, 또 지향하는 핵심 구현 사례는 바로 이것.
http://www.click-shirt.com/

진짜 사용자 친화적인, 쉬운, 직관적인, 그러면서도 Rich한 UX가 무엇인가를 단 세페이지로 '구현'하고 있습니다.

Raju씨도 중간에 언급했지만 컴퓨터에 대한 지식이 없는 사용자들은 화면 전환이 일어나면 쉽게 내비게이팅을 하지 못한다는 점, 화면에 어떤게 메뉴고 어떤게 무슨일을 하는지 파악하는데 시간이 많이 걸린 다는 점을 잘 고려해야 합니다.

언제까지나 '국내 정서에는 안맞다' 라고 틀에 박힌 포털식 사이트만 만드는게 능사가 아니란거에요. 또 앞으로 다가올 IPTV시대, 즉 리모콘으로 조작하는 웹에 대한 비전도 좀 더 현실적으로 다가오고 있구요.

물론 이 데모는 단지 티셔츠라는 단순한 컨텐트만을 표현하는 게 전부지만, 초기 화면은 포털식 구성을 하더라도 개별 상품 카테고리 내에서는 이런 식의 직관적인 인터페이스로 구현하는게 어떨까 생각해봅니다.

제가 잘 이해하고 있는건지 확신이 안가지만, OpenLaszlo는 XML기반의 마크업과 ECMAScript(Javascript의 기초 언어) 문법으로 작성되어 이것을 컴파일하면 옵션에 따라 Flash 7, 8, 9 또는 DHTML로 결과물이 빌드되는 아키텍쳐를 가지고 있어요.

OpenLaszlo의 사용 편의성이나 개발자 지원, 도큐멘팅 이런걸 떠나서 이러한 중간언어적인 시도는 웹 표준화에 크게 기여하면서도 동시에 개발 플랫폼의 다양성도 양립할 수 있는 가능성을 보여준다는 점에 가장 높은 점수를 주고 싶어요.

이와 관련해서, .NET Framework는 애초에 개발 랭귀지에 관계없이 중간 언어로 컴파일한 뒤 .NET 런타임하에서 평등하게 실행되는 개념인데 바로 이런 개념과도 유사하다고 볼 수 있겠죠.

다시 실버라잇으로 돌아와서, 제가 Silverlight 1.1 alpha를 보고 턱 빠지게 놀랐던 건 CLR환경 뿐만 아니라 DLR이라는 이름으로 다른 언어들까지도 지원을 할 수 있는 가능성을 열어둔 점이었어요. 대표적으로 JScript, 파이썬.

실버라잇 1.1이 애초에 이러한 멀티 랭귀지 환경을 고려하고 있는 만큼 경우에 따라선 OpenLaszlo의 컴파일 결과물이 Silverlight이 될 수도 있겠고 반대로 Silverlight에서 OpenLaszlo의 문법을 수용하는 중간 언어가 만들어 질 가능성도 있다는 거죠. 물론 이런 가능성은 정치적인 이유로 성사되지 않을 가능성도 농후하지만요.

과장해서 말하자면, 프로그래밍 랭귀지간 매쉬업까지도 생각해 볼 수 있다는 거에요!

OpenLaszlo는 그 역사에 비해 오랫동안 몰랐다가 처음 접한 것도 있고 해서 약간은 흥분 상태에서 포스팅을 해서 오바가 심하긴 하지만, 웹의 미래에 대해 상당히 의미있는 생각들을 제게 던져준 것 같아요.

포스팅이 길어진데다가 컨퍼런스 내용과 겹쳐서 다음 글에 계속...
신고
Posted by gongdo
슬슬 RIA를 적용하는 사이트가 늘어나는 것 같아요.
지금까지는 대부분 영화관 같은 데가 고작이었는데 농협같이 언뜻 생각하면 딱딱한 사이트에도 RIA의 바람이 부는군요.
아마도 실험적인 성격의 사이트인 것 같은데 xbank라는게 있습니다.
플래쉬 기반으로 구현되었군요.
사용자 삽입 이미지
xbank 초기화면.
뭔가 좀 더 사용자 움직임에 반응을 해줬으면 하는데 어쨌든 시원하네요.
가장 필요한 메뉴를 단순하고 직관적으로 배치. 이게 기본이겠죠.
사용자 삽입 이미지
공인인증서 선택도 같은 폼 안에서 그래피컬한 윈도로 뜹니다. 이렇게 하는게 디자인 계통의 일관성을 지킬 수 있겠죠.

공인인증서 없이 사용할 수 있는 메뉴도 있는데요,


페이지를 통짜로 구성하고 스크롤하게 했네요. 나름 부드럽게 구동하고 느낌이 괜찮네요.
쓸데없는 메뉴가 최소화 되어 있어서 전체적으로 메뉴를 찾기 쉬운 것 같습니다.

이 정도 구성이라면 실버라잇으로도 빠르게 구현이 가능할 것 같지 않나요?
어차피 내부 로직이야 다 별도로 동작할테니 UI 쪽만 신경쓰면 될 것 같고요.

어쨌든 RIA를 적용한 UX의 구성에 대해 관심이 높아지는 건 사실인 것 같습니다. :)
신고
Posted by gongdo
TAG ria, UX, 농협


티스토리 툴바