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)
이미지 클리핑 역시 지원되는데, 사각형(이걸 클립핑이라고 봐야하나?), 원형, 둥근모서리 사각형 등등을 지원한다고 함.


저작자 표시 비영리 변경 금지
신고

구글이 사이드메뉴를 공식적인 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 는 대체 무엇????? ㅎㅎㅎ

신고

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

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

 

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

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

  

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

 

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

신고

image

2010년부터 꾸준하게 증가하고 있는 ‘naver’ 라는 검색 키워드가 의미하는 바는.

저 그래프만큼 안드로이드 기기가 퍼져나가고 있다는 것으로 해석하면 될 듯.

신고

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

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

신고

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 은 나중에 따로 포스팅…하도록…)

신고

인터넷 아무리 뒤져도 이 문제에 대해 제대로 답을 주는 데가 없었다.

그러다가 어느 어느 쓰레드의 댓글 댓글에 겨우 적혀있는

‘시간대를 미국 시간대로 바꾸어 보세요’

덕분에 이 미궁에서 겨우 빠져나옴.

 

안드로이드 SDK 이거저거 다운 받을 때는 ‘미국 시간대’ 로 시스템 시간을 바꿔놓으면,

다운로드 하다가 멈춰버리는 현상이 잘 생기지 않습니다.

참고하세요.

신고

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

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

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

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

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

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

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

 

▲ 이것이 원본 나인패치

 

     

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

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

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

 

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


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

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

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

 

신고

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

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

 

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.

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

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

신고