요즘 저렇게 수저통을 식탁 옆구리에 넣어놓는 음식점들을 종종본다. 식탁을 넓게 쓸 수 있다는 장점이 있는 반면에, 도대체 수저가 어디에 있는지 알 수가 없어서 종업원을 부르는 경우가 생긴다. 의도는 그게 아니었겠지만, 종업원이 불려다니는 cost를 발생시키면서 나는 별로 좋지 않은 인상을 받았더랬다.

그래도, 화면에 저렇게 충분한 정보를 표기해준다면!!! 좋지 않은가?

image

image

AND

 

5나 6, 많아봐야 12 같은 두 자리 숫자가 나오길래 내심 출발시각이나, 출발까지 내가 기다려야 하는 시간 정도면 좋겠다고 생각했다. 그러나 불길한 예감은 늘 맞아들지.

 

 

대체 열차편성번호 같은 걸 일반 이용객이 봐야 할 이유가 뭔지 누가 좀 알려주세요.
이 거지같은 정보디자인이 언제부터 표준 비슷하게 자리잡아서 너도나도 따라하고 있는지 모르겠지만. 제발좀 싹다 바꿔버리고 싶은 심정.

AND

요즘 페이스북 ‘좋아요’ 버튼을 여기저기 많이들 사용하는데, 이게 facebook 에 있는 social plugin 을 활용한 거라, 맘대로 크기조정이 잘 안 된다. 특히, 안드로이드나 iOS 모두 버튼이라면 7mm~10mm 사이의 physical dimension 을 요구하고 있는데, 실제 facebook 에서 제공하는 ‘좋아요’ 버튼은 모바일에 올려놓으면 3~4mm 수준으로 밖에 안 나오게 되는 경우가 많다.

image

 

iframe 안에 들어가 있는 놈이라 css 건드린다고 width 나 height 조절이 안 된다.

image

▲ 누르기가 좀 답답한 facebook 좋아요 버튼.

 

방법 1 – viewport 에서 target-densitydpi 조정하기 (비추)

처음엔 이 방법을 썼는데, target-densitydpi 를 low – medium – high 로 조정함에 따라, 좋아요 버튼의 크기를 크게 3가지로 조정하는 것이다. 보통 모바일웹이 medium-density 를 다들 쓰고 있으니, 더 크게 하고 싶으면 천상 low-density 를 쓰던가 initial-scale 을 조정해야 하는데, 이건 작업 픽셀과 실제 구현 픽셀이 다르게 계산되는 거다보니 건드리면 복잡해진다.

<meta name="viewport" content="width=device-width, minimum-scale=1, maximum-scale=1" target-densitydpi=medium-dpi">

암튼, 별로 추천하지 않는 방법.

image image image

▲ 왼쪽부터 low-medium-high density 뷰포트에 따른 좋아요 버튼의 크기 변화.
이미 작업 다 해놓고 좋아요 버튼 하나 키우자고, 다른 것들을 죄다 조정한다? 에… 별로

 

방법 2 – CSS에서 transfrom:scale() 사용하기 (추천)

두 번째 방법은 좋아요 버튼을 감싸는 div 에 transform 을 먹여서 scale 을 불려버리는 방법이다. 이렇게 작업하면, 좋아요 버튼만 내 맘대로 키웠다 줄였다 할 수 있으니 편리하다.

.like_button{
transform: scale(2);                
-moz-transform: scale(2);        /* firefox 용 */
-webkit-transform: scale(2);     /* webkit 브라우저 */
-o-transform: scale(2);            /* opera용 */
-ms-transform: scale(2);          /* IE용 */
}

▲ 좀 큰가? 아무튼, 누르기 큼지막한 ‘좋아요’ 버튼

AND

no brand

들여다보다 2012. 11. 1. 10:20

image

AND

2012-10-23 21.36.03

1. 저런 걸 입에 집어넣고 먹을만한 애들 중에는 글을 모르는 아이들도 다수 포함

2. 글을 모르는 애들이 저 그림을 보고 뭐라고 생각할까

3. 맛있게 먹는거구나. 냠냠!

AND

design by logos

생각 2012. 10. 26. 21:38
요즘 css작업을 거의 맨날 하면서 여러가지 생각이 드는데, 무엇보다도 '재미'를 느끼는 작업이라 즐겁다. 이게 소위 말하는 design by numbers 에 제법 근사한 작업인데, processing 이나 flash AS 만큼의 visual expression을 목표로 하는 것은 아니지만, 원하는 것들을 그려내는데 큰 무리가 없다.

사실 웹이라는 것은 상당부분 정보를 전달하고, 사용자와 인터랙션을 하는데 목적이 있기 때문에 디테일한 그래픽에 꼭 의존할 필요는 없다. 되려, 웹표준에 의거하자면, 이미지가 하나도 없어도 웹을 사용하는데 문제가 없도록 만들어야 한다. 적당히 영역을 긋고, 그 위에 정보(글자)를 올리고, 버튼을 만들고, 그걸 누름직하게 만들어주고 하는 작업들은 이제 css만으로도 충분하다.

과거 포토샵에서 해야만 가능했던 온갖 shadow 효과, gradation 같은 것들이 이제 코딩으로 모두 해결이 되니까, 포토샵 없이도 상당부분의 이미지는 만들어낼 수가 있다. 또 코딩은 언제라도 그 수치를 조절할 수 있기 때문에, 픽셀 기반의 노동이 가져오는 비가역성으로부터 자유할 수 있어서 좋다. 또, 복제와 재사용이 용이하다는 점도, 이미지 소스 의존도를 최대한 낮추고 싶게 만드는 매력이 있다. (이것은 또 하나의 문제를 초래하게 될테지만, 그건 나중에 얘기하기로 하고)

둘째로, 이 작업이 재밌는 이유는 '상대값에 의한 관계적 디자인' 이 가능하기 때문이다. 이건 꼭 css라서 라기보다는 html + CSS 의 조합이라고 봐야하겠다.
parametric design 이란 용어자체는 사실 design by numbers 와 거의 동일한 얘기지만, 이 용어를 많이 쓰던 곳은 제품디자이너들의 3D modeling 툴에서다. 내가 애용하는 rhino 3d 같은 디자인 툴이 이런 parametric design 을 지원하지 못하는 ㅠㅠ 싼 툴이고, 고급 툴로 갈수록 이런 parametric design 을 철저하게 지원하고 있다. parametric design이 가능한 툴을 썼을 때, 비로소 이러한 '상대값 기반의 관계적 디자인' 이 가능해지는데, 예를 들면 이런거다.

휴대폰을 디자인 한다고 했을때, 가로 60mm, 세로 120mm 에 두께가 9mm 인 형상을 만든다고 치자. (보통 실무에서는 왠 종일 걸려야 형상을 만들어낼 수 있다.) 그런데 최종 결정권자가 와서는 "이거 두께를 0.5mm만 줄이지" 라고 얘기하면, 과연 이 작업을 다시 시작해야 할까?

▲ 이런 느낌?


내가 rhino 3d 로 작업을 했다면, 아마 n 시간을 들인 만큼 처음부터 n 시간을 투입해야 하겠지만, pro-e 나 solidworks 를 썼으면 (그리고 관계적 디자인을 매우 잘 설계했다면) 수치하나만 조절하면 모든 형상들이 re-generated 된다. 


css작업도 마찬가지다. 워낙에 사용자가 마주할 환경이 다이나믹 한 것이 웹이다보니, 그 예측못할 수 많은 상황에 responsive 하게 디자인되려면, 이런 관계적 설계를 디자인에 많이 도입해야 한다. 가령 화면은 가로폭이 1024px이 될 수도, 700px 이 될 수도 있기 때문에, 어떠한 상황에서도 이상하게 보이지 않을만큼의 flexibility 가 요구된다. 글상자의 폭을 무작정 700px로 맞춰놓아버리면 이런 상황에 대처하기가 어렵다. 여백이 남거나, 화면이 잘리게 된다.
그러니 화면폭에 맞추어서 몇% 수준으로 설정한다던지, 폭을 꽉 채운 상태로 가장자리로부터 얼마간의 padding 을 준다는 식의 관계적 설계를 해놓는것이다. 이렇게 하면 글상자의 크기는 언제나 화면에 종속되게 되므로, 내가 원하는 모양새를 유지하기가 쉽다.

마지막으로 이게 재미있는 이유는 내가 좋아하는 'high-effectiveness'를 추구할 수 있기 때문이다. 다만 몇 kb의 용량을 줄이려고 이미지 사용이 꺼려지는 웹디자인에서 css는 축복이다. 글자 몇 줄이면 몇 kb에 달하는 그라데이션도 해결할 수 있고, animation 도 가능하다. 물론 이걸 다 rendering해주는 브라우저가 있으니 감사한 일이지만, 디자이너는 이미지 용량 줄인다고 고생 안 해서 좋고, 또 아무리 확대를 해도 깨지지 않을 robust한 visual 을 가지게 되니 좋다. 애니메이션 만든다고 플래시 삽질을 안 해서 좋고, 다 만들어놓고 수정한다고 그래픽 툴 버벅대며 열 필요도 없다. 결국 시간을 버는 셈이다.

물론, 이 작업이 가지는 여러 어려움들이 여전히 산재해 있는 것은 사실이고, 개선의 여지도 무지하게 많다는 것을 인정하지만.
결국 디자인이 logos(말)로 다 가능하다는 것이, 조금씩이나마 증명되는 것 아닌가 하는 생각이 든다.



AND

SNIPPING.jsx


안드로이드 이미지 작업을 하다보면 반복적으로 해야하는 작업들이 있는데, 이를 좀더 편하게 해주는 스크립트를 만들어봤습니다. action 으로 만든 것을 script 로 변환해주는 action to script 를 활용하였고, (첨엔 자바로 좀 짜다가 코딩 미스가 자꾸 생겨서… ㅠㅠ) CS5, CS6 에서 제대로 작동하는 것을 확인했습니다.

이 스크립트는

1) 활성 layer 혹은 layer group 만을 트리밍해내고,
2) 이를 hdpi 용 이미지로 한벌 더 만들어주는 작업을 합니다.

 

이 때, 안드로이드 이미지 특성상, dp 단위와의 충돌을 피하기 위해서, 애매한 픽셀수의 canvas 가 되지 않도록 조정해주는 작업이 스크립트 내에 포함되어 있습니다. (이론상으로는 canvas 사이즈가 숫자 ‘4’의 배수가 되도록 조금씩 확장합니다. 자세한 내용은 이 포스트를 참조하세요.)

 

사용방법은 File > Scripts > Browse 하셔서 첨부파일을 실행하셔도 되고, 아니면SNIPPING.jsx파일을 포토샵의 작업화면으로 드래그&드랍 하셔도 바로 쓰실 수 있습니다.

 

* 참고
- canvas를 안드로이드 최적화 할 때, 이미지는 좌상단에 고정한 채로 canvas 만 늘어납니다.
- vector 로 구성된 이미지의 경우 hdpi 로 축소하고 난 다음에는 pixel 에 정확하게 fit 하지 않을 수 있습니다. 이 부분은 수동으로 움직여 주시면 되고, CS6에서는 transform 상태에서 좌우로 한픽셀씩만 왔다 갔다하면 정확하게 pixel 에 들어맞게 됩니다. (이 tip 은 나중에 따로 포스팅…하도록…)

AND

2012-09-23 09.05.47

하린이가 아직 세 살인데, 자기가 원하는 CD를 넣고 빼면서 곧잘 음악을 튼다. 허나 여전히 재생이나 정지, 다음곡으로 넘기는 조작은 그 위에 붙은 버튼을 익히기 전까진 어려운 일이다. (그 픽토그램을 설명하기가 어렵다)

해서, 아내가 스티커를 가져와서는 재생, 멈춤, 이전곡 이 세 버튼 위에 붙여버렸다. (다음곡 보다 이전곡에 스티커를 붙여준 것은 아마도 아무곡이나 다른게 나오면 된다거나, 방금 지나간 곡을 더 찾는 경향이 있어서일지도. 이건 다시 물어봐야지)

이제는 하린이에게 ‘하트 누르면 음악이 나와’, ‘발바닥 누르면 음악이 멈춰’, ‘별 누르면 다른 곡 나와’ 라고 설명할 수 있고, 하린이도 쉽게 익히더니 이젠 아주 능숙하게 제 원하는 음악을 튼다.

아내에게 박수를!!! 짝짝짝~

AND

택배 아저씨들의 자작 제품들은 늘 흥미롭다. 21세기에 만날 수 있는 몇 안 되는 vernacular design 이랄까. 언제고 이런 거만 잔뜩 모아보는 것도 재밌을 거 같은데, 이미 관련해서 연구하는 디자이너들도 좀 있는거 같다. (논문도 몇개 보임)

스마트폰 거치대는 타파통(?)에 스티로폼을 끼우고 전화기가 들어갈 만큼 딱 홈을 파낸 것이 인상적. 게다가 기저귀 고무줄로 고정까지.

밑에 메모패드는 더욱 대단한 것이. 어디서 줏어온 것인지 모를 자석 쪼가리를 얹어버리니 밑에 오일탱크가 금속이다보니 바로 메모패드로 변신. 대단한 거 같다.

2012-09-21 09.54.02

AND

아예 티백 손잡이에 저런 홈을 파 놓으니, 컵 언저리에 걸쳐놓을 수 있어 좋다.

2012-09-20 16.38.22

2012-09-20 16.38.46

AND