앱을 위한 알림 디자인 (Designing notifications for apps)

이 글은 Shashank SahayDesigning notifications for apps 글을 번역했습니다. 저의 모든 글은 허가를 받고 진행 하였습니다.

다양한 알림 모델 및 사용 시기 알아보기

presentation
Notification Models
안녕하세요. Feature Breakdown 시리즈를 계속 진행합니다. 5번째 기능 분석 - 앱의 알림 모델입니다. 알림은 처리하기에 복잡한 기능이 될 수 있습니다. 이 글에서 그에 관한 모든 세부 사항을 다루지는 않지만, 앱에 올바른 알림 모델을 선택하는 방법에 대한 명확성과 방향을 제시하기에 충분할 것으로 기대합니다.
알림 모델에 대해 논의하기 전에 알림의 개념과 구성에 대해 간략하게 살펴 보겠습니다. 알림은 사용자를 대상으로하는 앱에서 발생한 정보입니다. 다음은 알림의 몇 가지 중요한 구성 요소입니다.
presentation
Notification Models — Schema
Source : 알림이 시작된 앱의 일부입니다. 앱의 아키텍처에는 정보가 분류되는 여러 버킷이 있을 수 있으며 이러한 버킷이 알림 소스가 됩니다.
Information : 이 메시지는 알림을 통해 사용자에게 전달되어야 하는 메시지입니다. 예를 들어 "Daenerys Targaryen이 친구 요청을 보냈습니다" 또는 "Lord Varys가 당신을 팔로우하기 시작했습니다"가 있습니다.
Type: 알림은 주로 정보 제공 및 실행 가능한 두 가지 유형으로 구성될 수 있습니다. 두 유형 모두 앱의 상황에 따라 추가로 하위 유형을 가질 수 있습니다.
Notification Badge : 사용자에게 알림 메시지를 알려주는 시각적 표시입니다. 알림 표시는 점처럼 간단할 수도 있고 읽지 않은 알림 수를 표시하는 카운트가 있을 수도 있습니다.
Anchor: 앵커는 인터페이스에서 알림이 표시되는 앱의 시각적 구성 요소입니다. 이를 간단히 말하면 사용자가 알림 표시 / 배지를 볼 구성 요소입니다. 앵커는 알림 소스일 필요는 없으며 알림이 표시되는 구성 요소에만 적용됩니다. 앵커는 여러 소스 또는 한 소스의 알림을 저장할 수 있습니다. 이것을 생각하면 소스는 아키텍처 / 정보 수준에서 더 많이 나오지만 앵커는 알림 배지를 보는 시각적 구성 요소입니다.
알림은 앱이 사용자와 통신하여 앱으로 다시 가져올수 있는 매체 중 하나입니다. 따라서 앱에서 정말 중요한 부분입니다. 존재하는 가장 널리 사용되는 알림 모델을 소개하고 모델을 사용하는 것이 합리적 일 경우도 소개해 드리겠습니다.

1. Notification Center

이 모델에는 모든 알림이 도착하는 정의된 장소가 있습니다. 알림 센터는 사용 가능한 부동산에 따라 전용 화면 또는 플라이아웃이 될 수 있습니다. 이 모델에서는 모든 알림이 소스에 관계없이 알림 센터에 고정됩니다. 그런 다음 알림 센터에서 알림의 원본으로 이동할 수 있습니다. 이 모델을 알림에 사용합니다. 모든 알림의 시작점인 종 아이콘에 배지가 표시됩니다. 또한 읽기 알림과 읽지 않은 알림은 시각적으로 차이가 있어 사용자가 이를 구분할 수 있어야 합니다.
presentation
Medium — Notification Center
이 모델의 가장 큰 장점은 유연성입니다. 기존 알림이나 새로운 알림과 같은 모든 알림을 수용할 수 있는 곳입니다.
Guidelines
  • 모든 다른 유형의 알림은 동일한 설계 스키마를 따라야 합니다. 스키마를 설계할 때 확장성을 주요 목표로 고려하는 것이 중요합니다.
  • 알림 소스가 너무 많으면 알림이 너무 많을 때 이 모델이 약간 복잡해 보이기 시작할 수 있습니다. 비슷한 유형의 알림이 있는 경우 이를 그룹화하여 반복을 줄일 수 있습니다. 예를 들어, "산사 스타크와 3명이 친구 요청을 보냈습니다."
  • 알림 센터를 쉽게 검색하고 액세스할 수 있는지 확인하십시오.
다음과 같은 경우 알림 센터를 사용하십시오.
  • 제품에 기존 내비게이션 옵션에 고정할 수 없는 알림이 필요합니다. 알림이 제품의 기존 개체와 일치하지 않거나, 알림이 정보 아키텍처의 정의 된 원본에서 생성되지 않았기 때문일 수 있습니다.
  • 앱이 랜딩 화면에서 수용할 수 있는 것보다 더 많은 알림 소스가 있습니다.
  • 당신이 시간이 부족할 때. 가능한 모든 알림 시나리오를 검토하고 각각에 대한 앵커를 찾기 전에 기능을 전송해야 하는 경우가 있을 수 있습니다. 이런 경우에 알림 센터는 본래 매우 유연하기 때문에 쉽게 빠져나갈 수 있습니다.
2. 소스 고정(Anchored) 알림
이 모델에서 모든 알림은 알림 소스인 내비게이션 옵션에 고정되어 있습니다. 모든 알림을 위한 단일 허브/센터가 없습니다. WhatApp에서 더 좋은 아이디어를 얻으십시오. 두 플랫폼 (Android 및 iOS)에서 채팅 또는 통화 알림은 각 내비게이션 메뉴에 고정되어 있습니다. 이 모델의 장점은 더 많은 콘텐츠를 발견할 수 있다는 것입니다. 이제 사용자는 추가 된 중간 계층의 문제없이 알림에 의해 전달되는 정보에 직접 도달 할 수 있습니다. 그러나이 모델은 알림 센터만큼 유연하지 않거나 확장 가능하지 않습니다.
presentation
WhatsApp — Source Anchored Notifications
이 모델은 앱의 정보 아키텍처에 크게 의존합니다. 내비게이션은 다양한 유형의 알림을 모두 수용 할 수 있어야합니다. 이전 모델과 마찬가지로 읽음 및 읽지 않음 알림도 시각적으로 다릅니다.
Guidelines
  • 모든 알림을 랜딩 화면의 내비게이션 옵션 중 하나에 고정시킬 수 있는지 확인하십시오. 애플리케이션의 복잡성이 증가함에 따라 알림의 출처도 증가할 수 있습니다. 이 경우 알림 센터를 방문하거나 혼합 모델(즉, 고정 모델과 알림 센터를 결합)을 고려할 수 있습니다. 다음 섹션에서 혼합 모델로 이동하겠습니다.
  • 모든 앵커는 수용할 콘텐츠에 대한 설계 스키마를 가지고 있어야 합니다. 알림이 앵커 스키마와 일치하는지 확인합니다. 이를 이해하려면 WhatsApp의 예를 들어 보겠습니다. 여기에 있는 앵커 "chat"에는 채팅 객체의 모양을 정의하는 설계 스키마가 있습니다. 즉, 채팅에 고정된 모든 알림은 이 스키마를 따라야 합니다. "콜"도 마찬가지입니다.
  • 앵커를 쉽게 발견하고 액세스 할 수 있는지 확인하십시오. 중첩 된 앵커를 사용하지 마십시오.
다음과 같은 경우 소스 고정 알림 사용
  • 가능한 모든 알림 소스를 랜딩 화면에 저장할 수 있는 경우.
  • 알림의 모든 시나리오와 기존 설계 스키마를 통해 모든 알림을 수용할 수 있습니다. 이러한 알림은 고정된 소스의 스키마를 따르는 것이 중요합니다.

3. Mixed Model

이 모델은 두 모델의 조합입니다. 가장 일반적으로 사용되는 모델입니다. Facebook, LinkedIn, Twitter 및 Instagram은 이를 사용하는 인기있는 앱입니다. 여기서 알림 센터는 내비게이션 메뉴의 옵션 중 하나가되어 방문 화면에 있을 자격이 없는 출처의 앵커로 사용할 수 있습니다. 예를 들어, Facebook은 "친구"탭에 새로운 친구 요청을 고정하지만 페이지를 좋아한다고하는 초대장은 알림 센터에 고정됩니다.
presentation
Facebook — Mixed Model
이 모델은 두 모델의 장점을 모두 갖추고 있으며 대부분의 경우에 쉽게 적용할 수 있습니다. 알림 센터에 알림을 고정할 수 있지만 모든 시나리오를 검토하고 소스 고정 알림으로 수용할 수 있는 우선 순위를 지정하는 것이 여전히 중요합니다.
소스 고정 모델과 마찬가지로 이 모델도 내비게이션 메뉴에 크게 의존하며, 이제 알림 센터도 옵션으로 제공됩니다.
Guidelines
  • 제품 아키텍처에서 가장 중요한 정보을 식별하고 순위를 정합니다. 이러한 알림의 순위를 지정하면 소스에 고정해야 하는 알림과 알림 센터에 가야 할 알림의 우선 순위를 지정할 수 있습니다. 이 모델은 탐색에 따라 다르므로 사용 가능한 부동산에 따라 알림 구성이 변경될 수 있습니다.
  • 기본 앵커 및 알림 센터를 랜딩 스크린의 내비게이션 부분으로 쉽게 검색할 수 있는지 확인하십시오.
다음과 같은 경우 혼합 모델을 사용
  • 알림 시나리오를 검토했습니다. 각 소스에 고정할 수 있는 일부 알림이 있지만, 아키텍처의 기존 소스에 고정할 수 없는 알림도 있습니다.
  • 네비게이션에 소스가 중첩되어 있습니다. 예를 들어 Facebook 앱의 햄버거 메뉴 아이콘은 그룹,보기, 추억, 저장 됨, 마켓 플레이스 등과 같이 소스 아래에있는 알림에 대한 앵커입니다.
Conclusion
위에서 언급한 모든 모델은 올바른 상황에서 유용합니다. 앱에 대해 어떤 모델을 선택해야 할지 결정하는 것은 정보 아키텍처와 원하는 알림 유형에 따라 다릅니다.

이 글은 번역 글입니다. 원본 링크입니다.



presentation
안녕하세요! Early adopter입니다.페이스북 [DTF] 디자인 번역 공장 - Design Translation Factory 그룹도 많이 가입해주시길 바랍니다.
"보버"에서 "디자인 번역 공장" 연재를 저와 함께 해주실 분을 찾습니다. 하단 "리뷰" 또는 "페이스북"으로 편하게 메시지 주세요!
PS. 제가 사용하는 블로그 "보버"에 "함께 쓰는 블로그"라는 기능이 요번에 추가됐네요 ㅋ (미디엄에 퍼블리케이션 같은 기능..)
하단 링크 글을 보시면 "디자인 번역 공장"에 어떻게 함께 연재할 수 있는지 자세히 설명되어있습니다. 또는 쉽게 FB 메시지 주세요!
https://bit.ly/2L6WsZp