Launching - App Architecture - iOS - Human Interface Guidelines

 

Launch experience 은 사용자들이 당신의 앱에 대한 평가를 내리는 과정에서 유의미한 영향을 미칩니다.

 

사용자들이 사용하는 기종과 상관없이,

그리고 사용자가 당신의 앱을 마지막으로 열었던 것이 얼마나 오래되었는지와는 상관없이,

Launch experience 는 빠르고 매끄러워야 (seamless) 합니다. 

 

launch: to begin something such as a plan or introduce something new such as a product:

앱에서의 launch experience 는 앱을 시작하여 launch screen을 띄우고 app's fisrt screen 으로 transition 된 직후 까지라고 볼 수 있습니다.

seamless: happening without any sudden changes, interruption, or difficulty:

seam 은 봉제선을 의미하며 예를 들어 봉제선 없는 의류 앞에 seamless 란 수식어가 붙습니다. 부가적인 의미로 "without stopping" 이 있습니다.

 

추가적으로, 사용자에게 즐거운 launch experience를 설계할 수 있게 도와줄 수 있는 가이드라인이 있습니다.

 

아래 링크를 참고해주세요.

"Responding to the Launch of Your App"

---

 

1. Provide a launch screen.

"Launch screen을 제공하세요"

 

시스템은 앱을 시작함과 동시에 앱의 launch screen을 출력하고, 곧바로 앱의 첫 화면 (app's first screen)으로 대체합니다.

 

instagram의 launch screen(좌), app's first screen(우)

Launch screen은 사용자에게 당신의 앱이 빠르게 작동하고 신속하게 반응한다는 인상을 줍니다.

동시에 launch screen 출력 중 앱 시작에 필요한 콘텐츠를 로드합니다.

Launch screen에서 매끄러운 화면 전환을 보장하려면, 그것 자체로 주목을 끌지 않으면서 앱의 첫 시작화면과 비슷한 평범한 screen으로 설계해야 합니다. 이에 대한 원문 가이드가 있습니다. "Launch Screen" - 이후 제 블로그에서도 다룰 예정입니다.

---

 

2. Launch in the appropriate orientation.

" 적절한 방향으로 launch 하세요. "

 

만약 앱이 가로(portrait) 와 세로 보기 모드 (landscape) 를 모두 지원한다면, 앱은 기기의 현재 방향에 맞게 launch 되어야 합니다.

당신의 앱이 한 가지 방향의 보기를 지원한다면, 그 방향으로 앱을 launch 하고 만약 필요하다면 사용자가 방향에 맞게 기기를 회전시키도록 해야 합니다.

Portrait Mode vs. Lanscape Mode

중대한 이유가 없다면, 세로 보기 모드 상태인 앱은 기기가 왼쪽으로 혹은 오른쪽으로 눕혀있든 간에 알맞게 세로 보기 모드를 보여주어야 합니다. 이에 대한 원문 가이드가 있습니다. "Adaptivity and Layout." - 이후 제 블로그에서도 다룰 예정입니다.

---

 

3. Avoid asking for setup information up front.

"시작하자마자 셋업 정보를 요구하지 마세요."

 

setup: the process of starting a business, project, service, etc.:

서비스 등을 갓 시작할 때의 처리 절차

 

사용자는 앱이 단지 본래 목적에 맞게 작동하기만을 바랍니다.

다수의 사용자를 위한 앱을 일단 설계하고, 나머지 소수 사용자들은 그들의 입맛에 맞게 설정을 조정하게 하면 됩니다.

초기 셋업을 다수 사용자에 맞게 설정해두어 셋업 정보를 요구하지 않게 설계하자는 의미입니다.

 

기기의 기본 설정이나 사용자가 해둔 기기 설정, 혹은 iCloud 와 같은 동기화(synchronization) 서비스에서 최대한 많은 셋업 정보를 가져오세요. 만약 반드시 셋업 정보를 요구해야 한다면, 사용자가 앱을 최초로 실행했을 때 설정하도록 유도하고, 추후 수정이 필요할 때 앱의 설정에서 수정할 수 있도록 해야 합니다.

---

 

4. Avoid showing in-app licensing agreements and disclaimers.

" 앱 사용에 대한 동의와 법률 사항 (이하 아래 인용 참고)을 보여주는 것을 지양하세요."

 

license agreements: a formal contract that allows a person or organization to use computer software...

앱의 사용에 관한 공식적인 법률 문서

disclaimer: a statemet that you are not responsible for something

권리 포기 각서라 사전에  정의되어 있지만 마땅치 않아 검색 후 찾은 웹사이트의 설명 부분을 추가로 기재합니다.
이 웹페이지는 웹사이트나 앱의 disclaimer 작성 목적을 크게 두 가지로 설명하고 있습니다.

목적 1. To warn ( 경고 )
목적 2. To limit liability ( 법적 책임의 제한 )

 

이러한 것들은 앱스토어에 게재하여 사용자들이 앱을 다운로드하기 전 읽을 수 있도록 합니다.

앱에 반드시 이것들을 추가해야 한다면, 사용자 경험을 해치지 않는 균형 잡힌 방법 (balanced way) 으로 앱에 넣을 수 있도록 합니다.

---

 

5. Restore the previous state when your app restarts.

"앱이 재시작될 때, 앱이 종료되기 직전의 상태를 복구하게 하세요."

 

사용자가 이전의 상태로 돌아가기 위해 똑같은 절차를 다시 밟게 하지 않게 합니다.

그들이 앱을 종료했을 시점의 상태에 이어서 앱을 사용할 수 있도록 앱의 상태 (app' state) 를 저장하고 복구해야 합니다.

---

 

6. Don't encourage rebooting.

"앱의 재시작을 부추기지 마세요."

 

재시작은 시간이 들뿐더러, 앱이 불안정하고 사용하기 어렵다는 인상을 줍니다.

만약 당신의 앱이 재시작을 하지 않고는 실행하기 어려운 메모리 혹은 다른 문제가 있다면, 그 문제를 해결해야 합니다.

사용자에게 재시작을 시키지 말고 말이죠!!

---

 

7. Avoid asking people to rate your app too quickly or too often.

"앱의 대한 평가를 너무 성급히 그리고 자주 요구하는 것을 지양하세요."

 

첫 launch 후 평가를 요구한다던가 - 혹은 앱을 사용할 때 사용자에게 너무 자주 앱에 대한 평가를 요구한다면 - 사용자를 짜증 나게 하고 아마 사용자에게서 받을 수 있는 유용한 피드백의 수가 줄어들게 될 것입니다. 사용자가 진지하게 숙고한 피드백을 받기 위해서는, 앱에 대한 평가를 요구하기 전에 사용자가 의견을 만들어 낼 수 있는 충분한 시간을 주어야 합니다. 앱의 평가 요청을 나갈 수 있는 선택지를 항상 제공하고, 사용자에게 절대로 평가를 강요해서는 안됩니다.

---

 

 

이전 글: [iOS] Interface Essentials

[iOS] Interface Essentials

 

끝.

---