왜 실제 제품은 디자이너의 프로토타입과 다른가
이 글을 읽고 있는 당신은 이미 알고 있다. 정지된 화면만으로는 서비스 전체의 디자인 경험을 온전히 전달하기 힘들어졌다. 자연스럽게 인터랙션, 애니메이션의 중요성이 대두됐고, 경우에 따라서는 모션 그 자체가 가장 중요한 디자인 요소로 여겨지기도 한다.
툴은 하루가 다르게 바뀌어서, 디자이너들은 인터랙션을 만들 수 있는 다양한 선택지를 가지게 됐다. 간단하게는 키노트 / PPT 애니메이션부터, Pixate, Principle, Flinto, ProtoPie, Form, Framer 등 프로토타이핑 관련 툴들은 넘쳐나고 있으니 자신과 가장 잘 맞는 도구를 선택해서 디자인하면 된다. 만약 위에 소개한 도구들을 모두 처음 듣는다면, 한번쯤 시도해보는것도 좋겠다.
왜 실제 제품은 프로토타입과 다를까
하지만 프로토타이핑과 실제 제품 사이에는 좁혀지지 않는 갭이 있다. 나의 프로토타이핑 산출물이 매우 아름다워도, 그건 어디까지나 ‘움직이는 시안' 에 불과하다. 개발자가 ‘이곳에 인터랙션이 있으라' 고 작성하기 전 까지는 아직 제대로 된 걸 만든게 아니다.
그러한 이유로, 실제로 개발이 진행되다 보면, 디자이너의 의도와는 미세하게 다른 느낌으로 산출물이 만들어지기 마련이다. 특히 애니메이션의 경우 열심히 작업해서 전달한 프로토타입의 느낌은 경쾌하고 부드러운데, 빌드된 제품의 애니메이션은 뭔가 투박한 느낌일 때가 많다. 이런 상황이면 프로토타입을 함께 보며 이야기해도 큰 진전이 없는데, 그 이유로는
—
- 디자이너가 애니메이션을 구체적인 수치와 함께 전달하지 않았다.
- 프로토타이핑 툴의 애니메이션 옵션과 현재 개발 플랫폼의 애니메이션 옵션이 다르다.
- 개발자가 애니메이션의 종류 / 차이를 인지하지 못한다.
- 개발자가 애니메이션의 차이는 인지하나, 맞출 방법이 없다고 한다.
—
이런 상황일때가 많았다. 뭔가 개선이 필요한 상황이다. 열심히 프로토타이핑을 했는데, 테스트했던 많은 수고가 어떤 지점에서 유실되고 있는 기분이었다.
이 글은 이런 개인적인 아쉬움에서 시작했다. 크게 웹, iOS, 안드로이드 플랫폼에서 사용하는 애니메이션 관련 옵션을 대략적으로 살펴보고, 그중에서 어떤 값을 사용하여 개발자에게 전달하면 될 지 알아보려 한다. 또한 제목은 거창하게 들어왔지만, 세분화해서 애니메이션 커브만을 다룬다는 것도 미리 밝힌다. (나중에 내공이 더 쌓여서 다른 부분도 쓸 수 있기를 바란다.)
애니메이션의 종류
이 내용을 모르는 사람은 없겠지만, 먼저 애니메이션의 종류에 대해 한번 더 알아보자. 대부분의 애니메이션은 크게 아래 4가지로 분류된다. 익숙하고 직관적인 이름이다.
- linear : 등속운동. 애니메이션 처음부터 끝까지 같은 속도로 움직인다.
- ease-in : 점진적인 진입. 부드럽게 시작했다가 빠르게 끝난다.
- ease-out : 점진적인 퇴장. 빠르게 시작했다가 부드럽게 끝난다.
- ease-in-out : 점진적인 진입 및 퇴장. 부드럽게 시작해서 부드럽게 종료
위 예시중 ease-in-out을 주목해서 살펴볼 필요가 있다. 많은 플랫폼에서 디폴트 값으로 설정되어 있고, 애니메이션의 시작과 종료가 모두 부드럽게 진행되어 대부분의 상황에서 무리 없이 사용할 수 있기 때문이다.
하지만, 당신이 만약 애니메이션 속도를 미세하게 조절하고 싶고 (그것도 비대칭으로), 사이드메뉴가 퍽 퍽 하고 거칠게 튀어나올 때 마다 가슴이 아프고, 때로는 미세한 반동을 주고 싶은 욕망을 느낀다면, 이어지는 이 글을 정독해 볼 필요가 있다.
커스텀 애니메이션
자. 문제는 EaseInOut이 시작과 종료 모두 동일한 속도로 움직인다는 것이다. 오브젝트가 작은 경우에는 큰 상관이 없지만, 덩어리가 큰 오브젝트가 이 커브로 움직이면 어색함이 느껴진다.
이럴 때 진입시점의 가속을 좀더 빠르게 가져가면 느낌이 많이 좋아진다. 대부분의 경우 유저 이벤트에 따라 애니메이션이 시작되는 점을 고려해 볼때, 터치하자마자 신속한 반응을 보여줌으로써 ‘빠르다’ 는 느낌을 주기에도 좋다.
이처럼 디자이너가 의도한 효과를 위해서는 애니메이션 커브를 수정해야 한다. 그럼 어떤 값들을 기준으로 애니메이션 커브를 전달할 수 있을까? 이제부터가 재미있어지는 부분이다.
Cubic-bezier
애니메이션에 사용되는 커브는 ‘cubic-bezier’ 이라고 불리운다. 이것은 4개의 점을 기준으로 곡선을 그리는 방법으로, 웹, 앱 뿐만 아니라 기존의 많은 컴퓨터 그래픽스에서 사용하고 있는 보편적인 방식이다.
이 글에서 다루는 애니메이션에서는 시작점과 끝점을 각각 (0,0), (1,1) 로 고정시켜 두고, 중간의 점 2개만을 조절하여 그래프를 그린다. 잠깐만, 2개의 점을 고정시킨다고? 그럼 결국 필요한 것은 나머지 2개의 점의 좌표 아닌가. 그리고 이것을 실제 애니메이션의 움직임과 함께 잘 설명해주는 있는 웹사이트가 있다. 꼭 방문해보자. 앞으로도 자주 방문하게 될 것이다.
위 사이트에서 2개의 점을 드래그 해보면 cubic-bezier(A1, A2, B1, B2) 의 값이 각각 바뀌는 것을 볼 수 있다. 그리고 이 값이 바로 애니메이션의 느낌을 결정하는 것이다. 이전에 분류했던 4가지의 애니메이션도 cubic-bezier 의 특정 값을 미리 저장해둔 것에 불과하다. 숫자 4개만 가지고는 사람이 애니메이션의 종류를 떠올릴 수 없으므로, 미리 이름을 지어서 이해하기 쉽도록 한 것이다.
- linear = (0, 0, 1, 1)
- ease-in = (0.42, 0, 1, 1)
- ease-out = (0, 0, 0.58, 1)
- ease-in-out = (0.42, 0, 0.58, 1)
여기까지 왔다면 슬슬 눈치를 챘을것이다. 커스텀 커브를 전달하고 싶을 때는 위 사이트에서 테스트를 통해 4개의 좌표를 구한 뒤, 개발자에게 아래와 같이 말할 수 있다.
“cubic-bezier 기반 4개의 좌표를 전달드릴게요. 0.4, 0, 0.2, 1 입니다”
명쾌하고 깔끔하다. 오해의 여지는 찾아볼 수 없다.
그럼 이제부터 웹, iOS, android의 실제 케이스를 살펴보도록 하자. 플랫폼별로 차이가 분명히 존재한다.
웹 ( CSS3 )
위에서 예를 든 사이트에서 잘 동작하고 있는 만큼, cubic-bezier 방식이 문제 없이 잘 작동한다. 다만 css3 지원이 원활하지 않은 구버전 IE에서는 제대로 나타나지 않을 수 있으니 확인이 필요하다.
커브 값을 지정하지 않은 경우에는 앞서 분류한 애니메이션 종류에서 언급하지 않은 “ease” 를 디폴트 값으로 가지는데, 빠르게 시작했다가 천천히 끝나는 커브이다. 그래프의 앞뒤 기울기가 비대칭인 방식. 디폴트로 사용하기 적절하다.
/* Keyword values */
transition-timing-function: ease; /* Default */
transition-timing-function: ease-in;
transition-timing-function: ease-out;
transition-timing-function: ease-in-out;
transition-timing-function: linear;
/* Function values */
transition-timing-function: cubic-bezier(0.1, 0.7, 1.0, 0.1);Android
먼저 안드로이드에서는 애니메이션 커브를 Interpolator 라고 부른다는 점에 유의하자. Docs를 살펴보면 아래와 같은 리스트를 확인할 수 있다.
용어가 어색하긴 하지만 우측의 설명과 함께 읽어보면 금방 이해가 간다.
- AccelerateInterpolator = ease-in
- DecelerateInterpolator = ease-out
- AccelerateDecelarateInterpoloatr = ease-in-out
대표적으로 위와 같은 의미로 사용하고 있다. 그리고 cubic-bezier 방식도 역시 존재한다. 위 테이블의 맨 아래줄을 보면 정확하게 동일한 의미를 나타내는 것을 알 수 있다!
- PathInterpolator
An interpolator that can traverse a Path that extends from Point (0, 0) to (1, 1).
시스템에 미리 준비된 애니메이션의 종류가 예상보다 많지 않은가 ? 디자인을 진행할 때 아무래도 이런 효과에 대해서는 iOS 대비 제약이 많다고 생각했었는데, 괜한 걱정으로 밝혀졌다. 게다가 특정 Interpolator 들은 factor를 가지기도 하는데 ( 그래프의 기울기 조정 등 ) 이걸 미리 해볼 수 있는 앱까지 나와있다.
참고로 최근 업데이트 된 구글 모션가이드 에서는, 스탠다드 커브로 FastOutSlowInInterpolator 를 권장하고 있다. 이것은 css의 디폴트 애니메이션인 ease와 비슷한 기울기를 가진다.
iOS
마지막으로 iOS를 살펴보자. iOS는 CSS와 비슷한 키워드로 애니메이션을 표현한다. UIViewAnimation은 iOS에서 일반적으로 애니메이션을 처리하는 방식이라고 일단 이해하면 좋다.
UIViewAnimationCurve : Int {
case EaseInOut // Default
case EaseIn
case EaseOut
case Linear
}음 ? 옵션이 4가지밖에 없다. cubic-bezier 는 커녕 ease나 FastInSlowOut 같은 녀석들도 역시 제공하지 않고 있다. 혹시나 해서 EaseIn, EaseOut 그래프를 factor를 사용해서 수정할 수 있는줄 알았더니 그마저도 아니었다. 열심히 구글링을 해 보았더니 UIViewAnimation 말고 다른 방식으로는 가능하다는것 같았다.
CAMediaTimingFunction represents one segment of a function that defines the pacing of an animation as a timing curve. The function maps an input time normalized to the range [0,1] to an output time also in the range [0,1].
그런데 이 시점부터 점점 디자이너의 영역을 벗어나는 기분을 느꼈다. 가까운 개발자의 조언을 들어보니, UIViewAnimation 대신 CAMediaTimingFunction을 사용하게 되면 코드의 양이 많아지고, 유지보수가 힘들어 지는 등 이슈가 발생할 수 있다고 했다. 개발 구조에 대해서까지 디자이너가 관여하는것은 좀 아니라고 생각해서 대안을 찾아보기로 했다.
iOS에서 커스텀 커브를 표현하기
사실 바로 이 파트 때문에 글 쓸 마음을 먹게됐다. 결론적으로 말하자면, UIViewAnimation으로는 cubic-bezier 커브를 표현할 수 없는것 같다. 머리속이 혼란스러웠다. 결과적으로 다른 플랫폼 대비 가장 유연하지 못한 애니메이션 방식 아닌가. cubic-bezier는 포기하고, CSS의 ease, 안드로이드의 FastOutSlowIn 같은 커브. 즉 애니메이션의 진입부분의 속도라도 조금 더 빠르게 할 수는 없을지 찾아보기로 했다.
열심히 찾다 보니 spring 애니메이션 쪽에서 힌트를 얻었다.
UIView.animateWithDuration(0.5, delay: 0, usingSpringWithDamping: 0.3, initialSpringVelocity: 0.8, options: nil, animations: {
//object you want to animate
}, completion: nil)
damping value는 1 ~ 0 값을 가지는데, 0에 가까울수록 더 많이 진동하는 효과가 난다. 그렇다면 반대로 아예 damping을 주지 않으면 어떻게 될까? 즉, usingSpringWithDamping을 1로 주면 어떻게 될지 실험해봤다.
오호라. 이렇게 하면 UIViewAnimation을 유지하고, 원치 않은 spring 효과를 보이지 않으면서도, 사용자의 인풋에 즉각적으로 반응하는 빠른 애니메이션 효과를 보여줄 수 있다. 즉, CSS의 Ease, Android 의FastOutSlowIn 과 유사한 느낌을 iOS도 낼 수 있다.
요약정리
개발 플랫폼에서는 일반적인 경우의 애니메이션 처리를 위한 옵션들을 가지고 있다. 디자이너는 그 옵션들을 미리 알아둘 필요가 있고, 그 옵션에서 더 나아가 커스텀 애니메이션을 사용하고 싶을 때는, cubic-bezier 방식으로 전달하면 좋다.
특히 ease-in-out 커브에서 처음 진입을 좀더 가파르게 수정한 애니메이션이 여러 상황에서 적절하게 사용되는데, 이 경우 각각의 표현은 아래와 같다.
- CSS > Ease
- android > FastOutSlowIn
- iOS > usingSpringWithDamping: 1
비단 애니메이션의 종류 뿐 아니라, UI에서 제대로 표현되어야 할 요소들은 플랫폼에서 사용하는 값의 방식을 개발자에게 물어보고, 그 단위를 조정하는게 좀더 현실적이고 표준에 가까운 방식이 아닐까 한다.
긴 글 읽어주셔서 감사하며, 모쪼록 애니메이션에 골머리를 썩고 있는 많은 디자이너에게 이 글이 도움이 됐으면 좋겠다.
