Art, Design & Lifelog

Art, Philosophy, Design, Font, Music, Essay, Critique, Diary, Opinion, News

IMG/UIX

UX의 ZEN. 01 - 우리는 언제 Blur를 사용해야 할까.

Curious ARTBRAIN 2021. 1. 6. 14:42

iOS 7이 발표된 지 벌써 7년이나 되었네.

2013년 6월에 발표된 iOS 7은 이전 버전과는 다르게, 스큐어모픽한 요소를 다 걷어내고 심플한 디자인으로 승부를 본 첫 시도였지. 아마도 더이상 스큐어모피즘을 사용해서 유저를 안내할 필요가 없다고 판단했기 때문일 거야. 이미 스마트폰이 충분히 익숙한 시대였으니까. 조너선 아이브가 당시 소프트웨어 총책임자였던 스캇 포스톨을 몰아내고(?) 소프트웨어 디자인까지 총괄했기 때문이라고 말하는 사람도 많았는데, 루머라기엔 실제로 마찰도 좀 컸었고, 사실이지 않을까 해.

 

초기 iOS 7 디자인, 네번째 이미지에 Blur UI가 처음 등장 - (c) Apple

 

iOS 7을 처음 공개했을 때는 저 Blur UI를 관심 있게 보는 사람들이 별로 없었어. 수많은 표절 의혹이 있었기 때문에 Blur UI는 얘깃거리가 되지 못했지. 당시만 해도 안드로이드와 iOS는 서로 달라야 한다고 믿는 사람들이 많았었고, 또 애플이 너무 노골적으로 상대방 진영(?)의 UI 요소들을 뻔뻔하게 차용했기 때문에, 당시 iOS 7에 대한 소비자의 반감은 매우 거셌던 걸로 기억해. 하지만, 저 Blur UI 만큼은, 표절했다는 기사를 본 적이 없는 거 같아. 아마도 애플 고유의 창작이지 싶어. 

https://developer.apple.com/design/human-interface-guidelines/ios/visual-design/materials/

 

그런데, 공식적으로도 비공식적으로도 - Blur UI의 종류에는 어떤 것이 있으며, 어떻게 써야 한다는 매뉴얼을 본 적이 없는 것 같아. 애플의 HIG 가이드를 뒤져 보면 딱 한 페이지 나오는데. 이게 좀... 애매하거든. 간단히 번역하자면 다음과 같아. 

 

  • 명칭 : 이제껏 "Blur UI"라고 불렀지만, 공식 명칭은 Materials...래. 구글과 헷갈리겠네. 뒤에 "or blur effects"라고 써놓긴 했어.

  • 방식 : 반투명 블러를 이용해서 깊이감을 만들어 준다. 배경 이미지를 블러해서 가독성을 살린다. (~ to evoke a sense of depth. / ~ while also blurring the background context to maintain legibility.)

  • 효과 : 앞의 컨텐츠에서 주의를 뺏기지 않고서도 배경 컨텐츠를 힌트삼아 컨트롤할 수 있게 돕는다. (The effect of a material lets views and controls hint at background content without distracting from foreground content.)

  • 주의 : 가급적 시스템이 정의하는 블러 옵션을 사용하라. 라이트/다크모드 연동에 유리하다. (~ these effects automatically adapt to the system's light and dark modes.)* 이 내용에서 말하는 "애플의 블러 기본 옵션"은 이 블로그 : PSPDFKIT에서 더 자세하게 설명하고 있어. 

 

요게 끝이야. 나머지 내용은 개발 스크립트에 대한 설명이고, 기능 정의나 용례 같은 건 찾아볼 수 없어. 이쯤 되면 애플이 일부러 사용 정의를 하지 않는 건 아닐까 의심스러워. 아직 스스로도 명확하게 정의 내리지 못하는 상황이거나, 확장 가능성을 테스트하는 중이기 때문에 섣불리 확정하지 않거나, 그것도 아니라면 특허 관련해서 민감하게 얽힌 내용이 있거나.

실제로도 애플은 iOS 7부터 현재에 이르기까지 여러가지 형태로 Blur UI를 테스트 해오고 있어. 조금씩 규칙이 보이기 시작하고, 그들이 하려는 말이 정리되는 느낌이야. 현재까지 애플 및 서비스들이 사용한 용례를 바탕으로 추론해 보았고, 리서치에서 보이는 패턴을 기준으로 정리했어.

 

728x90

 

1. 상실의 두려움을 방지해야 하는 경우

애플이 주장하는 걸 유저 방향에서 보면 이런 뜻인 것 같아. 컨트롤을 하기 위해서 UI를 추가해야 하는데, 이전 페이지를 벗어나지 않아야 하는 경우. 즉, 언제든 이전 화면으로 돌아갈 수 있고, 몇 번이든 다시 컨트롤을 불러낼 수도 있다고 유저를 안심시켜야 하는 경우 사용하라는 것 같아. 형태적으로는 블러 위에 컨트롤이 있고, 보통 스와이프로 작동해. (그래야 역동작을 하면 이전 화면으로 돌아갈 수 있다는 메타포가 성립하니까. 탭은 가역적이지 않잖아.)

이렇게 '돌아갈 수 있다'고 안심을 시켜주는 도구로서 블러는 참 영리한 사용인 것 같아. 모달이나 팝업도 같은 기능을 하지만, 이게 좀 더 세련된 방식이라 생각해. 사실... 팝업은... 고전적인 컴퓨터 OS로부터 그대로 넘어온 거잖아. 

또한, 이 경우는 대개 '갔다 오는' 형태의 UI Flow가 많아. 대표적인 게 볼륨 조절할 때. 화면을 아래로 끌어내려서 콘트롤 센터를 열고, 볼륨 바를 드래그해서 볼륨을 조정하고, 위로 스와이프해서 콘트롤 센터를 닫고. (물론, 거기에서 이슈가 있으면 다른 페이지로 점프하기도 하지만) 블러가 쓰이는 대부분의 플로우는 '잠깐 갔다 오는 기능'을 구현할 때 유용하지. 즉, Dead End 페이지.

하지만, 그저 정보를 보여주기 위해 띄운 페이지가 블러일 필요는 없다고 봐. 그런 건 일반 팝업이나 모달로도 충분해. 다시 말하지만, 단순정보 말고 컨트롤을 담는 경우에 Blur UI가 더 유용한 것 같아. 

 

왼쪽 페이지에서 탐색이 불편할 때, 이를 보완하기 위해 서치바(콘트롤)를 꺼내는 거지. 

 

그럼 일반 모달이나 팝업과의 차이는 무얼까? 나는 직관성에 있다고 봐. 확실히 Blur UI 위의 컨트롤은 직관적이어야만 해. 오래 관찰하거나, 숙고해서 결정하는 건 Blur UI와는 어울리지 않아. 화면 닫기/취소를 명시하지 않는 UI이기 때문에, 임시 화면이라는 성격이 강하거든. 

 

2. 화면의 톤을 유지해야 하는 경우

블러를 사용하면 UI 요소의 색상이 고정되지 않는다는 점을 이용한 거야. 화면의 톤을 망가뜨리지 않고, 집중해야 하는 컨텐츠(동영상)에 몰입을 유지시키는 역할을 해. 개인적으로 이건, 밤에 불 다 끄고 핸드폰으로 영상을 볼 때 유용한 것 같아. 이전 버전에서는 갑자기 눈뽕 당하는 경우도 있었거든. (특히 어두운 영화 볼 때)

 

iOS 6에서의 플레이어와 현재 버전 비교 - (c) Pixar, Addictive Tips

 

이런 "플레이어 UI"에서 블러의 톤 유지 능력이 빛을 발하지만, 다양한 색상의 모듈을 사용하는 앱 위에 동일한 UI를 오버레이 해야 하는 경우 활용하면 괜찮을 것 같아. 디자이너가 예상하지 않는 색 조합을 피하는 데는 이만한 장치가 없을 듯. 어떤 경우에서든 밑색을 참조하니까.

 

3. 화면의 확장, 또는 컨텐츠의 이어짐을 예상하도록 돕기

유저가 Blur UI를 가장 빈번하게 접하는 건 아무래도 네비바와 하단 탭바일 거야. 상하로 긴 컨텐츠의 연속을 보여주기 위해서 블러를 사용하는 것 같아. 위아래 탭바 밑으로 뭔가 희끄무레한 게 보이면, 유저는 은연중에 '뭐가 더 있구나'를 알 수 있는 거지. 디바이스의 물리적 크기를 커버하기 위해서 탭바 영역까지 활용하는 거랄까.

두번째는 특이한 케이스인데, 애플 뮤직 앱에서 나오는 가사 UI야. 마치 노래방처럼 현재 가사만 뚜렷이 보이고, 나머지 가사는 블러로 지워져 있어. (바로 다음 행은 읽을만 해) 이런 형태의 블러는 여러모로 효용이 있을 거 같은데, 왜 다들 안 쓰는지 모르겠어. 구현이 어려운 걸까? 아무튼 배경을 블러링하는 건 이제 흔한 기술이 되었지만, 오브젝트를 블러하는 경우는 흔하지 않잖아. 깊이를 관리하기 어려워서... 겠지?

 

(좌) 사파리에서의 탭바 (우) 애플뮤직의 가사 UI

 

 

4. 가독성의 확보 (논리가 빈약한 부분, 진행 중인가?)

블러를 적용한 부분과 적용하지 않은 부분은 시각적으로 극명한 대비를 보여주기 때문에, 컨텐츠 뒤로 넓은 영역에 블러를 주는 건 컨텐츠의 가독성을 높이는 데 아주 효과적이지, 애플 규정에 따르면, 요소(텍스트)가 세밀할수록 더 깊은 심도의 블러를, 톤을 잘 보여줘야 할 땐 얕은 심도의 블러를 사용하라는 것 같아. 하지만, 이 부분은 iOS의 각 요소들조차도 서로 통일되어 있지 않아.

 

(좌) iOS 7이 처음 등장했을 때의 컨트롤 센터, (중) 현재의 공유 모달, (우) 현재의 컨트롤 센터

 

제일 처음에는 블러와 UI를 동일 평면 위에 두었어. 그런데 만들고 보니, 흰색과 검은색 외의 색 계조를 사용하기 어렵다는 치명적인 약점이 발견된 거지. 블러된 면과 버튼을 동일한 높이에 두기 위해서 선형 테두리까지 사용했지만, 문제는 해결되지 않았어. 그래서 현재 컨트롤 센터는 박스 영역 위에 아이콘을 놓는 구조로 바뀌었고, 확실히 배경과는 다른 위계에 놓이게 되었어. 덕분에 유채색 색면도 사용할 수 있게 되었지. 여전히 아이콘은 단일 색상이지만. (처음 Blur UI를 출시했을 땐, 물리적으로 아주 얇은 두께를 생각했던 것 같아. 아이폰 박스 안의 설명서가 성경책 종이처럼 얇아진 것도 그때쯤 일거야.)

그런데, 이 컨셉을 더 확장해서 아이콘 이상의 무언가를 담으려다 보니 뭔가 석연치 않은 거지. 가운데 이미지에서 보듯, 애플은 모달이나 팝업 등 다이얼로그에도 블러를 적용하려 했지만, 이게 블러인지 흰색인지 구별도 안되게 만들었어. 이게 의미가 있나? 확실히 가독성은 확보한 것 같은데, 저건 무드를 잇는 것도, 전화면을 환기시키는 것도 아니잖아. 

또한, iOS 13부터 애플은 블러를 남발하고 있는데, 솔직히 난 애플의 행보를 이해하기 어려워. 무슨 생각일까? 

 

위젯과 앱드로어

 

블러 위에 블러를 두는 것이 뎁스 개념이라면 나름 이해하려 노력해 보겠는데^^, 한 화면에 여러 개의 블러를 중복해서 쓰는 건 좀 아니다 싶어. 서치 인풋에도 블러가 있고, 그 아래에 네비바 만큼의 작은 블러가 있고, 그 아래로 스크롤되는 모듈에도 블러가 있고, 마지막으로 최하단 영역도 블러가 있고 - 무려 4겹의 블러로 떡칠을 했는데, 이건 아니지 싶어. 아마 다음 개선 때 이 부분 디자인이 바뀌지 않을까? Force Touch도 비슷한 이유로 퇴화하고 있는 걸 보면, 이 화면들도 조만간 개선될 것 같아. 

 

에어팟 맥스 소개글 중 발췌  - (c) Apple

 

에어팟 맥스 웹사이트에 목업으로 얹어진 이미지인데, 많은 계위를 시각적으로는 참 깔끔하게 잘 정리했어. 역시 최저 연봉 1억의 애플 디자이너다운 솜씨. (애초에 많은 계위가 생기지 않도록 구조를 잘 짰어야 하는 거 아닌가. @_@) 하지만 그것과는 별개로, 이 형태가 확장 가능성이 있는지는 정말 의심스러워. 

하단의 어두운 리스트 부분은 최대 높이값이 있어서 그 안에서 스크롤 되는 것 같고, 맨 아래 아이콘은 초심을 잃고 점점 더 복합적인 형태로 발전해서 한 눈에 이해하기 어려워졌고 (그러니까 버튼 설명이 저렇게 길게 쓰였지) 앨범 섬네일은... 아마 트랜지션으로 바로 커지게 하려고 섀도우를 넣은 것 같기는 한데. 형태는 좋지만 이걸 어떻게 다른 곳에 활용하려고 하는 거지? 

애플은 이런 면에서는 정말 자유로운 것 같아. 확장성에 대한 고려 없이 디자인이 이쁘면 바로 라이브 하는 것. 그리고 그런 걸 인정하는 분위기. 하지만 Blur UI는 하나의 멘탈 모델로서의 위상이 잡혀가고 있는데, 너무 방임하는 건 아닌가 싶네. 

 

5. 갑자기 결론

그래도 애플이 UI의 한 요소로서 블러를 잘 도입했고, 이제는 충분히 대중적인 장치가 되었다고 봐. 안드로이드에서도 충분히 구현 가능한 상황이고, 심지어 CSS 미디어쿼리로도 괜찮게 따라 할 수 있게 되었지. 하지만, 아직은 확실히 블러를 "어떻게 사용해야 한다"는 공감대가 형성되진 않았다고 봐. 하지만 이 두 가지는 확실한 것 같아 :

  1. 블러 위로 뜨는 요소에는 가급적 컨트롤 만으로 구성해야 하며, 그 컨트롤은 직관적이어야 한다. 
  2. 블러로 나뉘는 뒤 화면과 앞 화면은 유기적인 연결성이 있어야 한다. 목적은 유저의 안도감이다. 

맞는 것 같아? ^^

 

[+]  구글 사이트에 이런 블러가 있네. 이것도 Blur UI의 한 형태로 편입될 수 있을까? (really?)

 

https://material.io/blog/android-material-motion

 

 

 


1 2 3 4 5 6 7 8 9