받은지 3일 좀 넘었는데, 간단한 감상을. 늘 뭔가 진지한 디자인 글만 올리다가 갑자기 간단 사용기를 올리자니 어색하지만, 이 블로그가 원래 그거 하던 블로그입니다 여러분;;
그립은 완벽하고, 손에 착 감기는게 아주 좋다. 하지만 재질 때문에 떨어뜨릴 것 같은 불안함이… 케이스를 어서 사야 한다. 
화면과 베젤이 구분이 안 갈 정도로 블랙이 깊다. 색감은 아주 마음에 든다. 여러분 컬러는 스페이스 그레이입니다.
커진 화면은 좋다. 하지만 강제 해상도 scale이 된 앱들은 점점 꼴보기 싫어진다. 멀리서 보면 큰 차이가 없다고 하나, 이미 멀리서 봐도 큰 차이가 느껴진다. 꼴보기 싫을 정도인데, 앱들이 업데이트 대응이 늦다. 참고로 텀블러는 완벽 대응. 6의 경우에는 뭔가 더 활용할 만한 공간도 없고, margin들만 조정해 주는 수준이 되겠다. 매번 좋게 느껴지는 건 아니고, 오히려 작은 화면이 그리워질 때도 있다.
4.7인치의 경우 넓어진 스크린을 가지고 할 일이 딱히 생각나지 않는다. 미묘하다. 텍스트를 더 많이 읽을 수 있어서 좋을리가.
터치 ID가 제대로 동작 안하는 경우가 많은데, 그립이 달라져서일수도 있겠다. 예상치 못한 불편함이다. 5s에 하던 대로 엄지를 대면, 인식이 잘 되지 않아 꼭 한번씩 각도를 조정해야 한다. 터치 아이디에 여러 손가락을 등록해서 쓰는데 두번째 손가락이 가장 잘 된다.
전원 버튼의 위치가 바뀌면서 스크린 캡쳐는 아주 어렵게 되었다. 이것도 치명적인 단점. 
소리가 좀 작아진 것 같은데 기분 탓이겠지…
퍼포먼스는 5s와 비교하여 크게 좋아진 것 같지 않다. 와이파이에 물렸을 때 좀 느리다는 느낌이 있는데, 이것도 기분 탓이겠지… 5s의 속도라고 보면 될 듯.
뒷면의 절연 테이프와 카툭튀는 하도 말이 많아서 굳이 부연설명하지 않아도 될 듯. 난 카툭튀나 테이프보다 둥근 모서리 때문에 거치가 불편해진 게 더 아쉽다. 아무데나 세워놓을 수 있었던 시절이 좋았지. 
5s는 생폰을 들고 있으면 약간 보석같다는 느낌마저 주는데, 이건 좀 평범한 느낌. 하드웨어 버튼의 느낌은 5s보다 좋다.
Reachability는 쓰지 않는다. 4.7인치에서는 굳이… 라는 느낌.
전체적으로 아이폰이 좀 평범해졌다는 느낌이 든다. 안드로이드의 폼 팩터를 따라가서 더욱 그런 느낌이 들 지도 모르겠다.
하지만 그 안의 소프트웨어는 여전히 비범하다. 8.0.1은 특히 비범했는데, 터치 ID와 전화 기능을 마비시켰다. 지금은 8.0으로 내려서 쓰는 중.
일본 애플 스토어에서 정가에 구매하여, 배송 대행으로 받았다. VISA카드는 어지간하면 다 먹는듯. 의외로 간단하고 (상대적으로 저렴하게) 구입이 가능했다.
총평: 그냥 사세요 어차피 살거면서
  • Camera: LGE Nexus 5
  • Aperture: f/2.4
  • Exposure: 1/30th
  • Focal Length: 3mm

받은지 3일 좀 넘었는데, 간단한 감상을. 늘 뭔가 진지한 디자인 글만 올리다가 갑자기 간단 사용기를 올리자니 어색하지만, 이 블로그가 원래 그거 하던 블로그입니다 여러분;;

  • 그립은 완벽하고, 손에 착 감기는게 아주 좋다. 하지만 재질 때문에 떨어뜨릴 것 같은 불안함이… 케이스를 어서 사야 한다. 
  • 화면과 베젤이 구분이 안 갈 정도로 블랙이 깊다. 색감은 아주 마음에 든다. 여러분 컬러는 스페이스 그레이입니다.
  • 커진 화면은 좋다. 하지만 강제 해상도 scale이 된 앱들은 점점 꼴보기 싫어진다. 멀리서 보면 큰 차이가 없다고 하나, 이미 멀리서 봐도 큰 차이가 느껴진다. 꼴보기 싫을 정도인데, 앱들이 업데이트 대응이 늦다. 참고로 텀블러는 완벽 대응. 6의 경우에는 뭔가 더 활용할 만한 공간도 없고, margin들만 조정해 주는 수준이 되겠다. 매번 좋게 느껴지는 건 아니고, 오히려 작은 화면이 그리워질 때도 있다.
  • 4.7인치의 경우 넓어진 스크린을 가지고 할 일이 딱히 생각나지 않는다. 미묘하다. 텍스트를 더 많이 읽을 수 있어서 좋을리가.
  • 터치 ID가 제대로 동작 안하는 경우가 많은데, 그립이 달라져서일수도 있겠다. 예상치 못한 불편함이다. 5s에 하던 대로 엄지를 대면, 인식이 잘 되지 않아 꼭 한번씩 각도를 조정해야 한다. 터치 아이디에 여러 손가락을 등록해서 쓰는데 두번째 손가락이 가장 잘 된다.
  • 전원 버튼의 위치가 바뀌면서 스크린 캡쳐는 아주 어렵게 되었다. 이것도 치명적인 단점. 
  • 소리가 좀 작아진 것 같은데 기분 탓이겠지…
  • 퍼포먼스는 5s와 비교하여 크게 좋아진 것 같지 않다. 와이파이에 물렸을 때 좀 느리다는 느낌이 있는데, 이것도 기분 탓이겠지… 5s의 속도라고 보면 될 듯.
  • 뒷면의 절연 테이프와 카툭튀는 하도 말이 많아서 굳이 부연설명하지 않아도 될 듯. 난 카툭튀나 테이프보다 둥근 모서리 때문에 거치가 불편해진 게 더 아쉽다. 아무데나 세워놓을 수 있었던 시절이 좋았지.
  • 5s는 생폰을 들고 있으면 약간 보석같다는 느낌마저 주는데, 이건 좀 평범한 느낌. 하드웨어 버튼의 느낌은 5s보다 좋다.
  • Reachability는 쓰지 않는다. 4.7인치에서는 굳이… 라는 느낌.

전체적으로 아이폰이 좀 평범해졌다는 느낌이 든다. 안드로이드의 폼 팩터를 따라가서 더욱 그런 느낌이 들 지도 모르겠다.

하지만 그 안의 소프트웨어는 여전히 비범하다. 8.0.1은 특히 비범했는데, 터치 ID와 전화 기능을 마비시켰다. 지금은 8.0으로 내려서 쓰는 중.

일본 애플 스토어에서 정가에 구매하여, 배송 대행으로 받았다. VISA카드는 어지간하면 다 먹는듯. 의외로 간단하고 (상대적으로 저렴하게) 구입이 가능했다.

총평: 그냥 사세요 어차피 살거면서

지루한 디자이너

Cap Watkins의 글.

보통 예쁘게 만들고자하는 디자이너들의 태도와 달리, 이 사람은 “지루한 선택”을 하는 디자이너들을 그려냄. 그간 많이 보이지 않던 시각이라 신선함.

  • "영리함" 보다 "뻔함"을 선택한다 : 뭔가를 숨겨놨다가 드러내는 것과, 처음부터 드러내는 것 중에 후자를 선택한다. 비쥬얼 밸런스는 깨지겠지만 사용자들은 좋아할 것이다. 쉽게 찾을 수 있을테니까.
  • 줏대가 없다 : 맞는 아이디어를 찾아다니는데, 팀의 의견을 모두 존중하고, 거의 대부분의 아이디어를 시도한다. 입씨름 하는 대신 그 시간에 모든 아이디어를 실험해 보는 것이다. 심지어는 남의 아이디어를 밀어주기도 한다. 꾸준히 피드백을 요구하고, 새로운 아이디어를 찾는다. 그 결과 아이디어를 신나게 제공하고, 다른 아이디어도 듣게 된다.
  • 실용적이다 : 시간과 리소스가 제한되어있음을 깨닫고, 팀을 위해 희생할 줄 안다. 개발팀이 페이지 로드 시간을 단축시키도록 하기 위해 ui를 다시 그리거나, 디자인, 카피 변경도 하고 아이디어를 바꾸기도 한다. 어떤 경우건 팀을 위해 헌신한다.
  • 게으름에 가치를 둔다 : 만지는 모든 것에 흔적을 남기고 싶어하지 않는다. 일관성을 사랑하고, 스타일 가이드를 사랑한다. “틀린” 블루나, 갑작스레 새로운 패턴을 만들 일이 없다는 사실을 사랑하며, 이런 게으름을 유발하는 툴을 업그레이드/ 업데이트 할 타이밍을 잘 잡거나, 포기할 줄도 안다(줏대가 없다고 하지 않았는가). 이런 툴이 없다면, 잠깐 엄청 열정적인 디자이너가 되어 그걸 다 만든 다음, 다시 게을러진다.
  • 팀을 리드한다 : 이런 디자이너라면 구석탱이에서 무시받는 신세일거라 생각하지만 그렇지 않다. 대부분은 질문하러 가장 먼저 찾아오며, 그들의 눈을 신뢰한다. 남의 의견을 존중하고 기댈 줄 안다. 지루한 디자이너들은 자신이 답을 알고 있다고 생각하지 않는다.

첫 몇줄만 읽는다면 실력 없는 디자이너와 동급으로 여겨질 수 있겠지만, 툴 / 스킬에 대한 노력과는 별개의 이야기일 것 같다. 업무에 필요한 스킬은 할 수 있는 한 최대한으로 깎아 나가되, 실제 협업하는 과정에는 마치 게으른 사람처럼 보이도록 굴라는 의미이겠지.

내가 뭔가를 만들어낸 다음, 그걸 아무렇지 않게 포기하는 일은 정말 어렵다. 그리고 남의 피드백(주로 부정적인)을 받는 일도 너무 낯뜨거운 일이다. 속없는 사람처럼 구는 일은, 누구보다 단단한 내공이 있어야 가능한 일이 아닌가 생각한다.

주니어 디자이너 vs 시니어 디자이너

이미 많이 돌았겠지만, 믿고 보는 Julie Zhou의 디자이너에 대한 글….이 아니라 그림.

주니어 디자이너는 지나치게 활동적인 초록 요정을 쫒는 것 같다. 대체 뭐가 뭔지 전혀 알 수 없지만 이리저리 삐뚤빼뚤. 

그에 반해 시니어 디자이너들은 헤매더라도 그 안에 방법론을 찾을 수 있음. 말하자면, 문제 해결이라는 것은 늘 번뇌를 수반하는 일이지만, 혼란 그 자체인 주니어 디자이너의 프로세스는 본인도 괴롭고 남도 괴롭다. 어제 여기 넣었던 버튼, 그 버튼의 동작 방식, 그 버튼에 연결된 페이지, 하루만에 뒤집히는 일도 다반사지만, 왜 그렇게 되어야 하고, 그렇게 되면 어떤 점이 좋은지. 뚜렷하게 설명할 수 없이 캄캄한 동굴 속을 헤매고 다니는 느낌. 익숙하다.

예쁜 그림을 만든다.

새로운 가치를 만든다.

이건 정말 어려운 일이다. 어찌 보면 우리나라의 UI 디자이너들은 앞의 그림처럼 일하도록 강요받고 있는지도 모르겠다. 가치 창출이라는 것의 정의가 어떻느냐에 따라서 다르겠지만…

우리나라는 분업이 확실하게 되어있기 때문에 시간대비 생산성은 늘지만, 어찌 보면 그 때문에 조직 자체가 보수적이 되어가고, 결국 결과물에서 누구도 만족할 수 없는 경우가 왕왕 생긴다. 그럼에도 불구하고 디자이너들은 밤을 꼴딱 지새며 결과물을 다듬어 내지만.

주니어들에겐 문제를 인식하고, 솔루션을 만들어내는 일까지가 가장 어렵다. 

시니어들에겐 아이디어보다 실행과 결과가 전부이다. 출시한 이후에 더 어려워진다는 점이 가장 큰 차이이다. 그들에겐 출시한 이후의 결과가 새로운 문제 인식(주니어들이 한번 해내기가 어려운 그 일)의 시작이기 때문이다.

멋진 제품을 만드는 방법은 무엇일까?

도자기에서 그 해답을 찾을 수 있다고 한다. 팀을 두개로 나누어 도자기를 만들었는데, 한 팀은 도자기를 수없이 만들어가며 방법을 찾았고, 다른 한 팀은 끝없이 토의하며 단 하나의 도자기만을 만들었다. 결과는 앞의 팀이 좋았는데, 있지도 않은 제품을 두고 공상하며 토론하는 것 보다, 불완전하더라도 실물을 가지고 이야기하는 것이 훨씬 도움이 된다는 것이다.

제품을 만들기 전에 하는 흔한 실수는, “세상에 없던 무엇”, “무지하게 쩌는 무엇”을 내놓기 위해 꿈부터 크게 가진다는 것이다. 하지만 사실 그런 건 없는 것 같다. 결과적으로 무지하게 위대해 보이는 제품들도, 사실은 작은 시도와 실패가 겹쳐서 만들어진 산물일 것이다. 간혹 천재의 일필휘지와 같은 디자인이 세상에 나와 빅 히트를 치기도 하지만, 그 역시 이면에 숨은 노력이 있다고 믿는다. 한방에 되는 일은 없고, 만약 성공한 것 같아 보여도 내공이 없다면 금방 숨이 꺼지기 마련이다.

- 도자기 이야기는 여기(http://vimeo.com/102228362)에서 보고 들었다.

아이폰 6 스크린 수수께끼 풀기

아이폰 6 플러스가 발표되면서, 스크린에 많은 변화가 일어났다. 그래서 PaintCode에서 인포그래픽으로 설명한다.

포인트 (Points)

실제 그리게 되는 모든 좌표들을 ‘포인트’로 표현한다. 이는 추상적인 단위이고, 수학적인 좌표 위에서만 성립한다. 오리지널 아이폰에서는 실제 표현되는 픽셀까지도 동일했으나, 이전 더 이상 그렇지 않다. 

: 즉, 1픽셀을 1포인트로 쳤을 때 논리적으로 존재하는 픽셀 수를 말한다. 버튼이 포인트 공간 위에 얼마 정도로 자리 잡아야 하는지 따질 때 등에 사용한다. Xcode 상의 좌표 단위라고 보면 될 듯.

렌더링 (Rendered Pixels)

이 포인트 기반의 그림이 픽셀로 렌더링되는데, 이 과정을 레스터라이제이션(Rasterization)이라고 한다. 포인트 좌표에 스케일 요소를 곱해, 픽셀 좌표를 얹는다. 스케일 요소가 높을 수록 디테일이 뛰어나다.

일반적인 스케일 팩터는 1x, 2x, 그리고 3x(아이폰 6+)이다.

물리적 픽셀 (Physical Pixels)

아이폰 6+에만 해당하는 이야기인데, 화면이 렌더링 된 이미지보다 낮은 해상도를 가지고 있다. 이미지가 실제로 화면에 표시되기 전에, 낮은 해상도로 다운샘플(리사이즈)되어야 한다.

물리적 디바이스 (Physical Device)

마지막 단계는 계산된 픽셀을 물리 스크린에 표현하는 일이다. 모든 스크린은 PPI를 가지고 있고, 이 숫자를 통해 1인치에 어느 정도의 픽셀이 들어가는지 알 수 있으며, 따라서 현실 세계에 픽셀이 얼마나 크게 표현되는지 알 수 있다.

이제 이걸 텍스트와 라인을 표현하는 단계로 나누어 설명하는데, 라인 렌더링에 대해 요약하면 아래와 같다.

  • 현존하는 아이폰의 스케일 팩터는 3개(1x,2x,3x). 그 중 아이폰 6플러스는 스케일 팩터가 3이지만, 이후에 2208x1242픽셀에서 1920x1080픽셀로 다운샘플링 된다.
  • 다운스케일 ratio는 20/23. 즉, 렌더링되는 23픽셀마다 물리적인 20픽셀로 매핑된다는 이야기이다. 오리지널 사이즈의 87%로 스케일 다운되어 표현된다는 것.

이에 대해서 많은 이야기가 오가고 있다. 미디엄 글 두개를 추가로 링크해 본다.

https://medium.com/@nannerb/pixel-perfect-design-and-development-on-the-iphone-6-and-6-plus-11dac9f4fa4e

https://medium.com/@brucewangsg/the-curious-case-of-iphone-6-1080p-display-b33dac5bbcb6

위의 글은 1:1 픽셀 매치가 깨졌기 때문에, 리사이즈로 인한 블러링을 걱정하는 목소리들이 늘고 있는데, 차이는 생각보다 크지 않다고 하는 내용을 담고 있다.

하지만 어쨌건 그동안은 없었던 “downsampling”은 애플 제품에서 디자인하던 즐거움을 깨는 요소임과 동시에, 좀 더 많은 부분을 고려해야 하는 문제이기도 하다. Point 측면에서도 320x480, 320x568, 375x667, 414x736같이 4개의 해상도가 되었다. 고려해야 하는 레이아웃이 4개, 그리고 6+의 다운샘플링(신경쓰일 정도가 아니라곤 하지만)까지, 이제 아이폰 디자인도 꽤 복잡해졌다.

Apple Watch 관련 글 모음

굳이 내가 쓸 필요조차 없이 엄청나게 많은 글들이 올라왔다. 괜찮았던 글을 모아서 올려본다.

"A Watch Guy’s Thoughts On The Apple Watch After Seeing It In The Metal (Tons Of Live Photos)"

(원문) http://www.hodinkee.com/blog/hodinkee-apple-watch-review

(번역) http://ppss.kr/archives/29128

: 시계는 IT인들이 모두 가지고 있는 제품은 아니다. 주변에 시계를 차고 있는 사람들은 그리 많지 않다. ‘지인 이상’으로 범위를 확장해 봐도 그럴 것이다. ‘시계를 차는 사람들은 이 제품을 어떻게 생각할까?’ 라는 질문이 자연스레 떠오르는데 이 글이 어느 정도 설명해 줄 수 있을거라 생각한다.

"Once you get your hands on the Apple Watch, you’ll never let it go"

(원문) http://www.cultofmac.com/294923/get-hands-apple-watch-youll-never-let-go/

(요약번역) http://www.interpiler.com/blog/2014/9/10/apple-watch

: 애플의 시계가 다른 제품들 (휴대폰, 태블릿)과 마찬가지로 사람들의 마음을 빼앗을 것이라는 전망. 몇가지 포인트를 집었는데 동의할만하다. 무식한 진동이 아니라는 점, 이모티콘을 크게 띄우고 세심하게 디자인 한 점은 이것이 손목에 차는 시계라는 것을 잘 이해했기 때문이 아닐까.

"애플 키노트 감상기"

(원문) http://nymin.tistory.com/136

: Yahoo의 송민승님이 간단하게 요약한 키노트 감상문. 특히 Crown에 대해 잘 짚어주셨는데, 지난번 Google I/O에서 받은 G Watch는 전원을 켜는 법부터 시작해서 시간을 설정하는 법까지, 단 한 단계도 그냥 넘어가는 법이 없었다. 아침 식사 시간에 나누어줬는데 모두 앉아서 “대체 어떻게 활성화시키는거야” 라고 불평을… 중간에 시차 때문인지 시간이 틀어졌는데 당최 어떻게 고치는지 몰라서 한참 헤맸다. 심지어 전원을 켜고 끄는 버튼도 없었다.

그런 면에서 Crown은 아무튼 뭔지 모르겠는데 눌러나 보자 하는 사람들이 “탐색”하기에 딱 좋은 도구인 것 같다. 클릭 휠 같은 느낌.

미디엄은 왜 본문 서체로 FF Tisa Web Pro를 선택했나

애초에 Quora에 올라온 질문 답변 글인데, Forbes에서 다시 정리함. 

  • 사실 FF Meta Serif를 사용하기 전에도 FF Tisa Web Pro를 사용했었음. 폰트를 선택하는 일은 뭔가 임의로 한다는 느낌이 강했고, 디자이너 개인적인 선택 정도로 여겨졌었음.
  • 당시엔 Medium이라는 브랜드가 어떻게 보여져야 하는지 이해하지 못하고 있었던 때였고, 엄청나게 빠르게 움직였기 때문에 고려가 충분치 못한 상황이었음.
  • 이런 문제들은 브랜드 개발 시점에 떠오르게 되었고, 그것을 계기로 “무엇을 사용할 것인가”에 대한 질문을 스스로에게 던지게 되었음.
  1. "미디엄" 브랜드의 가치란 무엇인가? (제품/디자인 원칙)
  2. 누구를 위한 것인가? (퍼소나, 질문/답변, 피드백)
  3. 우리는 미디엄이 어떻게 받아들여지길 원하는가? (브랜드 리서치, 분석, 브랜드의 위치)
  • 이런 질문에 대한 답을 찾아나가면서, 전체 브랜드에 대한 방향이 뚜렷해지기 시작했음.
  • 브랜드의 주요 요소들에 원칙들을 정해나갔음. 여기서 요소들이란 로고, 컬러, 서체, 어포던스, 그리드, 베이스라인 같은 것들임. 좀 더 탄탄한 디자인 언어를 만들 수 있는 프레임워크.
  • 서체에 집중하게 될 때 쯤엔, 브랜드 가치에 대한 가이드가 많은 도움이 되었음. 정보가 더 많았고, 그에 따라 유저들을 위한 선택을 좀 더 잘 할 수 있었음.
  • 아티클들을 여러 서체로 비교하고, 따져보는 일은 우리가 이상적으로 생각하는 브랜드 방향에 맞는지 확인하고, 정당화하는 데 도움이 되었음.
  • FF Tisa Web Pro와 FF Meta Serif간의 비교에서는 FF Meta Serif가 좀 너무 격식있고 권위있어 보인다는 결론을 얻었음. 사실 확인 뿐 아니라, 스토리 텔링도 중요하다고 생각했기 때문에, 이보다는 좀 더 부드럽고, 격식없는 폰트는 유저들에게 그런 느낌을 줄 수 있을거라 생각했음. 
  • FF Tisa Web Pro는 여러 아티클 타입에도 잘 어울리고, 아티클 맥락과 충돌이 나지 않는 그런 폰트였음. 물론 보기에도 좋았고.
  • Myriad Pro를 버린 이유는, 폰트가 너무 많아서 로딩 타임이 길어지는 문제 때문이었음. 당시엔 FF Meta Serif, FF Tisa Web Pro, Adelle, Myriad 같은 폰트가 여러개 있었음. 그리고 우리는 이런 폰트들의 수를 단 두개로 줄이면서도, 그럴듯한 위계관계와 대비를 주려고 노력했음.
  • 그 결과 Freight Sans가 선택되었는데, Myriad Pro보다는 좀 더 개성있었고, 뉘앙스 측면에서도 FF Tisa Pro와 잘 맞았음. 

이 글을 쓴 Leigh Taylor는 얼마 전까지 Medium 디자인을 맡아왔고, 지금은 예전에 소개했던 noflo의 디자인을 하고 있음. 

UX의 일관성보다 중요하다고 생각하는 것.

generalapps:

스타트업을 하고 있고 내게 서비스를 디자인할 수 있는 책임이 있다고 하자. 1년 뒤면 떨어질 돈을 가지고 있고 (물론 나는 그런 돈이 없다) 지금 하고 있는 프로젝트를 완성 시켜서 1-2년동안 성공할 수 있는 확률을 높여야 한다.

혼자서 모든 것을 결정하고 혼자서 모든 책임을 질 수 있을까?

1-2억이 아닌 100억이 있는 회사에서 이커머스 서비스를 설계한다고 해보자. 스타트업과 마찬가지로 혼자서 모든 것을 결정하고 책임을 지는 것은 불가능해보인다.

친구인 Limisit가 쓴 글에 대해 이야기를 나눴었다. (매끄러운…

이해관계자(특히, 우리나라 대기업의 stereotype이라고 볼 수 있는 관리자형 인물들)들의 개입과 불필요한 프로세스가 생산성을 저해시키고 완성도를 낮춘다는 측면에서는 위에 언급된 대부분의 이야기들에 동의하지만, 그렇다고 해서 혼자 설계하는 것만이 답은 아니라고 생각한다.

이유를 간단히 정리하면:

  • 혼자 설계하면 놓치는 부분이 너무 많아진다. 적어도 꾸준히 제품의 비전을 공유하며 피드백을 주고 받을만한 파트너가 있어야 한다고 생각. 혼자 진행하면 막막할 때도 많고, 너무 그럴듯하다고 생각한 방향이지만 알고보면 전혀 엉뚱한 곳으로 가고 있을 때도 많았다. 여기서 파트너는 피드백만을 공유하는 대상이 아니라, 서로 치열하게 논의하며 같이 답을 찾아나가는 주체를 의미.
  • 디자인 프로세스에서 가장 중요한 것 중 하나가 “Feedback -> Iteration”: 혼자서 Iteration을 진행하는 것은 꽤 어려운 일이다. 다단계 컨펌이야 힘들고 비효율적으로 보이긴 하지만, 나의 디자인을 설득해나가는 것도 중요한 역량이라고 생각한다. 의사결정자가 일방적으로 “컨펌” 하는 건 옳지 않아보이기도 하지만, 그 결정에 책임을 진다면 안될 것도 없음. 결정만 하고 나몰라라 하는 경우가 문제.
  • 심플하고 매끄러운 경험은 설계하는 사람의 수와 관계 없다고 봄. 혼자 진행하나, 여럿이 진행하나 복잡하고 삐걱거리는 경험으로 갈 리스크는 비슷하다고 생각하고, 문제는 설계하는 사람들의 역량. 모난 부분을 빨리 드러내고 깎아내는 과정에서 우아한 경험이 만들어진다고 생각함.

어찌보면 권한과 책임의 이야기로 넘어가야 하지 않는가 하는 생각이 드는데, 이 이야기는 일단 여기서는 생략;

iOS에 바로 프로토타입을 올릴 수 있는 강력한 툴, Form

프로토타입 툴로서 Quartz Composer의 단점은 크게 세 가지가 있다고 볼 수 있다.

  • 용어의 모호함 : 툴에서 사용되는 언어가 디자이너에게 친숙하지 않다.
  • 복잡한 에디터 : 패치를 선으로 엮는 구조이기 때문에 복잡한 프로토타입을 만들 때엔 에디터 보는 일 자체가 일이다. 특히 이런 툴은 복잡한 프로토타입을 만들 때 쓰기 때문에 더더욱 문제.
  • 공유의 어려움 : 사용자의 환경에서만 볼 수 있기 때문에 인터랙티브 파일의 공유가 어렵다. 특히 모바일 앱 프로토타입을 할 경우, 기기에서 볼 수 있는 방법이 없다는 것이 문제

Origami는 용어의 모호함을 없앴다. 더불어 디자이너가 필요로하는 기능들을 잘 묶어서 유용한 패치를 제공해서 한결 쉽게 프로토타입을 만들 수 있게 되었다. 하지만 여전히 복잡한 에디터의 문제는 남아있고, 공유의 어려움은 전혀 해결되지 않았다. 내부적으로는 툴이 있다고 하지만, 아직 공유는 되지 않은 상태.

그런데 어제 RelativeWave에서 내놓은 “Form”이라는 대항마(?)가 공개되었다. 이 툴은 기본적으로 Origami+QC와 거의 동일한 node based programming 툴이다. 즉 패치와 패치를 선으로 엮어서 구조를 만들고 인터랙션 할 수 있는 것인데, 이 툴은 iOS 네이티브로 바로 프로토타입을 볼 수 있다는 점이 가장 큰 강점이다. 카메라, 모션 센서를 가지고 바로 이미지를 가지고 놀 수 있다. 

QC+Origami에 익숙하다면 바로 프로토타입을 만들 수 있다. 용어도 거의 동일하고, 에디터 구조도 거의 같아서 버벅임이 전혀 없이 바로 샘플을 만들 수 있다. 다만 QC와는 다르게 데스크톱용 뷰어가 없어서 폰을 항상 연결해야 한다는 점이 문제인데, 큰 장벽은 아닌 것 같다.

기능은 QC+Origami에 비해 아직 부족하다. 1.3버전까지 올라오면서 꽤 많은 기능이 추가된 터라, 단숨에 따라잡기에는 버거울 것 같다. 무엇보다 아쉬운 점은 QC는 Classic/Bouncy Animation이라는 아무 값이나 다 easing을 줘버릴 수 있는 막강한 툴이 있었는데, 여기는 포지션에 대해서만 주어진다는 것. 이건 QC를 많이 쓰는 사용자들에게는 좀 아쉬운 부분일 것 같다.

가격은 150불, iOS용 뷰어 앱은 무료다. 지금은 같은 Wi-Fi망에 물린 기기만 볼 수 있지만, 조만간 외부 망에서도 접근 가능하도록 할 예정이라고 하니 공유 측면에서는 정말 Framer 못지 않은 대안이 될 수 있을 듯. Free Trial도 제공하니 연결된 홈페이지에서 바로 시도해 보시길.

Edit : Spring은 포지션에만 주어지는 것이 아니라, 대부분의 값에 다 들어갈 수 있다. 초기 셋업이 아래와 같은데, 이건 말 그대로 참고용이며 아무 값에나 다 적용이 가능하다. 아마 이해를 돕기 위해 이런 식으로 표기한 것 같은데, 이렇게 표기하니 꼭 포지션에만 값이 들어갈 것 같은 착각이 드네. Origmai의 표현 방식이 더 나은 것 같다.

디자이너의 JS 통역사, uilang

오늘(?) Stripe의 디자이너인 Benjamine De Cock이 공개한 js 라이브러리 uilang이 화제다. 공개하며 이면에 숨겨진 철학을 같이 이야기하는데, 이게 꽤 공감이 가는 이야기라 간략히 요약 공유. 

  • 몇년 전 처음 Javascript를 배웠을 때 jQuery가 꽤 좋은 진입점이라고 들어서 “쓰기 쉬운” 라이브러리를 써보려고 했을 때 대체 어디가 쉬운 건지… 특히 어떻게 개념적으로 접근해야 하는건지 몰랐었음. 완전히 새로운 ‘언어’들이었기 때문에.
  • uilang은 매우 제한적인 언어임. 대신 그렇게 제한을 둠으로 인해 이벤트 핸들링을 어떻게 접근해야 하는지 명확한 가이드를 줄 수 있게 됨. 엘레멘트를 선택해서, 이벤트를 듣고, 같은 엘레멘트나 다른 엘레멘트의 클래스에 변화를 주는 것이 전부임. 이 워크 플로우는 개발자들에게는 너무 뻔한 걸 수도 있겠지만, 일반 디자이너들이 단번에 이해하기에는 어려운 일이었음. 
  • 말하자면, getElementsbyTagName(‘div’).addClass(‘clicked’) 같은 ‘명령어’는 언어의 측면으로 봤을 땐 한번에 이해하기가 대단히 어려움. 그걸 “add a clicked state everytime user taps a div tag”같이 일반 대화문처럼 바꾸어주는 역할을 하는 것.
  • uilang을 시작점으로 삼아 언어를 쉽게 이해하고 다음 단계로 나가길 바라는데, js로 바로 연결이 쉽지 않기 때문에 http://transpiler.uilang.com/ 를 만들었음. 이건 uilang언어를 쓰면 바로 js 코드를 뱉어주는 툴임. 완벽하진 않지만, 도움이 될 것 : 여러번 쓰고 포팅된 걸 보다보면 대강 코드가 뭘 의미하는 지 알 수 있지 않을까…

정말 말 같은 명령문을 만들었다는 것이 놀랍다. 마치 글을 쓰듯 프로그래밍을 할 수 있는 것이 장점이고, (우리에겐 아직도) 영어라서 좀 문제이긴 하지만 그래도 난이도가 확 낮아진 느낌이다. 단, 현재까지는 용도가 매우 제한적이다. 가능한 건 오로지 ‘클릭’ 이벤트를 받아서 클래스를 붙였다가 떼었다가 하는 수준이다. 게다가 css transition과 transform은 알아서 해야 하기 때문에 (거기에 css 클래스 개념과  html tag까지도 물론 알고 있어야 함) 어찌 보면 ‘이걸로 뭘 하란 말이냐’ 라는 말이 나올수도 있겠지만, 아래와 같은 코드로 뭔가를 움직여 볼 수 있다는 것이 어디란 말이냐.

clicking on “.try-it" toggles class "hidden" on ".info-box

교육에 목적을 두었기 때문에, 딱히 복잡한 수준까지 지원을 끌어올리지 않은 듯. ‘정말’ 간단한 javascript 공부를 하고 싶다면 uilang은 좋은 대안이 될 것임.