http://developer.android.com/preview/material/index.html

에 나온 내용들을 중심으로, 디자이너들이 알아두면 좋을 내용들을 추려본다.


* The Android L Developer Preview supports drawable tinting: you can define bitmaps as an alpha mask and tint them using a color resource. You create these assets only once and color each instance to match your theme. Drawables also now support specifying most XML properties as theme attributes.
Tinting을 위한 컬러 리소스로 비트맵 이미지를 활용할 수 있게 됐다. 기존에는 컬러값을 코드로 지정하고, 그것을 불러다 사용했는데, 이제 비트맵 이미지에 투명도나 컬러를 입혀서 그걸 가지고 Tinting 작업을 할 수 있다(전체적인 브랜드 컬러를 유지하는게 가능). 옐로우톤으로 유지하던 전체 디자인을 비트맵 이미지 하나 바꿈으로써 그린톤으로 바꿔버릴 수 있다는 얘기.

*Bitmap -> Primary color libraryThe Android L Developer Preview Support Library includes a color extraction library that lets you automatically extract prominent colors from a bitmap image.
예전에 어떤 앱에서, 앨범아트의 가장 주된 색상을 뽑아다가 앨범 제목 텍스트에 입히는 것을 보았는데, 대략 그런 내용이다. 비트맵이미지에서 가장 대표적인 색을 하나 뽑아내주는 라이브러리가 탑재됐단 얘기. 

* Specify the elevation of your views to cast appropriate shadows.
material 디자인에 깊이(depth 라고 쓰지만 정확하게는 높이가 더 맞지 싶다?)개념이 들어왔다는 얘기는 익히 도는 소문대로. 근데 이 깊이를 지정하면 그림자 모양이 조금씩 달라져서, 화면에서 멀고 가깝고의 느낌이 달라짐.

*Rounded corner

<shape xmlns:android="http://schemas.android.com/apk/res/android"       android:shape="rectangle">    <solid android:color="#42000000" />    <corners android:radius="5dp" /></shape>

css의 border-radius 처럼 Round corner 값을 지원(이건 이미 있었음).


*outline
You can also create outlines in your code using the methods in the Outline class, and you can assign them to views with the View.setOutline method.
역시 css의 border  속성처럼 outline 도 지원하기 시작한다는 거. 

이렇게되면, 왠만한 카드타입, 박스타입의 디자인들은 비트맵으로 구성된 나인패치 없이도 그려낼 수 있게 됨. css의 초기버전쯤 지원한다는 얘기?

*Cliping views
Clip a view to its outline area using the View.setClipToOutline method (round, rounded rect)
이미지 클리핑 역시 지원되는데, 사각형(이걸 클립핑이라고 봐야하나?), 원형, 둥근모서리 사각형 등등을 지원한다고 함.


AND

앱디자인의 한계

mobile 2013. 9. 26. 10:55

현재의 앱디자인은 과거 웹디자인을 테이블로 짜던 시절과 거의 비슷하다. 모든 이미지의 shadow 를 포토샵에서 잘라내서 나인패치 형태의 테이블에 한 귀퉁이씩 짜넣던 그 시절. 이 답답함때문에 모바일웹 디자인이 차라리 편한 것 같다. 적어도 레이아웃에서 shadow를 고민하지 않아도 되니까. 

언제쯤이면 앱디자인에서도 CSS가 구현하는 수준의 언어기반 렌더링이 가능해질지....

AND

구글이 사이드메뉴를 공식적인 UI로 가져오면서, Google Earth 에 첫 적용을 했는데 (google shopper 도 있지만 국내에서 다운로드가 되지 않음), 구체적인 가이드가 아직 발표되지 않은 관계로 일일이 화면을 뜯어서 분석해보기로 한다.

image  image  image

왼쪽부터, 평상시, 눌렀을때, 펼쳐진 사이드메뉴.

 

image

사이드메뉴쪽 버튼을 눌렀을때 눌린 영역을 측정해보니 가로 97px, 세로 96px 로 나온다. xhdpi 환경에서 스크린캡쳐를 했기 때문에 대략 48dp 임을 알 수 있는데, 가로가 한 픽셀 차이나는 것은 잘 모르겠다.

image

저 문제의 햄버거 아이콘이 실존하는 것인지 알아보기 위해, apk 를 뜯어 이미지 리소스를 확인해본다. ic_drawer.png 라고 있다. 이 아이콘의 크기는 xhdpi 폴더에서 가로세로 32px. 즉 16dp 의 크기다.

image

구글어스의 캡쳐화면에 이미지 리소스를 갖다 얹어보면 딱 나온다. 앱아이콘이랑 살짝 부대낀다.

 

image

그리고 이것이 사이드메뉴가 펼쳐졌을때, 햄버거 아이콘이 왼쪽으로 스윽 빠진 모습. 이때의 가로폭은 21px 이 나오는데, 역시 딱 떨어지는 dp가 아니어서 아쉽다.

대략 16dp 에서 10dp로 뒷걸음질 하는 걸로 보고 6dp 만큼 애니메이션이 있다고 보면 될 거 같다.

 

image

앱아이콘과 크기 위치를 분석해보면, 앱아이콘은 32dp 수준으로 들어가고 우측에 4dp 정도 공간을 비워주는 듯 하다. 좌측 햄버거 아이콘이랑은 적당히 겹치는 양상. 그저 라이브러리가 있나보다 한다.

 

 

image

그리고 마지막으로 하나!
hdpi 폴더안에 들어있는 icon_dev.png 는 대체 무엇????? ㅎㅎㅎ

AND

안드로이드 4.0 디자인 가이드라인에 분명 메뉴키를 빼라 했지만, 제조사들은 최신 제품에 여전히 메뉴키를 고수하고 있다. 아마도 하위버전 호환성때문에 울며 겨자먹기로 메뉴버튼을 가져가는 것 같은데, 최신 안드로이드 앱에서는 하드웨어 메뉴키가 존재하는 것만으로도 사용성에 엄청난 타격을 입는다.

▲ LG 옵티머스 G pro(왼쪽) 와 삼성 갤럭시 노트 II (오른쪽) 의 하드웨어키

 

결론부터 말하면, 화면에 보여야 할 액션오버플로우(action overflow) 버튼이 사라지는 현상인데, 아래 그림과 같다. 똑같은 화면인데 오른쪽 스크린에는 버튼이 아예 없다. 하드웨어 메뉴키를 누르란 소리다.

*'액션오버플로우(action overflow)'는 액션바를 사용하는 안드로이드 4.0 이상의 앱들에서, 공간이 부족해서 나오지 못하는 액션아이템들을 한데 모아놓는 버튼이다. 구글 기본앱은 물론이고, 4.0 이상의 기본 가이드라인을 준수하는 앱이라면 대다수가 사용하고 있다.

  

▲ 하드웨어키가 없는 안드로이드(왼쪽) 하드웨어 메뉴키가 있는 안드로이드 (오른쪽)

 

물론 하드웨어 메뉴키를 누르면 동일한 기능이 작동하기 때문에, 기능 자체가 없거나 하는 것은 아니지만. 메뉴키 자체가 available 하다는 사실을 알려줄 수 없으니 사용성에 있어서는 정말 치명적이라고 할 수 밖에.

제조사가 이런 선택을 할 수 밖에 없는 이유에는 아마도 여러가지 이유가 있을텐데…

1) 그 동안 사용하던 하드웨어 홈버튼을 포기할 수 없어서. 
    (하드웨어 홈버튼은 사용성에 좋은 선택이니 어느 정도 이해함) 

2) 하드웨어 홈버튼을 그대로 사용하자니, 소프트웨어 키를 사용할 수 없음. (중복됨) 

3) 뒤로가기 버튼도 하드웨어 키로 처리 

4) 홈버튼을 하드웨어로 중앙에 박았다면, 이제 남은 자리는 한 자리. 여기에 ‘멀티태스킹 버튼’을 넣을 것인가? ‘메뉴 버튼’ 을 넣을 것인가? 

5) 안드로이드 2.x 대에서는 액션바를 사용하지 않으니, 메뉴키를 사용해야하는 상황이 생기면 어딘가에 메뉴키가 존재해야 함. 소프트웨어 키 영역이 아예 존재하지 않기 때문에, 울며겨자먹기로 하드웨어 키로 존재해야 함. 

6) 따라서, 남은 공간에 ‘멀티태스킹’ 같이 좋은 버튼 놔두고 ‘메뉴 버튼’을 넣을 수 밖에.

아마도 이런 고민의 결과가 아닐까 싶다. (이런 고민을 하기는 했겠지?)

하드웨어 키를 사용하지 않는 경우에도 이런 하위호환성을 위해서 소프트웨어 키 영역에 ‘메뉴 버튼’을 넣어서 처리하는 경우가 있다. 하지만 이건 어디까지나 소프트웨어 키를 쓰는 경우니까. 지들 맘대로 넣었다 뺐다가 되겠지.

▲ 소프트웨어 키를 사용하는 경우 하위호환을 위해 임시로 배치하는 메뉴키 (아우 궁색해보여)

 

더 큰 문제는 이런 액션오버플로우 버튼의 사라지는 현상을 간단한 옵션처리 등으로 막을 방법이 없다는 것이다. 안드로이드 디자인 가이드라인에서는 단지 ‘한 화면에 메뉴키가 2개나 존재할 수 없다’ 라는 (이것들아, 하드웨어 키는 화면에 없단 말이다!) 이유로 허용하지 않고 있다.

내가 제조사라면 어떻게 했을까?
메뉴키가 사용 가능한 경우 하드웨어 메뉴키가 깜빡 거려주는? 혹은 라이팅을 더 세게 좀 넣어주는 방법? 혹은 메뉴키 라이팅이 붉은 색으로 변해? 뭐 그런 식으로라도 처리하지 않는 이상. 누구도 이 화면에서 메뉴키를 쓸 수 있다는 걸 알 수가 없을 것이다.

결론은 이런 디자인 가이드를 만든 안드로이드가 나쁘다는 식의 결론을 내릴 수 밖에.
액션오버플로 버튼을 항상 뜨도록 허하라! 허하라!

AND

장점
- 300dpi가 넘는 해상도와 10.1인치 스크린. 확실히 책보기에 편하다. 넥7도 고민하다가 관둔것이 결국 a4사이즈 pdf 읽기가 어렵다는 판단이었는데, 이점은 확실한 듯.
- 안드로이드가 가지는 장점 : 터치인터페이스와 마우스+키보드 인터페이스를 모두 사용 가능. 블투마우스+블투키보드+윈도원격접속을 사용하면 그냥 윈도 노트북이 되어버림.
- 가격이 싸다. (그러나 국내에서 배송대행시키고, 필름붙이고 케이스달고 이래저래하면 그냥 아이패드 가격이나 별 차이가 없다)

단점
- 잦은 freezing 현상. 포럼에서도 자주 얘기되고 있고, 안드로이드 업그레이드로 어떻게 좀 나아지겠지... 하는 분위기. 사흘새 서너번 먹통됨. 내 뽑기운이 안 좋은가.
- 터치움직임을 따라오지 못하는 display frequency. 가로로 길게 놓고 쓸때는 위아래 스크롤이 크게 거슬리지 않는데, 세로로 놓고 위아래 스크롤 할때에는 주사방향이 좌->우 또는 우->좌 가 되기때문에 화면 울렁임이 심한 편. 핀터레스트같이 이미지를 많이 사용하는 앱들에서 쉽게 발견할 수 있음.
- 전면부에 로고나 라벨이 전혀 없기 때문에 하드웨어 버튼 찾기가 힘듦. 매번 네 귀퉁이를 다 더듬어서야 하드웨어 버튼 찾을 수 있음 –> 사진보면 일부러 왼쪽 위 귀퉁이에 스티커를 붙여놓았음. 이거 붙이고 훨씬 편해짐.
- 세로그립을 하면 조도센서를 손으로 가리게 되는 경우가 종종 생김. 이상하게 화면이 어두워진다 싶더니... 이게 손으로 센서를 가린 거였음.

AND

이전 포스팅에서 (http://zamar.tistory.com/162) 한 번 얘기한 적 있는 ‘5/6/5 디코딩’ 이슈. 32bit 이미지로 아무리 만들어도, 기기에서 256 컬러로 강제로 다운시켜버리는 현상이다. 이렇게 되면 넓은 면적에 그라데이션이 들어간 부분이나, 그라데이션이 있는 나인패치 들은 아주 절망적인 계단현상을 볼 수 있다.

이게 딱히 방법이 없어서 그 동안 깨나 골치를 썩였는데, 나인패치에 꼼수를 조금 부리면 기기에서 강제로 디코딩 하는 것을 막을 수 있다.

안드로이드는 이미지에 투명도가 조금이라도 들어가면, transparency 를 구현하기 위해서 32bit 이미지로 디코딩을 하게 되는데, 이걸 활용하는 것이다.

디자이너: 안드로이드님 여기 방금 만든 따끈한 나인패치입니다. 그라데이션 들어가 있으니 조심히 다뤄주세요.

안드로이드: 엇? 이 이미지는 그라데이션이 조금 있긴 하지만… 보자… 여긴 투명도가 없잖아. 뭐 이런거 따위에 32bit 디코딩을 해서 아까운 메모리를 쓰나. 됐어! 너는 그냥 256 컬러로 디코딩 해줘버리겠다!

디자이너: 흑흑흑… 내 그라데이션 안습 ㅠㅠ 

자, 아래의 방법으로 안드로이드를 속이고, 32bit 디코딩을 쟁취하자.

 

▲ 이것이 원본 나인패치

 

     

▲ 맨 위에 한 픽셀만 뜯어내자. delete 해서 아예 지워버린다.

▲ 여기가 핵심. 방금 잘라낸 곳과 거의 비슷한 컬러로

100% 가 아닌 99% 불투명도로 채워넣는다.

 

▲ 99% 불투명도로 채워넣어서 원래 나인패치와 비슷하게 만들어진 나인패치


디자이너: 안드로이드님 여기 방금 만든 따끈한 나인패치입니다. 한번 보시죠.

안드로이드: 흠. 보자, 흔한 나인패치 따위인 거 같은… 헛? 투명도가 있잖아? 어이쿠. 그럼 32bit 디코딩 해줘야지. 옛다.

디자이너: 오예! 땡큐땡큐~~ 나이스 그라데이션!

 

AND

아… 왜 진작 클라우드를 쓸 생각을 안 했을까.

바보같이 맨날 캡쳐화면을 메일로 보내고 있었네. 하여, 오늘 세팅해놓은 환경을 소개. 나와 같은 바보가 또 안 생기길.

 

iOS 환경

iOS 는 iCloud 로 아주 심플하게 해결할 수 있습니다.

1) 우선 iCloud 제어판을 PC에 설치합니다.
http://www.apple.com/kr/icloud/setup/pc.html

 

2) 설치후 iCloud 제어판에서 ‘사진 스트림’ 을 활성화 합니다.

 

3) 기본적으로 다운로드 폴더와 업로드 폴더가 생깁니다. 위치 바꿔주시고 싶으시면 바꾸시구요.

 

자. 세팅 끝!

이제 iOS 디바이스에서 화면캡쳐를 하면 자동으로 ‘다운로드’ 폴더에 캡쳐한 이미지가 쏙!
그리고 그래픽툴에서 만든 시안을 ‘업로드’ 폴더에 쏙 넣으면 iOS 디바이스에 스르르~ 하고 나타날 겁니다.

 

Android 환경

안드로이드는 한 방으로 해결되는 클라우드 서비스가 없어서 부득이 2 가지를 섞어서 쓰겠습니다.

 

I. Android to PC

1) 화면 캡쳐

화면을 캡쳐하는 툴은 제각각 알아서 쓰실테지만, 저는 마켓에서 ‘Screenshot UX’ 라는 걸 다운받았습니다.
PNG 포맷으로 화질 손상없이 캡쳐가 되는 점이 좋네요. 또, SDcard 안에 DCIM 폴더 하위로 캡쳐된 이미지를 경로설정 할 수 있어서 좋습니다. (이게 돼야 dropbox 를 쓸 수 있다는…)

 

2) PC로 자동전송

안드로이드 기기에서 찍은 사진이나 캡쳐화면을 자동으로 PC에 보내주는 툴이 몇몇 있습니다. 제가 사용해본 것들 중에 이게 되는 클라우드가 sugarsync 와 dropbox 인데요, 편의성으로나 안정성으로나 dropbox 가 낫습니다.

드랍박스를 실행하면, 중간에 ‘uploads’ 탭이 있는데요, 카메라로 찍은 사진을 자동으로 바로바로 올려버리는 세팅이 있습니다. 환경 설정 들어가면 Camera Upload 관련 설정이 있습니다.

기본적으로 SDcard 안에 있는 DCIM 폴더 밑을 자동으로 보냅니다. 따라서, 1) 번에서의 캡쳐 프로그램이 DCIM 밑으로 이미지를 저장하지 않으면 소용없습니다.

 

3) PC에서 받기!

dropbox가 좋은 건 새로 이미지를 싱크하면 자동으로 버블팁이 떠서 어떤 사진이 들어왔다는 걸 표시해주는 겁니다. 또 버블팁을 누르면 자동으로 사진을 열어주죠. (sugarsync 의 경우 이 기능이 부재해서 결국 버렸습니다. 안정성도 별로고)

 

II. PC to Android

드랍박스가 upload 까지 완벽하게 지원해주면 참 좋겠는데!!!! 그게 좀 문제가 있습니다. 바로 이런 거죠.

좋은화질  안 좋은 화질

▲ 왼쪽은 원본이미지 / 우측은 모바일에서 dropbox 앱으로 열었을 때

dropbox 앱에서 싱크된 이미지를 열면 화질 저하가 일어납니다. 전송된 사진의 퀄리티 문제가 아니라, 드랍박스 뷰어의 문제죠. 이렇게 되면 또 이 이미지를 SDcard 에 어디 저장해서 봐야하는데 그러면 이게 다 무슨 짓.

1) N드라이브 설치

드랍박스 외에 uCloud 도 써봤지만 원본 화질을 제대로 재현해주지 못하는 현상 + 풀스크린 지원 못함 ㅠㅠ
해서 그냥 N드라이브로 선택. full screen 에 원본화질 재현해줘서 굿.

 

▲ 전체화면 및 원본화질 재현이 되는 클라우드군요! 짝짝짝~

 

2) N드라이브 폴더에 시안 투척

이건 뭐… 포토샵에서 여기로 세이브 하시면 되겠습니다. 자동으로 폰에 동기화되겠죠?

 

 

Additional tip.

파일탐색기에 ‘즐겨찾기’ 에다가 이 클라우드 관련 폴더들을 정리해놓으면 좋습니다.

작업결과물 투척하기에도, 캡쳐화면 꺼내오기에도 굿!

AND

미로니에서는 생일과 관련된 뱃지를 나눠주거나 관련된 이벤트를 만들기 때문에. 가입할 때 생일을 받는 부분이 있다. (옵션)
입력하지 않을 수도 있기 때문에 그냥 스킵하고 가입할 수 있는데, 이럴 때 디폴트 생년월일이 들어가게 된다.
문제는 이 디폴트 생년월일이 너무 평범하면 다른 유저들의 진짜 생일과 구분할 수 없게 된다는 것…

해서 고민 끝에 1988년 2월 29일을 디폴트로 넣기로 했다.
여기에는 두 가지 이유가 있는데

1. 사용성
2. DB 필터링

현재 미로니를 주로 사용하는 유저가 10대 후반에서 30대 초반까지인데, 이 사람들이 80년생에서 90년생 사이다.
그럼 디폴트 생년월일을 너무 생뚱맞은 1900 등으로 만들어버리면 카운터를 +, -  하면서 자기 생년 찾기가 무척 힘들어진다. 해서 적어도 8,90년생들이 자기 생년 찾기에 어렵지 않도록 만들어 주는 것이 1988년의 의미.

그리고 2월 29일은 앞에서 말한 것처럼, DB에서 생일을 입력한 유저와 그렇지 않은 유저를 필터링 하는데 쓰인다.

AND

앞글에서 말한 문제를 해결하기 위해…

16비트 컬러로(라고 적고 256 칼라라고 부른다) 이미지 파레트를 고쳐볼라고 하니, 흔히 말하는 5/6/5 필터를 사용해야하는 상황이 됐다. 5/6/5 필터는 telegraphics 라는 데서 무료로 제공하고 있는데, 모바일 GUI 하는 사람들은 다 알고 있던 툴인 듯. (나만 몰랐어 ㅠ_ㅠ)

이 5/6/5 필터를 사용하면 dithering 을 통해서 그라데이션 같은 많은 계조가 필요한 것들을 눈에 거슬리지 않게 16비트 컬러로 낮춰준다.

언뜻 눈으로 보면 별반 차이가 없다. 그러라고 필터를 만든 거겠지만…
그러나 확대해서 보면 대략 이런 차이… (보일런지????)

 

오케이. 여기까진 좋았다.
근데 문제는 안드로이드에서 버튼 따위를 만들 때 많이 쓰는 나인패치(nine-patch) 에 이 필터를 먹이기 시작하면서 딜레마가 생겨버렸다.

왼쪽에 보이는 것이 원본 나인패치고, 오른쪽이 5/6/5 필터를 먹인 나인패치다. 문제는 나인패치에서 늘어나는 영역이 붉은 색으로 박스쳐놓은 저 한 픽셀이라는 데 있다. (늘어나는 픽셀의 범위를 더 지정할 수도 있지만, 해결책이 되지 못한다.)

보시다시피 5/6/5 필터는 그라데이션을 사방팔방 모자이크를 하면서 dithering 을 하기 때문에, vertical 한 픽셀만 잡아서 늘이면 진정한 의미의 dithering 이 되었다고 볼 수가 없다.

엄청난 그라데이션 깨짐 현상 ㅠ_ㅠ
그 결과는 아래와 같다.

앞서도 말했지만, 늘어나는 영역을 두어픽셀 정도 같이잡아놔도, 늘어난 영역에 픽셀들이 반복해서 채워지는 개념이 아니라서. 이 문제가 해결이 안 된다.

 

차라리 HTML/CSS 처럼 stretch 가 아닌 fill 의 개념으로 nine-patch를 만들 수 있다면, 좋겠는데. 고건 좀 아쉽다. (근데 이거도 또 다른 문제를 불러일으킬 듯)

안드로이드에서도 tile 형태로 이미지를 만들어낼 수 있음! (그렇다고 5/6/5 문제가 쉽게 해결되지는 않음)


AND

왼쪽 캡쳐는 HTC evo4G+ 에서 캡쳐한 미로니 화면이고, 오른쪽 캡쳐는 LG 옵티머스 LTE 로 캡쳐한 화면. 물론 둘의 해상도는 qHD 와 HD 로 차이가 좀 나지만, 이 문제의 핵심은 32bit 컬러 구현을 하느냐, 16bit 컬러구현을 하느냐의 차이로 귀결됨.

  

소프트웨어상에서 png 를 어떻게 decoding 해내느냐의 차이로 볼 수 있는데, decoder 를 어떤 것을 쓰느냐에 따라 다르다. PNG 디코딩은 뭐 여러가지 방법으로 가능한데, 우리 CTO님께서는 ARGB_8888 로 디코딩하라고 짜놓은 것을, 제조사에서 강제로 RGB_565 로 디코딩해버려서 나타나는 현상이라고 볼 수 있다. (삼성 갤스. 갤스투. 에스케이w 에서는 정상작동. LG 옵티머스 LTE와 삼성 갤럭시s2 HD LTE 두 모델에서 나타나는 현상)

16Bit Bitmap : #RRRRRGGGGGGBBBBB (RGB_565)
24Bit Bitmap : #RRRRRRRRGGGGGGGGBBBBBBBB (RGB_888)
32Bit Bitmap : #AAAAAAAARRRRRRRRGGGGGGGGBBBBBBBB (ARGB_8888)

지금까지 nexus one 이랑 htc 폰들만 가지고 테스팅을 해오다보니, 이런 차이를 발견하지 못했던 것 같다. 이 이미지 소스들을 다 고칠라니 아.. 답답하구만. 우선 나인패치는 그냥 두고 넙대대한 그라데이션들만 좀 손댔는데, 나인패치는 언제 다 고치나 ㅠ_ㅠ

AND